...

The Trusted Compute Framework is a ledger independent implementation of the Trusted Compute Specifications published by the Enterprise Ethereum Alliance.

The TCF extends computational trust to off-chain execution enabling.

...

The TCF prototype has been released to open source as a Hyperledger Lab project at https://github.com/hyperledger-labs/trusted-compute-framework.

The TCF was first developed at another Hyperledger Lab project – Private Data Objects (PDO) that , which can be found at https://github.com/hyperledger-labs/private-data-objects.

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

...

TCF does not depend on other Hyperledger projects. Other However, other Hyperledger projects are encouraged to use TCF as a component.

...

The Trusted Compute Framework (TCF) 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.

...

The TCF 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 will start 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.

...

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 results 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 (blockchain node, Requester, off-chain Trusted Compute Service).  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 architecture at a high-level.

Trusted Compute Service (TCS) hosts trusted Workers and makes them available for execution of Work Orders (WO) that are submitted by Requesters via a front end UI or command line tools. Work orders also can be submitted by (Enterprise app specific) smart contracts running on the DLT.

There are four interfaces implemented according to [EEA-TC-SPEC]. Even though initially designed for Ethereum, these interfaces are uniformly implemented for all supported DLTs. The interfaces are:

• TCS catalog that lists available TCS services and, for each service, provides a blockchain address and/or URI where about their corresponding Workers can be discovered
• Worker registry that lists Trusted Compute Workers . It includes an attestation verification report, public RSA encryption key, and public ECDSA SECP256K1 verification key
• Work order processing API that allows Requesters to submit Work Order requests and receive corresponding responses with data encrypted end-to-end between the Requester the and Worker. Both the request and response may include multiple data items independently encrypted by different parties using different keys. The Requester may optionally sign its requests. Even if the Requester doesn’t sign the request (aka anonymous request), there is a mechanism enforcing Work Order request integrity. The enclave always signs its responses.
• Work Order receipts API that can be used for payment processing, auditing, and dispute resolution. The receipts are signed by the Requester and the worker.

There are two models of operation:

• 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 API running on the blockchain and . The Requestor is implemented using the a blockchain-specific mechanism, e.g. 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.

Direct model was introduced as a complement to the proxy model to facilitate specific use cases that are hard to address by relying on the proxy model alone, e.g. processing sensor data streams (data filtering and pre-processing for IoT , or supply chain), handling custom worker key update polices, and aggregating (a large volume of) worker receipts.

Currently, only the direct model is implemented. Proxy model for Ethereum and Fabric will be implemented next. 

It is expected that real world applications may benefit from a hybrid model that will combine elements of both proxy and direct models.

A Trusted Worker executes applications application-specific workloads and implements following capabilities:

• Worker Attestation service, e.g. in case of Intel SGX TEE it can be an Intel IAS or 3^rd party (DCAP) Service
• Work Order Invocation service, which verifies the integrity of the Work Order and the Requester signature, decrypts input and encrypts output data, signs the result, and creates the Work Order receipt update
• External IO I/O Plug-in Interfaces, which allows a workload running inside of TEE to read and write data from/to external data source, e.g. hosted locally by the TCS or remotely in the cloud. The Interface provide provides a basic infrastructure from crossing to cross trust boundaries. Actual data access and format is application-specific and depicted as Data Connector on the diagram

Workloads can be implemented to  execute pre-defined predefined fixed functions which are precompiled pre-compiled at build time (written, for instance in Rust or C++),  or can be implemented as runtime script interpreters, (e.g. Solidity or Python). In the latter case the script interpreter is precompiled pre-compiled into the worker at  at build  timetime, and scripts are loaded at runtime as a part of the Work Order. Scripts can be chosen from a list provided by the TCS, or dynamically provided by the Requester (unknown to the TCS). The specific policy enforcement is application-dependent.

...

In the current implementation, interactions between TCS components is brokered via a KV (Key-Value) Storage that is implemented on top of LMDB. The KV Storage Connector allows utilizing the KV Storage on a single physical system or across multiple physical systems. The Adaptor abstracts LMDB from the rest of TCS so a production implementation may choose to replace LMDB with another database of their choice.

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 case cases the TCF baseline implementation can be is sufficient, while in others dApp may have to differ or extend the baseline implementation.  

...

The diagram below depicts a high level execution flow in the proxy model.

During the registration phase, TCS:

