(Originally proposed as Trusted Compute Framework (TCF))
Project Identifier
HIP: TCFAvalon
Sponsor(s)
Eugene (Yevgeniy) Yarmosh; Intel; yevgeniy.y.yarmosh@intel.com - primary contact
...
Silas Davis; silas@monax.io
Abstract
The Trusted Compute Framework is a ledger independent implementation of the Trusted Compute Specifications published by the Enterprise Ethereum Alliance.
TCF Avalon extends computational trust to off-chain execution enabling.
- Improved blockchain throughput and scalability
- Improved transaction privacy
- Attested Oracles, trusted reporters of data generated outside of the blockchain.
Context
The TCF Avalon prototype has been released to open source as a Hyperledger Lab project at https://github.com/hyperledger-labs/trusted-compute-framework.
TCF Avalon was first developed at another Hyperledger Lab project – Private Data Objects (PDO), which can be found at https://github.com/hyperledger-labs/private-data-objects.
TCF complies Avalon complies with existing and emerging standards especially, the Off-Chain Trusted Compute Specification developed by the Enterprise Ethereum Alliance (EEA). The spec can be found at https://entethalliance.org/wp-content/uploads/2019/05/EEA_Off_Chain_Trusted_Compute_Specification_V1_0.pdf.
A prototype (work in progress) that integrates TCF Hyperledger Avalon and Hyperledger Fabric can be found at https://github.com/jeffgarratt/fabric-prototype/tree/tcf-demo and https://github.com/jeffgarratt/hyperledger-member-summit-2019-tcf-demo-app
Dependent Projects
TCF Hyperledger Avalon does not depend on other Hyperledger projects. However, other Hyperledger projects are encouraged to use TCF Avalon as a component.
Motivation
The Trusted Compute Framework (TCF) Hyperledger Avalon enables the secure movement of blockchain processing off the main chain to dedicated computing resources. This enables:
- Improved blockchain throughput and lower latency
- Improved transaction privacy
- Attested Oracles, which are trusted reporters of data generated outside of the blockchain.
TCF Avalon is designed to help developers gain the benefits of computational trust and mitigate its drawbacks. A blockchain is used to enforce execution policies and ensure transaction auditability, while associated off-chain trusted compute resources execute transactions.
...
The approach will work with any Trusted Compute option that guarantees integrity for code and integrity and confidentiality for data. Our initial implementation uses a Trusted Execution Environment enabled by Intel@ Software Guard Extensions (SGX).
The TCF Hyperledger Avalon uses a distributed ledger to:
- Maintain a registry of the trusted workers (including their attestation info)
- Provide a mechanism for submitting work orders from a client(s) to a worker
- Preserve a log of work order receipts and acknowledgments
Status
This project started in incubation and is now a full-fledged Hyperledger project.
The initial core functionality of the project has been implemented and the community will deliver additional functionality and bring project quality to product level standards.
Solution
Early blockchains delivered computational trust via massive replication but had limited throughput, and imperfect privacy and confidentiality. Adding trusted off-chain execution to a blockchain is proposed as way to improve blockchain performance in these areas. A main blockchain maintains a single authoritative instance of the objects, enforces execution policies, and ensures transaction and result auditability, while associated off-chain trusted computing allows greater throughput, increases Work Order integrity, and protects data confidentiality.
...
The figure above depicts an example of blockchain with N member enterprises. Each enterprise has Requesters, a blockchain node and one or more Trusted Workers (hosted by a Trusted Compute Service). Requesters submit Work Orders, and Workers execute these Work Orders. Work Order receipts can be recorded on the blockchain. While each of the enterprises in the figure above contains all three major components (blockchain node, Requester, and off-chain Trusted Compute Service), this is not necessary. For example, Requesters from Enterprise 1 may send Work Orders to a Worker at Enterprise 2 and vice versa. Ultimately, an enterprise is free to host any combination of the three elements depicted on the figure above. Accessing resources across multiple enterprises increases network resilience, allows more efficient use of resources, and provides access to greater total capacity than most individual enterprises can afford.
A diagram below depicts TCF Avalon architecture at a high-level.
...
- Proxy model relies on the smart contract (Ethereum or Sawtooth with Seth) or chaincode (Fabric) running on the DLT for managing all or any subset of APIs listed above. The proxy model has:
- A DLT connector, which is shown on the diagram above. The diagram depicts components implementing interactions between the DLT and TCS. DLT-specific plug-in adapters are responsible for abstracting DLT-specific APIs from the rest of implementation
- A Requester, which utilizes a TCF Avalon API running on the blockchain. The Requestor is implemented using a blockchain-specific mechanism, such as Solidity smart contracts on Ethereum or Sawtooth (via Seth) or as chaincode on Fabric.
- Direct model provides a JSON RPC API for any of the APIs listed above except for the TCS catalog
- The TCS listener on the diagram above depicts components implementing the direct model APIs
...
Components shown in blue on the diagram below depict functions that are generic for all or most applications. Components shown in orange depict functions that are always application-specific. Decentralized components (smart contracts or chaincode) running on DLT are depicted as a mix of both colors because in some cases the TCF Avalon baseline implementation is sufficient, while in others dApp may have to differ or extend the baseline implementation.
...
- TCS submits the Work Order response to the Work Order Queue on the blockchain and updates the Work Order receipt on the blockchain.
- After the Work Order Result is submitted, the Recipient receives a notification and retrieves the result from the blockchain. It may also retrieve the updated Work Order Receipt. In many use cases the receipt is used by 3rd party (not by a requester itself) for payment processing, dispute resolution, auditing, or regulation compliance
- The requester decrypts the result using the same one-time key that was generated during the invocation phase. The Requester uses the Worker’s public verification key to verify that the result was signed by the Worker (and hence the Work Order indeed was processed by the right Worker).
Efforts and Resources
Initial functional implementation is already available as a Hyperledger Lab project [TCF-GITHUB]. The TCF Avalon implementation is derived from another Hyperledger Lab called Private Data Objects (PDO) [TCF-GITHUB]. Initially a private branch was forked by Intel to build the initial TCF Avalon implementation, with contributions from iExec.
There is a growing TCF Avalon community already. Below is list of companies that have already expressed a formal support for the project. More companies and individuals are in the process of learning and ramping up on TCF Avalon with plans to joint join the TCF Avalon project and utilize it for their product development. The number of contributors represents the initial commitments, with many companies intending to increase participation as the project advances to the next phase.
- Intel Corporation: 7 contributors to deliver core TCF Avalon infrastructure and Intel SGX-specific code
- iExec: 4 contributors will develop Ethereum smart contracts, integrate TEE options that support most of the the mainstream programming languages and native applications, and improve TCF Avalon easy-of-use for developers
- Alibaba: 2 contributors who will work to adopt TCF Avalon for its Ali Cloud and contribute to the TCF Avalon core to extend supported programming environments, e.g. GOLANG
- Baidu: 2 contributors who will work on enhancing core capabilities and integration of MesaTEE based workers.
- BGI: Will contribute to the integration of TCF Hyperledger Avalon into Hyperledger Fabric
- Chainlink: 3 contributors that will contribute to the TCFAvalon's plans for how to integrate with decentralized oracles and attested oracles, which will be able to provide both TCF Avalon computations and various on-chain computations enabled by them with secure access to various key API inputs and enterprise/payment event outputs.
- Consensys: 2 contributors to work on the TCF Avalon architecture, documentation, and spec compliance
- EEA: expects to use TCF Avalon as a base for its EEA Off chain TC Specification certification program and cooperate with the TCF Avalon community to drive improvements to the Specification
- Espeo: 1 developer to contribute a monitor tool and help with implementation of Ethereum integration
- IBM: 1 contributor to work on integrating TCF Avalon with Fabric
- Kaleido (A ConsenSys Business): 1 contributor working on deployment and manageability solution for hosting Trusted Compute Service
- Microsoft: to provide Azure resources to run a TCF Avalon test net and contribute to Trusted Token usage implementation
- Santander: 3 contributors to provide reference implementation of critical use cases and incorporate TCF Avalon into Santander's cyber-security policies.
- WiPro: 2 contributors working on design and implementation of resource types (ZKP, MPC etc.)
How To
The project will be managed in a Hyperledger GitHub repository and will follow community norms present in other Hyperledger projects.
We propose creation of the following repository: github.com/hyperledger/trusted-compute-framework
References
[TCF-GITHUB]
TCF Hyperledger Labs repo: https://github.com/hyperledger-labs/trusted-compute-framework
...
https://github.com/jeffgarratt/fabric-prototype/tree/tcf-demo and https://github.com/jeffgarratt/hyperledger-member-summit-2019-tcf-demo-app
FAQ
What is the connection between TCF and Gardener? TCF and Gardener discovered each other recently and we definitely agree that there is shared scope between these two projects and both projects are interested in working together in the process of evaluating optimal collaboration options.
...
What is the relation between TCF and Gardener projects? Gardener and TCF are separate but complementary projects. Gardener may adopt TCF core infrastructure for testing purposes during the TCF implementation phase. In the future TCF will be one of the attested Oracle use cases. Espeo (primary Gardener sponsor) will join TCF and to contribute a monitor tool and help with implementation of Ethereum integration.
Closure
The success of this project can be measured by successful integration of TCF with multiple DLTs and, more importantly, by its broad utilization in real world enterprise-focused use cases emphasizing requirements of scalability and privacy preservation.
Reviewed By
- Arnaud Le Hors
- Baohua Yang
- Binh Nguyen
- Christopher Ferris
- Dan Middleton
- Hart Montgomery
- Kelly Olson
- Mark Wagner
- Mic Bowman
- Nathan George
- Silas Davis
...