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
IV. LAYER-ONE SOLUTION
The layer-one approach enables blockchain nodes to run contracts in their isolated areas, as well as conducting the consensus (see Fig. 3). This approach combines the consensus procedure and state execution, either in terms of logically or physically. The reason why we call this method layer-one is that all executions are completed in the same layer of the blockchain network. The key to such an approach is to equip every blockchain node with a TEE. Indeed, this requires more integration efforts, but also comes with several advantages. The smart contract can implement stateful functionalities that receive arguments and update states instantly. In particular, a smart contract can directly access the ledger data stored in a local disk, greatly saving time often wasted in the interactive network communications.
System model. In a layer-one execution model, the operation of ledger update (consensus) and state transition (contract execution) are coupled. Like Ethereum [2], smart contracts run inside blockchain nodes. Assume that a user plans to use the private contract; she only needs to upload data to the blockchain service and wait for results. The remaining procedures are completed by TEE-assisted distributed nodes. A TEE in these nodes acts as a black box for data processing and output targeted results without the data leakage. This approach greatly improves convenience for users due to its easy access and management. As illustrated in Fig.3, a generic data flow goes as follows: A contract creator deploys the code into blockchain. Then, a user sends the transaction with an encrypted argument to an arbitrary blockchain node. Her request is confidentially executed inside TEEs in this node and output encrypted state. Then, the consensus algorithm in this node broadcasts the encrypted results to peers. After the encrypted results are confirmed by other blockchain nodes, users fetch on-chain results and decrypt them for the plaintext.
A. Property Evaluation
Privacy-preserving property. This property indicates that contract states and the procedure of contract executions are hidden from the public. To achieve privacy, layer-one systems execute these confidential contracts inside TEEs in every distributed node. CCF [45], Fabric [60] and CONFIDE [37] follow this straightforward design where confidential contracts are loaded to the TEE of each consensus node, which encrypts both the inputs and outputs of contract states, together with their operating logic and predefined rules. Enigma[1] [61] introduces the secret network and allows users to submit their transactions together with encrypted data to miners. We also notice that current layer-one solutions only focus on internal procedures rather than the linkability and anonymity of addresses and transactions. This indicates that confidential smart contracts only protect the contents that have been loaded into TEEs, while the data that relates to external users is out of the scope of this work.
Blockchain intrinsic feature. The layer-one systems inherit most of the features empowered by blockchain. More precisely, the properties of code immutability, high availability, explicit invocation, decentralized execution, automatic execution and consensus verifiability remain the same because basic contract executions still rely on their underlying blockchain systems. Also, the property of (confidential) state consistency in Enigma [61], CCF [45] and Fabric [60] remains unchanged. The states and executions from these systems follow the procedures of online consensus processes. Then, the returned results from inside TEEs still require to be confirmed on-chain. This makes their actions effectively perform the same functions as a normal smart contract, except for that the contents of states are transmitted from plaintext to ciphertext. In contrast, the property of contract interoperability is lost since the contracts are executed in isolated TEEs. This isolation requires additional communications such as dispatching keys through the remote attestation service, bringing much complexity.
B. System Evaluation
The layer-one solution encapsulates TEE computations into blockchain nodes. Every node in the network has to take responsibility for conducting confidential executions and performing the consensus. The design to coordinate TEEs and consensus within the same physical space brings many distinguished features. We start the analysis from their threat model and then dive into each component of these systems.
Threat model. Users in the layer-one approach are assumed to be unreliable. They may have mistakes unconsciously, like dropping messages or mis-sending transactions. Even worse, a malicious user can arbitrarily behave like faking messages, identities, or compromising other nodes. As for TEE hosts, an external attacker can monitor, eavesdrop or even compromise part of involved TEE hosts among these distributed nodes, but cannot block all traffic transmitted in communication channels. Subsequently, a TEE is supposed to work in a good condition: The attestation service is trusted, and the cryptographic primitives used inside TEEs are secure. Meanwhile, as for the blockchain network, the basic systems (ledgers) are assumed to be robust [62], [63], [64]. When running the consensus, the majority (might be two-third, depends on specific consensus algorithms) of nodes are assumed to be honest [65]. Also, forging smart contract codes or states will happen in honest blockchain nodes with a negligible possibility. Based on that, we analyse securities from four aspects.
TEE host security. Firstly, we focus on the security of TEE hosts, or equally, individual nodes that run TEEs. Unlike classical blockchain systems, there are no explicit incentive or punishment mechanisms in this solution. This is easy to understand: A node with malicious behaviors will be instantly moved out of the committee and replaced by a new honest participant. Meanwhile, due to the fact that CCF [45] and Enigma [61] rely on Tendermint (a BFT variant) consensus algorithm, they can tolerate at most one-third of TEE Byzantine nodes. But the sacrifice is the increased difficulty in synchronization, especially when every node has to establish a secure channel for communications of distributed TEEs. In layer-one systems, host authentication is necessary. The node who wants to join the committee has to obtain permission from communities by proving her TEE capability. For instance, CONFIDE [37] builds a mutual authenticated protocol (MAP) (supported by SGX remote attestation techniques [66]) among blockchain nodes. Any nodes joining in the network have to pass the authentication via MAP.
TEE security. Then, we analyse TEE-level securities. Attestation service is an essential part of TEE techniques. Systems in the layer-one solution still require such services for network connection and verification. Enigma [61], Fabric [60] and CCF [45] follow the original attestation mechanism with an implicit rule: The Intel Attestation Service (IAS) should be reliable. However, this cannot be guaranteed in the case of IAS being comprised. In contrast, CONFIDE [37] utilizes a customized Decentralized Attestation Service to provide the robust authentication. As for memory limitations, layer-one systems load contract executions and consensus algorithms into one TEE-embedded node, causing an increase in disk and memory usage of individual nodes. Once the usage of TEE memory runs over the predefined settings, a decrease in the performance is inevitable [34]. This may further cause an unpredictably severe result like system crash-down. Fortunately, Fabric [60] mitigates such issues by separating the operations into two types (execution and ordering) and delays the transaction-ordering procedures after state-execution. Among them, only the state-execution parts are processed inside TEEs. This decreases computation complexity and limits the memory usage to a suitable range. Physical attacks like the Spectre and Meltdown vulnerabilities [57] are intrinsic design pitfalls that may occur inside the TEE kernel. To our knowledge, no layerone solutions mention them or provide the remedies.
TEE program security. Next, we focus on the program-level security. Issues like overburdening may frequently happen, especially when a malicious developer deploys a contract with infinite loop logic. Unlike using the gas mechanism in Ethereum [2], systems in the layer-one model constrain their running programs by the time-out mechanism. It sets a threshold, namely, a suitable range of time that allows processing contract operations. When exceeding the timebound, the system will abort under-processing states and restart a new round. As for the flaw detection, no formal techniques or verification tools, based on our observation, have been applied to layer-one systems. This gap needs further exploration. Similar to the previous discussion, the properties of data verification (covering both user data authenticity and blockchain data confirmation) and output conflicts are guaranteed by their underlying consensus algorithms. Each time performing the consensus, these properties are automatically checked. For instance, Enigma [61] relies on trusted validators, who equip with TEEs to conduct the verification procedure. Such validators maintain both the privacy of executions inside TEEs and the consistency of states that connects to peers. Once conflicts occur, validators will quickly make decisions on a block and remove another conflicting block. Fabric [60] performs such a process inside TEEs among committee nodes and then submits the passed results to its abstract ordering service. This service prevents forks caused by conflicting states, as well as proving a fact that: All executed messages are valid and integral once reaching the consensus agreement. It should be noted that, successful consensus procedures can merely guarantee the integrity of transactions and states, rather than linkability and authenticity that relates to physical entities.
TEE key management. Lastly, we move to the aspect of TEE key management. In layer-one systems, the key management service takes over the task of creating and managing keys for activities like attestation, verification, encryption, etc. To achieve the key management service among distributed nodes, several types of designs have been proposed. CCF [45] relies on the public key infrastructure (PKI) for certificate issuance, management, and revocation. It creates key pairs and dispatches them to every participated TEE, where each TEE holder is authenticated by the certificate. Similarly, Fabric [60] adopts an admin peer to provision the specific decryption key to chaincode enclave during bootstrapping. Enigma [61] setups an independent key management component to reply to the requests for encryption. Such designs help to simplify complex management procedures, as well as providing distinguishable keys for each TEE. However, these independent key management services lead to centralization even they are maintained by a group of nodes in the committee. CONFIDE [37] mitigates this issue by proposing a decentralized key management protocol. Two types of keys are involved in this protocol: the asymmetric private key used to decrypt confidential transactions from clients and the symmetric states root key used for state encryption/decryption between the confidential engine and storage service.
C. Pros and Cons
The layer-one solution provides a highly integrated approach towards confidential smart contracts.
The layer-one solution provides a consistent interface for users without changing the customer’s habits transformed from non-TEE blockchain systems. A user can use the layer-one system by directly interacting with the blockchain interface, without considering cumbersome and complicated operations between the TEE and blockchain. However, the layer-one solution still confronts several common disadvantages.
Minimizing the size of Trusted Computing Base (TCB) contributes to the TEE security [67]. In particular, a small TCB has fewer errors and can reduce attack surfaces. However, complicated interactive operations for contract execution and consensus agreement in the L1 solution greatly increase the size of TCB. Meanwhile, TEE products have limited secure memory. For example, in the current implementation of Intel SGX [35], the enclave page caches are constrained to 128 MB, and only 93 MB of those is available for applications, which limits the concurrent execution.
Furthermore, the layer-one solution lacks compatibility, which means being incompatible with existing blockchain systems. The solution integrates the consensus procedure and the contract execution into the same blockchain node, requiring every node having to equip a TEE hardware. Nevertheless, this requirement is difficult to be fulfilled in a public blockchain while already in use (e.g., Ethereum [2]).
Authors:
(1) Rujia Li, Southern University of Science and Technology, China, University of Birmingham, United Kingdom and this author contributed equally to this work;
(2) Qin Wang, CSIRO Data61, Australia and this author contributed equally to this work;
(3) Qi Wang, Southern University of Science and Technology, China;
(4) David Galindo, University of Birmingham, United Kingdom;
(5) Mark Ryan, University of Birmingham, United Kingdom.
[1] Enigma’s secret network consists of a list of secret nodes equipped with TEE, which is categorised as a layer-one solution in the context of our definition (Sec.III-A). We also note that such a secret network can be regarded as a layer-two solution in the traditional classifications in terms of Ethereum, namely, either on-Ethereum chain (L1) or off-Ethereum chain (L2).
