ShadowZone WhitePaper

Our site: http://shadowzone.io/

ShadowZone: Private Smart Contract on Public Blockchain

Abstract

Blockchain is becoming popular as a distributed and reliable ledger which allows distrustful parties to transact safely without trusting third parties. Emerging blockchain systems like EOS support smart contracts where miners can run arbitrary user-defined programs. However, one of the biggest concerns about the blockchain and the smart contract is privacy, since all the transactions on the chain are exposed to the public.

In this paper, we present ShadowZone, a system that leverages hardware enclave to ensure the confidentiality of smart contracts while keeping the integrity and availability based on existing public blockchains like EOS. ShadowZone establishes a confidential and secure platform protected by Trusted Execution Environment (TEE) off the public blockchain for the execution and storage of private contracts. It only puts the process of verification on the public blockchain. The private computation runs off the blockchain with a protocol token called "SZT", which workers earn by providing correct and confidential computation for users. This creates a powerful incentive for workers who own computation devices with TEE to participant into the network. Users can deploy and execute their smart contracts on ShadowZone just like using existing smart contract systems (e.g., Ethereum and ESOIO), while maintaining the confidentiality. ShadowZone also achieves availability and robustness by replicating data of private contracts on an off-chain network called TEE-DS. The data stored in TEE-DS is encrypted with secret keys which are only held by TEE and the data transmission channel between any two nodes is protected by a secure session key. ShadowZone proposes a complete solution for executing private smart contracts on public blockchains.

We provide a design of our system including a protocol of the cryptographic communication and verification and show the applicability and feasibility of the ShadowZone by various case studies.

Introduction

Blockchain, proposed as an underlying technology of cryptocurrency like Bitcoin, allows users to transfer currency over a distributed, public and trust-less network. Over the last few years, blockchain systems evolved to support smart contracts which can run custom Turing-complete code on the blockchain, such as Ethereum and EOS. Today, public cryptocurrencies are widely used. On Ethereum, more than 10 million ethers are held by more than 1 million smart contracts. On these blockchain systems, all the participants have the entire log of the system and reach a distributed consensus on the transactions that will modify the state of the chain. This high degree of replication and the strict consensus mechanism ensure integrity and availability but make all data public, which brings the deficiency in confidentiality.

In this paper, we present ShadowZone, a system that enables private smart contract based on public blockchains. Our idea is to combine hardware enclaves and public blockchains to offer confidentiality of smart contracts while keeping the integrity and availability. On the public blockchain, we create a public smart contract named "bounty contract" which performs the process of deployment and verification and stores the metadata of private contract. We also introduce an off-chain distributed storage named TEE-DS to store binary and states of private contracts. The entire TEE-DS is protected by hardware enclaves so all the data it stores will not be leaked or tampered with. Users can then publish the deployment and invocation request and the remuneration on the bounty contract to draw workers (who provide off-chain execution environment) in. If a worker wants to execute a private contract, it needs to run a worker client in hardware enclave, which will get the binary and state from TEE-DS to execute. After the off-chain execution, the enclave will generate a particular signature and put it back to the EOS blockchain, which is used to verify the correctness of the execution. Since we just put the metadata (like hash of binary, public key, state versions) and the encrypted data (like input and output) of ShadowZone to the bounty contract, there is no need for any modification to the underlying protocol of existing blockchain systems. Meanwhile, many workers comprise a distributed storage to improve the reliability and guarantee the availability. We also implement a prototype of ShadowZone with the Intel SGX on EOS blockchain network and show the applicability with three use cases.

This work:

•presents ShadowZone, a confidential, distributed, trust-less off-chain smart contract system clinging to existing public blockchain networks like EOS without any modification.
•describes the detailed architecture and protocol of ShadowZone.
•shows the applicability of ShadowZone with three use cases and demonstrates the security and availability of ShadowZone.

Background

In this section, we provide background on the technologies that underpin ShadowZone. We first give a short overview of the blockchain and smart contracts, explore the lack of confidentiality of current smart contract systems, then introduce the hardware enclave and finally describe the threat model of ShadowZone.

Blockchain

A blockchain typically serves as an open, decentralized and trustless distributed ledger which is maintained by all participants. Some participants, called miners, form a peer-to-peer network and all have the full copy of the blockchain. They collect transactions signed by users. After validating the signatures, they packed these transactions into a block. Each block contains the information of the transactions as well as the hash of the previous block, which organizes the data as a sequential list of blocks, called a blockchain. The blockchain is a distributed system designed for Byzantine fault tolerance. Each transaction which may modify the state of the chain will be broadcasted to all miners in the network. Once a block is generated, all the miners need to achieve a consensus on whether to accept it or not. Each miner can decide the block’s content arbitrarily, that is to say, he/she can decide which transactions will be packed into the block. Miners can always generate different blocks with the same parent at the same time, which will cause inconsistency called a fork. To solve the bifurcation, an honest miner always chooses to follow the longest branch.

