Security Assurances of Blockchains: Smart Contract

Abstract

A smart contract is an application which is executed on blockchains. It digitally enforces agreements between distrusting parties. Smart contracts inherit security assurances of blockchains, but their lack of privacy and confidentiality raises concerns and limits the applicability of smart contracts, while blockchains also constitute a performance bottleneck. Combining smart contracts with Trusted Execution Environments (TEEs) is one way of preventing unauthorized access and manipulation through untrusted blockchain nodes, thus resolving the privacy and confidentiality issues. This paper reviews four existing frameworks that incorporate Trusted Execution Environments in their smart contracts systems, examines the different architectures, discusses the individual strengths and shortcomings, and performs a detailed comparative evaluation of the four approaches in order to find the right combination of characteristics that a new generation smart contract should possess.

Index Terms — smart contracts, blockchains, TEEs, privacy, confidentiality

I. INTRODUCTION

Distributed ledgers and especially blockchains are emerging technologies that gained a lot of attention recently, since they constitute a new decentralized computing paradigm, which enables payments with cryptocurrencies such as Bitcoin [1] on the one hand, but also serve as the basis for smart contracts on the other hand. Smart contracts like Ethereum [2] are programs executed on blockchains, that define and enforce agreements between two or more parties, based on pre-agreed policies to access and update contract-specific data. Smart contracts have been proposed to improve applications across a range of industries, including finance, insurance, identity management, and supply chain management [3]. Typically, even the creator of a smart contract cannot feasibly modify its code or subvert its execution. The smart contract code is replicated on all participants within the network to ensure verifiability, fault tolerance and availability. But even though such smart contract systems provide a number of benefits, they exhibit several problems that limit their applicability, especially for certain domains of use cases, since they inherit some undesirable blockchain properties.

A. Motivation

As stated in [3], the most notable disadvantage of existing smart contract systems is the lack of privacy and confidentiality, which results from the distributed and publicly available nature of blockchain data. In order to verify correct computation and validate state transitions, contract methods are computed on every node of the network and the entire contract state is stored publicly, even if a contract deals with sensitive data and the blockchain nodes are owned by untrusted parties.

This procedure is a fundamental characteristic of distributed ledgers, which allows for transactions without intermediaries, but at the same time, it presents a data privacy issue, since it opens up the risk of potential information leakage or privacy threats such as data theft. As a result, privacy concerns create a demand for novel approaches in terms of smart contract systems, which are capable of safeguarding data access in some way.

According to [3] and [4], another problem of conventional smart contracts is the limited performance of most blockchain protocols with respect to computation power, transaction throughput and latency, which is also associated with high processing costs. Due to these issues, existing smart contract systems may fail to deliver key requirements, such as reasonable performance, as required by various use cases or enterprise applications. Therefore, the aim of new smart contract systems is to improve the transaction speed and latency, without imposing trade-offs regarding privacy and confidentiality.

Cryptographic protocols like secure multiparty computation, such as Enigma [5], or zero-knowledge proof systems like Zerocash [6] or Hawk [7] promise to provide a privacypreserving approach for blockchains by using cryptographic primitives. However, due to a relatively high performance overhead, they incur high costs and do not provide a generalpurpose solution, as stated in [3] and [8]. As an alternative approach, several papers propose the combination of smart contracts with Trusted Execution Environments (TEEs) as an attempt to tackle the limitations of smart contracts concerning privacy, confidentiality and performance. This is achieved by using trusted hardware that provides fully isolated execution environments, such as the Intel Software Guard eXtensions (SGX). Since Intel SGX, a CPU-based implementation of TEEs, constitutes the predominant TEE technology used in recently proposed TEE-backed smart contract solutions, the focus of the paper is primarily on this trusted computing technology.B. Trusted Execution Environments (TEEs) The Intel SGX offers secure hardware enclaves for executing computations with sensitive data, such as private data and confidential contract states, by implementing a memory encryption mechanism that enables an isolated and thus sealed address space. Therefore, the memory space cannot be accessed by the operating system, the host owner, or other applications and TEEs, as described in [3] and [8]. In order to realize this property, a key management mechanism is used to generate and handle public and private keys, which are needed for encrypting and decrypting sensitive data inside an enclave.

Before data leaves the TEE and can be stored on the ledger, it is encrypted with keys that are only known by the CPU of the associated hardware enclave. In this way, data integrity is ensured and unauthorized access, as well as data manipulation through untrusted blockchain nodes is prevented, so the lack of privacy and confidentiality is remedied.

Another important feature of TEEs is the support for attested execution due to a remote attestation mechanism, as mentioned by the authors of [3] and [8]. Remote attestations are digital cryptographic signatures proving the correct execution of a program within a TEE, which can be issued by an enclave during runtime. The attestation keys of an enclave, that are used to generate the digital signature, can be verified by means of an attestation protocol, e.g. the Intel Attestation Service (IAS), an endorsement certificate provided by the manufacturer, in this case Intel, that guarantees unforgeable and authenticated attestations by validating the TEEs. This procedure fosters verifiable computation by dispensing proofs of correctness, even if the enclaves run on potentially untruste nodes. As a result of shifting the computation to TEEs, the performance overhead is reduced and thus transaction speed, throughput and latency are improved, since computation is simplified due to the unencrypted processing of data [3]. Additionally, further performance optimizations are conceivable, depending on the particular solution approach.

