How Trusted Execution Environments Power Scalable, Private Smart Contracts

Table of Links

Abstract and I. Introduction

II. A Lightning Tour

III. Systematization Methodology

IV. Layer-One Solution

V. Layer-Two Solution

VI. Discussion

VII. Research Challenges

VIII. Concluding Remarks and References

Appendix A. Key Managements

Appendix B. Anonymity and Confidentiality

Appendix C. Background

Appendix D. A TCSC-Based Voting Protocol

V. LAYER-TWO SOLUTION

The layer-two solution is a straightforward approach that combines the TEE and blockchain to provide smart contracts with confidentiality while keeping scalability. In such systems, the operations of smart contracts are decoupled from their underlying blockchain systems. The smart contracts are executed in an independent layer outside blockchain systems.

System model. In a general layer-two solution, the blockchain is used as a dispute resolution layer. The smart contract is executed outside the blockchain, making TEEs act as an agent between users and blockchain systems. Suppose that a user aims to use a private contract. She first needs to compile the original contract code, push binary codes to a TEE, and then upload execution results to the public ledger. As illustrated in Fig.4, we extract a generic data flow as follows. A user sends the encrypted input data to a TEE-powered node. Then, the TEE decrypts the input data and executes the contract. After that, the encrypted execution results are sent to the blockchain platform for verification and storage. Finally, the user fetches and decrypts the blockchain-confirmed results.

A. Property Evaluation

Privacy-preserving property. The confidential execution is an essential property. In layer-two systems, such as [46], [68], [69], the contract computations run inside Intel SGX enclaves, while TZ4Fabric [44] moves contract executions into ARM Trusted Zone. Since the contract state-transition process happens inside TEEs, any intermediate states remain invisible to the outside. Meanwhile, to achieve the full lifecycle security for a smart contract, the input sent to a TEE and the output returned from this TEE are also required to be encrypted. For example, in ShadowEth [68], PDOs [46], Phala [69] and Hybridchain [41], the contract invocation arguments are encrypted with the TEE public key. They can only be decrypted within the enclave. Also, before transferring execution results to the blockchain (or users), the intermediate (or final) states in an enclave are encrypted. Some variants also enhance the privacy-preserving properties from other aspects. In Phala [69], only authorized queries to the contract will be answered. The smart contract source codes in ShadowEth [68] are hidden during the procedures of deployment and synchronization. This further reduces the possibility of data leakage in subsequent contract executions. Considering a fixed address may expose the user who has invoked the contract, PDOs [46] also allows the user to use pseudonym addresses for submitting a transaction (including TEE outputs) to the blockchain.

Blockchain intrinsic feature. ShadowEth [68] and Taxa [70] introduce an external distributed service to manage the contracts, achieving the properties of code immutability, high availability and decentralized execution. Meanwhile, layer-two systems satisfy state consistency for reasons that the encrypted states of contracts in different blockchain nodes will eventually get consistent when reaching a successful agreement. Intuitively, the contracts deployed in layer-two systems should retain the features given by original blockchains. However, some fundamental properties are lost when using layer-two solutions. For example, most layer-two systems lose contract interoperability since each contract is executed in different machines. Among all the evaluated systems, only Phala [69] identifies this issue and proposes a command query responsibility segregation architecture to ensure certain interoperability. Also, public verifiability is a crucial property for the blockchain since it allows each contract invocation, and contract execution to be publicly verifiable. Unfortunately, contracts are executed in TEEs so that the outputs are encrypted. To check whether the TEE has executed contracts following loaded contract specifications is a non-trivial task.

B. System Evaluation

Threat model. An attacker may control the network between users and TEE hosts. Meanwhile, TEEs are assumed to always produce correct results, and the smart contracts inside TEEs cannot deviate from their specifications. The main difference compared with the assumption of layer-one systems is that an adversary can observe the network activities between the TEE interfaces and active blockchain nodes.

