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.