In summary, TEEs can provide secure remote computation of sensitive data and by hybridizing TEEs and blockchains, smart contract systems can take advantage of both technologies in order to overcome problems arising from smart contract execution on blockchains in the clear. As a result, trustworthy and privacy-preserving smart contract systems with reasonable performance can be built, so the applicability of smart contracts is expanded to applications with strong privacy requirements, e.g. in the field of insurance companies. Recently, a number of TEE-hybridized smart contract systems have been developed. Existing solutions proposed by disparate research groups exhibit conceptual differences, but broadly, they can be divided into two categories, namely the ones with on-chain execution and those with off-chain execution of smart contracts. Both concepts are analyzed in the next section on the basis of four different TEE-based smart contract systems.

II. STATE OF THE ART

Compared to on-chain approaches, where smart contracts are executed within TEEs that are directly deployed on blockchain nodes, off-chain solutions propose the usage of special non-blockchain nodes that are equipped with trusted hardware [9]. Thus, the approaches exhibit opposed architectures and concepts, which are separately described in the following by means of two existing off-chain and two on-chain solutions, namely Private Data Objects [10], Ekiden [3], the Coco framework [4] and SCE-Fabric [8]. Both TEE-backed smart contract approaches imply benefits, but also disadvantages compared to their counterparts, which are identified and evaluated in the subsequent sections.

A. Private Data Objects

As introduced by [10], Hyperledger Private Data Objects (PDOs) represent an off-chain approach from Intel to run smart contracts involving private data on a distributed ledger leveraging TEEs.

1) System architecture: The architectural concept behind the execution of smart contract within PDO-based systems. It shows the main entities which are involved during smart contract execution, namely a Distributed Ledger, multiple Users, a Contract the parties agreed on, and an Enclave Hosting Service providing SGX enclaves.

PDOs make use of an SGX-based enclave hosting service, such as a cloud provider, enabling off-chain execution of contracts in Intel SGX enclaves, and are built upon Hyperledger Sawtooth as distributed ledger platform, which provides higher scalability compared to Hyperledger Fabric, since it is designed to be capable of scaling to a large number of nodes [10]. Additionally, Hyperledger Sawtooth can guarantee strong privacy and confidentiality requirements through the use of customizable transaction families, as described below, especially in combination with trusted computing. The ledger nodes are responsible for the verification and record of transactions which “allows contracting parties to retrieve and check data related to contract and enclave instances, as well as toserialize and commit contract state updates” [10]. Therefore, PDOs implement three types of custom transaction families, namely Contract Registry, Enclave Registry, and Coordination and Commit Log (CCL). They abstract the layer in such a way that each transaction family defines specific customized operations and rules to modify the state of the ledger. Each transaction submitted to the ledger has to comply with the rules of the associated transaction family, otherwise it will be rejected and thus not appended to the ledger. As the name already suggests, the Contract Registry transaction family defines the contract management, such as registering a contract and adding or removing enclaves authorized for the execution of a specific contract, whereas the Enclave Registry transaction family is responsible for transactions concerning the enclave management like the registration, update or revocation of an enclave. On the contrary, the CCL transaction family enables the construction of a dependency graph consisting of dependencies between state transition transactions, which “allow the specification and enforcement of the progression of a contract state conditional to the progression of other contract states, while enabling maximal concurrency among interacting contracts and ledger interactions” [10].

2) System initialization: Before a smart contract can be executed securely in trusted environments, a PDO instance needs to be created by registering the SGX enclaves and the contract on the ledger. First of all, an enclave needs to be verified by the Intel Attestation Service, in order to ensure trustworthy attestations, and then be registered on the ledger by the enclave hosting service as an enclave registration transaction, that includes the verification report produced by the IAS, the enclave owner and the enclave’s public keys. Such a transaction has to abide by the rules of the Enclave Registry transaction family.

On the contrary, the contract registration is initiated by the contract owner and divided into multiple phases. First of all, the registration of the contract on the ledger as a contract registration transaction takes place, which has to adhere to the rules defined by the Contract Registry transaction family and is followed by an execution authorization of the contract. During the execution authorization, the contract owner poses a key provisioning inquiry to so-called provisioning services in order to be able to supply the registered enclaves with cryptographic material as part of the subsequent contract enclave provisioning phase. The provisioned enclaves are then capable of encrypting and decrypting the state of the contract by using the keys provided by the provisioning services. This procedure allows for the contract state encryption to be enclave-independent and also enclave service-independent. During these phases, the contract owner acts as an intermediary between the ledger, the provisioning services and the enclave hosting services, so there is no direct interaction between the ledger and the TEEs. As the final step, the contract owner provides a proof of provisioning, signed by the enclave, to the ledger, which completes the contract registration and the execution authorization process, resulting in the disclosure of a set of provisioning services, as well as a list of authorized and provisioned enclaves for a specific contract on the ledger.

