#  Cloak: Enabling Confidential Smart Contract with Multi-party Transactions

Qian Ren§∗ Han Liu∗ Yue Li∗ Anne Victor∗
Hong Lei†∗ Lei Wang‡ Bangdao Chen§∗

§SSC Holding Company Ltd.
∗Oxford-Hainan Blockchain Research Institute
†School of Computer Science and Cyberspace Security, Hainan University
‡Department of Computer Science and Engineering, Shanghai Jiao Tong University

###### Abstract

In recent years, as blockchain adoption has been expanding across a wide range
of domains, _e.g._ , supply chain and digital asset, smart contracts’
confidentiality has now become a fundamental demand for practical
applications. However, while new privacy protection techniques are emerging,
how existing ones can best fit development settings is understudied. State-of-
art solutions lack architectural support of programming interfaces thus can
hardly reach general developers.

This paper proposes Cloak, a pluggable and configurable framework for
developing and deploying confidential smart contracts. The key capability of
Cloak is to allow developers to develop and deploy practical solutions to
_Multi-party Transaction_ (MPT) problems, _i.e._ , to verifiably transact with
secret parameters and states owned by different parties by simply _specifying_
it. To this end, Cloak allows users to specify privacy invariants in a
declarative way, automatically generate runtime with enforced privacy, and
deploy it to enable the MPT on existing platforms. Additionally, we identify
the pitfalls and treats for achieving MPT, _e.g._ , achieving public
verifiability and resisting byzantine adversaries with minimal blockchain
interaction. In our evaluation of both examples and real-world applications,
developers manage to deploy business services on blockchain concisely by only
developing Cloak smart contracts, whose size is less than 13.5% of the
deployed ones. Moreover, while previous works require at least $O(n)$
transactions to secure an MPT, Cloak requires only 2 transactions and reduces
gas cost by 29% on average.

We believe that the insights learned from Cloak pave the way for public
verifiable thus reusable general-purpose multi-party computation achieved by
harmonizing TEE and blockchain.

##  1 Introduction

With the rapid development of both permissionless and permissioned
blockchains, privacy issues have now become one of the top concerns for smart
contracts, _i.e._ , keeping transaction inputs and contract states as secrets
to non-relevant participants. In many of the practical applications, privacy
is an essential property to achieve, _e.g._ , avoiding malicious arbitrage on
cryptocurrency, protecting sensitive information in a cooperative business.
Unfortunately, despite the importance of smart contract privacy, most of the
existing blockchains are designed _without privacy_ by nature [29, 44]. For
example, miners of Ethereum verify transactions in a block by re-executing
them with the exact input and states. Consequently, private data is shared
within the entire network.

Figure 1: A simplified multi-party scenario

_Confidential smart contract_. To address the aforementioned problem,
researchers have proposed various _confidential smart contract_ solutions. In
general, these approaches fall into two categories that based on cryptography
techniques and trusted hardware respectively. For the former class of
approaches, techniques including ring signature, homomorphic encryption, and
zero-knowledge proof (ZKP) are adopted to achieve anonymity and privacy [11,
25, 8, 5]. For the latter, Trusted Execution Environment (TEE), _e.g._ , Intel
SGX, is used to provide confidentiality and trustworthiness [12, 27]. More
specifically, TEE is able to reveal sealed transactions and execute them in
enclaves, hiding input and contract states with a verifiable endorsement from
the hardware manufacture.

_Limitations_. However, while both classes of solutions provide architectural
capabilities to enforce confidential lifecycles of transactions, they are
insufficient for the _development_ of practical applications. Fig. 1 describes
a scenario of procurement bidding among multiple enterprises in supply chain
applications. Specifically, each participant submits its secret bid. The core
enterprise selects a winner with the lowest bid and pays the second-lowest bid
by updating the winner’s balance. Cryptography-based solutions suffer from low
performance and error-prone implementation since that developers are required
to implement a set of off-chain multi-party computation (MPC) programs [21]
and on-chain verification smart contracts [25, 11]. Most of TEE-based
solutions [12, 35, 27] support general confidential smart contracts with
secrets owned by only one side in a single transaction. These solutions
process one source of confidential bid input at a time, cache intermediate
bids, and generate final states when the bidding is completed thus lead to
non-intuitively program model. Although recent works [14, 25] aim to enable
secure off-chain MPC programs, they suffer on low scalability by requiring
$O(n)$ blockchain interactions. In summary, literature solutions of
confidential smart contracts can hardly fit in the practical multi-party
transactions, _i.e._ , transactions with secret inputs and states owned by
different parties.

_Challenges_. Handling multi-party transactions on blockchain faces the
following challenges:

C1: Development cost for confidentiality. Developing a confidential smart
contract is time-consuming and error-prone due to the lack of programming
support. Given a privacy specification, the development commonly requires
embedding low-level controls into implementations for business logic.
Consequently, it becomes less flexible for developers to understand, develop
and maintain such contracts and more.

C2: Interoperability with existing blockchains. Evaluating multi-party
transactions involves reading and writing both off-chain and on-chain data,
_e.g._ , off-chain parameters and on-chain states. However, existing solutions
are primarily for off-chain one-time MPC programs, _i.e._ , receive inputs and
deliver outputs off-chain, thus can hardly fit into general application
domains, _e.g._ have combined off-chain and on-chain inputs/outputs.

C3: Security design of multi-party transaction. Securing multi-party
transactions requires efficiently resisting byzantine adversaries, _i.e._ ,
not only to resist adversaries to abort protocols, peek at secrets, cheat on
results _etc._ , but also guarantee the security with minimal blockchain
interaction.

_Contributions_. In this paper, we formalize the _Multi-party Transaction_
(MPT) problem on blockchain for the first time and harmonize TEE and
blockchain to build a general-purpose MPT-enabled confidential smart contract
framework, Cloak. Cloak allows developers to annotate MPT privacy invariants
in contract source code, then do the rest to enable MPT on existing
blockchains. Our main contributions are as follows:

  * •

We first identify and formalize the multi-party transaction problem that
transacts with secret parameters and states owned by different parties in a
public verifiable manner.

  * •

We highlight a domain-specific language (against C1), which allows developers
to efficiently annotate MPT privacy invariants directly in developing smart
contracts and generate deployable code compliant to the specified privacy
invariants.

  * •

We propose a novel MPT-enabled confidential smart contract framework; It is
interoperable with existing blockchains (against C2), and achieves
confidentiality, public verifiability, and financial fairness under byzantine
adversaries in the cost of 2 transactions (against C3).

  * •

We have applied Cloak in several industrial applications, including supply
chain, e-governance, and more. Cloak has managed to greatly simplify the
implementation of a confidential smart contract and reduce the gas cost of
MPT.

_Organization_. This paper is organized as follows. Section 2 formally defines
the multi-party transaction problem. Section 3 illustrates advances of Cloak
to related works. Section 4 shows the key design and overview of Cloak.
Section 5 answers how Cloak helps developers specify MPT in an intuitive
manner (against C1) and enable MPT on existing blockchains (against C2).
Section 6 shows how our protocol proceeds and resists byzantine adversaries
(against C3). Finally, we claim system security in Section 7, evaluate Cloak
in Section 8 and conclude in section 9.

##  2 Multi-party Transaction

In this section, we first illustrate the public verifiability required by both
public transactions (_e.g._ , normal transactions of Ethereum) and private
transactions of confidential smart contracts [12, 27], then identify a new
privacy problem called Multi-party Transaction and elaborate its novelty and
impact.

Currently, prominent blockchains (_e.g._ , Ethereum [44]) are typically
modeled as State Machines. In these blockchains, every single step of state
transition is supposed to be verified by all nodes. Thus, we say the state
transition is publicly verifiable and the transaction causing the transition
has public verifiability. Let’s go deep into public verifiability in Figure 2.

Figure 2: Public verifiable state transition. PUT refers to a public
transaction. PRT refers to a private transaction that takes secrets from a
single party. MPT refers to a multi-party transaction that takes secrets from
multiple parties. Dashed thick line arrows refer to reading blockchain while
solid thick line arrows refer to writing blockchain. $\sigma$ refers to the
world state. $C_{*}$ refers to a commitment to a secret $*$.

Public verifiability of public transactions. When a normal transaction is
packaged in a block, its transaction parameters, old states, function logic,
return values, and new states are all public, therefore we call it PUT (public
transaction). We say a PUT has public verifiability since all nodes can re-
execute it to verify the state transition. Formally, in Figure 2, $f$ refers
to the function logic of a transaction, _e.g._ , a transaction for rather
transferring ETH or calling a function of a contract on Ethereum; $x$ refers
to transaction parameters; $r$ refers to return values, $s,s^{\prime}$ refers
to old state and new state separately. We formalize a PUT as the following
formula. The $proof$ there is for proving that a $f$ taking parameters $x$,
transfers the old state $s$ to $s^{\prime}$ and gets return values $r$.
Obviously, the $proof$ of PUT can be the set of published $x,s,f,s^{\prime},r$
and everyone can verify the PUT by re-executing it thus also trusting the
state transition caused by a sequence of PUT.

$\displaystyle\mathrm{PUT}:\quad s\stackrel{{\scriptstyle
f(x)}}{{\Longrightarrow}}s^{\prime},r,proof$

Public verifiability of private transactions. Similarly, as for a private
transaction (PRT) of confidential smart contract that takes secrets from a
single party, although its $x,s,s^{\prime},r$ and even $f$ can be private, it
is also required to prove the validity of it caused state transition from old
state commitment to new state commitment, _i.e._ , a PRT also requires public
verifiability. As is shown in Figure 2, Let $C_{*}$ refer to a cryptographic
commitment of $*$, _e.g._ the hash or ciphertext of $*$. A PRT executes
$f(x,s)$ off-chain, gets private return values $r$ and new states $s^{\prime}$
and generates a $proof$. The $proof$ proves that there are indeed private
$f,x,s,s^{\prime},r$ matching their public commitments
$C_{f},C_{x},C_{s},C_{s^{\prime}},C_{r}$ fits this relation: executing
$f(x,s)$ gets return value $r$ and causes the state transition from $s$ to
$s^{\prime}$. PRT has been researched for several years and there are both
ZKP-based [25, 11, 19] and TEE-based [12, 35] solutions. However, these
solutions hardly consider or practically achieve a PRT taking secrets from
different parties.

$\displaystyle\mathrm{PRT}:\quad C_{s}\stackrel{{\scriptstyle
C_{f},\leavevmode\nobreak\
C_{x}}}{{\Longrightarrow}}C_{s^{\prime}},C_{r},proof\mid
s\stackrel{{\scriptstyle f(x)}}{{\Longrightarrow}}s^{\prime},r$

Multi-party transaction. In this paper, we expand the public verifiability of
PRT to multi-party scenarios and call it Multi-party Transaction (MPT). We
model the MPT as the formula below. The $proof$ achieves an MPT’s public
verifiability by proving both variables’ relation and privacy policy.
Variables’ relation means that anchored by public
$C_{x_{i}},C_{s_{i}},C_{f},C_{s^{\prime}_{i}},C_{r_{i}}$, a MPT confidentially
executes $f(x_{1},\dots,x_{n},s_{1},\dots,s_{i})$ and outputs private
$r_{i},s^{\prime}_{i}$ to their corresponding $P_{i}$. The privacy policy of
an MPT means that secrets are exactly fed by and delivered to different
parties $P_{i}$ and their confidentiality is kept in the whole process.

$\displaystyle\mathrm{MPT}:$ $\displaystyle
C_{s_{1}},\dots,C_{s_{n}}\overset{C_{f},\leavevmode\nobreak\
C_{x_{1}},\dots,C_{x_{n}}}{\Longrightarrow}$ $\displaystyle\qquad
C_{s^{\prime}_{1}},\dots,C_{s^{\prime}_{n}},C_{r_{1}},\dots,C_{r_{n}},proof$
$\displaystyle\quad\mid s_{1},\dots,s_{n}\stackrel{{\scriptstyle
f(x_{1},\dots,x_{n})}}{{\Longrightarrow}}s^{\prime}_{1},\dots,s^{\prime}_{n},r_{1},\dots,r_{n}$

MPC with strong adversary model vs. MPT. MPC refers to Multi-Party
Computation. Typically, MPC constructs cryptographic protocols to allow
different parties to jointly compute a target function without revealing their
input secrets to each other [45]. An MPC protocol can be formalized as
following formula, where $f$ refers to the target function, $x_{i},y_{i}$
refer to private input and output of a party $P_{i}$.

$f(x_{1},x_{2},...,x_{n})\Rightarrow y_{1},y_{2},...,y_{n}$

MPC protocols under the strong adversary model, marked as MMPC, consider
malicious parties who can arbitrarily abort or misbehave during the protocols.
MMPC requires parties to mutually prove their honest behavior in each protocol
step so that honest parties can identify misbehaviors in time and even punish
misbehaved parties. However, while both MPT and MMPC solutions pursue keeping
the confidentiality of parties’ secrets and identifying misbehaviors, MPT
distinguished from MMPC in public verifiability and blockchain nativeness.

In terms of public verifiability, while MMPC focuses on building the mutual
trust of honest behavior among involved parties, MPT focuses on making the
public trust both multi-party process and results. In fact, there are indeed
many practical scenarios where a non-involved party of MPC needs to verify
both MPC process and results without trusting any party, _e.g._ , a regulation
authority verifies business compliance without trusting any involved firms, or
a miner verifies the state transition caused by an MPC process without
trusting any involved parties.

In terms of blockchain nativeness, while MMPC [14, 40] just distinguishes a
party’s inputs and outputs from others, MPT furthermore distinguishes
transaction parameters and return values from states. As a result, while
parties involved in an MMPC feed their private inputs to the protocol without
any restriction, parties of an MPT can also feed transaction parameters
without restriction but must feed old states matching the states’ commitments
on-chain. Moreover, current solutions [14, 38] committing a part of MMPC
inputs or outputs on blockchain never consider sharing their committed data
with PRT [25, 14, 40]. Conversely, MPT is not considered as a standalone
transaction type of confidential smart contract but coexists with PRT and PUB
in contracts. In our work, the data structure of secrets’ commitments is well-
designed so that can be operated by an MPT as well as a PRT111The definition
of PUT indicates its impossibility in involving secrets. Most importantly,
while some solutions partially commit MMPC only for recording the evaluation,
all elements of MPT that uniquely identify the evaluation are forced to be
committed on-chain. Because our commitment strategy make it trustworthy to
publicly verify the state transition, construct transaction chain to reuse the
MPT outputs, and re-executing the MPT for an after-event audit, we believe our
work paves the way for public verifiable and reusable multi-party computation.

