Private Smart Contract Execution

A survey of existing proposals

Introduction

Smart contracts are immutable programs that run, when predetermined conditions are met, on blockchains. They are used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any third party involvement or time loss. While smart contracts inherit the availability and other security assurances of blockchains, they also inherit blockchains’ lack of confidentiality.

Lack of privacy is a huge concern. Blockchain platforms such as Bitcoin or Ethereum do not support privacy as all records are logged in the clear on the blockchain, allowing anyone to read their contents. Moreover, it is possible to link random-looking addresses to the real identities of their owners. This is a problem as users do not want their activity to be disclosed, not to mention their more sensitive data such as votes or health-related information.

In general, the privacy of a smart contract consists of the following parts:

• Privacy of the specification: The source code of a private contract must be hidden during the deployment and subsequent process of execution and synchronization.
• Privacy of the execution: once a private contract is invoked, the executing process on a worker client must be kept secret and the call arguments, together with the return values should be hidden during the execution.
• Privacy of the state: The internal state of a private contract may contain users’ secrets and can reflect the information of recent transactions.

This survey presents a, provably non-exhaustive, list of the existing proposals concerned about solving the problem of the lack of privacy of smart contracts.

Hawk and zkHawk

Hawk

Hawk was originally designed to improve the Zerocash protocol but can be used with a cryptocurrency supporting private transactions.

Hawk splits a smart contract into a public contract, which runs on-chain, and a private contract executed off-chain.

The public contract gathers inputs and funds from the participants, whereas the private contract takes the form of a cryptographic protocol that decides how the funds collected and held by the public contract are to be distributed. The public contract will only distribute funds according to valid instructions from the private contract.

Hawk requires the figure of a manager to execute the private contract. The manager must be trusted by the participants, as it can see the transactions that take place in a private contract. The manager cannot affect the outcome of the contract, it just could prevent the contract execution, or cause the abortion of the contract, and in both cases, it would be castigated.

The logic contained within the private contract can be kept private from everyone except the manager.

Parties can verify that the public contract distributes the funds according to a valid instruction from the private contract and that the private contract operations cannot be influenced by the manager.

If the public blockchain supports private transactions, then the identity of the participants can be kept secret from everyone, including the manager. The inputs and funds the parties send to the public contract will only be visible to the manager.

zkHawk

As one may imagine, Hawk’s main inconvenience is the figure of the manager, which must be trusted not to leak each party’s input to the smart contract.

In the zkHawk proposal, the authors present a protocol that replaces the manager with a multi-party protocol (MPC) that makes the function to be executed by the protocol relatively lightweight, involving little overhead added to the smart contract function. The proposal also makes use of Σ-protocols and homomorphic commitments to prove to the blockchain that the sum of the incoming balances in the smart contract matches the sum of the outgoing balances.

Enigma

Enigma is intended to complement an existing blockchain using distributed secure multiparty computation.

Enigma makes use of secure MPC to compile its protocol as an arithmetic circuit, with the individual arithmetic operations distributed across several untrusted nodes: users’ data is encrypted, split up, and distributed across the nodes. Each node carries out a single step in the computation and passes the encrypted result on to the next node. The Enigma protocol provides the framework for coordinating the computation. Eventually, the user receives the encrypted result, which only they can decrypt.

While the computational logic cannot be considered confidential, since it is disclosed to the computation nodes, the data being processed is encrypted, so the inputs and outputs remain confidential.

The computation nodes are also required to make security deposits to ensure that they execute their code.

Raziel

Raziel is a system based on secure MPC that computes smart contracts preserving privacy while assuring correctness and verifiability. The main contributions are:

• Practical formal verification of smart contracts: the proofs accompanying the smart contracts can be used to prove functional correctness of computations as well as other properties such as termination, invariants and any other requirements for well-behaved code.
• The code producer can convince the executing party of the smart contract of the existence and validity of proofs about the code without revealing any actual information about the proofs themselves or the code of the smart contract.
• A protocol for secure computation that allows offline parties and private parameter reuse.
• Using zero-knowledge proofs to prove the validity of smart contracts before execution.

