Keywords

1 Introduction

Ethereum introduced the first implementation of Turing-complete smart contracts for blockchains, widely adopted for financial and contracting applications since its introduction in 2015. Smart contracts offer auditability and correctness guarantees, and as a consequence expose both their state and any submitted inputs to all participants of the blockchain network. This lack of privacy not only leaks user data but also gives rise to concrete attacks. For example, current Decentralised Finance (DeFi) and Decentralised Autonomous Organisations (DAO) are vulnerable to front-running [23] in token transactions and proposal voting. This motivates the need to shield user inputs and internal contract state from the very parties who execute smart contracts in a decentralized environment.

Challenges. Hawk [37] introduced the first notion of general-purpose privacy preserving smart contracts, which required users to privately submit both input strings and confidential balances to a trusted contract manager. Upon evaluation of the contract over private inputs, the contract manager settles the confidential outputs to a confidential ledger, proving in zero knowledge that these outputs have been obtained according to the contract’s instructions. Importantly, in order to accommodate real-world applications such as DeFi or DAO’s, we must extend the Hawk notion of confidential contracts as follows:

  1. 1.

    Distribute the role of the trusted third party in an efficient manner, avoiding a single point of failure without significantly sacrificing performance.

  2. 2.

    Only require clients to be online during a short input phase; as in the standard client-blockchain interaction model, clients only broadcast signed inputs.

  3. 3.

    Allow privacy preserving smart contracts to be long-running applications over indefinite rounds, as is the case in standard, public smart contracts.

Our Contributions. In this work we present “Eagle”, a Universally Composable [17] protocol for achieving efficient privacy preserving smart contracts, which handles all the three challenges explained above: (1) is achieved by evaluating the contract’s instructions via an outsourced secure multi-party computation (MPC) protocol [31], where clients provide private inputs and servers execute the bulk of the protocol to compute a function on these inputs without learning them. We use a MPC protocol, known as insured MPC, which allows a public verifier to identify servers aborting at the output phase, so that cheating servers can be identified and financially punished, incentivizing fairness (i.e. if a server gets the output, all servers/clients also get it) [7]. That is, by combining outsourced and insured MPC we get a protocol where client computation and interaction is independent of the circuit computed in MPC and where reliability is incentivized and security is obtained as long as only a single MPC is honest. (2) is accomplished with a novel input protocol which pre-processes data necessary for the servers to generate private outputs (e.g. token amounts) that are posted directly to the public ledger but can only be read by specific clients. (2) facilitates (3), realized by a reactive version of our MPC protocol, which maintains a secret off-chain state over multiple rounds. Here, we contribute a model of long-running, privacy preserving contracts, which at the onset of each round accepts new inputs from any subset of clients. At the end of each round, clients get public outputs and servers keep a secret internal state, allowing evaluation to take place in a continuous, multi-round fashion, even if clients are offline (2).

Applications. Several general applications for privacy preserving smart contracts have already been proposed. Auctions: can be realized securely on-chain with privacy preserving smart contracts, as auctions implemented without privacy are vulnerable to front-running (miners can trivially observe individual bids posted to the ledger). Identity management: Decentralized Identity (DID) management considers the setting where user-attributes are posted to a ledger, in a certified, yet hidden manner. DID implemented with privacy preserving smart contracts enables proofs and computations on private identity attributes, facilitating their integration with blockchain applications. KYC Mixing: We can construct a privacy preserving smart contract to realize a mixer that enforces Anti Money Laundering (AML) policies. For example, such a mixer could use DID to integrate Know Your Customer (KYC) information to either limit user permissions or the quantity of mixed tokens allowed per month. Side-chains: The MPC servers alone could be considered a privacy preserving side-chain. Multiple sets of MPC servers could work together with a single smart contract to realize a privacy preserving sharding scheme on any layer 1 chain with Turing complete smart contracts. AMMs and DeFi via Cross-chain contracts: Using ideas of P2DEX [9], we show that the MPC servers can interact with smart contracts on many different ledgers. Hence, privacy preserving smart contracts can work across multiple ledgers and different native tokens. This realizes cross-chain, front-running resistant automated market makers (AMMs) with strong privacy guarantees. We discuss these applications in more detail in the full version [6].

Our Techniques. We sketch our protocol in Fig. 1. This only considers execution of a single instance of a privacy preserving smart contract for simplicity. We discuss the multi-round setting in the full version [6]. where computations are executed continuously with different sets of clients. We assume a set of clients \(\mathcal {C}\) and MPC servers \(\mathcal {P}\), both interacting with a ledger functionality \(\mathcal {F}_{\textsf{Ledger}}\). The ledger hosts two deployed smart contract instances: \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\) maintains a confidential ledger and is extended with \(\mathcal {X}_{\textsf {Lock}}\), which locks and redistributes confidential balances, output and jointly signed, by the MPC servers. Concretely our protocol runs the following phases:

Fig. 1.
figure 1

Outline of our protocol for confidential contracts. The wrapping and interaction of functionalities are shown.

Full size image

Init. Before any execution, the servers setup the system by sampling a threshold signature key pair and provide sufficient collateral for the insured MPC execution, and setup smart contact \(\mathcal {X}_{\textsf {Lock}}\), administered by the distributed signature key. We note that in the multi-round setting this only needs to be executed once for the specific set of MPC servers, and is thus independent of the clients and the amount of computations that will get carried out later.

Enroll. When a privacy preserving smart contract is to be executed, each client who wish to participate transfers confidential tokens to \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\) which they wish to use as input to the confidential smart contract \(\textsf {\underline{C}Contract}\). The client then gives any auxiliary input, along with the opening information to the commitment containing their confidential balance v, to the insured MPC functionality \(\mathcal {F}_{\textsf{Ident}}\) from the work of Baum et al. [7, 9], extended with a secure client input interface to allow for outsourced MPC [31] and described in detail in the full version [6]. Each client constructs an appropriate amount of “mask” commitments; one for each round of confidential contract computation, for which they wish their input to be used. A masking commitment is simply a commitment to a random value.