Table 1: Comparison of Cloak with related works. The ⚫, ◗, ❍, ✕ refers to
full, partial, not match and not-related respectively. "Chain Agnostic" means
the approach is integrated into the consensus of a specific chain. "Privacy
Specification" means the approach proposes a method to specify privacy needs.
"Negotiation" means the approach starts with apriori-unknown parties.
"min(#TX)" means how many transactions are required by the approach in absence
of an adversary.

Approach | min(#TX) | Confidentiality | Adversary Model |  | Public Verifiability |  |  Chain Agnostic |  Privacy Specification |  Negotiation |  Financial Fairness
---|---|---|---|---|---|---|---|---|---|---
#Parties | #TEE Executors |  | $x$ | $s$ | $f$ | $r$ | $s^{\prime}$ | Policy |
Ethereum [44] | $O(1)$ | ✕ | $1^{*}$ | ✕ |  | ⚫ | ⚫ | ⚫ | ⚫ | ⚫ | ⚫ |  | ✕ | ✕ | ✕ | ✕
Ekiden [12] | $O(1)$ | ⚫ | $1^{*}$ |  $m-1$1 |  |  ❍2 | ⚫ | ⚫ |  ❍2 | ⚫ | ⚫ |  | ⚫ | ❍ | ✕ | ✕
Confide [27] | $O(1)$ | ⚫ | $1^{*}$ |  $\lfloor m/3\rfloor$3 |  | ⚫ | ⚫ | ⚫ | ⚫ | ⚫ | ⚫ |  | ❍ | ⚫ | ✕ | ✕
Hawk [25] | $O(n)$ |  ◗4 | $n$ | ✕ |  | ⚫ | ❍ | ⚫ | ⚫ | ❍ | ❍ |  | ⚫ | ⚫ | ❍ | ⚫
Fastkitten [14] | $O(n)$ | ⚫ | $n$ | $1^{*}$ |  | ❍ |  ❍5 | ❍ | ⚫ |  ❍5 | ❍ |  | ⚫ | ❍ | ❍ | ⚫
LucidiTEE [38] | $O(n)$ | ⚫ | $n$ | $m-1$ |  | ⚫ | ❍ | ⚫ | ⚫ |  ◗6 |  ◗6 |  | ⚫ | ❍ | ⚫ | ✕
Cloak | $O(1)$ | ⚫ | $n$ | $1^{*}$ |  | ⚫ | ⚫ | ⚫ | ⚫ | ⚫ | ⚫ |  | ⚫ | ⚫ | ⚫ | ⚫

  * 1 The tolerated number of corrupted compute nodes. 2 Transaction parameters $x$ (resp. return values $r$) are received (resp. delivered) off-chain while not committed on-chain. 3 We assume the Confide’s undeclared consensus is BFT. 4 The manager is expected not to leak parties’ private data. 5 Fastkitten does not commit the states of MPC programs. 6 LucidiTEE does not consider states owned by different parties.

##  3 Related Work

Since our contributions involve a new language for specifying multi-party
privacy and a novel framework harmonizing TEE and blockchain to enforce MPT,
in this section, we elaborate how Cloak distinguishes from current privacy
specification languages against smart contracts and confidential smart
contract solutions utilizing MPC or TEE.

Privacy policy languages. In terms of expressive ability, we first consider
privacy policy languages designed for contracts. CCLe [27] and SecondState
[39] only distinguishes values between public and private. Zkay [11] allows
annotating owners of private data in simplified Solidity. However, Zkay is
designed for NIZK-based solutions and does not consider multi-party scenarios.
Then, we consider languages that support multi-party computation. Hawk [25]
only support hard-coded parties’ addresses and is designed for NIZK-based
payment system. MPCL [30], Wysteria [33], SecreC [3] and ObliVM [26] also only
distinguish values between public and private. Differently, Cloak allows
developers to fine-grained annotate private values available to specific
addresses ignoring how many parties are involved and leave Cloak to recognize
the transaction types, _i.e._ , PUT, PRT, or MPT. While Fairplay [28], SecreC,
and ObliVM do not support general loops with private conditions due to the
limitation of fix-round cryptographic algorithms, Cloak runs the transaction
logic with plaintext secrets inside enclaves thus is free of this limitation.

TEE-enforced confidential smart contract. As is shown in Table 1, Ekiden [12,
39] reveals and executes private transactions in TEE to confide transactions’
parameters and return values, and contracts’ states. CCF [35] supports users
to run any typescript or C++-based application in a TEE-based permissioned
blockchain. CONFIDE [27] designs a key protocol to synchronize and hold a
common public key between all SGX. It also holds EVM and WASM in SGX to
support kinds of contracts. Because all above three solutions serve to handle
a private transaction from its single sender, they inherently indicate PRT
policy. However, Ekiden receives inputs and delivers outputs off-chain without
committing them on-chain thus does not uniquely bind the PRT, therefore,
losing its public verifiability. While both CCF and CONFIDE integrate TEE into
the pipeline of their consensus thus being specific to their blockchains,
Cloak is chain-agnostic and can enable confidential smart contracts on
existing blockchain.

Transactions based on multi-party computation. Transactions based on multi-
party computation mean several parties jointly execute a target function and
commit part of the information on blockchain without revealing their secrets
to each other in the process. As is shown in Table 1, in terms of
confidentiality, Hawk [25] requires an credible manager to be tight-lipped
thus just achieving partial confidentiality. In terms of public variability,
the manager of Hawk updating contract state with ZKP proof makes the multi-
party policy transparent to public verifiers, _e.g._ , miners. FastKitten [14]
just records m-round MPC’ output on blockchain though additionally achieves
the financial fairness when malicious parties or the unique operator
misbehave. To the best of our knowledge, Cloak is the first scheme that
achieves public verifiability of MPT-caused state transitions by committing
all inputs (_i.e._ , transaction parameters and old state), code, outputs
(_i.e._ , return values and new state), and multi-party privacy policy on-
chain. LucidiTEE does not distinguish parties identities in committed states
and policy. In terms of security, while LucidiTEE [38] lacks a collateral
system to punish malicious parties, both Hawk and FastKitten [14] adopts
challenge-response protocols to punish malicious parties and the single
operator/manager thus achieves financial fairness. Cloak furthermore improves
the challenge-response protocol of FastKitten [14] thus also achieve financial
fairness. Moreover, in terms of scalability, MPC-based works [42, 43, 34]
allows m-round MPC with penalties over Bitcoin, but relies on the claim-or-
refund functionality which requires complex and expensive transactions and
collateral thus making these solutions impractical. Schemes adopting TEE to
enhance MPC also requires high money-cost [43, 42] and time-consume
transactions [14] for collateral, thus suffers on high-cost. In contrast,
Cloak requires only a constant number of collateral transactions for defending
adversaries.

To the best of our knowledge, Cloak is the first to allow developers to
specify PUT, PRT, and MPT in a single contract simultaneously. It is also the
first to achieve public verifiable state transition caused by MPT and resist
byzantine adversaries with normally only 2 transactions.

##  4 Cloak Design

This section presents the overview of Cloak, a novel MPT-enabled confidential
smart contract framework. We first model the architecture of Cloak, then
introduce the workflow of Cloak, which helps users develop, deploy and send
MPT.

###  4.1 Design challenges of Cloak

Leveraging TEE and blockchain to build a general-purpose MPT-enabled
confidential smart contract framework faces the following challenges.

####  4.1.1 Support intuitive MPT specification

Expressing multi-party privacy needs is not enough intuitive now. The
programming model of TEE requires developers to carefully split normal
application code into trusted part and untrusted part, of which the trusted
part should be executed in trusted enclaves and the untrusted part be executed
in an untrusted environment. There is no intuitive connection between TEEs’
programming model and MPT requirements. Moreover, while ZKP-solution-oriented
languages [11] do not support multi-party scenarios. Current programming
frameworks considering multi-party privacy mainly focus on the off-chain
multi-party computation thus less considering the features of smart contracts,
_e.g._ parties’ identities are represented by addresses [22, 4] or the inputs
of MPT split to off-chain parameters and on-chain states. Besides, never of
the current languages support PUB, PRT, and MPT in one contract so developers
have to differently specify the privacy needs of various transaction types by
different tools or forms.

All these limitations motivate us to propose Cloak language. The core idea of
Cloak language is allowing developers to intuitively annotate the ownership
(_i.e._ , owners’ addresses) of private data without considering the type of
transactions. Then, Cloak analyzes how many parties’ secrets are involved to
infer the type of each transaction.

####  4.1.2 Achieving public verifiability of MPT

The challenge of achieving public verifiability of MPT is that how to
construct a well-structured $proof$ of which the structure and size are
agnostic of $x,s,f,r,s^{\prime}$ and privacy policy.

To design a general structure of $proof$, we first identify a general
framework for implementing confidential smart contract based on TEE. The
framework marks as a tuple
$(\mathcal{F},\mathcal{P},\mathcal{E},\mathcal{V})$. $\mathcal{F}$ refers to
the target function $f$ of MPT. $\mathcal{P}$ refers to the privacy policy of
MPT. $\mathcal{E}$ refers to TEE, which receives inputs $x,s$, runs $f$,
delivers outputs $r,s^{\prime}$, generates $proof$, and enforces the
$\mathcal{P}$ in the whole process. $\mathcal{V}$ is a on-chain verifier that
holds contract states and accepts new states by verifying the state transition
proved by $proof$. Specifically, when $\mathcal{E}$ successfully executes an
MPT, it sends a signed transaction $TX_{com}$. The $proof=\langle
H_{\mathcal{P}},H_{\mathcal{F}},\hat{H}_{C_{s}},\hat{H}_{C_{x}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r^{\prime}}}\rangle$222The
$H_{\mathcal{P}}$ (resp. $H_{\mathcal{F}}$) refers to
$\textnormal{{hash}}(\mathcal{P})$ (resp. $\textnormal{{hash}}(\mathcal{F})$).
$\hat{H}_{C_{s}}$ refers to $\textnormal{{hash}}([C_{s_{i}}|_{1..n}])$, as
well as $\hat{H}_{C_{x}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}$ in
$TX_{com}$ shows the endorsement of $\mathcal{E}$ against state transition
from $s$ to $s^{\prime}$ caused by the MPT. Therefore, if the $\mathcal{V}$
verifies that the $H_{\mathcal{P}},H_{\mathcal{F}},\hat{H}_{C_{s}}$ in
$TX_{com}$ match their required values, $\mathcal{V}$ accepts the state
transition.

Figure 3: The overall workflow of Cloak framework

####  4.1.3 Allowing nondeterministic MPT negotiation

Current works [25, 40, 14] assume that the setting of an MPC, _e.g._ ,
involved parities and target functions, has already been known and fixed, thus
all their protocols start from specified static settings. However, in a
decentralized and open network, there are definitely scenarios where a party
joins an MPT without the idea about other parties’ identities, _e.g._ , a
public auction where bidders independently decide to join the auction. This is
what we called nondeterministic participation, _i.e._ , a party joins an MPT
without knowing the identities or a total number of parties until the MPT
proposal is settled. Although [38] allows parties to autonomously bind data to
a specific MPC task, it costs $O(n)$ transactions. One may think we can
require all parties to interact with a TEE off-chain to negotiate with other
parties to avoid the interaction with a blockchain. However, if the
negotiation is not settled by the blockchain, the blockchain will neither
knows when the MPT starts nor be able to deduct the collateral of the TEE
Executor before evaluating the MPT. Consequently, the TEE Executor colluded
with some parties can arbitrarily drop or delay MPT outputs without being
discovered and punished by the blockchain.

In this paper, we propose an nondeterministic negotiation protocol to support
the mentioned nondeterministic participation of MPT parties. The basic idea is
to let a party send an MPT proposal to start a negotiation process. Then,
parties agreeing on the MPT proposal can send their acknowledgments and their
inputs’ commitments to join the MPT. When the negotiation is finished, TEE
attaches parties’ identities and inputs’ commitments in the proposal to get a
settled proposal and publishes the settled MPT proposal on the blockchain. In
this way, both parties and TEE proceed next depending on the unique MPT
proposal confirmed on the blockchain.

####  4.1.4 Resisting adversary with minimal transactions

A Cloak Executor running a TEE controls the TEE’s interaction with the
environment. Thus, a malicious Executor can abort the execution of the TEE or
present Eclipse Attacks [12] by dropping, delaying, and even mutating input
and output messages of TEE. Besides that, malicious parties can also abort in
any protocol stage to present a DoS attack. Current works [25, 42, 14]
resisting the above attacks require both parties and the Executor to deposit
collaterals at the beginning of the protocol. Even though all parties and the
Executor behave honestly, these works lead to minimal $O(n)$ transactions for
each MPC, which is high-cost and impractical.

In this paper, we design a one-deposit-multiple-transact mechanism which only
requires constantly 2 transactions when all parties and the Executor behave
honestly. Specifically, the Executor and parties globally deposit coins to an
address controlled by TEE once. When they join an MPT, the collaterals
required for the MPT will be deducted from their coins before executing MPT
and refunded to them after the MPT successfully completed. In this way, a
party can safely and concurrently join multiple MPT alongside at any time the
sum of deducted collaterals of these MPTs do not exceed the party’s deposited
coins. As for scenarios that malicious Executor or parties present, we adopt
an improved challenge-response mechanism which additionally requires $O(m)$
transactions, where $m$ is the number of malicious parties. We stress that the
challenge-response mechanism typically will not be executed often due to the
high financial cost for an adversary. Finally, we achieve $O(1)$ transactions
per MPT in normal cases.

###  4.2 Architecture and workflow

The target blockchain architecture interoperable with Cloak is modeled as
$A_{BC}$. Here $BC$ is a general-purpose smart contract enabled blockchain on
which the data are available to all $C$, _e.g._ , Ethereum [44]. $C$ is a
user/client sending transactions, _e.g._ , a digital wallet. There can be
multiple $C$ nodes (indicated by $!$) but a single blockchain $BC$.

