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
II. A LIGHTNING TOUR
This section gives a high-level description and offers a running example to illustrate how a typical confidential smart contract operates. From existing literature [42], [43], [41], [44], [45], [46], establishing a confidential smart contract mainly requires four steps, namely invocation, computation, consensus and response (see Fig. 1).
A. Overview
B. An Running Example
From a bird’s eye view, a TCSC can be used as an ideal contract-based black box [47] with secrecy and correctness. This idea has been adopted by several advanced security protocols [48], [49]. We provide a secret e-voting example borrowed from Oasislabs [50].
A TCSC can be well qualified for the role of decentralized vote manager in an e-voting system [17], [51]. Once a contract-based manager is deployed successfully, the voting logic is loaded into a TEE and corresponding secret keys are privately generated and stored inside TEEs. The encrypted state is then confirmed by the blockchain nodes. This offers the e-voting protocol with confidentiality, neutrality, auditability and accountability. Firstly, the voter’s input cu is encrypted, and intermediate parameters (e.g., mb) are privately processed through TEEs. External attackers cannot obtain the knowledge of sensitive information, and thus the confidentiality is achieved. Secondly, the predefined voting logic only occurs in the decentralized network when certain conditions are satisfied, bringing neutrality for the access control management. Thirdly, if a voter wants to vote for a candidate, she needs to in advance build a channel to the TEE and then send a transaction Tx to call the contract. Due to the protection of encrypted channels, transaction arguments are kept secret. Meanwhile, such invoking records in the form of transactions remain visible and will become immutable, ensuring the voting process accountable. Unfortunately, verifiability, as one of fundamental properties, performs not smooth in the context of encryption. Contracts that are executed inside TEEs make the execution procedures lack public verifiability. Only the nodes who install TEEs with correct corresponding keys can verify the correctness of contract executions. However, the metadata of the transaction Tx retains unencrypted, making it possible to verify the absence of double spending.
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.