Verify Input. The servers validate the input received from the clients using outsourced MPC, and ensure that \(\mathcal {X}_{\textsf {Lock}}\) has also received the appropriate confidential tokens. The servers and the clients also execute a proof to ensure that the opening information supplied by clients are indeed valid for the confidential token commitments. They do this following a standard \(\Sigma \)-protocol where each client commits to a random commitment a and servers select a random challenge \(\gamma \) and ask the client to open \(\text {com}(c)=\text {com}(a)\oplus (\gamma \odot \text {com}(v))\). Similarly the servers use MPC to securely open \([c]=[a]+\gamma \cdot [v]\) and check consistencyFootnote 1.

Evaluate. After the checks are completed the servers evaluate the circuit expressing the private smart contract \(\textsf {\underline{C}Contract}\), using insured MPC. For the clients who are supposed to get output from this round of computation, shares of messages and randomness for a new commitment for each client are computed, and blinded with the “masking” values the clients provided during Enroll. If this goes well, the servers distributedly sign a message saying that they have reached this stage and post it to \(\mathcal {X}_{\textsf {Lock}}\).

Open. For clients that receive output after this round of computation the servers open the masked output. They publish these values and sign them, as part of the transcript of the current round execution, and post this to \(\mathcal {X}_{\textsf {Lock}}\). Note that \(\mathcal {X}_{\textsf {Lock}}\) can generate the output coins in commitment form, due to the homomorphism of the commitments and since it obtained the mask commitments from the clients in \(Enroll \). \(\mathcal {X}_{\textsf {Lock}}\) can then transfer the new confidential tokens back to the client’s address. We show an extension to our protocol in the full version [6]) that ensures no token minting can occur even if all servers are corrupted.

Withdraw. Based on the masks they constructed, the clients who are supposed to receive outputs can compute the coin commitment openings from their masked outputs signed and posted to \(\mathcal {X}_{\textsf {Lock}}\) by servers during Open.

Abort. In case a server stops responding or acts maliciously, an honest server can request the entering of an abort phase. Any server can do this, either by submitting a proof that the malicious server sent wrong information or by requesting missing information from the accused servers. At this point the accused malicious server has a constant amount of time left to prove to the smart contract that they did not abort, by submitting the message that the accusing server claims they didn’t get. If they don’t, they will have their collateral revoked and it will be shared among the honest servers and clients, and the contract state will roll back one round, i.e. to the contract state preceding Evaluate. Concretely \(\mathcal {X}_{\textsf {Lock}}\) will refund the clients their input funds, plus a compensation obtained from the cheating servers’ collateral.

Related Works. A long line of work realizes notions of privacy preserving smart contracts that sacrifice privacy [21, 32, 35, 37, 41, 46,47,48] or flexibility [14, 15]. Zexe [14] extends the ZCash model of confidential transactions to enable Bitcoin Script-like stateless privacy preserving smart contracts supporting only very simple logic. Zether [15] implements confidential transactions on top of Ethereum, allowing for very simple privacy preserving applications (e.g. auctions). Zkay [47] allows for computing on encrypted private inputs by means of keeping data encryption on the blockchain, and using NIZKs to validate that any updates done to the encrypted is carried out correctly. Follow-up work, Zeestar [46] uses additively homomorphic encryption to allow for limited private computation on data from multiple owners, without them having to share their private data with each other. Secret Network [48] and Ekiden [21] implement general purpose contracts but rely on notoriously vulnerable trusted execution environments (e.g. Intel SGX [42]) for privacy and correctness. Arbitrum [32] relies on a full quorum of parties (the servers in our setting) being honest to achieve privacy for general purpose contracts. Finally, Kachina [35] subsumes these approaches with a framework based on state oracles [41] that yields privacy preserving smart contracts, where either flexibility is limited (i.e. contract state is only updated by one client’s private input at a time) or privacy is compromised (i.e. a trusted third party must learn clients’ private inputs in order to update the state). The ideal functionality of Kachina is designed to permit input concurrency, allowing honest inputs to be finalized on a global ledger in a different order as their generation; the Kachina protocol requires private inputs to be accompanied with NIZKs proving a valid update of the private state fragment. Here, the NIZKs are not bound to a specific, public contract state and thus remain valid even if the public contract state observed by the user was updated by another user input in the meantime.

Combining MPC with blockchain based cryptocurrencies and smart contracts has been investigated in a long line of works [1, 2, 7,8,9,10,11,12, 22, 27, 36, 38,39,40] aiming at achieving fairness in the dishonest majority setting via financial punishments. The core idea of these works is having all parties, who execute the MPC protocol, provide a collateral deposit, which is taken from them in case they are caught cheating. Thus incentivizing honest behavior. However, this approach publicly reveals the amount of collateral deposited by each party, which falls short of achieving our notion of privacy preserving smart contracts, where both auxiliary data and the amount of tokens given as input to the contract must remain private. Notice that revealing the deposit amount is an issue in applications where this amount is directly related to the client’s private input, e.g. in sealed-bid auctions, where the collateral deposit must be equal to at least the client’s private bid. An auction protocol using collateral deposits with private amounts was proposed in [28] but it cannot be generalized to other tasks.

Hawk [37, App. G] does suggest to use MPC to achieve a decentralized confidential smart contracts on both token amount and auxiliary input. However, Hawk works in the ZCash model and thus their MPC solution would require the computation of SNARKs to realize the ZCash transactions, within the MPC circuit. Although it has been shown [33, 43] that integrating NIZKs with MPC can be done without degrading performance too much, there is still a performance hit. Since the construction of a single ZCash transaction SNARK still takes a non-negligible amount of time plain, this would naturally be inefficient to realize in MPC, as MPC is orders of magnitude slower than regular computation. Furthermore, they need all users to take part in the MPC computation. zkHawk [4] improves upon this, by forgoing the need of doing SNARKs in MPC, but still require all users taking part in a confidential smart contract to facilitate an MPC computation which must compute Schnorr style ZKPs on Pedersen commitments to the bit-decomposition of the amount of coins each of them hold. While V-zkHawk [5] forgoes the need of proofs of the bit-decomposed commitments, they replace it with the computation of commitments in a larger fields and a signature, in MPC instead. While more efficient, this approach would still require MPC over a large domain and contributes non-negligible overhead. In the full version [6]. we further discuss related works.

