Source-linked AI summary
Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contract Execution
Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, Dawn Song
TL;DR
Smart contracts lack confidentiality and suffer poor performance because blockchain data is public and computation is constrained. Ekiden combines blockchains with TEE-backed execution, separating consensus from computation and systematically addressing hybrid-system pitfalls. It presents a confidentiality-preserving, scalable platform and demonstrates secure decentralized applications that compute on sensitive data.
Problem
Blockchain smart contracts lack confidentiality for sensitive data and have limited computational performance, while harmonizing TEEs with blockchains introduces subtle security pitfalls.
Method
Ekiden combines permissioned or permissionless blockchains with TEE-based execution, separates consensus from computation, and uses cryptographic ideal functionalities to analyze security.
Results
Ekiden provides a confidentiality-preserving platform for secure decentralized applications that compute on sensitive data.
Takeaways & Limitations
Ekiden demonstrates that blockchains and trusted enclaves have complementary security properties that can be combined into a generic platform for confidentiality-preserving smart contracts.
Abstract
from arXiv · showhide
Smart contracts are applications that execute on blockchains. Today they manage billions of dollars in value and motivate visionary plans for pervasive blockchain deployment. While smart contracts inherit the availability and other security assurances of blockchains, however, they are impeded by blockchains' lack of confidentiality and poor performance. We present Ekiden, a system that addresses these critical gaps by combining blockchains with Trusted Execution Environments (TEEs). Ekiden leverages a novel architecture that separates consensus from execution, enabling efficient TEE-backed confidentiality-preserving smart-contracts and high scalability. Our prototype (with Tendermint as the consensus layer) achieves example performance of 600x more throughput and 400x less latency at 1000x less cost than the Ethereum mainnet. Another contribution of this paper is that we systematically identify and treat the pitfalls arising from harmonizing TEEs and blockchains. Treated separately, both TEEs and blockchains provide powerful guarantees, but hybridized, though, they engender new attacks. For example, in naive designs, privacy in TEE-backed contracts can be jeopardized by forgery of blocks, a seemingly unrelated attack vector. We believe the insights learned from Ekiden will prove to be of broad importance in hybridized TEE-blockchain systems.
I. INTRODUCTION
Smart contracts provide strong integrity but inherit blockchains’ lack of confidentiality and limited performance. Ekiden combines blockchains with TEE-backed execution, separating consensus from computation while addressing hybrid-system pitfalls through formal modeling and protocol techniques.
- Motivation: Blockchains expose smart-contract data for public validation, preventing safe computation on sensitive information and limiting computational power, storage, and transaction throughput.These constraints threaten applications involving auction bids, financial transactions, and other sensitive data.
- Motivation: TEE-based approaches offer more performant, general-purpose confidential computation than zero-knowledge proofs or secure multiparty computation for the targeted use cases.The paper characterizes those alternatives as imposing significant overhead and supporting only limited, relatively simple computations.
- Hybrid-system challenges: Naively combining TEEs and blockchains introduces pitfalls including termination, conflicting state, rewinding attacks, and privacy compromise through forged blockchain views.A forged blockchain can rewind TEE execution and circumvent a privacy budget by enabling arbitrarily many queries.
- System design: Ekiden combines permissioned or permissionless blockchains with TEE execution and anchors its design in a cryptographic ideal functionality for rigorous security analysis.The system is presented as confidentiality-preserving and capable of thousands of transactions per second.
- System design: Ekiden separates consensus from execution: compute nodes process private data off chain in TEEs and attest to execution on chain, while consensus nodes maintain the blockchain.Consensus and compute nodes can scale independently, and consensus nodes need not use trusted hardware.
- System design: TEEs provide confidentiality, near-native performance, and trusted randomness, avoiding the computational burden and latency of on-chain execution.The design also supports cryptographic primitives such as functional encryption and black-box obfuscation.
- Security and robustness: Ekiden addresses TEE availability and network-security limitations through on-chain checkpointing, optional state storage, and mitigations for failures such as side-channel attacks.Under blockchain integrity, the stated guarantees cover liveness, persistence, confidentiality, and correctness without trusting contract creators, miners, or node operators.
- Security and robustness: The paper formalizes Ekiden’s security requirements as FEkiden and outlines a Universal Composability proof showing protocol equivalence under concurrent composition.It also systematically enumerates pitfalls of hybridized TEE-blockchain systems and gives general techniques intended to be principled, provably secure, and performant.
III. TECHNICAL CHALLENGES IN TEE-BLOCKCHAIN HYBRID SYSTEMS
TEE-blockchain hybrids must address availability, side channels, unreliable timers, confidentiality-preserving state persistence, and atomic delivery. Ekiden treats TEEs as replaceable while using blockchain mechanisms to reject stale or conflicting updates and coordinate state transitions.
- Availability failures: TEE failures can cause termination, state loss, or delayed execution, so hybrid systems must ensure crashed TEEs at most delay progress.Ekiden treats TEEs as expendable and interchangeable, storing persistent state on the blockchain.
- Side channels: Side-channel defenses remain application- and attack-specific, so Ekiden defers much of the protection against leakage to contract developers.The design instead limits compromise impact through spatial and temporal compartmentalization and a stronger key-manager threat model.
- Timer failures: TEE timers can be delayed or unavailable, requiring protocols to minimize timer reliance and have the blockchain reject updates based on stale input state.This avoids requiring a TEE to determine whether its blockchain view is current.
- Timer failures: Proofs of publication are needed to verify blockchain persistence, but missing trustworthy time enables old or forged subchains in proof-of-work systems.Ekiden introduces a time-based proof-of-publication protocol designed to withstand delayed clock reads.
- Key management in TEEs: Blockchain persistence protects state availability but exposes state unless encrypted, creating a further challenge of securely persisting encryption keys.Replicating keys across TEEs trades greater resilience to state loss against a larger attack surface.
- Atomicity: Atomic delivery is critical because separately delivering outputs and blockchain state updates permits rewind attacks and repeated grinding against randomized programs.Ekiden therefore requires the caller output and accepted state update to be delivered together.
IV. OVERVIEW OF EKIDEN
Ekiden combines clients, TEE-backed compute nodes, and blockchain consensus nodes to execute confidential stateful contracts while persisting encrypted state and validating attestations. Its execution-consensus separation avoids replicating every request across the entire blockchain network.
- Contract model: A contract computes an output and new state from a previous state and client input: (outp, stnew) := Contract(stold, inp).Contracts are deterministic stateful programs.
- Architecture: Ekiden combines trusted hardware and blockchain infrastructure to provide smart contracts with confidentiality, integrity, and availability guarantees.The architecture includes clients, compute nodes, and consensus nodes.
- Workflow: Clients submit secret inputs to compute nodes, which run contracts inside TEEs and generate attestations for state updates.Clients are intended to be lightweight, while compute nodes contribute liveness and scalability.
- Workflow: Consensus nodes maintain the append-only blockchain, persist contract state and attestations, and verify state updates using TEE attestations.A key-management committee supplies keys to contract TEEs.
- Workflow: During request execution, the TEE decrypts encrypted state and input, computes output and new encrypted state, and produces a correctness signature.An atomic delivery protocol reveals output only if consensus accepts the corresponding state update.
- Execution and consensus: Ekiden decouples request execution from consensus, executing requests only by selected compute nodes rather than replicating execution across all consensus nodes.In Ethereum, replicated execution renders network performance comparable to a single node.
D. Ekiden Security Goals
Ekiden targets correct, consistent, secret, and resilient contract execution under specified TEE and blockchain conditions. Its confidentiality guarantees degrade in a bounded way after certain computation-node breaches, while contract-level leakage remains outside its goals.
- Security goals: Ekiden requires contract state transitions to reflect correct execution of contract code on supplied state and inputs.
- Security goals: The blockchain must maintain a single sequence of state transitions consistent with each compute node’s view.
- Security goals: During periods without TEE breach, Ekiden keeps honest clients’ contract state and inputs secret from other parties and tolerates some key-manager TEE breaches.
- Security goals: After a computation-node confidentiality breach at time t, the attacker can access history only up to t − ∆, and the compromised TEE affects only a subset of contracts.
- Non-goals: Ekiden does not prevent contract-level leakage through public outputs, bugs, covert channels, or side channels, leaving developers responsible for avoiding such disclosures.
E. Assumptions and Threat Model
Ekiden assumes correctly implemented blockchain services, partially trusted TEE infrastructure, available participants, and adversaries able to control most compute-node environments and network behavior. Its proof-of-publication mechanism limits forged-block attacks by constraining publication time and required confirmations.
- TEE assumptions: Ekiden assumes TEE hardware is correctly implemented and securely manufactured, while allowing confidentiality compromise in a small fraction of TEEs.The impact depends on whether compromised devices are key-manager or computation nodes.
- Blockchain assumptions: The system is blockchain-agnostic but requires correct prescribed computation, continuous availability, attestation verification, and efficient proofs of blockchain-item inclusion.
- Threat model: The adversary may control operating systems and network stacks on all but one compute node, reorder or delay messages, observe global traffic, and corrupt any number of clients.Contracts themselves may still intentionally or accidentally leak secrets through their software.
- Proof of Publication: A proof of publication is an interactive proof between a contract TEE verifier and an untrusted prover that demonstrates timely publication in a sufficiently difficult subchain.
- Proof of Publication: The verifier uses a recent checkpoint and blockchain difficulty to validate candidate blocks, while a timer-based interval constrains the prover’s publication opportunity.The protocol is designed for permissionless blockchains and assumes relatively stationary difficulty in the simplified analysis.
- Proof of Publication: Higher slack reduces false rejection but increases false acceptance, while sufficiently many confirmations can make forged proofs negligible at the cost of longer honest waiting.
- Proof of Publication: With 25% hash power, nc = 80 and ϵ = 1.6 require an expected 2^112 hashes to forge a proof, while honest proofs are rejected with probability 2^-19.
- Proof of Publication: Once one TEE publishes successfully, other TEEs can obtain the proof through attested secure channels instead of repeating the protocol.
2) Desired properties:
Ekiden’s key-management design derives short-lived contract keys from distributed long-term secrets while isolating breaches through epochs and per-node privacy budgets. Its atomic-delivery protocol releases outputs only after the corresponding state update is published.
- Desired properties: The key-management requirements are confidentiality of the master key, availability of decryption keys, and forward secrecy for compromised short-term keys.Forward secrecy excludes decrypting messages encrypted before t − ∆ after compromise at time t.
- Key management committees and long-term keys: Long-term contract keys are generated by a key-management committee using DKG and secret-shared among committee members.The committee can be proactively rotated or dynamically expanded without changing the secret.
- Generating short-term keys: Short-term keys are derived per epoch from committee shares after a compute node authenticates and collects enough responses.A compute node reconstructs the epoch key from at least f + 1 committee outcomes.
- Breach isolation: Privacy breaches are contained by resetting per-node query counters with epoch advancement and refusing requests after a configured privacy budget is exhausted.This mechanism assumes contract TEEs have unforgeable host identities.
- Atomic delivery: Atomic delivery encrypts the client output first, publishes the state update after client acknowledgment, and releases the decryption key only after proof of publication.The protocol uses two messages: one for the caller and one for the blockchain.
- Atomic delivery: The atomic-delivery protocol ensures that a published state update eventually makes the output key available, while an unpublished update prevents key release.This follows from TEE verification of publication and key-manager availability.
VI. PROTOCOL DETAILS AND SECURITY PROOF
ProtEkiden combines idealized attested execution with an append-only blockchain whose validity rule verifies state continuity and TEE attestations. Contract creation and requests use encrypted state, authenticated inputs, and atomic output-state delivery.
- Formal specification: ProtEkiden UC-realizes the Ekiden ideal functionality using attested execution and a general-purpose blockchain functionality.The protocol also relies on digital signatures, symmetric encryption, and asymmetric encryption.
- Attested Execution: Attested execution signs the program and output with a hardware key, while the extended interface can leave a second output outside the attestation.A hash of the second output may be included in the attested output for separate verification.
- Blockchain: The blockchain functionality provides append-only storage, validity checks through a successor function, and an inclusion-query interface for clients.It abstracts away the inclusion of state updates in blocks while retaining append-only semantics.
- Blockchain: A valid state transition extends the latest state by matching its hash and carries a TEE attestation that verifies for the new state.This yields a single sequence of state transitions consistent with each party’s view.
- Contract creation: Contract creation generates a contract identifier, keys, encrypted initial state, and an attestation before submitting them to the blockchain.The client receives the identifier after the compute node obtains a blockchain receipt.
- Request execution: Request execution verifies authenticated encrypted input, decrypts the prior state and input inside a contract TEE, and runs the contract to produce a new state and output.The client and compute node then invoke the atomic-delivery protocol to deliver both results consistently.
- Request execution: The protocol encrypts the output and state-related data, publishes an attested state update, and releases the output decryption only after blockchain acceptance.The attestation binds the new state and output to the previous state and input, preventing compute-node tampering.
C. Security of ProtEkiden
ProtEkiden’s security theorem establishes UC realization under standard cryptographic assumptions, while the paper identifies application-interface leakage as an explicit protection boundary. The prototype supports a general-purpose programming model and EVM contracts, but not inter-contract calls.
- Security of ProtEkiden: Under EU-CMA, second-preimage resistance, and IND-CPA assumptions, ProtEkiden securely realizes FEkiden in the hybrid model for static adversaries.The theorem assumes secure attestation and digital signatures, a second-preimage-resistant hash, and secure encryption schemes.
- Mitigating app-level leakage: Ekiden does not protect data leakage at contract interfaces caused by contract design, including possible extraction of a secret model through client queries.Persistent counters and differential-privacy budgets are presented as approaches that require persistent state.
- Mitigating app-level leakage: Persistent application state can mitigate application-level privacy leakage by maintaining counters and privacy budgets securely on chain.Atomic delivery ensures the output is revealed only when this state is correctly updated.
- Security of ProtEkiden: A revocation mechanism can reduce reliance on the IAS after initialization by replacing later attestations with signatures under an enclave-generated key.The initial attestation binds the signing key to the TEE code.
- Implementation: The prototype comprises about 7.5k lines of Rust and includes a compiler that builds contracts into executables loadable by compute nodes.The compiler uses the Rust SGX SDK.
- Programming Model: Ekiden-BT extends Tendermint without changes to Tendermint, and the system supports contracts written for the Ethereum platform through an EVM port.The programming model requires deterministic contract methods that terminate in bounded time.
- Programming Model: The system does not support calling contract functions from another contract, which the paper leaves for future work.
B. Applications
Ekiden demonstrates applications spanning machine learning, thermal modeling, tokens, poker, CryptoKitties, and Origin, combining sensitive-data computation with contract portability. Its evaluation reports substantially lower latency and higher throughput than Ethereum for supported comparisons.
- Machine Learning Contracts: Ekiden implements credit-scoring and heart-disease contracts that train models on sensitive records with differential privacy.Noise is added centrally, improving accuracy and utility at the same privacy level compared with client-side noise addition.
- Smart Building Thermal Modeling: Ekiden runs thermal-modeling contracts that update shared temperature-prediction models from real-time smart-building sensor data.The deployed buildings sample temperature sensors every 20 seconds.
- Tokens: Ekiden supports ERC20 contracts through its EVM port and also provides a Rust token implementation with privacy and anonymity.The Rust implementation yields moderate performance improvement, while token balances are secret state.
- Poker: Ekiden’s poker contract persists state after each action, allowing secret cards to be revealed if a player aborts.This addresses the abort behavior of prior mental-poker implementations, where the game can terminate when a secret hand cannot be reconstructed.
- CryptoKitties: Ekiden executes CryptoKitties bytecode from Ethereum and reproduces real transactions, while supporting secrecy or unpredictability without source code.The example uses the ported EVM and verifies correct behavior against Ethereum transactions.
- Evaluation: Compared to an ERC20 contract on Ethereum mainnet, Ekiden-BT provides 600x greater throughput, 400x less latency, and 1000x less monetary cost.The evaluation covers Token, ERC20, CryptoKitties, Credit, and Thermal; machine-learning workloads would be cost-prohibitive on Ethereum.
D. Impact of Consensus on Throughput
Ekiden separates contract execution from blockchain agreement so compute nodes can proceed while consensus commits state asynchronously. This design supports performance across varied consensus commit latencies, while the paper identifies deployment and threat-model boundaries.
- Consensus-Layer Commit Time: Token transfers maintain good throughput across a wide range of consensus-layer commit latencies.The evaluation simulates slower consensus by injecting variable delays into writes to consensus nodes.
- Execution and Agreement: Cached compute-node state lets new transactions execute without waiting for consensus responses, while state is committed asynchronously in batches.Separating execution from agreement allows both layers to operate in parallel.
- System Architecture: Ekiden parallelizes contracts across compute nodes, unlike Ethereum’s sequential miner execution and single blockchain.The paper states that full cross-contract calls remain future work.
- Cost and Performance: Ekiden’s SGX-based machines perform token transfers in 2ms at roughly 10^-7 dollars per call, versus Ethereum’s $0.17 transfer cost.The same comparison reports CryptoKitties breeding at 100ms and roughly 10^-5 dollars per call on Ekiden.
- Security and Scope: Ekiden combines blockchains’ availability and persistence with trusted enclaves’ confidential computation, but its future work includes stronger protection for key management and compute-node coordination.The planned extension would leverage secure multiparty computation under a stronger threat model.
APPENDIX
Ekiden’s ideal functionality models contract creation, public storage, confidential execution, controlled leakage, and corruption of clients or executors.
- FEkiden defines Ekiden’s security goals as an ideal functionality for parties that create and interact with contracts.
- The functionality parameterizes permitted information leakage through a leakage function ℓ(·), including leakage from public storage reads.
- Contracts are user-provided programs associated with persistent storage containing contract code and state, and the storage is publicly readable.
- Contract queries return a secret output to the invoker and produce a secret transition to a new contract state, while access control may use the caller’s pseudonym.
- FEkiden allows arbitrary client corruption and corruption of up to all but one contract executor, with invalid enclave identifiers potentially causing aborts.
3) Contract TEE wrapper:
The contract TEE wrapper is specified as the mechanism connecting contract execution inside a trusted enclave to Ekiden’s protocol.
- The contract TEE wrapper is formally specified in Figure 9.
- The wrapper is presented as a named component of Ekiden’s confidentiality-preserving contract design.
B. Proof of Publication
The proof establishes that ProtEkiden realizes FEkiden through simulation and cryptographic hybrids, while performance optimizations preserve the same ideal functionality.
- ProtEkiden is proven to UC-realize FEkiden for leakage revealing only input length, implemented using IND-CPA encryption.
- The simulator emulates network traffic, Gatt, and the blockchain while obtaining required information from FEkiden.
- The proof uses hybrids that address forged attestations, second-preimage attacks, contract creation, and encryption of sensitive values.
- Signature verification rejects forged attestations except with negligible probability under the EU-CMA security of the signature scheme.
- The simulation maintains that FEkiden always holds the latest contract state, ensuring the final hybrid reflects ideal execution.
- Performance optimizations reduce blockchain round trips and storage requirements while preserving the same security interface, with improvements up to 200% for write-heavy workloads.
C. Extended Protocol
The extended protocol packages performance optimizations into a formal protocol using an enclave program as a subroutine.
- C. Extended Protocol: The extended protocol with performance optimizations is specified in Figure 11.
- C. Extended Protocol: The extended protocol uses the enclave program shown in Figure 12 as a subroutine.
- C. Extended Protocol: The protocol initializes client signing and encryption key pairs before processing contract-creation inputs.