$A_{BC}:=BC|!C$

We design a Cloak framework to enable confidential smart contract supporting
both PRT and MPT on the $A_{BC}$. A blockchain with architecture $A_{BC}$
equips Cloak in a pluggable manner to become a new architecture $A_{Cloak-
BC}$, where $BC$ and $C$ in $A_{BC}$ are enhanced to be Cloak Blockchain (BC)
and Cloak Client (C) respectively.

$A_{Cloak-BC}:=\textbf{{BC}}|\textbf{{E}}|!\textbf{{C}}|$

Cloak Blockchain (BC). This is a $BC$ with deployed Cloak service smart
contract, _i.e._ , the CloakService (CS) in Algorithm 1.

Cloak Executor (E). A Cloak Executor (E) is a server holding a TEE. The TEE
marks as $\mathcal{E}$, which runs the Cloak enclave program in Algorithm 2.

Cloak Client (C). A Cloak Client is a $C$ with Cloak SDK. C is able to
interact with specified BC and E to send PRT or MPT. We mark a Cloak Client as
C.

We leave the details of how to initialize an $A_{BC}$ to become $A_{Cloak-BC}$
in Appendix 9.1. Here we assume that the one-time global initialization has
been done and we get a BC (which has deployed CS) and E (which publishes the
public key $pk_{\mathcal{E}}$ and address $adr_{\mathcal{E}}$ of
$\mathcal{E}$). Figure 3 shows the workflow of Cloak framework. It is mainly
divided into three phases: development, deployment, and transaction. We will
briefly travel through these three phases and then introduce them in detail in
Section 5 and 6. Moreover, as PRT can be regarded as 1-party MPT, we exemplify
how Cloak achieves MPT in the follow-up part of this paper, without losing
generality.

In the development phase, a developer uses Cloak Language, a domain-specific
annotation language we will present in Section 5, to intuitively annotate
privacy invariants in a Solidity smart contract. The annotated contract calls
a Cloak smart contract. Taking the Cloak smart contract, Cloak Compiler
identifies transaction types, then generates the corresponding privacy
enforcement code: a verifier contract $\mathcal{V}$, a private contract
$\mathcal{F}$, and a privacy policy $\mathcal{P}$.

In the deployment phase, the developer deploys the generated
$\mathcal{V},\mathcal{F},\mathcal{P}$ to $A_{Cloak-BC}$. Specifically, the
developer first deploys $\mathcal{V}$ to BC. The $\mathcal{V}$ is constructed
by hashes of $\mathcal{F},\mathcal{P}$ specifying that only state transitions
caused by $\mathcal{F},\mathcal{P}$ can be accepted. Then, the developer
deploys $\mathcal{F},\mathcal{P}$ to the $\mathcal{E}$ of Cloak Executor and
binds the address of deployed $\mathcal{V}$ to form the binding of
$(\mathcal{F},\mathcal{P},\mathcal{V},\mathcal{E})$. Afterward, $\mathcal{E}$
in high-level is responsible for enforcing $\mathcal{P}$, evaluating
$\mathcal{F}$, and sending transactions to $\mathcal{V}$ in achieving each
MPT.

In the transaction phase, all parties of an MPT follow Cloak protocol
$\pi_{\textsc{Cloak}}$ to interact with the BC and E to send MPT. The protocol
proceeds in four stages. In these stages, while the setup stage globally
proceeds once for E and each party, other stages proceed for each MPT. In the
following illustration, as E is just responsible for relaying input and output
messages of its $\mathcal{E}$, we simplify the indirect communications of
parties->E->$\mathcal{E}$ (resp. BC->E->$\mathcal{E}$) to direct
communications of parties->$\mathcal{E}$ (resp. BC->$\mathcal{E}$) unless
otherwise stated.

  * •

Global setup stage: When $\mathcal{E}$ is registered on BC.CS, all parties can
verify that $\mathcal{E}$ is initialized correctly by checking its attestation
report. $\pi_{\textsc{Cloak}}$ first requires E and all parties to globally
block their coins on BC. Specifically, E and parties deposit their coins to
$\mathcal{E}$’s address. The collaterals for joining each MPT will be deducted
from these coins.

  * •

(MPT) Negotiation stage: A party sends an MPT proposal to $\mathcal{E}$
without knowing other parties a priori. $\mathcal{E}$ starts a
nondeterministic negotiation protocol. First, $\mathcal{E}$ generates an id
for the proposal and broadcasts the signed proposal with the id to all
parties. If a party is interested in or required by the proposal, it responds
an acknowledgment to $\mathcal{E}$ where the acknowledgment includes signed
commitment of the party’s parameters. $\mathcal{E}$ keeps collecting parties’
acknowledgments until the negotiation stage timeouts or collected
acknowledgments meet the settlement condition of negotiation. Then,
$\mathcal{E}$ sends a $TX_{p}$ to BC. $TX_{p}$ publishes the settled MPT
proposal which records settled parties’ identities and parameters’
commitments. $TX_{p}$ also deducts collaterals of E and all parties for the
MPT proposal in case one of them aborts the MPT after the negotiation
succeeds.

  * •

(MPT) Execution stage: When $TX_{p}$ has been confirmed on BC, each party
sends their signed inputs (_i.e._ , parameters and old states) to
$\mathcal{E}$, which computes the MPT. Upon receiving these inputs,
$\mathcal{E}$ first verifies Proof-of-Publication (PoP) [14, 12] of $TX_{p}$
to ensure that $TX_{p}$ has been confirmed on BC, which indicates that
collaterals of parties have been deducted333In other words, both E and parties
have enough balance in their globally deposited coins and indeed deducted
collaterals required by the specific MPT. and parties cannot change their
parameters. Then, $\mathcal{E}$ checks that collected parties’ inputs meeting
their commitments in $TX_{p}$. In case $\mathcal{E}$ does not receive inputs
from some parties, $\mathcal{E}$ needs to determine whether these parties
failed to send inputs or if E behaved maliciously (_e.g._ , by dropping
messages). Therefore, $\mathcal{E}$ will punish E unless it can prove that it
reminded these parties but did not receive the inputs. This proof is generated
by performing a improved challenge-response protocol in [14] via the
blockchain: E publicly challenges these parties on BC. As soon as this
challenge transaction is confirmed, these parties need to respond publicly on
BC by posting a response transaction with the ciphertext of their inputs. If
these parties respond, $\mathcal{E}$ can extract plaintext of their inputs and
continue with the protocol execution. If these parties did not respond, E
forwards the respective blocks as a transcript to $\mathcal{E}$ to prove that
these parties misbehaved, so that $\mathcal{E}$ sends $TX_{pns}$ to refund
collaterals deducted by $TX_{p}$ to all honest parties and stop the protocol.
Otherwise, if all parties’ inputs have been successfully collected,
$\mathcal{E}$ executes the MPT to get outputs (_i.e._ , return values and new
states).

  * •

(MPT) Distribution stage: When the execution stage finished, $\mathcal{E}$
sends a $TX_{com}$ to commit the outputs on BC, so that all parties seeing
their outputs’ ciphertext in $TX_{com}$ can decrypt the ciphertext to get
their corresponding return values and new states. Since $TX_{com}$ indicates
the honesty of both E and all parties during the protocol, this transaction
also refunds their collaterals respectively. In case E neither stops the MPT
by $TX_{pns}$ nor completes the MPT by $TX_{com}$ and leads to timeout, any
party can send $TX_{out}$ to punish E and claim their collaterals back.

$\displaystyle L::=$ $\displaystyle\text{id}\mid L[e]\ $
$\displaystyle\mathbf{(Location)}$ $\displaystyle\alpha::=$
$\displaystyle\mathbf{me}\mid\mathbf{all}\mid\text{id}\mid\mathbf{tee}\ $
$\displaystyle\mathbf{(Privacy\leavevmode\nobreak\ type)}$
$\displaystyle\tau::=$
$\displaystyle\mathbf{bool}\mid\mathbf{uint256}\mid\mathbf{address}\mid\mathbf{bin}\mid\mathbf{mapping}(\tau_{1}\Rightarrow\tau_{2}@\alpha_{2})\mid\mathbf{mapping}(\mathbf{address}!\text{id}\Rightarrow\tau@\alpha)\mid\mathbf{address}[!\text{id}]\mid\mathbf{\tau}[@\alpha]$
$\displaystyle\mathbf{(Data\leavevmode\nobreak\ type)}$ $\displaystyle e::=$
$\displaystyle c\mid\mathbf{me}\mid
L\mid\mathbf{reveal}(e,\alpha)\mid\hbox{\pagecolor{pink!60}$\ominus e\mid
e_{1}\oplus e_{2}\mid e_{1}?e_{2}:e_{3}\mid\cdots$}$
$\displaystyle\mathbf{(Expression)}$ $\displaystyle P::=$
$\displaystyle\mathbf{skip}\mid\tau@\alpha\ \text{id}\mid L=e\mid
P_{1};P_{2}\mid\mathbf{require}(e)\mid if\ e\ \\{P_{1}\\}\ \mathbf{else}\
\\{P_{2}\\}\mid\mathbf{while}\ e\ \\{P\\}\ $
$\displaystyle\mathbf{(Statement)}$ $\displaystyle F::=$
$\displaystyle\mathbf{function}\ f\left(\tau_{1}@\alpha_{1}\
\text{id}_{1},\ldots,\tau_{n}@\alpha_{n}\ \text{id}_{n}\right)\
\mathbf{returns}\ \tau@\alpha\ \\{P;\mathbf{return}\ e;\\}\ $
$\displaystyle\mathbf{(Function)}$ $\displaystyle C::=$
$\displaystyle\mathbf{contract}\
\text{id}\\{(\mathbf{final})?\tau_{1}@\alpha_{1}\ \text{id}_{1};\
\ldots(\mathbf{final})?\tau_{n}@\alpha_{n}\ \text{id}_{n};\ F_{1}\ldots
F_{m}\\}\ $ $\displaystyle\mathbf{(Contract)}$
Figure 4: Syntax of Cloak. The $f$ and ’id’ are identifiers, $c$ is a
constant. Native functions are highlighted

###  4.3 Adversary model

$\pi_{\textsc{Cloak}}$ is executed by $n$ parties and a Cloak Executor E (who
owns the TEE $\mathcal{E}$) to enforce MPT, and depends on TEE to ensure its
confidentiality and integrity. In this paper, we consider a byzantine
adversary who can corrupt all parties and E but not $\mathcal{E}$. The
compromised parties or E can behave arbitrarily, _e.g._ , scheduling processes
as well as reordering, delaying, mutating messages, however, can not break the
confidentiality and integrity of TEE itself. Therefore, while a party need not
execute contracts themselves or hold TEE, we assume honest party trust all
attested TEE as well as their own platforms and Cloak Client C. Although we
instantiate the TEE in $\pi_{\textsc{Cloak}}$ based on SGX, our design is TEE-
agnostic. In the following, we exemplify SGX to illustrate why the
confidentiality and integrity assumption of TEE are practical.

We stress that although recent research showed some attacks against SGX, the
confidentiality and integrity guarantees of SGX are still trustworthy.
Specifically, we assume that E has full control over the machine and
consequently can execute arbitrary code with root privileges. First, a
malicious E can exploit memory-corruption vulnerabilities [2] in enclave code
through the API between the host process and the enclave. We assume a common
code-reuse defense such as control-flow integrity (CFI) [1, 9], or fine-
grained code randomization [15] to be in place and active. Then, we consider
architectural side-channel attacks, _e.g._ , based on caches [6]. These
attacks can expose access patterns from SGX enclaves (and therefore our Cloak
prototype). However, this prompted the community to develop several software
mitigations [20, 37, 36] and new hardware-based solutions [31, 13]. A more
serious Micro-architectural side-channel attacks like Foreshadow [7] can
extract plaintext data and effectively undermine the attestation process Cloak
relies on, leaking secrets and enabling the enclave to run a different
application than agreed on by the parties; however, the vulnerability enabling
Foreshadow was already patched by Intel [24]. Therefore, since existing
defenses already target SGX vulnerabilities and since Cloak ’s design is TEE
agnostic (_i.e._ , it can also be implemented using ARM TrustZone or next-
generation TEEs), we consider mitigating side-channel leakage as an orthogonal
problem and out of scope for this paper so that the confidentiality and
integrity of TEE devices is still trustworthy. Therefore, users can trust the
TEE integrity attested by Intel Attestation Service.

We assume the common prefix, chain quality, and chain growth of the blockchain
are held so that honest parties and the Executor can access and trusted the
confirmed transactions on the blockchain. While the confidentiality and
integrity guarantees of SGX are still trustworthy, we note that Cloak does
not, and cannot reasonably, prevent contracts from leaking secrets
intentionally or unintentionally through software bugs.

##  5 Cloak Language

In this section, we present a domain-specific language, which expands privacy
invariants annotation - allows developers to annotate privacy invariants
intuitively at the place where the data are defined - to the MPT scenario
(handling C1).

###  5.1 Language Syntax

Cloak language is a domain-specific annotation language for the confidential
smart contract; it allows developers to _declare an owner’s identity and
annotate the owner’s private data ignoring the number of owners a transaction
involved_. Cloak language is implemented based on Solidity [18] one of the
most influential smart contract languages [23]. Fig. 4 shows the syntax of
Cloak language; it consists of (memory) locations, data and privacy types,
expressions, statements, functions, and contracts. In order to focus on key
insights, Cloak is deliberately kept simple.

Locations ($L$) consist of contract field identifiers, function arguments and
local variables (‘id’, alphanumeric strings), and mapping entries ($L[e]$).

A type declaration ($\tau@\alpha$) in Cloak consists of a data type ($\tau$),
and a privacy type ($\alpha$) specifying the owner of a construct. Privacy
types consist of $\mathbf{me}$, a pseudo-address indicating public
accessibility ($\mathbf{all}$), a pseudo-address indicating TEE accessibility
($\mathbf{tee}$) and identifiers (covering state variables, array elements and
mapping key tags). For readability, we often omit all, writing $\tau$ instead
of $\tau@$$\mathbf{all}$. Besides the well-known data types (the bool and
uint256), Cloak supports addresses indicating accounts (address), and binary
data capturing signatures, public keys and ciphertexts (bin). In addition,
types include mappings, _i.e._ ,
mapping($\tau_{1}\Rightarrow\tau_{2}@\alpha_{2}$) (resp. arrays
$\tau[@\alpha]$) and named mappings, _i.e._ , mapping(address!id
$\Rightarrow\tau@\alpha$) (resp. named arrays address[!id]), defining name
‘id’ for the key of the map to be used in the value type $\tau@\alpha$ (resp.
for the element of the array to be used in $\tau[@\alpha]$). It is
straightforward to extend Cloak with additional types, such as float and
struct.