2 Preliminaries

Let \(y \,{\leftarrow \!\!{{\$}}\,}F(x)\) denote running the randomized algorithm F with input x and implicit randomness, and obtaining output y. Similarly, \(y \leftarrow F(x)\) is used for a deterministic algorithm. For a set \(\mathcal {X}\), let \(x \,{\leftarrow \!\!{{\$}}\,}\mathcal {X}\) denote x chosen uniformly at random from \(\mathcal {X}\). \(s\) denotes the computational and \(\kappa \) the statistical security parameter. Let \([\,{x}\,]\) denote secret x maintained in an MPC instance: we lift the \([\,{\cdot }\,]\) notation to any object that can be encoded over secrets securely input to an MPC scheme, e.g. \([\,{g}\,]\), where g is an arithmetic circuit over field \(\mathbb {F}\). We use a group \({{\mathbb G}}\) where the discrete log problem is hard, and which is a source group of pairing scheme. For simplicity we assume \(|{{\mathbb G}}|=|\mathbb {F}|=p\). Unless noted otherwise we use \(\log \) to denote the logarithm to base 2, rounded up. We use \(\bar{v}_{\textsf {max}}\) to denote the maximum amount of tokens we want to represent and say \(l=\log (\bar{{v}}_{\textsf {max}})\). For simplicity, we assume \(|\mathcal {C}|\cdot \bar{v}_{\textsf {max}} <|{{\mathbb G}}|\), where \(\mathcal {C}\) is the set of participating clients. We denote set \(\{1, 2, \dots , n\}\) by [n] and vectors by bold faced Latin letters, e.g. \(\textbf{v}, \textbf{w}\).

Table 1. Notation.
Full size table

2.1 Security Model and Building Blocks

We analyse our results in the the (Global) Universal Composability or (G)UC framework  [18, 20]. We consider static malicious adversaries. Our protocols work in a synchronous communication setting, which is modeled by assuming parties have access to a global clock ideal functionality \(\mathcal {F}_{\textsf{Clock}}\) as seen in multiple works [3, 34, 36]. The core component of our protocols is publicly verifiable MPC with cheater identification in the output phase, which is modelled as an ideal functionality \(\mathcal {F}_{\textsf{Ident}}\), which can be realized as described by Baum et al. [7, 9]. This functionality produces a proof that either a certain output was obtained after the MPC or that a certain party has misbehaved in the output phase, while cheating before the output phase causes an abort without cheater identification. We further extend this functionality to handle reactive computation [25, 26] and an outsourced computation with inputs provided by clients and computation done by servers [24, 31]. Moreover, we use Pedersen Commitments [44], digital signatures represented by an ideal functionality \(\mathcal {F}_{\textsf{Sig}}\) as in [19], threshold signatures represented by an ideal functionality \(\mathcal {F}_{\textsf{TSig}}\) as defined by Baum et al. [9] and non-interactive zero knowledge proofs represented by \(\mathcal {F}_{\textsf{NIZK}}\) as defined by Groth [30]. Further discussion on our security model and building blocks are presented in the full version [6].

2.2 Ledgers and Smart Contracts

We model a ledger functionality \(\mathcal {F}_{\textsf{Ledger}}\) in the full version [6]. featuring a smart contract virtual machine which is adapted from an authenticated, public bulletin board functionality, an approach adopted from the work of Baum et al. [7, 9]. For this work, we emphasize accurate modelling of confidential balances, which are implemented on a public ledger, and omit the full consensus details in our UC model, similar to previous works [3, 36].

Token Universe. \(\mathcal {F}_{\textsf{Ledger}}\) supports a token universe consisting of t token types: \(\mathbb {T} = (\tau _1,...,\tau _{t})\). A ledger in \(\mathcal {F}_{\textsf{Ledger}}\) maintains a map from signature verification key to balances of each token type: \(\mathcal {L}: \{0,1\}^{*} \rightarrow \mathbb {Z}^{t}\). We write \(\mathbf{\bar{v}} = (v_1,...,v_t)\) for a balance over all supported token types. In addition to balances associated to signature verification keys, \(\mathcal {F}_{\textsf{Ledger}}\) also maintains token balances for each deployed smart contract instance. The ledger functionality enforces the preservation of token supplies over \(\mathbb {T}\).

Overview of Smart Contracts. In this work, we present smart contracts as human-readable programs and assume the presence of a compiler which translates program \(\mathcal {X}\) to a valid circuit T and initial state \(\gamma _{\textsf {init}}\). The following smart contract programs are deployed in the protocol which realizes the proposed confidential contract functionality \(\mathcal {F}_{\mathsf {\underline{C}Contract}}\).

  • \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\) (described in the full version [6]) describes a smart contract which implements a confidential token wrapper for each token in \(\mathbb {T}\) supported on the base ledger \(\mathcal {F}_{\textsf{Ledger}}\).

  • \(\mathcal {X}_{\textsf {Lock}}\) (described in the full version [6]) is an extension to \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\). It permits the locking and redistribution of confidential balances authorized by verifying threshold signatures generated by the servers (via global functionality \(\mathcal {F}_{\textsf{TSig}}\)).

  • \(\mathcal {X}_{\textsf {Collateral}}\) (described in the full version [6]) accepts collateral deposits from servers, which upon being identified as cheating parties lose their collateral to clients.

