Versions Compared

Old Version 21

changes.mady.by.user Dan Middleton

Saved on

compared with

New Version Current

changes.mady.by.user Dan Anderson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Changed TCF to Avalon

(

...

Originally proposed as Trusted Compute Framework (TCF))

Project Identifier

HIP: TCFAvalon

Sponsor(s)

Eugene (Yevgeniy) Yarmosh; Intel; yevgeniy.y.yarmosh@intel.com - primary contact

...

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:

...

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.  

...

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

...