Mark Russinovich: Hi. I’m Mark Russinovich, CTO of
Azure. And today, I’m going to talk to you about the
Coco Framework, the foundation of blockchain for
business.
Now, here at Azure, we’ve been working on blockchain for
a while and we’ve been making exciting progress. For
example, we’ve enabled enterprises to deploy the
blockchain network of their choice on top of Azure with
just a few clicks and the use of Azure Resource Manager
templates. We’ve also integrated blockchain networks
with Azure infrastructure and middleware, such as Azure
Key Vault and Azure Active Directory. And, we’re building
groundbreaking new applications and business models
on top of this support.
Now, for commercial enterprises use of blockchain, there’s
a number of limitations that sometimes get in the way
of the full potential of a distributed ledger.
One of them is that many blockchain networks suffer from
scalability problems, including throughput and latency,
where enterprises are used to the throughput and latency
they achieve from centralized databases and can’t achieve
that on blockchain networks that rely on something like
proof of work and cryptographic means to commit
transactions, resulting in transaction commit times of
tens of seconds and throughputs that can be as low as
20 transactions per second.
Another problem with many blockchain networks is they
lack any confidentiality model. In other words, any
enterprise member of a consortium that has a node is
able to see the full contents of the blockchain.
And then finally, in most enterprise networks today,
governance is left as an out of band process, where the
members must agree on changes to the blockchain
network rather than have a blockchain governance be
built right into the network itself.
Coco addresses all of these limitations through a
combination of advanced cryptography, novel consensus
mechanisms, and the use of secure hardware such as
Intel SGX.
And it’s important to keep in mind that Coco is not a
ledger itself. It’s a framework. And it enables arbitrary
ledgers to integrate with it and then achieve the benefits
that come with the Coco Framework, specifically scalability,
confidentiality, and built-in governance that enterprises
need to achieve real business results.
The prototype that we’ve created here that I’m going to
be showing you of the Coco Framework relies on the
RAFT consensus protocol, uses secure point to point
communications using TLS, and is built on top of Intel
SGX enclaves.
It’s got a configurable constitution that governs
memberships, such that the members can vote to add
new members to the consortium and also vote to eject
members from the consortium.
And the distributed ledger we’ve integrated with Coco
framework in the prototype is the Ethereum network.
But like I mentioned, arbitrary blockchain networks and
distributed ledgers can be integrated with Coco to
achieve its benefits.
What I’m going to show you is a couple of demos. One
of them that will demonstrate the scalability the Coco
framework provides in terms of throughput and latency.
And another one, a supply chain scenario, using the Mojic
supply chain software, where we’ve got multiple retailers
and suppliers that take advantage of Coco’s framework’s
confidentiality to prevent suppliers from seeing each
other’s purchase orders or inventory.
So, what I’m going to show you is Coco Framework’s
ability to provide confidentiality in an example consortium
scenario. In this one, we’re going to have a supply chain
where we’ve got multiple suppliers and multiple retailers.
Now, to simplify it, I just have two retailers and two
suppliers, and what we’ve implemented on Coco is a
confidentiality model such that one supplier shouldn’t
be able to see another supplier’s orders or inventory
and retailers shouldn’t be able to see each other’s
orders either.
I’ve got a dashboard here that’s seen by one of the
retailers, Retailer 2—Tray Research, and what they
want to do is open a purchase order against one of the
suppliers. The first step they’ll take is to go to the
purchase orders page and then click new order.
At this point, there is some default information filled in.
We’re going to select an approver. We’ve got the admin
as the approver. And now, we want to add some
products to order. In this case, I’m just going to order
one product. We’ve got a universal product code in our
system. I’ll pick the second one here. Pick a number of
items and then a sub total that we’re going to pay for
that item.
And we save that purchase order and then create the
order.
In this system, we’re using Ethereum and each of these
purchase orders is represented with a smart contract.
What I’ve just done when I created the order is submit
the smart contract to the Ethereum network on top of
the Coco Framework. Now, because I haven’t specified
any suppliers or any retailers as having access to this
purchase order, only Retailer 2 has access by default.
And we can go verify that by taking a look at the
purchase order here that was just created
by selecting it and copying it.
And then going to the dashboards of the other retailers.
Here I have Retailer 1 dashboard. If I go to the
blockchain view, go to smart contracts. Again, each of
these purchase orders is represented with a smart contract,
and enter that new purchase order. Sure enough, no
results are found.
If I go similarly over to Retailer 2 though and go to smart
contracts, enter the purchase order and do a search, I’m
able to see it.
I’ve also got the dashboards for the two suppliers here.
Here’s Supplier 1 and when Supplier 1 takes a look at it,
they’re also not able to find the purchase order because
it hasn’t yet been assigned to either of the two suppliers
I have here in this example.
Here’s the other supplier. If I go to smart contracts, enter
the purchase order, again, no results. So, at this point,
the smart contract’s authorized only for Retailer 2.
And now, what Retailer 2 needs to do is assign that
smart contract to one of the suppliers.
So, by clicking on it, I can then pick Supplier 1 or
Supplier 2. Let’s go pick one here, assign a role. And
what I’ve just done is updated the smart contract and
then authorized one of the suppliers—the one that I
want to issue the purchase order against—to see that
smart contract so that they can fulfill the order.
If I go back into the dashboards here for the two
suppliers, here, I’ve got Contoso and the purchase
order was issued to Contoso. So, when I do a search
again, I’m able to see that purchase order. Yet, the
other supplier is still unable to see it. And so, with
Coco Framework, we were able to very easily take a
smart contract, add a few functions that perform
authorization, and implement a confidentiality model.
It’s important to note that Coco Framework supports
basically a lift and shift of Ethereum smart contracts
and we’ve in this prototype not modified Ethereum in
any way—not the EVM, not the solidity language—but
rather just implemented a standard function interface
for authorization that Coco can call into to check to
see who has access to a smart contract.
So, it’s very simple to bring smart contracts and even
ones that don’t need confidentiality will simply run as is
on top of the Ethereum network running on the Coco
framework. We’ve added some confidentiality to these
examples, but it was a fairly simple amount of work
to implement that confidentiality model.
And so, Coco Framework provides this confidentiality
model as well as others, arbitrary in nature. We could’ve
made it so that both suppliers could’ve seen it or both
retailers could’ve seen this purchase order, but this is
just one example of the richness of confidentiality that
Coco Framework can provide.
So, let’s see how the Coco Framework can improve the
scalability of distributed ledgers.
Now, for this comparison I’ve got here, we’ve got the
stock Ethereum network and Ethereum integrated
with the Coco Framework running as multi-node
systems, multi-node networks on the same hardware.
I’m going to press the compare button and then
describe what we’re about to see.
What we’ve done is taken 2,000 transactions off the
public Ethereum network and submitted it to both of
these implementations. We’re going to look at the
throughput as well as the latency at which they
commit those transactions. Now, a few comments about
the way that we’re measuring this.
First, on the Coco side, we’re submitting in batches of a
hundred transactions and this is one of the tradeoffs
you can make with Coco is the size of the batch versus
the kind of latency that you’re looking for. The larger
the batch size, the higher throughput you’re going to
get, but the latency is going to suffer. And we’ve picked
something kind of in the middle here, and you can see
that we’re achieving about 1600 transactions per second
throughput with the latency that is about 150 milliseconds.
Now, on the Ethereum network, what we’re able to see
here is that we’re achieving a transaction throughput
which is pretty close to what we’ll see in the public
Ethereum network of anywhere between 15-25 transactions
per second. And we’re seeing latencies up in the tens of
thousands of milliseconds. And so, what this demonstrates
is that with integration of an existing distributed ledger,
in this case Ethereum, on top of the Coco Framework,
we’re able to take advantage of the Coco Framework’s
distributed consensus algorithm, which relies on a
trusted execution environment. In this case, we’ve got
the prototype running on top of SGX to commit
transactions very quickly and very securely. And we’re
able to achieve performance improvements of roughly
two orders of magnitude over what’s achievable on
stock distributed ledgers.