[solatic]

Trying to parse through the buzzwords, it sounds like it's trying to replace the need for a traditional database for ledger applications.

Let's say you're a traditional enterprise and you have a ton of geographically dispersed operations. Retail has shops open in malls across the country, logistics has warehouses across the country, and so on. Each one of these places has a local ledger - how much product is on the shelves, what came in, what went out the door. Many times, the ledgers are related - what leaves a warehouse should arrive at retail, and not drop off the face of the Earth.

Traditionally, you had a centralized database to manage all of this, from which reports could be drawn and sent to management. The problem with having a centralized database, however, is that it's a single point of failure. The database can suffer a loss of availability, etc.

If you replace it with a blockchain, then you can get rid of the database and allow all of your geographically dispersed operations to manage the ledger in a peer-to-peer manner, without the security problems that used to dismiss p2p solutions for enterprise, because the blockchain ensures the security of the ledger. Blockchain contracts can allow, say, a retail outpost to contract with a warehouse outpost to receive a shipment, even without connectivity to central management, and then central management can track the activity after-the-fact when it updates.

The real question that enterprise blockchains have to answer is, "is it really worth it to dump a system that works most of the time for a benefit I rarely if ever need that'll cost the enterprise a small fortune to develop, or are we picking blockchains because they're fad of the month and people love resume-driven-development?"

[stefano]

Is that any better than a distributed/replicated traditional database?

[MatthewKernerMS]

Richard Gendal Brown has a great post on the difference between a distributed database and a distributed ledger: https://gendal.me/2016/11/08/on-distributed-databases-and-di...

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.

[ghthor]

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.

[runeks]

Is there even a difference between a traditional distributed database and a blockchain once you remove proof-of-work? Without proof-of-work, the Bitcoin P2P network would just be a distributed database storing a linked list of blocks (each block pointing to the hash of a previous block), plus some business logic.

[solatic]

And on top of that, it sounds like Microsoft ditched most/all of the proof-of-work, because the nodes are trusted and the proof-of-work increased transaction times. So it sounds like whether Coco is actually a blockchain or a distributed database which has been branded as a blockchain because blockchains are FotM, is debatable.

[MatthewKernerMS]

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.

[champbronc2]

In the demo video they explicitly say Coco is not a blockchain.

[acdha]

The part of a block depending on the hashes of its ancestors seems very useful for tamper-evidence, which is useful in many applications if you can handle the data model & volume. Being able to definitively say who changed what and when is worth a lot if you have to maintain data which could be used in court and a distributed ledger, Merkle tree, etc. is more predictable and much cheaper to run if you don't have to maintain mining-level infrastructure.