If an attacker controls more than 50% of the nodes, he/she can unilaterally generate the branch containing the fake transactions faster than the branch containing the real ones, which causes the double spending problem. To solve this problem, a miner needs to prove that he/she has done a certain amount of work before generating a block. With this proof, known as Proof of Work (PoW), the block is acknowledged to be valid. PoW makes a miner create blocks at the rate related to the proportional of his/her mining power, whichprevents Sybil attack.

Smart Contract and EOS

The smart contract can trace back to 1996, proposed by Nick Szabo. It is described as "a set of promises, specified in digital form, including protocols within which the parties perform on these promises". The smart contract is usually designed to ensure the execution of a contract and to avoid malicious act as well as unforeseen circumstances. It can minimize the utilization of the trusted third party, which results in the reduction of transaction cost, and potentially circumvent censorship, collusion and counter-party risk. Blockchain makes smart contracts possible. Based on the blockchain, smart contracts usually take the form of a general-purpose program. Users can write and deploy any Turing-complete program on the blockchain network.

The most emerging smart contract implementation is EOS. An EOS smart contract is a user-generated application based on WebAssembly (WASM). WASM is a web standard with widespread support of Google, Microsoft, Apple and others. EOS currently uses clang/llvm with C/C++ compiler as its toolchain for building smart contracts, since C++ is the best language for developing high-performance and secure smart contracts.

In EOS, a smart contract is registered on the blockchain and executed on EOS nodes. The smart contract defines the interface (actions, parameters, data structures) and the code that implements the interface. The code is compiled into a canonical bytecode format for EOS nodes to retrieve and execute. The blockchain stores the transactions (e.g., legal transfers, game moves) of the contract. Once a smart contract is deployed, it will be executed autonomously. Even its creator cannot stop the execution or modify the code arbitrarily.

An EOS smart contract consists of a set of action and type definitions. Action definitions specify and implement the behaviors of the contract. The type definitions specify the required content and structures. EOS actions operate primarily in a message-based communication architecture. A client invokes actions by sending (pushing) messages to nodeos. This can be done using the cleos command. It can also be done using one of the EOS send methods (e.g. EOS::action::send). nodeos dispatches action requests to the WASM code that implements a contract. That code runs in its entirety, then processing continues to the next action.

The wide public participation of smart contracts and the strict consensus mechanism ensure the enforcement, integrity and availability of smart contracts. However, the lack of privacy becomes a pain point that restricts the applications of smart contracts in some privacy-sensitive scenarios.

Hardware Enclave

Trusted executed environment (TEE) is a new feature provided by recent commodity CPUs. It creates a secure area which guarantees the integrity and confidentiality of code and data inside. TEE serves as an isolated environment running in parallel with OS. It provides a high-level security for software inside by reducing the trusted computing base (TCB) to only the CPU. Applications running in TEE have secure memory and cryptographic operations to resist attacks from other applications, even the privileged software such as OS or hypervisor.

Our design is general-purpose and applies to any TEE that has above features. In this paper, our implementation is based on Intel’s Software Guard Extensions (SGX) . Intel SGX provides a trusted and isolated environment called enclave. With this hardware feature in CPU, users can deploy their softwares in a remote host with integrity and confidentiality unless CPU package was hacked. An application running inside an enclave is protected from other malicious software including the operating system.

SGX provides remote attestation which allows a remote host to verify the application running in the enclave and generate a secure channel to communicate with it. In the process of initiation of an enclave, the CPU measures the trusted code and the trusted memory within the enclave and produces a hash based on all memory pages known as measurement. Then the software inside the enclave can acquire a report which contains the measurement and other supplementary data such as the public key. This report is signed by a hardware-protected key in CPU to prove that the measured software is running in SGX indeed. The remote attester can then verify the report with Intel Attestation Service (IAS) which can certify that the signature is valid and the corresponding report is generated from authentic CPUs.

Threat Model

Our threat model assumes that multiple parties mutually distrust each other. They are potentially malicious and may try to steal information of smart contracts, modify the execution flow and deviate from the protocol for their benefit. Each party may send, drop, modify, record arbitrary messages in the protocol at any time during the contract deployment and invocation. Any party may crash and stop responding entirely.

