The basic vision of our work is to increase decentralization of blockchain networks by lowering participation barriers and adding incentives while simultaneously strengthening blockchain security. In addition, we hope this work will accelerate deployment of energy-efficient consensus algorithms including Proof of Stake and scalability solutions such as Plasma.

Decentralization First

Decentralization can be loosely defined as no one single entity having control over the canonical truth of a system. Per Vitalik Buterin, “blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer).” Alternatively, when one says blockchains implement “decentralized trust,” it refers to mechanisms by which all parties in the system can reach a consensus on what the canonical truth of the system is. Therefore, power and trust aredistributed (or shared) among the network’s stakeholders (e.g. developers and miners), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions).

We believe that trusted containers such as Trusted Execution Environments (TEEs) can play a significant role in addressing scalability, privacy, and fairness in the current blockchain ecosystem, three challenges that are all impacting the level of decentralization. These challenges exist both at the core infrastructure/consensus level and at the application/smart contract level. Essentially, we believe our vision can be realized if any entity with a trusted container in off-the-shelf hardware can participate in a decentralized network by providing a utility service to the network in the same way that any blockchain node does when it executes transactions and mines a block. However, this service has autonomous, verifiable, tamper-resistant code execution in the trusted container. It would be trivial for an entity to prove at a particular time what logic was executed, and what the inputs and outputs were. This would be truly democratizing decentralization!

A common concern of the blockchain community regarding TEEs is that by placing trust in a TEE, we are indirectly placing trust in a private for-profit institution that manufactures the chip which enables the TEE to run. In this post, we will describe a decentralized TEE deployment architecture in which trust in a single entity is minimized such that the value for the ecosystem should outweigh any concerns with respect to the chip manufacturers. Such a decentralized TEE deployment architecture can help public blockchains both scale and comply with data protection regulations when combined with emerging scaling technologies such as Plasma.

Potential blockchain Core Infrastructure Benefits

With provable autonomous reputation blockchain nodes, one can offload sensitive consensus actions, requiring less time for economic finalization and less economic stake, thereby democratizing participation.

Autonomous Transaction pools can now prove that transactions were neither censored nor ordered maliciously.

Overlay networks can now be used for consensus processes outside of base protocols such as in governance of Decentralized Autonomous Organizations (DAOs) or, for example, to agree on the proper canonical order of transactions in a block.

Potential blockchain Application Benefits

Smart contracts can offload compute MIPS intensive tasks for efficiency.

Blockchain analytics, or in fact any analytics, can be performed on personal or confidential data without revealing the underlying data to any entity directly, thereby preserving data privacy.

Data oracles can ensure data supply chain integrity and preserve the privacy of data requesters or providers.

Given the potential significant positive impact on blockchain ecosystem services such as decentralized exchanges or prediction markets, and how blockchain utility services can reduce participation barriers and expand decentralization using off-the-shelf hardware, it is our hope that others in the blockchain ecosystem will partner with us to make this vision a reality.

Scaling Securely

The key requirements of virtually all blockchain platforms are to provide high scalability and functionality, while ensuring strong data privacy and security. This creates a natural tension between the need for a decentralized architecture that provides a high-level of security and the need for a centralized environment that offers high scalability and strong data privacy. In addition, if the platform is supposed to be open/permissionless, the complexity of providing a high-level of data privacy that is compliant with existing data protection regulations such as the General Data Protection Regulation (GDPR) [1] increases measurably. GDPR, for example, significantly limits what data can be placed on a blockchain, even in encrypted form. Given this context, we can make the following statements relevant about current (open) platforms that will always hold true:

Trust in decentralization is proportional to the number of validators and to the level of validator influence i.e. validator stake in a Proof-of-Stake (PoS) consensus algorithms. Increasing participation cost due to high infrastructure requirements in, for example, Proof-of-Work (PoW) consensus or size of the stake in PoS decreases decentralization. Validators can collude to intentionally misbehave by censoring input or output, changing the transaction ordering or including illicit transactions. Compliance with data protection regulations such as GDPR creates challenges for blockchain applications. Increasing popularity of dApps or decentralized applications will place significant requirements on network scalability.

