Confidential Consortium Framework (CCF) Part II: A deeper look and demos


hi everyone I’m Chris Klepper Program
Manager with the Azure Blockchain team I’ve got Sylvan Clebsch with me research
lead from MSR we’re here for part two of our CCF conversation Sylvan last time we
left off in part one we did a nice high-level overview of CCF where we can
get it and what we what we can do it in the value of it in the second session
let’s take a deeper dive we were discussing high confidentiality with him
within the platform can we do a bit of a double click into how confidentiality
and TEEs function and work within CCF fantastic an so Trusted Execution
Environments essentially provide a hardware basis as a root of trust
so it provides you with Harbor encrypted and integrity checked memory but that
memory works along with the software guard extensions with Intel or some
other technologies to such that even during execution memory remains
encrypted so even when you’re actually doing your computation on the on the
core you’re dealing with encrypted memory this is this incredibly valuable
stuff now that is not sufficient of course to get all the way to what we
need to do so we have to build on top of that so CCF relies on Intel SGX and
other hardware TEEs trusted execution environments but specifically we’re
really targeting Azure confidential compute which is Azure’s in some sense
deployment of Intel SGX and various supporting technologies but it’s CCF
does run both on-premises in Azure and even in other cloud which runs cloud
providers have that kind of confidential are available so that’s sort of the
ground truth of where we’re getting much of the special sauce of CCF as it were
but CCF then builds on top of that in order to provide the full environment so
one of the most important things it does is it runs the key value store the
execution engine and the consensus engine along with all of your trusted
communications ie your TLS sessions to the to the network inside of the enclave
to make sure that everything is both encrypted an integrity checked but also
importantly a testable so this has to do with being able to provide a
cryptographic quote a proof that a specific piece of code is running inside
of the Enclave and using that to build out the proof that a user is talking to
a network where all of the nodes in the network are these trusted execution
environment hosted nodes okay we talked about a little bit just now and in the
last session about how because of this trusted web in this trusted network
that’s established yeah with the enclaves we can we can tend to see higher
than average throughput of transactions in this framework that’s right with that
do we still need to rely on traditional kind of fault tolerant tolerance methods
that we’re used to seeing with blockchain absolutely so in some sense we use
slightly different methods than most public blockchains tend to require
proof of work or proof of stake and this sort of Nakamoto consensus style and instead we rely on techniques from distributed systems so effectively a CCF
has one mode now which is crash fault tolerance and soon we’ll have what’s
called Byzantine fault tolerance so in crash fault tolerance we expect all of
the nodes to be Hardware authenticated and thus we can prove that they are
doing the right thing but should they crash whether that’s because there’s a
network outage or a power outage or any kind of scenario that’s out of control
the code itself that we can tolerate F failures out of a network of 2 F plus 1
nodes and that’s crash fault tolerance we use approach to consensus called raft
which is a variation of paxos to do this where we run that algorithm inside of
the Enclave and we get these lovely crash fault tolerant guarantees that
keep us remote robust and resilient the fun stuff with Byzantine fault
tolerance there we can only tolerate F failures out of three F plus one but the
exciting thing here is that even if someone were to break the trusted
execution environment which is not something we expect to happen but it’s
important to have a defense in depth of some we’re able to compromise the entire
hardware environment we would still maintain integrity protect
give up confidentiality because they can recover encryption keys but we could
still maintain integrity and be certain that the network as a whole was
producing correct results it’s pretty fun guarantee next time and can you also
give us a quick idea on the lower level architecture of the network including
some the details on the actors involved in a CCF Network and how the ledger
implementation works yes absolutely so in some sense the service itself if we
think of the service as sort of a black box or a blue cloud as they say then we
can think of CCF operating over a key value store that’s running inside this
secure service now of course the secure service is actually made up of many
nodes but let’s just think about it as if it were a single entity at the moment
now that key value store when clients execute transactions over that key value
store produces a ledger and because each node in the network is producing its own
copy of the ledger and where we’ve got a consensus protocol over that over that
we’ve got a distributed ledger and that ledger itself is encrypted and signed so
this is important that we can maintain both confidentiality as well as the
normal type of guarantees of course the ledger is a miracle tree like you would
expect out of a box chain and the Merkle tree is is signed so that you have
integrity protection but the transactions themselves can be
individually encrypted on the ledger now how we’re running that is based on the
application that is built on top of CCF so in some sense that’s the bring your
own code piece now interestingly when we manage this we start talking about
another entity which is neither a user nor a node in the service but rather a
member and this is an identity that shares a responsibility for the
administration of the service and when I talked about rout of trust
earlier that was in in some sense as simplification we start we talk about
Hardware roots of trust but of course CCF is not ultimately rooted in the
hardware for trust it uses the trust in order to establish trust establish
certain guarantees but the root of trust is really the administrator or the
network because they’re able to make changes and what CCF does is
decentralizes that administration it creates a collection of
members each of which has voting power for any given CCF application you can
set up a constitution that controls how that voting power works whether you need
just one member or a majority or a unanimity or any fraction thereof to
make to make any specific change the configuration ie
adding and removing members I don’t know moving users adding and removing nodes
changing the version of the code that you accept moving from 1.2 to 1.3 these
kinds of decisions they’re made on the basis of votes that are
cryptographically signed and are part of the same total order of transactions so
that you know for any given transaction that you run on the CCF enabled platform
exactly what the rules were when the transaction was executed so how do all
these members and users talk to the service well roughly speaking they open
up a TLS connection like you would expect in a sort of normal rest based
web service and but that TLS connection terminates inside of the Enclave so it’s
so that even though it the CCF service is running on untrusted hosts in other
words we don’t expect that the host will survive in other words it might get
compromised by an attacker and yet we would still maintain all of our
confidentiality and integrity properties so because that secure channel
terminates inside the Enclave the host is unable to observe it and those
connections are used to ship transactions whether their governance
transactions or user transactions to the service then once the service gets them
the primary execute sit and comes up with a delta over the state and
distributes that Delta over all the backups and once sufficient backups have
communicated back to the primary that they agree that that Delta was
applicable we can call that transaction globally committed it’ll never be rolled
back and communicate that back to the user remember that fired the transaction
Thank You Sylvan let’s go ahead and show off a couple of quick demos of
applications built on the CCF Network so firstly to set the stage Microsoft has a
public relationship with JP Morgan in the blockchain space and so for this
demo we’ve gone ahead and built a demonstration of JPMCs quorum
surprise a blockchain application though using CCF for transaction processing the
Quorum team mentioned us they are looking for higher throughput and more
confidential transaction execution than quorum currently provides this scenario
demonstrates digital token transfer of JPMC’s JPM coin using virtual phone’s
on a Microsoft Power apps implementation what I’ll do is go ahead and fire off a
bunch of high throughput transactions and what we see here is basically a
transaction just executing a throughput speeds well beyond standard blockchain
implementations and JPM coins being transferred across a digital wallets
this demonstrates how CCF can be used for multi-party compete scenarios that
blockchain traditionally addresses to start approaching database speeds and
all transactions occurring with full confidentiality our second demo is an
application that is decoupled a bit from blockchain applications specifically
this is a multi-party application that represents money transfer across parties
we’ll see with this script that we fire off about 200,000 mostly right
transactions are executed in CCF you’ll see the output here is roughly 56
thousand transactions per second as printed at the bottom here which is well
beyond expected industry throughput so Sylvan just to wrap it up for
application builders on CCF is it safe to say we can summarize the work for
them to do as the following points firstly pick up the SDK and implement to
some degree code that receives client commands or transaction calls to the
framework secondly implement against the the ledger in CCF or a key value store
via basic you know crud or create delete updates and thirdly basically standing
up and running a running instance of the CCF network with their application code
is that a fair summary yeah that’s right CCF comes along with some examples
how to do this so it comes along with some example code using C++ as your
transaction to do things like logging secure auditable logging is really
interesting area it also comes along with sample code to use a Lua
interpreter to do smart contracts using the Lua language and of course we have
the EE VM which is an enclave based ethereum virtual machines such that
you can also integrate ethereum for virtual virtual machine and run you VM
transactions over the key value store so there’s a bunch of sample code and
helpers of transactions to get people started as well excellent thanks for
joining us again – thank you very much and thanks for joining us on Block Talk
for CCF you

You May Also Like

About the Author: Oren Garnes

Leave a Reply

Your email address will not be published. Required fields are marked *