The Confidential Consortium Framework (https://ccf.dev/) is an open-source framework for building highly available stateful services that leverage centralized compute for ease of use and performance, while providing decentralized trust. It enables multiple parties to execute auditable compute over confidential data without trusting each other or a privileged operator.
The feedback from customers of CCF had been that building apps was easy but managing the infrastructure and framework was not. This preview provides a fully-managed CCF deployment where Azure handles all infra and framework tasks so that developers can focus on their apps, without any change in the trust model.
I do appreciate the fact that the Azure team is here, noting feedback and routing it. I had a longstanding complaint about how Cosmos' mongo API was incomplete, and my complaints about it here were noticed and it did eventually get fixed. So, it may be slow, but the Azure team isn't unresponsive.
Thanks much for providing specific feedback on areas where Azure could do better. This is really helpful and I've followed up with owners for the components you mentioned. None of these points fall directly into areas that I work on, but I'll make sure teams are aware.
I did want to correct one misconception, which is that we do not outsource Azure product development (we do, from time to time, hire contractors to add force on projects, but these projects are led by FTEs who are involved on a daily basis). There are certainly areas where we strive to target lean MVPs so we can get new products into customers' hands faster and get feedback earlier. I'm sure there will be some sharp edges there and we greatly appreciate you giving these services a try.
The technical whitepaper clarifies some of these points. To summarize, Coco networks are permissioned. Every authorized member can run a node, and all nodes see all data on the ledger. The code running inside of TEE-protected enclaves on each node determines what subset of the ledger data to expose to each caller, based on the permissions they are granted. Coco enforces basic network-level authentication, but the ledger and the smart contracts on the ledger enforce all of the app-level authN/Z.
We tried to address several distinct concerns with Coco: scalability, latency, confidentiality and governance. Scalability and latency are determined largely by the consensus model of the network. Our intent with Coco is to make consensus pluggable so that each network can make its own choices (via the Coco network constitution) about how to run their market.
I agree with you that the branding is tricky, in part because the dominant term "blockchain" is describing a specific data structure. The key point we wanted to convey with Coco is that we are trying to enable secure, performant, multi-party computation. We think there will be many models for this over time as TEEs come into wider use. "Blockchain" is just one of them.
We tried to address several separate concerns with Coco: scalability, latency, confidentiality and governance. TEEs can be helpful in addressing each one. We are working with ledger partners who want to use Coco to address some but not all of the concerns - for example they want fine-grained confidentiality, but they don't want to rely on the TEE for consensus. In this example Coco can be used with Proof of Work.
In the technical whitepaper, one of the things we discuss is that the "Ledger Model" (data structures, APIs, abstractions and programming model) are owned by the ledger, not by Coco. I think you are right that using TEEs opens up the alternatives to some of the data structures and abstractions in use in the public networks today. We look forward to seeing what people will do with Coco in this regard.
The Coco team shares Richard's view that the distinguishing factor is where the trust boundary exists within the system. In the case of Coco, we assume a lack of trust among consortium participants, but we leverage the attestation and anti-tampering features of Trusted Execution Environments (TEEs) to establish trust between the enclaves: assuming that the TEEs themelves are trustworthy, the TEEs can provide cryptographic proof of the software and configuration running on each enclave. In other words, I don't trust you, but my enclave has decided it can trust your enclave based on mutual attestation exchange and mutual authentication. In other words, we've transitioned from a byzantine failure mode (adversary can replace the expected remote code with arbitrary code at will) to a crash failure mode (adversary can shut the remote enclave down at will, but not alter what runs on it).
Once there is trust between enclaves, Proof of Work seemed inefficient as a consensus mechanism, although it's certainly one choice that is available and that can be used with Coco (in this case Coco would provide governance and confidentiality, but scalability and latency would be limited by PoW). Instead we can use any one of many distributed systems techniques such as Paxos or Raft to achieve consensus.
This is an amazing development for enterprise as it removes the major risk of being cheated after the fact. This is largely why it's so difficult to establish trust between enterprises and had lead to this situation where the best trust is authoritarian centralization.
If we can lose this barrier to establish trust from a human one to a code audit that would be and outstanding achievement for our civilization.
The feedback from customers of CCF had been that building apps was easy but managing the infrastructure and framework was not. This preview provides a fully-managed CCF deployment where Azure handles all infra and framework tasks so that developers can focus on their apps, without any change in the trust model.