3) Transaction workflow: As soon as both the contract and the associated enclaves are registered on the distributed ledger, an authorized user is able to trigger smart contract method invocations, which are carried out by the contract interpreter of an enclave. Initially, when the first smart contract method is invoked by the user, the contract interpreter initializes an empty state. Subsequent method invocations might then lead to state updates. Fig. 3 demonstrates a contracts method invocation sequence within PDOs. Before a method can be invoked through a request sent from the user to the SGXhosting enclave service, the user has to be authenticated either by enclaves or by a contract, depending on the predefined policies. Subsequently, he has to fetch the latest contract state from the ledger. After the corresponding contract code is executed on the trusted hardware, the user receives the outcome of the computation from the enclave and can then submit a transaction including the resulting state transition to the ledger, which is verified and logged by the ledger nodes in terms of correct attestation before acceptance.

4) Security aspects: As outlined in Fig. 3, a user acts as a communication channel between the distributed ledger and the SGX enclave, which executes smart contract code. The channel concept forces the user to generate a new public/private key pair for each method invocation. By including the user’s signature and its public key in the method invocation and in the resulting transaction commit, the ledger nodes can verify whether the signature of the transaction belongs to the user who submitted it. This way, it is guaranteed that a transaction resulting from a specific method invocation is only committed by the user who actually invoked the method. Additionally, this mechanism ensures the privacy of a user, since different transactions cannot be correlated with a specific user.

In general, each enclave generates two public/private key pairs. The two private keys are stored within the enclave’s sealed memory, but their public counterparts are needed for the attestation, so these keys are registered on and can thus be retrieved from the ledger. The public verification key is used for validating the signature of the enclave, while the public encryption key is necessary for the provisioning of the confidential contract state to the enclave. The state of a contract “indicates the (private) data which a PDO associates to a specific contract” [10] and is available in plain text inside the enclave. Before a state leaves the TEE, it is encrypted by the enclave via the contract-specific encryption key and analogically, the enclave decrypts the state it receives from the user for computation purposes.

B. Ekiden

The second off-chain execution approach to combining blockchains with TEEs is called Ekiden. It represents an efficient and confidentiality-preserving smart contract system and was proposed in [3]. Ekiden is based upon Intel SGX as trusted hardware and exhibits an architecture that separates contract execution from consensus, which opens up the possibility to scale the nodes used for contract code computation independently from the ones maintaining the blockchain, and vice versa.

According to [3], using the platform produces minimal performance overhead through off-chain computation of smart contract data. This way, Ekiden is capable of efficiently supporting large-scale applications with strong privacy demands, while preserving availability and integrity as fundamental blockchain characteristics. Its functional prototype is built upon Tendermint as the consensus layer, but the architectural design facilitates its compatibility with different blockchain systems, either with permissioned (private) or permissionless (public) consensus-layer mechanics, since the only prerequisite for blockchain nodes is the capability of attestation validation.

1) System architecture: Ekiden provides an architecture consisting of three different types of entities, namely Clients, Compute Nodes and Consensus Nodes. Compute nodes can run smart contracts dealing with confidential data within SGX enclaves, but are also responsible for the key management. Therefore, each compute node is able to induct various TEE instances, either Contract TEEs or Key Manager TEEs. Contract TEEs are used to execute smart contract code and generate attestations as proofs of correct computation, whereas the whole key management is delegated to special key manager TEEs, which together form a key management committee (KMC) and are synchronized via the blockchain. Thus, the key manager TEEs are responsible for generating random and unbiased keys, as well as providing them to the contract TEEs through secure channels for data encryption and decryption.

On the contrary, consensus nodes maintain the blockchain and thus ensure consensus among the ledger nodes. The underlying blockchain system is characterized by a generalpurpose, distributed append-only ledger that persists encrypted and persistent contract states, as well as attestations issued by compute nodes in order to verify state transitions.

Finally, clients represent the end users that are able to create new smart contracts or run existing ones.

2) System initialization: A client must initiate the creation of a contract by sending a piece of smart contract code to a compute node, where the contract is initialized inside a contract TEE. The contract TEE generates a new contract ID, acquires a fresh contract-specific public/private key pair for client input encryption and decryption, as well as a symmetric secret state key for state encryption and decryption from one of the key manager TEEs. Afterwards, it generates a new, encrypted initial contract state and a remote attestation as proof of initialization correctness. Subsequently, the compute node retrieves a verification attestation from the Intel Attestation Service and sends the contract code, the public key associated with the contract ID, the encrypted initial state and both attestations to the consensus nodes, which verify the generated attestations and then store the remaining information received from the compute node on the blockchain in case of acceptance.

3) Transaction workflow: From then on, a client can request the execution of contract code by acquiring the contractspecific public key from the blockchain, encrypting its owninput data by means of the retrieved key and then sending the encrypted input together with the contract ID to a compute node. In the subsequent step, the contract TEE of the compute node obtains the contract code and the encrypted previous state from the blockchain. Together with the secret state key and the private key for input encryption/decryption that is provided by the key manager TEE, the state and the client input is loaded into the contract TEE. After the client input and the state is decrypted with the two provisioned keys, the contract code is executed, which produces a resulting output and an updated state. The last steps of this sequence include the transmission of the new encrypted state and an attestation to the consensus nodes, as well as the output to the client.

These messages need to be delivered atomically, so the output is only sent to the client if the consensus nodes accept the state transition as valid by verifying the TEE’s signature. The updated and encrypted state is then stored on the blockchain.