2.3 Confidential Ledgers from \(\mathcal {F}_{\textsf{Ledger}}\)

We briefly describe a confidential ledger functionality \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\), presented in full detail in the full version [6], that can be implemented from a hybrid \(\mathcal {F}_{\textsf{Ledger}}\) functionality, enabling both confidential balances and the confidential transfer of default tokens types \(\mathbb {T}\) exposed by the underlying public ledger \(\mathcal {F}_{\textsf{Ledger}}\). This modeling choice maximizes the generality of our construction, as it can be implemented on any standard ledger and a basic smart contract machine.

Confidential Ledger. Confidential coins in \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\) are identifiable by a unique public \(\textsf {id}\), and a confidential balance \(\mathbf{\bar{v}}\) over \(\mathbb {T}\), as in [45]. Each confidential token is publicly associated with an account verification key \(\textsf {vk}_{{}}\), owned by a party that generated it with \(\textsc {GenAcct}\). A confidential transfer consumes two input coins \((\textsf {id}_1, \textsf {id}_2)\) with confidential balances \((\mathbf{\bar{v}}_1, \mathbf{\bar{v}}_2)\) and mints fresh output coins \((\textsf {id}_1', \textsf {id}_2')\) with confidential balances \((\mathbf{\bar{v}}_1', \mathbf{\bar{v}}_2')\), such that \((\mathbf{\bar{v}}_1 + \mathbf{\bar{v}}_2 = \mathbf{\bar{v}}_1' + \mathbf{\bar{v}}_2')\). Here, coin \(\textsf {id}_1'\) is now held by the owner of the receiving account, who also learns the confidential amount \(\mathbf{\bar{v}}_1'\).

Functionality \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\) exposes \(\textsc {Mint}\) and \(\textsc {Redeem}\) interfaces: a mint activation locks a public amount of tokens \(\mathbb {T}\) and generates a fresh confidential token of the same balance. Conversely, a redeem activation will release the balance of a confidential coin back to the public ledger.

Realizing a Confidential Ledger. A confidential token is realized in protocol \(\varPi _{\mathsf {\underline{C}Ledger}}\) with Pedersen Commitments [44], described in full detail in the full version [6]. Let \(g, g_1,...,g_t, h\) denote generators of group \(\mathbb {G}\) of safe prime order p, such that \(s_i\) in \(g_i = g^{s_i}\) and w in \(h = g^{w}\) are given by \(\mathcal {F}_{\textsf{Setup}}\) (parameterized with \(g \in \mathbb {G}\)) that publicly outputs \(g_1,...,g_{t}, h\). The commitment to a balance \(\mathbf{\bar{v}} = (v_1,...,v_t)\) over tokens \(\mathbb {T}\) with blinding r is \(\textsf {com}({\mathbf{\bar{v}}},{r}) = \textbf{g}^{\mathbf{\bar{v}}}h^{r} =g_{1}^{v_1}...g_{t}^{v_t}h^{r}\). Pedersen commitments are additively homomorphic: \(\textsf {com}({\mathbf{\bar{v}}_1},{r_1}) \circ \textsf {com}({\mathbf{\bar{v}}_2},{r_2}) = \textsf {com}({\mathbf{\bar{v}}_1+\mathbf{\bar{v}}_2},{r_1+r_2})\). Thus, during a confidential transfer, the sum equality between consumed input and freshly constructed output coin commitments holds if total token balances are preserved and \(r_1'\) and \(r_2'\) are correlated such that \(r_1+r_2 = r_1'+r_2'\).

$$\begin{aligned} \textsf {com}({\mathbf{\bar{v}}_1},{r_1}) \circ \textsf {com}({\mathbf{\bar{v}}_1},{r_1}) = \textsf {com}({\mathbf{\bar{v}}_1'},{r_1'}) \circ \textsf {com}({\mathbf{\bar{v}}_2'},{r_2'}) \end{aligned}$$
(1)

However, since the equality above holds for any \(\mathbf{\bar{v}}_1 + \mathbf{\bar{v}}_2 \equiv \mathbf{\bar{v}}_1' + \mathbf{\bar{v}}_2' \mod p\) and correlated \(r_1',r_2'\), an additional p units of each token in \(\mathbb {T}\) can be minted: \(\bar{v}_1 + \bar{v}_2 + p \equiv \bar{v}_1' + \bar{v}_2' \mod p\). Thus, each confidential token is associated with NIZK \(\pi \) which proves \(\mathcal {R}(c;\mathbf{\bar{v}},r) = \{ c = \textsf {com}({\mathbf{\bar{v}}},{r}) \wedge \mathbf{\bar{v}} \le \mathbf{\bar{v}}_{\textsf {max}} = 2^{l}-1 \}\), such that such wrap-around never occurs undetected.

We note that \(\varPi _{\mathsf {\underline{C}Ledger}}\) in itself affords a fully decentralized layer 2 confidential token transfer solution, since it is independent of the MPC servers. Thus allowing client’s to send a receive confidential tokens in a peer-to-peer manner. This is needed to prevent leakage of exchange orders after-the-fact by analysing client’s non-confidential tokens given as input and withdrawn as output from a privacy preserving smart contract execution. By allowing the privacy preserving smart contract executions to integrate in a greater payment ecosystem reasonably ensures that it is possible to hide token inputs and outputs from a privacy preserving smart contract execution by using them for confidential payment, similar to other confidential token systems. 

We present a protocol \(\varPi _{\mathsf {\underline{C}Ledger}}\) which GUC-realizes \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\) in the full version [6], where we also prove the following statement:

Theorem 1

Protocol \(\varPi _{\mathsf {\underline{C}Ledger}}\) GUC-realizes functionality \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\) in the \(\mathcal {F}_{\textsf{Clock}}\), \(\mathcal {F}_{\textsf{Ledger}}\), \(\mathcal {F}_{\textsf{NIZK}}\), \(\mathcal {F}_{\textsf{Setup}}\), \(\mathcal {F}_{\textsf{Sig}}\)-hybrid model against any PPT-adversary corrupting any minority of committee \(\mathcal {Q}\).