• Instantiates a Worker. The Worker generates signing and encryption key pairs and stores the private keys in a way accessible to the Worker only, e.g. in case of Intel SGX TEE, it will be in its sealed storage
• Produces an attestation quote for the Worker (including an attestation chain for its public keys) and submits it for a verification, e.g. in case of Intel SGX TEE, to Intel IAS
• The attestation verification report from the previous step along with the public keys is submitted to and recorded in the Worker Registry on the blockchain

During the discovery phase a Requester looks up an appropriate Worker and validates its attestation verification report and stores the Worker’s public keys for further use.

During the invocation phase:

• The Requester creates a Work Order request payload (JSON). To encrypt the data, the Requester generates a one time symmetric key that also submitted as a part of the request, but encrypted with the Worker’s public encryption key. The request includes an encrypted hash of its key parameters and data items (integrity enforcement). The request can also be signed by the Requester.
• The Requester submits the request to the Work Order Queue on the blockchain and creates a corresponding Work Order Receipt on the blockchain.
• After the Work Order request is submitted to the Work Order queue on the blockchain, TCS receives a notification (aka event or alert) and retrieves the Work Order request from the Work Order Queue on the blockchain. TCS verifies the Requester’s signature (if provided).
• The Work Order request is submitted to the Worker. The Worker decrypts the data and verifies the Work Order integrity. Then the Worker processes the Work Order and generates a response. The Worker uses the symmetric data encryption key from the request to encrypt output data and signs the response using its private signing key.

During the results phase

• 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 3^rd 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).

...

Initial functional implementation is already available as a Hyperledger Lab project [TCF-GITHUB]. The TCF implementation is derived from another Hyperledger Lab called PDO Private Data Objects (PDO) [TCF-GITHUB]. Then Initially a private branch was created forked by Intel to build the initial TCF implementation, with contributions from iExec.   

There is a growing TCF community already. Below is list of companies that have already expressed a formal support for the project and more . More companies and individuals are in the process of learning and ramping up on TCF with plans to joint the TCF project and utilize it for their product development. Number The number of contributors represents an the initial commitments, with many companies intended intending to increase participation as the project advances to the next phase.   

• Intel Corporation: 7 contributors to deliver core TCF 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 easy-of-use for developers
• Alibaba: 2 contributors who will work to adopt TCF for its Ali Cloud and contribute to the TCF 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 into

...

• Hyperledger Fabric
• Chainlink: 3 contributors that will contribute to the TCF's plans for how to integrate with decentralized oracles and attested oracles, which will be able to provide both TCF 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 architecture, documentation, and spec compliance
• EEA: expects to use TCF as a base for its EEA Off chain TC Specification certification program and cooperate with the TCF 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 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 test net and contribute to Trusted Token usage implementation
• Santander: 3 contributors to provide reference implementation of critical use cases and incorporate TCF 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/tcftrusted-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 connection? 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. 

Chainlink work works with Google- does Google–does this have any bearing (except for the Ethereum angle)? Chainlink joined TCF to contribute an implementation and use case for attested decentralized oracles.

Intel SGX vulnerabilities - what vulnerabilities–what bearing will this have on the work? Intel tracks information about vulnerabilities and mitigations on a central website at following these links: facts-about-side-channel-analysis-and-intel-products and engineering-new-protections-into-hardware. Please refer to the website these websites for information about specific security vulnerabilities, resources, and responses, including mitigation by product CPU model.

What are the identity bindings between off-chain identities (both Enterprise and TCF identities) and on-chain identities? At this time TCF assumes that identities can be either user defined, blockchain address, or the public signature verification key of the requester.  This is an area that can be defined further, e.g. to accommodate DIDEthereum Decentralized Identifiers (DIDs). 

Any Is there any current work or hooks in TCF that deals with other forms of trusted computation (such as Hardware TEEs, HME, MPC, ZK etc.)? The TCF architecture is specifically designed to accommodate additional trusted compute options (via a KV storage interface). There is a work in the process to locate potential contributors with appropriate domain expertise via the Ethereum Enterprise Alliance (EEA). Also TCF encourages anybody with such expertise to join the this project and contribute additional worker types to the project.

What are is the relation between TCF and Gardener projects? Gardener and TCF are as separate but complementary projects. Gardener may adopt TCF core infrastructure and it can be used for testing purposes during the TCF  implementation phase and in . 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.

...