The only cloak-specific expressions are the runtime address of the caller
($\mathbf{me}$), common address of $\mathcal{\bar{E}}$ ($\mathbf{tee}$), and
re-classification of information ($\mathbf{reveal}$). The highlighted
expressions can be viewed as evaluations of so-called native functions
$g(e_{1},...,e_{n})$, including standard arithmetic and boolean operators
(captured by $\ominus,\oplus$). It is straightforward to extend Cloak with
additional native functions (as indicated by ‘$...$’).

Statements ($P$) in Cloak are mostly standard. To declare a local variable, we
write $\tau@\alpha\leavevmode\nobreak\ {\texttt{\small id}}$. If $e$ does not
evaluate to true, require($e$) throws an exception. While we only discuss
functions ($F$) which return a value, Cloak also allows constructors and
functions without return values. Contracts ($C$) consist of contract field
declarations and function declarations, where contract fields may be declared
final.

###  5.2 Specify Privacy Invariants

####  5.2.1 Invariants specification exemplified

With Cloak language, users can intuitively specify the MPT in Fig. 1 as a
Cloak smart contract, the .cloak file in Listing 1. In line 2, the developer
can declare the key of balances as a temporary variable $\mathbf{k}$, then
specify that the corresponding value is owned by the account with address
$\mathbf{k}$, _e.g._ , balances[tenderer] is owned by the tenderer in line 23.
In line 3, the developer specifies mPrice to be public. In lines 6-7, to
handle an uncertain number of suppliers, the developer declares owners
$\mathbf{p}$ and their owned data separately in two dynamic arrays. In line
10, the return value sPrice is owned by the winner. In lines 12-13, the
developer $\mathbf{reveal}$s private data to another owner, which is forced by
Cloak to avoid unconsciously leaking private data. In lines 14-24, it computes
the lowest price, the second-lowest price, and the winner. The computation is
based on the operation between private data from different parties, _e.g._ ,
bids[i]<sPrice, balances[tenderer]+=sPrice.

⬇

1contract SupplyChain {

2 mapping(address !k => uint @k) balances;

3 uint @all mPrice;

4

5 function biddingProcure(

6 address[!p] parties,

7 uint[@p] bids,

8 address tenderer

9 ) public

10 returns (address winner, uint @winner sPrice) {

11 winner = parties[0];

12 uint mPrice = reveal(bids[0], all);

13 sPrice = reveal(bids[0], winner);

14 for (uint i = 1; i < parties.length; i++) {

15 if (bids[i] < mPrice) {

16 winner = parties[i];

17 sPrice = mPrice;

18 mPrice = bids[i];

19 } else if (bids[i] < sPrice) {

20 sPrice = bids[i];

21 }

22 }

23 balances[tenderer] -= sPrice;

24 balances[winner] += sPrice;

25 }

26}

Listing 1: An exemplified Cloak smart contract (.cloak)

####  5.2.2 Type system exemplified

We now discuss the type system. We present core rules of Cloak ’s type system
(illustrated shortly) in Fig. 5. We write $\Gamma\vdash e:\tau@\alpha$ (resp.
$\Gamma\Vdash L:\tau@\alpha$) to indicate that expression $e$ (resp. location
$L$) is of type $\tau@\alpha$ under the typing context $\Gamma$. We write
$g\vdash\prod_{i=1}^{n}\tau_{i}@\alpha_{i}\rightarrow\tau@\alpha\triangleright
F:\beta$ to express that the $i^{th}$ argument of a native function $g$ is of
type $\tau_{i}@\alpha_{i}$, the return value is of type $\tau@\alpha$, where
$\alpha,\alpha_{1},\dots,\alpha_{n}\in\\{$$\mathbf{me}$, $\mathbf{all}$,
id$\\}$, the function type of $F$ which $g$ belongs to is
$\beta\in\\{\mathbf{PUT},\mathbf{PRT},\mathbf{MPT}\\}$. We write
$\Gamma\stackrel{{\scriptstyle P}}{{\leadsto}}\Gamma^{\prime}$ to indicate
that statement $P$ is well-typed and transforms the typing context $\Gamma$ to
$\Gamma^{\prime}$, capturing that $P$ might declare new variables and thereby
modifies the context.

$\frac{\Gamma\Vdash L:\tau@\alpha\quad\alpha\text{ provably evaluates to
$\alpha^{\prime}$ }}{\Gamma\vdash L:\tau@\mathbf{\alpha^{\prime}}}$

(a) reduce

$\frac{\Gamma\Vdash L:\tau@\alpha\quad\Gamma\vdash
e:\tau@\alpha^{\prime}\quad\left(\alpha=\alpha^{\prime}\vee\alpha^{\prime}=\mathbf{all}\right)}{\Gamma\stackrel{{\scriptstyle
L=e}}{{\leadsto}}\Gamma}$

(b) assign

$\frac{\Gamma\vdash
e:\tau@\mathbf{\alpha}}{\Gamma\vdash\mathbf{reveal}(e,\alpha^{\prime}):\tau@\alpha^{\prime}}$

(c) reveal

Figure 5: Selected typing rules for expressions

Fig. 5 shows the expression rules. The provable equal $\alpha$ and
$\alpha^{\prime}$ will be recorded as a same owner (Fig. 5a). The type rule
for assignments $L=e$ (Fig. 5b) requires (a) typing the target location $L$ as
$\tau@\alpha$, (b) the expression $e$ as $\tau@\alpha^{\prime}$, and (c)
$\alpha=\alpha^{\prime}\lor\alpha^{\prime}=all$. To avoid type errors, we must
explicitly reclassify expression private to $\alpha$ to another owner
$\alpha^{\prime}$ (Fig. 5c).