Fig. 2.
figure 2

Functionality for Confidential Contracts

Full size image

3 Confidential Contracts

We present our formal model of confidential contracts. We assume m clients \(\{ C_{1},\dots , C_{m} \}\) and servers \(\{ P_{1}, \dots , P_{n} \}\) that interact with \(\mathcal {F}_{\mathsf {\underline{C}Contract}}\), which extends \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\). For simplicity of presentation, we first present a single-round confidential contract functionality in Fig. 2, and subsequently illustrate how it is easily extended to a multi-round contract functionality where clients can selectively choose to participate in specific rounds.

The choice of modelling \(\mathcal {F}_{\mathsf {\underline{C}Contract}}\) as an extension of \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\) arises from the relation between underlying protocols: confidential coins in \(\varPi _{\mathsf {\underline{C}Ledger}}\) that are committed to a confidential contract evaluation must be locked and subsequently replaced by a new set of output coins reflecting a new distribution of balances, determined by \(\varPi _{\mathsf {\textsf {\underline{C}Contract}}}\). However, this requires verification operations over the homomorphic commitment representation of coins in \(\varPi _{\mathsf {\underline{C}Ledger}}\), which are not exposed by \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\).

We provide a brief sketch of the interface exposed by \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\). Upon initialization with an arithmetic circuit g encoding only the contract logic, users can enroll, specifying input string x and a confidential coin to input, identified by its \(\textsf {id}\). Upon a completed Enroll, the functionality is prompted by servers to evaluate circuit g on both client input strings, interpreted as numerical values, and input balances, with checks to ensure g does not mint tokens. \(\mathcal {F}_{\mathsf {\underline{C}Ledger}}\) permits clients to withdraw anytime to retrieve the private output string and output balance. \(\mathcal {F}_{\mathsf {\underline{C}Contract}}\) permits the simulator to abort and indicate cheating servers, which are then penalized by the functionality.

Model of Confidential Contracts. Unlike public smart contracts deployed to \(\mathcal {F}_{\textsf{Ledger}}\), an instance of \(\mathcal {F}_{\textsf{Ident}}\) permits the computation of any arithmetic circuit on both private and public inputs. We model a confidential contract as an arithmetic circuit over a field \(\mathbb {F}_{p}\) consistent with the domain that \(\mathcal {F}_{\textsf{Ident}}\) is realized with. A well-formed confidential contract permits the writing of both numerical and financial inputs from each client to its input gates. Further, we enforce a maximum circuit depth \(d_{T}\) prior to the circuit evaluation to bound the rounds of interaction in the MPC instance.

$$ \big (([\,{y_1}\,],[\,{\mathbf{\bar{w}}_1}\,]),...,([\,{y_{m}}\,],[\,{\mathbf{\bar{w}}_{m}}\,])\big ) \leftarrow \textsf {eval}_{g}\big (([\,{x_1}\,],[\,{\mathbf{\bar{v}}_1}\,]) ....,([\,{x_m}\,],[\,{\mathbf{\bar{v}}_m}\,])) $$

Upon confidential evaluation of a contract circuit g with well-formed depth and gates, the following assertion must be performed at each run-time over confidential inputs and outputs of evaluated g: namely, that token supplies have been preserved.

$$\begin{aligned} \sum _{i \in [m]} [\,{\mathbf{\bar{v}}_i}\,] =^{?} \sum _{i \in [m]} [\,{\mathbf{\bar{w}}_i}\,] \end{aligned}$$
(2)

One-Round Client-Server Interaction. Upon providing inputs to a confidential contract execution, clients can go off-line and retrieve confidential outputs with \(Withdraw \) at any later point in time.

Collateral. Our need for collateral follows the same logic as in Insured MPC [7]. The collateral contract incentivizes the servers to continue to participate in the privacy preserving smart contract computation, and behave honestly as they would otherwise suffer a financial loss. While the underlying maliciously secure MPC system will ensure that a server acting maliciously will cause an abort except with negligible probability, such an abort the adversary might have learned the output of the computation. This can in some situations have high value. Thus we require each server to give as collateral, strictly more than the maximum value they could gain from learning the output of a privacy preserving computation.

3.1 Realizing the Confidential Contract Functionality

Overview of Protocol. Having provided a high-level overview of the protocol phase in Sect. 1, we now proceed to detail the individual protocol phases for the single-round privacy preserving smart contract execution and refer to the full version [6] for the full protocol description and UC-security proof.

Setup of Contracts. Servers deploy instances of \(\mathcal {X}_{\textsf {Lock}}[\mathcal {X}_{\textsf {\underline{C}Ledger}}]\), \(\mathcal {X_{\textsf {Collateral}}}\) on \(\mathcal {F}_{\textsf{Ledger}}\). Since wrapper \(\mathcal {X}_{\textsf {Lock}}\) extends \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\), both are deployed and initialized as a single contract instance on \(\mathcal {F}_{\textsf{Ledger}}\) with shared contract id (\({\textsf {cn}_{\textsf {Lock}}}\)) and shared state such as the confidential ledger \((\mathcal {L}_{\textsf {Conf}})\). Here, the function of \(\mathcal {X}_{\textsf {Lock}}\) is to lock the confidential coins of clients input to the confidential contract evaluation, and to replace these with a new confidential distribution according to result of the contract evaluation. Further, \(\mathcal {X}_{\textsf {Lock}}\) is initialized with a threshold signature verification key \(\textsf {vk}_{{\textsf {TSig}}}\), jointly generated by all servers via \(\mathcal {F}_{\textsf{TSig}}\): whenever servers agree on a new status of the contract evaluation in \(\mathcal {F}_{\textsf{Ident}}\), this agreement can be settled in \(\mathcal {X}_{\textsf {Lock}}\) with a threshold signature jointly generated via global functionality \(\mathcal {F}_{\textsf{TSig}}\). \(\mathcal {X}_{\textsf {Collateral}}\) is parameterized by \({\textsf {cn}_{\textsf {Lock}}}\) and is activated each time \(\mathcal {F}_{\textsf{Clock}}\) progresses: it obtains collateral from all participating servers. It observes any recorded cheating servers \(\mathcal {J}\) stored in the state of contract instance \({\textsf {cn}_{\textsf {Lock}}}\) and enforces penalties accordingly.

