6 ms·

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

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 9y ago
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.
- mtgx 9y ago
  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_you_look_at_the_detail/ https://www.theregister.co.uk/2016/02/01/sgx_secure_until_yo... [2] - https://www.corda.net/2017/06/corda-sgx-privacy-update/ https://www.corda.net/2017/06/corda-sgx-privacy-update/ [3] - https://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf https://invisiblethingslab.com/resources/bh09dc/Attacking%20...
- MatthewKernerMS 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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).
    - MatthewKernerMS 9y ago
      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.
- imtringued 9y ago
  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.
  - MatthewKernerMS 9y ago
    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.
ecesena 9y ago
Think you have a lib of smart contracts like you have a lib of java code. 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.
MatthewKernerMS 9y ago
I work in Azure, and my team builds the Coco Framework. There is more information on the details in the technical whitepaper here: https://aka.ms/cocopaper https://aka.ms/cocopaper 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.
- dbcooper 9y ago
  Can metadata be extracted from the ledger to gain business intelligence on competitors?
  - MatthewKernerMS 9y ago
    Coco enables the ledger to mask all data, including metadata precisely to prevent the leakage you ask about. When a ledger integrates with Coco it decides what capabilities to take advantage of - and how much data to expose to the public, to permissioned participants, to counterparties or to any other role. Similarly, when someone writes a smart contract on top of a ledger, they can take advantage of the confidentiality features to decide what to expose to their callers based on the role of the caller. We are aiming to enable a decentralized system that behaves the way that enterprises expect the data layer should behave - to only expose data to authorized callers. The cool thing about it being decentralized is that you don't have to trust/pay any one party to run it, and your authorized callers can include many counterparties within a market.

PretzelPirate 9y ago

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.

mtgx 9y ago
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_you_look_at_the_detail/ https://www.theregister.co.uk/2016/02/01/sgx_secure_until_yo... [2] - https://www.corda.net/2017/06/corda-sgx-privacy-update/ https://www.corda.net/2017/06/corda-sgx-privacy-update/ [3] - https://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf https://invisiblethingslab.com/resources/bh09dc/Attacking%20...
MatthewKernerMS 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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).
  - MatthewKernerMS 9y ago
    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.
imtringued 9y ago
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.
- MatthewKernerMS 9y ago
  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.

ecesena 9y ago

Think you have a lib of smart contracts like you have a lib of java code. 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.

MatthewKernerMS 9y ago

I work in Azure, and my team builds the Coco Framework. There is more information on the details in the technical whitepaper here: https://aka.ms/cocopaper https://aka.ms/cocopaper 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.

dbcooper 9y ago
Can metadata be extracted from the ledger to gain business intelligence on competitors?
- MatthewKernerMS 9y ago
  Coco enables the ledger to mask all data, including metadata precisely to prevent the leakage you ask about. When a ledger integrates with Coco it decides what capabilities to take advantage of - and how much data to expose to the public, to permissioned participants, to counterparties or to any other role. Similarly, when someone writes a smart contract on top of a ledger, they can take advantage of the confidentiality features to decide what to expose to their callers based on the role of the caller. We are aiming to enable a decentralized system that behaves the way that enterprises expect the data layer should behave - to only expose data to authorized callers. The cool thing about it being decentralized is that you don't have to trust/pay any one party to run it, and your authorized callers can include many counterparties within a market.