$\vdash
g:\prod_{i=1}^{n}\tau_{i}@\alpha_{i}\rightarrow\tau@\alpha_{o}\triangleright\left\\{\begin{array}[]{lcl}\vspace{0.2cm}F:\mathbf{PUT}&&\begin{array}[]{l}\forall\leavevmode\nobreak\
\alpha_{i}\in\\{\mathbf{all}\\}\end{array}\\\
\vspace{0.2cm}F:\mathbf{PRT}&&\begin{array}[]{l}|\alpha_{o}\backslash\\{\mathbf{all,tee}\\}|=1\end{array}\\\
F:\mathbf{MPT}&&\begin{array}[]{l}(\exists\alpha_{i}=\mathbf{tee})\leavevmode\nobreak\
\vee\\\ (|\alpha_{o}\backslash\\{\mathbf{all}\\}|\geq
2)\end{array}\end{array}\right.$

Figure 6: Typing rules for functions.
$\alpha_{o}=\\{\alpha_{1},\cdots,\alpha_{n}$} is the unified owner set of all
expressions in $g$

Fig. 6 shows the function rules recognizing the function type. We denote the
unified owner set of $g$’s expressions as
$\alpha_{o}=\\{\alpha_{1},\dots,\alpha_{n}\\}$. For example, $g$ include
$\tau_{1}@$$\mathbf{all}$$,\tau_{2}@id,\tau_{3}@$$\mathbf{me}$$,\tau_{4}@$$\mathbf{all}$.
Given $\mathbf{me}$ equals $\mathbf{id}$ (by Fig. 5a) thereby
$\alpha_{o}=($$\mathbf{all}$, $\mathbf{me}$$)$. The functions type of $F$
which $g$ belongs to is typed as public transaction ($\mathbf{PUT}$) iff
$\alpha_{o}=\\{$$\mathbf{all}$$\\}$, private transaction ($\mathbf{PRT}$) iff
only one private expression exists but not owned by $\mathbf{tee}$, and multi-
party transaction ($\mathbf{MPT}$) iff $g$ reads secrets from different
parties. Here we design the typing rules of $\mathbf{PRT}$ and $\mathbf{MPT}$
for two reasons. First, since computational sparse $\mathbf{PRT}$ can be also
implemented by ZKP solutions, we distinguish it from $\mathbf{MPT}$ to allow
developers in parallel implement $\mathbf{PRT}$ functions without TEE, _e.g._
, [11], though we stress that it’s also easy to naturally support
$\mathbf{PRT}$ by regarding it as a 1-party $\mathbf{MPT}$. Second, we
classify the scenarios involving $\mathbf{tee}$-owned private data to
$\mathbf{MPT}$ in reason that it also needs evaluating the function in
enclaves, thus technically being equivalent to $\mathbf{MPT}$ in the
compilation.

Taking a Cloak smart contract, Cloak ignores the annotation to check the
Solidity validation first, then builds an Abstract Syntax Tree (AST) for
further analysis. It adopts rules in Fig. 5 to infer expression owners and
recognize function type by Fig. 6. Then, Cloak checks privacy invariants
consistency, _e.g._ , prohibiting developers from implicitly assigning private
data to variables owned by others. For example, in Listing 1 line 6-7, the
developer declares the address array _parties’s elements as $\mathbf{p}$, and
annotates the _bids’s elements being private to $\mathbf{p}$ respectively.
Therefore, Cloak requires the run-time length of _parties equals it of _bids.
Next, in line 20, the run-time owner of _bid[i], _i.e._ , _parties[i], is
different from the owner of sPrice, thus Cloak infers the function being
$\mathbf{MPT}$.

###  5.3 Generate and Deploy Enforcement Code

With a specified Cloak smart contract, Cloak compiles the contract to generate
enforcement code, _i.e._ a verifier contract $\mathcal{V}$ that be deployed on
blockchain to verify state transition, a private contract $\mathcal{F}$ that
will be confidentially executed in TEE, and a privacy policy $\mathcal{P}$
that holds ownership setting of the Cloak smart contract and is also deployed
to and enforced by TEE. We leave the details of $\mathcal{V}$, $\mathcal{F}$,
$\mathcal{P}$ in Appendix 9.2.

In the deployment phase, a developer uses C to deploy the generated
enforcement code (_i.e._ , $\mathcal{V},\mathcal{F},\mathcal{P}$) to
$A_{\textsc{Cloak}-BC}$ (handling C2). Specifically, the developer first
deploys $\mathcal{V}$ to BC. $\mathcal{V}$ is constructed by
$adr_{\mathcal{E}}$ and hashes of $\mathcal{F},\mathcal{P}$. In this way,
$\mathcal{V}$ only accepts state transition transactions that match the
$\mathcal{F},\mathcal{P}$ in it and are sent by $adr_{\mathcal{E}}$. Then, the
developer deploys $\mathcal{F},\mathcal{P}$ to E and binds $adr_{\mathcal{V}}$
to $\mathcal{F},\mathcal{P}$. We leave the details of how to deploy
$\mathcal{V}$, $\mathcal{F}$, $\mathcal{P}$ to $A_{\textsc{Cloak}-BC}$ in
Appendix 9.2.

##  6 Cloak Protocol

Cloak protocol $\pi_{\textsc{Cloak}}$ is used to enforce MPT in the
transaction phase (handling C3). As is shown in Figure 7, given a Cloak
blockchain BC, a party set $\bar{\textit{{P}}}$ (a set of C participating the
MPT), and a Cloak Executor E, where $|\bar{\textit{{P}}}|=n$, we stress that
each $P_{i}\in\bar{\textit{{P}}}$ communicates with $\mathcal{E}$ of E by
secure channel, _i.e._ , all messages sent by a party $P_{i}$ to E is signed
by $P_{i}$ and encrypted by $pk_{\mathcal{E}}$, while all messages sent by
$\mathcal{E}$ to $P_{i}$ are also signed by $\mathcal{E}$ . Therefore, for
simplicity, we omit to mark ciphertext in communications between
$\bar{\textit{{P}}}$ and $\mathcal{E}$ in the following, but will explicitly
mark the ciphertext in each transaction sent to the blockchain.

###  6.1 Cloak Protocol in Transaction Phase

As explained in Section 4, our protocol $\pi_{\textsc{Cloak}}$ used in the
transaction phase proceeds in four stages, depicted in Figure 7. Before using
Cloak, a party $P_{i}$ is supposed to globally $register$ its public key
$pk_{i}$ and $deposit$ its coins $Q$ in global setup stage. We stress this
stage happen only once for each party. Then, three stages follows to evaluate
an MPT. During a negotiation stage, all parties negotiate to join an MPT and
finally, E commits settled MPT proposal with parties’ inputs commitments and
deducts their collateral on-chain. Then, an execution stage follows for
collecting plaintext of parameters and old states from parties and executing
MPT in the TEE enclave to get outputs. When the execution finishes, the
protocol enters a distribution stage to commit outputs and complete the MPT.
We now explain the detailed protocol steps in depth. The detailed interactions
are displayed in Figure 7. Algorithm 2 in Appendix 9.1 describes the Cloak
enclave program $\mathcal{E}$.

####  6.1.1 Negotiation stage

The negotiation stage uses an nondeterministic negotiation protocol
($\textbf{{{Proc}}}_{\text{noneg}}$) to guide parties to reach a consensus on
an MPT proposal and commit parameters $x_{i}$ on-chain444As contracts’
storage, old state $s_{i}$ has been committed on-chain..
$\textbf{{{Proc}}}_{\text{noneg}}$ allows $\bar{\textit{{P}}}$ proceeds in two
steps.

Cloak Clients ($\bar{\textbf{{P}}}^{\textbf{{C}}}$) Cloak Executor
($\textbf{{E}}^{\mathcal{E}^{\mathcal{F},\mathcal{P}}}$) Cloak Blockchain
($\textbf{{BC}}^{CS,\mathcal{V}}$) $\uparrow S1$$\uparrow S2$$\uparrow
S1$$\uparrow S2$$\uparrow S3$ Global
---
setup
stage
Negotiation
---
stage
($\textbf{{Proc}}_{\text{noneg}}$)
Execution
---
stage
Distribution
---
stage
$\begin{aligned} \text{send}\leavevmode\nobreak\
TX^{i}_{pk}\leftarrow\textbf{{BC}}.CS.register(pk_{i})\end{aligned}$
$\begin{aligned} \text{send}\leavevmode\nobreak\
TX^{i}_{col}\leftarrow\textbf{{BC}}.CS.deposit(Q)\end{aligned}$
$\begin{aligned} \text{sends}\leavevmode\nobreak\
TX^{\textit{{E}}}_{col}\leftarrow\textbf{{BC}}.CS.deposit(Q)\end{aligned}$
$\begin{aligned} &\text{initialize}\leavevmode\nobreak\ p\leftarrow\langle
f,q,t_{n}\rangle\\\ &\text{send}\leavevmode\nobreak\ p\end{aligned}$
$\begin{aligned} &\text{generates}\leavevmode\nobreak\ id_{p}\\\
&\text{sends}\leavevmode\nobreak\ \langle id_{p},p\rangle\end{aligned}$
$\begin{aligned} &\text{generate a random number}\leavevmode\nobreak\
r^{x}_{i}\\\ &\text{generate}\leavevmode\nobreak\
C_{x_{i}}\leftarrow\textnormal{{Enc}}_{pk_{i}}(x_{i},r^{x}_{i})\\\
&\text{send}\leavevmode\nobreak\ ACK_{i}\leftarrow\langle
id_{p},H_{C_{x_{i}}}\rangle\end{aligned}$ $\begin{aligned}
&\text{gets}\leavevmode\nobreak\ TX^{i}_{pk}\leavevmode\nobreak\ \text{and
reads}\leavevmode\nobreak\ pk_{i}\end{aligned}$ $\begin{aligned}
&\text{generates}\leavevmode\nobreak\ p^{\prime}\leftarrow\langle
adr_{\mathcal{V}},f,\bar{\textit{{P}}},H_{C_{x_{i}}},q\rangle\\\
&\text{sends}\leavevmode\nobreak\
TX_{p}\leftarrow\textbf{{BC}}.CS.propose(id_{p},p^{\prime},\tau_{res},\tau_{com})\end{aligned}$
$\begin{aligned} &\text{if}\leavevmode\nobreak\
\bar{\textit{{P}}}_{M}\subset\bar{\textit{{P}}}\leavevmode\nobreak\
\text{depart the protocol}\\\ &\text{sends}\leavevmode\nobreak\
TX_{cha}\leftarrow\textbf{{BC}}.CS.challenge(id_{p},\bar{\textit{{P}}}_{M})\end{aligned}$
$\begin{aligned} &\text{if}\leavevmode\nobreak\
P_{j}\in\bar{\textit{{P}}}_{M}\leavevmode\nobreak\ \text{is challenged}\\\
&\text{generate}\leavevmode\nobreak\ in\leftarrow\langle
x_{i},r^{x}_{i},s_{i},r^{s}_{i}\rangle\\\ &\text{sends}\leavevmode\nobreak\
TX_{res}\leftarrow\textbf{{BC}}.CS.response(id_{p},\textnormal{{Enc}}_{pk_{\mathcal{E}}}(in))\end{aligned}$
$\begin{aligned} &\text{verifies}\leavevmode\nobreak\
PoP_{res}\leavevmode\nobreak\ \text{and reads}\leavevmode\nobreak\ TX_{res}\\\
\end{aligned}$ $\begin{aligned} &\text{if}\leavevmode\nobreak\
\bar{\textit{{P}}}^{\prime}_{M}\subset\bar{\textit{{P}}}_{M}\leavevmode\nobreak\
\text{still depart}\\\ &\text{sends}\leavevmode\nobreak\
TX_{pns}\leftarrow\textbf{{BC}}.CS.punish(id_{p},\bar{\textit{{P}}}^{\prime}_{M},q)\\\
\end{aligned}$ $\begin{aligned} &\text{send}\leavevmode\nobreak\
in\leftarrow\langle x_{i},r^{x}_{i},s_{i},r^{s}_{i}\rangle\\\ \end{aligned}$
$\begin{aligned} \text{verifies}\leavevmode\nobreak\
PoP_{p}\leavevmode\nobreak\ \text{and reads}\leavevmode\nobreak\
TX_{p},C_{s}\end{aligned}$ $\begin{aligned}
&\text{evaluate}\leavevmode\nobreak\ f(x)\leavevmode\nobreak\ \text{based
on}\leavevmode\nobreak\ s\\\ &\text{get}\leavevmode\nobreak\
s^{\prime},r\end{aligned}$ $\begin{aligned} &\text{generates random
numbers}\leavevmode\nobreak\ r^{s^{\prime}}_{i},r^{r}_{i}\\\
&\text{generates}\leavevmode\nobreak\
C_{s^{\prime}_{i}},C_{r_{i}}\leftarrow\textnormal{{Enc}}_{pk_{i}}(s^{\prime}_{i},r^{s^{\prime}}_{i}),\textnormal{{Enc}}_{pk_{i}}(r_{i},r^{r}_{i})\\\
&\text{generates}\leavevmode\nobreak\ proof\leftarrow\langle
H_{\mathcal{P}},H_{\mathcal{F}},\hat{H}_{C_{s}},\hat{H}_{C_{x}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}\rangle\\\
&\text{sends}\leavevmode\nobreak\
TX_{com}\leftarrow\textbf{{BC}}.CS.complete(id_{p},proof,C_{s},C_{s^{\prime}},C_{r})\end{aligned}$
$\begin{aligned} &\text{send}\leavevmode\nobreak\
TX_{out}\leftarrow\textbf{{BC}}.CS.timeout(id_{p})\end{aligned}$
+$\mathcal{E}.generateIDp$$\mathcal{E}.propose$$\mathcal{E}.execute$$\mathcal{E}.challenge$$\mathcal{E}.punish$$\mathcal{E}.complete$✓✓
Figure 7: The detailed Cloak protocol $\pi_{\textsc{Cloak}}$. The
$\bar{\textbf{{P}}}^{\textbf{{C}}}$ means parties holding Cloak Client C. The
$\textit{{E}}^{\mathcal{E}^{\mathcal{F},\mathcal{P}}}$ means a Cloak Executor
holding a TEE device $\mathcal{E}$ with deployed $\mathcal{F},\mathcal{P}$.
$\textit{{BC}}^{CS,\mathcal{V}}$ means the Cloak Blockchain with deployed
Cloak service contract $CS$ and verifier contract $\mathcal{V}$. Double dashed
arrows refer to reading from the blockchain and double arrows refer to sending
a transaction to the blockchain. Normal arrows mean off-chain communication.
$\textbf{{Proc}}_{\text{noneg}}$ refers to Non-deterministic negotiation
protocol. All parties $P_{i}$ communicate with the Cloak Executor in secure
channels, thus we omit to mark ciphertext in communications between
$\bar{\textit{{P}}}$ and $\mathcal{E}$ for simplicity but explicitly mark the
ciphertext in each transaction published on $\textit{{BC}}^{CS,\mathcal{V}}$.
For parties’ private data, we refer the part of data $d$ owned by $P_{i}$ to
$d_{i}$ (_e.g._ , $x_{i},r^{x}_{i}$), and refer an array $[d_{i}|_{1..n}]$
including all $d_{i}$ from $n$ parties to $d$ (_e.g._ , $x,r^{x}$). For
operation based on these data, we similarly refer $\textnormal{{hash}}(d_{i})$
to $H_{d_{i}}$, and $[\textnormal{{hash}}(d_{i})|_{1..n}]$ to $H_{d}$ (_e.g._
, $H_{C_{x}}$ refers to $[\textnormal{{hash}}(C_{x_{i}})|_{1..n}]$).
Differently, we refer $\hat{H}_{d}$ (_e.g._ ,
$\hat{H}_{C_{x}},\hat{H}_{C_{s}}$) to $\textnormal{{hash}}([d_{i}|_{1..n}])$.

S1: One party who wants to call an MPT $f$ send an MPT proposal $p=\langle
f,q,t_{n}\rangle$ to $\mathcal{E}$, in which $t_{n}$ means the time of
finishing the negotiation phase, $q$ refers to required collaterals for
punishing malicious parties. Then, $\mathcal{E}$ generates a random id
$id_{p}$ for the proposed MPT and broadcasts the signed $\langle
id_{p},p\rangle$ to parties.

S2: Receiving $\langle id_{p},p\rangle$, each $P_{i}$ interested in the MPT
autonomously computes the commitment $C_{x_{i}}$ of its parameter $x_{i}$ and
sends a signed acknowledgment $ACK_{i}=\langle id_{p},C_{x_{i}}\rangle$ to
$\mathcal{E}$ before $t_{n}$. $\mathcal{E}$ receiving $ACK_{i}$ knows that
$P_{i}$ is interested in the MPT. Then, $\mathcal{E}$ reads $TX^{i}_{pk}$ to
get $pk_{i}$. $pk_{i}$ will be used for encrypting $P_{i}$’s secrets next.
$\mathcal{E}$ keeps collecting $ACK_{i}$. If collected $ACK_{i}$ meet the
settlement condition555Settlement conditions of negotiation can be flexible
and configurable, _e.g._ , all inputs required by the MPT have been provided
or the number of parties exceeds a specific number. in $p$, $\mathcal{E}$
constructs the settled proposal $p^{\prime}$ which expands $p$ with parties’
addresses $\bar{\textit{{P}}}$ and the hash of parameter commitments
$H_{C_{x}}$. $\mathcal{E}$ then sends $TX_{p}$ to confirm the $p^{\prime}$ on
blockchain before executing the MPT. $TX_{p}$ also deducts $q$ collateral of
each party respectively before executing the MPT. Then, $\mathcal{E}$ goes to
the execution stage. Otherwise, if the settlement condition is still not
satisfied and the time exceeds $t_{n}$, the negotiation of the $p$ failed and
$\mathcal{E}$ stops the protocol.

####  6.1.2 Execution stage

This stage aims to collect plaintext inputs from parties and execute the MPT
to get outputs. It also contains three steps.

S1: Upon $TX_{p}$ is confirmed on BC, $\mathcal{E}$ verifies the Proof-of-
Publication ($PoP_{p}$ [12, 10]) of $TX_{p}$. Then, $\mathcal{E}$ reads
$f$-needed old state commitments $C_{s}$666The old states that the called MPT
$f$ read in execution. $\mathcal{E}$ reads $f$-needed old states commitments
from BC according to $f$’s read set $\mathcal{P}_{f}.\mathcal{P}_{X}$. from
BC. Meanwhile, each party $P_{i}$ knowing they are involved in $TX_{p}$ sends
inputs (_i.e._ , parameters $x_{i}$ and old states $s_{i}$) to $\mathcal{E}$.
The $\mathcal{E}$ receiving $P_{i}$’s inputs recomputes commitments of
$x_{i},s_{i}$ respectively to match them with their commitments
$C_{x_{i}},C_{s_{i}}$. If all involved parties’ inputs are collected and
matched, $\mathcal{E}$ goes to S3. Otherwise, if $\mathcal{E}$ finds that some
parties’ inputs mismatches their on-chain commitments, or have not received
some parties’ inputs before $t_{e}$, $\mathcal{E}$ marks these parties as
potentially misbehaved parties $\bar{\textit{{P}}}_{M}$ and returns
$\bar{\textit{{P}}}_{M}$ to E. Then, E calls $challenge$ to send $TX_{cha}$ to
challenge all parties in $\bar{\textit{{P}}}_{M}$ on-chain. Then,
$\mathcal{E}$ goes to S2.

S2: When $TX_{cha}$ has been confirmed on-chain, honest parties in
$\bar{\textit{{P}}}_{M}$ are supposed to send a $TX_{res}$ to publish their
ciphertext of inputs $x_{i},s_{i}$ on BC. All published $TX_{res}$ are
required to be confirmed before block height $\tau_{res}$. When the block
height goes to $\tau_{res}$, $\mathcal{E}$ reads published $TX_{res}$ and
verifies its $PoP_{res}$. For a party $P_{i}$ in $\bar{\textit{{P}}}_{M}$, if
$\mathcal{E}$ successfully reads matched inputs from its $TX^{i}_{res}$,
$\mathcal{E}$ removes $P_{i}$ from $\bar{\textit{{P}}}_{M}$. Otherwise, if
$PoP_{res}$ shows that no $TX^{i}_{res}$ is published or the inputs in
$TX^{i}_{res}$ are still mismatched, $\mathcal{E}$ keeps $P_{i}$ in
$\bar{\textit{{P}}}_{M}$. After that, if $\bar{\textit{{P}}}_{M}$ becomes
empty, which means all inputs are collected, $\mathcal{E}$ goes to S3. On the
contrary, if $\bar{\textit{{P}}}_{M}$ is not empty, which means the
misbehavior of parties left is confirmed, $\mathcal{E}$ marks these misbehaved
parties as $\bar{\textit{{P}}^{\prime}_{M}}$. Then, $\mathcal{E}$ sends
$TX_{pns}$. The $TX_{pns}$ calls $\textbf{{BC}}.CS.punish$ to refund deducted
collaterals of all parties to only honest parties on average and settle the
MPT with ABORT.

S3: If all parties’ inputs are correctly collected, $\mathcal{E}$ replaces the
state of private contract $\mathcal{F}$ with old state $s$, then execute
$f(x)$ to get MPT outputs, _i.e._ , return values $r$ and new state
$s^{\prime}$.

####  6.1.3 Distribution stage

This stage delivers $s^{\prime}_{i},r_{i}$ to each $P_{i}$ by publishing their
commitments on-chain. Specifically, $\mathcal{E}$ computes commitments of
$s^{\prime}_{i},r_{i}$ thus getting $C_{s^{\prime}_{i}},C_{r_{i}}$. Then,
$\mathcal{E}$ generates a $proof$ and sends
$TX_{com}=\textbf{{BC}}.CS.complete(id_{p},proof,C_{s},C_{s^{\prime}},C_{r})$
to blockchain. The $proof=\langle
H_{\mathcal{P}},H_{\mathcal{F}},\hat{H}_{C_{s}},\hat{H}_{C_{x}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}\rangle$
where $H_{\mathcal{P}}$ (resp. $H_{\mathcal{F}}$) refers to
$\textnormal{{hash}}(\mathcal{P})$ (resp. $\textnormal{{hash}}(\mathcal{F})$)
and $\hat{H}_{C_{s}}$ refers to $\textnormal{{hash}}([C_{s_{i}}|_{1..n}])$ as
well as $\hat{H}_{C_{x}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}$. The
$proof$ in $TX_{com}$ achieves the public verifiability of the MPT by
following way: The signed $TX_{com}$ means that $\mathcal{E}$ endorses that by
enforcing a privacy policy $\mathcal{P}$ (matching $H_{\mathcal{P}}$), it
takes private $x,s$ (matching $\hat{H}_{C_{x}},\hat{H}_{C_{s}}$) from
$\bar{\textit{{P}}}$, evaluates $f$ of a private contract $\mathcal{F}$
(matching $H_{\mathcal{F}}$), and gets private outputs $s^{\prime},r$
(matching $\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}$). Therefore, by trusting
the integrity and confidentiality of $\mathcal{E}$, if $\textbf{{BC}}.CS$
checks that $H_{\mathcal{P}},H_{\mathcal{F}}$ in $proof$ match recorded
$H_{\mathcal{P}},H_{\mathcal{F}}$ in $\mathcal{V}$ and the $H_{C_{s}}$ in
$proof$ matches the current state commitments777$\mathcal{V}$ reads current
state commitments of $\mathcal{V}$ according to $TX_{com}.\mathcal{P}_{X}$ of
$\mathcal{V}$, $\textbf{{BC}}.CS$ then accepts the state transition and
updates $\mathcal{V}$’s current state commitment with $C_{s^{\prime}}$, which
signals the COMPLETE of the MPT. Otherwise, if $\mathcal{E}$ departing the
protocol does not complete (by $TX_{com}$) or stop (by $TX_{pns}$) the MPT
before the block height $\tau_{com}$, it indicates that E departs the protocol
by dropping $TX_{com}$ and $TX_{pns}$ or crashing. Then, any $P_{i}$ can send
$TX_{out}$ to punish E and refunds their collaterals with additional
compensation. $TX_{out}$ also finishes the MPT with TIMEOUT.