TEE host security. Several layer-two solutions adopt incentive or punishment mechanisms to encourage TEE hosts to provide a stable and secure environment for executing confidential contracts. For example, Fastkitten [43] and Erdstall [75], [76] propose penalty transactions, in which a host will be punished if its malicious behavior has been identified. In particular, if the TEE execution is aborted, the host will be charged according to previous deposits. In Taxa [70], every node can identify any faulty nodes with reliable proofs for executing further economic punishment. On another route, TEE hosts in Phala [69] will get paid by providing their computing resources to users. Similarly, the remuneration in ShadowEth [68] will be transferred to TEE hosts who execute private contracts. These mechanisms can effectively prevent malicious TEE hosts from an economic aspect. However, they are powerless against external threats. An adversary may directly terminate a TEE host at any time. Even worse, the TEE provides users with an open interface that is vulnerable to DoS [77] or single-point attack. To overcome such issues and achieve fault tolerance, different methods are proposed. Fastkitten provides low-level fault tolerance by periodically saving an encrypted snapshot of current states in enclaves. If the enclave fails, the TEE host can instantiate a new enclave and restart the computation starting from the encrypted snapshot. Similarly, Taxa [70] stores a session file for maintaining and recovering user’s requests. However, a malicious attacker may directly terminate the TEE host, and Fastkitten does not tolerate such host failures. Another technical route is to maintain a secure network. ShadowEth maintains a group of TEE nodes to ensure consistency via a Paxos-like [78] algorithm. Taxa adopts TEE-enabled computing nodes powered by a PBFT-derived PoS [79] algorithm. Any node in the network has the same responsibility to privately execute smart contracts and transfer execution results to the blockchain. However, this brings additional authentication issues. A TEE host must be carefully authenticated to ensure her TEE capability when joining an external network.

Meanwhile, the systems PDOs [46], Phala [69], Ekiden [42] and COMMITEE [73] introduce an expendable and interchangeable solution. TEEs are stateless: any particular TEE can be easily replaced once it has clashed or finished its task. Unfortunately, these solutions are along with new challenges. Firstly, even if TEEs are changeable, detecting a compromised TEE is still difficult. For instance, PDOs can re-execute a method multiple times for the verification. Given the same input parameters to different TEEs, TEEs are believed to work securely only if their outcomes match. Then, the outputs of enclaves are allowed to commit to the blockchain. COMMITEE adopts master/backup TEE host mechanism. If the master TEE host is proved to be malicious, a backup TEE host will continue to work without communications to the master TEE host. Nevertheless, this model increases the attack interface and makes the whole system vulnerable. Secondly, TEE hosts are stateless. That means, to ensure an exceptional execution is recoverable, any persistent state must be stored in the blockchain or a trusted third party (TTP). However, for a non-deterministic blockchain system such as Ethereum (PoS version) [2], verifying whether an item has been stored on the blockchain is a non-trivial task. Meanwhile, storing data in TTPs may lead to the single-point failure, which goes against the blockchain’s real intention.

TEE security. A contract runs inside TEE, and heavily depends on remote attestation service. The SGX-supported blockchain systems including PDOs [46], Fastkitten [43], ShadowEth [68], Phala [69] and Ekiden [42] assume that Intel Attestation Service (IAS) is trusted. IAS can correctly and completely report whether a certain output with cryptographic material (quote [80]) is produced by SGX-enabled hardware. However, IAS might be compromised, posing a risk to these architectures. A compromised or hijacked remote attestation service may maliciously report an attestation with the wrong cryptographic material that does not belong to its corresponding TEE hardware, breaking the promised security. Meanwhile, a centralized service might be crashed, causing the leakage of private states. Unfortunately, none of layer-two schemes consider these risks in designs or implementations.

As discussed, current TEE implementations have memory limitations for confidential executions. If the memory usage exceeds the threshold, it may confront significant performance and security issues [81]. Hybridchain [41] optimizes the storage by maintaining transaction records outside Intel SGX. Meanwhile, TZ4Fabric [44] minimizes TCB by avoiding all the executions inside TEEs. However, these approaches increase the implementation complexity. A well-known fact is that a TEE is vulnerable to physical vulnerabilities [57]. Unfortunately, very few layer-two solutions provide remedial measures to reduce the risk of being attacked.

TEE program security. A poorly-written contract might deviate from designated functionalities and further leak the secret information. This part discusses the potential pitfalls and remedies when deploying contracts.

In original smart contract systems, gas mechanism is a powerful tool to prevent infinite loop attacks [2]. Since the layertwo systems execute smart contract outside the blockchain, a similar mechanism must be considered. Fastkitten [43] and Hybridchain [41] protect against such attacks by using the timeout mechanism. Limitations are firstly defined on the maximum amount of execution steps that allow to perform inside a TEE per round. Then, TEE monitors smart contract operations. If the number of execution steps exceeds a predefined threshold, the enclave will terminate executions. ShadowEth [68] combines a timeout mechanism with a remuneration mechanism. Similar to the gas mechanism in Ethereum [2], TEE hosts can still gain remuneration even if a contract exits after timeout since they provide sufficient computing power. These mechanisms effectively protect against endless loops and denial-of-service (DoS) launched by external attackers.