Client Enrollment. Clients interact with \(\mathcal {X}_{\textsf {Lock}}\) to enroll a confidential coin it controls to the contract evaluation, and send both the coin commitment opening and numerical input x to an instance of \(\mathcal {F}_{\textsf{Ident}}\). Enrolled coins are removed from the confidential ledger \(\mathcal {L}_{\textsf {Conf}}\) maintained by \(\mathcal {X}^{\textsf {\underline{C}Ledger}}\) and moved to a dedicated ledger \(\mathcal {L}_{\textsf {Lock}}\) for funds committed to a pending MPC computation in \(\mathcal {F}_{\textsf{Ident}}\).

Clients must also commit to a output mask during enrollment, which enables the subsequent redistribution of confidential coins without client interaction in the output phase of the contract evaluation. Here each client with confidential coin input c and numerical input x performs the following:

  • Samples \(\hat{y} \,{\leftarrow \!\!{{\$}}\,}\mathbb {F}\) as a numerical output mask and sends to \(\mathcal {F}_{\textsf{Ident}}\).

  • Samples \(\hat{\textbf{w}} \,{\leftarrow \!\!{{\$}}\,}\mathbb {F}^{|\mathbb {T}|}\), \(\hat{s} \,{\leftarrow \!\!{{\$}}\,}\mathbb {F}\), and computes mask commitment \(\hat{c} \leftarrow \textsf {com}({\hat{\textbf{w}}},{\hat{s}})\).

  • Sends mask commitment \(\hat{c}\) to \(\mathcal {X}_{\textsf {Lock}}\) on \(\mathcal {F}_{\textsf{Ledger}}\).

  • Sends mask commitment openings \((\hat{\textbf{w}},\hat{s})\) of \(\hat{c}\) to \(\mathcal {F}_{\textsf{Ident}}\).

Here clients can also give any auxiliary input, x, needed for the privacy preserving smart contract computation.

figure a

Input Verification. Upon enrollment of clients, servers must verify that the confidential coin c and mask commitment \(\hat{c}\) sent to \(\mathcal {X}_{\textsf {Lock}}\) are consistent with their respective openings \((\mathbf{\bar{v}},\bar{r})\) and \((\hat{\textbf{v}},\hat{r})\) sent to \(\mathcal {F}_{\textsf{Ident}}\) during enrollment. For simplicity of presentation, we illustrate the batched input verification of input confidential coins and their openings assuming a token universe size of \(|\mathbb {T}| = 1\), such that \(c = g^{\bar{v}}h^{\bar{r}}\). Input verification for output masks \(\hat{c}\) and their openings submitted to \(\mathcal {F}_{\textsf{Ident}}\) follow similarly.

Each server obtains both confidential coin c from \(\mathcal {X}_{\textsf {Lock}}\) and additive shares of submitted openings thereof from \(\mathcal {F}_{\textsf{Ident}}\), namely \((\bar{v}^{\prime \,(i)}, \bar{r}^{\prime \,(i)})\). We write \(\bar{v}^{\prime \,(i)} = (\bar{v} + \epsilon )^{(i)}\) and similarly for \(\bar{r}^{\prime \,(i)}\), where the \(\epsilon \) denotes the error or discrepancy that the adversary can introduce to \(\bar{v}\). We employ a standard technique of evaluating a random linear combination over client inputs to verify consistency.

  1. 1.

    Servers jointly sample \(\gamma ,\alpha ,\beta \,{\leftarrow \!\!{{\$}}\,}\mathbb {F}\) and open \(\gamma \).

  2. 2.

    Each server locally computes the following on the inputs from m clients.

    • \(\bar{v}_{\textsf {lin}}^{\prime (i)} = \alpha ^{(i)} + \gamma \,\bar{v}_{1}^{\prime (i)} + \, ... \, + \gamma ^{m}\,\bar{v}_{m}^{\prime (i)}\)  and  \(r_{\textsf {lin}}^{\prime (i)} = \beta ^{(i)} + \gamma \,r_{1}^{\prime (i)} + \, ... \, + \gamma ^{m}\,r_{m}^{\prime (i)}\)

    • Subsequently, it sends \(\bar{v}_{\textsf {lin}}^{\prime (i)}\) and \(\bar{v}_{\textsf {lin}}^{\prime (i)}\) to all other servers.

  3. 3.

    Each server locally reconstructs \(\bar{v}_{\textsf {lin}}^{\prime } = \prod _{i\in [n]} \bar{v}_{\textsf {lin}}^{\prime (i)}\) and \(r_{\textsf {lin}}^{\prime } = \prod _{i\in [n]}r_{\textsf {lin}}^{\prime (i)}\)

  4. 4.

    Servers locally verify: \( \prod _{i\in [n]}g^{\alpha ^{(i)}}h^{\beta ^{(i)}} \prod _{j\in [m]} c_{j}^{\gamma ^{j}} {\mathop {=}\limits ^{?}} g^{\bar{v}_{\textsf {lin}}^{\prime }}h^{r_{\textsf {lin}}^{\prime }}\)

