Sie sind auf Seite 1von 26

Ekiden: A Platform for Confidentiality-Preserving, Trustworthy,

and Performant Smart Contract Execution


Raymond Cheng1 , Fan Zhang2 , Jernej Kos3 , Warren He1 , Nicholas Hynes1 , Noah Johnson1
Ari Juels4 , Andrew Miller5 , Dawn Song1
1 University of California, Berkeley, 2 Cornell University, 3 National University of Singapore
4 Cornell Tech, 5 University of Illinois, Urbana-Champaign, IC3
Abstract a range of industries, including finance, insurance, iden-
tity management, and supply chain management.
Smart contracts are applications that execute on
arXiv:1804.05141v1 [cs.CR] 14 Apr 2018

Smart contracts inherit some undesirable blockchain


blockchains. Today they manage billions of dollars
properties. To enable validation of state transitions during
in value and motivate visionary plans for pervasive
consensus, blockchain data is public. Existing smart con-
blockchain deployment. While smart contracts inherit the
tract systems thus lack confidentiality or privacy: They
availability and other security assurances of blockchains,
cannot safely store or compute on sensitive data (e.g., auc-
however, they are impeded by blockchains’ lack of confi-
tion bids, financial transactions). Blockchain consensus
dentiality and poor performance.
requirements also hamper smart contracts with poor per-
We present Ekiden, a system that addresses these criti- formance in terms of computational power, storage capac-
cal gaps by combining blockchains with Trusted Execu- ity, and transaction throughput. Ethereum, the most popu-
tion Environments (TEEs), such as Intel SGX. Capable lar decentralized smart contract platform, is used almost
of operating on any desired blockchain, Ekiden permits exclusively today for technically simple applications such
concurrent, off-chain execution of smart contracts within as tokens, and can incur costs vastly (eight orders of
TEE-backed compute nodes, yielding high performance, magnitude) more than ordinary cloud-computing environ-
low cost, and confidentiality for sensitive data. ments. In short, the application complexity of smart con-
Ekiden enforces a strong set of security and availabil- tracts today is highly constrained. Without critical perfor-
ity properties. By maintaining on-chain state, it achieves mance and confidentiality improvements, smart contracts
consistency, meaning a single authoritative sequence of may fail to deliver on their transformative promise.
state transitions, and availability, meaning contracts can Researchers have explored cryptographic solutions to
survive the failure of compute nodes. Ekiden is anchored these challenges, such as various zero-knowledge proof
in a formal security model expressed as an ideal function- systems [47] and secure multiparty computation [95].
ality. We prove the security of the corresponding imple- These approaches, though, are practical only for niche
mented protocol in the UC framework. smart contract and cryptocurrency applications. A more
Our implementation of Ekiden supports contract de- performant and general-purpose option is trusted hard-
velopment in Rust and the Ethereum Virtual Machine ware, such as Intel Software Guard eXtensions (SGX).
(EVM). We present experiments for applications includ- SGX provides a trusted execution environment (TEE)
ing machine learning models, poker, and cryptocurrency known as an enclave. It prevents other applications, the
tokens. Ekiden is designed to support multiple underly- operating system, and the host owner from tampering
ing blockchains. When building on top of Tendermint for with or even learning the state of protected applications.
consensus, we obtain example performance of 600x more It thereby provides strong confidentiality for smart con-
throughput and 400x less latency at 1000x less cost than tract data that blockchains cannot. Unfortunately, SGX
on the Ethereum mainnet. When used with Ethereum as cannot guarantee availability or provide secure network-
the backing blockchain, Ekiden still costs less than on- ing or persistent storage. Thus, it cannot alone achieve
chain execution and supports contract confidentiality. blockchains’ authoritative transaction ordering, persistent
record keeping, or resilience to network attacks.
In this paper, we show that blockchains and trusted
1 Introduction hardware have complementary properties that can be
combined to improve both security and performance of
Smart contracts are protocols that digitally enforce agree-
smart contracts and enable novel and diverse applications.
ments between or among parties. Typically executing on
blockchains, they enforce trust through strong integrity
assurance: Even the creator of a smart contract cannot fea- Ekiden. We present Ekiden, a system for highly per-
sibly modify its code or subvert its execution. Smart con- formant and confidentiality-preserving smart contract ex-
tracts have been proposed to improve applications across ecution. To the best of our knowledge, Ekiden is the

1
first confidentiality-preserving smart contract system that specify two protocol variations, a simple baseline and
can perform thousands of transactions per second. The an optimization, to realize this functionality. We out-
key to this achievement is the effective combination of line a security proof in the Universal Composability
blockchains and trusted hardware. Ekiden combines any (UC) framework that shows that the Ekiden protocol
desired underlying blockchain system (permissioned or matches FEkiden under concurrent composition.
permissionless) with TEE-based execution. Anchored in • Strong security properties: Ekiden’s security model
a formal security model that is expressed as a crypto- and implementation realize strong notions of consis-
graphic ideal functionality [19], its principled design sup- tency (authoritative sequencing of concurrent transac-
ports rigorous analysis of its security properties. tion requests) and atomicity (all-or-nothing state check-
Ekiden relies on compute nodes that use trusted hard- pointing and delivery of messages to clients). Ensuring
ware to perform smart contract computation over private these properties in an asynchronous network is a chal-
data off chain, then attest to their correct execution on lenge that we overcome by using the blockchain to
chain. The underlying blockchain is maintained by con- checkpoint state and conditioning enclave communica-
sensus nodes, which need not use trusted hardware. Eki- tion on valid blockchain updates in an atomic delivery
den is agnostic to consensus-layer mechanics, only requir- protocol. Ekiden thus requires enclaves to have a fresh,
ing that the blockchain is capable of validating remote correct view of the blockchain, despite SGX’s lack of
attestations from compute nodes. Ekiden can thus scale trusted time. We address this additional challenge with
consensus and compute nodes independently according a novel proof of publication protocol that requires only
to performance and security needs. SGX’s partially trustworthy relative timer. Ekiden also
By operating compute nodes with SGX enclaves, Eki- leverages enclave isolation to achieve contract confi-
den imposes minimal performance overhead relative to dentiality in a model of black-box execution.
an ordinary (e.g., cloud) computing environment. In this • High availability: SGX hosts and thus enclaves may
way, we avoid the computational burden and latency of crash or lose network connectivity, posing the risk and
on-chain execution. Enclave-based computation in Eki- challenge of lost and/or conflicting state. Ekiden treats
den provides confidentiality, enabling efficient use of enclaves as expendable and interchangeable: Should
powerful cryptographic primitives that SGX is known to one enclave be lost, failover to any other live enclave is
emulate, such as functional encryption [36] and black- possible. Ensuring such availability involves a strategy
box obfuscation [67], and also provides a trustworthy of enclave key management and blockchain key and
source of randomness, a major acknowledged difficulty state checkpointing, supported by Ekiden’s atomicity
in blockchain systems [18]. to ensure consistency during failovers.
To address the availability and network security limi- • Performance: Ekiden includes several performance op-
tations of SGX, Ekiden supports on-chain checkpointing timizations that minimize use of the blockchain, which
and (optional) storage of contract state. Ekiden thereby is a bottleneck. Our optimizations do not degrade se-
supports safe interaction among long-lived smart con- curity: We show that they realize the same FEkiden
tracts across different trust domains. To address potential functionality as the unoptimized protocol. We evaluate
TEE failures, such as side channel attacks, we propose their individual and cumulative impact, showing speed,
mitigations to preserve integrity and limit data leakage throughput, and on-chain storage 2–4 orders of magni-
(Section 4.1). Assuming blockchain integrity, users need tude better than baseline on-chain Ethereum execution.
not trust smart contract creators, miners, node operators Evaluation. We evaluate the performance of Ekiden on a
or any other entity for liveness, persistence, confidential- suite of applications selected to exercise the full range of
ity, or correctness. Ekiden thus enables self-sustaining system resources and demonstrate how Ekiden enables
services that can outlive any single node, user, or devel- application deployment that would otherwise be impracti-
opment effort.1 cal due to privacy and/or performance concerns. They
include a machine learning framework, credit-scoring
Technical challenges and contributions. Our work on application, a smart building thermal model, a medical
Ekiden addresses several key technical challenges: diagnosis application, and a poker game. We also port
an Ethereum Virtual Machine implementation to Eki-
• Formal security modeling: While intuitively clear, the
den, so that existing contracts (e.g., written in Solidity),
desired and achievable security properties required for
such as Cryptokitties [1] and the ERC20 token, can run
Ekiden are challenging to define formally. We express
in our framework as well. We report on development
the full range of security requirements of Ekiden in
effort, showing that the programming model in Ekiden
terms of an ideal functionality FEkiden . We formally
lends itself to simple and intuitive application develop-
1 Our system name Ekiden refers to this property. “Ekiden” is a ment. Contracts in Ekiden process transactions 2–3 or-
Japanese term for a long-distance relay running race. ders of magnitude both faster and higher throughput over

2
Ethereum. Our performance optimizations also greatly space. When data from a TEE moves off the processor to
compress the amount of data stored on the blockchain, DRAM, it is transparently encrypted with keys only avail-
yielding a 2–4 order of magnitude improvement over the able to the processor. Thus the operating system, hypervi-
baseline. (The advantage is greater for read-write opera- sor, and other users cannot access the enclave’s memory.
tions on contracts with large state, such as our token con- The SGX memory encryption engine also guarantees data
tract.) Furthermore, Ekiden decouples computation from integrity and prevents memory replay attacks [38]. Intel
the blockchain and shards contracts, which allows the sys- SGX supports attested execution, i.e., it is able to prove
tem to scale horizontally. In contrast, all transactions for the correct execution of a program, by issuing a remote
all contracts must be serialized on a single blockchain in attestation, a digital signature, using a private key known
Ethereum. only to the hardware, over the program and an execution
output. Remote attestation also allows remote users to
establish encrypted and authenticated channels to an en-
2 Background clave [8].
Attested execution realized by trusted hardware is im-
2.1 Smart Contracts and Blockchain perfect, however. For example, SGX alone cannot guaran-
Blockchain-based smart contracts are programs executed tee availability. A malicious host can terminate enclaves
by a network of participants who reach agreement on the or drop messages arbitrarily. Even an honest host could
programs’ state. Existing smart contract systems replicate accidentally lose enclave state in the event of a power cy-
data and computation on all nodes in the system. Each cle. The weak availability of SGX poses a fundamental
node can thus individually verify correct execution of the challenge to the design of Ekiden. Furthermore, recent
contract. Full replication on all nodes provides a high attacks on Intel SGX have shown that current implemen-
level of fault tolerance and availability. Smart contract tations of TEEs often leak information through side chan-
systems such as Ethereum [33] and NEO [5] have demon- nels [69, 92]. Ekiden is compatible with existing TEE
strated their utility across a range of applications. defenses [16, 57, 67, 71, 88]. In future work we plan to
However, several critical limitations impede wider extend Ekiden to maintain its security guarantees under
adoption of current smart contract systems. First, on- a stronger threat model, where individual enclaves can
chain computation of fully replicated smart contracts is be compromised without affecting service integrity. Eki-
inherently expensive. For example in August 2017, it cost den can be extended with other secure computation tech-
$26.55 to add 2 numbers together one million times in an niques, such as secure multi-party computation [9,23,56].
Ethereum smart contract [33], a cost roughly 8 orders
of magnitude higher than in AWS EC2 [74]. Further- 3 Overview of Ekiden
more, current systems offer no privacy guarantees. Users
are identified by pseudonyms. As numerous studies have In this section, we provide an overview of the design and
shown [62, 66, 72, 73], pseudonymity provides only weak security properties of Ekiden. We begin with a motivat-
privacy protection. Moreover, contract state and user in- ing example, highlighting the challenge met by existing
put must be public in order for miners to verify correct systems. Then we present the high-level architecture, the
computation. Lack of privacy fundamentally restricts the workflow, and the security goals of Ekiden. Finally, we
scope of applications of smart contracts. state the threat model and assumptions.

2.2 Trusted Hardware with Attestation 3.1 Motivation


A key building block of Ekiden is a Trusted Execution As an example to motivate our work, consider a credit
Environment (TEE) that protects the confidentiality and scoring application—an example we implement and re-
integrity of computations, and can issue proofs, known port on in Section 6.1. Credit scores are widely used by
as attestations, of computation correctness. Ekiden is im- lenders, insurers, and others to evaluate the creditworthi-
plemented with Intel SGX [8, 40, 61], a specific provider ness of consumers [6]. Despite its considerable revenue
of TEEs, but we emphasize that it may use any compara- ($10.8B in 2017 [42]), the credit reporting industry in
ble TEE with attestation capabilities. We now offer brief the U.S. is concentrated among a handful of credit bu-
background on TEEs, with a focus on Intel SGX. reaus [42]. Such centralization creates large single points
Intel SGX provides a CPU-based implementation of of failure and other problems, as highlighted by a recent
TEEs—known as enclaves in SGX—for general-purpose data breach affecting nearly half the US population [15].
computation. A host can instantiate multiple TEEs, which Blockchain-based decentralized credit scoring is thus
are not only isolated from each other, but also from the an attractive and popular alternative. Bloom [54], for ex-
host. Code running inside a TEE has a protected address ample, is a startup offering a credit scoring system on

3
three types of entities in Ekiden: Clients, compute nodes
Clients and consensus nodes.
(1) inp (5’b) outp • Clients are end users of smart contracts. In Ekiden, a
Zoomed-in view of a
Compute Node i Compute Node j client can create contracts or execute an existing con-
Compute
Contract TEE (3) Get k Key Manager
<latexit sha1_base64="N/i1wvfVzYTA02VzvnCuXJ3vKkE=">AAACBnicbVDLSgMxFM34rPVVdSlIsBRclRk36sqCmy5bcGyxHUomzbShmWRIMkIdunTh3q3+giuxS7/AvX8g+BNmpl3U1gOBwzn3cXL9iFGlbfvLWlpeWV1bz23kN7e2d3YLe/s3SsQSExcLJmTTR4owyomrqWakGUmCQp+Rhj+4Sv3GHZGKCn6thxHxQtTjNKAYaSPdtkOk+ypIBqNOoWiX7QxwkThTUrz8HNd/Ho7GtU7hu90VOA4J15ghpVqOHWkvQVJTzMgo344ViRAeoB5pGcpRSJSXZIlHsGSULgyENI9rmKmzHQkKlRqGvqnMEs57qfif14p1cO4llEexJhxPFgUxg1rA9PuwSyXBmg0NQVhSkxXiPpIIa3OkfGl2TTo8QvciPY0zf4hF4p6WL8p23S5WqmCCHDgEx+AEOOAMVEAV1IALMODgCTyDF+vRerXerPdJ6ZI17TkAf2B9/AKTx57L</latexit>
<latexit sha1_base64="2XkW6LkDmee5tVMXCd0WPlqRmQY=">AAACBnicbVC7TsMwFL3hWcqrwMhiUVViqhIWYKISS8eCCK1oo8pxndaq40S2g1SifgA7K/wCE4KRL2DnD/gMnLRDaTmSpaNz7uP4+jFnStv2t7W0vLK6tl7YKG5ube/slvb2b1WUSEJdEvFItnysKGeCupppTluxpDj0OW36w8vMb95TqVgkbvQopl6I+4IFjGBtpLtOiPVABelw3C2V7aqdAy0SZ0rKF18f12DQ6JZ+Or2IJCEVmnCsVNuxY+2lWGpGOB0XO4miMSZD3KdtQwUOqfLSPPEYVYzSQ0EkzRMa5epsR4pDpUahbyrzhPNeJv7ntRMdnHkpE3GiqSCTRUHCkY5Q9n3UY5ISzUeGYCKZyYrIAEtMtDlSsTK7Jhse44coO40zf4hF4p5Uz6v2lV2u1WGCAhzCERyDA6dQgzo0wAUCAp7gGV6sR+vVerPeJ6VL1rTnAP7A+vwFWiOchg==</latexit>