##  7 System Security

In this section, we present the underlying protocol security considerations of
Cloak. The architecture security is shown in Appendix 9.3. To guarantee
security for the protocol, we require three security properties. Intuitively,
they can be explained as the following:

Confidentiality. During a period without any compromised TEE, Cloak guarantees
that the inputs, return values, and contract states of MPT are kept secret to
their owners.

Public Verifiability. Everyone can verify that a state transition correctly
results from an MPT which given committed old states and parameters from
different parties results in the claimed committed return values and new
states.

Financial Fairness. At least one of parties or the Executor is honest, then
either (i) the protocol correctly completes execution of MPT or (ii) all
honest parties and the Executor know that setup or negotiation failed and stay
financially neutral or (iii) all honest parties and the Executor know the
protocol abort, stay financially neutral, and malicious parties or Executor
must have been financially punished.

######  Theorem 1 (Informal statement).

The protocol $\pi_{\textsc{Cloak}}$ satisfies confidentiality, public
verifiability, financial fairness

##  8 Evaluation

System implementations. We prototype Cloak compiler by ANTLR [32]. It
generates $\mathcal{P}$ in JSON and contracts $\mathcal{V},\mathcal{F}$ in
Solidity 0.8 [16]. We use Ganache [41] as $BC$ and prototype the Cloak enclave
program and its called EVM [17] in C++ as an application of CCF [35] with a
single node.

Methodology and setup. To evaluate the effectiveness of Cloak, we propose 3
research questions.

  * •

Q1: How does Cloak language reduce the complexity of developing confidential
smart contracts?

  * •

Q2: What’s the cost of initialization, setup and deployment for enabling MPT
on a blockchain by using Cloak?

  * •

Q3: What’s the cost of sending MPT by using Cloak?

The experiment is based on Ubuntu 18.04 with 32G memory and 2.2GHz Intel(R)
Xeon(R) Silver 4114 CPU. Although the gas cost of a specific transaction is
deterministic, it also varies from transaction arguments. Therefore, we send
each transaction of Cloak parsed contract 5 times with different arguments to
get the average.

Development Simplicity. To answer Q1, we apply Cloak on 8 contracts. The 8
contracts vary from LOC, scenarios, and privacy needs. Contracts business
involves energy, education, blockchain infrastructure and so on. Their LOC
distributes from 29 to 1035, which is a representative LOC distribution of
Ethereum contracts [23]. Each of these contracts consists of at least two of
three function types (PUT, PRT, and MPT). Table 2 shows the LOC of code before
and after using Cloak. Specifically, for MPT related code, while developers
simply annotate privacy invariants of MPT in Solidity contract, Cloak
generates a total of 2.86-21.78X LOC, including 0.30-4.11X LOC of verifier
contracts, 1.06-4.33X private contracts, and 1.67-13.33X privacy policies.
Therefore, Cloak significantly reduces the development complexity of privacy
in cryptography understanding and code implementation.

Table 2: The LOC of code before and after using Cloak. #C refers to the number of transactions ($\mathrm{PUT}$, $\mathrm{PRT}$, $\mathrm{MPT}$); The #$\mathcal{F}_{a}$, #$\mathcal{V}_{a}$, and #$\mathcal{P}_{a}$ refer to LOC of the Cloak smart contract, private contract, verifier contract, and privacy policy respectively. Name | #TX | #C | #$\mathcal{F}_{a}$ | #$\mathcal{V}_{a}$ | #$\mathcal{P}_{a}$ |  | MPT related
---|---|---|---|---|---|---|---
| #C |  #$\mathcal{F}$ |  #$\mathcal{V}$ |  #$\mathcal{P}$
PowerGrid |  4(1, 1, 2) | 29 | 60 | 71 | 146 |  | 11 | 36 | 39 | 114
Bidding |  4(1, 1, 2) | 46 | 70 | 73 | 164 |  | 22 | 56 | 61 | 137
SupplyChain |  6(1, 4, 1) | 71 | 110 | 118 | 357 |  | 9 | 39 | 37 | 120
Scores |  6(1, 2, 3) | 79 | 126 | 139 | 438 |  | 37 | 106 | 126 | 289
ERC20Token |  11(4, 4, 3) | 115 | 152 | 130 | 662 |  | 38 | 55 | 37 | 240
YunDou |  14(11, 0, 3) | 275 | 348 | 331 | 1172 |  | 99 | 105 | 58 | 433
Oracle |  22(20, 0, 2) | 329 | 323 | 333 | 1720 |  | 37 | 60 | 48 | 307
HTLC |  39(31, 0, 8) | 1035 | 858 | 576 | 2240 |  | 377 | 437 | 146 | 816

Gas cost of initialization and deployment. To answer Q2, we discuss the gas
cost of deploying CloakService and generated contracts. Specifically, we
compile the Cloak smart contracts in Table 2. As is depicted in Figure 8. In
global initialization phase. deploying the CloakService to enable Cloak cost
the Cloak service provider 4.49M gas. In global setup stage, each party pays
127k gas to $register$ its public key and 42k gas to $deposit$ its coins.
Then, for developers, they pay 2.90-6.87X gas to deploy the transformed small
contracts (PoW.-ERC.), 1.49X gas to deploy the transformed Yun., 0.92X gas to
deploy the transformed Ran., and 0.05X to deploy the transformed HTLC, where
Yun.-HTLC are industrial contracts. This result indicates that with the
computation complexity of original contracts growing, the gas cost of
transformed contracts relatively reduces. That is because the gas cost of
generated $\mathcal{V}$ to verify and update new state depends more on how
many state variables the $\mathcal{V}$ managed than how heavy the computation
is in original contracts. Therefore, Cloak has great potentiality in applying
to industrial contracts.

Figure 8: The gas cost of Cloak

Gas cost of sending MPT. To answer Q3, for all 8 contracts, all their 24 MPT
cost 0.71X gas to the Fastkitten on average. Specifically, for the MPT with 1
party (classified as MPT by $\mathbf{tee}$), Cloak cost 0.97X gas. However,
for all MPT with at least 2 parties, Cloak cost 0.46-0.82X gas (0.71X on
average). The result shows that the more parties involved in an MPT, the more
advantage Cloak has in gas cost, _e.g._ , for 10 parties, Cloak costs only
0.46X gas against Fastkitten. We stress that while our implementation is
definitely not optimized, we can furthermore adopt other methods to reduce the
gas cost. We discuss it in detail in Appendix 9.4.

Off-chain latency of sending MPT. Normally, all 24 MPT complete in 6 second
except that an bidding transaction with 6 parties completes in 8 seconds. We
stress that only 0.1-0.39s is cost for negotiation phase and 0.26-0.71s is for
execution and distribution phase. Most time 4-5s is spent on verifying the
$PoP_{p}$ of $TX_{p}$, which is also indicated in [14].

##  9 Conclusion

In this paper, we have first identified and formalized the problem of the
Multi-party Transaction which requires public verifiability of a state
transition caused by a multi-party computation process. We also developed a
novel framework, Cloak, to enable confidential smart contracts with mixed PUT,
PRT, and MPT on existing blockchains. To the best of our knowledge, Cloak
advances in these aspects: introducing the first domain-specific language
which allows developers to specify PUT, PRT, and MPT in a single confidential
smart contract by annotating privacy invariants at the place; the first
solution achieving public verifiability of an MPT; supporting parties
negotiating MPT proposals without knowing each other’s identity in prior;
achieving financial fairness under byzantine adversary model. During our
evaluation of Cloak in both examples and real-world smart contracts, the LOC
of developing Cloak smart contract is 13.5% less than deployed ones, and Cloak
requires only 2 transactions to secure an MPT.

In conclusion, Cloak achieves low-cost, secure, and public verifiable MPT. It
eliminates low-level, bug-prone, and time-consuming MPT implementations for
both developers and users thus paving the way for general-purpose multi-party
privacy-preserved computation.