C. The Coco framework

In order to overcome limitations of public networks like Bitcoin and Ethereum, the Confidential Consortium (Coco) Blockchain Framework was developed by Microsoft. According to [4], it is an on-chain execution wherein there exists a trusted network of nodes which form the distributed ledger. The consortium identified that the existing public networks fail to meet important requirements including “acceptable transaction throughput and latency, confidentiality, effective governance, and computational efficiency” [4]. The TEEs used by the Coco Framework are primary Intel SGX and “Windows Virtual Secure Mode (VSM)” [4].

1) System architecture: A system based on the Coco framework is comprised of a distributed network of “trusted Validating Nodes (VNs)” [4]. The trusted enclave is contained inside a VN and the VNs together are running the framework as well as the blockchain protocol. Therefore, VNs accept transactions and participate in the network’s consensus algorithm. A VN can be run by an actor in the network. Depending on the purpose and policies of a consortium, an actor in the network can be a member or a participant. Members collectively decide which actors may transact on the network and can be seen as “governing bodies of a consortium” [4]. Participants, on th other hand, do not have any control over the governance or operation of the network. They carry out transactions on the network if allowed by the members. Depending on the chosen consensus algorithm, one or some VNs process transactions and execute smart contract code. It is mentioned in [4] that VNs are able to verify the identities of other VNs which is why they are considered to be fully trusted. This is not the case in public blockchain networks. Fig. 6 illustrates the architecture of the framework. To enable authorized end users without an identity to interact with the network, members and participants of the network provide front-end systems.

2) System initialization: According to [4], there are certain policies which govern the framework. These include the membership and VN list, code manifest, TEE manifest, and voting policies. In order to initialize the system, one of the members needs to bootstrap the first VN and upload a genesis constitution to the network. Prior to this, a virtual machine with a TEE, e.g. Intel SGX, has to be set up by the member.

Then he installs a supporting operating system and the Confidential Consortium Blockchain Framework along with the desired blockchain protocol. Once the network constitution has been uploaded, a communication channel is established between the VN and each front-end application. Lastly, the member uploads his “private/public key shares” [4], which are essential for ensuring data integrity and confidentiality. Once the network has been established, a member may make change proposals such as the inclusion or elimination of members, participants, and VNs, among others. All existing members are required to vote for the proposed changes to be implemented.

3) Transaction workflow: As mentioned earlier, transactions on the network can be performed by members and participants determined by the members. The Coco framework defines two kinds of transactions which are allowed on the network, namely “administrative transactions” and “application transactions” [4]. Administrative transactions are the transactions which take place for the governance of the network, e.g. the addition or removal of members, whereas application transactions are the regular business transactions which are submitted by end users to front-end systems of members andparticipants via the secure communication channel.

4) Consensus: Irrespective of the type of transaction, in order to implement a change in the network, reaching consensus is essential. “The Confidential Consortium Blockchain Framework is designed to support pluggable consensus algorithms with plans to integrate Paxos-like consensus algorithms and Ceasar consensus, an algorithm from Microsoft Research” [4].

5) Secure communication: To ensure that network transactions can be performed only by valid VNs and to limit the visibility of the transactions to them, the Coco Framework enforces secure “application-to-node and node-to-node” [4] communication channels. Transport Layer Security connections and data encryption throughout the network restrict the accessibility of data to within the enclave of the VN.

D. SCE-Fabric

This section introduces an on-chain solution for Secure Chaincode Execution for Hyperledger Fabric (SCE-Fabric) and its corresponding prototype enabling smart contract execution within Intel SGX enclaves, as proposed by [8]. Fabric represents an open-source blockchain platform and is one of the projects of Hyperledger [12] of the Linux Foundation. By following a “novel execute-order-validate paradigm” [8] for the execution of smart contract code, this solution attempts to maximize flexibility, scalability, resilience, and confidentiality of the blockchain network. Although in Fabric, smart contract code execution occurs across many nodes, it gives an impression of execution on a single globally-distributed blockchain computer.

1) System architecture: The SCE-Fabric prototype adopts a modular architecture. As expected from a TEE-based blockchain system, the smart contract code execution takes place inside the trusted enclave, thus separating it from the peer. Outlines the principal components of the system which include: a Chaincode enclave, a Ledger enclave, an Enclave registry and an Enclave transaction validator. Chaincode enclave. It is inside the chaincode enclave where the chaincode execution takes place following the specifications of the smart contract. The enclave also contains the chaincode library, which extends the Fabric interface with “additional support for state encryption, attestation, and secure blockchain state access” [8].

• Ledger enclave. It maintains the ledger as an integrityspecific metadata, which represents the most recent blockchain state. Upon the arrival of a new block, it generates a cryptographic hash of every key-value pair in the blockchain state and stores the hash inside the enclave. The integrity-specific metadata can be accessed through the interface to the enclave and in this way, the correctness of the retrieved data is verified.
• Enclave registry. Running outside of the SGX enclave, it is responsible for maintaining the list of all chaincode enclaves present within the network and performing attestation with the chaincode enclave.
• Enclave transaction validator. It is responsible for checking the validity of signatures on the transaction and ensuring that it is issued by a registered enclave. It sends valid transactions to the ledger enclave, where the decision is verified before the transaction is finally committed to the ledger.

