Coco: Framework for enterprise blockchain networks

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.

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.

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.

Another example would be trades: Most people think of trades as buying stocks and bonds in an open market but there's a lot of private/internal-to-an-organization markets too. The blockchain is an excellent way to facilitate such transactions.

Being in banking (where we're trying to take advantage of blockchain transactions) the objections from management so far have been surrounding the inability to "undo" a transaction. Even though you can just make the same transaction in reverse afterwards the price of whatever it was that you're trading could've changed resulting in some troublesome circumstances.

For it to work you have to negotiate contracts ahead of time to ensure that all parties participating understand the ramifications of such a system. Since the blockchain is new technology it will be difficult to get 3rd parties to sign of on such things.

So say you've got central logging setup at your organization. You're smart and are using rsyslog with SSL/TLS and your own CA. For the most part you can reasonably claim that your log messages are secure from the server that emitted them to the destination in your central logging system but can you guarantee they're not modified after that? No. You can't.

From this perspective using a blockchain for logging security-critical events would be extremely useful. It would be impossible for an attacker to modify the logs after-the-fact so that you could no longer determine which account they used to login.

You wouldn't want to use it for general logging because of the overhead but for things like login events, reboots, etc it would be fantastic.

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?"

It just happens that ledger is a quite good fit for document timestamping, and account balance can be used as a way to transfer money-like values (note that it's not the only way; cryptographers have a history of developing digital money systems).

About the only thing new about blockchain is that it doesn't need a trusted third party (system with rights and means to modify the data) to timestamp documents to defend against adversarial modifications to the timestamps stream.

Anyway, anything that would use ordering of documents/messages could be built on top of blockchain, but calculating proof-of-work is a very steep price to pay for the defense against some of the participating servers being malicious, given that enterprises happily trust regular databases that don't sign cryptographically anything.

On the other hand such a system might make the individual votes less anonymous ...

Edit: campaigns and any other interested party such as the press

In practice, I have yet to see anything concrete, but I haven't exactly been looking hard.

Identity/reputation: If you have a certain reputation on eBay, you can't carry that reputation over to Amazon to sell goods. You must start from scratch. If the reputation score was independent of the service you could even post it on Craigslist and people could trust it.

Real estate: I paid a lot of money for a completely useless title insurance. If the details of a home title were stored on a blockchain, there would be no need for this entire industry of bloodsucking leeches. :)

Supply chain: there's an ad-hoc network of suppliers for many things (cars, planes, electronic doodads). There is no central authority, and it spans the globe. Having perfect knowledge of the supply chain can save companies lots of money. It's what made Walmart successful, now everyone can do it on a shared platform.

The tech for this stuff is still very primitive. I'd compare it to when Jaron Lanier started virtual reality in the late '80s. He was right but several decades too early. There are still some limited contexts where a current blockchain can be useful right now, but it won't be a big thing for a while.

Actually most value will go to enterprise architects who can hire their friends as consultants.

What this framework appears to do is enable your endpoints to participate in a one-way fashion. So they will get just enough information to facilitate a transaction but nothing beyond that.

It seems like a bit of cloak & dagger tomfoolery where the blockchain is just being implemented behind-the-scenes on a specified collection of servers but I haven't looked very deep yet. I can see the benefit to Microsoft from having a setup like that--they can allow customers to participate in a blockchain-utilizing system without giving them full access to the blockchain but to me that seems like defeating the purpose and unnecessarily trusting a 3rd party to handle all your transactions with no independent way of verifying said transactions.

In other words, it's no different than just standard server-client architecture except instead of handling transactions through a database (the traditional way) they utilize a blockchain in the background. When you want to verify a transaction you're really just making a request to their central server and asking it to do the job for you--and trusting whatever it tells you.

Not exactly a proper blockchain if you ask me.

(This assumes the public chain is unsuitable for scalability or confidentiality reasons.)

>This is because existing systems were designed to function—and to achieve consensus—in public scenarios amongst anonymous, untrusted actors with maximum transparency. Because of this, transactions are posted “in the clear” for all to see, every node in the network executes every transaction, and computationally intensive consensus algorithms must be employed. These safeguards, while necessary to ensure the integrity of public blockchain networks, require tradeoffs in terms of key enterprise requirements such as scalability and confidentiality.

..

>Coco achieves this by designing specifically for confidential consortiums, where nodes and actors are explicitly declared and controlled. Based on these requirements, Coco presents an alternative approach to ledger construction, giving enterprises the scalability, distributed governance and enhanced confidentiality they need without sacrificing the inherent security and immutability they expect.