Here, we propose trusted compute overlay networks, where each network provides their own trusted compute utility service, and where each node executes validator logic with integrity, communicates with other overlay nodes to detect censoring of input and/or output in a peer-to-peer fashion, and forms an opinion on the correct computational and data state via a consensus mechanism that leverages trusted compute properties. These trusted compute overlay networks can be used to offload smart contract processing for scaling/ responsiveness and/or for privacy with guaranteed code and execution integrity and data confidentiality. This effectively addresses issues of increasing participation costs and validator collusion. In turn, a trusted compute overlay network would allow us to safely scale blockchains through a framework such as Plasma [2] while maintaining a high level of decentralization.

Fig.1: A conceptual view of a Trusted Compute Overlay Network.

Leveraging trusted compute overlay networks for Trusted PoS Validators / Validator pools as depicted in Fig. 1 allows one to reduce costs of entry, thereby increasing both participation and trust in the network.

We achieve this level of decentralization and security by decomposing a full blockchain node into its base components using Ethereum [3,4] as a reference framework:

Transaction Mempool & Ordering

Ethereum Virtual Machine (EVM)

Casper FFG

PoW Algorithm

and adapting the key security components of each module to run in a TEE [5] except for the PoW Algorithm. After discussing the node decomposition in more detail below, we will delineate how a network for each module can be established either through the existing validator network or through overlay networks, and how it can be secured through properly adapted incentive models and consensus algorithms.

Fig.2: Trusted Compute Overlay Network for trusted smart contract execution

As depicted in Fig.2, we can also leverage trusted compute overlay networks for smart contract scalability and confidentiality of the user’s data.

We achieve the required security guarantees by creating a trusted framework to offload complex smart contract logic and private data handling to a trusted compute overlay network.

Lastly, a common expectation of state channels and most side chains is that participants are expected to constantly monitor for fraudulent exits. A trusted compute overlay network will create an alternative for participants to offload all monitoring activities to the overlay, allowing them to focus on their core business.

We believe that once the community has seen the value and understood the operational autonomy of such trusted services, nodes can charge a transaction fee for the extra level of trust, which they can share with the trusted service providers. The consensus protocol can also be amended to allow for block rewards to be shared with trusted utility service providers. This will create a marketplace and economy for trusted utility services that is vibrant, diverse, and that provides a myriad of services we cannot conceive of today.

Let us know see how TEEs are currently used in the ecosystem and how they might be used going forward.

Trusted Compute Resources for Blockchains

General Usage Patterns of TEEs in the Blockchain Ecosystem

As the community makes progress in the development of distributed ledger and smart contract execution architectures, the need for performance, responsiveness, and privacy are starting to become major roadblocks for broader adoption.

While transaction verifiability raises privacy and confidentiality concerns, emerging data protection regulations such as GDPR could make sharing data on distributed ledgers challenging given their immutability guarantees. On the one hand, the participants in a distributed ledger need all the data involved in a transaction to perform the appropriate checks and balances. In the case of smart contracts, this includes having access to the input and output data for executing and validating a smart contract. On the other hand, this requirement clearly clashes with the sensitive nature of information such as personal health records and confidential corporate documents.

Proposed solutions to balancing verifiability with confidentiality include private groups, zero-knowledge constructions, and multi-party computation protocols. While private groups can achieve good performance by simply implementing access control mechanisms for trusted group members, zero-knowledge constructions and multi-party computation protocols are still relatively computationally expensive in practice. Zcash [6] and Hawk [7] rely on advanced cryptographic primitives — Zero-Knowledge proofs such as ZK-Snarks — and provide strong transactional and user privacy as well as programmability. Hawk additionally relies on a facilitating party which can be instantiated with Trusted Computing technology e.g. Intel SGX [8]. Enigma [9] proposes the use of Secure Multi-Party Computation as a building block for the decentralized execution of smart contracts on private data.