We assume that the blockchain is trustable and available all the time. The information on the blockchain is tamper-resistant but public to everyone. We also assume that network adversaries can intercept the communication between parties, but they cannot control the whole network so that the communication can be eventually established, for example, the user can send a request to the blockchain network and get the response.

We trust the hardware enclave, its manufacture (like Intel) and the remote attestation service. As long as a node passes the remote attestation, it will be able to execute the shadow contract within its enclave. The rest of the system, including the other software stacks (outside the enclave) and the hardware is not trusted. Side-channel attacks against enclaves and DoS attacks are not considered in this paper.

Our system also relies on the privacy of private key. Each private contract has a unique private key only possessed by the enclave. The private key is used to generate the attestation that the contract has been executed correctly. If an attacker steals the private key in some way, he/she can get paid from the EOS without executing the contract, which could compromise the integrity but not privacy.

System Overview

The goal of ShadowZone is to provide a confidential platform to executing private smart contracts which can be integrated with existing public blockchain such as EOS. Specifically, the privacy of a smart contract consists of the following three parts.

•Privacy of the specification of a smart contract. The source code of a private contract must be hidden during the deployment and subsequent process of execution and synchronization.

•Privacy of the execution of a smart contract. Once a private contract is invoked, the executing process on a worker client cannot be spied and the call arguments, as well as the return values should be hidden during the execution.

•Privacy of the state of a smart contract. The internal state of a private contract may contain user’s secrets and can reflect information of recent transactions. So it should not be published on the blockchain.

To guarantee the confidentiality of the code and data of a smart contract, a secure channel between a user and TEE-DS will be established before transferring the contract. The contract will be encrypted before transferring and can only be decrypted inside the corresponding enclave.

To preserve the privacy of execution, we only put the information of invocation and verification onto the blockchain. During the deployment of a private contract, TEE will generate a key-pair for this contract and publish the public key. The invocation arguments are encrypted with the contract’s public key which can only be decrypted within the enclave. The return value will be encrypted by a user-provided key which is delivered along with call arguments. In the entire process, the information of the execution is encrypted except inside the enclave. Anyone even the worker cannot leak the internal executing state.To guarantee the confidentiality of the persistent state of a private contract, ShadowZone stores only the hash of the ledger on the EOS instead of all data. The data can only be managed and viewed inside enclaves. Due to the limited secure memory of enclave like SGX, data could be moved to untrusted memory or disk, and sometimes need network transmission for backup or synchronization. Before writing out the data, ShadowZone will encrypt all data with the hardware key which is only kept by CPUs. This ensures that the data can only be accessed by authenticated users through ShadowZone and no one outside can view or manipulate the persistent state.

System Components

Figure.1 shows the architecture of ShadowZone. ShadowZone can be broken down into several subcomponents.

•Bounty Contract. A bounty contract is a native smart contract deployed on blockchain directly, serving as the public portion of ShadowZone.

•User Client. A user client provides interfaces to end users. It does not require enclave to execute.

•Worker Client. A worker client is responsible for the execution and maintenance of private contracts. It needs to run inside enclaves.

•TEE-DS. TEE-DS (Distributed Storage) serves as a distributed network which stores private contracts.

We create a smart contract named bounty contract on the EOS blockchain network which serves as a platform for publishing private contract, grabbing execution task and remuneration settlement. Bounty contract is a public contract that every participant in EOS can see and use. A user can deploy his/her private contracts and then invoke them like ordinary contracts via the bounty contract. On the other side, workers with TEE-enabled devices can look up executory tasks in the bounty contract, get the parameters, do the computation, and finally commit the result of the execution.

A user client provides interfaces including contract deployment and invocation for users. It communicates with bounty contract through cleos, command line interface to interact with the EOS blockchain. A user client can be launched without TEE, so it is only trusted by its user.

A worker client is used for fetching executory tasks from bounty contract, getting code and data of private contracts from TEE-DS, executing contracts, committing results and updating the persistent state of contracts. The main part of a worker client, which does the contract correlation processing, runs inside enclaves. It communicates with bounty contract through cleos. Furthermore, a worker client also serves as a server node in TEE-DS.

Many worker clients comprise TEE-DS, a peer-to-peer network storing the code and data of private contracts. In the process of execution of contracts, all the nodes maintain consistency by Paxos-like consensus algorithm. For a certain contract, different workers store the same data but encrypt it with different secret keys. Enclaves maintain the consistency of the unencrypted logical data. The data synchronization is performed on the safe channel between two enclaves after the remote attestation.