2) System initialization: It is with the genesis block, containing the expected hash, that the ledger enclave is initialized. The ledger enclave proceeds with the initialization only if the actual hash obtained by the peer matches the expected value. It then generates a pair of private/public keys so that the ledger enclave can be uniquely identified. The ledger enclave also receives public keys of the peers, clients and the “ordering service” [8], which are used for the authentication of transactions it will receive. The ordering service is a component in the Fabric network which “establishes the total order of all transactions and broadcasts them as blocks of transactions to all peer in the network” [8].

3) Transaction workflow: The chaincode execution is triggered, when a client first proposes a transaction and sends it to the peer. The peer receives it and sends it to the chaincode enclave. After the chaincode execution is performed, a response it sent to the peer, which forwards it to the client. The client then extracts the results of the performed execution and sends the transaction to the ordering service. The transactions that are accepted by the ordering service are assigned to blocks and broadcast to all peers present in the blockchain network. Peers are required to validate the transactions so that the transaction process can be finalized. In order to validate the transactions and to confirm the chaincode enclave which created the transaction, a peer utilizes a “validationsystem chaincode (VSCC)” [8]. Fig. 9 graphically explains the validation process. Once the enclave transaction validator declares that the transaction is valid, consequently, the local ledger of the peer and the blockchain state need to be updated.

III. EMERGING CONCERNS AND TECHNICAL CHALLENGES

So far, the design, system architecture, initialization and the key aspects of the transaction workflow of four different solutions, where smart contracts are executed within TEEs, were described. Although there are notable differences between the on-chain and off-chain approaches, all four prototypes discussed earlier, aim at securing blockchains for keeping transaction data secret. They offer several advantages, however, executing smart contracts within a TEE also introduces several challenges. For instance, since TEEs are generally stateless and thus susceptible to rollback attacks as described below, it might lead to loss of confidentiality [8]. In this section, we will be looking into some of the technical obstacles associated with the execution of smart contracts within TEEs, how existing solutions attempt to overcome them, as well as other emerging concerns which are yet to be addressed and not entirely resolved by the existing frameworks.

As mentioned earlier, the support for attested execution through a remote attestation mechanism is a key feature of TEEs. Attestation allows the clients to verify that the correct smart contract is loaded and executed in a genuine TEE, which is crucial for establishing trust in a smart contract within a TEE at a potentially untrusted node. However, attestation is expensive as it usually requires an interactive protocol [9]. The attestation protocol of Intel SGX involves consulting a third party, the IAS, for every attestation. The four solutions introduced before avoid this by performing the attestation only initially and storing the attestation result on the ledger.

According to [9], attestation is currently only supported by a subset of available TEEs like Intel SGX. To prevent TEE vendor lock-in and provide interoperability, it is necessary that the industry adopts a common set of security features including attestation as also suggested by the Keystone-enclave project [13].

Another problem faced by most public blockchains patterned after Bitcoin [1], is that they do not reach consensus with finality. “Their consensus mechanism is based on a randomized protocol, in which for each epoch (or “block height”) a node selected through a probabilistic scheme that is difficult to bias (such as a “proof of work”) disseminates a block of transactions to be appended to the blockchain” [8]. These blocks are propagated to all nodes within the network following an efficient peer-to-peer gossip protocol. However, strict consistency is still not guaranteed. When a node receives a block as candidate for extending the current chain, the node has to validate the contents of the block and ensure that all transactions inside the block are correct. In terms of Bitcoin, the validation step means to only check that a coin state has not been spent earlier, but for blockchains like Ethereum, validation includes the execution of all transactions and the computation of the corresponding state updates. If the block is valid, consequently, the node appends it to the local chain and updates the state. However, while later receiving other valid blocks, there is still a possibility that a node reverts the previously received transactions and therefore, there can never be consensus with finality. A node is compelled to continue participating in the consensus protocol endlessly in order to ensure the validity of its blockchain state. From this discussion and the analysis performed by [8], it is clear that TEEs cannot be used in the case of blockchains based on non-final consensus. “Blockchains with consensus that has no final decisions, such as the proof of work in Bitcoin or Ethereum, are inherently unable to benefit from TEEs to maintain confidentiality” [8]. By allowing the execution of only final transactions on the TEE, trying to roll back its state would lead to an attack. A common way to prevent rollback attacks is to ensure state continuity through specific mechanisms, e.g. by enforcing that the enclave’s state input for contract execution always matches the blockchain state which is committed by all peers, as stated in [8].

The support for non-deterministic transactions, incorporating randomness in their computation, constitutes another challenge for TEE-backed smart contract systems. Theoretically, this issue can be addressed by executing transactions inside only one TEE and applying the resulting state on all ledger nodes, but as mentioned in [9], it is practically impossible to check whether the computation is correct, especially since enclaves can be compromised and thus the integrity of the computation is not ensured anymore. This makes it difficult to differentiate between a non-deterministic transaction and a compromised enclave, whereby the need for appropriate mechanisms arises, but such mechanisms still have to be developed in order to overcome this problem.