Another significant issue in blockchain networks are trusted data oracles, or the lack thereof. In the case of a data oracle, smart contracts are dependent on the accuracy of an outside data source for their transaction data input. A priori, there are several points of failure in the data supply chain, from the source all the way to the entry point into the blockchain network. An effort to address at least most of the concerns around a trusted source of data oracles as well as the privacy of the consumer of the data is addressed by the TownCrier project [10] which uses Intel SGX as its TEE.

Lastly, to compete with more mainstream systems such as Visa, Paypal, Nasdaq, eBay, Amazon, or Facebook, cryptocurrencies and the business models built on top of them need to significantly scale transaction volumes and improve fairness guarantees. Scalability problems of public blockchains are due to the time it takes to put a transaction into a block and to reach consensus on that transaction. When miners mine a block, they become temporary dictators of that block, which leads to fairness conflicts. The higher the transaction fees, the faster the miners will include a transaction in their block. While this is okay for people who have a large balance of cryptocurrency, it is neither financially fair nor does it support broad adoption.

For example, as the network load increases, transactions with the lowest transaction fees could have to wait for hours or even days to be included in a block while higher fee transactions are given preference. Payment channels have been proposed as a solution to scaling payments on a blockchain with real time settlement. Payment channels are effectively an off-chain point-to-point payment network with the aggregate of many payments being settled through one on-chain transaction. A representative of this family of scaling solutions leveraging TEEs to increase both privacy and trust in correct payment accounting and settlement is Teechan [11]. The Teechan approach primarily achieves a higher transaction throughput and lower transaction latency than other solutions and does not require protocol changes.

Lastly, to reach consensus in a trustless system, every node must independently validate a transaction and its effect on the state of the ledger. Consequently, each node must have their own copy of the blockchain ledger. The problem is that, unlike other pieces of technology, the system latency typically increases with the number of nodes in a network, and therefore, the whole process becomes less and less responsive. Proposed solutions include increasing transactions per block, better consensus algorithms, sharding, hierarchical networks, and off-chain channels. An example of a new, higher performance consensus algorithm that leverages a TEE is Proof-of-Elapsed-Time (PoET), part of the Hyperledger Sawtooth project [12]. PoET was designed primarily for permissioned blockchains in an enterprise context to avoid economic incentive structures required for public blockchains. However, the algorithm could be easily extended to encompass Casper FFG type incentive structures. In the end, all these solutions have their pros and cons, and proven solutions to the scalability problem are yet to emerge. As a consequence, the problems around privacy, confidentiality, performance, and responsiveness end up restricting the current application domain of distributed ledgers and smart contracts.

As the general usage pattern demonstrates, TEEs can offer significant benefits to blockchain networks in several different areas. Therefore, it is worth exploring this direction further and bringing multiple components together to build new trusted compute capabilities that address some of the pressing blockchain challenges.

Deconstructing an Ethereum Blockchain Node into Trusted Compute Modules

In this section, we will use the general structure of an Ethereum blockchain node with Casper FFG as a reference case for how any blockchain node with any consensus algorithm can be decomposed into trusted compute components. The aim is to provide an approach and roadmap to eventually create blockchain nodes that utilize trusted compute resources in all critical node modules in order to increase decentralization, security, and scalability of blockchain networks.

Although we are using an Ethereum node as an example, the approach is quite general and can be readily extended to other blockchain architectures such as Bitcoin [13], Burrow [14], Cardano [15], BigChainDB [16], and others.

A Fully Deconstructed Ethereum Node

An Ethereum node with Casper FFG can generally be deconstructed into the following main components:

Transaction Pool and Ordering Ethereum Virtual Machine (EVM) Casper FFG PoW Algorithm

Modules 1 through 3 can benefit from trusted compute resources in the following areas:

Transaction Pool and Ordering: Eliminating transaction selection and ordering bias by node operators. Ethereum Virtual Machine (EVM): Eliminating manipulation of opcode sequences from smart contracts and subsequent state changes as well as possible data manipulation of transaction inputs and outputs. Casper FFG: Eliminating the possibility of Casper nodes casting malicious checkpoint votes, registration, withdraw transactions, validation signatures, and validation codes.