## References

  * [1] Martín Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay Ligatti.  Control-flow integrity principles, implementations, and applications.  ACM Transactions on Information and System Security (TISSEC), 13(1):1–40, 2009.
  * [2] Andrea Biondo, Mauro Conti, Lucas Davi, Tommaso Frassetto, and Ahmad-Reza Sadeghi.  The guards dilemma: Efficient Code-Reuse attacks against intel sgx.  In 27th USENIX Security Symposium (USENIX Security 18), pages 1213–1227, Baltimore, MD, August 2018. USENIX Association.
  * [3] Dan Bogdanov, Peeter Laud, and Jaak Randmets.  Domain-polymorphic programming of privacy-preserving applications.  In Proceedings of the Ninth Workshop on Programming Languages and Analysis for Security, pages 53–65, 2014.
  * [4] Niek J. Bouman.  MPyC: Rapid-Prototyping MPC Computations in Python, 10 2018.
  * [5] Sean Bowe, Alessandro Chiesa, Matthew Green, Ian Miers, Pratyush Mishra, and Howard Wu.  ZEXE: Enabling Decentralized Private Computation.  2020 IEEE Symposium on Security and Privacy, 2020.
  * [6] Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, and Ahmad-Reza Sadeghi.  Software grand exposure: Sgx cache attacks are practical.  In 11th USENIX Workshop on Offensive Technologies (WOOT 17), Vancouver, BC, August 2017. USENIX Association.
  * [7] Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F. Wenisch, Yuval Yarom, and Raoul Strackx.  Foreshadow: Extracting the keys to the intel sgx kingdom with transient Out-of-Order execution.  In 27th USENIX Security Symposium (USENIX Security 18), page 991–1008, Baltimore, MD, August 2018. USENIX Association.
  * [8] Benedikt Bünz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh.  Zether: Towards privacy in a smart contract world.  In Joseph Bonneau and Nadia Heninger, editors, Financial Cryptography and Data Security, pages 423–443, Cham, 2020. Springer International Publishing.
  * [9] Nathan Burow, Scott A Carr, Joseph Nash, Per Larsen, Michael Franz, Stefan Brunthaler, and Mathias Payer.  Control-flow integrity: Precision, security, and performance.  ACM Computing Surveys (CSUR), 50(1):1–33, 2017.
  * [10] Lorenzo Cavallaro, Johannes Kinder, XiaoFeng Wang, Jonathan Katz, Iddo Bentov, Yan Ji, Fan Zhang, Lorenz Breidenbach, Philip Daian, and Ari Juels.  Tesseract: Real-Time Cryptocurrency Exchange Using Trusted Hardware.  Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pages 1521–1538, 2019.
  * [11] Lorenzo Cavallaro, Johannes Kinder, XiaoFeng Wang, Jonathan Katz, Samuel Steffen, Benjamin Bichsel, Mario Gersbach, Noa Melchior, Petar Tsankov, and Martin Vechev.  zkay: Specifying and Enforcing Data Privacy in Smart Contracts.  pages 1759–1776, 2019.
  * [12] Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, and Dawn Song.  Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts.  2019 IEEE European Symposium on Security and Privacy (EuroS&P), 00:185–200, 2019.
  * [13] Victor Costan, Ilia Lebedev, and Srinivas Devadas.  Sanctum: Minimal hardware extensions for strong software isolation.  In 25th USENIX Security Symposium (USENIX Security 16), pages 857–874, 2016.
  * [14] Poulami Das, Lisa Eckey, Tommaso Frassetto, David Gens, Kristina Hostáková, Patrick Jauernig, Sebastian Faust, and Ahmad-Reza Sadeghi.  FastKitten: Practical smart contracts on bitcoin.  In 28th USENIX Security Symposium (USENIX Security 19), pages 801–818, Santa Clara, CA, August 2019. USENIX Association.
  * [15] Lucas Vincenzo Davi, Alexandra Dmitrienko, Stefan Nürnberger, and Ahmad-Reza Sadeghi.  Gadge me if you can: secure and efficient ad-hoc instruction-level randomization for x86 and arm.  In Proceedings of the 8th ACM SIGSAC symposium on Information, computer and communications security, pages 299–310, 2013.
  * [16] Ethereum.  Solc 0.5.17, July 2021.
  * [17] Ethereum Foundation.  Ethereum virtual machine, Dec 2020.
  * [18] Ethereum Foundation.  Solidity documentation, Dec 2020.
  * [19] Alex Gluchowski.  Zk rollup: scaling with zero-knowledge proofs.  2019\.
  * [20] Daniel Gruss, Julian Lettner, Felix Schuster, Olya Ohrimenko, Istvan Haller, and Manuel Costa.  Strong and efficient cache side-channel protection using hardware transactional memory.  In 26th USENIX Security Symposium (USENIX Security 17), pages 217–233, 2017.
  * [21] Marcella Hastings, Brett Hemenway, Daniel Noble, and Steve Zdancewic.  SoK: General Purpose Compilers for Secure Multi-Party Computation.  volume 00 of 2019 IEEE Symposium on Security and Privacy (SP), pages 1220–1237, 2019.
  * [22] Marcella Hastings, Brett Hemenway, Daniel Noble, and Steve Zdancewic.  SoK: General Purpose Compilers for Secure Multi-Party Computation.  2019 IEEE Symposium on Security and Privacy (SP), 00:1220–1237, 2019.
  * [23] Péter Hegedűs.  Towards Analyzing the Complexity Landscape of Solidity Based Ethereum Smart Contracts.  Technologies, 7(1):6, 2019.
  * [24] Intel.  Resources and response to side channel l1 terminal fault, Dec 2021.
  * [25] Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos Papamanthou.  Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts.  2016 IEEE Symposium on Security and Privacy (SP), pages 839–858, 2016.
  * [26] Chang Liu, Xiao Shaun Wang, Kartik Nayak, Yan Huang, and Elaine Shi.  Oblivm: A programming framework for secure computation.  In 2015 IEEE Symposium on Security and Privacy. IEEE, 2015.
  * [27] David Maier, Rachel Pottinger, AnHai Doan, Wang-Chiew Tan, Abdussalam Alawini, Hung Q Ngo, Ying Yan, Changzheng Wei, Xuepeng Guo, Xuming Lu, Xiaofu Zheng, Qi Liu, Chenhui Zhou, Xuyang Song, Boran Zhao, Hui Zhang, and Guofei Jiang.  Confidentiality Support over Financial Grade Consortium Blockchain.  pages 2227–2240, 2020.
  * [28] Dahlia Malkhi, Noam Nisan, Benny Pinkas, Yaron Sella, et al.  Fairplay-secure two-party computation system.  In USENIX Security Symposium, volume 4, page 9. San Diego, CA, USA, 2004.
  * [29] Satoshi Nakamoto.  Bitcoin: A peer-to-peer electronic cash system.  Decentralized Business Review, page 21260, 2008.
  * [30] Janus Dam Nielsen and Michael I Schwartzbach.  A domain-specific programming language for secure multiparty computation.  In Proceedings of the 2007 workshop on Programming languages and analysis for security, pages 21–30, 2007.
  * [31] Job Noorman, Pieter Agten, Wilfried Daniels, Raoul Strackx, Anthony Van Herrewege, Christophe Huygens, Bart Preneel, Ingrid Verbauwhede, and Frank Piessens.  Sancus: Low-cost trustworthy extensible networked devices with a zero-software trusted computing base.  In 22nd USENIX Security Symposium (USENIX Security 13), pages 479–498, 2013.
  * [32] Terence Parr.  Antlr(another tool for language recognition), Dec 2020.
  * [33] Aseem Rastogi, Matthew A Hammer, and Michael Hicks.  Wysteria: A programming language for generic, mixed-mode multiparty computations.  In 2014 IEEE Symposium on Security and Privacy, pages 655–670. IEEE, 2014.
  * [34] Indrajit Ray, Ninghui Li, Christopher Kruegel, Ranjit Kumaresan, Tal Moran, and Iddo Bentov.  How to Use Bitcoin to Play Decentralized Poker.  Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015.
  * [35] Mark Russinovich, Edward Ashton, Christine Avanessians, Miguel Castro, Amaury Chamayou, Sylvan Clebsch, and et al.  Ccf: A framework for building confidential verifiable replicated services.  Technical report, Microsoft Research and Microsoft Azure, 2019.
  * [36] Jaebaek Seo, Byoungyoung Lee, Seong Min Kim, Ming-Wei Shih, Insik Shin, Dongsu Han, and Taesoo Kim.  Sgx-shield: Enabling address space layout randomization for sgx programs.  In NDSS, 2017.
  * [37] Ming-Wei Shih, Sangho Lee, Taesoo Kim, and Marcus Peinado.  T-sgx: Eradicating controlled-channel attacks against enclave programs.  In NDSS, 2017.
  * [38] Rohit Sinha.  Luciditee: A tee-blockchain system for policy-compliant multiparty computation with fairness.  2020\.
  * [39] Second State and Oasis Labs.  Confidential Ethereum Smart Contracts.  Technical report, 12 2020.
  * [40] Bhavani Thuraisingham, David Evans, Tal Malkin, Dongyan Xu, Arka Rai Choudhuri, Matthew Green, Abhishek Jain, Gabriel Kaptchuk, and Ian Miers.  Fairness in an Unfair World: Fair Multiparty Computation from Public Bulletin Boards.  Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pages 719–728, 2017.
  * [41] trufflesuite.  Ganache, July 2021.
  * [42] Edgar Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew Myers, Shai Halevi, Ranjit Kumaresan, and Iddo Bentov.  Amortizing Secure Computation with Penalties.  Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016.
  * [43] Edgar Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew Myers, Shai Halevi, Ranjit Kumaresan, Vinod Vaikuntanathan, and Prashant Nalini Vasudevan.  Improvements to Secure Computation with Penalties.  Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 406–417, 2016.
  * [44] Gavin Wood et al.  Ethereum: A secure decentralised generalised transaction ledger.  Ethereum project yellow paper, 2014.
  * [45] Andrew C Yao.  Protocols for secure computations.  In 23rd annual symposium on foundations of computer science (sfcs 1982), pages 160–164. IEEE, 1982.

## Appendix

###  9.1 Enable Cloak on Existing Blockchain

To be interoperable with existing blockchains, Cloak is designed to depend on
contract-based infrastructure to enable MPT. The Cloak Executor should
globally initialize its TEE and register $\mathcal{E}$ on an existing
blockchain first, then anyone can deploy their generated enforcement code of
the Cloak smart contract to enable MPT on the blockchain.

####  9.1.1 Setup Cloak executor

The Cloak Executor deploys the Cloak enclave program (Algorithm 1) in a TEE
device to get its $\mathcal{E}$. E first calls $setup$ to generate a key pair
and accounts inside $\mathcal{E}$, _i.e._ ,
$(pk_{\mathcal{E}},sk_{\mathcal{E}})$ and
$(adr_{\mathcal{E}},key_{\mathcal{E}})$. Then, E publish the Attestation
Report $REP_{ias}$ of its ${\mathcal{E}}$.

####  9.1.2 Setup Cloak blockchain

The Cloak Executor deploys a CloakService ($CS$, Algorithm 1) on an existing
blockchain $BC$ to get a Cloak blockchain BC. $CS$ is constructed by the
config of $\mathcal{E}$, _e.g._ , $pk_{\mathcal{E}}$ and $adr_{\mathcal{E}}$,
so that parties can authenticate $\mathcal{E}$ by $REP_{ias}$ and build secure
channel with $\mathcal{E}$ by $pk_{\mathcal{E}}$. Moreover, $CS$ also allows
parties to call $CS.register$ to register their public keys, so that
$\mathcal{E}$ can get parties’ registered keys $pk_{i}$ to encrypt private
data by their owners’ public keys. Finally, $CS$ provides several functions to
follow $\pi_{\textsc{Cloak}}$ and manage the life cycles of MPT.

// Can be deployed to any contract-enabled blockchain

1 Function
_constructor(_$pk_{\mathcal{E}},adr_{\mathcal{E}},adr_{\textbf{{E}}}$_)_

// called by Cloak service provider

$pk_{\mathcal{E}},adr_{\mathcal{E}}\leftarrow
pk_{\mathcal{E}},adr_{\mathcal{E}}$ // for secure channel

2 $adr_{\textbf{{E}}}\leftarrow adr_{\textbf{{E}}}$

3 $Prpls\leftarrow[]$

4

5

6 Function  _register(_$pk_{i}$_)_

// called by $TX_{pk}$

7 $ParPKs[msg.sender]\leftarrow pk_{i}$

8

9 Function  _deposit(_$Q$_)_

// called by $TX_{col}$

10 $Coins[msg.sender]\leftarrow Coins[msg.sender]+Q$

11

12 Function  _propose(_$id_{p},p^{\prime},\tau_{res},\tau_{com}$_)_

// called by $TX_{p}$ from TEE, $\mathcal{E}$

13 $\textnormal{{require}}(Prpls[id_{p}]=\emptyset)$

14
$Prpls[id_{p}].\\{\mathcal{V},f,\mathbf{\bar{P}},H_{C_{x}},q,\tau_{res},\tau_{com},h_{cp}\\}\leftarrow
p^{\prime}.\\{adr_{\mathcal{V}},f,\mathbf{\bar{P}},H_{C_{x}},q\\},\tau_{res},\tau_{com},\textbf{{BC}}.\textnormal{{getHeight}}()$

// deduct collaterals before execution

15 $Coins[adr_{\textbf{{E}}}]\leftarrow
Coins[adr_{\textbf{{E}}}]-Prpls[id_{p}].q$

16 $\textnormal{{require}}(Coins[adr_{\textbf{{E}}}]\geq 0)$

17 for $P_{i}\in\mathbf{\bar{P}}$ do

18 $Coins[P_{i}]\leftarrow Coins[P_{i}]-Prpls[id_{p}].q$

19 $\textnormal{{require}}(Coins[P_{i}]\geq 0)$

20 $Prpls[id_{p}].status\leftarrow\texttt{SETTLE}$

21

22 Function  _challenge(_$id_{p},\mathbf{\bar{P}}_{M}$_)_

// called by $TX_{cha}$ from TEE, $\mathcal{E}$

23 $\textnormal{{require}}(Prpls[id_{p}].status=\texttt{SETTLE})$

24 for $P_{i}\in\mathbf{\bar{P}}_{M}$ do

25 $Prpls[id_{p}].\mathbf{\bar{P}}[P_{i}].cha\leftarrow true$

26

27

28 Function  _response(_$id_{p},Enc_{pk_{\mathcal{E}}}(in)$_)_

// called by $TX_{res}$ from parties

29 $\textnormal{{require}}(Prpls[id_{p}].status=\texttt{SETTLE})$

30 $Prpls[id_{p}].\mathbf{\bar{P}}[msg.sender].res\leftarrow
Enc_{pk_{\mathcal{E}}}(in)$

31

32

33 Function  _punish(_$id_{p},\mathbf{\bar{P}}^{\prime}_{M}$_)_

// called by $TX_{pus}$ from TEE, $\mathcal{E}$

34
$\textnormal{{require}}(\textbf{{BC}.{{getHeight}}()}>Prpls[id_{p}].h_{cp}+\tau_{res})$

35 $\textnormal{{require}}(Prpls[id_{p}].status=\texttt{SETTLE})$

36
$rfcol=Prpls[id_{p}].q*(1+\frac{|\mathbf{\bar{P}}^{\prime}_{M}|}{|Prpls[id_{p}].\mathbf{\bar{P}}-\mathbf{\bar{P}}^{\prime}_{M}|+1})$

37 for
$P_{i}\in(Prpls[id_{p}].\mathbf{\bar{P}}-\mathbf{\bar{P}}^{\prime}_{M})$ do

38 $Coins[P_{i}]\leftarrow Coins[P_{i}]+rfcol$

39 $Coins[adr_{\textbf{{E}}}]\leftarrow Coins[adr_{\textbf{{E}}}]+rfcol$

40 $Prpls[id_{p}].status\leftarrow\texttt{ABORT}$

41

42 Function  _complete(_$id_{p},proof,C_{s^{\prime}},C_{r}$_)_

// called by $TX_{com}$ from TEE, $\mathcal{E}$

43 $\textnormal{{require}}(Prpls[id_{p}].status=\texttt{SETTLE})$

44 if
$\mathcal{V}.\textnormal{{verify}}(proof,Prpls[id_{p}].C_{x},C_{s^{\prime}},C_{r})$
then

45 $\mathcal{V}.\textnormal{{setNewState}}(C_{s^{\prime}})$

46 $Prpls[id_{p}].\\{C_{r}\\}\leftarrow\\{C_{r}\\}$

47 $rfcol=Prpls[id_{p}].q$

48 for $P_{i}\in Prpls[id_{p}].\mathbf{\bar{P}}$ do

49 $Coins[P_{i}]\leftarrow Coins[P_{i}]+rfcol$

50 $Coins[adr_{\textbf{{E}}}]\leftarrow Coins[adr_{\textbf{{E}}}]+rfcol$

51 $Prpls[id_{p}].status\leftarrow\texttt{COMPLETE}$

52

53

54 Function  _timeout(_$id_{p}$_)_

// called by $TX_{out}$ from parties

55
$\textnormal{{require}}(\textbf{{BC}.{{getHeight}}()}>Prpls[id_{p}].h_{cp}+\tau_{com})$

56 $\textnormal{{require}}(Prpls[id_{p}].status=\texttt{SETTLE})$

