MatthewKernerMS

Thanks very much for the product feedback. I've routed the points of feedback to the teams who own the components involved to take a look.

As above, I've shared these points as well with teams who own these areas. Thanks again!

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.

Coco doesn't use any underlying network - it forms the bottom-most layer of a permissioned blockchain network. When a ledger (could be any ledger, Ethereum as in the demo or otherwise) is integrated on top of it, the ledger decides whether to expose metadata or not, and to whom.

Maybe I misunderstand your question?

There are three layers at work in the confidentiality demo.

Coco is at the bottom of the stack. Coco handles replication of data across a network of TEE-enabled nodes, ensuring confidentiality and integrity of the data. The data is only in the clear inside each enclave. Coco enforces network-level authentication, restricting connections to actors authorized by the network constitution. At this level there are no smart contracts.

In the middle of the stack is the ledger. In the demo that is Ethereum ported to run on Coco. We disabled a few Ethereum APIs so that transactions and smart contract state cannot be read directly. We also added access control to APIs that expose events.

At the top of the stack sit smart contracts that are hosted on the ledger. Here the DApp developer can add public read methods to expose any data that they want to expose, and they can implement access control within these smart contracts to restrict access to appropriate counterparties. This can be based on RBAC with arbitrarily fine-grained rules.

In the case of bitcoin, some design would be required. Today, the scripting language is used to decide whether to unlock UTXOs at the time that they are consumed as inputs to a new transaction. If bitcoin were integrated with Coco, there would have to be some modifications made to apply access control somewhere. This could be done in the ledger code. For example, it could only allow read access to a given transaction by the counterparties (it is not obvious how the counterparties would be identified, but in the P2PKH case perhaps the caller could sign the request with the private key corresponding to the public key hash of either an input or an output). Or the bitcoin ledger could be augmented by allowing the creation of scripts to govern access. They would need to be accommodated in the transaction format and stored along with the ledger. This would be a bigger change obviously.

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 were talking about this yesterday. We should call them Cokens :)

Caesar consensus, which is referenced in the Coco technical whitepaper, seeks to address the problem you mention.

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.

Many use cases we encounter in customer discussions can best be solved by using traditional databases which benefit from academic and industry investment over more than 50 years. Databases offer more mature algorithms, implementations, toolsets, talent pools and ecosystems.

That said, there are some compelling scenarios that customers are exploring where a decentralized model opens up new market opportunities, or reduces risk or reduces cost.

One challenge with a database is answering the question of who operates it, and whether that party could choose or could be compelled to act maliciously. Coco and its ilk are specifically designed to address that concern, with tradeoffs in other dimensions as mentioned above.

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.

Coco enables the ledger to mask all data, including metadata precisely to prevent the leakage you ask about. When a ledger integrates with Coco it decides what capabilities to take advantage of - and how much data to expose to the public, to permissioned participants, to counterparties or to any other role. Similarly, when someone writes a smart contract on top of a ledger, they can take advantage of the confidentiality features to decide what to expose to their callers based on the role of the caller.

We are aiming to enable a decentralized system that behaves the way that enterprises expect the data layer should behave - to only expose data to authorized callers. The cool thing about it being decentralized is that you don't have to trust/pay any one party to run it, and your authorized callers can include many counterparties within a market.