Table of Links Abstract and I. Introduction Abstract and I. Introduction II. A Lightning Tour II. A Lightning Tour III. Systematization Methodology III. Systematization Methodology IV. Layer-One Solution IV. Layer-One Solution V. Layer-Two Solution V. Layer-Two Solution VI. Discussion VI. Discussion VII. Research Challenges VII. Research Challenges VIII. Concluding Remarks and References VIII. Concluding Remarks and References Appendix A. Key Managements Appendix A. Appendix A. Key Managements Appendix B. Anonymity and Confidentiality Appendix B. Appendix B. Anonymity and Confidentiality Appendix C. Background Appendix C. Appendix C. Background Appendix D. A TCSC-Based Voting Protocol Appendix D. Appendix D. A TCSC-Based Voting Protocol APPENDIX C. BACKGROUND Blockchain Technology. Blockchain, conceptualized by Nakamoto [100], was proposed as a distributed and appendonly ledger, in which all committed transactions are stored in a chain of data records (named as blocks). According to the initial idea of Bitcoin [1], when the blockchain maintainers reach an agreement on the newest block, related transactions appearing in that time will be packaged in this block and further stored in a distributed network to maintain a continuously growing list. By providing a secure solution to distribute the information and allowing all participants to audit the shared records, blockchain obtains many key characteristics such as decentralization, auditability and nonrepudiation, transparency, and non-equivocation. Blockchain Technology. Smart Contract Proposed by Szabo [1], the smart contract are widely applied in blockchain systems by Ethereum [2]. Blockchain-based smart contracts adopt Turing-complete scripting languages to achieve complicated functionalities [6] and execute thorough state transition/replication over consensus algorithms to realize final consistency. By the design, a blockchain-based smart contract includes multiple functions, methods, and a few parameters that can run on the blockchain when specific conditions or events are met and encompass business logic and transactions between two or more parties. To be specific, the source code of a contract forming as part of a transaction is first sent to the blockchain. Once the transaction is included in a new block and confirmed by the majority of the participants, the contract code becomes immutable and executable. When an external user invokes the contract, the state will be updated under the instruction of the preloaded source code. The neutrality of the execution Smart Contract environment among all blockchain nodes facilitates the same execution result of the program code. Smart contracts thus enable unfamiliar and distributed participants to fairly exchange without trusted third parties and present a uniform approach to improve applications across a wide range of industries. Trusted Execution Environments. Trusted Execution Environment (TEE) [29] provides a protected processing area in the main processor that runs on a separation kernel to ensure confidentiality and integrity of inside data and computations. State-of-the-art implementations include Intel Software Guard Extensions (SGX) [80], ARM TrustZone [89], Keystone [28], etc. For a TEE, three main TEE features are highlighted, including runtime isolation, sealing technologies and attestation technologies. For simplicity, we use Intel SGX as an example to explain these features in the following paragraphs. It has to be mentioned that the Intel SGX design used in our paper can also be implemented on other trusted hardware platforms such as Keystone [28]. Trusted Execution Environments. etc runtime isolation, sealing technologies attestation technologies. Runtime Isolation. The secure and isolated regions of memory are called enclaves. Sensitive data and intermediate computations run inside enclaves to provide protection against outside programs. Besides, all the runtime enclave memories are stored in Enclave Page Cache (EPC) [101] and encrypted by Memory Encryption Engine (MEE). These protective mechanisms enforced in SGX protect memories against the access of any process outside the enclave itself, including the operating system, hypervisors, etc. Runtime Isolation. Sealing. Sealing [88] is a process of loading enclave internal secret state to persistent storage. Roughly speaking, using the Sealing, the secrets can be encrypted and stored in the untrusted memory or disk. Further, it allows such encrypted secrets to be retrieved once the enclave is torn down (either due to the host’s power or the application itself). Sealing is achieved by using a private seal key [80], which covers two types of identities: Enclave Identity and Signing Identity. Enclave Identity is represented by the value of MRENCLAVE, which is a cryptographic hash of the enclave measurement. Any operation inside an enclave that changes measurement will yield a different key. Thus, it restricts the permission to sealed data; only the corresponding enclave can access the sealed data. In contrast, Signing Identity is provided by an authority and represented by MRSIGNER. It provides the same sealing key for different enclaves, or even different versions of the same enclave. Therefore, Signing Identity can be used to share sensitive data between multiple enclaves produced by the same development firm. Sealing MRENCLAVE MRSIGNER Attestation. Attestation mechanism [33] is used to prove to a validator that an enclave has been correctly instantiated and when in that condition can then proceed to further establish a secure, authenticated connection for the data transmission. SGX provides two types of attestation: local attestation and remote attestation. In the former attestation, SGX facilitates the instructions to help an enclave to attest to another enclave on the same platform. In the latter one, SGX enables an enclave to prove a correct loading of code and data to another enclave that resides in a remote platform. Attestation local attestation remote attestation 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. Authors: 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. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

A Technical Breakdown of Blockchain, Ethereum Smart Contracts, and Intel SGX

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps