Introducing Hyperledger Avalon

We are very excited to announce the latest of the Hyperledger projects, Hyperledger Avalon. Some of you may know Avalon as TCF or Trusted Compute Framework, the name it held during the initial phases of its collaborative development. In fact, that collaboration is one of the stand-out aspects of Hyperledger Avalon. It is an interesting intersection of Hyperledger, EEA, and cloud service provider ecosystems and is perhaps the most broadly sponsored project to date. It brings together sponsorship from Intel, iExec Blockchain Tech, Alibaba Cloud, Baidu, BGI, Chainlink, Consensys, EEA, Espeo, IBM, Kaleido, Microsoft, Banco Santander, Wipro, Oracle, and Monax. That’s quite a list of sponsors by any standard. The natural question is what could drive so much interest?

There are a couple of key challenges with blockchain that probably don’t surprise any reader of this blog: scalability and confidentiality. One approach to both of these limitations is to perform some operations “off-chain.” In a traditional view of a blockchain, the data and validation logic for every transaction takes place on every node of the blockchain network or “on-chain.” It’s this redundancy and transparency that provides a network with its integrity but also comes at the cost of performance and confidentiality. By offloading some work, participants can trade off resiliency and integrity for performance and confidentiality. Of course, everyone wants to have their cake and eat it too, and so the use of the use of “trusted computing” is intended to maintain resiliency and integrity guarantees as much as possible while affording the additional performance and confidentiality. Trusted computing includes a variety of techniques to ensure that computation was done correctly and secretly. Hyperledger Avalon will realize these as different Worker types and include TEE (Trusted Execution Environments like Intel® SGX), MPC (multi-party compute), and ZK (zero-knowledge proofs).

Check out the project proposal for more on the technical details and, of course, the initial code base https://github.com/hyperledger/avalon.

It’s also worth understanding a little of the project’s history to see how these communities came together. Avalon began as a reference implementation of the EEA’s Off-Chain Trusted Compute Specification, which sought to standardize how to farm out and reconcile workloads. Coming out of the EEA specification discussions, iExec was excited to build a heart disease evaluation prototype. iExec also immediately dove into building the Ethereum components for Avalon’s proxy model. In parallel, Mic Bowman was exploring trusted execution uses in a Hyperledger Lab called Private Data Objects (PDO). The initial Avalon authors forked off the PDO codebase and launched it as another lab within Hyperledger. Hyperledger Labs is a place to facilitate collaboration and experimentation among the projects, in this case spawning some interesting trusted computing code from a couple disparate sources. Having tangible code enabled other contributors to see directly how they could make use of and integrate with this approach. For example, IBM prototyped this Hyperledger Fabric integration with Avalon [2 links: https://github.com/jeffgarratt/hyperledger-member-summit-2019-tcf-demo-app and https://github.com/jeffgarratt/fabric-prototype].

Now that Avalon has matriculated to a full project at Hyperledger, we are excited to continue maturing and expanding the code base. Some of the initial areas we plan to work on are solidifying the Hyperledger Fabric integration and similarly working with another new addition to Hyperledger, the Ethereum client, Hyperledger Besu. We may even be some new things to say at DevCon 5!

Back to all blog posts

Sign up for Hyperledger Horizon & /dev/weekly newsletters 

By signing up, you acknowledge that your information is subject to The Linux Foundation's Privacy Policy