57 $rfcol=Prpls[id_{p}].q*(1+\frac{1}{|(Prpls[id_{p}].\mathbf{\bar{P}}|})$

58 for $P_{i}\in Prpls[id_{p}].\mathbf{\bar{P}}$ do

59 $Coins[P_{i}]\leftarrow Coins[P_{i}]+rfcol$

60 $Prpls[id_{p}].status\leftarrow\texttt{TIMEOUT}$

61

Algorithm 1 Cloak service contract ($CS$)

// For setup of $\mathcal{E}$ and deployment of $\mathcal{F},\mathcal{P}$. For
simplicity, we ignore $id_{p}$ management logic

1 Function  _setup(_$\kappa,b_{cp}$_)_

$pk_{\mathcal{E}},sk_{\mathcal{E}},adr_{\mathcal{E}},key_{\mathcal{E}}\leftarrow
Gen(1^{\kappa})$ // for new $\mathcal{E}$

$\tau_{res},\tau_{com}\leftarrow Gen(1^{\kappa})$ // secure parameters for
PRT/MPT

2 return $pk_{\mathcal{E}}$

3

4 Function  _deploy(_$\mathcal{F},\mathcal{P},adr_{\mathcal{V}}$_)_

5 bind $\langle\mathcal{F},\mathcal{P},adr_{\mathcal{V}}\rangle$

6 return $adr_{\mathcal{F}}$

7

// For enforcement of PRT/MPT

8 Function  _generateIDp(_$p$_)_

9 $p\leftarrow p$

10 $id_{p}\leftarrow Gen(1^{\kappa})$

11 $status\leftarrow\texttt{GENERATEIDP}$

12 return $\langle id_{p},p\rangle$

13

14 Function  _propose(_$ACK,TX_{pk}$_)_

15 if $status\neq\texttt{GENERATEIDP}$ or $currentTime>p.t_{n}$ or
$\textnormal{{MeetPolicy}}(ACK,\mathcal{P}.\mathcal{P}_{f}.\mathbf{\bar{P}})\neq
1$ then abort

16 $p^{\prime}\leftarrow\langle
adr_{\mathcal{V}},p.f,\mathbf{\bar{P}},ACK.H_{C_{x}},p.q\rangle$

17 $status\leftarrow\texttt{SETTLE}$

18 return $TX_{p}(id_{p},p^{\prime},\tau_{res},\tau_{com})$

19

20 Function  _execute(_$in,TX_{p},PoP_{p}$_)_

21 if $status\neq\texttt{SETTLE}$ or
$\textnormal{{verifyPoP}}(b_{cp},TX_{p},PoP_{p})\neq 1$ then abort

22 $\mathbf{\bar{P}}_{M}\leftarrow\emptyset$

23 for $x_{i},r^{x}_{i},s_{i},r^{s}_{i}$ in $in.\\{x,r^{x},s,r^{s}\\}$

24 if
$\textnormal{{hash}}(\textnormal{{Enc}}_{TX^{i}_{pk}.pk_{i}}(x_{i},r^{x}_{i}))\neq
PoP_{p}.TX_{p}.H_{C_{x_{i}}}$

25 or $\textnormal{{Enc}}_{TX^{i}_{pk}.pk_{i}}(s_{i},r^{s}_{i})\neq
PoP_{p}.C_{s_{i}}$ then

26 $\mathbf{\bar{P}}_{M}\leftarrow\mathbf{\bar{P}}_{M}\cup\\{P_{i}\\}$

27 if $|\mathbf{\bar{P}}_{M}|>0$ then

28 return $\mathbf{\bar{P}}_{M}$

29 $status\leftarrow\texttt{EXECUTE}$

30 $s^{\prime},r\leftarrow$ evaluate $\mathcal{F}.f(x)$ based on $s$

31 $b_{cp}\leftarrow PoP_{p}.\textnormal{{getLastBlock}}()$

32
$C_{s^{\prime}_{i}},C_{r_{i}}\leftarrow\textnormal{{Enc}}_{pk_{i}}(s^{\prime}_{i}),\textnormal{{Enc}}_{pk_{i}}(r_{i})$

33 goto Dcomplete()

34

35 Function  _challenge(_$\mathbf{\bar{P}}_{M}$_)_

36 if $status\neq\texttt{SETTLE}$ then abort

37 if $|\mathbf{\bar{P}}_{M}|>0$ then

38 return $TX_{cha}(id_{p},\mathbf{\bar{P}}_{M})$

39

40

41 Function  _punish(_$TX_{cha},TX_{res},PoP_{res}$_)_

42 if $status\neq\texttt{SETTLE}$ or
$\textnormal{{verifyPoP}}(b_{cp},TX_{cha},PoP_{res})\neq 1$ then abort

43 $\mathbf{\bar{P}}^{\prime}_{M}\leftarrow\emptyset$

44 for $P_{i}\in\mathbf{\bar{P}}_{M}$ do

45 if $\textnormal{{verifyPoP}}(b_{cp},TX^{i}_{res},PoP_{res})\neq 1$

46 or
$\textnormal{{hash}}(\textnormal{{Enc}}_{pk_{i}}(TX^{i}_{res}.x_{i},TX^{i}_{res}.r^{x}_{i}))\neq
PoP_{res}.TX_{p}.H_{C_{x_{i}}}$

47 or
$\textnormal{{Enc}}_{pk_{i}}(TX^{i}_{res}.s_{i},TX^{i}_{res}.r^{s}_{i}))\neq
C_{s_{i}}$ then

48
$\mathbf{\bar{P}}^{\prime}_{M}\leftarrow\mathbf{\bar{P}}^{\prime}_{M}\cup\\{P_{i}\\}$

49

50 if $|\mathbf{\bar{P}}^{\prime}_{M}|>0$ then

51 $status\leftarrow\texttt{ABORT}$

52 return $TX_{pns}(id_{p},\mathbf{\bar{P}}_{M})$

53

54

55 Function  _complete(__)_

56 if $status\neq\texttt{EXECUTE}$ then abort

57
$\hat{H}_{C_{x}},\hat{H}_{C_{s}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}\leftarrow\textnormal{{hash}}(C_{x}),\textnormal{{hash}}(C_{s}),\textnormal{{hash}}(C_{s^{\prime}}),\textnormal{{hash}}(C_{r})$

58 $proof\leftarrow\langle
H_{\mathcal{F}},H_{\mathcal{P}},\hat{H}_{C_{x}},\hat{H}_{C_{s}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}\rangle$

59 $status\leftarrow\texttt{COMPLETE}$

60 return $TX_{com}(id_{p},proof,C_{s},C_{s^{\prime}},C_{r})$

61

Algorithm 2 Cloak enclave program ($\mathcal{E}$)

###  9.2 Enforcement Code Generation

####  9.2.1 Privacy policy generation

Cloak generates a privacy policy $\mathcal{P}$ for a Cloak smart contract. To
formally explain $\mathcal{P}$, we first model the privacy policy of an basic
annotated private data $d$ as $\mathcal{P}_{d}=\langle
id_{d},\tau@\alpha\rangle$, where $id_{d}$ is the identifier of $d$. We define
a complete set of all sets consisting of $\mathcal{P}_{d}$ as
$\mathcal{P}_{U}$.

$\mathcal{P}_{f}=\langle
id_{f},type_{f},\mathcal{P}_{X},\mathcal{P}_{R},\mathcal{P}_{M},\mathcal{P}_{O}\rangle$
is the privacy policy model of a function $f$, where
$type_{f}\in\\{\mathbf{PUB},\mathbf{PRT},\mathbf{MPT}\\}$, and
$\mathcal{P}_{X},\mathcal{P}_{R},\mathcal{P}_{M},\mathcal{P}_{O}\in\mathcal{P}_{U}$.
Specifically, $\mathcal{P}_{X}$ means parameter, which includes function
parameters with specified $\mathcal{P}_{d}$; read, the $\mathcal{P}_{R}$,
records the $\mathcal{P}_{d}$ of state variables that the $f$ needs for
execution; $\mathcal{P}_{M}$ means mutate, which records the $\mathcal{P}_{d}$
of state variables that the $f$ will mutate; $\mathcal{P}_{O}$, which means
return, records the $\mathcal{P}_{d}$ of all return variables.

We model the privacy policy of a Cloak smart contract $c$ as
$\mathcal{P}_{c}=\\{\mathcal{P}_{S},\mathcal{P}_{F}\\}$, where
$\mathcal{P}_{S}\in\mathcal{P}_{U}$ and $\mathcal{P}_{F}$ is a collection of
function privacy policy, _i.e._ ,
$\mathcal{P}_{F}=\\{\mathcal{P}_{f}^{i}|i=1..n\\}$. $n$ is the number of
functions in $c$. Finally, $\mathcal{P}_{c}$ is what we called $\mathcal{P}$
in our paper.

####  9.2.2 Private contract generation

To generate private contract $\mathcal{F}$, Cloak handles PUT, PRT, and MPT
transactions of a Cloak smart contract in different ways. First, Cloak deletes
all ownership annotations from the Cloak smart contract to get a pure Solidity
smart contract, which holds the computation logic of business without
considering privacy. Then, since users can send a PUT by directly interacting
with $\mathcal{V}$ on the blockchain, we delete the PUT in the contract to get
the private contract $\mathcal{F}$.

####  9.2.3 Verifier contract generation

Cloak then generates a verifier contract $\mathcal{V}$. While leaving the
computation logic of PRT and MPT in $\mathcal{F}$, Cloak generates
$\mathcal{V}$ to verify the PRT and MPT outputs and update the state.
Algorithm 3 shows the structure of $\mathcal{V}$. $\mathcal{V}$ is constructed
by the address of TEE ($adr_{\mathcal{E}}$) and hashes of
$\mathcal{P},\mathcal{F}$. When $\mathcal{E}$ seeks to complete the MPT by
calling $\textbf{{BC}}.CS.complete$, $\textbf{{BC}}.CS.complete$ will first
call $\mathcal{V}.verify$ to check the validity of state transition, then
update the state of $\mathcal{V}$ by calling $\mathcal{V}.setNewStates$.

// Generated by Cloak

1 Function  _constructor(_$config$_)_

// contract creation by developer

2 $H_{\mathcal{F}}\leftarrow config.H_{\mathcal{F}}$

3 $H_{\mathcal{P}}\leftarrow config.H_{\mathcal{P}}$

4 $adr_{\mathcal{E}}\leftarrow config.adr_{\mathcal{E}}$

5

6 Function  _getOldStates(__)_

7 $C_{s}\leftarrow\text{current state}$

8 return $C_{s}$

9

10 Function  _setNewStates(_$C_{s^{\prime}}$_)_

// indirectly called by $TX_{com}$ from CS

11 $\textnormal{{require}}(tx.origin=adr_{\mathcal{E}})$

12 $\text{current state}\leftarrow C_{s^{\prime}}$

13

14

15 Function  _verify(_$proof,C_{x},C_{s^{\prime}},C_{r}$_)_

// verify the proof of PRT/MPT

16
$\hat{H}_{C_{s}}\leftarrow\textnormal{{hash}}(\mathcal{V}.\textnormal{{getOldStates}}())$

17 if $proof=\langle
H_{\mathcal{F}},H_{\mathcal{P}},\hat{H}_{C_{x}},\hat{H}_{C_{s}},\hat{H}_{C_{s^{\prime}}},\hat{H}_{C_{r}}\rangle$
then

18 return $true$

19 return $false$

20

21

Algorithm 3 Verifier contract ($\mathcal{V}$)

###  9.3 Architecture Security

Cloak aims to enable confidential smart contracts with MPT on any contract-
enabled blockchain. Here, we analyze the architecture security of Cloak by
considering its implementation. Possible adversaries can be malicious parties
of MPT, malicious executors, or a combination of both.

We note that parties of MPT are only required to send and receive transactions
from the blockchain and exchange protocol messages with the Cloak Executor.
Hence, although we provide Cloak Client to help parties follow our protocol,
parties can also implement the Cloak Client by themselves using a diverse set
of entirely different code bases in practice, possibly using memory-safe
languages such as Go and Rust. Malicious parties are further limited to
interacting with Cloak Executor to proceed protocol, hence, we focus on the
Cloak Executor in the following.

To prevent malicious Cloak Executor from departing the protocol, we assume
that the goal of a malicious Cloak Executor is to exploit the enclave program
at runtime. Enclaves have well-defined program interfaces and any attack has
to be launched using these interfaces. A malicious Cloak Executor can provide
fake data through these interfaces to try to exploit a memory-corruption
vulnerability in the low-level enclave code to launch (a) a code-reuse attack,
_e.g._ , by manipulating enclave stack memory, or (b) a data-only attack,
_e.g._ , to leak information about private data of an MPT. For (a) we assume a
standard code-reuse defense such as control-flow integrity or fine-grained
code randomization. For (b) we stress that the vulnerability leading to data
leakages has been fixed. Although we prototype Cloak Executor in C++, we note
that it’s easy to tackle both attack vectors by using memory-safety languages,
such as Python and Rust.

###  9.4 Discussion

Expanding annotations to meet real-world need. In current syntax, the owner of
private data is allowed to be {$\mathbf{tee}$, $\mathbf{me}$, $\mathbf{id}$},
each of which limits the owner to a specific account. However, in the real
world, the owner could be a group or committee, which may have dynamic
members. We can definitely expand the ownership annotation system to support
special owners. It’s also possible to allow an owner to transfer his ownership
to others, for which the Cloak can match the plaintext secret with on-chain
ciphertext, encrypt the secret with transferee’s public key and record the
ownership transfer event on-chain.

Expanding to multi-party privacy-preserved computation. Although we take
Solidity as a front-end language to express private data and computation logic
of MPT, the insight behind Cloak is essentially agnostic to language or
computation. Currently, Cloak allows users to annotate the data owner at where
it was defined. While it benefits developers a lot in the intuitive expression
of privacy requirements, it also limits the expression ability to the language
Cloak based. We note that for large data or complex data structures which are
not suitable to be stored on-chain, Cloak can allow a developer to annotate
the inputs’ commitments, such as inputs hash, so that no matter what’s the
data structure or where the data is stored, it can be identified and used as
inputs to the MPT. As for more complex computation, a developer can just bind
the code commitment (_e.g._ , code hash) on-chain, so that the code expressing
complex computation logic (_e.g._ , AI training) by any language can be
identified by the commitment and executed in TEEs.

Toward low-cost layer-2 solutions. For simplicity, in this paper, we indicate
that each MPT executed by Cloak Executor needs 2 transactions for committing
MPT settings, inputs, and the MPT results on-chain. Consequently, the gas cost
of an MPT only depends on how many parties it involved and state variables it
write. While Cloak has guaranteed advanced security of MPT, its gas cost can
be further reduced. For example, the more parties involved in an MPT, the
lower gas an $TX_{p}$ costs against previous $O(n)$ solutions. Moreover, Cloak
Executor can cache many state transitions in TEE and only update the final new
states to amortize the gas cost of a single MPT. We can also develop more
computation-intensive MPT so that Cloak can better take advantages of off-
chain execution of MPT and thus relatively reduce its on-chain cost.

Limitations of current implementation. For proof of concept, we have not
supported all the Solidity features, _e.g._ , return statement in the middle
of the function body, annotation cross contract or library. These limits
mainly affect the development experience of developers. Developers have to
develop under limited language features or modify the audited legacy code to
meet Cloak smart contract. We note that the limits do not reduce the
scientific advantage of our design and the effectiveness of our experiment.