The TEE itself lacks self-awareness of input data, since it cannot distinguish which state is fresh. A lack of input data authentication makes the system vulnerable to the rollback attack [82], [59]. A malicious user may attempt to invoke the confidential contract many times to seek the leaked secret information. Authentication of the user’s identity is helpful to prevent this attack. However, none layer-two solution provides these remedies for these potential pitfalls. On the other hand, the TEE input may come from a non-deterministic blockchain system [83], [84], in which deciding whether an input has been confirmed is tricky. Fastkitten [43] and COMMITEE [73] mitigate this issue by using a checkpoint mechanism. As for TEE output conflicts, Ekiden [42] uses a probabilistic proofof-publication protocol to avoid the ambiguous input.

After the invocation of a private contract, the outputs returned from TEEs are uploaded on-chain for the final confirmation. But a malicious TEE host may send an exceptional result to the blockchain. Even worse, two hosts may publish different updates towards the same contract simultaneously. To prevent such malicious publications and to evade conflicts, PDOs [46] depends on Coordination and Commit Log (CCL) to manage the synchronization in the execution of interacting contracts and enables a contract owner to decide on selecting the enclave for contract executions, which effectively avoid conflicts. Phala [69] adopts an event sourcing command query responsibility segregation architecture to scale up and avoid conflicts, in which the write operations are recorded as events and read operations can be served by the current view of states. Again, these solutions contradict the property of decentralization. Ekiden [42] and ShadowEth [68] rely on the blockchain to resolve conflicts resulting from concurrency. In particular, ShadowEth [68] requires a worker to specify the version number with a timestamp when pushing data to the blockchain. Even miners accept different responses at first, they will eventually reach an agreement by comparing version number and the timestamp, with the help of the consensus procedure. Yet, such an approach is inefficient, especially in non-deterministic blockchain systems.

TEEs key management. PDOs [46] uses a key provisioning service to distribute private keys. The drawback is obvious: A compromised provisioning service could make the entire system fail. To increase the robustness of a private key, Ekiden [42] designs a distributed key generation (DKG) [85] protocol using the secret sharing scheme [86]. Even if one key manager is compromised, an adversary cannot obtain the entire key. However, this solution does not completely solve the key leakage issue. The final keys are assembled and replicated among all end-TEEs. If an adversary compromises an end-TEE, exposing all the contract state becomes a trivial task. The key rotation technology, adopted by Ekiden [42], Fastkitten [43], Phala [69] partially solves the above issue by providing a short-term key in every epoch. An adversary cannot corrupt a future or previous committed state, which minimizes the possibility of key exposure to attackers and further helps the layer-two system to achieve forward secrecy. Also, layer-two projects such as COMMITEE [73] mitigate these key issues by providing each TEE per secret key. Even if a certain TEE’s private key were stolen, this only would affect the smart contract running on that compromised TEE. Furthermore, Phala Network [69], equips each contract with an asymmetric key called the contract key, which also enhances the key security to a certain degree.

C. Pros and Cons

The layer-two solution decreases computational burden and avoids latency by decoupling the smart contract executions from consensus mechanisms. The solution merely puts the execution results on-chain rather than all processing states. Meanwhile, the layer-two solution does not require a dedicated public ledger, meaning that such a solution can smoothly

integrate with existing public blockchain platforms. Unfortunately, this method also brings security and functionality challenges when delegating the task of contract management to an external TEE layer.

Firstly, the layer-two solution complexifies contract data management. The contracts that are deployed outside the blockchain require an external execution/storage party. A malicious storage maintainer may reject to provide the service, while a malicious host may abort TEE executions, terminate enclaves or delay/drop messages. Even an honest host might accidentally lose states in a power cycle. To solve the centralization issue and tolerate host failures, many countermeasures such as the TEE network, stateless TEEs and punishment mechanisms, are proposed. However, these solutions are not effortless, inevitably making the system complicated and hard to implement in practice.

Secondly, the layer-two solution increases the attack surface and thus becomes vulnerable to rollback attacks. There is a high probability that an adversary node can revert transactions where temporary forks, representing inconsistent blockchain views, are allowed in blockchain systems with probabilistic consensus (e.g., PoW). Since TEEs provide no guarantee on verification of input data; they cannot distinguish whether an input state is fresh or not. An attacker may offer stale states to resume a TEE’s execution. This enables rollback attacks against randomized TEEs programs. Even worse, plugging up these loopholes needs much effort.