Ekiden — A Hardware Approach to Privacy-Maintaining Smart Contracts
Introduction
All of the current smart contract public blockchains suffer from limited transaction throughput and lack of privacy. For these reasons, many industries and investors (e.g., J.P.Morgan & Goldman Sachs) are shifting towards private chains, sacrificing the benefits of decentralization and global resource utilization of public chains. Although many current projects are focused on the scalability problem, very few of them are trying to solve the privacy concerns. For example, the Enigma Project is amongst the very few projects that are focusing on solving public-chain privacy using a software-based approach.
A new platform called Ekiden solves these major problems by a) decoupling smart contract execution from the underlying state consensus protocol to achieve scalability and b) using hardware support, in particular, Trusted Execution Environments (TEEs) to provide privacy to the execution layer. Ekiden demonstrates superior performance and privacy results in comparison to current smart contract blockchains (e.g. Ethereum).
The Ekiden project has received significant investor interest raising 45 million USD in a private presale. The team has deep roots in academia, i.e., Cornell, Berkeley, Urbana-Champaign, Illinois, and IC3. Their technical paper is quite involved and technical. Therefore, this blog post serves as a high-level summary of the main concepts and take away messages of this paper.
Technical Overview
Ekiden is a novel smart contract blockchain that targets two main goals 1) scalability and 2) confidentiality.
TEEs and Enclaves
Ekiden takes a hardware-based approach in achieving these goals. The core idea of their solution is to build a blockchain platform on top of Trusted Execution Environments (TEE). A TEE is a secure area of the main processor that ensures code and data confidentiality and integrity. It provides an isolated environment called an enclave that prevents anyone else (i.e., other applications, the operating system, even the host owner) from tampering with or eavesdropping on the state of any process running inside the enclave.
Now, this is an interesting premise. In general, there is a tradeoff between privacy and performance. Software solutions that achieve privacy on computations ranging from homomorphic encryption to secure multi-party computation (Enigma) introduce a computational overhead on performance that are usually impractical. Pushing the solution for the privacy problem deep down into the hardware level, omits much of this overhead and simplifies the design.
There is one take on this, and that is, one has to trust the hardware itself in complying with the promised integrity and confidentiality guarantees. However, in the long run, as long as there is a free market between the hardware-vendors and no monopoly, there will always be a competition between them and hence a highly probable compliance guarantee.
High-Level Design
Ekiden is building on top of a new hardware environment and therefore, they set off to revisit the entire design stack of their blockchain.
Modular Design: Ekiden proposes a modular design that separates the roles of the different entities that contribute to the blockchain. Modularity admits to specialization & performance, and most importantly to the practical modeling of a blockchain network, i.e, a set of heterogeneous actors rather than a simple homogeneous model. The system comprises three main actors with different roles:
- Clients: are the end users of smart contracts. They can deploy a new smart contract or trigger the execution of an existing one.
- Compute nodes: are the nodes that empower the actual execution engine of the smart contracts.
- Consensus nodes: are nodes that maintain the distributed storage append-only ledger.
Workflow: The Ekiden platform has a simple and modular workflow as depicted in the figure above.
- Contract creation: A client sends a new contract to the compute nodes (that host TEEs). The compute nodes securely process the smart contract; provide encryption keys that are special for the TEE only; and communicate with the consensus nodes to deploy it to the blockchain.
- Contract execution: A client triggers the execution of a smart contract by initially finding the contract info on the blockchain, including its associated encryption keys; uses these keys to encrypt its inputs; and then sends them back to the compute nodes. The compute nodes fetch the necessary info from the blockchain and process the clients request within the TEEs.
The main point here is that TEEs are independent entities that have their own encryption (public and private) keys. No one has the ability to extract the private key, not even the owner of this hardware.
Security Model
Assumption: The Ekiden platform presents a strong security guarantee that assumes a worst case scenario where all compute nodes are compromised except for one. This is a pretty strong security guarantee in comparison to the well known 51% attack for bitcoin which requires at least half of the miners to be honest.
Side channel attacks: Although Ekiden is secure against many attacks, it has one major downside. Side channel attacks can compromise the entire functionality and guarantees provided by Ekiden. Side channel attacks are attacks that try to infer additional information from the running hardware, e.g., power consumption, electromagnetic leaks, etc.
Protocol Design
The Ekiden platform has been built with several design decisions in mind:
Availability: Ekiden supports high availability. Meaning that if compute nodes fail (for whatever reason), another compute node can take over. TEEs are expendable and interchangeable dynamically allowing for contracts to run at all times. Certainly, Ekiden’s performance may be affected in the event of compute node failures since the task would need to be delegated to another compute node. However, availability will not be compromised.
Proof of Publication: Ekiden presents an efficient protocol called proof-of-publication that proves to a TEE that the smart contract information has been stored in the blockchain. This protocol strives to limit attackers from tricking honest TEEs into believing false information that may result in malicious smart contract execution.
App-level Leakage: Ekiden is not designed to protect data at contract-level interfaces. These are data leakages resulting from the application or contract design (E.g., a secret prediction model may be “extracted” via client queries). However, the authors propose a stateful approach that mitigates this leakage by securely maintaining any sensitive application state on-chain. Although this approach is valid and secure, the downside is that it assumes developer knowledge and responsibility which limits productivity and error prevention.
Key Management: Privacy is ensured by maintaining contract keys that are only known within trusted TEEs. However, to maintain availability, these keys need to be replicated across all compute nodes. Ekiden achieves this by coordinating encrypted contract keys via the blockchain. The current key management system utilized by Ekiden is weak and can be liable to various attacks. The Ekiden paper, however, acknowledges this fact and discuss future extensions to enhance these issues.
Programming Model
The Ekiden prototype is built with a programming interface for developers that do not require expertise in secure computing or SGX. This is a plus, as it frees the developer from the idiosyncrasies of the underlying system. Moreover, given the independent design of compute nodes from consensus nodes, Ekiden is also compatible with the various blockchain implementations.
Ekiden supports a general-purpose programming model. Moreover, in the paper Ekiden was ported to the Ethereum virtual machine, thereby supporting any contract written for the Ethereum platform. This is a big plus as it ensures backward compatibility and support for any ethereum smart contract. Compared to Ethereum, execution happens off-chain on Ekiden compute nodes, rather than on the Ethereum blockchain. However, they do not support calling contract functions from another contract.
Applications
The Ekiden paper presents a set of practical applications including Machine Learning contracts for credit scoring, non-linear least squares for thermal modeling, token contracts (ERC20), and games such as Cryptokitties and Poker.
- The Machine Learning applications demonstrate the privacy-preserving properties and confidentiality of Ekiden. For example, the machine learning contracts could run on the public chain without exposing their input data or output trained models.
- The non-linear least squares application runs on real-time streams of data coming from sensors. This application demonstrates the responsiveness of Ekiden under online interactive workloads.
- The ERC20 token contracts on the Ekiden platform demonstrates the privacy and anonymity of token balances that cannot be achieved on the Ethereum blockchain.
- Cryptokitties and poker represent games that require secrecy and unpredictability, being a perfect match for the Ekiden platform, i.e., privacy.
Evaluation
The paper evaluates the performance of the Ekiden platform on the aforementioned applications. Evaluation results demonstrate up to 600x greater throughput, 400x less latency and 1000x less monetary costs than existing smart contract platforms like Ethereum. However, one criticism about the evaluation section is that it is experimented on one compute node and 4 consensus nodes, which is far from a realistic evaluation.
The performance of public chains remains to be far slower in comparison to centralized solutions like Amazon EC2. i.e., 4–6 orders of magnitude slower, i.e., 10000–1000000x slower. In general, there will always be a performance penalty to be paid to run applications on a blockchain vs a centralized solution.
The Ekiden prototype presents several system-level optimizations including batching, caching, and write-ahead logging that improves performance, reduce network costs of synchronizing state with the blockchain. These are well known low-level system optimizations from other fields of computer science that the authors got inspired from and leveraged into Ekiden.
To sum up this article, we present some advantages of the new platform Ekiden and the potential challenges ahead.
Positive Potential
- This work widens the class of applications and computations that can run on public chains. Especially those that require confidentiality and privacy of their data which is a common requirement from industry and financial institutions. Such guarantees give more confidence to companies and investors to begin porting their infrastructures and technologies on smart contract environments if needed.
- The design choice of decoupling computation from the blockchain-state seems to be a promising direction that allows separation of concerns, modularity, and efficient independent execution.
Challenges
- Ekiden relies on TEE’s security. This is where all its privacy and confidential properties stem from. If this axiom falls, everything falls apart. In particular, the reliance on vendors to manufacture trusted hardware.
- Although Ekiden provides privacy guarantees, it is the developer’s responsibility, however, to ensure that no secret is revealed. This is problematic, as you can have the most trusted hardware in the world, but it won’t save you from poorly written software.
- EVMs are still 4–6x orders of magnitude slower than that of centralized ones (e.g., Amazon EC2) which raises the question of how many applications are open to sacrifice performance in favor of being decentralized.