Example

Here is a simple example to briefly demonstrate the process of deployment and invocation from different perspectives in our system.

•Deployment: Suppose a user needs to deploy a private contract to ShadowZone. He/She first compiles the code and puts the binary to TEE-DS through the user client. TEE-DS will generate a pair of keys, bind them with the contract and transfer only the public key back to the user. The user client then uploads identification information of the contract (including the public key and the hash of binary, etc.) to the bounty contract. Now the contract is publicly available.

•Invocation: Once the user needs to invoke his/her private contract, he/she sends an invocation request (including arguments) to the bounty contract with a sum of remuneration. A worker client will get the arguments from the bounty contract and get the private contract’s binary from the TEE-DS with the public key as its ID. It then loads the binary to its hardware enclave and executes using the arguments to get a return value. After that, it sends the new state of the private contract to TEE-DS, which will be held at this moment. The worker then makes a response (including the return value and signature, etc.) and sends it to the bounty contract. The bounty contract will verify the response to ensure that it is generated by correct contract, states, and arguments in real hardware enclave before transferring the remuneration to the worker. Once TEE-DS confirms that the execution has been acknowledged by the bounty contract, it will update the states of the private contract, which finishes the process of one invocation.

As shown in the example, the EOS blockchain ensures the availability (a private contract will eventually get executed), and the integrity (the result cannot be modified), while the hardware enclave is used to protect privacy. There are many challenges unlisted, e.g., how to design a protocol and key management to defend against attacks like rollback and impersonation, how to minimize the trust on the manager in a second-price auction, which will be described in the following sections.

Design

In this section we present the design of ShadowZone. We first describe the three major parts of ShadowZone: the bounty contract (Subsection [subsec:bounty-contract]), the shadow contract (Subsection [subsec:shadow-contract]) and the TEE-DS (Subsection [subsec:tee-ds]) and then introduce the detailed protocol (Subsection [subsec:protocol]).

Bounty Contract

Bounty contract is a native smart contract deployed on the EOS. Its major responsibility is to perform the public portion of deployment, invocation and verification of private contracts. Sometimes it needs to generate transactions to handle the settlement. It maintains two lists: a contract list and a todolist.

Each entry in the contract list represents a private contract. It contains (1) the contract’s ID (as the primary key), (2) the contract’s public key, (3) a version number, (4) an owner list, (5) the hash of the contract’s persistent state, and (6) the balance of the contract. Once the bounty contract receives a deploying request, it will construct a new entry and add it into the contract list, and the invocation will update the hash value and increase the version number. The contract list can be used to record and verify the state of private contracts but does not expose any information about the core business logic. Users can deposit funds into a private contract by sending the corresponding tokens to bounty contract through deploy transaction or invoke transaction (described in Subsection [subsec:protocol]). The bounty contract records the funds as the balance of a contract. When the result of an invocation is a settlement, the bounty contract will check if the balance is enough before performing the transfer. It is worth noting that the bounty contract only records the total balance of the contract. The detailed distribution of this sum money is decided by the contract itself.

The todolist serves as a task pool. Users publish invocation tasks into the todolist to allow workers to bid the task. Each entry represents an invocation request, which contains (1) the task ID (as the primary key), (2) the contract’s public key, (3) the encrypted arguments, (4) the remuneration offered by the user, (5) the state (e.g.,TODO or FINISHED), and (6) the encrypted return value. Only one worker can gain the remuneration (typically the first), which is guaranteed by the EOS.

The bounty contract is the key component of our system. Users and workers communicate indirectly through the bounty contract. Thus, the integrity and the availability of operations on private contracts like deployment and invocation are ensured by the public blockchain.

Shadow Contract

We propose to build a confidential environment for smart contract execution using hardware enclave, but it is not enough to just deploy the native EOS contract directly because only the process of the execution can be hidden, while the information outside such as the call arguments and return values is still exposed.

To this end, we introduce Shadow Contract, a re-design of the native EOS smart contract. Shadow Contract uses a contract gate to isolate the core business logic of the smart contract. The contract gate is loaded by the worker client before the execution of smart contracts, endowed with the private key of the smart contract. The contract gate has two primary functionalities: decrypting arguments and generating the response. The two functionalities are independent of the contract code, which means the contract gate can be compatible with any private contract.

To preserve the privacy of the call arguments, users need to encrypt them with the public key of the contract before sending them to the bounty contract. Before execution, the contract gate first decrypts the arguments and then invokes the target function with the plaintext.