By now, it is clear that TEEs aim to protect confidentiality. However, side-channel attacks on smart contract systems might lead to data leakage, as stated in [3]. Since there is currently no general-purpose approach to safeguard such a smart contract system from side channel attacks, protective measures are not introduced by all of the solutions presented above. “Key management is fundamental to the availability of a TEE-blockchain system” [3], but the question arises, how the encryption keys can be persisted. Replication of keys across multiple TEEs poses the risk of key exfiltration as in case of confidentiality breaches through side-channel attacks. So there is a trade-off between availability of the replicated keys and the risk of exposure, since “a higher replication factor means not only better resiliency to state loss, but also a larger attack surface” [3].

While several other concerns regarding the execution of smart contracts within TEEs have been mentioned in [3], [4], [8] and [10], one of the biggest arguments against the usage of TEEs is that they do not guarantee availability. In case of SGX, a malicious host can terminate enclaves, and even an honest host could lose enclaves in a power cycle. Malicious hosts might also manipulate the scheduling or I/O of a TEE, as well as drop messages arbitrarily. Availability failures can lead to the risk of having conflicting states or even losing the state [3]. As proposed by [9], a possible solution to limit this risk is the execution of the same contract code on multiple nodes, but this approach, in turn, imposes further technical challenges.

Besides side-channel attacks and availability failures, timer failures can also occur as a fully trusted timer is not guaranteed within SGX enclaves. Malicious hosts are able to delay the clock read, which can lead to an outdated view of the blockchain inside the TEE or computation with stale input states [3]. In general, proposed solutions should provide means to identify compromised TEEs and tolerate or rather eliminate such enclaves. Additionally, the impacts of TEE failures should be dammed as far as possible. From the discussion above, we can infer that several pitfalls arise when harmonizing TEEs and blockchains. While some of these may serve as building blocks for the conceptual design of prototypes, others still pose serious risks and need to be addressed by the new generation of smart contract protocols.

IV. COMPARATIVE EVALUATION OF PROPOSED SOLUTIONS

The choice of smart contract system has many implications, since they all have different properties, even though they rely on the same idea, that is combining smart contract execution with trusted computing through TEEs. Each of the proposed solutions mentioned above can yield benefits, but also exhibits some shortcomings, which are identified and evaluated in the following.

A. Architectural differences

While all of the four solutions have in common that they are built upon Intel SGX and therefore support attestations for proofs of execution correctness, their individual designs and implementations show remarkable differences. As stated above, the categorization into on-chain and off-chain smart contract execution directly affects the architecture of those systems, but nevertheless, the specific solutions for the different kinds of approaches also differ in their architectural composition concerning the entities involved, their particular roles and how they interact with each other. While both offchain approaches, Ekiden and PDOs, only encapsulate the smart contract code execution in SGX enclaves by means of special TEE nodes and persistently store the current contract state on the ledger in an encrypted manner [3], Coco and SCEFabric as on-chain approaches make use of TEE-equipped blockchain nodes [9]. The Coco framework implements nearly  its whole functionality within an enclave on a blockchain node as stated in [4] and [9], so the local ledger and also the state management is maintained inside the TEE. As a result, the size of trusted computing base (TCB) is relatively large. SCEFabric, on the other hand, extends a Hyperledger Fabric peerby two enclaves, namely a chaincode enclave and a ledger enclave [8], as described above. This way, SCE-Fabric only consigns a fraction of the blockchain node responsibilities to a TEE and leaves the rest within an untrusted environment, which leads to a smaller TCB size as opposed to Coco and thus decreases the attack surface [8].

The architectural choices also imply that on-chain TEEs have direct access to the local ledger, while the state of a contract needs to be retrieved from the blockchain when using off-chain enclaves, which can result in complex mechanisms [9]. Coco and SCE-Fabric create a network that is likely to be composed of known, approved and hence trusted peers [4], [10], while PDOs are also designed for private and permissioned settings. Ekiden, on the contrary, can be used in permissioned, as well as in permissionless settings [3].

B. Consensus layer dependency

Since on-chain approaches aim to provide ledger nodes with TEEs, the enclaves need to be integrated into the blockchain nodes properly, which is why SCE-Fabric, as the name suggests, is dependent on Hyperledger Fabric as distributed ledger technology [8]. The goal of the Coco framework is to support multiple consensus protocols through pluggable consensus algorithms [4], but its initial prototype is built upon Ethereum. On the contrary, off-chain solutions make use of a ledger abstraction that generally enables them to run on different blockchain systems [9]. The Ekiden prototype implements Tendermint as consensus layer [3] and the PDO project relies on Hyperledger Sawtooth [10].

C. Key management

Another property that allows for distinction is the key management mechanism used by each of the solutions. In this sense, Ekiden maintains key manager TEEs that together form a key management committee, share a secret key for every contract among each other and provide the contract TEEs with public/private key pairs [3]. On the contrary, PDOs make use of key-provisioning services that supply the enclaves with cryptographic material for encryption and decryption [10], thus the availability risk of TEEs is limited. Coco consigns the key management to an on-premise or a cloud-based key management system, e.g. a hardware security module (HSM) [4], where the generated private keys persists, while the corresponding public keys of consortium members or participantsis stored on the blockchain. Finally, SCE-Fabric offers either client-based encryption for state encryption, where the key management is performed by the client, or encryption per chaincode, where the admin has to provide the chaincode enclaves with a chaincode-specific key during the bootstrapping phase [8].