Note that \(\bar{v}_{\textsf {lin}}^{\prime \,(i)}\) and \(r_{\textsf {lin}}^{\prime \,(i)}\) are shares held by servers and do not reveal the values of user inputs. We write \(\bar{v}_{\textsf {lin}}' = \alpha + \gamma \,(\bar{v}_{1}+\epsilon _{\bar{v}_{1}}) + \, ... \, + \gamma ^{m}\,(\bar{v}_{m}+\epsilon _{\bar{v}_{m}})\) and similarly for \(r_{\textsf {lin}}'\) to expose \(\epsilon \)’s introduced by the adversary. If \(\epsilon \) values are committed to by the adversary before \(\alpha ,\beta ,\gamma \) are sampled, we can interpret \(\bar{v}_{\textsf {lin}}' - \bar{v}_{\textsf {lin}}=0\) and \(r_{\textsf {lin}}' - r_{\textsf {lin}}=0\) as m - degree polynomials with coefficients chosen by the adversary that are later evaluated at some random coordinate \(\gamma \): since verification step (4) implies exactly these assertions, the probability for an undetected non-zero error is therefore \(m/|\mathbb {G}|\), where m is the number of polynomial roots, by the Schwartz-Zippel Lemma.

Execute. Servers call the Evaluate interface on \(\mathcal {F}_{\textsf{Ident}}\) to evaluate circuit g with input gates set to client inputs.

$$ ([\,{x_1}\,],[\,{\hat{y}_1}\,],[\,{\mathbf{\bar{v}}_1}\,],[\,{r_1}\,],[\,{\hat{\textbf{w}}_1}\,],[\,{\hat{s}_1}\,]) ,...,([\,{x_m}\,],[\,{\hat{y}_m}\,],[\,{\mathbf{\bar{v}}_m}\,],[\,{r_m}\,],[\,{\hat{\textbf{w}}_m}\,],[\,{\hat{s}_m}\,]) $$

Upon secure evaluation, outputs in form of numerical values and balances are written to the output gates of g: \(\big ( ([\,{y_{1}}\,],[\,{\mathbf{\bar{w}}_{1}}\,]),...,([\,{y_{m}}\,],[\,{\mathbf{\bar{w}}_{m}}\,]) \big )\). Before masking these for opening, the servers then perform a confidential consistency check to ensure the preservation of tokens as shown in Eq. (2).

Masked output values are obtained by applying the masking values input by users, \([\,{y_j'}\,] = [\,{y_j}\,] + [\,{\hat{y}_j}\,]\) and similarly for balances, \([\,{\mathbf{\bar{w}}_j'}\,] = [\,{\mathbf{\bar{w}}_j}\,] + [\,{\hat{{\textbf{w}}}_j}\,]\) and generating a joint signature \(\sigma _{\textsf {vk}_{{\textsf {TSig}}}}(\textsf {evaled})\) via \(\mathcal {F}_{\textsf{TSig}}\), that is sent to \(\mathcal {X}_{\textsf {Lock}}\) on \(\mathcal {F}_{\textsf{Ledger}}\). Upon verification, the \(\mathcal {X}_{\textsf {Lock}}\) contract updates the state of protocol execution, reflecting completion of the Execute phase.