After the execution, a response is required to put back to the bounty contract. A response includes the execution’s return value, the version number before the execution, the hash of the contract’s state after the execution, and the settlement information. What is more, an invocation verification signature (IVS) is required to attached to the response.

IVS is used for verifying whether the contract has been executed correctly inside an enclave. The contract gate signs the response along with thehash of call arguments and the worker’s ID by the secret key of the contract to generate IVS. The encryption can only be performed after the execution within enclaves. Then the bounty contract can decrypt IVS by the public key of the contract to verify the execution. The inclusion of the hash of call arguments is to ensure that the worker does execute the contract with given arguments. Since IVS contains the ID of the worker, the remuneration will be sent to the right worker even when a malicious attacker captures IVS and resents it to the bounty contract using his/her own EOS account.

The return value of the execution is required to be sent back to the user without exposure. To this end, the user needs to provide another symmetric key along with the arguments and encrypt them together with the public key of the contract. The contract gate will encrypt the return value with this key and put the cipher-text into the response, which will then be put back to the bounty contract and only the user can decrypt it.

When a function is to trigger a settlement on the EOS, it will return a transaction-type object which the contract gate will put into the response. If a response contains settlement information, the bounty contract will generate an EOS transaction to transfer the money.

Besides the above-mentioned data, the contract gate also puts the hash of the contract state after execution into the response which is used as an attestation for off-chain contract transfer.

TEE-DS

TEE-DSTEE-DS is a peer-to-peer network consisting of many worker clients. It serves as a distributed storage of private contracts which can provide high reliability against malfunction. The secrets (e.g., the code, data and private key) of a private contract are protected by hardware enclave, which guarantees the confidentiality.

Admission Mechanism: Anyone runs the worker client inside an enclave can join the TEE-DS as a worker. To get permission, the expectant worker needs to connect one of the approved workers and offer a CPU-signed statement that he/she is executing a particular enclave. Once the statement is certified, which is known as remote attestation, the expectant worker can then join the network, get the current network constitution and synchronize data from other workers.

Synchronization Mechanism: After a worker performs an invocation of a private contract, he/she needs to broadcast the updates to other workers. However, some workers may publish different updates of the same contract simultaneously. This happens for several reasons: (1) the states before invocation are different; (2) the invocation requests they choose are different; (3) there are some malicious actions. We utilize the consensus on the blockchain to evade conflicts in TEE-DS. When a worker sends the response of an invocation to the bounty contract, he/she must specify the version number before the execution and the hash of the contract’s state after the execution.

Protocol

The ShadowZone protocol operates in two scenarios: 1) contract deployment, and 2) contract invocation. Figure. 2 shows the process. Just like smart contract systems based on public blockchains, our current system does not support withdrawal mechanisms unless they have been coded in the contract. Considering the irreversibility and nonrepudiation, a contract cannot be stopped from the outside once deployed. The following is a detailed description of the process of these two scenarios. For simplicity, we ignore mining fees in this subsection, although they can be supported in the implementation.

Contract Deployment

The first scenario of the ShadowZone protocol is contract deployment, as shown in the Fig. 2-A. Similar to using EOS natively, users write the business logic of their private contracts on their clients using native languages (like C/C++), then compile the code, deploy them onto the TEE-DS, and meanwhile upload the identification information (e.g., the hash of the code) to the bounty contract.The final purpose of the deployment is to generate an asymmetric key pair, of which the private key is only kept by the enclave, so that the subsequent invocation can be protected by the public key directly without establishing a secure communication channel.

A1. First, the user sends the binary code to TEE-DS through a secure channel, which is established through remote attestation and protected by a Key〖session〗 which is used for encrypting data in the session. Once the code is received, TEE-DS will generate an asymmetric encryption key pair(based on the RSA algorithm): Key〖(c_p)〗 and Key〖(c_s)〗 (p for public and s for secret), which is unique for each contract. Then TEE-DS sends Key〖(c_p)〗 back to the user.

A2. After receiving Key〖(c_p)〗, the user will upload the identification information to the bounty contract, essentially announcing the existence of a new private contract. The information includes: 1) Key〖(c_p)〗, 2) the owner list (the user’s public address as default), and 3) the hash of the binary code. This is done by the cleos, which generates a deploy transaction containing the information and sends it to the bounty contract. The bounty contract then creates a new contract record in its contract list with the identification information, sets the version number to 0, and sets the state to DEPLOYED.

