Coco Framework Whitepaper
.
Contents
Executive Summary................................................................................................ 1
Facilitating Enterprise Blockchain Adoption............................................................. 2
The Coco Framework............................................................................................. 4
Actors and Identity................................................................................................ 8
Network Creation and Governance....................................................................... 10
Transaction Workflow.......................................................................................... 14
Confidentiality and Integrity................................................................................. 18
Mitigating Compromise........................................................................................ 21
Functional Prototype and Demos.......................................................................... 22
Conclusion........................................................................................................... 24
Executive Summary
Over the last few years, enterprises have come to realize how blockchain, the technology that powers public networks such as Bitcoin and Ethereum, can be used to streamline their own business processes. However, they have also found that most existing blockchain protocols fail to meet several key enterprise requirements—including acceptable transaction throughput and latency, confidentiality, effective governance, and computational efficiency (i.e., the energy cost for mining/proof of work). Efforts to adapt existing public blockchain protocols or to create new protocols to meet these needs have generally traded one required enterprise attribute for another—such as improved confidentiality at the cost of greater complexity or lower performance.
The Coco Framework is an open-source system that enables high-scale, confidential blockchain networks that meet all key enterprise requirements—providing a means to accelerate production enterprise adoption of blockchain technology. Coco achieves this by re-evaluating existing assumptions for public blockchain protocols in the context of a confidential consortium, where nodes and actors (including voting members and other non-voting participants) are explicitly declared and controlled. Based on this new set of requirements, Coco brings together the power of existing blockchain protocols, trusted execution environments, distributed systems, and cryptography to enable enterprise-ready blockchain networks that deliver:
Throughput and latency approaching database speeds.
Richer, more flexible, business-specific confidentiality models. • Network policy management through distributed governance.
Support for non-deterministic transactions.
Reduced energy consumption.
It is important to note that Coco is not a standalone blockchain protocol; rather, it provides a trusted foundation with which existing blockchain protocols such as Ethereum, Quorum, Corda, or Hyperledger Sawtooth[1] can be integrated to deliver complete, enterprise-ready ledger solutions. Coco is designed to be open and compatible with any blockchain protocol.
This paper reexamines the requirements for a blockchain network in the context of a confidential consortium. It then introduces the Coco Framework, including network topology and system architecture, network creation and governance, transaction flow, and architectural variations. It also examines how scalability, confidentiality, and distributed governance are achieved, along with security considerations and how security risk can be mitigated. Finally, it discusses the current working implementation of Coco, including initial performance findings.
Facilitating Enterprise Blockchain Adoption
Blockchain technology is poised to become the next transformational computing paradigm. It promises to disrupt existing business processes, to reduce the friction of doing business, and to unlock new business models—especially shared processes across organizations. According to Gartner, “the business value-add of blockchain will grow to slightly more than $176 billion by 2025, and then it will exceed $3.1 trillion by 2030.”[2] Given such benefits, in our rapidly evolving digital economy, it won’t be long before blockchain technology is a key foundation for distributed enterprise and consumer applications.
Framing the Problem
Blockchain technology is already generating strong interest among enterprises across almost every industry. However, as enterprises look to apply blockchain technology to meet their business needs, they have come to realize that most existing blockchain protocols fail to meet key enterprise requirements in areas such as performance, confidentiality, governance, and required processing power. This is because they were designed to function—and to achieve consensus—in a potentially hostile environment, where anonymous, untrusted actors can execute transactions or propose block commits. As such, to prevent malicious behavior, transactions are “in the clear” for all to see, every node in the network executes every transaction, and Byzantine fault tolerant consensus algorithms must be employed. All of 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.
For instance, the public Ethereum network has an average processing rate of 20 transactions per second, with a typical transaction latency of around 10-20 seconds.[3] By contrast, the Visa credit card processing system averages 2000 transactions per second.[4] In addition, all Ethereum transactions, smart contract code, and state are in the clear—visible to anyone who joins the network.
Processing power required for public blockchain networks—and associated energy costs—are also prohibitive to enterprise scenarios. According to Digiconomist[5], the annual energy consumption of the Bitcoin network is equal to 14.96 terawatt-hours (TWh), with estimated annualized mining (transaction processing) costs of more than US$747 million. Put another way, the Bitcoin network consumes enough energy to power more than 1.3 million U.S. households.
There have been efforts to adapt public blockchain network protocols or to create new protocols to meet the needs of the enterprise. However, so far, these approaches have not met all enterprise requirements; most have required undesirable tradeoffs in terms of complexity or performance. For example, while approaches exist that leverage zero-knowledge proofs 6 or other advanced cryptography to hide transaction details, they are complex and require computational space and time tradeoffs making them unsuitable for high-volume applications, or they rely on a trusted source to bootstrap crypto material.
Other schemes introduce rigidity because confidential channels require “commitments” of tokenized resources, making them inaccessible outside the channel while the channel is active.
A Consortium-First Approach
Adapting existing, public blockchain technology to the needs of the enterprise (or, more accurately, to a consortium of enterprises) begins with re-examining the environment in which the blockchain must operate. In a public blockchain network, anyone can transact on the network, actors on the network are pseudo-anonymous and untrusted, and anyone can add nodes to the network—with full access to the ledger and with the ability to participate in consensus.
In contrast, in a consortium blockchain network, member identities and nodes are known and controlled. Actors are often equally mature, with robust and highly controlled IT environments, security policies, and other enterprise characteristics.
So how can we take advantage of these differences to meet the needs of the enterprise? Fundamentally, the trust relationship between the actors in a consortium need not be changed. However, if we can create a trusted network of physical nodes without requiring the actors that control those nodes to trust one another, we can control what code is run and guarantee the correctness of its output—thereby simplifying consensus and reducing duplicative validation. This is the approach that Microsoft has taken in developing the Coco Framework, which is described in the remainder of this paper.
The Coco Framework
The Coco Framework is an open-source system that enables high-scale, confidential blockchain networks. It meets all key enterprise requirements, providing a means to accelerate production adoption of blockchain technology. Coco achieves this through the use of trusted execution environments (TEEs) such as Intel’s SGX and Windows Virtual Secure Mode (VSM), enabling the creation of a trusted network of physical nodes on which to run a distributed ledger.
With Coco, enterprises can benefit from:
Throughput and latency approaching database speeds. Through its use of TEEs, Coco creates a network of trusted nodes that reduces the problem from Byzantine fault tolerance to crash fault tolerance. This simplifies consensus and thus improves transaction speed and latency—all without compromising security or assuming trust.
Richer, more flexible confidentiality models. Coco uses industry standard authorization and authentication to safeguard data access. Transactions, smart contract code, and smart contract state can be processed in the clear yet revealed only to authorized parties, without requiring complicated confidentiality schemes.
Network policy management through distributed governance. Coco provides a network constitution to express and manage consortium policies. Expression of network policies can be codified, and policies can be managed through standard ledger-like transactions.
Non-deterministic transactions. With Coco, because the results of code execution can be trusted, smart contract code need only be executed by a single node in the network. When the network is configured in this manner, transactions can have non-deterministic results (e.g. by incorporating randomness in calculations) and can even interact directly with trusted external systems.
Reduced energy usage. Coco improves energy consumption by eliminating computationally intensive consensus algorithms, such as proof of work.
Conceptual Overview
It is important to note that Coco is not a standalone blockchain protocol; rather, as illustrated in Figure 1, it provides a trusted foundation that delivers efficient consensus algorithms and flexible confidentiality schemes—a framework with which existing blockchain protocols such as Ethereum, Quorum, Corda, or Hyperledger Sawtooth can be integrated to deliver complete, enterprise-ready ledger solutions.
Coco was designed to provide secure, reliable base components that any blockchain protocol can use. Figure 2 illustrates the separation/overlap between Coco and a blockchain protocol, with the Coco components shaded in green. At its core, Coco:
Implements a consistent, distributed, persistent store (such as a key-value store) that is replicated across TEEs—containing both the application (business transaction) ledger and the Coco administrative ledger used for network policy management. While there are logically two ledgers, both are recorded within a single store to maintain relative ordering across all transactions in the network.
Provides secure node-to-node and application-to-node communication.
Enables arbitrary confidentiality models with easy-to-use primitives.
Provides a codified governance model to support arbitrary, distributed policy management.
Coco relies on the specific blockchain protocol for the distributed ledger model, as well as core transaction and smart contract code processing.
High-Level Architecture
A Coco system is a distributed network of trusted validating nodes (VNs), each of which run the Coco Framework and the integrated blockchain protocol. VNs accept transactions and participate in the network’s consensus algorithm. Depending on the chosen consensus algorithm, one or some VNs process transactions and execute smart contract code.
Loosely, the VNs in a Coco network are similar in function to the mining nodes in a public blockchain network—though the acts of “mining” and communication in a Coco network are very different. Unlike public blockchain networks, each VN in a Coco network is fully trusted because VNs can verify the identity of all other VNs and validate the code they run through TEE attestation at runtime.
As illustrated in Figure 3, a VN can be decomposed into several logical sub-components. These are divided across the host (the potentially untrusted hypervisor and operating system of the node) and the enclave, which is a protected, secure container within the TEE. All sensitive components of the system run inside the enclave and are responsible for maintaining integrity, confidentiality, and security of the ledger.
Coco interface (host) – the host process that implements the transport layer interface to which the client and other VNs connect. This host process also interfaces with the operating system and other external services on behalf of the enclave. (While the host itself is required to maintain availability of the VN and persistence of the data stored in the ledger, it has no responsibility for maintaining integrity, confidentiality, or security of the ledger.)
Coco core (enclave) – the interface between the host and all other functionality within the enclave.
Persistent store (enclave) – the single, globally ordered, on-disk representation of the application ledger and the Coco administrative ledger. (There is an in-memory copy for fast access; durability is achieved via a persistent store.)
Coco configuration state (enclave) – the Coco state machine implementation that supports creation of the network constitution and all subsequent updates.
Blockchain core and adapter (enclave) – the logic to process transactions and execute smart contract code, as well as the glue to integrate the blockchain protocol into the rest of the Coco system.
Actors and Identity
There are two types of actors in a Coco network, members and participants. At a high level:
Members are the governing bodies of a consortium, with collective control over who can transact on the network and its governance—including network membership, the code that runs in the TEEs, and the definition of network policies. Members run VNs and can transact on the network. Members also define the initial configuration and setup of a Coco network and, throughout the lifetime of the network, can propose changes to its configuration and vote on changes proposed by other members. Further, each member receives a share of the network’s shared network key (described later), which allows a quorum of members to collaboratively restore the network in the event of a catastrophic failure. In a consortium of banks, members could be large, global, systemically important financial institutions (GSIFIs).
Participants, unlike members, cannot vote and thus have no operational control over who can directly access the network or its governance. Participants are determined by the network’s members and, like members, participants can transact on the network. They also can, and likely do, run their own VNs. In a consortium of banks, participants could be a group of domestic systemically important banks (D-SIBs) that transact between themselves and the GSIFIs.
It’s worth noting that, depending on the purpose and policies of the consortium, a Coco network doesn’t necessarily need to have both types of actors. For example, a consortium may decide that all parties within it should be members, with equal responsibilities and permissions. Similarly, each actor could have both member and participant identities, as a means of separating business and administrative transactions.
Every member and participant has a private/public key pair (PrivKeyMi, PubKeyMi and PrivKeyPi, PubKeyPi, respectively) and is identified in the Coco network with an organization-wide X.509 certificate. An intermediate certificate can be used to uniquely identify the organization and all users within it, abstracting actor-specific certificate policies and roll-over from the Coco system. Within the organization, to maintain fine-grained control, different departments that are participating in different consortiums (and thus different Coco networks) can have different certificates to minimize cross-network access. This allows for easy integration with existing corporate systems and public-key infrastructures (PKIs).
End users, such as a bank’s customers, do not have an identity in the Coco network and cannot transact on the network directly. Instead, they interact with it through the front-end systems of members or participants.
In a typical scenario, as illustrated in Figure 4, end-users are authenticated and authorized using existing enterprise identity management mechanisms, such as Active Directory (AD) or Azure Active Directory (AAD). The end user submits a transaction to a front-end system. The front-end system then submits the transaction to the Coco network using the member’s or participant’s Coco identity (PrivKeyMi or PrivKeyPi), which is stored in a local or cloud-based key management system, such as a hardware security module (HSM).
Network Creation and Governance
Coco describes and manages network policies through a network constitution (described below) and a process of distributed voting. This allows consortium rules and agreements to be codified in the system, similar to how contracts are codified in smart contract code.
Any member can start a network by bootstrapping the first VN. After that, proposals for changes to the Coco network constitution (such as adding or deleting a member) can be submitted by any member for a vote. Like application transactions, such Coco administrative tasks are submitted as transactions to the Coco network.
Network Constitution
In a Coco network, the network constitution is the complete expression of network policies. At a minimum, these include the membership list, VN list, code manifest, TEE manifest, and voting policies.
The membership list is a list of all approved actors (members and participants) in the network. A member, M1, is represented by its private/public key pair (PrivKeyM1, PubKeyM1). If M1 to Mi are members in the consortium, the member list would be represented by the public key set {PubKeyM1, … PubKeyMi}. Only each member’s public key certificate is uploaded into the Coco network. Each member’s private key remains in the originating key management system, which can be on-premises or in the cloud. Participants are handled in the same way as members.
The Code manifest is the specification of all approved code that can run within the Coco network— including but not limited to Coco Framework versions, blockchain protocols, and specific blockchain protocol versions. Any one code identity is represented as a single measurement.
The TEE manifest is the specification of all approved trusted execution environments—hardware or software. VNs in a Coco network can run different TEEs, provided that all TEEs employed are acceptable per the TEE manifest. In such a mixed TEE environment, network security is only as strong as the weakest TEE mechanism employed.
The VN list is a list of all approved validating nodes in the network. A VN is represented in the Coco network by a signed tuple that includes the member’s identity, the address (either DNS name or IP address) of the physical node, and the public key corresponding to the private key generated within the enclave to uniquely identify the VN/secure enclave pair. For the first VN of the first member, VNM1_1 = {PubKeyM1, address of VNM1_1, PubKeyVN_M1_1}SPrivKey_M1.
Any change to the network constitution, such as additions or removals to the membership or VN lists, must be done through a voting process (described later). The criteria for a vote to be accepted is known as the voting policy, and is also expressed in the network constitution. Options for a voting policy can include unanimous, M of N, one of N, etc. Similarly, policies on whether vote submission can be automated if it meets certain criteria can be expressed. For example, vote submission could be automated so that every member could add a specified number of VNs, provided that the VNs are running majority-endorsed code.
These are the fundamental policies a Coco network implements; we plan to support additional policies over time.
Bringing up the Network
Any member can start a network by bootstrapping the first VN and uploading a genesis network constitution. The member who starts the network has no extra privileges compared to subsequent members who join the network.
Bootstrapping a VN
To bootstrap a VN, a member or participant performs the following steps:
Sets up a server or virtual machine with a TEE and installs a Coco Framework-supported operating system.
Installs the Coco Framework and desired blockchain protocol. The software is installed on the server, which in turn creates an enclave in the TEE to run sensitive Coco and blockchain functionality. The TEE generates an attestation of its hardware/software mechanism and the code running inside the enclave, which the actor uses to verify that all is as expected. A private/public key pair is generated within the enclave and the public key is included as part of the attestation to represent the enclave’s identity.
Uploads the network constitution to the VN.
Establishes a secure communication channel between each front-end application and the VN.
Uploads its private/public key shares, which are used for data integrity and confidentiality (described later).
The above process for bootstrapping a VN is the same whether it is the first VN in the network or a subsequent VN. Subsequent VNs will discover other VNs in network using the VN list and attempt to establish secure node-to-node connections with them. Secure connections are only established with other VNs if they are in the VN list and the TEE for each other VN can provide a valid attestation.
Member, Participant, and Node Management
After the network is up and running, any existing member can propose a vote to add a new member or participant; add a new VN belonging to an existing member or participant; or remove a member, participant, or VN.
Adding a New Member or Participant
Multiple members and/or participants can be defined in the genesis network constitution, in which case they do not need to be added after the network is up and running. New members or participants who are not defined in the genesis network constitution can be added by existing members.
Regardless of whether a new member or participant is being added, the process is the same. Here’s how the process works for a new member:
The new member, MJ, creates a VN using the process described above. To do this, the new member must receive a copy of the current network constitution to use during bootstrap from an existing member. This happens outside of the Coco system today, through whatever secure means the members communicate. (While having a copy of the network constitution does not mean a rogue entity can join the network, the network constitution does contain sensitive information, meaning care should be taken in sharing it with others.)
After the new member’s VN is ready to join the network, an existing member Mi proposes a vote, providing MJ’s identity and MJ’s first VN to admit to the network: {PubKeyMj, VNMj_1}. If the vote is successful, the member, MJ, is added to the membership list and its node (VNMj_1) is added to the VN list.
After the member is admitted to the network, it will receive the current network constitution and blockchain state from another member VN and ensure the constitution matches its own version.
To simplify the above process, on bootstrap (Step 1 above), a new member’s VN can receive the current network constitution from the network itself to avoid passing it outside of the system. In this case, in Step 3, Mj must have a chance to approve the network constitution after the VN is setup, but before the VN downloads data or processes transactions, to avoid the case where Mj does not approve of the constitution at the time of Mj’s admission.
Technically, the addition of an actor (member or participant) and its first VN can be decoupled if the new actor wants to be added to the membership list before its first VN is ready; however, in this case, a second voting proposal must be made through another member’s infrastructure to add the new actor’s first VN to the VN list.
Similarly, if the new actor bootstraps its first VN too early, that VN will be rejected when initiating connections with existing VNs in the network because the new actor’s VN is not yet in the VN list. The lookup and connection attempt will need to be re-initiated after the vote has completed and the new actor’s VN has been added to the VN list.
Adding New VNs for Existing Actors
Similar to adding a new member, a member may propose a vote on the addition of a new VN belonging to an existing actor. The proposal can be made by any actor, not just the one who owns the VN. The voting process is the same, and the new VN cannot join the network until the vote is successful.
Removing Actors or VNs
The process to remove an actor or VN is also similar. The actor or VN is not officially removed from the membership list or VN list until voting is completed and the vote is processed, meaning that the actor or VN will still have access to the network during that time.
Voting
Any member can propose a change to any of the policies specified in the network constitution for a vote, in a manner similar to how members and VNs are added or deleted through voting. Members can also propose values for policies that were not specified in the genesis network constitution, provided that the policy is supported by the Coco system. Similarly, members can propose to remove policies from the network constitution. Updates to the Coco Framework code and blockchain protocol code are also proposed and voted on. Even the voting policy itself can be changed through this process. (A vote to change the voting policy would use the old voting policy; if the vote succeeds, the next vote will use the new voting policy.)
When a proposal for a change to the network constitution is submitted, all existing members are notified and must vote. Each member gets one vote, regardless of the number of VNs it has in the network. Each member’s vote is a Coco administrative transaction and, as such, is submitted, processed, and finally recorded in the Coco administrative ledger.
After a quorum of members have voted, the Coco system determines the result of the vote based on the designated voting policy. Members can vote at any time, meaning that the delay before the result of a vote is determined depends entirely upon how quickly members vote and the voting policies expressed in the network constitution. Changes to any network policy do not take effect until the quorum has finished voting and the change approved.
Transaction Workflow
After a Coco network is established, it can accept transactions from members or participants. There are two types of transactions:
Application transactions, the main set of business transactions through the network.
Coco administrative transactions, such as adding a member.
The Coco Framework uses similar workflows to receive and process both types of transactions, including how consensus is achieved. (Recall that, while there are logically two ledgers, both are recorded within a single store to maintain relative ordering across all transactions in the network.)
Regardless of transaction type, Coco uses secure communication channels for all application-to-node and node-to-node traffic to protect confidentiality. Coco also supports encryption and authentication at the application layer instead of the transport layer.
Application Transaction Workflow
Figure 5 illustrates the workflow for an application transaction:
Before sending transactions, an application (such as an Ethereum DApp) establishes an authenticated, encrypted connection with a VN in the network. The application can establish the connection directly with the VN or through an intermediate front-end system, depending on the security and key management design goals for the DApp and the front-end.
When the Coco Framework receives a transaction, it decrypts it, then routes it to the appropriate blockchain adaptor for the protocol. (The connection is accepted by the host, but is decrypted and processed inside the enclave. Through this approach, interactions at the networking and operating system layers on the host side of the VN take place without visibility into the data payload or the ability to tamper with it.)
The adapter starts a transaction set and interacts with components of the blockchain protocol subsystem (such as block generation logic and Ethereum Virtual Machine, or EVM) to process the transaction.
The adapter commits the transaction set via a distributed store, which persists and replicates all state changes across the network using the configured consensus algorithm. Processing of a single transaction may result in several state changes.
The Coco Framework supports batching of application transactions, however, this trades-off higher throughput for higher latency. When the adapter processes a batched set of transactions, it collects all updates in the transaction set before committing them to the distributed store.
Coco Administrative Transaction Workflow
The workflow for processing a Coco administrative transaction is similar to the above; the only difference is that the transaction is handled by the portion of the Coco Framework that handles governance instead of the blockchain core.
Achieving Consensus
In a Coco network, consensus is required for all updates to the distributed store, including application transactions, smart contract state, and administrative transactions. While consensus is a fundamental aspect of any distributed network, compared to public blockchain networks, a Coco network is unique in that every VN fully trusts every other VN in the network.
Because of this, no need exists to defend against Byzantine faults, such as malicious messages, and blockchain updates that do not conflict with existing state maintained by a VN can be unequivocally accepted. The end result: Coco does not require wasteful, compute-intensive algorithms for proof-ofwork, potentially unfair proof-of-stake algorithms, or latency-inducing time-bound algorithms. Defensein-depth measures to mitigate the risk of TEE compromise or hardware errors in execution are covered later in this document, under Security and Compromise.
The Coco Framework is designed to support pluggable consensus algorithms—with plans to initially integrate Paxos-like consensus algorithms and Caesar consensus, an algorithm from Microsoft Research. Coco networks can be built with other consensus algorithms; to achieve efficient agreement and maximum throughput, ideal implementations should take advantage of the fact that a message received over a secure channel from a trusted VN is itself trusted.
Regardless of the consensus algorithm employed, consensus can be achieved as quickly as durability and serializability requirements are met for the algorithm. Distributing transactions throughout the network can be performed using multi-cast, broadcast trees, or any other protocol deemed efficient for the size and topology of the physical Coco network.
Paxos Consensus
With Paxos consensus, one VN is elected the leader. All other VNs are followers that simply accept transactions and forward them to the leader for processing. After the leader processes the transaction, thanks to the use of TEEs in Coco, followers can simply accept the transaction results from the leader.
Paxos consensus (and Paxos-like algorithms, such as Raft) are highly efficient for a smaller number of nodes, and are traditionally limited by the median latency between nodes. As such, the suitability of Paxos-like consensus algorithms for a Coco network is dependent on the number of VNs—which, in turn, depends on the number of actors in the consortium and the number of nodes per actor.
In future versions of Coco, node scalability could be addressed by adopting distributed systems research such as Flexible Paxos—the simple observation that it is not necessary to require all quorums in Paxos to intersect. It is sufficient to require that the quorum used by the leader election phase will overlap with the quorums used by previous replication phases. This allows Coco to trade slower leader elections (an uncommon event) for faster replication (a common event).
Node scalability could also be addressed through distributed transaction support, using approaches such as optimistic commits and dependent commits on followers. This allows all nodes, not just the leader, to process transactions, spreading the computational load across the Coco network.
More information on Paxos can be found here and more information on Raft can be found here.
Caesar Consensus
Caesar consensus is a new consensus algorithm for architecting secure and efficient consortium blockchain networks. It leverages the cryptographic properties of a blockchain to enable nodes in the blockchain network to reach consensus on a valid ledger. Caesar consensus supports flexible fault tolerance models for network nodes—including crash, Byzantine, a mix of both, or near-total compromise (i.e., all-but-one-node compromises).
In a Coco network, Caesar consensus can be used with traditional fault tolerance algorithms (such as Paxos) to help provide additional security and compromise detection, such as in the event of a TEE compromise. Under such a combined approach, rather than unequivocally accepting transactions from a leader node, follower nodes store small bits of cryptographic information (called heartbeat transactions) within the distributed ledger to enable distributed consensus, which also tracks progress and keeps the leader accountable. If misbehavior is detected, follower nodes can come together to eject the leader from the network, upon which another leader is elected. (Recall that, in a Coco network, the leader can only act maliciously if its TEE is compromised. Caesar consensus detects such a compromise and initiates a failover protocol to start a new leader, which in turn addresses the compromise.) More information on Caesar consensus can be found in Section 3.4 of this paper.
Secure Communication
Coco enforces secure application-to-node and node-to-node communication channels, both of which use mutually authenticated TLS connections that terminate in the enclave. (Technically, there are two application-to-node communication channels—one for application transactions and another for Coco administrative transactions.)
This ensures that only valid members and participants can submit, process, and view network transactions, and that only valid VNs can join the network. Similarly, because data is encrypted across all connections and is only in the clear within the enclave, host-level access to a VN does not allow for inspection of network traffic.
Confidentiality and Integrity
A Coco network’s persistent state—meaning the state that’s written to durable storage—includes three types of data: application transactions, smart contract state, and administrative transactions. All are protected to ensure network confidentiality and data integrity—i.e., to ensure that only valid actors on the Coco network can access the data, and that the data is unaltered. Coco also supports fine-grained data access control, as required to accommodate business requirements for more granular confidentiality— such as 2+ party confidentiality.