The PoW algorithm does not require a trusted compute component because PoW is trusted compute by itself through its brute force computation of the nonce.

In a generalization of the above, for any blockchain stack employing a consensus algorithm other than PoW such as PoS or other BFT-type algorithms, the same argument made for Casper FFG can be directly applied since those algorithms fall into the same equivalence class.

In the figure below, we detail our deconstruction:

Fig.3: Ethereum Node decomposed into trusted compute components

As one example, let us now discuss the simplest service at a high level — a Trusted Transaction Ordering Service Oracle. We will discuss the Oracle in detail in subsequent posts.

Ideal State Trusted Transaction Ordering Service Oracle (TTOSO)

Incoming transactions are randomized and given a Unique ID for ordering (SCN).

Ordered transactions are encrypted with EVM Trusted Execution Environment (TEE) public key.

Encrypted transactions in predetermined batch size are passed to EVM TEE with attestation of correct execution.

Optionally, one can employ an overlay network of TTOSOs to reach consensus on one version of a transaction ordering. This will increase trust in the ordering result.

Possible Rewards: Donations, extra transaction fees, or even additional protocol rewards.

A Three Phase Roadmap

For such a set of services to gain acceptance in the blockchain ecosystem, it is crucial that the approach remains agnostic to the actual TEE implementation, does not replace any current security guarantees, that the services are open source, and that the TEE self-attestation functions without a third party. Additionally, Trusted Compute Resources have to deliver immediate value to the blockchain ecosystem in general and the Ethereum ecosystem in particular. We see three phases to implementing Trusted Compute Resources:

Phase 1: We will initially focus on creating a TTOSO overlay network with more than one non-third party dependent TEE technology represented. This service will be free with donations from the community gladly accepted.

We will initially focus on creating a TTOSO overlay network with more than one non-third party dependent TEE technology represented. This service will be free with donations from the community gladly accepted. Phase 2: Based on the acceptance of the blockchain community of such a trusted service as an overlay network and the lessons learned, we will want to expand to a Trusted Casper Validator node (TCVN) in time for Ethereum switching from PoW to the PoW/Casper hybrid. At this point, it might also be feasible to introduce the right reward model for TTOSO through fee or reward sharing implemented at the protocol level.

Based on the acceptance of the blockchain community of such a trusted service as an overlay network and the lessons learned, we will want to expand to a Trusted Casper Validator node (TCVN) in time for Ethereum switching from PoW to the PoW/Casper hybrid. At this point, it might also be feasible to introduce the right reward model for TTOSO through fee or reward sharing implemented at the protocol level. Phase 3: At this point both TTOSO and TCVN will have been established in the ecosystem with enough learnings to make both utility service networks robust. We will fine-tune the consensus and incentive models such that we can implement a Trusted EVM (TEVM), ultimately completing the hardening of all critical components of an Ethereum node with trusted compute resources.

Phase 1: Trusted Ordering Service

The most important things to achieve in Phase 1 are:

Build consensus in the Ethereum community that such a TTOSO is valuable, and form a coalition of contributors that would be willing to provide such a service to the community. Produce a community Proof-of-Concept including a first overlay network that is peer reviewed and has proven the advertised value-add. Launch an overlay testnet for Ropsten/Rinkeby to demonstrate the feasibility and usability at a larger scale. Launch a production overlay network. Monitor adoption and robustness “in-the-wild” and course-correct, if required.

In subsequent posts, we will go into the details of the analysis for the Trusted Transaction Ordering Oracle Service, the Trusted Casper FFG, and the Trusted EVM service.

A Call to the Community

In this post, we proposed a new set of trusted compute services for blockchain nodes that would allow the community to security harden blockchain networks, improve data privacy, increase scalability, expand the level of decentralization, and ultimately facilitate trust by lowering current cost entry barriers associated with required node infrastructure.