D. Scalability

Concerning the scalability of smart contract system, the proposed approaches exhibit different capabilities. While the PDO system exhibits a stronger focus on scalability than Ekiden [10], in general, both systems are relatively easy to scale, since the number of TEE-backed computing nodes and the number of blockchain nodes can be increased independently from each other [3]. According to the whitepaper published by Microsoft, Coco provides a high-scale framework that “approaches the performance and scalability of a traditional, centralized database” [4]. Compared to Hyperledger Sawtooth, Hyperledger Fabric is not as scalable [10], so SCE-Fabric systems do not necessarily exhibit as high scaling capabilities as PDOs.

E. Performance evaluations

In terms of project and implementation status, Ekiden and SCE-Fabric have provided prototypes and evaluation reports on different measurements like throughput or latency, carried out for specific applications. The Ekiden prototype “achieves example performance of 600x more throughput and 400x less latency at 1000x less cost than the Ethereum mainnet” [3] for the ERC20 token standard. Conversely, the SCE-Fabric prototype “reaches 0.80x-0.95x of the throughput achieved by the native execution” [8], whereby the native execution refers to using the Hyperledger Fabric implementation without SGX enclaves. At the same time, it exhibits a 10-20% overhead for a sealed-bid application caused by encapsulating the smart contract execution in a TEE [8]. Coco, on the other hand, describes two demos performed with a functional prototype of the framework, that is based on Ethereum, focusing on scalability and confidentiality. The outcome of the demos shows that “transaction rates were roughly 100 times faster than for a non-framework based protocol” [4]. On the contrary, the PDO paper did not mention any evaluations, but points out that it is an open source Hyperledger Labs project, which lays a foundation for further development and demonstrations [10].

Since the measurements were only carried out for certain applications that differ among the approaches, no general conclusion can be drawn from the results as to which of the solutions has the best overall performance. However, so far, Ekiden’s results seem more promising and its performance outweighs the other three.

F. Non-deterministic transactions

As stated in the previous section, there are several challenges that arise from combining smart contracts with TEEs. The proposed solutions attempt to tackle some of them, but there is no approach that solves them all. For instance, to the best of our knowledge, only the Coco framework allows the execution of non-deterministic transactions [4]. Similar to SCE-Fabric, which states that transactions are by default deterministic [8], Ekiden simply defines a smart contract as “a deterministic stateful program” [3] and thus contract methods need to be deterministic as well. The PDO paper [10] does not mention any support for executing non-deterministic transactions.

G. Compromised system components

Compromised components of the systems have different impacts depending on the solution approach. Since a compromised enclave might possibly affect the whole network by exposing confidential data or committing incorrect transactions, aiming to minimize the potential attack surface is essential. Additionally, the primary design goals should comprise the detection of malicious components, the minimization of their impact and the harm they might cause on the system, as well as, the elimination of such components. In this sense, PDOs distinguish between data confidentiality breaches and integrity breaches. A confidentiality breach means that an enclave is compromised and thus private data can be exposed, while execution correctness is still given. In the case of an integrity breach, computation correctness might also be compromised [10]. PDOs provide mechanisms to protect against both attacks, e.g. in order to maintain confidentiality, the implemented methods include using enclaves from reputable enclave hosting services and reducing the number of provisioned enclaves per contract, but this approach involves a trusted third party for providing the enclaves. Even though confidentiality might not be guaranteed at all times, the execution integrity can still be preserved by verifying the computation result of an enclave by re-executing the same method on one or more other enclaves. This way, integrity is warranted and misbehaving enclaves can be identified and revoked.

Ekiden tries to mitigate the impacts of integrity risks and data leakage by designing critical components “against a strong adversarial model, allowing an attacker to break the confidentiality of a small fraction of TEEs” [3], but restricting access to critical components from other components of the system. If the confidentiality of a computation node is threatened, a forward secrecy and isolation mechanism is used. Additionally, Ekiden implements a proactive key rotation in case a key manager node is compromised, but it does not cover measures to circumvent contract-level data leakage through side channels or software bugs.

The Coco framework differentiates between compromised validating nodes and compromised enclaves. One of the mechanisms implemented by Coco is that a VN needs partial decryptions from other nodes in order to decrypt the data, so a single malicious VN is not capable of fully decrypting confidential data by himself [4]. Similarly to PDOs, Coco proposes to synchronously execute transactions on multiple nodes for verification and rapid compromise detection. Measures to mitigate the risks of malicious components, such as software-fault isolation techniques, are also introduced by the Coco framework [4].

Lastly, SCE-Fabric states that a malicious peer might interfere with the invocation order of contract operations or feed the enclaves with spurious input, but it “cannot access or tamper with the code and data residing in an enclave” [8], so the execution correctness itself is still ensured. In order to prevent a wrong execution order, SCE-Fabric implements an execute order-validate architecture, which enforces a peer to execute a transaction before the transaction order is decided by means of consensus. Therefore, SCE-Fabric makes use of a trusted ordering service that cannot be rolled back and is consulted for every transaction submitted by a client, thus state continuity is ensured. Nevertheless, SCE-Fabric does not prevent denial of-service attacks or leakage due to side channels [8].

H. Individual benefits

