Four Key Steps to Confidential Smart Contract Execution

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.