TEE
tract with her secret input. In either case, clients dele-
(4) exec
Nodes gate computation to compute nodes (discussed below).
(5’a) Store (2) Get We expect clients to be lightweight, allowing both mo-
(Enck (statenew ),
<latexit sha1_base64="KLKZS9rOJszbhYUtSf8G9pcNJB8=">AAACMnicbVDLattAFB3lHTdJ3TS7bESNwYZg5FJouwsUUy9diGODZcTV+MoePBqJmau0jtCP5COyyz7b5A9KV6GbLvoRGT8WadIDA4dz7mPuCVMpDHneT2dtfWNza3tnt/Rqb//gdfnN4blJMs2xyxOZ6H4IBqVQ2CVBEvupRohDib1w+mXu9y5QG5GoM5qlOIxhrEQkOJCVgvKHmh8DTUyUtxQPpjVDQBj4hD8oV/i9qBcnvhHjGFbaWatV1INyxWt4C7gvSXNFKqe1y4ev10d5Jyj/8UcJz2JUxCUYM2h6KQ1z0CS4xKLkZwZT4FMY48BSBTGaYb64rnCrVhm5UaLtU+Qu1KcdOcTGzOLQVi5Oee7Nxf95g4yiT8NcqDQjVHy5KMqkS4k7j8odCY2c5MwS4FrYv7p8Aho42UBL1adr5sNTuEwKG03zeRAvSfd943PD+2YjarMldtgxe8dqrMk+slPWZh3WZZxdsVt2x+6dG+eX8+D8XpauOauet+wfOH8fAQAOr3Q=</latexit>
sha1_base64="juaLG4TGlXt9PzyL3I7m/yuJhp8=">AAACMnicbVBNSxtRFL2jrdq0tbFddjMoQoQSJlJQdwEJuFQwKmTCcOflTnzkzZvhvTtqMswf8X9077b9B8WVdNOFP8KXj4XVHnhwOOd+vHviXEnLQfDbW1p+83Zlde1d7f2Hj+uf6hufz2xWGEFdkanMXMRoSUlNXZas6CI3hGms6DweHU798ysyVmb6lMc59VMcaplIgeykqP69EabIlzYpO1pEo4ZlZIpCphsuNV1XO9W30MphigvttNOpdqL6VtAMZvBfk9aCbLUbk4c2ABxH9b/hIBNFSpqFQmt7rSDnfomGpVBU1cLCUo5ihEPqOaoxJdsvZ9dV/rZTBn6SGfc0+zP1eUeJqbXjNHaVs1NeelPxf16v4GS/X0qdF0xazBclhfI586dR+QNpSLAaO4LCSPdXX1yiQcEu0Nr28zXT4TlOsspF03oZxGvS3W0eNIMTF9ERzLEGX2ETGtCCPWjDERxDFwTcwh38hF/eD+/ee/D+zEuXvEXPF/gH3uMTNEOuMA==</latexit>
TEE ) Enck (stateprev )
<latexit sha1_base64="SmFDLoEd0RmiG7NjKjvH+8Qja5s=">AAACH3icbVDLSsNAFJ3UV62vqks3USkoQkkFUXcFKXapYK3QljCZ3rRDJ5MwcyPW0LX/4d6t/oIrcesfuBP8AidtF9p6YOBwzn3N8SLBNTrOh5WZmZ2bX8gu5paWV1bX8usb1zqMFYMaC0WobjyqQXAJNeQo4CZSQANPQN3rnaV+/RaU5qG8wn4ErYB2JPc5o2gkN7/dDCh2tZ9UJHN7exopgttEuMPEzLkd7A/c/K5TdIawp0lpTHbLB9/nlZOvows3/9lshywOQCITVOtGyYmwlVCFnAkY5JqxhoiyHu1Aw1BJA9CtZPiVgV0wStv2Q2WeRHuo/u5IaKB1P/BM5fDwSS8V//MaMfonrYTLKEaQbLTIj4WNoZ3mYre5AoaibwhliptbbdalijI06eUKv9ekwyN6H6bRlCaDmCa1w+Jp0bk0EVXJCFmyRXbIHimRY1ImVXJBaoSRB/JEnsmL9Wi9Wm/W+6g0Y417NskfWB8/Ju+n5w==</latexit>
sha1_base64="+0AUWAL90kUSKsk5TDK8eRSpa0I=">AAACH3icbVDLSsNAFL3xbX1VXbqJSqEilNSNuiuI6FLBqtCWMJnetEMnkzBzU6yha//DvVv9BVfi1j9w7Rc4aV34OjBwOOe+5gSJFIY8782ZmJyanpmdmy8sLC4trxRX1y5NnGqOdR7LWF8HzKAUCuskSOJ1opFFgcSroHeU+1d91EbE6oIGCbYi1lEiFJyRlfziZjNi1DVhdqy43ysbYoR+k/CGMjunP9wZ+sVtr+KN4P4l1S+yXdv9OKkBwJlffG+2Y55GqIhLZkyj6iXUypgmwSUOC83UYMJ4j3WwYaliEZpWNvrK0C1Zpe2GsbZPkTtSv3dkLDJmEAW2cnT4by8X//MaKYUHrUyoJCVUfLwoTKVLsZvn4raFRk5yYAnjWthbXd5lmnGy6RVK39fkwxN2G+fRVH8H8ZfU9yqHFe/cRnQKY8zBBmxBGaqwDzU4hTOoA4c7eIBHeHLunWfnxXkdl044Xz3r8APO2ycyOaaG</latexit>
bile and web applications to interact with contracts.
• Compute nodes instantiate multiple TEEs to run con-
Consensus
tract programs. They also instantiate a service called
Nodes Append-only ledger a key manager in a TEE. Compute nodes process re-
quests from clients by running the contract in a contract
TEE and generating attestations proving the correct-
Figure 1: Overview of Ekiden architecture and workflow. ness of state updates. Anyone with a TEE-enabled plat-
Clients send inputs to confidentiality-preserving smart contracts, form can participate as a compute node, contributing
which are executed within a TEE at any compute node. The to the liveness and scalability of the system. Compute
blockchain stores encrypted contract state. See Section 3.2 for nodes also perform key management for contracts in
details. the key manager. Upon requested by the contract TEE,
a key manager TEE creates or retrieves existing keys,
Ethereum. Their scheme, however, only supports a static as needed. We defer details of key management to Sec-
credit scoring algorithm that omits important private data tion 4.5. The key manager TEEs synchronize their state
and cannot support predictive modeling. Such applica- via the blockchain.
tions are bedeviled by two critical limitations of current • Consensus nodes maintain a distributed append-only
smart contract systems: (1) A lack of data confidentiality ledger, i.e. a blockchain, by running a consensus pro-
needed to protect sensitive consumer records (e.g., loan- tocol. Contract state and attestations are persisted on
service history for credit scoring) and the proprietary pre- this blockchain. Consensus nodes are responsible for
diction models derived from them and (2) A failure to checking the validity of state updates using TEE attes-
achieve the high performance needed to handle global tations, as we discuss below.
workloads.
To support large-scale, privacy-sensitive applications Workflow. We now sketch the contract creation and re-
like credit scoring, it is essential to meet these two re- quest execution workflow, providing further details on
quirements while preserving the integrity and availability Figure 1. The detailed formal protocol is presented in
offered by blockchains—all without requiring a trusted Section 5.2.
third party. Ekiden offers a confidential, trustworthy, and For simplicity, we assume a client has a priority list
performant platform that achieves precisely this goal for of compute nodes to use. In Appendix C, we describe a
smart contract execution. coordinator that facilitates compute node discovery and
load balancing. We denote a client as P and a compute
3.2 Ekiden Overview node as Comp.
Conceptually, Ekiden realizes a secure execution environ-
ment for rich user-defined smart contracts. An Ekiden Contract creation. When creating a contract, P sends
contract is a deterministic stateful program. Without loss a piece of contract code Contract to Comp. Comp loads
of generality, we assume contract programs take form Contract into a TEE (called contract TEE hereafter), and
of (outp, stnew ) := Contract(stprev , inp). A contract pro- starts the initialization. The contract TEE creates a fresh
gram takes as input a previous state stprev and a client’s contract id cid, obtains fresh (pkin in state
cid , skcid ) pair and kcid
input inp, and generates an output outp and new state from the key manager TEE and generates an encrypted
stnew . initial state Enc(kstate
cid , 0) and an attestation σTEE , prov-
~
Once deployed on Ekiden, smart contracts are en- ing the correctness of initialization and that pkin cid is the
dowed with strong confidentiality, integrity and availabil- corresponding public key for contract cid. Finally, Comp
ity guarantee. Ekiden achieves these properties with a obtains a proof of the correctness of σTEE by contacting
hybrid architecture combining trusted hardware and the the attestation service (detailed below); this proof and
blockchain. σTEE are bundled into a “certified” attestation π. Comp
Figure 1 depicts the architecture of Ekiden and a work- then sends (Contract, pkin state ~
cid , Enc(kcid , 0), π) to consen-
flow of Ekiden smart contracts. As it shows, there are sus nodes. The full protocol for contract creation is spec-

4
ified in the “create” call of ProtEkiden (Fig. 4). Consen- Agnostic to the specifics of contract execution, consen-
sus nodes verify π before accepting Contract, the en- sus nodes only need to verify π generated by TEEs. In
crypted initial state, and pkin
cid as valid and placing it on our implementation, Comp obtains π from the Intel At-
the blockchain. testation Service (IAS) [43]. As an SGX attestation is a
group signature, its verification is facilitated by the IAS
acting as group manager. To verify the correctness of an
Request execution. The steps of request execution il- attestation σTEE , Comp first sends σTEE to IAS, which
lustrated in Fig. 1 are as follows: replies with a “certified” attestation π := (b, σTEE , σIAS ),
(1) To initiate the process of executing a contract cid where b ∈ {0, 1} indicates the validity of σTEE and σIAS
with input inp, P first obtains pkin cid associated with is a signature over b and σTEE by IAS. As π is just a
the contract cid from the blockchain, computes signature, consensus nodes need neither trusted hardware
inpct = Enc(pkin cid , inp) and sends to Comp a message nor to contact the IAS to verify it.
(cid, inpct ), as specified in Line 8-11 of ProtEkiden .
(2) Each contract is also associated with a secret state Preventing replay attacks. When the output of a con-
key kstate
cid that is only known to the contract and key tract call has value, the system must prevent an adver-
manager. When executing a contract, Comp retrieves sary in control of a TEE host from conducting replay
the contract code and stct := Enc(kstate cid , stprev ), the attacks, where a malicious compute node allows a mali-
encrypted previous state of contract cid, from the cious client to repeatedly execute queries on a prior state
blockchain, and loads stct and inpct into a TEE and snapshot. For example, an attacker could try to repeatedly
starts the execution, as specified in Line 30-33 of query a credit scoring contract that implements differen-
ProtEkiden . tial privacy, in order to exhaust the privacy budget and
(3-4) From the key manager TEE, the contract TEE obtains leak information about user data. Ekiden’s atomic deliv-
in
kstate
cid and skcid , with which it decrypts stct and inpct ery protocol ensures that clients only see the output of a
and executes, generating an output outp, a new en- contract call after the system can prove that the state has
crypted state st0ct := Enc(kstate cid , stnew ), and an signa- been successfully written to the blockchain (Section 4.3).
ture π proving correct computation, as specified in Atomic delivery enables the contract to impose query lim-
Line 7-13 of the TEE Wrapper (Fig. 5). Key manage- its and transaction fees on queries to the smart contract.
ment is discussed in Section 4.5.
(5a, 5b) Finally, Comp and P conduct an atomic delivery pro-
tocol which delivers outp to P and (st0ct , π) to the 3.3 Ekiden Security Goals
consensus nodes. We defer the detail of atomic de-
We formally characterize the security goals of Ekiden
livery to Section 4.3. Briefly, Step 5a and Step 5b in
in Section 5. Some security properties, however, are im-
Fig. 1 are executed atomically, i.e. outp is revealed
plied by but not explicit in the formal model. Here we
to P if and only if (st0ct , π) is accepted by consensus
call them out explicitly in order to clarify protocol design
nodes. Consensus nodes verify π before accepting the
considerations in Ekiden. Briefly, Ekiden aims to support
new state as valid and placing it on the blockchain.
execution of general-purpose contracts while enforcing
the following security properties:
Concurrency. By design, Ekiden compute nodes re-
ceive inputs and generate state updates concurrently. Correct execution: Ekiden ensures that contract state
Thus, race conditions are possible, but handled by the con- transitions reflect correct execution of contract code on
sensus layer. If two compute nodes concurrently update previous state with current inputs.
the same state, only one will be accepted by the consensus
layer. The rejected compute node will notify the client to
retry. Secret state: Ekiden guarantees that contract state and
inputs from honest clients are kept secret from all other
parties. Contracts explicitly specify their secret state,
Decoupling consensus from computation. In contrast which will automatically be encrypted with keys known
to Ethereum, where contract execution is replicated by only to enclave applications. Part of the contract state can
all nodes in the blockchain to reach consensus, Ekiden also be marked public, in which case it is stored unen-
decouples consensus from contract execution. For every crypted on the blockchain with only integrity guarantees.
client request, the contract only needs to be executed by We emphasize that Ekiden does not protect confidential-
K compute nodes for some small K, a security parameter ity at contract interfaces, thus application developers are
(e.g. in Figure 1, we set K = 1, which may be a reasonable responsible for ensuring that no secret is revealed through
choice in practice). public output, and that the contract is free of side channels.

5
We discuss defense against side-channels and application- tions. We further assume the blockchain provides an ef-
level leakage in Section 4.4. ficient way to construct proofs of item inclusion on the
blockchain, i.e., proofs of publication. This is similar to
Fault-tolerance: Ekiden is resilient to network adver- the bulletin board model of blockchain used in [23].
sary model and compute node failures. In general, the In a permissioned blockchain, such proof can simply
system can make progress if at least one of the compute be a multisig signed by a majority of the consensus nodes.
nodes is available. We discuss our threat model in Sec- In permissionless blockchains, especially proof-of-work
tion 3.4 and tolerance to compute node failure and cor- based ones, however, only a weaker notion of security can
ruption in Section 4.1. be achieved, as acknowledged in [23]. We discuss our
strategy that confines the impact of potential blockchain
Consistency: Ekiden guarantees that at any time, the synchronization failure in Section 4.1.
blockchain stores a single sequence of state transi-
tions consistent with the view of each compute node.
We rely on the consensus layer, i.e., blockchain, to en-
sure correct state transitions. Specifically, recall that Shared-key bootstrapping: The Ekiden protocol in-
contract programs take the form of (outp, stnew ) := volves establishing a shared master secret among all TEEs
Contract(stprev , inp). Each attestation generated by com- running the Ekiden program. The master secret is initially
pute nodes attests to the correct state transition from generated at a single TEE, but propagates to the rest in
stprev to stnew . While verifying attestations, consensus a peer-to-peer network. We thus assume that each new
nodes also check that stprev is the latest state stored on node can communicate at least once with an existing boot-
the blockchain, rejecting the attestation otherwise. strapped node to obtain the master secret. We discuss a
key management protocol in detail in Section 4.5. We
Atomic and isolated transactions: Ekiden ensures leave the exploration of other key management schemes,
that concurrent client requests to the compute node are e.g., multiple master keys and secret-sharing schemes, for
processed sequentially and in isolation. Furthermore, future work.
transactions are atomic, providing all-or-nothing deliv-
ery of messages to clients and on-chain checkpointing
of state transitions, even in the presence of a malicious
network or host. Threat Model: All parties in the system must trust Eki-
den and TEE.We assume a strong adversary that can cor-
rupt up to all but one compute nodes and any number
3.4 Threat Model and Assumptions of clients. By corrupting a compute node, the adversary
We present a formal adversarial model in Section 5. In- gains full control of the operating system and the net-
formally, however, we assume the following: work stack of the host, and thus can reorder messages and
schedule processes arbitrarily. We assume the attacker
cannot corrupt TEEs. A corrupted party reveals her entire
Hardware Assumptions: We assume that hardware
internal state to the adversary and may deviate arbitrarily
providing TEE is correctly implemented and securely
from the protocol.
manufactured. Recent work shows that the confiden-
tiality of SGX enclaves can be compromised via side- Clients need not execute contracts themselves and do
channels [53, 91]. In light of this potential threat, we not require trusted hardware. We assume clients trust their
discuss various mechanisms to tolerate compromised en- own code and platform, but do not trust other clients. Each
claves in Section 4.1. contract has an explicit policy dictating how data is pro-
cessed and requests are serviced. Ekiden does not (and
Blockchain Assumptions: Ekiden is designed to be ag- cannot reasonably) prevent contracts from leaking secrets
nostic to the underlying consensus protocol used by the intentionally or unintentionally through software bugs.
blockchain. It can be deployed atop any blockchain imple- The adversary observes global network traffic and may
mentation as long as the requirements specified below are reorder and delay messages arbitrarily. If a compute node
met. Informally, we model a blockchain as a distributed times out when processing a client request, the client
append-only ledger that is trusted for integrity and avail- needs to resubmit the request to another (possibly ran-
ability, but not for privacy. domly chosen) compute node. The adversary could also
We assume the blockchain will perform prescribed censor messages selectively. In Section 4.3, we discuss
computation correctly and is always available. In partic- the atomic delivery protocol that ensures both output and
ular, Ekiden relies on consensus nodes to verify attesta- state update are delivered atomically.