A3. At last, after the deploy transaction is acknowledged, the code of the private contract along with the key pair will be broadcasted to all other workers in TEE-DS.

Contract Invocation

Once a private contract has been deployed, users can invoke it just like invoking native EOS contracts. The procedure is shown in the Fig. 2-B.

B1. A user initiates an invocation request through its user client. Similar to the native contract invocation in EOS, the user must specify the contract’s Key〖_(c_p)〗, the remuneration and the corresponding parameters including the function name and call arguments.

B2. The user client will process the request: 1) adding the timestamp into the request body, 2) generating a secret key Key〖req〗 which is only used for this request and adding it into the request body, and 3) using the Key〖(c_p)〗 to encrypt the request except for the remuneration, then send the data to the e.

B3. The cleos generates an invoke transaction including the contract’s Key〖_(c_p)〗, the encrypted request and the remuneration, which is sent to the bounty contract.

B4. Once the bounty contract receives the invoke transaction, it first verifies the identification to ensure that the contract exists and the request is from one of the owners of the contract. It then adds a new entry with the information included in the invoke transaction into the todolist marked as TODO, and transfers the remuneration into its account simultaneously.

B5. After the invoke transaction is acknowledged, workers can see the executory tasks. They can choose any task and get the related information including Key〖_(c_p)〗 and encrypted request from the bounty contract.

B6. By using Key〖_(c_p)〗, a worker can ask the TEE-DS for the contract’s code and load the contract into its enclave along with the encrypted request. Inside enclave, the contract gate first decrypts the request to get the arguments and the Key〖_req〗, and then executes the specified function.

B7. If the function exits normally, the contract gate will broadcast the modification of the contract’s persistent state to other workers in TEE-DS and then generate a response including the following parts:1) the version number of the contract before the execution, 2) the hash of the contract’s state after the execution, 3) the return value (if the function has one) which is encrypted by Key〖req〗, 4) the settlement information (if the function has one), and 5) the IVS (described in Subsection [subsec:shadow-contract]). The worker client then sends the response back to the bounty contract and the bounty contract can verify the validity of the IVS with Key〖(c_p)〗 to ensure that this worker has completed this task correctly. After the verification, the bounty contract updates the entry in the todolist, marking it as FINISHED and filling the return value if any, and updates the information of the contract including the version number and the hash of contract state. Then the user can fetch the return value and decrypt it by Key〖_req〗. If the result is marked as a settlement, the bounty contract will generate a settlement transaction with the settlement information in the response. The first worker to finish it will obtain the remuneration.

B8. Once the result is acknowledged by bounty contract, the other workers in TEE-DS will accept the modification.

Use Cases

In this section we introduce some use cases to explain how we can use the ShadowZone to preserve the privacy of smart contract.

Protecting Simple Vote

We first implement a simple vote example to show the confidentiality of private contract. The scenario is that some people want to start a vote between themselves by a smart contract on the EOS, but they do not want to expose the content of this vote to the public. In our implementation, we assume that the participants know and trust each other and create the vote contract together. Algorithm [code:vote] shows the approximate logic of the example but not the detail.

First, all the voters agree on the voting code (private contract). Then they deploy the contract as described in Section [subsec:protocol], which can be performed by any one of the participants. After the deployment is acknowledged, each participant can invoke the cast() function to cast their ballot. The cast() operation will be executed by workers using hardware enclave. Any participant can invoke the check function to query the current state of the vote at any time.

It is noteworthy that the whole process of the vote including the cast and the check is hidden and only the participants can view it. The workers can get involved in executing but they will never know what indeed happens inside the contract. If a participant is malicious in this case, he/she can only leak the vote result but not the detailed information.

[t]0.98 [1]⊳ #1
[H] [code:vote]
[1] $\boldsymbol{vote} \gets {0,0,0,0,0}$ $\boldsymbol{vote}[option]++$

Protecting Transaction Details

We consider the following scenario: a seller and a buyer have a contract with a certain price and quantity of some commodity. The key secret of the scenario is the detail of the purchase including the price, the quantity and maybe some promotion strategy in some complicated cases, while the result (i.e., the total money transferred) which will eventually be reflected on the EOS is not protected. The approximate code is shown in Algorithm [code:transaction]. To ensure the efficacy of the contract, the buyer is required to deposit some funds as balance before making a purchase, which is done by invoking the deposit() and send the corresponding tokens to the bounty contract. Once the both parties are prepared to make a deal, they can invoke the purchase() with the negotiated price and quantity. The invocation of purchase() requires to be signed by both parties. Either party can invoke the settlement() for a refund. The bounty contract will check the total amount of refund before generating the settlement transaction.

