I work in Azure, and my team builds the Coco Framework. There is more information on the details in the technical whitepaper here: https://aka.ms/cocopaper

Coco is designed for permissioned networks (as opposed to public networks). The network constitution in Coco contains a list, arrived at by a vote of consortium members, of all of the actors permitted to interact with the network. Coco implements network-level authentication to restrict access to participants. The constitution state is stored within the state replicated by the Coco Framework, so it is stored on all of the nodes in the network.

Beyond network-level authentication, there is also ledger and DApp level authentication. The supply chain demo demonstrates this capability. For the demo, we modified Ethereum to integrate it with the Coco prototype. We removed the capability to read raw transactions or to access raw smart contract state directly. Instead, the DApp must implement public smart contract methods enabling reads to state that the developer wants to expose. Those read methods contain code (in this case implemented in Solidity, executed by the EVM) that is responsible for authentication and authorization of callers. This enables the DApp developer to decide for themselves now to authenticate the caller, and what roles and privileges apply to the DApp's data. We also did some work to restrict access to events to only authorized callers - you can read more in the whitepaper on this.

We believe there's an opportunity for common patterns here (a la the ERC20 token standard), but these patterns can vary by ledger and by DApp. All of that is above the Coco layer. This is why the ledger (in this example Ethereum) matters. The ledger exposes capabilities that either natively, or through smart contracts, secure the data in the ledger. Coco's job is to ensure that ledger data is only ever in the clear inside the TEE, where the ledger and smart contract code can implement a confidentiality model appropriate for the use case.

First of all, I haven't read the whitepaper yet, forgive me

But if I understand what you're saying correctly, Coco develops a smart contract that implements some sort of authentication method such that it cannot be publically read on the Ethereum blockchain?

And that the ability for Coco framework to implement those permissions depends upon the ledgers capability? So for example, Bitcoin's scripting language wouldn't be sophisticated enough to support authentication via Coco? (amongst numerous other functions of course)

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.

Can metadata be extracted from the ledger to gain business intelligence on competitors?

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.

Thanks for the reply!

Just to clarify, is it possible to extract any metadata from the underlying Ether network (if that is being used)?

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?

No, thank you for the explanation. I had a fever yesterday and had details backwards.

I think the idea is that, since the blockchain nodes are running in a TEE, that any participant in the network can get an attestation to be sure that no one has tampered with the rules of the network. You don't need to personally validate each transaction as long as you are sure that the network is running the correct code.

It seems that permissions are set in each contract with identities tied to Azure AD members. I might be wrong about that. The white paper is pretty long and I only had time to skim it.

TEE is a joke. I don't even trust the newer SGX [1], which some blockchain companies like Corda [2] are adopting now, let alone TEE, with its myriad of security issues [3].

[1] - https://www.theregister.co.uk/2016/02/01/sgx_secure_until_yo...

[2] - https://www.corda.net/2017/06/corda-sgx-privacy-update/

[3] - https://invisiblethingslab.com/resources/bh09dc/Attacking%20...

You captured the basic idea of the TEEs well. One way of thinking about this is that proof of work and proof of stake consensus protocols establish trust on a per-block basis. By leveraging TEEs, we have hoisted that trust establishment out of the per-block workflow and instead have the option to pay the cost once, at the time the network is established. One tradeoff of this design is that a TEE compromise would have major impact on the ledger. The whitepaper (https://aka.ms/cocopaper) contains a section on mitigating TEE compromise. Additionally, our intent is to support multiple consensus models, including models that require per-block trust validation. Ledgers and consortiums are free to make choices about what they want to support depending on their threat model and the assets being protected - with the ability to trade off scalability and latency against security as they see fit. What we demo'ed is one design that we think is interesting for many use cases we've heard about from customers.

Permissions are not tied to AAD members per se - we rely on a set of X.509 certs that correspond to the identities of the actors on the network for network-level authentication. These certs are referenced in the network constitution.

Ledger- and app-level authentication can be done however developers would like to do it. It can be, but need not be, AAD. See my comment above or the whitepaper for more details on the confidentiality design.

This is nothing that cannot be achieved by a write locked DB, with verification via inputs from smart contracts. You are basically using the security of these massive P2P networks to shore up a consultancy model.

Yeah, exactly. These permissioned blockchain implementations rely upon some centralised source of trust (eg the government, network permissions, etc.) and I don't see exactly what distinguishes them from a distributed ledger. The core innovation and the whole point of blockchains is that they are permissionless and trustless. Or am I missing something here?

Yes, the core innovation in public blockchains, the double spend problem in trusless networks, is not present in private blockchains and private blockchains can he simplified with basic block that have existed for decades.

The biggest and critical issue with private blockchains is at the political level: how to make a lot of parties (e.g. bank) agree in a protocol involving critical things (e.g. money).

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.

I don't get it. Blockchains solve the consensus problem. If you use a TEE for consensus then you have no consesus problem and don't need a blockchain. You can basically choose any type of datastructure at that point.

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.

Think you have a lib of smart contracts like you have a lib of java code.

Part of your code is used internally and you have an authz server (typically not the one that runs the java code, in MS world it's active directory).

Think that you have dockerized your java servers. It's not that you don't trust your employee laptops for development, it's just that you want to reduce the differences between dev and prod.

Same for blockchains, you want a lib of contracts, you want authz, you want to reduce the diff between public and private.