6
4 Protocol Design Appendix B, we prove that security holds even if enclaves
cannot obtain latest states. Second, to establish proofs of
Before diving into the details of the Ekiden protocol, we publication in a permissionless blockchain, we design a
first describe the technical challenges involved in com- time-based protocol that is secure even the enclave timer
bining TEEs and blockchains to realize Ekiden’s security is delayed, as explained below in Section 4.2.
goals and the building blocks we use to address them. In
Section 5 we formally specify the Ekiden protocol com- Side channels. Although trusted hardware aims to pro-
bining these building blocks. tect confidentiality for TEE, recent work has uncovered
data leakage via side-channel attacks [17, 37, 39, 45, 52,
4.1 Tolerating TEE failures 53, 65, 69, 78, 90, 92]. Existing defenses [22, 24, 50, 57, 71,
79–81, 83] are generally application and attack-specific
Availability failures. Trusted hardware in general can- (e.g., crypto libraries avoid certain data-dependent oper-
not ensure availability. In the case of SGX, a malicious ations [16]); and generalizing such protections remains
host can terminate enclaves, and even an honest host challenging. Thus, Ekiden largely defers protections to
could lose enclaves in a power cycle. Ekiden is designed the application developer.
to tolerate such host failures, ensuring that crashed com- A range of applications, however, can be implemented
pute nodes can at most delay a request’s execution. with a flexible and efficient alternative side-channel de-
Our high-level approach is to treat TEEs as expendable fense for attested execution processor known as the
and interchangeable. Any TEE can process any query. Sealed-Glass Proof (SGP) model [88]. In this approach,
The blockchain serves an essential role in resolving any TEEs are presumed to protect integrity, but not confiden-
conflicts resulting from concurrency. tiality, and thus sensitive data are kept within the hosts
Formally, we model trusted hardware as a set of TEEs and are leakable exclusively to the data owner.
with distinct IDs (eids), and assume that at least one of Ekiden supports the SGP model by permitting confine-
them is not corrupted. Which TEE to invoke in a given ment of data to selected hosts, e.g., those of the data owner.
request is exposed as a choice to the environment. This This comes at the unavoidable cost of availability: keys
signifies that security is guaranteed regardless of how the for a TEE with confined data cannot be shared with other
TEEs are chosen, since the environment in UC stands in TEEs. Thus, availability depends on the data owner in
for arbitrary higher-level protocols. In Appendix C, we such deployments—a drawback that may be acceptable
suggest a pragmatic solution involving a coordinator that when confidentiality is a key concern.
is relied upon only for performance.
To ensure that any particular TEE is easily replaced,
TEEs are stateless, and any persistent state is stored by 4.2 Proof of Publication for PoW-based
the blockchain. We discuss later in the full protocol blockchains.
Protfull
Ekiden (Figure 13) how TEEs can also keep soft state Ekiden relies on efficient proofs of publication that prove
across invocations as a performance optimization, but we
to a contract TEE that an item has been stored in the
emphasize that losing such state at any point does not
blockchain. For blockchains based on Byzantine fault tol-
affect security.
erant consensus protocols, such a proof can be simply
constructed with a multisig signed by a majority of the
Timer failures. Trusted hardware in general cannot consensus nodes. To establish proofs of publication for
provide trusted time. In the case of SGX, although a PoW-based blockchains, contract TEEs must be able to
trusted relative timer is available, the communication be- validate new blocks. As noted in [23], a trusted timer is
tween enclaves and the timer (provided by an off-CPU needed to defend against an adversary isolating an en-
component) can be delayed by the OS2 [44]. Thus our clave and presenting an invalid subchain. Unfortunately,
protocol minimizes reliance on enclave time. First, the SGX timers cannot guarantee a bounded response time,
protocol does not require enclaves to have a current view as discussed above. To work around this limitation, we
of blockchain data. Specifically, instead of requiring a leverage the confidentiality of SGX so that an attacker
contract TEE to distinguish stale state from current state delaying a timer’s responses cannot prevent an enclave
(without a synchronized clock, there is no definitive coun- from successfully verifying blockchain contents.
termeasure to a network adversary delaying messages The proof of publication protocol (Fig. 2) involves a
from consensus nodes), the protocol relies on consensus verifier E, in the form of a contract TEE, and a untrusted
nodes to proactively reject any update based on a stale prover P. The high level idea is to only give P a limited
input state (a hash of which is included in the update). In amount of time to publish the message in a block within
2 as
confirmed by SGX SDK developers at https://github. a subchain of sufficient difficulty so that an adversary
com/intel/linux-sgx/issues/161 cannot feasibly forge it.