The example can be extended to a multi-participants scenario which can hide the detail of transactions among the participants and do settlement regularly. Although the transfer of tokens is public on EOS, it is acceptable in many cases because the privacy of transaction details is much more important. And users can do a settlement after a number of transactions, which mixes up the results of these transactions and makes it difficult to resolve.

[t]0.49 [1]⊳ #1
[H] [code:transaction]
[1] int seller_addr int buyer_addr int seller_blc int buyer_blc
buyer_blc+=amount
buyer_blc-=amountprice seller_blc+=amountprice
settlement←new Transaction() settlement.add(seller_addr,seller_blc) settlement.add(buyer_addr,buyer_blc)
[t]0.49 [FOR]ForEach[1] #1 [1]⊳ #1
[H] [code:second-price]
[1] Map⟨int,int⟩ $\boldsymbol{balances}$ int bestPrice←-1 int secondPrice←-1 int winner←-1 int seller←-1
$\boldsymbol{balances}.clear()$ seller←addrOfSeller
$\boldsymbol{balances}.insert(addr,funds)$
secondPrice←bestPrice bestPrice←price winner←addr
secondPrice←price
settlement←newTransaction settlement.add(seller,secondPrice) $settlement.add(winner,\boldsymbol{balances}[winner]$ -secondPrice)
settlement.add(b.first,b.second)

Second-Price Auction

In a second-price auction, the bidder who offers the highest price wins but pays the second highest price. The essential element of second-price auctions is that bidders offer bids without knowing the bid of other bidders.

We implements an example auction program using the ShadowZone, as shown in Algorithm [code:second-price]. The code above is an approximation of our real implementation. There are two different roles in this case: the manager and the bidders. First the manager can start an auction with the seller’s address so that the fund can be transferred to the seller immediately once the auction ends. After the auction starts successfully, each bidder can offer their price by invoking bid(). Since the tokens transfer on EOS is public, from which the bid price could be inferred, so we allow a user to obfuscate the real price by sending an arbitrary (but more than the real price) amount of tokens to bounty contract, and the excess will be returned to the user after the auction ends. The manager will decide when to conclude the auction and invoke the conclude() to transfer the money from the winner to the seller and refund other bidders’ funds.

ShadowZone guarantees the input independent privacy that each user can never see others’ bids even after the auction. In this way, users’ bids are independent of others’ bids. Also, the manager’s function is limited to starting and terminating the auction. Even if the manager is malicious, he/she cannot disclose any information of the auction.

Security Analysis

In this section, we discuss how ShadowZone mitigates potential attacks. Each party may send, drop, modify, record arbitrary messages in the protocol at any time during the contract deployment and invocation. So we discuss and evaluate the security of ShadowZone.

Malicious Worker: During the contract deployment, an attacker may pretend to be a worker and defraud the user of the code of his/her private contract. To defend this attack, remote attestation is required before the communication. The worker must provide a report which is signed by hardware-protected key to prove that he/she runs the unmodified worker client in enclave indeed. Even if the attacker has compromised the network, he/she cannot spy or tamper any message because the communication between the user and the worker is based on a secure channel which is protected by a session key after remote attestation. If the user who performs the deployment is dishonest, he/she cannot get any more privileges than other users in that the secret key of the contract is generated and kept by enclaves.

Stealing Invocation Information: The contract invocation is mediated by bounty contract which is publicly visible on the EOS. An attacker may try to steal the invocation information by spying the bounty contract. But this will not work because all the secrets of invocation are encrypted. The user encrypts the arguments with the public key of the contract, and oppositely, the enclave will encrypt the corresponding return value by another key which is transferred along with the arguments by the user. So the attacker can only see the inessential information such as the amount of the remuneration. Since the secrets of an invocation are fully hidden except for the invoker, ShadowZone can guarantee the personal privacy without any exposure risk from a malicious manager, which is a potential concern of some other private blockchain system such as Hawk [5].

Integrity of Invocation: There are potential attackers including dishonest workers who want to compromise the integrity of the invocation by tampering invocation requests or committing fake results. Since the invocation requests are acknowledged on EOS, attackers can manipulate them only by controlling more than half of the state of EOS, which is considered impossible. The response of an invocation includes IVS which contains the hash of corresponding arguments and is signed with the contract’s private key by the enclave. The bounty contract can check the IVS with the contract’s public key to verify that the worker executes the contract correctly with the given arguments inside an enclave. So no one can fake a response to the bounty contract.

