4 ms·

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

by jbob2000 9y ago

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

randomerr 9y ago
You need someone to at least partially direct traffic. Someone is still putting out new BitCoins.
riskable 9y ago
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 9y ago
  > 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 9y ago
    I can imagine something like carbon credits working well with this. What else?
- MatthewKernerMS 9y ago
  The technical whitepaper clarifies some of these points. To summarize, Coco networks are permissioned. Every authorized member can run a node, and all nodes see all data on the ledger. The code running inside of TEE-protected enclaves on each node determines what subset of the ledger data to expose to each caller, based on the permissions they are granted. Coco enforces basic network-level authentication, but the ledger and the smart contracts on the ledger enforce all of the app-level authN/Z.
DennisP 9y ago
It's useful when there's a consortium of companies who want to agree on some flow of transactions, but don't want to trust or pay any one company to maintain an authoritative database. (This assumes the public chain is unsuitable for scalability or confidentiality reasons.)
basch 9y ago
from the article you are replying to >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.

randomerr 9y ago

You need someone to at least partially direct traffic. Someone is still putting out new BitCoins.

riskable 9y ago

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 9y ago
> 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 9y ago
  I can imagine something like carbon credits working well with this. What else?
MatthewKernerMS 9y ago
The technical whitepaper clarifies some of these points. To summarize, Coco networks are permissioned. Every authorized member can run a node, and all nodes see all data on the ledger. The code running inside of TEE-protected enclaves on each node determines what subset of the ledger data to expose to each caller, based on the permissions they are granted. Coco enforces basic network-level authentication, but the ledger and the smart contracts on the ledger enforce all of the app-level authN/Z.

DennisP 9y ago

It's useful when there's a consortium of companies who want to agree on some flow of transactions, but don't want to trust or pay any one company to maintain an authoritative database. (This assumes the public chain is unsuitable for scalability or confidentiality reasons.)

basch 9y ago

from the article you are replying to >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.