7
Proof of Publication of m between verifier E and prover P
Table 1: Exemplary parameters for Proof of Publication.
1: Parameters: p nc ε expected no. of false reject rate
2: nc : publication of m needs at least nc confirmation hashes to forge
3 : CB : a recent checkpoint block
4: δ (CB): difficulty of CB
10% 30 2 2112 2−17
5: τ: expected block interval of main chain 10% 60 2 2147 2−31
6: ε: slackness factor 20% 60 1.7 2113 2−19
25% 80 1.6 2113 2−19
7: Verifier E (a contract TEE):
8 : t1 ← TEE.timer()
9: r ←$ {0, 1}λ
10 : send (m, r) to P timeframe). However, a high ε also increases the possibil-
11 : receive π(m,r) = (CB, B1 , · · · , Bn ) from P ity of false acceptance, i.e. accepting a forged subchain.
12 : t2 ← TEE.timer() For any ε > 1, it is possible to require a large enough nc
13 : if π(m,r) is not a valid chain, output false so that the probability of a successful attack becomes neg-
14 : let Bi ∈ π(m,r) be the block that contains (m, r), output false if @Bi
ligible. However, a large nc means that an honest P needs
15 : if Bi has less than nc confirmation, i.e. n − i < nc , output false
to wait for a long time before P can obtain the output,
16 : if any B ∈ π(m,r) has a lower difficulty than δ (CB), output false
which affects the user experience of Ekiden.
17 : if t2 − t1 < (n − i) × τ × ε: output true and update checkpiont CB = Bn
18 : else : output false
For an attacker controlling p fraction of the total min-
ing power of the blockchain network, we provide exem-
Prover P:
19 :
plary concrete parameters for nc and ε in Table 1. For
20 : On receive (m, r) from E:
example, for a powerful attacker with 25% hash power
21 : send (m, r) to the blockchain, denote the including block Bi
(roughly the largest mining pool known to exist in Bit-
22 : send a subchain from CB to Bi+nc (inclusive) to E
coin and Ethereum at the time of writing), setting nc = 80
and ε = 1.6 means the attacker needs an expected 2112
Figure 2: Proof of Publication
hashes to forge a proof of publication3 , while an hon-
est proof will be rejected with probability 2−19 . Similar
block-synchronization techniques and analysis are used
E stores a recent checkpoint block CB from the in the recently proposed Tesseract TEE-based cryptocur-
blockchain, from which a difficulty δ (CB), e.g. the num- rency exchange [32].
ber of leading zeroes in the block nonce, can be calculated. It is easy to see that delaying the timer’s responses
E will emit an (attested) version of CB to any request- does not give the attacker more time than t2 − t1 . Delay-
ing client, enabling the client to verify CB’s freshness. ing timestamp t1 shrinks this apparent interval of time,
Given a valid recent CB, E can verify new blocks based disadvantaging the attacker. E’s checkpoint block can be
on δ (CB), assuming the difficulty is relatively stationary. updated with the same protocol, by publishing an empty
(For simplicity in our analysis here, we assume constant message. Note that once a message is successfully pub-
difficulty, but our analysis can be extended under an as- lished by a TEE, other TEEs can obtain the proof via se-
sumption of bounded difficulty variations.) cure channels established by attestations, saving the cost
To initiate publication of m, E calls the timer to get a of repeating the protocol.
timestamp t1 . As discussed, E may receive t1 after a delay.
. After receiving t1 (maybe at a time later than t1 ), E gener-
ates a random nonce r and requires the prover to publish 4.3 Atomic delivery of execution results
(m, r). Upon receiving a proof π(m,r) (a subchain contain-
ing (m, r)) from P, E calls the timer again for t2 . Let nc As a result of contract execution, two messages are sent
to be the number of confirmations in (m, r), τ be the ex- from the TEE: m1 , which delivers the output to the calling
pected block interval (an invariant of the blockchain), and client, and m2 , which delivers the state transition to the
ε be a multiplicative slack factor that accounts for varia- blockchain, both via adversarial channels. We emphasize
tion in the time to generate blocks, which is a stochastic that it is critical to enforce atomic delivery of the two
process. E.g., ε = 1.5 means that production of π(m,r) is messages, i.e. both m1 and m2 are delivered or the sys-
allowed to be up to 1.5 times slower than expected on the tem has become permanently unavailable. m1 is delivered
main chain. E accepts π(m,r) only if t2 − t1 < nc × τ × ε. when the calling client receives it. The new state m2 is
The above protocol is formally presented in Fig. 2. delivered when it’s accepted by the blockchain. Rejected
state transitions are not considered delivered.
Setting ε to a high value reduces the probability of false
rejections (i.e., rejecting proofs from an honest P when 3 as the time of writing, it takes roughly 273 hashes to mine a Bitcoin
the main chain growth was unluckily slow during some block.

8
Attacks without atomic delivery. To see the necessity Common approaches to minimizing such leakage, e.g.,
of atomic delivery, consider possible attacks when it’s restricting requests based on requester identity and/or
violated, i.e., when only one of the two messages is deliv- a differential-privacy budget [29, 46], require persistent
ered. counters. The monotonic counters in SGX are untrustwor-
First, if only the output (m1 ) is delivered, a replay at- thy, however [59].
tack becomes possible. Since TEE cannot tell whether Ekiden instead supports stateful approaches to mitigate
a user-supplied state is the latest, an attacker can replay application-level privacy leakage by enabling persistent
stale states to the TEE. Although attempts to extend a application state—e.g., counters, total consumed differ-
stale state will not be accepted by the blockchain (see Sec- ential privacy budget, etc.—to be maintained securely
tion 5.2.1), the output is delivered to the calling client. For on chain. Moreover, the aforementioned atomic delivery
example, a contract implementing a budgeted differential guarantee ensures that the output is only revealed if this
privacy policy can be caused to overrun its privacy bud- state is correctly updated.
get via such replay attacks. Moreover, for a contract with For instance, consider a contract enforcing a differen-
randomized methods, an attacker may repeatedly query tial privacy (DP) policy, maintaining the privacy budget
the compute node until she gets the desired result. on chain as part of the state. To circumvent the DP policy,
On the other hand, if only the state update (m2 ) is de- an attacker may try to feed a TEE with a stale state, cre-
livered, the user risks permanent loss of the output, as it ating a false appearance of unconsumed privacy budget.
might be impossible to reproduce the same output with Ekiden prevents this type of replay attack by relying on
the updated state. Note that there must be some mecha- consensus nodes to reject updates to stale states. Conse-
nism to prevent users from using earlier states otherwise quently, the atomic delivery protocol ensures the output is
replay attacks become possible. not revealed to the attacker, thus preserving the DP policy.

Blockchain-based commit. Assuming a secure com-


4.5 Key management
munication channel between a TEE and the calling client
Pi (which in practice can be constructed with remote at- To ensure privacy, contract states are encrypted using per-
testation.) we realize atomic delivery of m1 and m2 (de- contract keys that are only known to the trusted hardware.
fined above) via the following two-phase protocol: To However, the flip side is the challenge of ensuring avail-
initiate atomic delivery, TEE obtains a fresh key k from ability of these keys in the event of TEE failure. In Ekiden,
the key manager and sends an attested m01 := Enc(k, m1 ) we replicate keys across all compute nodes. Specifically,
to Pi over a secure channel. Once Pi acknowledges the each compute node instantiates a key manager TEE run-
reception of m01 , the TEE sends m2 to the blockchain. Fi- ning ProtKM (defined in Figure 11).
nally, after seeing a proof πm2 showing that m2 has been All key managers share a master key kmaster . When ini-
included in the blockchain the TEE sends k to Pi . tialized, a key manager first retrieves contact points of
We claim this scheme realizes atomic delivery. On the standing key managers by looking up the latest “km list”
one hand, as a TEE can ascertain the delivery of m2 by entry from the blockchain and obtains kmaster from them.
verifying πm2 , k is revealed only if m2 is delivered. On the Communication between key managers is encrypted and
other hand, if m2 has been delivered, k will be released authenticated via secure channels established through re-
eventually because at least one TEE is available and the mote attestations. To initialize the key management func-
key management protocol ProtKM ensures that k can be tionality, the first key manager generates a fresh kmaster
retrieved from any TEE. and creates on the blockchain a “km list” entry contain-
Although the above protocol is conceptually simple, ing its identity. Subsequent key managers bootstrap by
ProtEkiden adopts a more efficient variant. In ProtEkiden , requesting to “sync” with prior key managers, finally
the one-time key k is replaced with a persistent key kout cid adding themselves to “km list”. We rely on the consen-
that is reused across requests. Instead of sending kout cid to sus layer to handle race conditions. When multiple key
calling clients, TEE obtains m01 from Pi and sends the managers create “km list” entries at the same time, one
decryption. This optimization preserves atomicity. of them will be accepted by the blockchain while others
are rejected and must retry. In practice, to protect kmaster ,
4.4 Persistent state to mitigate app-level key managers must be carefully implemented and side-
channel free. Efficient implementations of side-channel
leakage
resistant encryption are available (e.g. AES-NI).
While Ekiden protects within-TEE data, it is not designed Once bootstrapped, key managers maintain a set of
to protect data at contract interfaces, i.e., data leakage re- keys for every contract, coordinating via the blockchain
sulting from the contract design. (E.g., a secret predic- by encrypting contract keys with the shared kmaster . Each
tion model may be “extracted” via client queries [87].) key (Ei , type, k) is associated with a type and Ei , the

9
identity of the contract TEE that creates the key. Key FEkiden (λ , `, {Pi }i∈[N] )
(Ei , type, k) can only be accessed by TEEs with identity
1: Parameter: leakage function ` : {0, 1}∗ → {0, 1}∗
Ei . Roughly speaking, the identity of a contract TEE is
2: On receive (“init”): Storage := 0/
the hash of the contract code. In practice, distinct con-
3: // Create a new contract
tracts will have different identities with high probability,
4: On receive (“create”, Contract) from Pi for some i ∈ [N]:
thus ProtKM enforces contract-level key isolation as is
5: cid ←$ {0, 1}λ
essential for security. 6: notify A of (“create”, Pi , cid, Contract); block until A replies
Contract TEEs {Ei }i can reach out to any key manager 7: Storage[cid] := (Contract,~0)
to create and retrieve keys. Upon a request by some Ei 8: send a public delayed output (“receipt”, cid) to Pi
for a key of type type, the key manager first checks if the 9: // Send queries to a contract
same key (Ei , type, kct ) has appeared on the blockchain, 10 : On receive (“request”, cid, inp, eid) from Pi for some i ∈ [N]:
in which case the key manager just reuses it. Otherwise, 11 : notify A of (“request”, cid, Pi , `(inp))
the key manager samples a fresh key k, encrypts it with 12 : (Contract, st) := Storage[cid]; abort if not found
kmaster and stores the ciphertext on the blockchain. Only 13 : (outp, st0 ) := Contract(Pi , inp, st)
then does the key manager send k to Ei . 14 : notify A of (cid, `(st0 ), `(outp), eid)
For key management, this paper adopts a simple global 15 : wait for “ok” from A and halt if other messages received
16 : update Storage[cid] := (Contract, st0 )
key, kmaster , as this suffices in our threat model assuming
17 : send a secret delayed output outp to Pi
no broken nodes. In future extensions, we are pursuing
key management strategies under stronger threat models, 18 : // Allow public access to encrypted state
19 : On receive (“read”, cid) from Pi for some i ∈ [N]:
using techniques such as secret sharing [35, 76].
20 : ( , st) := Storage[cid]; abort if not found
21 : send `(st) to Pi

5 Formal Security Model and Protocol De- 22 : if Pi is corrupted: send `(st) to A

tails Figure 3: The ideal functionality of Ekiden.

In this section, we formally define the security of Ekiden


as a Universal Composability (UC) [19] ideal function- information leakage through such reading is also defined
ality FEkiden . In Section 5.2 we specify ProtEkiden , the by the leakage function `.
protocol realization of FEkiden that we implement. We Users can send queries to FEkiden to execute the con-
prove its security in Appendix B in the UC framework. tract code with user-provided input. The execution of a
contract will result in a secret output (denoted outp) re-
turned to the invoker and a secret transition to a new con-
5.1 Formal Security Model tract state (denoted st0 ), equivalent intuitively to black-
box contract execution (modulo leakage). Although any
The ideal functionality. We specify the security goals
party may send messages to the contract, the contract
of Ekiden in the ideal functionality FEkiden defined in
code can enforce access control based on the calling
Figure 3. FEkiden allows parties to create contracts and
pseudonym passed to the contract.
interact with them.
Each party Pi is identified by a unique id simply de-
noted Pi . Parties send messages over authenticated chan- Session ID (SID). In UC [19], each functionality is as-
nels. To capture the allowed information leakage from sociated with a unique session ID (SID). The SID is es-
the encryption, we follow the convention of [19] and pa- sential for the composition theorem, as it ensures that con-
rameterize FEkiden with a leakage function `(·). We use current instances of protocols are kept separate from each
the standard delayed output terminology [19] to model other. To reduce clutter, we omit the handling of SIDs in
the power of the network adversary. Specifically, when FEkiden .
FEkiden sends a delayed output outp to P, this means that
outp is first sent to the adversary A and forwarded to P Corruption model. FEkiden adopts the standard corrup-
after acknowledgement by A. If the message is secret, tion model of [19]. A can corrupt any number of clients,
only the allowed amount of leakage (i.e., that specified by and up to all but one contract executors. When A corrupts
the leakage function) is revealed to S. a TEE (or similarly a party), A sends the message (“cor-
A Contract is a user-provided program, i.e. a smart rupt”, eid) to FEkiden . If a query includes an invalid TEE
contract. Each smart contract is associated with a piece id, FEkiden aborts if instructed by A. Otherwise the ideal
of persistent storage where the contract code and st can functionality ignores eids, which are included in FEkiden
be stored. The storage is public; therefore FEkiden allows only as a technical requirement to ensure interface com-
any party, including A, to read the storage content. The patibility with ProtEkiden , given below.

10
Formal security and privacy guarantees. FEkiden en- property of blockchains but abstract away the inclusion
capsulates the following security and privacy properties. of state updates in blocks. We assume overlay seman-
First, query execution correctly reflects the code provided tics that associate blockchain data with id’s. In addition
by the contract creator, Second, output and new states are to read and write interfaces, Fblockchain provides a con-
delivered atomically, i.e. output is revealed if and only if venient interface by which clients can ascertain whether
the new state is committed. We discuss implementation an item is included in the blockchain. In practice, this
of this property in Section 4.3. interface avoids the overhead of downloading the entire
FEkiden provides privacy in the sense that neither other blockchain.
parties nor the adversary learns the secret input of an
honest party more than allowed leakage `. A client in- Parameterizing Fblockchain . In Ekiden, the contents of
teracting with a contract learns no more than its input and storage are parsed as an ordered array of state transitions,
output. Contract states are kept secret from all parties, A defined as transi = (H(sti−1 ), sti , σi ), a tuple of a hash
included, unless intentionally revealed through the output. of the previous state, a new state, and a proof from TEE
However, contract code is revealed publicly so that users attesting to the correctness of a state transition. (Note
can examine it before using it. We leave supporting pri- that as a performance optimization, large user input—e.g.
vate contract code (e.g. by employing a similar technique training data in an ML contract— may not be stored on
as in [77]) for future work. chain.) Storage can be interpreted as a special initial state
followed by a sequence of state transitions:
5.2 Protocol Details Storage = ((Contract, st0 , σ0 ), {transi }i≥1 ).
The Ekiden protocol is formally specified in ProtEkiden
(Fig. 4). ProtEkiden depends upon Gatt and Fblockchain , For a storage instance to be valid, each state transition
ideal functionalities for attested execution and must correctly reference the previous state and the attes-
the blockchain, respectively. We first specify the tation must verify. Formally, this is achieved by parame-
(Gatt , Fblockchain )-hybrid model in which FEkiden can be terizing Fblockchain with a succ(·, ·) such that
UC-realized by ProtEkiden . Then we discuss the details succ(Storage, (h, stnew , σTEE )) = true
of ProtEkiden .
if and only if h = H(stprev ) where stprev is the previous
5.2.1 The (Gatt , Fblockchain )-Hybrid World state in Storage and ΣTEE .Vf(pkTEE , σTEE , (h, stnew )).
Attestation σ proves that st0 is correctly derived from
Attested Execution. To formally model attested exe- the previous state with hash h. The practical significance
cution on trusted hardware, we adopt the ideal function- of succ(·, ·) is that it guarantees that at any time there is
ality Gatt defined in [70]. Informally, a party first loads a single sequence of state transitions consistent with the
a program prog into a TEE with an “install” message. view of each party. It thus guarantees that the chain of
On a “resume” call, the program is run on the given in- state transitions is fork-free.
put, generating an output outp along with an attestation
σTEE = ΣTEE .Sig(skTEE , (prog, outp)), a signature under 5.2.2 Protocol and its Security
a hardware key skTEE . The public key pkTEE can be ob-
tained from Gatt .getpk(). See [70] for details. Fig. 4 presents the main protocol for Ekiden. ProtEkiden
In practice it’s useful to allow a TEE to output data that makes use of a digital signature scheme Σ(KGen, Sig, Vf),
is not included in attestation. We extend Gatt slightly to al- a symmetric encryption scheme SE(KGen, Enc, Dec) and
lows this: in the extended Gatt , if a TEE program prog gen- an asymmetric encryption scheme AE(KGen, Enc, Dec).
erates a pair of output (outp1 , outp2 ), the attestation only
signs outp1 , i.e. σTEE = ΣTEE .Sig(skTEE , (prog, outp1 )). Sharing state keys. Each contract is associated with
A common pattern is to include a hash of outp2 in outp1 , a set of keys. As discussed in Section 4.5, contract
to allow parties to verify σTEE and outp2 separately. Sim- TEEs delegate key management to key manager TEEs.
ilar technique is used in [93]. In ProtEkiden , communication with key managers is ab-
stracted away with the keyManager function. Please refer
Blockchain. Fblockchain [succ] defines a general-purpose to Figure 11 for pseudocode specifying the key manager.
append-only ledger implemented by common blockchain
protocols (formally defined in Figure 10 in the Appendix). Contract creation. Ekiden contracts are deterministic
The parameter succ is a function that specifies the criteria programs written in a general-purpose programming lan-
for a new item to be added to the storage, modeling the guage. We use an TEE wrapper (Figure 5) to provide
notion of transaction validity. We retain the append-only routine functionalities used by all contracts, such as state

11
ProtEkiden (λ , AE, SE, Σ, {Pi }i∈[N] )

1: Clients Pi : 23 : Compute Nodes Subroutines (called by clients Pi ):


2: Initialize: (sski , spki ) ←$ Σ.KGen(1λ ); (eski , epki ) ←$ AE.KGen(1λ ) 24 : On input create(Contract):
3: On receive (“create”, Contract) from environment Z: 25 : \ to Gatt , wait for eid
send (“install”, Contract)
4: cid := create(Contract) 26 : send (eid, “resume”, (“create”)) to Gatt
5: assert cid has been stored on Fblockchain wait for ((Contract, cid, st0 , pkin
27 : cid ), σTEE ) from Gatt
6: output (“receipt”, cid) send (“write”, (Contract, cid, st0 , pkin
28 : cid , σTEE )) to Fblockchain
7: On receive (“request”, cid, inp, eid) from environment Z: 29 : wait to receive (“receipt”, cid) and return
8: σPi := Sig(sski , (cid, inp)) 30 : On input request(cid, inpct ):
9: obtains pkin
cid from Fblockchain 31 : send (“read”, cid) to Fblockchain and wait for stct
10 : let inpct := AE.Enc(pkin
cid , (inp, σPi )) 32 : // non-existing eid is assumed to be created transparently
11 : (st0ct , outpct , σ ) := request(cid, inpct ) 33 : send (eid, “resume”, (“request”, cid, inpct , stct )) to Gatt
12 : parse σ as (σTEE , hinp , hprev , houtp , spki ) 34 : receive ((“atom-deliver”, hinp , hprev , st0ct , houtp , spki ), σTEE , outpct )
13 : assert H(inpct ) = hinp 35 : // σTEE = ΣTEE .Sig(skTEE , (hinp , hprev , st0ct , houtp , spki ))
14 : assert outpct is correct by verifying σ 36 : let σ := (σTEE , hinp , hprev , houtp , spki )
15 : o := claim-output(cid, st0ct , outpct , σ , epki ) 37 : return (st0ct , outpct , σ )
16 : // retry if the previous state has been used by a parallel query 38 : On input claim-output(cid, st0ct , outpct , σ , epki ):
17 : if o = ⊥ then jump to the beginning of the “request” call 39 : send (“write”, cid, (st0ct , σ )) to Fblockchain
18 : parse o as (outp0ct , σTEE ) 40 : if receive (“reject”, cid) from Fblockchain then
19 : assert ΣTEE .Vf(pkTEE , σTEE , outp0ct ) // pkTEE := Gatt .getpk() 41 : return ⊥
20 : output AE.Dec(eski , outp0ct ) 42 : send (eid, “resume”, (“claim output”, st0ct , outpct , σ , epki )) to Gatt
21 : On receive (“read”, cid) from environment Z: 43 : receive (“output”, outp0ct , σTEE ) from Gatt or abort
22 : send (“read”, cid) to Fblockchain and relay output 44 : return (outp0ct , σTEE )

\ is defined in Figure 5.
Figure 4: Ekiden Protocol. The contract TEE program Contract

encryption, key management, etc. A properly wrapped decrypts stct and inpct with keys obtained from the key
\ can be executed in a TEE. To
contract, denoted Contract, manager and executes the contract program Contract to
create a contract in Ekiden, a client Pi calls the create get (stnew , outp). To ensure the new state and the output
subroutine of a compute node Comp with intput Contract, are delivered atomically, Comp and Pi conduct an atomic
a piece of contract code. Comp loads the Contract \ into a delivery protocol as specified in Section 4.3:
TEE and starts the initialization by invoking the “create” • First the contract TEE computes outpct =
call. As specified in Fig. 5, the contract TEE creates Enc(koutcid , outp) and st0ct = Enc(kstate cid , stnew ),
a fresh contract cid, obtains fresh (pkin in
cid , skcid ) pair and
and send both and proper attestation to Pi in a
state
kcid from the key manager and generates an encrypted secure channel established by epki .
initial state st0 and an attestation σTEE . The attestation • Pi acknowledges the reception by calling the
proves the st0 is correctly initialized and that pkin cid is
claim-output subroutine of Comp, which trig-
the corresponding public key for contract cid. The com- gers the contract TEE to send m1 = (st0ct , outpct , σ )
pute node Comp sends (Contract, cid, st0 , pkin cid , σTEE ) to
to Fblockchain . σ protects the integrity of m1 and cryp-
Fblockchain and waits for an receipt. Comp returns the con- tographically binds the new state and output to a
tract cid to Pi , who will verify that contract cid is properly previous state and a input, thus a malicious Comp
stored on Fblockchain . cannot tamper with it.
• Once m1 is accepted by Fblockchain , the contract TEE
sends the decryption of outpct to Pi in a secure chan-
Request execution. To execute a request to contract
nel.
cid, a client Pi first obtains the input encryption key pkin
cid
from Fblockchain . Then Pi calls the request subroutine
of Comp with input (cid, inpct ), where inpct is Pi ’s input Security. Theorem 1 characterizes the security of
encrypted with pkin ProtEkiden . A proof sketch is given in Appendix B.
cid and authenticated with spki . Comp
fetches the encrypted previous state stct from Fblockchain Theorem 1 (Security of ProtEkiden ). Assume that Gatt ’s
and launches an contract TEE with code Contract \ and attestation scheme ΣTEE and the digital signature Σ are
input (cid, inpct , stct ). existentially unforgeable under chosen message attacks
As specified in Fig. 5, if σPi verifies, the contract TEE (EU-CMA), that H is second pre-image resistant, and

12
\
Contract TEE wrapper Contract cure computing or Intel SGX. We have implemented a
compiler, which automatically builds contracts into exe-
1: On input (“create”) : cutables that can be loaded into a compute node, using
2: cid := H(Contract)
the Rust SGX SDK [27]. We leave compiling to different
3: (pkin in
cid , skcid ) := keyManager(“input key”) targets, such as secure multi-party computation for future
state
4: kcid := keyManager(“state key”)
work.
5: st0 = SE.Enc(kstate ~
cid , 0)
Ekiden is compatible many existing blockchains. We
6: return (Contract, cid, state0 , pkin
cid )
have built one end-to-end instantiation of our system,
7: On input (“request”, cid, inpct , stct ): Ekiden-BT, with a blockchain extending from Tender-
8: // retrieve skin state
cid , kcid from a key manager as above mint [51], which required no changes to Tendermint. Ten-
9: (inp, σPi ) := AE.Dec(skin
cid , inpct ) dermint is based on the DLS Byzantine fault tolerant con-
10 : assert Vf(σPi , spki , (cid, inp)) // spki is publicly known sensus protocol [30]. We leave implementing instantia-
11 : stprev := SE.Dec(kstate
cid , stct ) tions of Ekiden on other blockchains for future work. For
12 : stnew , outp := Contract(stprev , inp, spki )
blockchains where the application cannot define a custom
13 : st0ct := SE.Enc(kstate
cid , stnew )
block verification procedure, one may need to make small
14 : // initiate atomic delivery
changes to verify attestations that prove correct computa-
15 : kout
cid := keyManager(“output key”)
16 : outpct := SE.Enc(kout
tion of the TEE.
cid , outp)
17 : let hinp := H(inpct ), hprev := H(stct ), houtp = H(outpct )
18 : return ((“atom-deliver”, hinp , hprev , st0ct , houtp , spki ), outpct )
6.1 Programming Model
19 : On input (“claim output”, st0ct , outpct , σ , epki ):
20 : parse σ as (σTEE , hinp , hprev , houtp , spki ) We support a general-purpose programming model for
21 : assert H(outpct ) = houtp specifying contracts. A contract registers a mutable
22 : send (“∈”, cid, (st0ct , σ )) to Fblockchain
struct as its state, which Ekiden transparently serializes,
23 : receive true from Fblockchain or abort
encrypts, and synchronizes with the blockchain after
24 : kout
cid := keyManager(“output key”)
25 : outp := SE.Dec(kout
method calls. Contract methods must be deterministic
cid , outpct )
26 : return (“output”, AE.Enc(epk, outp))
and terminate in bounded time. Within this model, we
implemented two programming environments for deploy-
Figure 5: Contract TEE wrapper. Subroutine keyManager is ing smart contracts. In the Rust backend, developers can
defined in ProtKM (Figure 11). write contracts using a subset of the Rust programming
language, and thus benefit from access to a range of open
source libraries. We also ported the Ethereum Virtual Ma-
that AE and SE are IND-CPA secure. Then ProtEkiden
chine (EVM), thereby supporting any contract written for
securely realizes FEkiden in the (Gatt , Fblockchain )-hybrid
the Ethereum platform. The system currently does not
model, for static adversaries.
support calling contract functions from another contract.
We leave this for future work.
5.3 Performance Optimizations
Reduce attestations. Given an additional mechanism 6.1.1 Common Components
for revocation, a simple modification eliminates reliance
on the IAS apart from initialization. When initialized, RPC library. Ekiden comes with its own RPC library,
an enclave creates a signing key (pk, sk), and outputs which facilitates remote procedure calls into an enclave.
pk with an attestation. Subsequently, attestations are re- Our compiler automatically generates client stubs to
placed with signatures under sk. Since pk is bound to the which other Rust applications can link. The client stub
TEE code (by the initial attestation), signatures under sk includes logic to perform the remote attestation protocol
prove the integrity of output, just as attestations do. As for an authenticated encrypted channel into the enclave.
with other keys, (pk, sk) are managed by the key manager
(c.f. Section 4.5). Randomness. Intel SGX provides a native source of se-
In the Appendix we discuss an extended version of the cure randomness. We expose SGX random number gener-
protocol with several performance optimizations. ation to developers as an input to their contract methods.
Good on-chain randomness is challenging to obtain in
6 Implementation blockchain systems, and its lack frequently causes smart-
contract vulnerabilities [25]. Among our example con-
We implemented an Ekiden prototype in 7486 lines of tracts, the poker game and Cryptokitties require secure
Rust. Developers in Ekiden do not need expertise in se- randomness.

13
6.1.2 Smart Contract Languages pute nodes can scale up capacity to serve inference re-
quests without affecting correctness or privacy.
Rust Contracts. We built a compiler for Ekiden con- Because inference results can leak information about
tracts written in the Rust programming language. A sin- training data in membership inference attacks [82], dif-
gle struct is used to represent persisted state. Clients re- ferential privacy is commonly used to protect against ex-
motely call methods on the struct using our RPC library. traction of data from the model via black-box queries.
In our Rust token contract, the contract state contains a Without confidentiality-preserving smart contracts, devel-
mapping from client public keys to account balances, de- opers would need to apply differential privacy in the lo-
noted in tokens. When a client issues a transfer re- cal model, where noise is added to data before leaving
quest for a given amount, the smart contract first checks the client device, providing the strongest privacy guaran-
if the sender’s token balance is sufficient, i.e., at least tees at the cost of model accuracy [31]. Because Ekiden
the requested amount. If so, it deducts the amount from provides black-box confidentiality for data and computa-
the sender’s balance and adds it to the recipient’s bal- tion, it allows contract developers to employ differential
ance. Ekiden ensures that this transaction modifies con- privacy mechanisms in the central model, where noise is
tract state atomically. added in the contract during the training process. Thus,
Ekiden enables the same privacy guarantee as the local
Ethereum Virtual Machine (EVM) Contracts. We model of differential privacy, with better accuracy and
have ported the SputnikVM implementation of the utility. We extended our machine learning contract with
Ethereum Virtual Machine (EVM) to run inside an Eki- our own implementation of differentially-private stochas-
den enclave. Support for EVM means automatic support tic gradient descent [12].
existing contracts written for Ethereum. For example, in
our evaluation we use Ekiden to run existing ERC20 to- Smart Building Thermal Modeling. We ported an im-
kens written for Ethereum. These contracts automatically plementation of non-linear least squares, which is used to
inherit the guarantees of Ekiden, including secret con- predict temperatures based on time series thermal data
tract state and high performance. Compared to Ethereum, from smart buildings [26]. We have deployed this smart
execution happens off-chain on Ekiden compute nodes, contract to train a shared model across real-time data from
rather than on the Ethereum blockchain. select buildings in Berkeley, CA. These buildings sample
their temperature sensors every 20 seconds, generating
data used to update the predictive model. Ekiden allows
6.2 Applications the contract to run its model while keeping the sensor
data and model secret, demonstrating that our system is
In this section we describe several different applications
sufficiently responsive for highly interactive workloads
we developed to demonstrate the versatility of the Eki-
in an online setting.
den programming model. Figure 6 highlights the secret
state and application complexity of each contract. In Ap-
pendix C.1 we describe additional smart contracts. Tokens. The most popular kind of Ethereum contract is
the ERC20 token standard. At the time of writing, ERC20
tokens together comprise a $35 billion USD market.4 Us-
Machine Learning Contracts. In order to facili- ing the Ethereum port (Section 6.1), we can run existing
tate shared learning on secret data, we ported rusty- ERC20 token contracts. We also implemented a token
machine [10], a machine learning library for Rust, to run contract written directly in Rust, which yields moderate
inside our contracts. Using this library, we implemented performance improvement (see Section 7). In either case,
two contracts. In the credit scoring contract, we trained a Ekiden automatically provides privacy and anonymity,
model of credit scores based on financial records [11]. In which the contract would not receive on the Ethereum
the medical diagnosis contract, we trained a model pre- mainnet. The secret state in the token is the balances
dicting the likelihood of heart disease based on medical mapping, which stores the account balance for each user.
records [75]. For both applications, we generated clients
that sourced data from the UCI machine learning repos-
Cryptokitties. Cryptokitties [1] is a game built on the
itory [55]. Our machine learning contracts allow clients
Ethereum network that allows users to breed virtual cats,
with sensitive data to train a shared model in a secure set-
which are stored on the blockchain as ERC721 tokens.
ting. Plaintext training data is never exposed outside of
Each cat has a unique set of genes that determine its ap-
the contract and the clients that own the data. The con-
pearance and therefore its value. The traits of offspring
tract also stores the secret trained model in its secret state,
are determined by a smart contract that mixes the genes of
allowing other remote clients to issue inference requests.
Because the model is stored on the blockchain, new com- 4 https://coinmarketcap.com/tokens/views/all/

14
Application LoC Secret Input/Output Secret State
Machine Learning 806 Training data, predictions Model
Thermal Modeling 621 Sensor data, temperature Building model
Token (Rust) 514 Transfer(from, to, amount) Account balances
Poker 883 Players’ cards Shuffled deck
Cryptokitties 54 Random mutations Breeding algorithm
Ethereum VM 774 Input and output Contract state

Figure 6: Smart contracts written in Rust. For each, we specify the number of lines of code to implement in Ekiden, as well as secret
inputs, outputs, and state. Secret inputs and outputs are only accessible to the contract and the user invoking the contract. Secret
state is only accessible to the contract. For the EVM, we only include the cost of porting SputnikVM, which is 5445 lines of code.
For cryptokitties, a contract written for the EVM, we only include the work specific to porting this contract.

its parents. The source code of the gene mixing contract action, and can be accessed from any enclave, secret cards
is not publicly available, as the game developers aimed to can still be revealed if a player aborts.
make the breeding process unpredictable.
We obtained the bytecode for the gene mixing contract
from the Ethereum blockchain and executed it using our 7 Evaluation
Ekiden EVM port. We verified correct behavior by re-
In this section, we present the evaluation results for the
producing real transactions from the Ethereum network,
end-to-end latency and peak throughput. We evaluated
ensuring that the Ekiden application returned the same
five applications discussed in Section 6.2: a Rust to-
genetic results given the same inputs. The contract uses
ken contract Token, implementing an ERC20-like token
blockhash of a previous block as a source of entropy, so
in the Rust language, two Ethereum contracts, ERC20
for this experiment we initialized our EVM state to return
and Cryptokitties, running in the ported EVM, and
the appropriate hash values from Ethereum mainnet.
two machine learning applications, Credit and Thermal.
This example demonstrates that Ekiden can execute an
Compared to an ERC20 contract on Ethereum mainnet,
Ethereum contract even when source code is not available.
Ekiden-BT can support a token contract with 600x greater
Further, Ekiden can provide unique benefits for games re-
throughput, 400x less latency, at 1000x less monetary
quiring secrecy or unpredictability such as Cryptokitties.
cost. While we expect some mild performance degrada-
These properties are difficult to achieve with Ethereum,
tion when deployed with a larger scale blockchain, our
which makes contract code and data public. For example,
performance optimizations significantly reduce the ef-
the Cryptokitties gene mixing algorithm has been reverse-
fect of the blockchain’s speed, as shown below. Further-
engineered by players seeking to maximize their chance
more, we demonstrate that Ekiden can efficiently sup-
of breeding cats with rare traits [2, 4], thus undermining
port computation-intensive workloads such as machine
the game’s ecosystem. By contrast, an Ekiden contract
learning applications which would be cost-prohibitive on
has access to a source of randomness in hardware and
Ethereum. We also quantify the performance gains from
allows secret elements of a game’s algorithm to be stored
each of the optimizations described in Appendix C. We
in encrypted state.
show that batching, caching, and a write-ahead log im-
prove performance and reduce the network costs of syn-
Poker. We also implemented a poker contract, where chronizing state with the blockchain.
users take turns submitting their actions to the contract,
and the smart contract contains all of the game logic for 7.1 Experimental Setup
shuffling and (selectively) revealing cards. Poker applica-
tions have been used as a benchmark application for prior To evaluate the performance of Ekiden-BT, we ran ex-
systems using blockchains and secure multi-party com- periments with four consensus nodes hosted on Amazon
putation, known as mental poker [9, 14, 48, 49]. However, EC2 [7] and one compute node (with a Core i7-6500U
compared with these, Ekiden is significantly more robust CPU with 8GB of memory) hosted locally, as EC2 does
in how it handles player aborts. In most mental poker, not offer SGX-enabled instances at the time of writing.
if a party aborts, its secret hand cannot be reconstructed Transactions are only run once on the compute node
by others, so the game cannot proceed. Handling faults (K = 1). On EC2, we ran our Ekiden-BT blockchain
in secure multi-party computation requires application- extending Tendermint with four consensus nodes, dis-
specific changes to the cryptographic protocol [20]. Be- tributed evenly across different availability zones in Ore-
cause Ekiden persists state to the blockchain after each gon. Each consensus node was run on an t2.medium in-

15
100000
1000 Baseline

Peak Throughput (txn/sec)


Ekiden (compute-only) Ekiden-BT
100 Ekiden-BT 10000 Ethereum
Ethereum
Latency (sec)

10
1000
1
0.1 100
0.01
10
0.001
0.0001 1
Tok Tok ER ER Cry Cre Cre The The Tok Tok ER ER Cry Cre Cre The The
en: en: C20 C20 pto dit: dit: rm rm en: en: C20 C20 pto dit: dit: rm rm
tran get :tra :ge kitti trai infe al:tr al:in tran get :tra :ge kitti trai infe al:tr al:in
sfe nsf t es n r ain fer sfe nsf t es n r ain fer
r er r er

Figure 7: End-to-end latency of client requests for various con- Figure 8: Throughput comparison across contracts and systems.
tracts, plotting on a log scale. Running the Rust token and For our baseline, which reads and writes to a blockchain for
ERC20 token contracts on Ekiden-BT speeds up transactions every request, throughput is limited by blockchain performance.
by 2-5 orders of magnitude over Ethereum. Read-write trans- Our optimizations improve performance by 2–4 orders of mag-
actions are dominated by the confirmation times of the under- nitude over the baseline, with more advantage for read-write op-
lying blockchain. Read-write transactions on the Ekiden-BT erations on contracts with large state (e.g. Token). Operations in
blockchain take on the order of a second. Caching allows us the EVM incur about 10x higher cost compared to our Rust to-
to avoid writing to the blockchain for read-only transactions ken. For ERC20, we achieve between 1–2 orders of magnitude
(e.g. get). We only compare Ethereum for the ERC20 con- higher performance than Ethereum.
tract, as there are no comparable machine learning contracts on
Ethereum.
porated in the next block. Compared to the proof-of-work
protocol used in Ethereum, Ekiden-BT has 2-3 orders of
stance, with 2 CPU cores and 4 GB of memory. As shown magnitude faster confirmations, in part due to the use of
in Section 7.3, we do not expect throughput performance a faster blockchain. For the ERC20 token, which runs on
to be significantly impacted by a larger slower blockchain, the EVM in Ekiden-BT, we see similar performance to
because many transactions can be compressed into a sin- the Rust token contract, because both use the same con-
gle write onto the blockchain. By separating contract ex- sensus protocol.
ecution from state agreement, these layers can work in
parallel. However achieving consensus among a larger
group of consensus nodes will result in higher end-to-end 7.3 Throughput
latencies. To measure Ekiden-BT’s peak performance, we con-
ducted an experiment with 1000 clients, each sending
7.2 End-to-End Latency 100 serialized requests to a compute node. For each data
point, we disregard the first and last 10% of requests, av-
Figure 7 shows the end-to-end latency for calling the to- eraging the stable performance under stress. Figure 8
ken, Cryptokitties, and machine learning contracts, plot- shows the results for the token, Cryptokitties, and ma-
ted on a log scale. For the “Ekiden-BT” plot, we start our chine learning contracts. For the baseline, we implement
timer when the client triggers a request and end when the the simplest Ekiden-BT protocol, where each request trig-
response is decrypted, which includes the time the request gers a full state checkpoint on our blockchain. In the
is processed by the smart contract and the updated con- “Ekiden-BT” bar, we include our optimizations, as de-
tract state is committed to our blockchain. For read-only scribed in Appendix C. Batching compresses multiple
transactions like “Token:get” or “Credit:infer”, compute state checkpoints into a single commit on the blockchain.
nodes benefit from using a locally cached copy of state. We then cache the latest state on compute nodes and use
Writes to the Ekiden-BT blockchain take up to a second a write-ahead log for state updates. Our optimizations
to confirm. Latencies in Ekiden are dominated by the time have the greatest benefit for read-write operations, like
to commit to the blockchain. This relative cost is less for transfer. They have less benefit for contracts with
compute-intensive workloads like machine learning train- smaller states, such as the machine learning contract with
ing. For comparison, we include a bar (“compute-only”) small models. Conversely, writes to the blockchain sig-
that measures the time spent in the compute node, i.e. ex- nificantly impact performance for read-write transactions,
cluding time to commit to the blockchain. compared to read-only transactions with cached state. For
For the three transactions that could be run on the comparison on the transactions that could be run on the
Ethereum network, we plot the publicly reported block Ethereum network, we plot the publicly reported trans-
rates of the Ethereum mainnet in March 2018 [34], which action throughput of the Ethereum mainnet in March
represents the optimistic case that transactions are incor- 2018 [34]. Because CryptoKitties incurs higher computa-

16
Peak Throughput (txn/sec)
100000
Ekiden-BT
7.5 Transaction Costs
10000 To evaluate the transaction costs of Ekiden, we calculate
1000
an estimate of true dollar cost to executing contracts us-
ing recent market rates. In March 2018 on Ethereum, it
100 cost 52K gas ($0.17USD) to perform a transfer on an
ERC20 token contract and 130K gas ($0.39USD) to com-
10
pute the breeding algorithm on Cryptokitties [3]. For ref-
1 erence, it costs $26.55 to add 2 numbers together one
0 sec 1 sec 10 sec 1 min 10 min
million times in Ethereum [74]. By contrast, IBM rents
Consensus commit time
machines with Intel SGX processors for $260.00 per
Figure 9: Peak throughput performance of token transfers un-
month, which can do a token transfer in 2ms and Cryp-
der different consensus layer commit times. Because contract
execution occurs in parallel to state agreement, we show that
tokitties breeding in 100ms, at a cost of roughly 10−7 and
good throughput performance for a wide range of commit times 10−5 dollars respectively. Using similar logic, our ma-
on the consensus layer. We expect Ekiden to perform well on a chine learning contract costs 10−5 dollars for each call
variety of blockchains. to train. For these contracts, the cost to commit state to
the Ethereum blockchain ranges from $0.0688 for Cryp-
tokitties to $1.92 to store a 1KB machine learning model.
Because Ekiden can compress results from multiple re-
tional cost, we can fit fewer transactions in a block due to
quests into a single write to the blockchain, our system
the gas limit, compared to ERC20 transactions.
has a total cost vastly less than that of on-chain execution.
There are no current public deployments of Tendermint
for comparison.

7.4 Impact of Consensus on Throughput


8 Related Work
. In order to understand the impact of using different con-
sensus protocols with Ekiden, we measured peak through- Confidential smart contracts: Hawk [47] is a smart
put performance of token transfers as a function of the contract system that provides confidentiality by execut-
time to commit state to the blockchain. In order to simu- ing contracts off-chain and posting only zero-knowledge
late slower consensus protocols, we inject a variable delay proofs on-chain. As the zero-knowledge proofs in Hawk
for writes to the consensus nodes. Figure 9 shows that to- (zk-SNARKs) incur very high computational overhead,
ken transfers have good performance for a wide range Ekiden is significantly faster. Additionally, Hawk was de-
of commit latencies seen in popular blockchains. . Be- signed for a single compute node (called the “manager”),
cause state is cached at compute nodes, compute nodes and thus cannot (as designed) offer high availability. Eki-
can opportunistically execute new transactions without den does require trust in the security of Intel SGX, but
waiting for a response from consensus nodes. Periodi- Hawk’s “manager” must be trusted for privacy. Hawk sup-
cally, compute nodes asynchronously commit the state ports only a limited range of contract types, not the gen-
to the blockchain, as defined by the batch size. By sep- eral functionality of Ekiden.
arating contract execution from agreement on state, the The Microsoft Coco Framework [63] is concurrent and
layers can operate in parallel. Compute nodes compress independent work to port existing smart contract systems,
the state transitions from many transactions into a single such as Ethereum, to run in an SGX enclave. To the best
update to the blockchain. of our knowledge, only a whitepaper containing a high-
In contrast, Ethereum transactions are broadcast over level overview has been produced. No details of a proto-
the entire network of miners. Secondly, Ethereum serial- col or implementation have yet been released.
izes all contracts onto a single blockchain. At the time Blockchain transaction privacy: The goals Ekiden are
of writing, there are 36974 ERC20 token contracts on related to mechanisms for enhancing transaction privacy
Ethereum [34], with all transactions on all token contracts on public blockchains. Maxwell proposed a confidential
serialized on the same blockchain. Furthermore, all min- transaction scheme [60] for Bitcoin that conceals transac-
ers execute transactions in sequence prior to committing tion amounts, but not participant identities. Zerocash [13]
a block. Ekiden allows contracts to be parallelized across as well as Cryptonote [84, 89], Solidus [21], and Zero-
compute nodes and thus, computation is not a bottleneck, coin [64] provides stronger confidentiality guarantees by
enabling better performance. However, we leave the im- concealing identities. These schemes, however, do not
plementation of full cross-contract calls for future work. support smart contracts.

17
Privacy-preserving systems based on trusted hard- upon work supported by the Center for Long-Term Cy-
ware: Trusted hardware, particularly Intel SGX, has seen bersecurity, DARPA (award number N66001-15-C-4066)
a wide spectrum of applications in distributed systems. IC3 industry partners, and the National Science Founda-
M2 R [28], VC3 [77], Opaque [94] and Ohrimenko et tion (NSF award numbers TWC-1518899 CNS-1330599,
al. [68] leverage SGX to offer privacy-preserving data CNS-1514163, CNS-1564102, CNS-1704615, and ARO
analytics and machine learning with various security guar- W911NF-16-1-0145). This work was also supported
antees, Ryoan [41] is a distributed sandbox platform us- in part by FORCES (Foundations Of Resilient CybEr-
ing SGX to confine privacy leakage from untrusted ap- Physical Systems), which receives support from the Na-
plications that process sensitive data. These systems do tional Science Foundation (NSF award numbers CNS-
not address state integrity and confidentiality over a long- 1238959, CNS-1238962, CNS-1239054, CNS-1239166).
lived system. In comparison, Ekiden provides a stronger Any opinions, findings, and conclusions or recommenda-
integrity and availability guarantees by persisting contract tions expressed in this material are those of the author(s)
states on a blockchain. and do not necessarily reflect the views of the National
Blockchains for verifiable computations and secure Science Foundation.
multi-party computations: Several related works of-
fer blockchain-based guarantees of computation integrity,
but cannot guarantee privacy [58, 85, 86]. A line of works
have used a blockchain to provide fairness for MPC
by requiring parties to forfeit a security deposit if they
abort [9, 14, 48, 49, 95]. Compared to these, Ekiden can
guarantee that all the data can be recovered if any com-
pute node remains online. TEE-based computation is also
far more performant than MPC.

9 Conclusion
Ekiden demonstrates that blockchains and trusted en-
claves have complementary security properties that can
be combined effectively to provide a powerful, generic
platform for confidentiality-preserving smart contracts.
The result is a compelling programming model that over-
comes significant challenges in blockchain smart con-
tracts. We show that Ekiden can be used to implement
a variety of secure decentralized applications that com-
pute on sensitive data.
In future work we plan to extend Ekiden to operate
under a stronger threat model, where individual enclaves
can be compromised while preserving long-term guaran-
tees. Hybrid architectures, leveraging techniques such as
secure multi-party computation [9, 23, 56], can protect
the system’s more critical features, such as key manage-
ment and coordination across compute nodes. Coordina-
tion can also facilitate parallelism in contract execution,
merging output from queries processed by multiple en-
claves concurrently.

Acknowledgments
We want to thank Iddo Bentov, Mic Bowman, Joe Near,
Chang Liu, Jian Liu, and Lun Wang for their helpful
feedback and discussion. We also thank Pranav Gad-
damadugu and Andy Wang for their contributions to ap-
plication development. This material is in part based

18
References [19] C A N E T T I , R . Universally Composable Security: A New
Paradigm for Cryptographic Protocols. Cryptology ePrint Archive,
[1] CryptoKitties - Collect and breed digital cats. https://www. Report 2000/067, 2000. https://eprint.iacr.org/
cryptokitties.co/ 2000/067.
[2] CryptoKitties GeneScience algorithm. [20] C A S T E L L A - R O C A , J . , S E B É , F. , A N D D O M I N G O -
https://medium.com/@alexhegyi/ F E R R E R , J . Dropout-tolerant TTP-free mental poker. In
cryptokitties-genescience-1f5b41963b0d International Conference on Trust, Privacy and Security in
Digital Business (2005), Springer, pp. 30–40.
[3] Eth gas station. https://ethgasstation.info
[21] C E C C H E T T I , E . , Z H A N G , F. , J I , Y. , K O S B A , A . E . ,
[4] Genetics Fur Cats: Premier genetic testing services for your Cryp- J U E L S , A . , A N D S H I , E . Solidus: Confidential distributed
toKitties based on machine learning and the blockchain. http: ledger transactions via PVORM. In Proceedings of the 2017 ACM
//www.kitty.services/ SIGSAC Conference on Computer and Communications Security,
[5] Neo: An Open Network For Smart Economy. https://neo. CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017
org/ (2017), B. M. Thuraisingham, D. Evans, T. Malkin, and D. Xu,
Eds., ACM, pp. 701–717.
[6] A LT M A N , E . I . , A N D S A U N D E R S , A . Credit risk measure-
ment: Developments over the last 20 years. Journal of banking & [22] C H E N , S . , Z H A N G , X . , R E I T E R , M . K . , A N D Z H A N G ,
finance 21, 11 (1997), 1721–1742. Y. Detecting privileged side-channel attacks in shielded execution
with déjá vu. In Proceedings of the 2017 ACM on Asia Conference
[7] A M A Z O N . Elastic Compute Cloud. https://aws.amazon. on Computer and Communications Security (2017), ACM, pp. 7–
com/ 18.
[8] A N AT I , I . , G U E R O N , S . , J O H N S O N , S . , A N D S C A R - [23] C H O U D H U R I , A . R . , G R E E N , M . , JA I N , A . ,
L ATA , V. Innovative Technology for CPU Based Attestation K A P T C H U K , G . , A N D M I E R S , I . Fairness in an un-
and Sealing. In HASP’13 (2013), pp. 1–7. fair world: Fair multiparty computation from public bulletin
boards. Cryptology ePrint Archive, Report 2017/1091, 2017.
[9] A N D R Y C H O W I C Z , M . , D Z I E M B O W S K I , S . , M A L I -
https://eprint.iacr.org/2017/1091.
NOWSKI, D., AND MAZUREK, L. Secure multiparty
computations on Bitcoin. In Security and Privacy (SP), 2014 [24] C O S TA N , V. , L E B E D E V , I . A . , A N D D E VA D A S , S . Sanc-
IEEE Symposium on (2014), IEEE, pp. 443–458. tum: Minimal hardware extensions for strong software isolation.
In USENIX Security Symposium (2016), pp. 857–874.
[10] A T H E M AT H M O . rusty-machine. https://github.com/
AtheMathmo/rusty-machine [25] D E L M O L I N O , K . , A R N E T T , M . , K O S B A , A . , M I L L E R ,
A . , A N D S H I , E . Step by step towards creating a safe smart
[11] B A E S E N S , B . , V A N G E S T E L , T. , V I A E N E , S . , contract: Lessons and insights from a cryptocurrency lab. In In-
S T E PA N O VA , M . , S U Y K E N S , J . , A N D V A N T H I E N E N , ternational Conference on Financial Cryptography and Data Se-
J . Benchmarking state-of-the-art classification algorithms for curity (2016), Springer, pp. 79–94.
credit scoring. Journal of the operational research society 54, 6
(2003), 627–635. [26] D E W S O N , T. , D AY , B . , A N D I R V I N G , A . Least squares
parameter estimation of a reduced order thermal model of an ex-
[12] B A S S I LY , R . , S M I T H , A . , A N D T H A K U R TA , A . Private perimental building. Building and Environment 28, 2 (1993), 127–
empirical risk minimization: Efficient algorithms and tight error 137.
bounds. In Foundations of Computer Science (FOCS), 2014 IEEE
[27] D I N G , Y. , D U A N , R . , L I , L . , C H E N G , Y. , Z H A N G , Y. ,
55th Annual Symposium on (2014), IEEE, pp. 464–473.
C H E N , T. , W E I , T. , A N D W A N G , H . Rust SGX SDK: To-
[13] B E N - S A S S O N , E . , C H I E S A , A . , G A R M A N , C . , G R E E N , wards Memory Safety in Intel SGX Enclave. In Proceedings of
M . , M I E R S , I . , T R O M E R , E . , A N D V I R Z A , M . Zerocash: the 2017 ACM SIGSAC Conference on Computer and Commu-
Decentralized anonymous payments from bitcoin. In 2014 IEEE nications Security (New York, NY, USA, 2017), CCS ’17, ACM,
Symposium on Security and Privacy, SP 2014, Berkeley, CA, USA, pp. 2491–2493.
May 18-21, 2014 (2014), IEEE Computer Society, pp. 459–474. [28] D I N H , T. T. A . , S A X E N A , P. , C H A N G , E . - C . , O O I ,
[14] B E N T O V , I . , K U M A R E S A N , R . , A N D M I L L E R , A . In- B . C . , A N D Z H A N G , C . M2R: Enabling Stronger Privacy
stantaneous decentralized poker. In International Conference on in MapReduce Computation. In 24th USENIX Security Sympo-
the Theory and Application of Cryptology and Information Secu- sium (USENIX Security 15) (Washington, D.C., 2015), USENIX
rity (2017), Springer, pp. 410–440. Association, pp. 447–462.
[15] B E R N A R D , T. , H S U , T. , P E R L R O T H , N . , A N D L I E B E R , [29] D W O R K , C . Differential privacy: A survey of results. In In-
R . Equifax Says Cyberattack May Have Affected 143 Million ternational Conference on Theory and Applications of Models of
in the U.S. https://www.nytimes.com/2017/09/07/ Computation (2008), Springer, pp. 1–19.
business/equifax-cyberattack.html [30] D W O R K , C . , L Y N C H , N . , A N D S T O C K M E Y E R , L . Con-
sensus in the presence of partial synchrony. Journal of the ACM
[16] B E R N S T E I N , D . J . , L A N G E , T. , A N D S C H WA B E , P. The
(JACM) 35, 2 (1988), 288–323.
security impact of a new cryptographic library. In International
Conference on Cryptology and Information Security in Latin [31] D W O R K , C . , R O T H , A . , E T A L . The algorithmic founda-
America (2012), Springer, pp. 159–176. tions of differential privacy. Foundations and Trends R in Theo-
retical Computer Science 9, 3–4 (2014), 211–407.
[17] B R A S S E R , F. , M Ü L L E R , U . , D M I T R I E N K O , A . , K O S -
T I A I N E N , K . , C A P K U N , S . , A N D S A D E G H I , A . - R . Soft- [32] E T A L . , I . B . Tesseract: Real-time cryptocurrency exchange
ware grand exposure: Sgx cache attacks are practical. arXiv using trusted hardware, 2017.
preprint arXiv:1702.07521 (2017), 33. [33] E T H E R E U M F O U N D AT I O N . Ethereum: Blockchain App Plat-
[18] B Ü N Z , B . , G O L D F E D E R , S . , A N D B O N N E A U , J . Proofs- form. https://www.ethereum.org/
of-delay and randomness beacons in ethereum. IEEE Security [34] E T H E R S C A N . Etherscan: The Ethereum Blockchain Explorer.
and Privacy on the Blockchain (IEEE S&B) (2017). https://etherscan.io/

19
[35] F E L D M A N , P. A practical scheme for non-interactive verifiable C . Sgxbounds: Memory safety for shielded execution. In Pro-
secret sharing. In Foundations of Computer Science, 1987., 28th ceedings of the Twelfth European Conference on Computer Sys-
Annual Symposium on (1987), IEEE, pp. 427–438. tems (2017), ACM, pp. 205–221.
[36] F I S C H , B . , V I N AYA G A M U R T H Y , D . , B O N E H , D . , A N D [51] K W O N , J . Tendermint: Consensus without mining. 2017.
G O R B U N O V , S . Iron: functional encryption using Intel SGX. In [52] L E E , J . , J A N G , J . , J A N G , Y. , K WA K , N . , C H O I , Y. ,
Proceedings of the 2017 ACM SIGSAC Conference on Computer C H O I , C . , K I M , T. , P E I N A D O , M . , A N D K A N G , B . B .
and Communications Security (2017), ACM, pp. 765–782. Hacking in darkness: Return-oriented programming against se-
[37] G Ö T Z F R I E D , J . , E C K E R T , M . , S C H I N Z E L , S . , A N D cure enclaves. In USENIX Security (2017), pp. 523–539.
M Ü L L E R , T. Cache attacks on intel sgx. In Proceedings of [53] L E E , S . , S H I H , M . - W. , G E R A , P. , K I M , T. , K I M , H . ,
the 10th European Workshop on Systems Security (2017), ACM, A N D P E I N A D O , M . Inferring fine-grained control flow inside
p. 2. sgx enclaves with branch shadowing. In 26th USENIX Security
[38] G U E R O N , S . A memory encryption engine suitable for general Symposium, USENIX Security (2017), pp. 16–18.
purpose processors. IACR Cryptology ePrint Archive 2016 (2016), [54] L E I M G R U B E R , J . , A N D B A C K U S , A . M . J . Bloom proto-
204. col:decentralized credit scoring powered by Ethereum and IPFS,
[39] H Ä H N E L , M . , C U I , W. , A N D P E I N A D O , M . High- 27 Jan. 2018.
resolution side channels for untrusted operating systems. In [55] L I C H M A N , M . UCI machine learning repository, 2013.
2017 USENIX Annual Technical Conference (USENIX ATC 17). [56] L I N D E L L , Y. , A N D P I N K A S , B . Secure multiparty compu-
USENIX Association, Santa Clara, CA (2017), pp. 299–312. tation for privacy-preserving data mining. Journal of Privacy and
[40] H O E K S T R A , M . , L A L , R . , P A P PA C H A N , P. , P H E G A D E , Confidentiality 1, 1 (2009), 5.
V. , A N D D E L C U V I L L O , J . Using innovative instructions to [57] L I U , C . , W A N G , X . S . , N AYA K , K . , H U A N G , Y. , A N D
create trustworthy software solutions. In Proceedings of the 2nd S H I , E . Oblivm: A programming framework for secure computa-
International Workshop on Hardware and Architectural Support tion. In Proceedings of the 2015 IEEE Symposium on Security and
for Security and Privacy - HASP ’13 (2013), pp. 1–1. Privacy (Washington, DC, USA, 2015), SP ’15, IEEE Computer
[41] H U N T , T. , Z H U , Z . , X U , Y. , P E T E R , S . , A N D Society, pp. 359–376.
WITCHEL, E. Ryoan: A distributed sandbox for un- [58] L U U , L . , T E U T S C H , J . , K U L K A R N I , R . , A N D S A X E N A ,
trusted computation on secret data. In 12th USENIX Symposium P. Demystifying incentives in the consensus computer. In Pro-
on Operating Systems Design and Implementation (OSDI 16) ceedings of the 22nd ACM SIGSAC Conference on Computer and
(Savannah, GA, 2016), USENIX Association, pp. 533–549. Communications Security (2015), ACM, pp. 706–719.
[42] I B I S W O R L D . Credit Bureaus & Rating Agencies in the [59] M AT E T I C , S . , A H M E D , M . , K O S T I A I N E N , K . , D H A R ,
US. http://clients1.ibisworld.com/reports/ A . , S O M M E R , D . , G E R VA I S , A . , J U E L S , A . , A N D C A P -
us/industry/ataglance.aspx?entid=1475 K U N , S . ROTE: rollback protection for trusted execution. In

[43] I N T E L . Attestation Service for Intel


R Software 26th USENIX Security Symposium, USENIX Security 2017, Van-
Guard Extensions (Intel R SGX): API Documentation. couver, BC, Canada, August 16-18, 2017. (2017), E. Kirda and
https://software.intel.com/sites/default/ T. Ristenpart, Eds., USENIX Association, pp. 1289–1306.
files/managed/7e/3b/ias-api-spec.pdf. (Ac- [60] M A X W E L L , G . https://people.xiph.org/˜greg/confidential values.txt.
cessed on 02/06/2018). https://people.xiph.org/˜greg/confidential_
values.txt. (Accessed on 01/31/2018).
[44] I N T E L . Intel SGX platform services. https://software.
intel.com/sites/default/files/managed/1b/ [61] M C K E E N , F. , A L E X A N D R O V I C H , I . , B E R E N Z O N , A . ,
a2/Intel-SGX-Platform-Services.pdf. (Accessed R O Z A S , C . V. , S H A F I , H . , S H A N B H O G U E , V. , A N D
on 01/29/2018). S AVA G A O N K A R , U . R . Innovative instructions and software
model for isolated execution. In Proceedings of the 2nd Inter-
[45] J A N G , Y. , L E E , J . , L E E , S . , A N D K I M , T. Sgx-bomb:
national Workshop on Hardware and Architectural Support for
Locking down the processor via rowhammer attack. In Proceed-
Security and Privacy - HASP ’13 (2013), pp. 1–1.
ings of the 2nd Workshop on System Software for Trusted Execu-
tion (2017), ACM, p. 5. [62] M E I K L E J O H N , S . , P O M A R O L E , M . , J O R D A N , G . ,
L E V C H E N K O , K . , M C C O Y, D . , V O E L K E R , G . M . ,
[46] J O H N S O N , N . M . , N E A R , J . P. , A N D S O N G , D . X . Prac- A N D S AVA G E , S . A fistful of bitcoins: characterizing pay-
tical differential privacy for SQL queries using elastic sensitivity. ments among men with no names. In Proceedings of the 2013
CoRR abs/1706.09479 (2017). conference on Internet measurement conference (2013), ACM,
[47] K O S B A , A . , M I L L E R , A . , S H I , E . , W E N , Z . , A N D P A - pp. 127–140.
PA M A N T H O U , C . Hawk: The blockchain model of cryptog- [63] M I C R O S O F T . The Coco Framework: Technical Overview.
raphy and privacy-preserving smart contracts. In Security and https://github.com/Azure/coco-framework/
Privacy (SP), 2016 IEEE Symposium on (2016), IEEE, pp. 839–
858. [64] M I E R S , I . , G A R M A N , C . , G R E E N , M . , A N D R U B I N ,
A . D . Zerocoin: Anonymous distributed e-cash from bitcoin. In
[48] K U M A R E S A N , R . , A N D B E N T O V , I . Amortizing secure 2013 IEEE Symposium on Security and Privacy, SP 2013, Berke-
computation with penalties. In Proceedings of the 2016 ACM ley, CA, USA, May 19-22, 2013 (2013), IEEE Computer Society,
SIGSAC Conference on Computer and Communications Security pp. 397–411.
(2016), ACM, pp. 418–429.
[65] M O G H I M I , A . , I R A Z O Q U I , G . , A N D E I S E N B A R T H , T.
[49] K U M A R E S A N , R . , M O R A N , T. , A N D B E N T O V , I . How Cachezoom: How sgx amplifies the power of cache attacks. In
to use bitcoin to play decentralized poker. In Proceedings of the International Conference on Cryptographic Hardware and Em-
22nd ACM SIGSAC Conference on Computer and Communica- bedded Systems (2017), Springer, pp. 69–90.
tions Security (2015), ACM, pp. 195–206.
[66] M Ö S E R , M . , A N D B Ö H M E , R . The price of anonymity: em-
[50] K U VA I S K I I , D . , O L E K S E N K O , O . , A R N A U T O V , S . , pirical evidence from a market for bitcoin anonymization. Journal
T R A C H , B . , B H AT O T I A , P. , F E L B E R , P. , A N D F E T Z E R , of Cybersecurity (2017).

20
[67] N AYA K , K . , F L E T C H E R , C . , R E N , L . , C H A N D R A N , N . , [83] S I N H A , R . , R A J A M A N I , S . , A N D S E S H I A , S . A . A com-
L O K A M , S . , S H I , E . , A N D G O YA L , V. Hop: Hardware piler and verifier for page access oblivious computation. In Pro-
makes obfuscation practical. In 24th Annual Network and Dis- ceedings of the 2017 11th Joint Meeting on Foundations of Soft-
tributed System Security Symposium, NDSS (2017). ware Engineering (2017), ACM, pp. 649–660.
[68] O H R I M E N K O , O . , S C H U S T E R , F. , F O U R N E T , C . , [84] S U N , S . - F. , A U , M . H . , L I U , J . K . , A N D Y U E N , T. H .
M E H TA , A . , N O W O Z I N , S . , V A S WA N I , K . , A N D Ringct 2.0: A compact accumulator-based (linkable ring signa-
C O S TA , M . Oblivious multi-party machine learning on trusted ture) protocol for blockchain cryptocurrency monero. In Eu-
processors. In USENIX Security Symposium (2016), pp. 619–636. ropean Symposium on Research in Computer Security (2017),
Springer, pp. 456–474.
[69] O ’ K E E F F E , D . E. A. SGXSpectre, 2018.
https://github.com/lsds/spectre-attack-sgx. [85] T E U T S C H , J . , B U T E R I N , V. , A N D B R O W N , C . Inter-
active coin offerings. URl: https://people. cs. uchicago. edu/˜
[70] P A S S , R . , S H I , E . , A N D T R A M E R , F. Formal Abstrac-
teutsch/papers/ico. pdf (visited on 11/16/2017) (2017).
tions for Attested Execution Secure Processors. Cryptology ePrint
Archive, Report 2016/1027, 2016. https://eprint.iacr. [86] T E U T S C H , J . , A N D R E I T W I E SS N E R , C . A scalable verifi-
org/2016/1027. cation solution for blockchains.
[71] R A N E , A . , L I N , C . , A N D T I WA R I , M . accoon: Closing dig- [87] T R A M È R , F. , Z H A N G , F. , J U E L S , A . , R E I T E R , M . K . ,
ital side-channels through obfuscated execution. In 24th USENIX A N D R I S T E N PA R T , T. Stealing machine learning models via
Security Symposium (USENIX Security 15) (Washington, D.C., prediction APIs. In USENIX Security Symposium (2016), pp. 601–
2015), USENIX Association, pp. 431–446. 618.
[72] R E I D , F. , A N D H A R R I G A N , M . An analysis of anonymity [88] T R A M È R , F. , Z H A N G , F. , L I N , H . , H U B A U X , J . P. ,
in the bitcoin system. In Security and privacy in social networks. J U E L S , A . , A N D S H I , E . Sealed-Glass Proofs: Using Trans-
Springer, 2013, pp. 197–223. parent Enclaves to Prove and Sell Knowledge. In 2017 IEEE
European Symposium on Security and Privacy (EuroS&P) (April
[73] R O N , D . , A N D S H A M I R , A . Quantitative analysis of the
2017), pp. 19–34.
full bitcoin transaction graph. In International Conference on
Financial Cryptography and Data Security (2013), Springer, pp. 6– [89] VA N S A B E R H A G E N , N . Cryptonote v 2. 0, 2013.
24. [90] W A N G , W. , C H E N , G . , P A N , X . , Z H A N G , Y. , W A N G ,
[74] R YA N , D . Calculating Costs in Ethereum X . , B I N D S C H A E D L E R , V. , T A N G , H . , A N D G U N T E R ,
Contracts. https://hackernoon.com/ C . A . Leaky cauldron on the dark land: Understanding memory
ether-purchase-power-df40a38c5a2f side-channel hazards in sgx. In Proceedings of the 2017 ACM
SIGSAC Conference on Computer and Communications Security
[75] S A J D A , P. Machine learning for detection and diagnosis of
(2017), ACM, pp. 2421–2434.
disease. Annu. Rev. Biomed. Eng. 8 (2006), 537–565.
[91] W E I C H B R O D T , N . , K U R M U S , A . , P I E T Z U C H , P. , A N D
[76] S C H O E N M A K E R S , B . A simple publicly verifiable secret shar-
K A P I T Z A , R . AsyncShock: Exploiting synchronisation bugs
ing scheme and its application to electronic voting. In Annual
in Intel SGX enclaves. In European Symposium on Research in
International Cryptology Conference (1999), Springer, pp. 148–
Computer Security (2016), Springer, pp. 440–457.
164.
[92] X U , Y. , C U I , W. , A N D P E I N A D O , M . Controlled-channel
[77] S C H U S T E R , F. , C O S TA , M . , F O U R N E T , C . , G K A N T -
attacks: Deterministic side channels for untrusted operating sys-
S I D I S , C . , P E I NA D O , M . , M A I NA R - RU I Z , G . , A N D
tems. In 2015 IEEE Symposium on Security and Privacy, SP 2015,
R U S S I N O V I C H , M . VC3: Trustworthy data analytics in the
San Jose, CA, USA, May 17-21, 2015 (2015), IEEE Computer So-
cloud using SGX. In Security and Privacy (SP), 2015 IEEE Sym-
ciety, pp. 640–656.
posium on (2015), IEEE, pp. 38–54.
[93] Z H A N G , F. , E YA L , I . , E S C R I VA , R . , J U E L S , A . , A N D
[78] S C H WA R Z , M . , W E I S E R , S . , G R U S S , D . , M A U R I C E ,
R E N E S S E , R . V. REM: Resource-efficient mining for
C . , A N D M A N G A R D , S . Malware guard extension: Using
blockchains. In 26th USENIX Security Symposium (USENIX Secu-
sgx to conceal cache attacks. In International Conference on De-
rity 17) (Vancouver, BC, 2017), USENIX Association, pp. 1427–
tection of Intrusions and Malware, and Vulnerability Assessment
1444.
(2017), Springer, pp. 3–24.
[94] Z H E N G , W. , D AV E , A . , B E E K M A N , J . G . , P O PA ,
[79] S E O , J . , L E E , B . , K I M , S . , S H I H , M . - W. , S H I N , I . ,
R . A . , G O N Z A L E Z , J . E . , A N D S T O I C A , I . Opaque: An
H A N , D . , A N D K I M , T. Sgx-shield: Enabling address space
oblivious and encrypted distributed analytics platform. In 14th
layout randomization for sgx programs. In Proceedings of the
USENIX Symposium on Networked Systems Design and Imple-
2017 Annual Network and Distributed System Security Symposium
mentation (NSDI 17) (Boston, MA, 2017), USENIX Association,
(NDSS), San Diego, CA (2017).
pp. 283–298.
[80] S H I H , M . - W. , L E E , S . , K I M , T. , A N D P E I N A D O , M .
[95] Z Y S K I N D , G . , N AT H A N , O . , E T A L . Decentralizing pri-
T-sgx: Eradicating controlled-channel attacks against enclave pro-
vacy: Using blockchain to protect personal data. In Security and
grams. In Proceedings of the 2017 Annual Network and Dis-
Privacy Workshops (SPW), 2015 IEEE (2015), IEEE, pp. 180–
tributed System Security Symposium (NDSS), San Diego, CA
184.
(2017).
[81] S H I N D E , S . , C H U A , Z . L . , N A R AYA N A N , V. , A N D
S A X E N A , P. Preventing page faults from telling your secrets.
In Proceedings of the 11th ACM on Asia Conference on Computer
and Communications Security (2016), ACM, pp. 317–328.
[82] S H O K R I , R . , S T R O N AT I , M . , S O N G , C . , A N D
S H M AT I K O V , V. Membership inference attacks against
machine learning models. In Security and Privacy (SP), 2017
IEEE Symposium on (2017), IEEE, pp. 3–18.

21
A Supplementary Formalism ProtKM (λ , {KMi }i∈[N] , {Ei }i∈[M] )

1: Key manager KMi :


A.1 Ideal Blockchain 2: On input (“init”) from Z:
3: if found an entry (“km list”, KM) on Fblockchain
Fblockchain [succ] 4: send (“sync”) to KM for all KM ∈ KM
5: if any key manager replies with k
1: Parameter: successor relationship succ : {0, 1}∗ × {0, 1}∗ → {0, 1} 6: set kmaster := k
2: On receive (“init”): Storage := 0/ 7: try to store (“km list”, KM ∪ {KMi }) on Fblockchain // overwrite
3: On receive (“read”, id): output Storage[id], or ⊥ if not found 8: if receive “reject” from Fblockchain : restart current “init” call
4: On receive (“write”, id, inp) from P: 9: else : k ←$ {0, 1}λ ; store (“km list”, {KMi }) on Fblockchain
5: let val := Storage[id], output ⊥ if not found 10 : if receive “receipt” from Fblockchain : set kmaster := k
6: if succ(val, inp) = 1 then 11 : else : restart current “init” call // retry on race condition
7: Storage[id] := val k (inp, P); output (“receipt”, id)
12 : On input (“get-key”, type) from E ∈ {Ei }i∈[M] :
8: else output (“reject”, id)
13 : if found an entry (E, type, kct ) on Fblockchain :
9: On receive (“∈”, id, val):
14 : send Dec(kmaster , kct ) to E
10 : if val ∈ Storage[id] then output true else output false
15 : else generate a key as follows:
16 : k ←$ KGen(1λ , keyType);
Figure 10: Ideal blockchain. The parameter succ defines the
17 : store (E, type, Enc(kmaster , k)) on Fblockchain
validity of new items. A new item can only be appended to the
18 : if receive “receipt” from Fblockchain : send k to E
storage if the evaluation of succ outputs 1.
19 : else : restart current “init” call // retry on race condition
20 : On input (“sync”) from KM ∈ {KMi }i∈[N] : send kmaster to KM

21 : Contract TEE Ei :
A.2 Protocol for Key Managers 22 : internal subroutine keyManager(type): // called in Fig. 4
23 : if found an entry (“km list”, KM) on Fblockchain :
24 : randomly choose a key manager KM ←$ KM
25 : send (“get-key”, type) to KM;
26 : wait for k with timeout T ; if timeout: restart current “get-key” call
27 : return k
28 : else : return ⊥

Figure 11: The protocol for a key manager. Communication be-


tween key managers and contract TEEs is implicitly encrypted
and authenticated via secure channels established through re-
mote attestations.

B Proof of Theorem 1
We prove that ProtEkiden [λ , AE, SE, Σ, {Pi }i∈[N] ] UC-
realizes the ideal functionality FEkiden [λ , `, {Pi }] with
respect to a leakage function `(x) that outputs a random
ciphertext with length |x|. In particular, `(·) maintains a
set L and `(x) is evaluated as follows: let C be the cipher-
text space. If ∃(x, r) ∈ L, `(x) returns r; otherwise, returns
r ←$ {c ∈ C : |c| = |x|} and add (x, r) to L. In the proto-
col, `(·) is realized with IND-CPA encryption schemes.

Proof. Let Z be an environment and A be a “dummy


adversary” [19] who simply relays messages between Z
and parties. To show that ProtEkiden UC-realizes FEkiden ,
we specify below a simulator Sim such that no environ-
ment can distinguish an interaction between ProtEkiden
and A from an interaction with FEkiden and Sim, i.e. Sim
satisfies

∀Z, EXECProtEkiden ,A,Z ≈ EXECFEkiden ,Sim,Z .

22
Construction of Sim. Sim generally proceeds as fol- • Upon receiving `(st) and `(outp) from FEkiden ,
lows: if a message is sent by an honest party to FEkiden , Sim computes c = Enc(kout cid , 0) and sends
Sim emulates appropriate real world “network traffic” for ((“atom-deliver”, H(inpct ), H(s), `(st), H(c)), σTEE , c)
Z with information obtained from FEkiden . If a message from Gatt to Pi . Sim records c.
is sent to FEkiden by a corrupted party, Sim extracts the • If Pi sends a “resume” message to Gatt with input
input and interacts with the corrupted party with the help (“claim output”, cid, (st0ct , outpct , σ , epki )), Sim em-
of FEkiden . We provide further details on the processing ulates Gatt as follows: Sim first checks that Gatt has
of specific messages. previously sent outpct to Pi and that (st0ct , σ ) has
been stored by Fblockchain . Sim aborts if any of the
(1) Contract creation: above checks fails. Sim obtains outp from FEkiden
and sends (“output”, Enc(epki , outp), σ ) to Pi .
• If Pi is honest, Sim obtains (Pi , cid, Contract) from
FEkiden and emulates an execution of the “create”
call of ProtEkiden . (3) Public read: On any call (“read”, cid) from Pi ,
• If Pi is corrupted, Sim extracts Contract from Z. Sim emulates a “read” message to Fblockchain . If Pi is
On behalf of Pi , Sim sends (“create”, Contract) to corrupted, Sim sends to FEkiden a “read” message on Pi ’s
FEkiden and instructs FEkiden to deliver the output. behalf and forward the response to A.
• In both cases, Sim simulates the interaction between
Fblockchain and Gatt , on behalf of the adversary or hon- (4) Corrupted enclaves: Sim obtains eids of cor-
est parties. rupted enclaves when Z corrupts them. In real world, Z
could terminate a corrupted enclave at any point, or could
(2) Query execution: strategically drop some messages while letting others go
through. To faithfully emulate Z’s “damage”, Sim sends
Case 1: When an honest party Pi is given input every messages leaving or entering a corrupted enclave
(“request”, cid, inp, eid) by Z, Sim works as follows: to Z and only delivers the message if Z permits. Sim
• Upon receiving (cid, Pi , `(inp)) from FEkiden , Sim instructs FEkiden to abort if the emulated execution is ter-
queries the “read” interface of FEkiden to obtain the minated by Z prematurely. Specifically, upon receiving
dummy state (i.e. a random string with the same (cid, `(st0 ), `(outp), eid) from FEkiden , Sim replies with
length as the real state) of cid, denoted s. Sim com- “ok” only if the corresponding “output” message from
putes cinp = Enc(pkin ~
cid , 0) with length `(inp), and Gatt is allowed by Z.
emulates a “resume” message to Gatt with input
(“request”, cid, cinp , s) on behalf of Pi .
Validity of Sim. We show that no environment can dis-
• Upon receiving `(st0 ) and `(outp) from FEkiden , Sim
out tinguish an interaction with A and ProtEkiden from one
computes c = Enc(kcid ,~0) and emulates a message
with Sim and FEkiden by hybrid arguments. Consider a
((“atom-deliver”, H(cinp ), H(s), `(st ), H(c), spki ), σTEE , c)
0
sequence of hybrids, starting with the real protocol exe-
from Gatt to Pi .
cution. Hybrid H1 lets Sim to emulate Gatt and Fblockchain .
• Sim proceeds by emulating the interaction
H2 filters out the forgery attacks against ΣTEE . H3 filters
between Fblockchain and Gatt , and a message
out the second pre-image attacks against the hash func-
(“output”, Enc(epki ,~0), σTEE ) with length |outp|
tion. H4 has Sim emulate the creation phase. H5 replaces
from Gatt to Pi .
the encryption of input and output with encryption of 0,
• Finally, Sim instructs FEkiden by sending a “ok” mes-
and replaces encryption of states with random strings
sage.
with the same length. The indispensability between ad-
Case 2: When a corrupted party Pi is given input jacent hybrids are shown below.
(“request”, cid, inp, eid) by Z, Sim learns the input when
Sim works as follows: Hybrid H1 proceeds as in the real world protocol,
• If Pi sends (“read”, cid) to Fblockchain , Sim obtains except that Sim emulates Gatt and Fblockchain . Specially
the latest state (denoted s) from FEkiden , and sends s Sim generates a key pair (pkTEE , skTEE ) for ΣTEE and
to Pi on behalf of Fblockchain . publishes pkTEE . Whenever A wants to communicate
• If Pi sends a “resume” message to Gatt with with Gatt , Sim records A’s messages and faithfully em-
input (“request”, cid, inpct , s), Sim emulates Gatt ulates Gatt ’s behavior. Similarly, Sim emulates Fblockchain
as follows: Sim queries FEkiden to check if s by storing items internally.
is not the latest state, Sim aborts. Sim com- As A’s view in H1 is perfectly simulated as in the real
putes inp0 = Dec(skin cid , inpct ). Then Sim sends world, Z cannot distinguish between H1 and the real exe-
(“request”, cid, inp0 , eid) to FEkiden on Pi ’s behalf. cution.

23
Hybrid H2 proceeds as in H1 , except for the follow- where c0 = Enc(pkin cid , 0), and any message
ing modifications. If A invoked Gatt with a correct mes- (“output”, AE.Enc(kout
cid , outp)) sent from Gatt to Pi
\ then for all sequential “resume”
sage (“install”, Contract), is replaced with (“output”, Enc(epki , 0)).
calls, Sim records a tuple (outp, σTEE ) where outp is the Indistinguishability between H5 and H4 can be directly
\ and σTEE is an attestation under skTEE .
output of Contract reduced to the IND-CPA property of AE and SE. Hav-
Let Ω denote the set of all such tuples. Whenever A sends ing no knowledge of the secret key, A cannot distinguish
an attested output (outp, σTEE ) 6∈ Ω to Fblockchain or an encryption of ~0 from encryption of other messages. Note
honest party Pi , Sim aborts. that we don’t require IND-CCA security because A do
The indistinguishability between H1 and H2 can be not have direct access to an decryption oracle.
shown by the following reduction to the the EU-CMA It remains to observe that H5 is identical to the ideal
property of Σ: In H1 , if A sends forged attestations to protocol. Throughout the simulation, we maintain the fol-
Fblockchain or Pi , signature verification by Fblockchain or lowing invariant: FEkiden always has the latest state, re-
an honest party Pi will fail with all but negligible proba- gardless who created the contract and who has queried the
bility. If Z can distinguish H2 from H1 , Z and A can be contract. This invariant ensures that H5 precisely reflects
used to win the game of signature forgery. ideal execution of FEkiden .

Hybrid H3 is the same as H2 besides the following


modifications. If A invoked Gatt with a correct “request” C Ekiden Performance Extensions
message, Sim records execution result outpct before out-
putting it. Whenever A sends to Gatt a “claim output” In this section we discuss several performance optimiza-
message with a input outp0ct that is not previously gen- tions to the simple protocol. Together, these optimizations
erated by Gatt , Sim aborts. reduce the number of round trips and storage capacity re-
The indistinguishability between H3 and H2 can be quired from the blockchain, and reduce work for compute
shown by a reduction to the second pre-image resis- nodes. As we show in Section 7, the impact is significant,
tanceproperty of the hash function.
 In H2 , A obtains up to 200% better for write-heavy workloads. Despite the
H = H(outpict ) i and O = outpict i from Gatt through performance improvements, all optimizations are trans-
“request” calls. If A sends a “claim output” message with parent to the security interface: we use the same ideal
outpct 6∈ O, Gatt aborts unless a H(outpct ) ∈ H. If Z can functionality for both the simple and extended protocols.
distinguish H3 from H2 , it follows that A can break the We present a formal protocol block defining the enhanced
second pre-image resistancy. protocol Protfull
Ekiden in Figure 13. For now, we provide a
high-level description of the insight and challenges in-
Hybrid H4 is the same as H3 but has Sim emu- volved in each application.
late the contract creation, i.e. honest parties will send
“create” to FEkiden . Sim emulates messages from Gatt and
Using a write-ahead log: In the original protocol, the
Fblockchain as described above. If Pi is corrupted, Sim
entire encrypted state stct is written to the blockchain af-
sends (“create”, Contract) to FEkiden as Pi .
ter each query. The entire state needs to be re-encrypted
It is clear that the A’s view is distributed exactly as in
because the modification side-effect should not leak infor-
H3 , as Sim can emulate Gatt and Fblockchain perfectly.
mation to the adversary. However, this approach is ineffi-
cient when each st is very large yet each query modifies
Hybrid H5 is the same as H4 except that honest par- only a small part. In our Token application, for example,
ties also sends “request” messages to FEkiden . If Pi is cor- we model a token with 500,000 different user accounts,
rupted, Sim emulates real-world messages with the help even though each transaction only debits one account and
of FEkiden , as described above. credits one other.
In A’s view, the difference between H5 and H4 are the Our first observation is that the use of a write-ahead
following. log can reduce this expense. We modify the protocol
• Any message (“atom-deliver”, hinp , hprev , s, houtp , c) so that only the “diff” of the state, ∆stct is written to
sent from Gatt to Pi with s = SE.Enc(kstate 0
cid , st ) the blockchain. To determine the current state, the en-
out
and c = SE.Enc(kcid , outp)) in H4 is replaced with clave must parse the entire diff sequence, starting from
(“atom-deliver”, hinp , hprev , `(st0ct ), H(c0 ), c0 ) where the initial state, and applying each patch. In the token
c0 = Enc(kout |c|
cid , 0 ). application, each transaction touches a constant number
• If Pi is honest, any message of records, hence requiring O(M + T ) storage complex-
(“request”, cid, AE.Enc(pkin cid , inp), s) from Pi ity for T transactions if there are M users, compared to
to Gatt is replaced with (“request”, cid, c0 , s) O(MT ) in the simple protocol.

24
The encryption of the diff ∆stct may leak information guarantees of FEkiden hold regardless of this choice. As
about which query was invoked. The token application a pragmatic solution, we propose to have clients defer
has constant-time queries, but in general applications, it to centralized coordinators that perform load balancing
may be necessary to bound the size of queries and pad and random assignment of compute nodes to tasks, based
the ciphertext. Finally, we note that the ideal functionality on reputations and prior experience. If a task is not com-
FEkiden is parameterized by a leakage function `, such pleted after some timeout, the coordinator can signal the
that the notation is in place to model the effect leakage client to repeat the query at another enclave. Randomiza-
resulting from unpadded queries. tion can ensure that a host cannot adaptively choose a par-
ticular target task to degrade service. In this way Ekiden
would prevent an adversary from degrading service for
Caching intermediate states at the enclave: In the
targeted applications. Following other work, incentives
simple protocol, each round begins with reading the state
can be aligned by having compute miners make security
ciphertext from the blockchain, and ends with writing the
deposits before they are assigned to a task.
next state ciphertext from the blockchain. In the case that
In our extended protocol, we optimistically use the pre-
vious state in the Cache, if available. This results in a C.1 Sample Contract Source
performance improvement when the same enclave eid is
used for multiple sequential queries. This is especially
beneficial when the write-ahead log grows large. 1 pub struct TokenContract {
2 balances: HashMap<Addr, uint>,
Bootstrapping from genesis seems to be necessary 3 }
whenever a query is sent to a new enclave (e.g., because 4
the previously-used enclave host has crashed). In prac- 5 impl TokenContract {
tice, we also define a policy for checkpoints by storing 6 ...
7 fn transfer(&mut self, sender: &Addr, to: &
the entire state (not just the diff) after every fixed num- Addr, value: uint) ->
ber of intervals. We leave the formal presentation of this 8 Result<(), Error> {
generalization to future work. 9 let from_acct = self.balances.get(sender)?;
10 let to_acct = self.balances.get(to)?;
11 if from_acct < value {
Batching transactions off-chain: Just as the caching 12 return Err(Error::new("low balance"));
optimization above removes the need to read from the 13 }
14 let from_acct = from_acct - value;
blockchain in each query, we can also coalesce the writes 15 let to_acct = to_acct + value;
for multiple sequential queries into a single message to 16 self.balances.insert(sender, from_acct);
the blockchain. This reduces both the number of net- 17 self.balances.insert(to, to_acct);
18 return Ok(());
work round trips, as well as the total communication
19 }
cost. When multiple queries in a batch write to the same 20 ...
location, only the last write needs to be stored on the 21 }
blockchain.
In our protocol we do not define a policy for how many Figure 12: Token contract code.
transactions must go in a batch. Instead, we formally ex-
pose this choice to the adversary. The choice of batch-
ing strategy has no impact on the security guarantees
of our formalism. Each query invocation simply stores
the inputs in a buffer, and the adversary can invoke the
commitBatch method at any time to commit the entire
buffer.
Batching is not a panacea. In order to maintain security,
the decrypted outputs must not leave the enclave unless
the updated state ∆stct is committed in the blockchain.
Hence a user cannot receive output from a query until the
entire batch is committed, and so only input-independent
queries can appear in the same batch.

Coordinating the choice of compute nodes: The Eki-


den protocol leaves it up to the client to decide which
compute node and enclave to query. All of the security

25
Protfull \
Enclave program Contract
Ekiden ({Pi }i∈[N] )
Clients Pi : Local state: Cache := 0,
/ Batch := 0/
Initialize: (sski , spki ) ←$ Σ.KGen(1λ ), (eski , epki ) ←$ AE.KGen(1λ ) On input (“create”)
On input (“create”, Contract) from environment Z: cid := H(Contract)
cid := create(Contract) (pkin in
cid , skcid ) := keyManager(“input key”)
assert cid has been stored on Fblockchain state
kcid := keyManager(“state key”)
output (“receipt”, cid) st0 := SE.Enc(kstate ~
cid , 0)
On input (“request”, cid, inp, eid) from environment Z: Cache[cid] = st0 // cache state locally
obtains pkin
cid from Fblockchain return (Contract, cid, st0 , pkin
cid )
letinpct := AE.Enc(pkin
cid , inp) On input (“request”, cid, inpct , σPi , stct ) from P:
σPi := Sig(sski , (cid, inpct )) assert Σ.Vf(spki , σPi , (cid, inpct ))
(∆stct , outpct , σ ) := query(cid, inpct , σPi ) add (inpct , spki ) to Batch[cid]
parse σ as (σTEE , hinp , hprev , houtp , spki )
On input (“commit batch”, cid, inp):
assert σ verifies 
assert ∃n s.t. hninp = H(inpct ) make a local copy of Batch and parse it as (inpct i , spki ) i∈[N]

o := claim-output(cid, ∆stct , outpct , σ , epki ) reset the global batch: Batch = 0/


// if the previous state has been used by a parallel query // retrieve pkin in state
cid , skcid , kcid from keyManager as above

if o = ⊥ then: jump to the beginning of this call inpi := AE.Dec(skin i


cid , inpct ) for i ∈ [N]
parse o as (outp0ct , σTEE ) if Cache[cid] = ⊥ ∧ inp = ⊥ then :
assert ΣTEE .Vf(pkTEE , σTEE , outp0ct ) // pkTEE := Gatt .getpk() return (“cache miss”)
output AE.Dec(eski , outp0ct ) if Cache[cid] = ⊥ then :

On receive (“commit batch”, cid, eid) from A: send (“∈”, cid, inp) to Fblockchain ; wait for true or abort
// optimistically commit a batch without providing state parse inp as st0ct k {∆stnct }n
send (eid, “resume”, (“commit batch”, cid, ⊥)) to Gatt reconstruct latest state and store it at Cache[cid]
if receive (“cache miss”) from Gatt then kout
cid := keyManager(“output key”)

send (“read”, cid) to Fblockchain let st[0] = Cache[cid]


receive val from Fblockchain for i = 1 . . . N:
send (eid, “resume”, (“commit batch”, cid, val)) to Gatt st[i], outp[i] = Contract(st[i − 1], inpi , pki )
outpct [i] = SE.Enc(kout
cid , outp[i])
On receive (“read”, cid) from environment Z:
Cache[cid] = st[N] // cache the latest state
send (“read”, cid) to Fblockchain
∆st := diff(st[N], st[0])
receive val from Fblockchain and return val
hinp :=:= H(inpct [1]) k · · · k H(inpct [N])
Compute Node Subroutines (called by Pi ):
hprev := H(st[0])
On input create(Contract): houtp := H(outpct [1]) k · · · k H(outpct [N])
\ to Gatt , wait for eid
send (“install”, Contract) ∆stct := SE.Enc(kstate
cid , ∆st)
send (eid, “resume”, (“create”)) to Gatt outpct := outpct [1] k · · · k outpct [N]
wait for ((Contract, cid, st0 , pkin
cid ), σTEE ) from Gatt send ((hinp , hprev , ∆stct , houtp , spki ), outpct ) to all {Pi }i∈[N]
send (“write”, cid, (Contract, cid, st0 , pkin
cid )) to Fblockchain
On input (“claim output”, ∆stct , outpct , σ , epki ):
receive (“receipt”, cid) from Fblockchain and return
parse σ as (σTEE , hinp , hprev , houtp , spki )
On input query(cid, inpct , σPi ):
parse houtp as h1outp k · · · k hnoutp
send (“read”, cid) to Fblockchain and wait for stct
assert ∃n s.t. hnoutp = H(outpct )
send (eid, “resume”, (“request”, cid, inpct , σPi , stct )) to Gatt
send (“∈”, cid, (∆stct , σ )) to Fblockchain
receive ((hinp , hprev , ∆stct , houtp , spki ), σTEE , outpct ) from Gatt
receive true from Fblockchain
let σ := (σTEE , hinp , hprev , houtp , spki )
kout
cid := keyManager(“output key”)
return (∆stct , outpct , σ )
outp := SE.Dec(kout
cid , outpct )
On input claim-output(cid, ∆stct , outpct , σ , epki ): return (“output”, AE.Enc(epki , outp)) // reveal the output
send (“write”, cid, (∆stct , σ )) to Fblockchain
if receive (“reject”, cid) from Fblockchain : return ⊥
send (eid, “resume”, (“claim output”, ∆stct , outpct , σ , epki )) to Gatt
receive (“output”, outpct , σTEE ) from Gatt or abort
return (outpct , σTEE )

26
Figure 13: Enhanced Ekiden Protocol. diff(·, ·) is a function that takes in two states and output the difference.

Das könnte Ihnen auch gefallen