Besides the properties mentioned above, each of the existing solutions exhibits advantages that are not present within the other approaches. For instance, Ekiden provides several performance optimizations for its system, which contribute to the remarkable performance improvement compared to the Ethereum mainnet during the evaluation of their prototype in [3]. PDOs focus on smart contracts that involve mutually distrusting parties, where contract owners have a freedom of choice concerning the selection of enclaves used for the execution of the contract from different enclave hosting services and the migration of contract executions is also possible [10], e.g. in case of TEE removals or failures. The Coco framework is the most generic solution, since it supports pluggable blockchain protocols “such as Ethereum, Quorum, Corda or Hyperledger Sawtooth” [4]. One of the main design goals of SCE-Fabric, besides the overall goal to ensure privacy and confidentiality, is minimizing the size of the trusted computing base, because this represents an “important computer-security principle” [8] in order to decrease the potential attack surface. This goal is achieved by identifying trusted and untrusted components of applications and limit the amount of code that is executed inside an enclave as far as possible in order to reduce the potential surface for attacks.

I. Usage of trusted third parties

All of the proposed solutions depend on a trusted third party for the verification of the the SGX enclaves, namely the Intel Attestation Service. The IAS, created by the hardware manufacturer Intel, has to be consulted for every SGX enclave in order to guarantee unforgeable and authenticated attestations issued by the enclaves [11] and therefore it has to be trusted by all entities. This procedure directly contradicts the fundamental blockchain concept of eliminating third party involvement in distributed ledger systems. Additionally, PDOs rely on enclave hosting services [10], which own platforms for providing SXG enclaves to PDOs, so there might be even more third parties participating in the smart contract system.

J. Summary

In summary, the choice of solution approach depends on the actual use case it should be applied to and the demands required by the application, such as privacy or performance requirements [9]. All of them show different benefits, but also weaknesses due to their architectural designs, so the solution specific trade-offs need to be considered and weighted before selecting an approach in order to identify the best solution for each application or use case. So far, no fully satisfactory general-purpose solution has been proposed to solve the availability issue of TEEs and all four proposed systems involve the Intel Attestation Service as a trusted third party, which represents an undesirable property of every approach, since it contradicts fundamental blockchain characteristics.

V. CONCLUSION AND OUTLOOK

This work has reviewed four different existing frameworks combining smart contract systems and TEEs, with the aim of protecting privacy and confidentiality of contracts as well as improving their execution performance. We divided the approaches into two broad categories based on their onchain and off-chain nature of executing smart contracts. We then described the architecture and functioning of all four proposed solutions and summarized important features as well as shortcomings of the different approaches. We established that each framework has various benefits to offer regarding the optimization of smart contract execution, but also faces challenges while attempting to implement the same. We then evaluated the four frameworks by comparing them to each other on the basis of their architecture, consensus layer dependency, performance, scalability and various other criteria.

We can conclude that depending on the use case, the selection of the solution approach may vary and since no one generalpurpose solution has been proposed yet, certain aspects of each framework can be taken into consideration as building blocks for the development of smart contract execution in the near future.

REFERENCES

1. N. Satoshi, “Bitcoin: A peer-to-peer electronic cash system,” https://bitcoin.org/bitcoin.pdf, 2008.
2. G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,”, Ethereum Project Yellow Paper 151, 2014, pp. 1–32.
3. R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. M. Johnson, A. Juels, A. Miller, and D. Song, “Ekiden: A platform for confidentialitypreserving, trustworthy, and performant smart contract execution. ArXive-prints, http://arxiv.org/abs/1804.05141, 2018.
4. Microsoft, “The Confidential Consortium blockchain framework,” Whitepaper, https://github.com/Azure/coco-framework/raw/master/docs/Coco%20Framework%20whitepaper.pdf, 2017.
5. G. Zyskind, O. Nathan, and A. Pentland, “Enigma: Decentralized computation platform with guaranteed privacy,” ArXiv preprint https://arxiv.org/abs/1506.03471, 2015.
6. E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, “Zerocash: Decentralized anonymous payments from bitcoin,” in Security and Privacy (SP), 2014 IEEE Symposium on. IEEE, 2014, 459474.
7. A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk: The blockchain model of cryptography and privacy-preserving smart contracts,” in Security and Privacy (SP), 2016 IEEE Symposium on. IEEE, 2016, 839858.
8. M. Brandenburger, C. Cachin, R. Kapitza, and A. Sorniotti, “Blockchain and trusted computing: Problems, pitfalls, and a solution for Hyperledger Fabric,” ArXiv e-prints, https://arxiv.org/abs/1805.08541, 2018.
9. M. Brandenburger, and C. Cachin, “Challenges for combining smart contracts with trusted computing,” in Proceedings of the 3rd Workshop on System Software for Trusted Execution (SysTEX ’18). ACM, New York, NY, USA, pp. 20-21, 2018.
10. Intel, “Private Data Objects: an overview”, ArXiv e-prints,https://arxiv.org/abs/1807.05686, 2018.
11. Costan, V., and Devadas, S., “Intel SGX explained,” in IACR Cryptology ePrint Archive, 2016, pp. 86.
12. Hyperledger Project https://www.hyperledger.org/
13. Keystone Project. 2018. https://keystone-enclave.org/