Raziel tackles on-chain and off-chain secure computations separately:

• For on-chain secure computations, the validation of transactions happens through the replicated execution of the smart contract. As privacy-preserving smart contracts require a significant resource consumption, the system avoids the execution of the same privacy-preserving smart contract on every node by allowing query commands on a large enough group of nodes.
• Concerning off-chain secure computations, the system makes use of oracle-like calls.

Zether

In Zether both the transaction amounts and the sender and receiver are hidden. It is implemented as a smart contract called Zether Smart Contract (ZSC) and has a token called Zether (ZTH) that is transferred between Zether accounts.

Zether can be extended to support those smart contracts represented uniquely using homomorphic addition. This allows performing simple sealed-bid auctions (assuming bidders buy all units on offer) and private voting (assuming the votes are binary).

In Zether, the amount of a transaction is encrypted and coupled to a proof showing that the sender is doing a convenient fund transfer.

The functioning of Zether is the following: user A, with Ethereum address A, creates a key pair and sends a transaction enclosing the public key and depositing some ether in the ZSC. The ZSC creates an account, identified with the public key, with the same amount of ZTH. User A can send ZTH confidentially and anonymously to any other Zether account.

User A may encrypt the amount if she wants to hide it. In case user A wants to hide her account, she selects a set of other Zether accounts called anonymity set and hides its account in this set, so it looks like one of the accounts from that set made a transaction with a hidden amount.

Zexe

The functioning of Zexe is essentially the same as we have surveyed previously: computations are done off-line and then a proof of correct execution is uploaded to the ledger. The authors introduce a new cryptographic primitive called decentralized private computation (DPC) and come up with some efficient implementation strategies including zk-SNARK optimization, recursive proof composition and a new set of elliptic curves.

Zexe provides two security properties:

• Privacy: a transaction reveals no information about the offline computation, except an upper bound on the number of consumed inputs and created outputs.
• Succinctness: a transaction can be validated in an amount of time that is independent of the cost of the offline computation whose correctness it attests to.

Offline computations in Zexe can be used to realize state transitions of multiple applications simultaneously running atop the same ledger.

Zexe users do not need to trust each other; this fact is achieved thanks to a shared execution environment, which has the following properties:

• Extensibility: users may execute arbitrary functions of their choice, without seeking anyone’s permission.
• Isolation: functions of malicious users cannot interfere with the computations and data of honest users.
• Inter-process communication: functions may exchange data with one another.

The core of Zexe, DPC (decentralized private computation), supports a programming model where the units of data are bound to scripts that specify the conditions under which a record can be created and consumed.

Zexe makes use of zk-SNARKs and recursive proof composition to get an efficient implementation of the DPC protocol.

Since verifying SNARKS is cheap, but producing them can be expensive, Zexe makes use of delegable DPC, where the user communicates details to an untrusted user about the desired transaction, then the user produces the transaction, and finally, the user authorizes it via a cheap computation that does not violate indistinguishability of transactions. Delegable DPC protocol also extends to support threshold transactions.

Zkay (v1 and v2)

Zkay v1

The main idea behind zkay is that users can define privately owned variables, represented as ciphertexts on the public smart contract. Updates to these variables can be issued using non-interactive zero-knowledge proofs (NIZKs), henceforth achieving privacy maintenance. The zkay system includes a compiler that transforms the smart contract code into two independent pieces of code as a circuit description of the code that is supposed to be run inside a zk-SNARK. In particular, zkay makes use of the zk-SNARK developed by Groth and Maller.

The language of zkay includes privacy annotations that specify the ownership of internal script variables. These annotations allow the author of the private smart contract to limit access to the concrete script variable to a single address so that the variable can be read exclusively by the owner of that address.

Zkay includes other features, such as handling of statements for declassifying the secret information; this component, combined access annotations, provides a user environment that is enough to implement various smart contracts with nontrivial privacy access structure.

After a zkay script is written and passed to the compiler, it is transformed into a Solidity contract that uses NIZKs to perform the private operation.

Zkay v2

Zkay v1 presents some limitations, including:

• Insecure encryption: it uses an encryption method that does not ensure confidentiality. Further, zkay v1 leverages the ZoKrates framework for NIZK proof generation and verification, which does not support realistic encryption functions.
• Missing integrity verification: zkay v1 does not provide tool support for verifying whether the bytecode of a deployed smart contract corresponds to a given zkay contract.
• Undefined behaviour: transaction transformations in zkay v1 uses arbitrary-precision integers instead of emulating the under and overflow semantics of fixed-sized integers. The user is required to ensure the absence of under and overflows as these may result in security vulnerabilities such as the possibility of permanently locking the funds of a contract.
• Initialization: zkay v1 assumes that variables are always initialized and does not model the zero initialization semantics of Solidity. When reading an uninitialized variable, transaction transformation in zkay v1 may therefore produce an invalid proof.

To improve the system, the authors developed a new version with the same work functioning but including a series of improvements, including:

• Adding support for state-of-the-art asymmetric and hybrid encryption.
• Introduction of essential language features including function calls, cryptocurrency-related functionality, private control flow, extended type support.
• Support for different zk-SNARKs backends;
• Provision of a live transaction runtime automatically transforming transactions, computing the necessary zero-knowledge proofs, and directly interacting with a blockchain.
• Several usability improvements such as improved error messages and simplified installation.
• Reduction of both compilation time and on-chain costs.

ShadowEth

The goal of ShadowEth is to provide a confidential platform to execute private smart contracts which can be integrated with existing blockchains like Ethereum.

ShadowEth splits the process of the verification of a smart contract from the private execution, and only puts the verification onto the blockchain, without revealing any secret.

The actual logic of smart contracts is executed by off-chain trusted executed environments (TEE), which creates a secure area that guarantees the integrity and confidentiality of code and data inside, and the communication is encrypted by a secret key only kept by TEE.

The system uses a native Ethereum smart contract named bounty contract to handle the publishing, verification and settlement of a private contract, which ensures integrity and coerciveness.

To guarantee the confidentiality of code and data of a smart contract, a secure channel between a user and TEE 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, the authors suggest putting the information of invocation and verification onto the blockchain. TEE will generate a key pair for this contract during the deployment of a private 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.

To guarantee the confidentiality of the persistent state of a private contract, ShadowEth stores only the hash of the ledger on Ethereum instead of all data.

Ekiden

Ekiden approaches the lack of confidentiality of smart contracts by combining blockchains with Trusted Execution Environments.

Ekiden’s architecture separates consensus from execution, enabling efficient TEE-backed confidentiality-preserving smart contracts and high scalability. Ekiden uses compute nodes to perform smart contract computations over private data off-chain in TEEs, then attest to their correct execution on-chain. The underlying blockchain is maintained by consensus nodes, which need not use trusted hardware.

Once deployed on Ekiden, smart contracts are endowed with strong confidentiality, integrity and availability guarantees by using a hybrid architecture combining trusted hardware and the Blockchain. This hybrid architecture takes into account three entities:

• Clients: these are end-users of smart contracts. They can create contracts or execute existing ones with secret input. Clients delegate computations to compute nodes.
• Compute nodes: these nodes process requests from clients by running the contract in a contract TEE, and generating attestations proving the correctness of state updates.
• Consensus nodes: these nodes maintain the blockchain by running a consensus protocol. Contract state and attestations are persisted on this blockchain. Consensus nodes are responsible for checking the validity of state updates using TEE attestations.

In contrast to Ethereum, where request execution is replicated by the whole network, Ekiden requests are only executed by a small number of compute nodes, and consensus nodes just verify the same number of proofs of correct execution without repeating the execution.

One can highlight the following three critical building blocks in Ekiden:

• Proof of publication: A proof of publication is an interactive proof between a verifier E, in the form of a contract TEE, and an untrusted prover P. The prover P has a limited amount of time to publish the message in a block within a subchain of sufficient difficulty so that an adversary cannot feasibly forge it.
• Key management: Each Ekiden contract is associated with a set of keys, including a symmetric key for state encryption and a key pair to encrypt client input.
• Atomic delivery: TEE execution yields two messages: m1, which delivers the output to the caller, and m2, which delivers the state update to the blockchain, both via adversarial channels. It is critical to enforce atomic delivery of the two messages, meaning that either both m1 and m2 are delivered or the system has become permanently unavailable.