Using the example of an Ethereum node with the planned Casper FFG addition, we demonstrated how to deconstruct an Ethereum node into components which can benefit from trusted compute resources.

We then presented a roadmap on how to realize our vision for trusted Ethereum compute utility services in three phases and delineated the steps of Phase 1, in which we intend to build and roll out a TTOSO together with interested contributors.

We invite the blockchain community to review and improve this vision and roadmap, and to help implement this framework so that not only Ethereum but the entire blockchain space can grow and deliver on its significant promise.

If you want to get in touch and contribute, please reach out to either one of us — sanjay.bakshi@intel.com or andreas.freund@consensys.net.

Acknowledgments

The authors would like to acknowledge the important input of Iddo Bentov early on in this work, the Ethereum Foundation’s Virgil Griffith, Jon Choi, and Vitalik Buterin for early encouragement, Intel’s Mic Bowman for conversations on Private Data Objects, and finally iExec’s Gilles Fedak and Lei Zhang for conversations on Decentralized Cloud.

Bibliography

[1] European Commission, “The General Data Protection Regulation (GDPR)”, (2016), https://ec.europa.eu/info/files/regulation-eu-2016-679-protection-natural-persons-regard-processing-personal-data-and-free-movement-such-data_en

[2] Plasma: Buterin, V., Poon, J. “Scalable Autonomous Smart Contracts” (2017), Retrieved from https://plasma.io/plasma.pdf

[3] Wood, G., “ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER”, (2015), Retrieved from https://gavwood.com/paper.pdf

[4] Buterin, V., Griffith, V. (2017) “Casper the Friendly Finality Gadget.” Ethereum Foundation, Retrieved from https://github.com/ethereum/research/blob/master/papers/casper-

basics/casper_basics.pdf.

[5] McGillion, B., Dettenborny, T., Nymanz, T. Asokanx, N.“Open-TEE — An Open Virtual Trusted ExecutionEnvironment”, (2015), Retrieved from https://arxiv.org/pdf/1506.07367

[6] Hopwood, D., “Zcash Protocol Specification, Version 2018.0-beta-19 — GitHub”, (2018), Retrieved from https://raw.githubusercontent.com/zcash/zips/master/protocol/protocol.pdf

[7] Kosba, A., Miller, A., Shi, E., Weny, Z., Papamanthou, C., “Hawk: The blockchain Model of Cryptography and Privacy-Preserving Smart Contracts”, (2015), Retrieved from https://eprint.iacr.org/2015/675.pdf

[8] Intel, “Intel SGX”, https://software.intel.com/en-us/sgx

[9] Zyskind, G., Nathan, O., Pentland, A., “Enigma: Decentralized Computation Platform with Guaranteed Privacy”, (2015), Retrieved from https://enigma.co/enigma_full.pdf

[10] Town Crier, www.town-crier.org and Zhang, F., Cecchetti, E., Croman, K., Juels, A., Shi, E., “Town Crier: An Authenticated Data Feed for Smart Contracts”, (2016), Retrieved from https://eprint.iacr.org/2016/168.pdf

[11] Lind, J., Eyal, I., Pietzuch, P., Gün Sirer, E. “Teechan: Payment Channels Using Trusted Execution Environments”, (2016), Retrieved from https://arxiv.org/abs/1612.07766

[12] Olson, K., Bowman, M., Mitchell, J., Amundson, S., Middleton, D., Montgomery, C., “Sawtooth:An Introduction”, (2018), Retrieved from https://www.hyperledger.org/wp-content/Fuploads/Hyperledger_Sawtooth_WhitePaper.pdf

[13] Bitcoin, https://github.com/bitcoin/bitcoin

[14] Burrow, https://www.hyperledger.org/projects/hyperledger-burrow

[15] Cardano, https://cardanodocs.com/introduction/

[16] BigChain DB, https://docs.bigchaindb.com/en/latest/#

[17] Intel https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

[18] Intel Side-channel https://software.intel.com/en-us/side-channel-security-support

Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.