Replay Attack: To protect the private contract from the replay attack, each message will be endowed with a timestamp. When the bounty contract receives an invoke message, it will first check the timestamp and refuse the old requests. The communication between users and workers will be protected in the same manner. Furthermore, the response of an invocation must specify the corresponding task in the todolist of the bounty contract. Thus the only one response will be accepted by the bounty contract for one task. It is worth noting that the worker’s address inside the IVS decides who will gain the remuneration so it is no use for attackers to intercept the IVS.

We implement ShadowZone using Intel SGX which guarantees the integrity and confidentiality of the execution. Intel SGX can protect the execution of smart contracts from attackers on the same host, even those who compromise the OS or control physical access. All the data of the contract is encrypted except inside the enclaves. Malicious workers or attackers on the same machine can only stop service, modify or record the encrypted messages, which will not harm the integrity and confidentiality of our system. For the attacks which exploit the hardware vulnerabilities (e.g., Meltdown and Spectre CPU security flaws), Intel has submitted patches to fix the problems. Actually, most side-channel attacks require multiple attempts to steal information from the enclave, so we can prevent these attacks effectively by limiting the execution times. This is a good idea we will probably implement in the future.

It is worth noting that our protocol is not Intel specific and we can implement out system easily on the base of another trusted hardware.

Discussion

Availability: Currently, the availability of a blockchain system depends on the participation to a large extend. Similarly, ShadowZone needs a number of workers to comprise the TEE-DS and provide services for private contracts. A nascent system always lacks user participation and few workers are willing to work, and it will take a long time to develop to maturation. So we choose to build our system on the base of the mature EOS system and make use of its availability without any modification to the EOS.In addition to EOS, we also need to establish a public platform to provide related services such as the client download (both the user client and the worker client) and maintaining the information of TEE-DS. With these services, anyone who has a machine with enclave can download a worker client, and then find and join the TEE-DS as a worker. In the beginning, we may build the TEE-DS with few nodes as a test version. With the broad participation of EOS, we anticipate that the requirement of private smart contracts and the remuneration will draw more users and workers in.

Incentive Mechanism: In current design of ShadowZone, workers only get remuneration for executing contracts. But there is no incentive mechanism for storing private contracts. Thus some utilitarian workers may stop their machines immediately after one task, and keep waiting until new tasks are sent to bounty contract. Since the remuneration is only gained by the fastest worker, the time of execution is closely connected with profit. If a worker only executes contracts without storing them, the latency of synchronizing data (e.g., binary of contracts) from other workers will add more overhead to execution time and reduce expected profit, which motivates workers storing private contracts locally. Furthermore, the worker client is executed as a whole and the response is generated only after all the work is done (including spreading data to other TEE-DS nodes), which is ensured by enclave, and hence no worker can perform part of the execution to maximize profit.

Workload Measurement: Ethereum provides a gas mechanism, which endows every operation with a fixed price. With Ethereum’s runtime environment (EVM), the workload of each execution can be measured and then the gas consumption can be calculated with the gas price. The execution will exit immediately once the gas is run out. This mechanism can prevent DoS attacks such as requests for executing some infinite loop within smart contracts. In our current implementation, the contract is executed in the native environment without a similar monitoring mechanism. To solve this problem, we can measure the workload by execution time. Each invocation task will be endowed with a timeout corresponding to the amount of remuneration. If some workers finish the execution before timeout, the first one will win. If the workload of the execution is so heavy that no worker can finish it within before timeout, workers can still gain the remuneration with a measurement to prove that the execution indeed exits after a timeout. The measurement can be generated by enclave, which is similar to Proof of Elapsed Time (PoET) used by Hyperledger Sawtooth .

Conclusion

We introduced ShadowZone, a system that addresses a major concern about the current smart contract systems based on the blockchainthe lack of confidentiality. Unlike the pure and computationally complex solution (such as Zcash) and the reconstructed licensing chain (such as Coco), ShadowZone can guarantee the confidentiality of existing public blockchains like EOS without any modification. ShadowZone separates the process of the verification of a smart contract from the private execution, and only puts the verification onto the blockchain, without revealing any secrets. The actual logic of smart contracts is executed by off-chain TEE and the communication is encrypted by a secret key only kept by the TEE.

We used a native EOS smart contract named bounty contract to handle the publishing, verification and settlement of a private contract, which ensures the integrity and coerciveness. Then we presented the applicability by case studies. We believe that ShadowZone is a practical approach to building confidential public smart contract systems.

Our site: http://shadowzone.io/