Arbitrum

In Arbitrum, smart contracts are implemented as independent virtual machines (VM) under the control of a predetermined set of managers, which are tasked with ensuring that state changes from the VM are performed correctly.

Managers accept state changes without repeating the computations on-chain unless there is a dispute between themselves. In the case of a dispute, the bisection protocol occurs:

The bisection protocol begins when a manager has made a disputable assertion and another manager has challenged that assertion. Both managers will have put down a currency deposit.

Once both managers make a currency deposit, the bisection protocol begins as follows: at each step, the asserter divides the assertion into two assertions, each involving half as many steps of computation by the VM, and the challenger chooses which half it would like to challenge. They continue this bisection protocol until an assertion about a single step is challenged, at which point the asserter must provide a one-step proof that the Verifier can check.

The asserter wins if provides a correct proof; otherwise, the challenger wins. The winner gets their deposit back and also takes half of the loser’s deposit. The other half of the loser’s deposit goes to the Verifier.

At each point in the protocol, a party has a limited time interval to make their next move, and that party loses if they fail to make a valid move by the deadline

An important drawback of Arbitrum is that correctness is guaranteed so long as at least one manager is honest, as these managers are trusted to maintain the privacy of users’ inputs and not reveal them to others.

There are four types of roles in the Arbitrum protocol and system:

• Verifier: it is the global entity that verifies the validity of transactions and publishes accepted transactions. The Verifier might be a central entity or a distributed multiparty consensus system, a worldwide collection of miners as in the Bitcoin consensus protocol, or a smart contract on an existing cryptocurrency.
• Key: it is a participant in the protocol that can own currency and propose transactions. A key is identified by the hash of a public key. It can propose transactions by signing them with the corresponding private key.
• Virtual machine (VM): it is a virtual participant in the protocol. Every VM has code and data that define its behaviour. Like keys, VMs can own currency and send and receive currency and messages. A VM is created by a special transaction type.
• Manager: this role is associated with a VM and is a party that monitors the progress of a particular VM and ensures the VM’s correct behaviour. When a VM is created, the VM's transaction specifies a set of managers for the VM. A manager is identified by the hash of its public key.

Kachina

Kachina is a theoretical construction, based in Universal Composability (UC), providing an abstraction for public and private state separation, together with a framework in which contracts can be proven secure, instead of providing an extension for a language as done in Zkay.

Kachina requires to formally specify the contract transition function Γ, which is the core of the interaction between users and the contract. Γ must be written in such a way that interactions with the public state of the contract and a set of private states are abstracted as communication with separate programs, called public or private state oracles respectively. The requirement forces to separate publicly accessible information, such as public contract variables, from the private states of users, which are generally stored on the user side, and may include secret data. Moreover, Γ does not maintain any state, since it is all delegated to the oracles.

The transition function describes the behaviour of the contract and manages the changes of the public and private states under certain requests. Kachina also includes an ideal behaviour function Δ and a leakage function Λ. The first one expresses a high-level intuition about the behaviour of Γ. The leakage function maps every possible input to the contract to the leakage that this contract does provide.

Kachina guarantees the soundness of the system since it will not be possible to prove that the system is secure if our leakage expectations Λ are strictly weaker than the real leakage, or if our modelled behaviour and possible attacks in Δ are less general than ones allowed by the transition function defined earlier.

Conclusions

Despite the importance of Blockchain technology, the impact of its appearance in the new computational models and the increasing number of applications, privacy is an aspect that has not received attention enough until the appearance of the first studies, which are seeds for an active research field.

The weight that multi-party computation, homomorphic cryptography, and zero-knowledge proofs have in some of the proposals give a good idea about the fact that providing the Blockchain with privacy is not a trivial task that involves interesting research. Private smart contracts present an important number of challenges, concerning efficiency and trust, requiring alluring theoretical and practical techniques and points of view allowing to tackle these challenges.