Open. Servers run \({\textbf {Optimistic Reveal}}\) in \(\mathcal {F}_{\textsf{Ident}}\) to open masked numerical outputs and balances \(\big ( (y_{1}',\mathbf{\bar{w}}_{1}'),...,(y_{m}',\mathbf{\bar{w}}_{m}') \big )\). Should all servers agree on the successful completion of the contract evaluation, they jointly sign all masked outputs and send these to \(\mathcal {X}_{\textsf {Lock}}\) (on \(\mathcal {F}_{\textsf{Ledger}}\)), which then computes the unmasked confidential coins for clients with the newly computed distribution as follows. Given the masked output balance \(\mathbf{\bar{w}}'\) from \(\mathcal {F}_{\textsf{Ident}}\) and the coin mask \(\hat{c}\) sampled by a client in \({\textbf {Enroll}}\), contract \(\mathcal {X}_{\textsf {Lock}}\) computes

  1. (a)

    The masked confidential coin: \(c^{\textsf {out}\,\prime } \leftarrow \textbf{g}^{\mathbf{\bar{w}}'}h^{0}\)

  2. (b)

    The unmasked confidential coin: \(c^{\textsf {out}} \leftarrow c^{\textsf {out}\,\prime } \cdot \hat{c}^{-1}\)

We rewrite (b) as \(c^{\textsf {out}} = \textbf{g}^{\mathbf{\bar{w}}'-\hat{\textbf{w}}}h^{-\hat{s}} = \textsf {com}({\mathbf{\bar{w}}},{-\hat{s}})\) to expose the unmasking of the output coin without any knowledge of the final balance. \(\mathcal {X}_{\textsf {Lock}}\) subsequently stores unmasked output coin \(c^{\textsf {out}}\) in the confidential ledger in \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\), thereby settling the output balance distribution read from output gates of contract circuit g. Should \(\mathcal {X}_{\textsf {Lock}}\) successfully verify the signed outputs, \(\mathcal {X}_{\textsf {Collateral}}\) will infer from the state of \(\mathcal {X}_{\textsf {Lock}}\) the completion of a successful round and return the deposited collateral to the servers.

Withdraw. Upon a successful Open, the output of the confidential contract evaluation has completed. Each client can obtain their masked output \((y',\mathbf{\bar{w}}')\) from \(\mathcal {X}_{\textsf {Lock}}\) and newly minted \(c_{\textsf {out}}\) from \(\mathcal {X}_{\textsf {\underline{C}Ledger}}\) anytime following a successful execution of a contract evaluation. Let \(\hat{y}\) and \((\hat{\textbf{w}},\hat{s})\) be the output masks generated by the client in \({\textbf {Enroll}}\). The withdrawing client obtains

  1. (a)

    The numerical output: \(y \leftarrow y' - \hat{y}\)

  2. (b)

    The opening of the output coin: \((\mathbf{\bar{w}},s) \leftarrow (\mathbf{\bar{w}}'- \hat{\textbf{w}},-\hat{s})\)

Thus, their the tokens are still confidential and that clients can transfer or redeem these using \(\varPi _{\mathsf {\textsf {\underline{C}Ledger}}}\) described in the full version [6].

Abort. If the protocol aborts prior to the completion of the \({\textbf {Execute}}\) phase, client funds are simply returned by \(\mathcal {X}_{\textsf {Lock}}\) and collateral deposited to \(\mathcal {X}_{\textsf {Collateral}}\) is returned. If servers have agreed upon the completion of \({\textbf {Execute}}\), honest servers can interact with \(\mathcal {F}_{\textsf{Ident}}\) to either (a) obtain shares that are verifiable and enable reconstruction of the output or (b) identify cheating servers (functionality described in the full version [6]). Thus, \(\mathcal {X}_{\textsf {Lock}}\) as a registered public verifier, can identify cheating servers by either verifying shares with \(\mathcal {F}_{\textsf{Ident}}\), or obtaining the identities of servers \(\mathcal {J}\) that refuse to participate in revealing their shares and allowing their verification. Cheating servers lose their collateral held by \(\mathcal {X}_{\textsf {Collateral}}\) which is redistributed to clients.

We present the full protocol \(\varPi _{\mathsf {\underline{C}Contract}}\) which GUC-realizes \(\mathcal {F}_{\mathsf {\underline{C}Contract}}\) in the full version [6] and prove the following statement.

Theorem 2

\(\varPi _{\mathsf {\underline{C}Contract}}[\varPi _{\mathsf {\underline{C}Ledger}}]\) realizes \(\mathcal {F}_{\mathsf {\underline{C}Contract}}[\mathcal {F}_{\mathsf {\underline{C}Ledger}}]\) in the \(\mathcal {F}_{\textsf{Clock}}\), \(\mathcal {F}_{\textsf{Ident}}\), \(\mathcal {F}_{\textsf{Ledger}}\), \(\mathcal {F}_{\textsf{NIZK}}\), \(\mathcal {F}_{\textsf{Setup}}\), \(\mathcal {F}_{\textsf{Sig}}\), \(\mathcal {F}_{\textsf{TSig}}\)-hybrid model against any PPT-adversary corrupting at most \(n-1\) of the n servers \(\mathcal {P}\) statically and any minority of \(\mathcal {Q}\).

4 Efficiency

We note that since previous works focus on using zero knowledge proofs and a trusted contract manager, we refrain from directly comparing our efficiency to their works. The closest previous works to ours is the Hawk family [4, 5, 37]. Unfortunately neither of the works provide an efficiency analysis, making it hard to provide a meaningful comparison. However, we note they all require computation of cryptographic primitives (commitments and ZKPs) in MPC. Thus requiring strictly more MPC computation, along with a larger (and hence) slower field of computation, as this field is needed to facilitate computational security of the cryptographic primitives they compute in MPC. In the following analysis, we assume Bulletproofs for range proofs and standard Fiat-Shamir Schnorr proofs of knowledge of exponents using elliptic curves. Although neither of these are UC-secure since knowledge extraction requires rewinding, there is evidence [29] that these techniques can be made non-malleable in the algebraic group model. Hence, for the purpose of efficiency we believe it is reasonable to forgo the formal UC security in this section. We use BLS threshold signatures and for simplicity we assume the size of the group used for BLS and commitments is the same, although it will in practice be slightly larger for BLS.

Table 2. Complexity of our protocol when executing one \(\textsf {\underline{C}Contract}\), excluding the computation of contract circuit g in MPC. We assume \(|\mathcal {C} |z >s\) for statistical security parameter \(s\), where \(z \) is the amount of input/output for each client in the set of clients \(\mathcal {C} \), including the hidden token amount. \(n=|\mathcal {P} |\) is the amount of servers and \(\textbf{mult}\) denotes the number of multiplications in MPC.
Full size table

We outline the amount of heavy computations needed for our core protocol in Table 2, except what is needed by the underlying MPC computation computing the contract circuit g, reflecting the privacy preserving smart contract \(\textsf {\underline{C}Contract}\). Concretely we count the amount of group exponentiations when assuming that the Pedersen commitments are realized using elliptic curves, along with pairings assuming BLS [13] has been used for realizing distributed signatures. The table only contains the complexity of executing one instance of \(\textsf {\underline{C}Contract}\), but we note that execution of multiple contracts is slightly sublinear in the complexity of a single execution. The Abort column illustrates the additional overhead associated with a cheating party.

Table 3. Complexity of \(\textsf {\underline{C}Ledger}\) in group exponentiation and amount of group elements stored, when \(\bar{v}_{\textsf {max}}\) is the maximum amount of allowed tokens (Recall \(|\mathcal {C}|\cdot \bar{v}_{\textsf {max}}<|{{\mathbb G}}|\)).
Full size table

When it comes to our confidential token layer, we outline the complexity in Table 3. We note that the constant in the complexity of Confidential Transfer reflects two range proofs over \(\log (|{{\mathbb G}}|/2)\), under the assumption that BulletProofs are used [16]. Although if the domain of the token amounts is further limited from \({{\mathbb G}}\) to \(\bar{v}_{\textsf {max}}<|{{\mathbb G}}|/|\mathcal {C}|\) then they can be reduced to range proofs of \([0; \bar{v}_{\textsf {max}}-1]\) and thus complexity \(O(\bar{v}_{\textsf {max}}\cdot \log (\bar{v}_{\textsf {max}}))\).

In both tables the amount of smart contract space is only what needs to be submitted. The persistent space use needed is only \(3+3|\mathcal {C} |\) group elements, if we assume that the storage used when posting to \(\mathcal {X}_{\textsf {Lock}}\) in evaluate and open gets overwritten the next time the servers call these methods.

The round complexity for all steps of both the confidential token layer protocols and our core protocol is constant, assuming g has constant multiplicative depth. Otherwise, the computation of g dominates the round complexity.