
Coco: Framework for enterprise blockchain networks - mbgaxyz
https://azure.microsoft.com/en-us/blog/announcing-microsoft-s-coco-framework-for-enterprise-blockchain-networks/
======
Gormisdomai
Watching the demo video [1] has me a little confused.

He makes it sound like all your interaction with Ethereum goes through the
Coco framework (so permissions are implemented by Coco deciding which
contracts you're allowed to see). Is that right?

If so what's the point of using Ethereum at all?

\- Who is doing the computation for a smart contract if it's private and only
you can see it?

\- Is the permissioning managed by a trusted Coco server somewhere? If so, why
not also trust that server with storing the information about your supply
chain?

[1] [http://aka.ms/cocodemo](http://aka.ms/cocodemo)

~~~
PretzelPirate
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.

~~~
MatthewKernerMS
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](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.

~~~
harwoodleon
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.

~~~
cgh
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?

~~~
wslh
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).

------
sboselli
I wonder what are the best use cases for an enterprise blockchain? EDIT: Great
suggestions. How about some non-banking applications?

~~~
riskable
I know I already replied but I forgot to mention another great usage of a
blockchain: Logging. Not general-purpose logging, no. I'm talking about SOX-
like "must be tamper-proof" transaction logging.

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.

~~~
pasxizeis
I'm curious, has this ever been a problem in real life?

~~~
corysama
Googling for enterprise blockchain scenarios, I find
[https://www.hyperledger.org/projects/sawtooth/seafood-
case-s...](https://www.hyperledger.org/projects/sawtooth/seafood-case-study) I
guess in this case the goal is to ensure customers trust in the enterprise
beyond just reputation. These records are currently being stored in
traditional databases and the customers trust that the records aren't being
tampered with out of the expectation of consequences if the enterprise was
caught cheating. But, with a blockchain record, cheating becomes
extraordinarily harder. The customers do not need to trust. They can verify.

~~~
stefano
Do the customers have to run their own mining network to ensure the producer
can't pull a 51% attack?

~~~
lurker456
While a 51% attack is a real concern, an even more likely scenario is the
network going down. During a network split the local node(s) will happily
continue to ingest logs which once the network is healed will all be rejected.

------
jbob2000
I don't understand 'enterprise blockchain'. Doesn't a blockchain depend on
thousands of computers, each independently verifying the data? How does this
hold if the blockchain is just running on 1 server (or a few, but that's not
the point)? Then it's just a server, not a block chain...

~~~
riskable
You're right: It's not practical to run a blockchain on a single server or
even just a collection of servers. For it to work properly it needs to be
constructed as a P2P system. So each system that wants to use the blockchain
has to participate in its construction.

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.

~~~
floatrock
> 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

The key is who is running that "specified collection of servers". If they're
all yours, then yeah, there's no advantage to just running your own sql-ish
cluster.

However, what if now your p2p miner pool includes a few machines run by your
regulator? Yes, your business logic endpoint nodes are participating in a one-
way fashion, but their transactions are now being automatically logged by the
regulator (regulator doesn't need to know what the underlying business logic
is, just that the reportable transaction results are being logged in the
blockchain they're part of). Something like a third of financial firms'
business is around reporting requirements.

Or consider a large supply chain... again the miners aren't just one company,
it's everyone in the supply web or the consortium. Allows for coordination
without necessarily being open to the public.

~~~
whytaka
I can imagine something like carbon credits working well with this. What else?

------
gwbas1c
"My framework runs on anything and works with anything..." should translate
to, "it's very fragile and only works with what we tested it with."

------
randomerr
I was hoping it would be a new Tandy Color Computer. I guess the news on the
new Amiga clone got my hopes up.

------
ksteigerwald
Wheres the ICO!

~~~
MatthewKernerMS
We were talking about this yesterday. We should call them Cokens :)

------
jrs95
Really? Couldn't come up with a name that wasn't effectively already in use?

~~~
2_listerine_pls
It's Microsoft, their names are supposed to be confusing.

~~~
greggyb
Their parallelized data warehousing solution: Azure Data Warehouse.

Their document store database: Azure DocumentDB.

Their large scale structured+unstructured data storage and analysis
(frequently referred to as a data lake): Azure Data Lake Storage... AND Azure
Data Lake Analytics. Let's talk about the precise differences and co-
dependencies between these two.

Their offering to expose functions as an API: Azure Functions.

Their RDBMS, a product that runs as a server and is queried with the language,
SQL (what might, in another world, be called a SQL server): SQL Server.

Their cloud version of the same: Azure SQL DB.

Their only well named product, you ask? Their cloud platform named Azure,
which is the color of a blue sky. Well played, Microsoft.

tl;dr I agree with you.

~~~
statictype
All those names are actually pretty clear and not confusing at all.

Boring and uninspired - yes - but certainly not confusing.

No different from MapKit and WebKit and ARKit and HomeKit and HealthKit

~~~
greggyb
ADLS and ADLA do definitely inspire confusion, but your point is well-taken.

------
aerovistae
Are we running out of words, or combinations of letters that are
pronounceable? I swear to god this is like the third time I've seen someone
release a new framework that had the same name as a different, already popular
framework.

Sure, Apple's API is called Cocoa, but verbally is there really any
difference?

------
victor106
MSFT needs a name doctor

------
johnnyringohP
Because removing an A makes it a completely different framework from Cocoa
Framework...

~~~
kin
I was just going to say, verbally Coco = Cocoa. Not that it matters all too
much since they're in different spaces, but they could have come up with a
different name, especially when you don't even have to use a real word.

------
custos
Because removing an A makes it a completely different framework from Cocoa
Framework...

~~~
mtgx
It's not a clon.

~~~
michaelcullina
Nice. They could have named it "Chanel" and by the fifth version it would
smell great.

------
smaili
Is this Microsoft's subtle way of saying they do not ackknowledge iOS's Cocoa
and Cocos2d frameworks? Or were they hoping dropping the 'a' wouldn't cause
for confusion/overlap.

~~~
pyroinferno
Was Apple naming their mobile OS iOS a diss towards Cisco?

~~~
captn3m0
They got a license from Cisco:
[https://blogs.cisco.com/news/cisco_and_apple_agreement_on_io...](https://blogs.cisco.com/news/cisco_and_apple_agreement_on_ios_trademark)

------
m0sa
Coco? Jamboo! [https://www.youtube.com/watch?v=m_-
Qtz70_z4](https://www.youtube.com/watch?v=m_-Qtz70_z4)

