HyperService: Interoperability and Programmability

Across Heterogeneous Blockchains∗

Zhuotao Liu1,2 Yangxi Xiang3 Jian Shi4 Peng Gao5 Haoyu Wang3
Xusheng Xiao4,2 Bihan Wen6 Yih-Chun Hu1,2
1 University of Illinois at Urbana-Champaign 2 HyperService Consortium
3 Beijing University of Posts and Telecommunications 4 Case Western Reserve University
5 University of California, Berkeley 6 Nanyang Technological University

[email protected]

ABSTRACT
arXiv:1908.09343v3 [cs.CR] 4 Sep 2019

As a result, in today’s blockchain ecosystem, we see many dis-

Blockchain interoperability, which allows state transitions across tinct blockchains, falling roughly into the categories of public, pri-
different blockchain networks, is critical functionality to facili- vate, and consortium blockchains [6]. In a world deluged with iso-
tate major blockchain adoption. Existing interoperability protocols lated blockchains, interoperability is power. Blockchain interoper-
mostly focus on atomic token exchange between blockchains. How- ability enables secure state transitions across different blockchains,
ever, as blockchains have been upgraded from passive distributed which is invaluable for connecting the decentralized Web 3.0 [26].
ledgers into programmable state machines (thanks to smart con- Existing interoperability proposals [21, 36, 38, 62] mostly center
tracts), the scope of blockchain interoperability goes beyond just around atomic token exchange between two blockchains, aim-
token exchange. In this paper, we present HyperService, the first ing to eliminate the requirement of centralized exchanges. How-
platform that delivers interoperability and programmability across ever, since smart contracts executing on blockchains have trans-
heterogeneous blockchains. HyperService is powered by two inno- formed blockchains from append-only distributed ledgers into pro-
vative designs: (i) a developer-facing programming framework that grammable state machines, we argue that token exchange is not the
allows developers to build cross-chain applications in a unified pro- complete scope of blockchain interoperability. Instead, blockchain
gramming model; and (ii) a secure blockchain-facing cryptography interoperability is complete only with programmability, allowing
protocol that provably realizes those applications on blockchains. developers to write decentralized applications executable across
We implement a prototype of HyperService in approximately 35,000 those disconnected state machines.
lines of code to demonstrate its practicality. Our experiment results We recognize at least two categories of challenges for simul-
show that (i) HyperService imposes reasonable latency, in order taneously delivering programmability and interoperability. First,
of seconds, on the end-to-end execution of cross-chain applica- the programming model of cross-chain decentralized applications
tions; (ii) the HyperService platform is scalable to continuously (or dApps) is unclear. In general, from developers’ perspective,
incorporate additional production blockchains. it is desirable that cross-chain dApps could preserve the same
state-machine-based programming abstraction as single-chain con-
CCS CONCEPTS tracts [60]. This, however, raises a virtualization challenge to ab-
stract away the heterogeneity of smart contracts and accounts on
• Security and privacy → Distributed systems security; Secu-
different blockchains so that the interactions and operations among
rity protocols.
those contracts and accounts can be uniformly specified when writ-
KEYWORDS ing cross-chain dApps.
Second, existing token-exchange oriented interoperability proto-
Blockchain Interoperability; Smart Contract; Cross-chain dApps cols, such as atomic cross-chain swaps (ACCS) [5], are not generic
enough to realize cross-chain dApps. This is because the “executa-
1 INTRODUCTION
bles” of those dApps could contain more complex operations than
Over the last few years, we have witnessed rapid growth of sev- token transfers. For instance, our example dApp in § 2.3 invokes
eral flagship blockchain applications, such as the payment system a smart contract using parameters obtained from smart contracts
Bitcoin [54] and the smart contract platform Ethereum [27]. Since deployed on different blockchains. The complexity of this opera-
then, considerable effort has been made to improve the perfor- tion is far beyond mere token transfers. In addition, the executa-
mance and security of individual blockchains, such as more effi- bles of cross-chain dApps often contain transactions on different
cient consensus algorithms [3, 8, 32, 43], improving transaction blockchains, and the correctness of dApps requires those trans-
rate by sharding [20, 44, 52, 61] and payment channels [37, 40, 53], actions to be executed with certain preconditions and deadline
enhancing the privacy for smart contracts [29, 39, 45], and reducing constraints. Another technical challenge is to securely coordinate
their vulnerabilities via program analysis [24, 46, 51]. those transactions to enforce dApp correctness in a fully decentral-
∗ This is an extended version of the material originally published in ACM CCS 2019. ized manner with zero trust assumptions.
To meet these challenges, we propose HyperService, the first
platform for building and executing dApps across heterogeneous
blockchains. At a very high level, HyperService is powered by two
innovative designs: a developer-facing programming framework for
 HSL HSL HSL
Client VES
Program Program Program A.1 HSL Program Network Status Blockchain
(NSB)
Client VES
dApp
Clients Universal State Model Action
A.2 Executable Graph Action PoA
PoA
BN A BN B … BN Z T1 T2
HyperService …
… Security Security
Client VES
Attestations Attestations
HSL Executables Zoom-In T3 T4 State Channel

VESes A.3 Insurance Smart Contract B.1 Post T1

B.4 T4
if CorrectExecution: B.2 Post T3
Cross-chain Execution Reachability Pay service fee B.3 T2
else:
Revert effective fund NSB or any mutual-agreed BN
Blockchain BN A BN B … BN Z Enforce accountability BN A BN B BN C
Networks
Overall Architecture Phase A. HSL Program Compilation Phase B. Cross-Chain Execution Phase C. Insurance Claim

Figure 1: The architecture of HyperService.

writing cross-chain dApps, and a blockchain-facing cryptography 2 HYPERSERVICE OVERVIEW

protocol to securely realize those dApps on blockchains. Within this
2.1 Architecture
programming framework, we propose Unified State Model (USM),
a blockchain-neutral and extensible model to describe cross-chain As depicted in Figure 1, architecturally, HyperService consists of
dApps, and the HSL, a high-level programming language to write four components. (i) dApp Clients are the gateways for dApps to
cross-chain dApps under the USM programming model. dApps interact with the HyperService platform. When designing HyperSer-
written in HSL are further compiled into HyperService executables vice, we intentionally make clients to be lightweight, allowing both
which shall be executed by the underlying cryptography protocol. mobile and web applications to interact with HyperService. (ii) Ver-
UIP (short for universal inter-blockchain protocol) is the cryptog- ifiable Execution Systems (VESes) conceptually work as blockchain
raphy protocol that handles the complexity of cross-chain execution. drivers that compile the high-level dApp programs given by the
UIP is (i) generic, operating on any blockchain with a public trans- dApp clients into blockchain-executable transactions, which are
action ledger, (ii) secure, the executions of dApps either finish with the runtime executables on HyperService. VESes and dApp clients
verifiable correctness or abort due to security violations, where mis- employ the underlying UIP cryptography protocol to securely exe-
behaving parties are held accountable, and (iii) financially atomic, cute those transactions across different blockchains. UIP itself has
meaning all involved parties experience almost zero financial losses, two building blocks: (iii) the Network Status Blockchain (NSB) and
regardless of the execution status of dApps. UIP is fully trust-free, (iv) the Insurance Smart Contracts (ISCs). The NSB, conceptually,
assuming no trusted entities. is a blockchain of blockchains designed by HyperService to provide
an objective and unified view of the dApps’ execution status, based
Contributions. To the best of our knowledge, HyperService is
on which the ISCs arbitrate the correctness or violation of dApp
the first platform that simultaneously offers interoperability and
executions in a trust-free manner. In case of exceptions, the ISCs
programmability across heterogeneous blockchains. Specifically, we
financially revert all executed transactions to guarantee financial
make the following major contributions in this paper.
atomicity and hold misbehaved entities accountable.
(i) We propose the first programming framework for develop-
ing cross-chain dApps. The framework greatly facilitates dApp
2.2 Universal State Model
development by providing a virtualization layer on top of the un-
derlying heterogeneous blockchains, yielding a unified model and A blockchain, together with smart contracts (or dApps) executed
a high-level language to describe and program dApps. Using our on the blockchain, is often perceived as a state machine [60]. We
framework, a developer can easily write cross-chain dApps without desire to preserve the similar abstraction for developers when writ-
implementing any cryptography. ing cross-chain dApps. Towards this end, we propose Unified State
(ii) We propose UIP, the first generic blockchain interoperabil- Model (USM), a blockchain-neutral and extensible model for de-
ity protocol whose design scope goes beyond cross-chain token scribing state transitions across different blockchains, which in
exchanges. Rather, UIP is capable of securely realizing complex essential defines cross-chain dApps. USM realizes a virtualization
cross-chain operations that involve smart contracts deployed on layer to unify the underlying heterogeneous blockchains. Such
heterogeneous blockchains. We express the security properties of virtualization includes: (i) blockchains, regardless of their imple-
UIP via an ideal functionality FUIP and rigorously prove that UIP mentations (e.g., consensus mechanisms, smart contract execution
realizes FUIP in the Universal Composability (UC) framework [28]. environment, programming languages, and so on), are abstracted
(iii) We implement a prototype of HyperService in approximately as objects with public state variables and functions; (ii) developers
35,000 lines of code, and evaluate the prototype with three cate- program dApps by specifying desired operations over those objects,
gories of cross-chain dApps. Our experiments show that the end-to- along with the relative ordering among those operations, as if all
end dApp execution latency imposed by HyperService is in the order the objects were local to a single machine.
of seconds, and the HyperService platform has sufficient capacity Formally, USM is defined as M = {E, P, C} where E is a set
to continuously incorporate new production blockchains. of entities, P is a set of operations performed over those entities,
and C is a set of constraints defining the dependencies of those
operations. Entities are to describe the objects abstracted from
 Table 1: Example of entities, operations and dependencies in USM
Entity Kind Attributes Operation Kind Attributes Dependency Kind
account address, balance, unit payment from, to, value, exchange rate precondition
contract address, state variables[], interfaces[], source invocation interface, parameters[const, Contract.SV, ...], invoker deadline

blockchains. All entities are conceptually local to M, regardless 1 # Import the source code of contracts written in different languages.
of which blockchains they are obtained from. Entities come with 2 import (“broker.sol”, “option.vy”, “option.go”)
kinds, and each entity kind has different attributes. The current 3 # Entity definition.
version of USM defines two concrete kinds of entities, accounts 4 # Attributes of a contract entity are implicit from its source code.
and contracts, as tabulated in Table 1 (we discuss the extensions of 5 account a1 = ChainX ::Account(0x7019..., 100, xcoin)
USM in § 6.1). Specifically, an account entity is associated with a 6 account a2 = ChainY ::Account(0x47a1..., 0, ycoin)
uniquely identifiable address, as well as its balance in certain units. 7 account a3 = ChainZ ::Account(0x61a2..., 50, zcoin)
A contract entity, besides its address, is further associated with a 8 contract c1 = ChainX ::Broker(0xbba7...)
list of public attributes, such as state variables, callable interfaces, 9 contract c2 = ChainY ::Option(0x917f...)
and its source code deployed on blockchains. Entity attributes are 10 contract c3 = ChainZ ::Option(0xefed...)
crucial to enforce the security and correctness of dApps during 11 # Operation definition.
compilation, as discussed in § 2.3. 12 op op1 invocation c1.GetStrikePrice() using a1
An operation in USM defines a step of computation performed 13 op op2 payment 50 xcoin from a1 to a2 with 1 xcoin as 0.5 ycoin
over several entities. Table 1 lists two kinds of operations in USM: a 14 op op3 invocation c2.CashSettle(10, c1.StrikePrice) using a2
payment operation that describes the balance updates between two 15 op op4 invocation c3.CashSettle(5, c1.StrikePrice) using a3
account entities at a certain exchange rate; an invocation operation 16 # Dependency definition.
that describes the execution of a method specified by the interface 17 op1 before op2, op4; op3 after op2
of a contract entity using compatible parameters, whose values 18 op1 deadline 10 blocks; op2, op3 deadline default; op4 deadline 20 mins
may be obtained from other contract entities’ state variables.
Figure 2: A cross-chain Option dApp written in HSL.
Although operations are conceptually local, each operation is
eventually compiled into one or more transactions on different
blockchains, whose consensus processes are not synchronized. To turn, prevents dApps from spreading their business across multi-
honor the possible dependencies among events in distributed com- ple blockchains. For instance, a call-option contract deployed on
puting [47], USM, therefore, defines constraints to specify depen- Ethereum forces investors to exercise the option using Ether, but
dencies among operations. Currently, USM supports two kinds of not in other cryptocurrencies.
dependencies: preconditions and deadlines, where an operation can As an introductory example, we shall see how conceptually
proceed only if all its preconditioning operations are finished, and simple, yet elegant, it is, from developers’ perspective, to build a
an operation must be finished within a bounded time interval after universal call-option dApp that allows investors to natively exer-
its dependencies are satisfied. Preconditions and deadlines offer cise options with the cryptocurrencies they prefer. The code snip-
desirable programming abstraction for dApps: (i) preconditions en- pet shown in Figure 2 is the HSL implementation for the referred
able developers to organize their operations into a directed acyclic dApp. In this dApp, both Option contracts deployed on blockchains
graph, where the state of upstream nodes is persistent and can be ChainY and ChainZ rely on the same Broker contract on ChainX to
used by downstream nodes; (ii) deadlines are crucial to ensure the provide the genuine strike price (lines 14 and 15 in Figure 2). Detailed
forward progress of dApp executions. HSL grammar is given in Grammar 1.

2.3 HyperService Programming Language 2.3.2 HSL Program Compilation

To demonstrate the usage of USM, we develop HSL, a programming The core of HyperService programming framework is the HSL
language to write cross-chain dApps under USM. compiler. The compiler performs two major tasks: (i) enforcing
security and correctness checks on HSL programs and (ii) compiling
2.3.1 An Introductory Example for HSL Programs HSL programs into blockchain-executable transactions.
Financial derivatives are among the most commonly cited blockchain One of the key differentiations of HyperService is that it al-
applications. Many financial derivatives rely on authentic data feed, lows dApps to natively define interactions and operations among
i.e., an oracle, as inputs. For instance, a standard call-option contract smart contracts deployed on heterogeneous blockchains. Since
needs a genuine strike price. Existing oracles [13, 63] require a smart these smart contracts could be written in different languages, HSL
contract on the blockchain to serve as the front-end to interact with provides a multi-language front end to analyze the source code
other client smart contracts. As a result, it is difficult to build a of those smart contracts. It extracts the type information of their
dependable and unbiased oracle that is simultaneously accessible to public state variables and functions, and then converts them into
multiple blockchains, because we cannot simply deploy an oracle the unified types defined by HSL (§ 3.1). This enables effective cor-
smart contract on each individual blockchain since synchronizing rectness checks on the HSL programs (§ 3.3). For instance, it ensures
the execution of those oracle contracts requires blockchain interop- that all the parameters used in a contract invocation operation are
erability, i.e., we see a chicken-and-egg problem. This limitation, in compatible and verifiable, even if these arguments are extracted
from remote contracts written in languages different from that of takes transaction-status proofs constructed from the NSB as input
the invoking contract. to determine the correctness or violation of dApp executions, and
Once a HSL program passes the syntax and correctness checks, meanwhile uses action proofs to determine the accountable parities
the compiler will generate an executable for the program. The ex- in case of exceptions.
ecutable is structured in the form of a Transaction Dependency In § 4.6, we define the security properties of UIP via an ideal
Graph, which contains (i) the complete information for computing a functionality and then rigorously prove that UIP realizes the ideal
set of blockchain-executable transactions, (ii) the metadata of each functionality in UC-framework [28].
transaction needed for correct execution, and (iii) the preconditions
and deadlines of those transactions that honor the dependency 2.5 Assumptions and Threat Model
constraints specified in the HSL program (§ 3.4). We assume that the cryptographic primitives and the consensus pro-
In HyperService, the Verifiable Execution Systems (VESes) are tocol of all underlying blockchains are secure so that each of them
the actual entities that own the HSL compiler and therefore re- can have the concept of transaction finality. On Nakamoto consen-
sume the aforementioned compiler responsibilities. Because of this, sus based blockchains (typically permissionless), this is achieved by
VESes work as blockchain drivers that bridge our high-level pro- assuming that the probability of blockchain reorganizations drops
gramming framework with the underlying blockchains. Each VES exponentially as new blocks are appended (common-prefix prop-
is a distributed system providing trust-free service to compile and erty) [35]. On Byzantine tolerance based blockchains (usually per-
execute HSL programs given by dApp clients. VESes are trust-free missioned), finality is guaranteed by signatures from a quorum of
because their actions taken during dApp executions are verifiable. permissioned voting nodes. For a blockchain, if the NSB-proposed
Each VES defines its own service model, including its reachabil- definition of transaction finality for the blockchain is accepted by
ity (i.e., the set of blockchains that the VES supports), service fees users and dApps on HyperService, the operation (or trust) model
charged for correct executions, and insurance plans (i.e., the ex- (e.g., permissionless or permissioned) and consensus efficiency (i.e.,
pected compensation to dApps if the VES’s execution is proven to the latency for a transaction to become final) of the blockchain
be incorrect). dApps have full autonomy to select VESes that satisfy have provably no impact on the security guarantees of our UIP
their requirements. In § 6.3, we lay out our visions for VESes. protocol. We also assume that each underlying blockchain has a
Besides owning the HSL compiler, VESes also participate in the public ledger that allows external parties to examine and prove
actual executions of HSL executables, as discussed below. transaction finality and the public state of smart contracts.
The correctness of UIP relies on the correctness of the NSB.
2.4 Universal Inter-Blockchain Protocol (UIP) An example implementation of NSB is a permissioned blockchain,
To correctly execute a dApp, all the transactions in its executable where any information on NSB becomes legitimate only if a quo-
must be posted on blockchains for execution, and meanwhile their rum of consensus nodes that maintain the NSB have approved the
preconditions and deadlines are honored. Although this executing information. We thus assume that at least K consensus nodes of
procedure is conceptually simple (thanks to the HSL abstraction), the NSB are honest, where K is the quorum threshold (e.g., the
it is very challenging to enforce correct executions in a fully trust- majority). In this design, an NSB node is not required to become
free manner where (i) no trusted authority is allowed to coordinate either a full or light node for any of the underlying blockchains.
the executions on different blockchains and (ii) no mutual trust We consider a Byzantine adversary that interferes with our UIP
between VESes and dApp clients are established. protocol arbitrarily, including delaying and reordering network
To address this challenge, HyperService designs UIP, a cryptog- messages indefinitely, and compromising protocol participants. As
raphy protocol between VESes and dApp clients to securely execute long as at least one protocol participant is not compromised by the
HSL executables on blockchains. UIP can work on any blockchain adversary, the security properties of UIP are guaranteed.
with public ledgers, imposing no additional requirements such as
their consensus protocols and contract execution environment. UIP 3 PROGRAMMING FRAMEWORK
provides strong security guarantees for executing dApps such that The design of the HyperService programming framework centers
dApps are correctly executed only if the correctness is publicly ver- around the HSL compiler. Figure 3 depicts the compilation work-
ifiable by all stakeholders; otherwise, UIP holds the misbehaving flow. The HSL compiler has two frond-ends: one for extracting
parties accountable, and financially reverts all committed transac- entities, operations, and dependencies from a HSL program and
tions to achieve financial atomicity. one for extracting public state variables and methods from smart
UIP is powered by two innovative designs: the Network Status contracts deployed on blockchains. A unified type system is de-
Blockchain (NSB) and the Insurance Smart Contract (ISC). The NSB signed to ensure that smart contracts written in different languages
is a blockchain designed by HyperService to provide objective and can be abstracted as interoperable entities defined in the HSL pro-
unified views on the status of dApp executions. On the one hand, gram. Afterwards, the compiler performs semantic validations on
the NSB consolidates the finalized transactions of all underlying all entities, operations and dependencies to ensure the security and
blockchains into Merkle trees, providing unified representations for correctness of the HSL program. Finally, the compiler produces an
transaction status in form of verifiable Merkle proofs. On the other executable for the HSL program, which is structured in the form
hand, the NSB supports Proofs of Actions (PoAs), allowing both of a transaction dependency graph. We next describe the details of
dApp clients and VESes to construct proofs to certify their actions each component.
taken during cross-chain executions. The ISC is a code-arbitrator. It
 Table 2: Unified type mapping for Solidity, Vyper, and Go
Solidity Vyper Go HSL
Contract Contract Contract … Program
Type
Boolean
Solidity
bool
Vyper
bool
Go
bool
Numeric int, uint int128, uint256, deci- int, uint, uintptr, float
mal, unit type
Address address address string
HSL Front Ends String string string string
Multi-language HSL Array array, bytes array, bytes array, slice
Front-End Front-End Map mapping map map
Struct struct struct struct
Function function, enum def func
Contract Contract file type
Unified Types Entities Operations Dependencies

⟨hsl ⟩ ::= ( ⟨import ⟩ )+ ( ⟨entity_def ⟩ )+ ( ⟨op_def ⟩ )+ ( ⟨dep_def ⟩ )*

HSL Validation and Compilation
Contract Imports:
⟨import ⟩ ::= ‘import’ ‘(’ ⟨file ⟩ (‘,’ ⟨file ⟩ )* ‘)’
Entity Operation Dependency Transaction ⟨file ⟩ ::= ⟨string ⟩
Validation Validation Validation Compilation Entity Definition:
⟨entity_def ⟩ ::= ⟨entity_type ⟩ ⟨entity_name ⟩ ‘=’ ⟨chain_name ⟩ ‘::’
⟨constructor ⟩
⟨entity_name ⟩ ::= ⟨id ⟩
Transaction Dependency Graph ⟨chain_name ⟩ ::= ‘Chain’ ⟨id ⟩
⟨constructor ⟩ ::= ⟨contract_type ⟩ ‘(’ ⟨address ⟩ , ( ⟨unit ⟩ )? ‘)’
Figure 3: Workflow of HSL compilation. ⟨contract_type ⟩ ::= ‘Account’ | ⟨id ⟩
⟨entity_type ⟩ ::= ‘account’ | ‘contract’
Operation Definition:
3.1 Unified Type System ⟨op_def ⟩ ::= ⟨op_payment ⟩ | ⟨op_invocation ⟩
⟨op_payment ⟩ ::= ‘op’ ⟨op_name ⟩ ‘payment’ ⟨coin ⟩ ⟨accts ⟩ ⟨exchange ⟩
⟨op_name ⟩ ::= ⟨id ⟩
The USM is designed to provide a unified virtualization layer for ⟨coin ⟩ ::= ⟨num ⟩ ⟨unit ⟩
⟨accts ⟩ ::= ‘from’ ⟨acct ⟩ ‘to’ ⟨acct ⟩
developers to define invocation operations in their HSL programs, ⟨acct ⟩ ::= ⟨id ⟩
⟨exchange ⟩ ::= ‘with’ ⟨coin ⟩ ‘as’ ⟨coin ⟩
without handling the heterogeneity of contract entities. Towards ⟨op_invocation ⟩ ::= ‘op’ ⟨op_name ⟩ ‘invocation’ ⟨call ⟩ ‘using’ ⟨acct ⟩
this end, the programming framework internally defines a Unified ⟨call ⟩ ::= ⟨recv ⟩ ‘.’ ⟨method ⟩ ‘(’ (arg)*‘)’
⟨arg ⟩ ::= ⟨int ⟩ | ⟨float ⟩ | ⟨string ⟩ | ⟨state_var ⟩
Type System so that state variables and methods of all contract ⟨state_var ⟩ ::= ⟨varname ⟩ ‘.’ ⟨prop ⟩
entities can be abstracted using the unified types when writing HSL Dependency Definition:
⟨dep_def ⟩ ::= ⟨temp_deps ⟩ | ⟨del_deps ⟩
programs. This enables the HSL compiler to ensure that all argu- ⟨temp_deps ⟩ ::= ⟨temp_dep ⟩ (‘;’ ⟨temp_dep ⟩ )*
ments specified in an invocation operation are compatible (§ 3.3). ⟨temp_dep ⟩ ::= ⟨op_name ⟩ (‘before’ | ‘after’) ⟨op_name ⟩ (‘,’
⟨op_name ⟩ )*
Specifically, the unified type system defines nine elementary ⟨del_deps ⟩ ::= ⟨del_dep ⟩ (‘;’ ⟨del_dep ⟩ )*
⟨del_dep ⟩ ::= ⟨op_name ⟩ (‘,’ ⟨op_name ⟩ )* ‘deadline’ ⟨del_spec ⟩
types, as shown in Table 2. Data types that are commonly used in ⟨del_spec ⟩ ::= ⟨int ⟩ ‘blocks’| ‘default’ | ⟨int ⟩ ⟨time_unit ⟩
smart contract programming languages will be mapped to these uni-
fied types during compilation. For example, Solidity does not fully Grammar 1: Representative BNF grammar of HSL
support fixed-point number, but Vyper (decimal) and Go (f loat)
do. Also, Vyper’s string is fixed-sized (declared via string[Inteдer ]), discussed below. Grammar 1 shows the representative rules of HSL.
but Solidity’s string is dynamically-sized (declared as string). Our We omit the terminal symbols such as ⟨id⟩ and ⟨address⟩.
multi-lang front-end recognizes these differences and performs Contract Importing. Developers use the ⟨import⟩ rule to include
type conversion to map all the numeric literals including integers the source code of contract entities. Depending on the program-
and decimals to the Numeric type, and the strings to the Strinд ming language of an imported contract, HSL’s multi-lang front end
type. For types that are similar in Solidity, Vyper, and Go, such uses the corresponding parser to parse the source code, based on
as Boolean, Map, and Struct, we simply map them to the corre- which it performs semantic validation (§ 3.3). For security purpose,
sponding types in our unified type system. Finally, Solidity and the compiler should verify that the imported source code is consis-
Vyper provide special types for representing contract addresses, tent with the actual deployed code on blockchain, for instance, by
which are mapped to the Address type. But Go does not provide a comparing their compiled byte code.
type for contract addresses, and thus Go’s Strinд type is mapped
Entity Definition. The ⟨entity_def⟩ rule specifies the definition of
to the Address type. The mapping of language-specific types to
an account or a contract entity. An entity is defined via constructor,
the unified type system is tabulated in Table 2. Our unified type
where the on-chain (⟨address⟩) of the entity is a required parameter.
system is horizontally scalable to support additional strong-typed
An account entity can be initialized with an optional unit (⟨unit⟩) to
programming languages. Note that the use of complex data types
specify the cryptocurrency held by the account. All contract entities
as contract function parameters has not been fully supported yet
must have the corresponding contract objects/classes in one of the
in production. We thus leave complex types in HSL to future work.
imported source code files. Each entity is assigned with a name
3.2 HSL Language Design (⟨entity_name⟩) that can be used for defining operations.
The language constructs provided by HSL are coherent with USM, Operation Definition. The ⟨op_def⟩ rule specifies the definition
allowing developers to straightforwardly specify entities, opera- of a payment or an invocation operation. A payment operation
tions, and dependencies in HSL programs. One additional construct, (⟨op_payment⟩) specifies the transfer of a certain amount of coins
import, is added to import the source code of contract entities, as (⟨coin⟩) between two accounts that may live on different blockchains
(⟨accts⟩). Note that no new coins on any blockchains are ever cre- Transaction T1 on ChainX:
Transaction T2 on ChainX:
ated during the operation. The ⟨exchange⟩ rule is used to specify from: a1.address
from: a1.address
to: c1.address
the exchange rate between the coins held by the two accounts. An to: VES.relayX.address
Meta:
Meta:
invocation operation (⟨op_invocation⟩) specifies calling one contract data: c1.getStrikePrice
value: 50 xcoin
<amt, dst>: <0.1 ncoin, 0x1…>
entity’s public method with certain arguments (⟨call⟩). The argu- <amt, dst>: <25 ncoin, 0x2…>
state_proof: collect from NSB
deadline: 4 NSB blocks
ments passed to a method invocation can be literals (⟨int⟩, ⟨float⟩,
⟨string⟩), and state variables (⟨state_var⟩) of other contract entities.
Transaction T5 on ChainZ
When using state variables, semantic validation is required (§ 3.3). Transaction T3 on ChainY:
Dependency Definition. The ⟨dep_def⟩ specifies the rule of defin- from: VES.relayY.address
Transaction T4 on ChainY: to: a2.address
ing preconditions and deadlines for operations. A precondition from: a2.address Meta:
(⟨temp_deps⟩) specifies the temporal constraints for the execution to: c2.address value: 25 ycoin
Meta: <amt, dst>: <5 ncoin, 0x3…>
order of operations. A deadline (⟨del_deps⟩) specifies the deadline data: c2.CashSettle(10, c1.StrikePrice) deadline: 6 NSB blocks
constraints of each operation. The deadline dependency may be <amt, dst>: <0.1 ncoin, 0x4…>
value_proof: T1.meta.state_proof
given either using the number of blocks on NSB (⟨int⟩ blocks) or
in absolute time (⟨int⟩ ⟨time_unit⟩), as explained in § 3.4. Figure 4: GT generated for the example HSL program.

3.3 Semantic Validation

explicitly paid value in T , as well as any gas fee. If the entire execu-
The compiler performs two types of semantic validation to ensure tion fails with exceptions whereas T is committed, the dst account
the security and correctness of HSL programs. First, the compiler is guaranteed to receive the amount of fund specified in amt. As
guarantees the compatibility and verifiability of the arguments used we shall see in § 4.4, the fund reversion is handled by the Insurance
in invocation operations, especially when those arguments are ob- Smart Contract (ISC). Therefore, the unit of amt (represented as
tained from other contract entities. For compatibility check, the ncoin in Figure 4) is given based on the cryptocurrency used by the
compiler performs type checking to ensure the types of arguments blockchain where the ISC is deployed, and the dst should live on
and the types of method parameters are mapped to the same uni- the hosting blockchain as well.
fied type. For verifiability check, the compiler ensures that only Second, for a transaction (such as T1) whose resulting state is
literals and state variables that are publicly stored on blockchains subsequently used by other downstream transactions (such as T4),
are eligible to be used as arguments in invocation operations. For its meta needs to be populated with a corresponding state proof.
example, the return values of method calls to a contract entity are This proof should be collected from the transaction’s destination
not eligible if these results are not persistent on blockchains. This blockchain after the transaction is finalized (c.f., § 4.2.3). Third,
requirement is necessary for the UIP protocol to construct pub- a cross-chain payment operation in the HSL program results in
licly verifiable attestations to prove that correct values are used to multiple transactions in GT . For instance, to realize the op1 in
invoking contracts during actual on-chain execution. Second, the Figure 2, two individual transactions, involving the relay accounts
compiler performs dependency validation to make sure that the owned by the VES, are generated. As blockchain drivers, each VES
dependency constraints defined in a HSL program uniquely specify is supposed to own some accounts on all blockchains that it has
a directed acyclic graph connecting all operations. This ensures visibility so that the VES is able to send and receive transactions on
that no conflicting temporal constraints are specified. those blockchains. For instance, in Figure 4, the relayX and relayY
are two accounts used by the VES to bridge the balance updates
3.4 HSL Program Executables between ChainX::a1 and ChainY::a2. Because of those VES-owned
Once a HSL program passes all validations, the HSL compiler gen- accounts, GT is in general VES-specific.
erates executables for the program in form of a transaction depen- Finally, the deadlines of transactions could be specified using
dency graph GT . Each vertex of GT , referred to as a transaction the number of blocks on the NSB. This is because the NSB con-
wrapper, contains the complete information to compute an on-chain structs a unified view of the status of all underlying blockchains
transaction executable on a specific blockchain, as well as additional and therefore can measure the execution time of each transaction.
metadata for the transaction. The edges in GT define the precon- Specifically, the deadline of a transaction T is measured as the
ditioning requirements among transactions, which are consistent number of blocks between two NSB blocks B1 and B2 (including
with the dependency constraints specified by the HSL program. B2 ), where B1 proves the finalization of T ’s last preconditioned
Figure 4 show the GT generated for the HSL program in Figure 2. transaction and B2 proves the finalization of T itself. We explain in
A transaction wrapper is in form of T := [from, to, seq, meta], detail how the finality proof is constructed based on NSB blocks in
where the pair <from, to> decides the sending and receiving ad- § 4.2.2. Transaction deadlines are indeed enforced by the ISC using
dresses of the on-chain transaction, seq (omitted in Figure 4) rep- the number of NSB blocks. Note that to improve expressiveness,
resents the sequence number of T in GT , and meta stores the the HSL language also allows developers to define deadlines in time
structured and customizable metadata for T . Below we explain intervals (e.g., minutes). The compiler will then convert those time
the fields of meta. First, to achieve financial atomicity, meta must intervals into numbers of NSB blocks.
populate a tuple ⟨amt, dst⟩ for fund reversion. In particular, amt In summary, the executable produced by the HSL complier de-
specifies the total value that the from address has to spend when T fines the blueprint of cross-blockchain execution to realize the HSL
is committed on its destination blockchain, which includes both the
program. It is the input instructions that direct the underlying PrevHash Block Number: N Hash Block Number: N + 1

cryptography protocol UIP, as detailed below. ActionRoot CommonRoots StatusRoot ActionRoot … StatusRoot

4 UIP DESIGN DETAIL

UIP is the cryptography protocol that executes HSL program exe-
Blockchain X Blockchain X
cutables. The main protocol ProtUIP is divided into five preliminary
BlockID: 2012 BlockID: 2019
protocols. In particular, ProtVES and ProtCLI define the execution StateRoot: 0x1… StateRoot: 0x2…
protocols implemented by VESes and dApp clients, respectively. Cert(a) Cert(z)
TxRoot: 0xf… TxRoot: 0xe…

ProtNSB and ProtISC are the protocol realization of the NSB and Figure 5: The architecture of NSB blocks.
ISC, respectively. Lastly, ProtUIP includes ProtBC , the protocol real-
ization of a general-purposed blockchain. Overall, ProtUIP has two
phases: the execution phase where the transactions specified in the support the extra functionality of the NSB, an NSB block contains
HSL executables are posted on blockchains and the insurance claim two additional Merkle tree roots: StatusRoot and ActionRoot.
phase where the execution correctness or violation is arbitrated. StatusRoot is the root of a Merkle tree (referred as StatusMT)
that stores transaction status of underlying blockchains. The NSB
4.1 Protocol Preliminaries represents the transaction status of a blockchain based on the Tx-
4.1.1 Runtime Transaction State Roots and StateRoots retrieved from the blockchain’s public ledger.
Although the exact namings may vary on different blockchains,
During the execution phase, a transaction may be in any of the fol-
in general, the TxRoot and StateRoot in a blockchain block rep-
lowing state {unknown, init, inited, open, opened, closed}, where
resent the root of a Merkle tree storing transactions and storage
a latter state is considered more advanced than a former one. The
state (e.g., account balance, contract state), respectively. Note that
state of each transaction must be gradually promoted following the
the NSB only stores relevant blockchain state, where a blockchain
above sequence. For each state (except for the unknown), ProtUIP
block is considered to be relevant if the block packages at least one
produces a corresponding attestation to prove the state. When the
transaction that is part of any dApp executables.
execution phase terminates, the final execution status of the HSL
ActionRoot is the root of a Merkle tree (referred to as ActionMT)
program is collectively decided by the state of all transactions, based
whose leaf nodes store certificates computed by VESes and dApp
on which ProtISC arbitrates its correctness or violation.
clients. Each certificate represents a certain step taken by either
4.1.2 Off-Chain State Channels the VES or the dApp client during the execution phase. To prove
The protocol exchange between ProtVES and ProtCLI can be con- such an action, a party needs to construct a Merkle proof to demon-
ducted via off-chain state channels for low latency. One challenge, strate that the certificate mapped to the action can be linked to a
however, is that it is difficult to enforce accountability for non- committed block on the NSB. These PoAs are crucial for the ISC to
closed transactions without preserving the execution steps by both enforce accountability if the execution fails. Since the information
parties. To address this issue, ProtUIP proposes Proof of Actions of each ActionMT is static, we lexicographically sort the ActionMT
(PoAs), allowing ProtVES and ProtCLI to stake their execution steps to achieve fast search and convenient proof of non-membership.
on NSB. As a result, the NSB is treated as a publicly-observable Note that the construction of StatusMT ensures that each under-
fallback communication medium for the off-chain channel. The lying blockchain can have a dedicated subtree for storing its trans-
benefit of this dual-medium design is that the protocol exchange action status. This makes the NSB shardable on the granularity of
between ProtVES and ProtCLI can still proceed agilely via off-chain individual blockchains, ensuing that the NSB is horizontally scalable
channels in typical scenarios, whereas the full granularity of their as HyperService continuously incorporates additional blockchains.
protocol exchange is preserved on the NSB in case of exceptions, ProtNSB , discussed in § 4.5, is the protocol that specifies the detailed
eliminating the ambiguity for accountability enforcement. construction of both roots and guarantees their correctness.
As mentioned in § 4.1.1, ProtUIP produces security attestations
to prove the runtime state of transactions. As we shall see below, an 4.2 Execution Protocol by VESes
attestation may come in two forms: a certificate, denoted by Cert, The full protocol of ProtVES is detailed in Figure 6. Below we clarify
signed by ProtVES or/and ProtCLI during their off-chain exchange, some technical subtleties.
or an on-chain Merkle proof, denoted by Merk, constructed using 4.2.1 Post Compilation and Session Setup
the NSB and underlying blockchains. An Cert and its corresponding
Merk are treated equivalently by the ProtISC in code arbitration. After GT is generated, ProtVES initiates an execution session for
GT in the PostCompiliation daemon. The primary goal of the ini-
4.1.3 Architecture of the NSB tialization is to create and deploy an insurance contract to protect
The NSB is a blockchain designed to provide an objective view on the execution of GT . Towards this end, ProtVES interacts with the
the execution status of dApps. Figure 5 depicts the architecture protocol ProtISC to create the insurance contract for GT , and fur-
of NSB blocks. Similar to typical blockchain blocks, an NSB block ther deploys the contract on NSB after the dApp client D agrees
contains several common fields, such as the hash fields to link blocks on the contract. Throughout the paper, Cert([∗]; Sig) represents a
together and the Merkle trees to store transactions and state. To signed certificate proving that the signing party agrees on the value
 1 Init: Data := ∅ 54 update S Cert .Add(Certid
T
) and T .state := inited
2 Daemon PostCompiliation(): 55 non-blocking wait until ProtNSB .MerkleProof(Certid ) returns Merkid
T T
3 generate the session ID sid ← {0, 1} λ 56 update S Merk .Add(Merkid )
T
4 call [cid, contract] := ProtISC .CreateContract(GT )
57 Upon Receive RInitedTrans(Certid T
) public: Southbound
5 send Cert([sid, GT , contract]; SigV ) to ProtCLI for approval
sid 58 assert Certid has the valid form of Cert([Te, inited, sid, T]; SigD )
6 halt until Cert([sid, GT , contract]; SigV , Sigsid
D ) is received T sid
sid 59 (_, _, S Cert, S Merk ) := Data[sid]; abort if not found
7 package contract as a valid transaction contract
œ
60 i id
abort if the CertT corresponding to CertT is not in S Cert
8 call ProtNSB .Exec(contract)
œ to deploy the contract œ
61 assert Te is correctly associated with the wrapper T
9 halt until contract
œ is initialized on ProtNSB
62 get tsopen := ProtNSB .BlockHeight()
10 call ProtISC .StakeFund to stake the required funds in ProtISC
63 compute CertoT := Cert([Te, open, sid, T, tsopen ]; SigV
sid
)
11 halt until D has staked its required funds in ProtISC
64 call ProtCLI .OpenTrans(CertoT ) to request opening for T
12 initialize Data[sid] := { GT , cid, S Cert =∅, S Merk =∅ }
65 call ProtNSB .AddAction(CertoT ) to prove CertoT is sent
13 Daemon Watching(sid, {ProtBC , ...}) private:
66 update S Cert .Add(CertoT ) and T .state := open
14 (GT , _, S Cert, S Merk ) := Data[sid]; abort if not found
67 non-blocking wait until ProtNSB .MerkleProof(CertoT ) returns MerkoT
15 for each T ∈ GT :
68 update S Merk .Add(MerkoT )
16 continue if T .state is not opened
69 Upon Receive OpenTrans(CertTo ) public: Northbound
17 identify T’s on-chain counterpart Te
18 continue if ProtBC .Status(Te) is not committed 70 assert Certo has valid form of Cert([Te, open, sid, T, tsopen ]; SigD )
T sid
19 get tsclosed := ProtNSB .BlockHeight() 71 (_, _, S Cert, S Merk ) := Data[sid]; abort if not found
20 T
compute C closed := Cert([Te, closed, sid, T, tsclosed ], SigV ) 72 abort if the CertTid corresponding to CertTo is not in S Cert
sid
T 73 assert tsopen is within a bounded range with ProtNSB .BlockHeight()
21 call ProtCLI .CloseTrans(C closed )
to negotiate the closed attestation
74 compute CertTod := Cert([Te, open, sid, T, tsopen ]; Sigsid
D , SigV )
sid
22 call ProtBC .MerkleProof(Te) to obtain a finalization proof for Te
c 75 call ProtBC .Exec(Te) to trigger on-chain execution
23 denote the finalization proof as MerkT1 (Figure 7)
c 76 call ProtCLI .OpenedTrans(CertTod ) to acknowledge request
24 update S Cert .Add(C closed
T ) and S Merk .Add(MerkT1 )
77 call ProtNSB .AddAction(CertTod ) to prove CertTod is sent
25 Daemon Watching(sid, ProtNSB ) private:
26 (GT , _, S Cert, S Merk ) := Data[sid]; abort if not found 78 update S Cert .Add(CertTod ) and T .state := opened
27 watch four types of attestations {Certid, Certo , Certod, Certc } 79 non-blocking wait until ProtNSB .MerkleProof(CertTod ) returns MerkTod
28 process fresh attestations via corresponding handlers (see below) 80 update S Merk .Add(MerkTod )
29 # Retrieve alternative attestations if necessary. 81 Upon Receive OpenedTrans(CertTod ) public: Southbound
30 for each T ∈ GT : 82 ast. CertTod has valid form of Cert([Te, open, sid, T, tsopen ]; SigV
sid
, Sigsid
D)
c
31 if T .state = opened and MerkT1 ∈ S Merk : 83 (_, _, S Cert, _) := Data[sid]; abort if not found
c
32 retrieve the roots [R, ...] of the proof MerkT1 84 abort if the CertTo corresponding to CertTod is not in S Cert
c
33 call ProtNSB .MerkleProof([R, ...]) to obtain a status proof MerkT2 85 update S Cert .Add(CertTod ) and T .state := opened
c2
34 continue if MerkT is not available yet on ProtNSB 86 T
Upon Receive CloseTrans(C closed ) public: Bidirectional
c c
35 compute the complete proof MerkcT := [MerkT1 , MerkT2 ] 87 assert C closed has valid form of Cert([Te, closed, sid, T, tsclosed ], Sigsid
T D)
36 update T .state := closed and S Merk .Add(MerkT ) c
c1
88 assert T is finalized on its destination blockchain and obtain Merk
e
T
37 compute eligible transaction set S using the current state of GT
89 assert tsclosed is within a bounded margin with ProtNSB .BlockHeight()
38 for each T ∈ S:
90 (_, _, S Cert, S Merk ) := Data[sid]; abort if not found
39 continue if T .state is not unknown
91 compute CertcT := Cert([Te, closed, sid, T, tsclosed ], Sigsid
D , SigV )
40 if T .from = ProtCLI : sid
92 call ProtCLI .ClosedTrans(CertcT ) to acknowledged request
41 compute CertiT := Cert([T, init, sid]; SigV ) c
sid 93 update S Cert .Add(CertTc ), S Merk .Add(MerkT1 ) and T .state := closed
42 call ProtCLI .InitTrans(CertiT ) to request initialization c
94 Upon Receive ClosedTrans(CertT ) public: Bidirectional
43 call ProtNSB .AddAction(CertiT ) to prove CertiT is sent
95 ast. Certc has valid form of Cert([Te, closed, sid, T, tsclosed ], SigV , SigD )
T
44 update S Cert .Add(CertiT ) and T .state := init sid sid
96 (_, _, S Cert, _) := Data[sid]; abort if not found
45 non-blocking wait until ProtNSB .MerkleProof(CertiT ) rt. MerkiT 97 abort if Cert([Te, closed, sid, T, tsclosed ], SigV ) is not in S Cert
sid
46 update S Merk .Add(MerkiT ) 98 update S Cert .Add(CertTc ) and T .state := closed
47 else: call self.SInitedTrans(sid, T) 99 Daemon Redeem(sid) private:
48 Upon Receive SInitedTrans(sid, T) private: Northbound 100 # Invoke the insurance contract periodically
49 (GT , _, S Cert, S Merk ) := Data[sid]; abort if not found 101 (GT , cid, S Cert, S Merk ) := Data[sid]; abort if not found
50 compute and sign the on-chain counterpart Te for T 102 for each unclaimed T ∈ GT :
51 compute Certid T
:= Cert([Te, inited, sid, T]; SigVsid
) 103
Ð
get the CertT from S Cert S Merk with the most advanced state
52 call ProtCLI .InitedTrans(Certid
T
) to request opening of initialized T 104 call ProtISC .InsuranceClaim(cid, CertT ) to claim insurance
53 call ProtNSB .AddAction(Certid
T
) to prove Certid
T
is sent

Figure 6: Protocol description of of ProtVES . Gray background denotes non-blocking operations triggered by status updates
on ProtNSB . Handlers annotated with northbound and southbound process transactions originated from ProtVES and ProtCLI ,
respectively. Handlers annotated with bidirectional are shared by all transactions.
 V and Sig D to represent the Blockchain X The NSB
enclosed in the certificate. We use Sigsid sid
signature by ProtVES and ProtCLI , respectively. … TxRoot: Rx StateRoot: Ry … … StatusRoot …
Additionally, both ProtVES and ProtCLI are required to deposit
sufficient funds to ProtISC to ensure that ProtISC holds sufficient
funds to financially revert all committed transactions regardless
Blockchain X
of the step at which the execution aborts prematurely. Intuitively,
each party would need to stake at least the total amount of in- Value A BlockID: 2019
TxHash: 0x3…
coming funds to the party without deducting the outgoing funds. StateRoot: Ry
This strawman design, however, require high stakes. More desir- Value B TxRoot: Rx

ably, considering the dependency requirements in GT , an party X Figure 7: The complete on-chain proof (denoted by MerkcT )
(ProtVES or ProtCLI ) only needs to stake to prove that the state of a transaction is eligible to be pro-
moted as closed. The left-side part is the finalization proof
Õ Õ
max T .meta.amt − T .meta.amt
s ∈ GS
T ∈s ∧ T .to=X T ∈s ∧ T .from=X (denoted by MerkcT1 ) for the transaction collected from its
where GS is the set of all committable subsets in GT , where a subset destination blockchain; the right-side part is the blockchain
s ⊆ GT is committable if, whenever T ∈ s, all preconditions of T status proof (denoted by MerkcT2 ) collected from the NSB.
are also in s. For clarity of notation, throughout the paper, when
saying T .from =ProtVES or T is originated from ProtVES , we mean both parties. Only the tsopen specified in Certod is used by ProtISC
T
that T is sent and signed by an account owned by ProtVES . Likewise, when evaluating the deadline constraint of T .
T .from =ProtCLI indicates that T is sent from an account entity Southbound transactions originating from ProtCLI are processed
defined in the HSL program. ProtISC refunds any remaining funds by ProtVES in a similar manner as the northbound transactions, via
after the contract is terminated. the RInitedTrans and OpenedTrans handlers. We clarify a subtlety
After the contract is instantiated and sufficiently staked, ProtVES in the RInitedTrans handler when verifying the association between
initializes its internal bookkeeping for the session. The two no- Te and T (line 61). If Te depends on the resulting state from its up-
tations S Cert and S Merk represent two sets that store the signed stream transactions (for instance, T4 depends on the resulting state
certificates received via off-chain channels and on-chain Merkle
of T1 in Figure 4), ProtVES needs to verify that the state used by Te
proofs constructed using ProtNSB and ProtBC .
is consistent with the state enclosed in the finalization proofs of
4.2.2 Protocol Exchange for Transaction Handling those upstream transactions.
In ProtVES , SInitedTrans and OpenTrans are two handlers process- 4.2.3 Proactive Watching Services
ing northbound transactions which originates from ProtVES . The
The cross-chain execution process proceeds when all session-relevant
SInitedTrans handling for T is invoked when all its preconditions
blockchains and the NSB make progress on transactions. As the dri-
are finalized, which is detected by the watching service of ProtVES
ver of execution, ProtVES internally creates two watching services
(c.f., § 4.2.3). The SInitedTrans computes Certid T
to prove T is in to proactively read the status of those blockchains.
the inited state , and then passes it to the corresponding handler of In the watching daemon to one blockchain, ProtVES mainly reads
ProtCLI for subsequent processing. Meanwhile, SInitedTrans stakes the public ledger of ProtBC to monitor the status of transactions
Certid T
on ProtNSB , and later it retrieves a Merkle proof MerkiT from that have been posted for on-chain execution. If ProtVES notices
the NSB to prove that Certid T
has been sent. MerkidT
essentially is a that an on-chain transaction Te is recently finalized, it requests the
id
hash chain linking Cert T back to an ActionRoot on a committed closing process for T by sending ProtCLI a timestamped certificate
block of the NSB. The proof retrieval is a non-blocking operation C closed . The pair of handlers, CloseTrans and ClosedTrans, are used
triggered by the consensus update on the NSB. by both ProtVES and ProtCLI in this exchange. Both handlers can
The OpenTrans handler pairs with SInitedTrans. It listens for a be used for handling northbound and southbound transactions,
timestamped CertoT , which is supposed to be generated by ProtCLI depending on which party sends the closing request. In general, a
after it processes CertidT
from ProtVES . OpenTrans performs special transaction’s originator has a stronger motivation to initiate the
correctness check on the tsopen enclosed in CertoT . In particular, closing process because the originator would be held accountable
ProtVES and ProtCLI use the block height of the NSB as a calibrated if the transaction were not timely closed by its deadline.
clock. By checking that tsopen is within a bounded range of the In addition, ProtVES needs to retrieve a Merkle Proof from ProtBC
NSB height, ProtVES ensures that the tsopen added by ProtCLI is to prove the finalization of Te. This proof, denoted by MerkcT1 , serves
fresh. After all correctness checks on Certid are passed, the state two purposes: (i) it is the first part of a complete on-chain proof
T to prove that the state Te can be promoted to closed, as shown in
of T is promoted from open to opened. OpenTrans then computes
certificate to prove the updated state and posts Te on its destination Figure 7; (ii) if the resulting state of Te is used by its downstream
blockchain for on-chain execution. Throughout the paper, Te denotes transactions, MerkcT1 is necessary to ensure that those downstream
the on-chain executable transaction computed and signed using transactions indeed use genuine state.
the information contained in T . Note that the difference between In the watching service to ProtNSB , ProtVES performs following
the CertoT received from ProtCLI and a post-open (i.e., opened) tasks. First, as described in § 4.1.2, NSB is treated as a fallback
communication medium for the off-chain channel. Thus, ProtVES
certificate CertodT
computed by ProtVES is that latter one is signed by
 1 Init: Data := ∅ 28 assert the Te enclosed in Certid
T
or CertoT is genuine
2 Upon Receive CreateContract(GT ): 29 assert the tsopen enclosed in CertoT is genuine
3 generate the arbitration cod, denoted by contract, as follows 30 update T.state := Atte.state
4 initialize three maps Tstate , Arevs and Fstake 31 elif Atte is MerkodT
:
5 for each T ∈ GT : 32 retrieve the certificate Certod from Atte
T
6 compute an internal identifier for T as tid := H (T) 33 update T.state := opened and T.tsopen := Certod .tsopen
T
7 initialize Tstate [tid] := [unknown, T, tsopen =0, tsclosed =0, stproof ] 34 elif Atte is MerkcT :
8 retrieve tid’s fund-reversion account, denoted as dst c
35 update T.stproof based on MerkT1 if necessary
9 initialize Arevs [tid] := [amt=0, dst] c
→− 36 update T.tsclosed as the height of the block attaching MerkT2
10 compute an identifier for contract as cid := H ( 0 , contract) 37 update T.state := closed
11 initialize Data[cid] := [GT , Tstate, Arevs, Fstake ] 38 Upon Timeout SettleContract(cid): Internal Daemon
12 send [cid, contract] to the requester for acknowledgment 39 (GT , Tstate, Arevs, Fstake ) := Data[cid]; abort if not found
13 Upon Receive StakeFund(cid): 40 for (tid, T) ∈ Tstate :
14 (_, _, _, _, Fstake ) := Data[cid]; abort if not found 41 continue if T.state is not closed
15 update Fstake [msg.sender] := Fstake [msg.sender] + msg.value 42 update Arevs [tid].amt := T. T .meta.amt
16 Upon Receive InsuranceClaim(cid, Atte): 43 if DeadlineVerify(T) = true : update T.state := correct
17 (_, _, Tstate, _, _) := Data[cid]; abort if not found 44 compute S := DirtyTrans(GT , Tstate ) # non-empty if execution fails.
18 compute tid := H (Atte. T); T := Tstate [tid] abort if not found 45 execute fund reversion for non-zero entries in Arevs if S is not empty
19 abort if T.state is more advanced the state enclosed by Cert 46 initialize a map resp to record which party to blame
20 if Atte is a certificate signed by both parties : 47 for each (tid, T) ∈ S :
21 assert SigVerify(Atte) is true 48 if T.state = closed | open | opened : resp[tid] := T. T .from
22 if Atte is CertodT
: update T.state := opened; T.tsopen := Atte.tsopen 49 elif T.state = inited : resp[tid] := T. T .to
23 else : update T.state := closed; T.tsclosed := Atte.tsclosed 50 elif T.state = init : resp[tid] := D
24 else : # Atte is in form of a Merkle proof 51 else : resp[tid] := V
25 assert MerkleVerify(Atte) is true 52 return any remaining funds in Fstake to corresponding senders
26 if Atte is a MerkiT or Merkid T
or MerkoT : 53 call Data.erase[cid] to stay silent afterwards
27 retrieve the certificate CertiT or Certid
T
or CertoT from Atte

Figure 8: ProtISC : the protocol realization of the ISC arbitrator.

searches the sorted ActionMT to look for any session-relevant cer- and OpenTrans of ProtVES , respectively, to process Certid and
tificates that have not been received via the off-chain channel. Sec- Certod sent by ProtVES when handling transactions originated from
ond, for each opened T whose closed attestation is still missing ProtVES . The InitTrans and OpenTrans process Certi and Certo sent
after ProtVES has sent C closed (indicating slow or no reaction from by ProtVES when executing transactions originated from ProtCLI .
ProtCLI ), ProtVES tries to retrieve the second part of MerkcT from The CloseTrans and ClosedTrans of ProtCLI match their counter-
ProtNSB . The second proof, denoted as MerkcT2 , is to prove that the parts in ProtVES to negotiate closing attestations.
Merkle roots referred in MerkcT1 are correctly linked to a StatusRoot For usability, HyperService imposes smaller requirements on
on a finalized NSB block (see Figure 7). Once MerkcT is fully con- the watching daemons implemented by ProtCLI . Specially, ProtCLI
structed, the state of T is promoted as closed. Finally, ProtVES may still proactively watches ProtNSB to have a fallback communica-
find a new set of transactions that are eligible to be executed if their tion medium with ProtVES . However, ProtCLI is not required to
preconditions are finalized due to any recently-closed transactions. proactively watch the status of underlying blockchains or dynami-
If so, ProtVES processes them by either requesting initialization cally compute eligible transactions whenever the execution status
from ProtCLI or calling SInitedTrans internally, depending on the changes. We intentionally offload such complexity on ProtVES to
originators of those transactions. enable lightweight dApp clients. ProtCLI , though, should (and is
motivated to) check the status of self-originated transactions in
4.2.4 ProtISC Invocation order to request transaction closing.
ProtVES periodically invokes ProtISC to execute the contract. All
internally stored certificates and complete Merkle proofs are accept- 4.4 Protocol Realization of the ISC
able. However, for any T , ProtVES should invoke ProtISC only using Figure 8 specifies the protocol realization of the ISC. The Create-
the attestation with the most advanced state, since lower-ranked Contract handler is the entry point of requesting insurance contract
attestations for T are effectively ignored by ProtISC (c.f., § 4.4). creation using ProtISC . It generates the arbitration code, denoted
as contract, based on the given dApp executable GT . The contract
4.3 Execution Protocol by dApp Clients internally uses Tstate to track the state of each transaction in GT ,
ProtCLI specifies the protocol implemented by dApp clients. ProtCLI which is updated when processing security attestations in the In-
defines the following set of handlers to match ProtVES . In partic- suranceClaim handler. For clear presentation, Figure 8 extracts
ular, the InitedTrans and OpenedTrans match the SInitedTrans
 Negative Branch Positive Branch
accountable for not proactively driving the initialization of T , no
Originator: Dest: Failed to VES: Failed to matter which party originates T .
Violated deadline request opening proactively drive

4.5 Specification of ProtNSB and ProtBC

Close /
Correct Open Inited Init Unknown
Opened ProtBC specifies the protocol realization of a general-purpose block-
chain where a set of consensus nodes run a secure protocol to agree
No party to Originator: Failed dApp: Failed to
blame to dispatch initialize
upon the public global state. In this paper, we regard ProtBC as a
conceptual party trusted for correctness and availability, i.e., ProtBC
Figure 9: The decision tree to decide the accountable party
guarantees to correctly perform any predefined computation (e.g.,
for a dirty transaction.
Turing-complete smart contract programs) and is always avail-
able to handle user requests despite unbounded response latency.
the state proof and fund reversion tuple from T as dedicated vari- ProtNSB specifies the protocol realization of the NSB. ProtNSB is
ables stproof and Arevs . When the ProtISC times out, it executes the an extended version of ProtBC with additional capabilities. Due
contract terms based on its internal state, after which its funds to space constraint, we move the detailed protocol description of
are depleted and the contract never runs again. Below we explain ProtBC and ProtNSB to Appendix A.1.
several technical subtleties.
4.6 Security Theorems
4.4.1 Insurance Claim
To rigorously prove the security properties of UIP, we first present
The InsuranceClaim handler processes security attestations from the cryptography abstraction of the UIP in form of an ideal func-
ProtVES and ProtCLI . Only dual-signed certificates (i.e., Certod and tionality FUIP . The ideal functionality articulates the correctness
Certc ) or complete Merkle proofs are acceptable. Processing dual- and security properties that UIP wishes to attain by assuming a
signed certificates is straightforward as they are explicitly agreed trusted entity. Then we prove that ProtUIP , our the decentralized
by both parties. However, processing Merkle proof requires addi- real-world protocol containing the aforementioned preliminary
tional correctness checks. First, when validating a Merkle proof protocols, securely realizes FUIP using the UC framework [28], i.e.,
MerkiT , Merkid T
or MerkoT , ProtISC retrieves the single-party signed ProtUIP achieves the same functionality and security properties as
certificate CertiT , CertidT
or CertoT enclosed in the proof and per- FUIP without assuming any trusted authorities. Since the rigorous
forms the following correctness check against the certificate. (i) The proof requires non-trivial simulator construction within the UC
certificate must be signed by the correct party, i.e., CertiT is signed framework, we defer detailed proof to a dedicated section § 8.
by ProtVES , Certid T
is signed by T ’s originator and CertoT is signed
5 IMPLEMENTATION AND EXPERIMENTS
by the destination of T . (ii) The enclosed on-chain transaction Te in
Certid and CertoT is correctly associated with T . The checking logic In this section, we present the implementation of a HyperService
T
is the same as the on used by ProtVES , which has been explained prototype and report experiment results on the prototype. At the
in § 4.2.2. (iii) The enclosed tsopen in CertoT is genuine, where the time of writing, the total development effort includes (i) ∼1,500
genuineness is defined as a bounded difference between tsopen and lines of Java code and ∼3,100 lines of ANTLR [55] grammar code
the height of the NSB block that attaches MerkoT . for building the HSL programming framework, (ii) ∼21,000 lines of
code, mainly in Go and Python, for implementing the UIP protocol;
4.4.2 Contract Term Settlement and ∼8,000 lines of code, mainly in Go, for implementing the NSB;
ProtISC registers a callback SettleContract to execute contract terms and (iii) ∼1,000 lines of code, in Solidity, Vyper, Go and HSL, for
automatically upon timeout. ProtISC internally defines an additional writing cross-chain dApps running on HyperService. The released
transaction state, called correct. The state of a closed transaction source code is available at [4]. The HyperService Consortium is
is promoted to correct if its deadline constraint is satisfied. Then, under active code maintenance and new feature development for
ProtISC computes the possible dirty transactions in GT , which are HyperService.
the transactions that are eligible to be opened, but with non-correct
state. Thus, the execution succeeds only if GT has no dirty transac- 5.1 Platform Implementation
tions. Otherwise, ProtISC employs a decision tree, shown in Figure 9, To demonstrate the interoperability and programmability across
to decide the responsible party for each dirty transaction. The deci- heterogeneous blockchains on HyperService, our current proto-
sion tree is derived from the execution steps taken by ProtVES and type incorporates Ethereum, the flagship public blockchain, and a
ProtCLI . In particular, if a transaction T ’s state is closed, opened or permissioned blockchain built atop the Tendermint [17] consensus
open, then it is T ’s originator to blame for either failing to fulfill the engine, a commonly cited cornerstone for building enterprise block-
deadline constraint or failing to dispatch Te for on-chain execution. chains. We implement the necessary accounts (wallets), the smart
If a transaction T ’s state is inited, then it is T ’s destination party’s contract environment, and the on-chain storage to deliver the per-
responsibility for not proceeding with T even though Certid T
has missioned blockchain with full programmability. The NSB is also
been provably sent. If a transaction T ’s state is init (only transac- built atop Tendermint with full support for its claimed capabilities,
tions originated from dApp D can have init status), then D (the such as action staking and Merkle proof retrieval.
originator) is the party to blame for not reacting on the CertiT sent For the programming framework, we implement the HSL com-
by V. Finally, if transaction T ’s state is unknown, then V is held piler that takes HSL programs and contracts written in Solidity,
Vyper, and Go as input, and produces transaction dependency Financial CryptoAsset Federated
Derivatives Movement Computing
graphs. We implement the multi-lang front end and the HSL front
Mean % Mean % Mean %
end using ANTLR [55], which parse the input HSL program and
HSL Compilation 1.1769 ∼16 0.2598 ∼4 1.095 ∼15
contracts, build an intermediate representation of the HSL program,
Session Creation 4.2399 ∼58 4.1529 ∼67 4.2058 ∼60
and convert the types of contract entities into our unified types.
Action/Status Staking 0.6754 ∼10 0.7295 ∼12 0.7592 ∼11
We also implement the validation component that analyzes the Proof Retrieval 1.0472 ∼15 1.0511 ∼17 0.9875 ∼14
intermediate representation to validate the entities, operations, and
Total 7.1104 6.1933 7.0475
dependencies specified in the HSL program.
Table 3: End-to-end dApp execution latency on HyperSer-
Our experience with the prototype implementation is that the
vice, with profiling breakdown. All times are in seconds.
effort for horizontally scaling HyperService to incorporate a new
blockchain is lightweight: it requires no protocol change to both UIP
1200
and the blockchain itself. We simply need to add an extra parser

Throughput (KB/s)
to the multi-lang front end to support the programming language 1000

used by the blockchain (if this language has not been supported 800

by HyperService), and meanwhile VESes extend their visibility 600

Cert. Size 200 Bytes
to this blockchain. The HyperService consortium is continuously 400 Cert. Size 250 Bytes
working on on-boarding additional blockchains, both permissioned 200 Cert. Size 500 Bytes
and permissionless. 0
0 20 40 60 80 100 120 140
Batch Size
5.2 Application Implementation Figure 10: The throughput of the NSB, measured as the total
Besides the platform implementation, we further implement and size of committed certificates on the NSB per second.
deploy three categories of cross-chain dApps on HyperService.
Financial Derivatives. Financial derivatives are among the mostly
cited blockchain applications. However, external data feed, i.e., an 5.3 Experiments
oracle, is often required for financial instructions. Currently, ora- We ran experiments with three blockchain testnets: one private
cles are either built atop trusted third-party providers (e.g., Ora- Ethereum testnet, one Tendermint-based blockchain, and the NSB.
clize [11]), or using trusted hardware enclaves [63]. HyperService, Each of those testnets is deployed on a VM instance of a public cloud
for the first time, realizes the possibility of using blockchains them- on different continents. For experiment purposes, dApp clients and
selves as oracles. With the built-in decentralization and correctness VES nodes can be deployed either locally or on cloud.
guarantees of blockchains, HyperService fully avoids trusted parties
5.3.1 End-to-End Latency
while delivering genuine data feed to smart contracts. In this appli-
cation sector, we implement a cross-chain cash-settled Option dApp We evaluated all three applications mentioned in § 5.2 and reported
in which options can be natively traded on different blockchains (a their end-to-end execution latency introduced by HyperService in
scaled-up version of the introductory example in § 2.3). Table 3. The reported latency includes HSL program compiling,
dApp-VES session creation, and (batched) NSB action staking and
Cross-Chain Asset Movement. HyperService natively enables
proof retrieval during the UIP protocol exchange. All reported
cross-chain asset transfers without relying on any trusted entities,
times include the networking latency across the global Internet.
such as exchanges. This primitive could power a wide range of
Each datapoint is the average of more than one hundred runs.
applications, such as a global payment network that interconnects
We do not include the latency for actual on-chain execution since
geographically distributed bank-backed consortium blockchains [9],
the consensus efficiency of different blockchains varies and is not
an initial coin offering in which tokens can be sold in various
controlled by HyperService. We also do not include the time for
cryptocurrencies, and a gaming platform where players can freely
ISC insurance claims in the end-to-end latency because they can
trade and redeem their valuables (in form of non-fungible tokens)
be done offline anytime before the ISC expires.
across different games. In this category, we implement an asset
These dApps show similar latency profiling breakdown, where
movement dApp with hybrid operations where assets are moved
the session creation is the most time consuming phase because it
among accounts and smart contracts across different blockchains
requires handshakes between the dApp client and VES, and also
Federated Computing. In a federated computing model, all par-
includes the time for ISC deployment and initialization. The Cryp-
ticipants collectively work on an umbrella task by submitting their
toAsset dApp has a much lower HSL compilation latency since its
local computation results. In the scenario where transparency and
operation only involves one smart contract, whereas the rest two
accountability are desired, blockchains are perfect platforms for
dApps import three contracts written in Go, Vyper, and Solidity. In
persisting both the results submitted by each participant and the
each dApp, all its NSB-related operations (e.g., action/status stak-
logic for aggregating those results. In this application category, we
ing and proof retrievals) are bundled and performed in a batch for
implement a federated voting system where delegates in different
experiment purpose, even though all certificates required for ISC
regions can submit their votes to their regional blockchains, and
arbitration have been received via off-chain channels. The sizes of
the logic for computing the final votes based on the regional votes
actions and proofs for three dApps are different since their executa-
is publicly visible on another blockchain.
bles contain different number of transactions.
5.3.2 NSB Throughput and HyperService Capacity In future work, we plan to extend the design of the UIP protocol
The throughput of the NSB affects aggregated dApp capacity on to support dynamic transaction graphs, which allows conditional
HyperService. In this section, we report the peak throughput of execution of operations and certain degree of indeterminism of
the currently implemented NSB. We stress tested the NSB by ini- operation executions, such as repeating an operation for a specific
tiating up to one thousand dApp clients and VES nodes, which times based on the values of state variables computed from previous
concurrently dispatched action and status staking to the NSB. We operations. With those extensions, we are able to implement control-
batched multiple certificate stakings by different clients into a single flow operations into HSL and provide both static and dynamic
NSB-transaction, so that the effective certificate-staking through- verification to ensure the correctness of dApps.
put perceived by those clients can exceed the consensus limit of the
NSB. Figure 10 plots the NSB throughput, measured as the total size 6.2 Cross-Shards and Cross-Worlds
of committed certificates by all clients per second, under different HyperService is motivated by heterogeneous blockchain interoper-
certificate and batch sizes. The results show that as the batch size ation. Thanks to its generic design, HyperService can also enable
increases, regardless of the certificate sizes, the NSB throughput cross-shard smart contracting and transactions for sharded block-
converged to about 1000 kilobytes per second. Given any certificate chain platforms (e.g., OmniLedger [44] and RapidChain [61]). On the
size, further enlarging the batch size cannot boost the throughput, one hand, the HSL programming framework is blockchain-neutral
whereas the failure rate of certificate staking increases, indicating and extensible. Thus, writing dApps that involve smart contracts
that the NSB is fully loaded. and accounts on different blockchains is conceptually identical
Given the above NSB throughput, the actual dApp capacity of the to writing dApps that operate contracts and accounts on differ-
HyperService platform further depends on how often the communi- ent shards. In fact, given that most of those sharded blockchains
cation between dApp clients and VESes falls back to the NSB. In par- are homogeneously sharded (i.e., all shards have the same format
ticular, each dApp-transaction spawns at most six NSB-transactions of contracts and accounts), developing and compiling cross-shard
(five action stakings and one status staking), assuming that the dApps using HSL are even simpler than cross-chain dApps. On the
off-chain channel is fully nonfunctional (zero NSB transaction if other hand, realizing UIP on sharded blockchains also requires less
otherwise). Thus, the lower bound of the aggregate dApp capacity overhead since maintaining an NSB for all (homogeneous) shards
on HyperService, which would be reached only if all off-chain chan- is more lightweight than maintaining an NSB supporting hetero-
nels among dApp clients and VESes were simultaneously broken, is geneous blockchains. In fact, many sharded blockchain platforms
about 170000
s transactions per second (TPS), where s is the (average) already maintain a dedicated global blockchain as their trust anchor
size (in bytes) of a certificate. This capacity and the TPS of most (e.g., the identity chain of OmniLedger [44] and the beacon chain
PoS production blockchains are of the same magnitude. Further, of Harmony [2]), to which the NSB functionality can be ported.
considering (i) the NSB is horizontally shardable at the granularity Additionally, we envision that the fully connected Web 3.0 should
of each underlying blockchain (§ 4.1.3) and (ii) not all transactions also include centralized platforms (i.e., Cloud) to compensate for
on an underlying blockchain are cross-chain related, we anticipate functionality (e.g., performing computationally intensive tasks) that
that the NSB will not become the bottleneck as HyperService scales is difficult to execute on-chain. We recognize that two additional
to support more blockchains in the future. capabilities, with minimal distribution of their operation models,
are required from those centralized platforms to make them compat-
6 DISCUSSION ible with HyperService: (i) any public state they publish should be
In this section, we discuss several aspects that have not been thor- coupled with verifiable proofs to certify the correctness of the state
oughly addressed in this paper, and present our vision for future (where the definition of correctness could be application-specific),
work on HyperService and its impact. and (ii) all published state should have the concept of finality. With
such capabilities, dApps on HyperService can trustlessly incorpo-
6.1 Programming Framework Extension rate the state published by those centralized platforms.
HSL is a high-level programming language designed to write cross-
6.3 Cross-Chain Interoperability Service
chain dApps under the USM programming model. The language
constructs provided by HSL allow developers to directly specify Providers
entities, operations, and dependencies in HSL programs. To ensure VESes play vital roles on HyperService platform. We envision that
the determinism of operations, which is an important property VESes would enter the HyperService ecosystem as Cross-chain
for the NSB and the ISC to determine the correctness or viola- Interoperability Service Providers (CSPs) by providing required
tion of dApp executions, the language constructs do not include services to support cross-chain dApps, such as compiling HSL pro-
control-flow operations such as conditional branching, looping, and grams into transaction dependency graphs and speaking the UIP
calling/returning from a procedure. Additionally, dynamic trans- protocol. This vision is indeed strengthened by the practical archi-
action generation is also not supported by HSL, since it has led tectures of production blockchains, where all peer-to-peer nodes
to a new class of bugs known as re-entrancy vulnerabilities [56]. evolve into a hierarchy of stakeholders and a number of organi-
These design choices are consistent with the recent blockchain zations operate (not necessarily own) most of the mining power
programming languages that emphasize on safety guarantees, such for Proof-of-Work blockchains or/and stakes for Proof-of-Stake
as Move [22] for Facebook’s Libra blockchain. blockchains (whether such a hierarchical architecture undermines
decentralization is debatable, and is out of the scope of Hyper- signature [59]. As a result, none of those blockchains can be ab-
Service). Those organizations are perfectly qualified to operate as stracted as generic programmable state machines. Therefore, our
CSPs since they have good reachability to multiple blockchains and approach towards interoperating privacy-preserving blockchains
maintain sufficient token liquidity to support insurance staking, will be application specific, such as relying on fast zero-knowledge
contract invocation, and token transfers that are required in a wide proofs [25] to allow dApps to certify the state extracted from those
range of cross-chain dApps. blockchains.
CSPs (VESes) could be found via a community-driven directory
(similar to the Tor’s relay directories [18, 31]), which we envision 7 RELATED WORK
to be an informal list of CSPs. Each CSP has its own operation Blockchain interoperability is often considered as one of the pre-
models, including the set of blockchains it has reachability, service requisites for the massive adoption of blockchains. The recent
fees charged for correct dApp executions, and insurance plans to academic proposals have mostly focused on moving tokens be-
compensate CSP-introduced dApp failures. Developers have full tween two blockchains via trustless exchange protocol, includ-
autonomy to select CSPs based on their dApp requirements. Since ing side-chains [21, 36, 41], atomic cross-chain swaps [5, 38], and
all dApp execution results are publicly verifiable, it is possible to cryptocurrency-backed assets [62]. However, programmability, i.e.,
build a CSP reputation system to provide a valuable metric for CSP smart contracting across heterogeneous blockchains, is largely ig-
selection. CSPs thus misbehave at their own risk. nored in those protocols.
Because a CSP may wish to limit its staking funds at risk in the In industry, Cosmos [7] and Polkadot [12] are two notable projects
ISC, a dApp may be too large for any single CSP. Alternatively, a that advocate blockchain interoperability. They share the similar
dApp may span a set of blockchains such that no single CSP has the spirit: each of them has a consensus engine to build blockchains (i.e.,
reachability to all of them. In such cases, a cross-chain dApp could Tendermint [17] for Cosmos and Substrate [16] for Polkadot), and
be co-executed by a collection of VESes. By design, HyperService a mainchain (i.e., the Hub in Cosmos and RelayChain for Polkadot)
allows multi-VES executions since the UIP protocol is generic to to bridge individual blockchains. Although we do share the similar
include more parties. vision of “an Internet of blockchains”, we also notice two notable
We envision the industrial impact by HyperService is the birth of differences between them and HyperService. First and foremost,
a CSP-formed liquidity network interconnected by the UIP protocol, the cross-chain layer of Cosmos, powered by its Inter-blockchain
powering a wide range of cross-chain dApps. Communication Protocol (IBC) [15], mainly focuses on preliminary
network-level communications. In contrast, HyperService proposes
6.4 Complete Atomicity for dApps a complete stack of designs with a unified programming framework
In the context of cross-chain applications, dApps should be treated for writing cross-chain dApps and a provably secure cryptography
as first-class citizens because the success or failure of any individual protocol to execute dApps. Further, at the time of writing, the most
transaction cannot fully decide the state of dApps. HyperService recent development of Cosmos and industry adoption are heading
follows this design philosophy by providing security guarantees at towards homogeneity where only Tendermint-powered blockchains
the granularity of dApps. However, the current version of Hyper- are interoperable [1]. This is in fundamental contrast with Hyper-
Service is not fully dApp-atomic since UIP is unable to revert any Service where the blockchain heterogeneity is a first-class design
state update to smart contracts if dApps were eventually terminated requirement. Polkadot proceeds relatively slower than Cosmos:
prematurely. We recognize this as a fundamental challenge due to Substrate is still in early stage [16].
the finality guarantee of blockchains. Existing blockchain platforms such as Ethereum [60] and Nebu-
To deliver full dApp-atomicity on HyperService, we propose the las [10] allow developers to write contracts using new languages
concept of stateless smart contract where contracts are able to load such as Solidity [14] and Vyper [19] or a tailored version of the
state from blockchains before execution. As a result, even if the state existing languages such as Go, Javascript, and C++. Facebook re-
persistent on block Bn for a smart contact C eventually becomes cently released Move [22], a programming language in their block-
dirty due to dApp failure, subsequent dApps can still load clean chain platform Libra, which adopts the move semantics of Rust
state for the contract C from a block (prior to Bn ) agreed by all and C++ to prohibit copying and implicitly discarding coins and
parties. Although this design imposes additional requirements on allow only move of the coins. To unify these heterogeneous pro-
underlying blockchains, it is practical and deliverable using “layer- gramming languages, we propose HSL that has a multi-lang front
two” protocols where smart contract executions could be decoupled end to parse those contacts and convert their types to unified types.
from the consensus layer, for instance, via the usage of Trusted Although there exist domain-specific languages in a variety of
Execution Environment (e.g., Intel SGX [30] and Keystone [49]). security-related fields that have a well-established corpus of low
level algorithms, such as secure overlay networks [42, 50], net-
6.5 Privacy-Preserving Blockchains work intrusions [23, 57, 58], and enterprise systems [33, 34], these
The primary challenge of supporting privacy-preserving block- languages are explicitly designed to solve their domain-specific
chains on HyperService is the lack of a generic abstraction for problems, and cannot meet the needs of the unified programming
those systems. In particular, various designs have been proposed framework for writing cross-chain dApps.
to enhance blockchain privacy, such as encrypting blockchain
state [29], obfuscating and mixing transactions via cryptography
8 SECURITY THEOREMS Correctness and Security Properties of FUIP .With the assumed
In this section, we present the main security theorems for our trustiness, it is not hard to see that FUIP offers the following cor-
cryptography protocol UIP, and rigorously prove them using the rectness and security properties. First, after the pre-agreed timeout,
UC-framework [28]. the execution either finishes correctly with all precondition and
deadline rules satisfied, or the execution fails and is financially
8.1 Ideal Functionality FUIP reverted. Second, regardless of the stage at which the execution
fails, FUIP holds the misbehaved parties accountable for the failure.
We first present the cryptography abstraction of the UIP in form of
Third, if Fblockchain is modeled with bounded transaction finality
an ideal functionality FUIP . The ideal functionality articulates the
latency, Op is guaranteed to finish correctly if both parties are
correctness and security properties that HyperService wishes to
honest. Finally, FUIP , by design, makes the contract public. This is
attain by assuming a trusted entity. The detailed description of FUIP
because in the real world protocol ProtUIP , the status of execution
is given in Figure 11. Below we provide additional explanations.
is public both on the ISC and the NSB. We leave the support for
Session Setup. Through this interface, a pair of parties (Pa , Pz )
privacy-preserving blockchains on HyperService to future work.
(e.g., a dApp client and a VES) requests FUIP to securely execute a
dApp executable. They provide the executable in form of a transac- 8.2 Main Security Theorems
tion dependency graph GT , as well as the correctness arbitration
code contract. As a trusted entity, FUIP generates keys for both In this section, we claim the main security theorem of HyperService.
parties, allowing FUIP to sign transactions and compute certificates The correctness of Theorem 8.1 guarantees that ProtUIP achieves
on their behalf. Both parties are required to stake sufficient funds, same security properties as FUIP .
derived from the contract, into FUIP . FUIP annotates each transac- Theorem 8.1. Assuming that the distributed consensus algorithms
tion wrapper T in GT with its status (initialized to be unknown), used by relevant BNs are provably secure, the hash function is pre-
its open/close timestamps (initialized to 0s), and its on-chain coun- image resistant, and the digital signature is EU-CMA secure (i.e.,
terpart Te (initialized to be empty). To accurately match FUIP with existentially unforgeable under a chosen message attack), our decen-
the real-world protocol ProtUIP , in Figure 11, we assume that Pa is tralized protocol ProtUIP securely UC-realizes the ideal functionality
the dApp client and Pz is the VES. FUIP against a malicious adversary in the passive corruption model.
Since FUIP does not impose any special requirements on the
We further consider a variant of ProtUIP , referred to as H-ProtUIP ,
underlying blockchains, we model the ideal-world blockchain as an
that requires PVES and PCLI to only use PNSB as their communica-
ideal functionality Fblockchain that supports two simple interfaces:
tion medium.
(i) public ledger query and (ii) state transition triggered by transac-
tions (where FUIP imposes no constraint on both the ledger format Theorem 8.2. With the same assumption of Theorem 8.1, the UIP
and the consensus logic of state transitions). protocol variant H-ProtUIP securely UC-realizes the ideal functionality
Transaction State Updates. FUIP defines a set of interfaces to FUIP against a malicious adversary in the Byzantine corruption model.
accept external calls for updating transaction state. In each interface,
FUIP performs necessary correctness check to guarantee that the 8.3 Proof Overview
state promotion is legitimate. In all interfaces, FUIP computes an We now the prove our main theorems. We start with Theorem 8.1. In
attestation for the corresponding transaction state, and sends it to the UC framework [28], the model of ProtUIP execution is defined
both parties to formally notify the actions taken by FUIP . as a system of machines (E, A, π1 , ..., πn ) where E is called the
Financial Term Execution. Upon the expiration of timer, both environment, A is the (real-world) adversary, and (π 1 , ..., πn ) are
parties can invoke the TermExecution interface to trigger the con- participants (referred to as parties) of ProtUIP where each party may
tract code execution. The arbitration logic is also derived from execute different parts of ProtUIP . Intuitively, the environment E
decision tree mentioned in Figure 9. However, FUIP decides the represents the external system that contains other protocols, includ-
final state of each transaction merely using its internal state due to ing ones that provide inputs to, and obtain outputs from, ProtUIP .
the assumed trustiness. The adversary A represents adversarial activity against the pro-
Verbose Definition of FUIP . We intentionally define FUIP ver- tocol execution, such as controlling communication channels and
bosely (that is, sending many signed messages) in order to accu- sending corruption messages to parties. E and A can communi-
rately match FUIP to the real world protocol ProtUIP . For instance, cate freely. The passive corruption model (used by Theorem 8.1)
in the SessionCreate interface, FUIP certifies (GT , contract, sid) on enables the adversary to observe the complete internal state of
behalf of both parties to simulate the result of a successful hand- the corrupted party whereas the corrupted party is still protocol
shake between two parties in the real world. Another example is compliant, i.e., the party executes instruction as desired. § 8.6 dis-
that the attestations generated in those state update interfaces are cusses the Byzantine corruption model, where the adversary takes
not essential to ensure correctness due to the assumed trustiness complete control of the corrupted party.
of FUIP . However, FUIP still publishes attestations to emulate the To prove that ProtUIP UC-realizes the ideal functionality FUIP ,
side effects of ProtUIP in the real world. As we shall see below, such we need to prove that ProtUIP UC-emulates IFUIP , which is the ideal
emulation is crucial to prove that FUIP UC-realizes ProtUIP . protocol (defined below) of our ideal functionality FUIP . That is, for
any adversary A, there exists an adversary (often called simulator)
S such that E cannot distinguish between the ideal world, featured
 1 Init: Data := ∅ 32 assert P = T .from, T .state = open and T .trans = Te
2 Upon Receive SessionCreate(GT , contract, Pa , Pz ): 33 assert tsopen is within the error boundary with now()
3 generate the session ID sid ← {0, 1} λ and keys for both parties 34 update T .state = opened and get T .tsopen := tsopen
Pz Pa
4 send Cert([sid, GT , contract]; Sigsid , Sigsid ) to both parties 35 post Te on Fblockchain for on-chain execution
Pa Pz
5 halt until both parties deposit sufficient fund, denoted as stake 36 compute Certod T
:= Cert([Te, open, tsopen, sid, T); Sigsid , Sigsid )
6 start a blockchain monitoring daemon for this session 37 send Certod
T
to both { Pa , Pz } to inform action
7 set an expiration timer timer for executing the contract term
38 Upon Receive ReqTransClose(T, sid, Te, tsclosed ):
8 for T ∈ GT : initialize the annotations for T
39 (GT , _, _, _) := Data[sid]; abort if not found
9 update Data[sid] := { GT , contract, stake, timer}
40 assert T .state = opened and T .trans = Te
10 Upon Receive ReqTransInit(T, sid, P): 41 query the ledger of Fblockchain for Te’s status
11 (GT , _, _, _) := Data[sid]; abort if not found 42 abort if T is not finalized on Fblockchain
12 assert P is Pz 43 assert tsclosed is within the error boundary with current time now()
13 assert T is eligible to be opened according the state of GT 44 update T .state := closed and T .tsclosed := tsclosed
14 update T .state := init 45
Pa
compute CertcT := Cert([T , closed, tsclosed, sid, T); Sigsid Pz
, Sigsid )
Pz
15 compute CertiT := Cert([T, init, sid]; Sigsid ) 46 send CertT to both { Pa , Pz } to inform action
c
16 send CertT to both { Pa , Pz } to inform action
i
47 Upon Receive TermExecution(sid, P ∈ (Pa , Pz )) public:
17 Upon Receive ReqTransInited(T, sid, P) 48 (GT , contract, stake, timer) := Data[sid]; abort if not found
18 (GT , _, _, _) := Data[sid]; abort if not found 49 abort if timer has not expired
19 assert P = T .from and T .state = init 50 # The following is the arbitration logic specified by contract
20 compute the on-chain transaction Te for T 51 initialize a map resp to record which party to blame
21 update T .state := inited and T .trans := Te 52 compute eligible transactions set S given current state of GT
22 compute Certid := Cert([Te, inited, sid, T]; SigP )
T sid 53 for T ∈ S :
23 send Certid
T
to both { Pa , Pz } to inform action 54 if T .state = unknown : update resp[T] := Pz
24 Upon Receive ReqTransOpen(T, sid, Te, P): 55 elif T .state = init : update resp[T] := Pa
25 (GT , _, _, _) := Data[sid]; abort if not found 56 elif T .state = inited : update resp[T] := T .to
26 assert P = T .to, T .state = inited and T .trans = Te 57 elif T .state = open and T .state = opened :
27 update T .state = open and get tsopen := now() 58 update resp[T] := T .from
28 compute CertoT := Cert([Te, open, tsopen, sid, T]; Sigsid
P ) 59 elif T .state = closed and deadline constraint fails :
29 send CertoT to both { Pa , Pz } to inform action 60 update resp[T] =: T .from
61 financially revert all closed transactions if resp is not empty
30 Upon Receive ReqTransOpened(T, sid, Te, P, tsopen ):
62 return any remaining funds in stake to corresponding senders
31 (GT , _, _, _) := Data[sid]; abort if not found
63 remove the internal bookkeeping of sid from Data

Figure 11: The ideal functionality FUIP .

by (IFUIP , S), and the real world, featured by (ProtUIP , A). Math- is that the simulator S observes the side effects of ProtUIP in the
→− real world, such as attestation publication on the NSB and contract
ematically, on any input, the probability that E outputs 1 after
interacting with (ProtUIP , A) in the real world differs by at most invocation of the ISC, and then accurately emulates these effects
→− in the ideal world, with the help from FUIP . As a result, E cannot
a negligible amount from the probability that E outputs 1 after
distinguish the ideal and real worlds.
interacting with (IFUIP , S) in the ideal world.
The ideal protocol IFUIP is a wrapper around FUIP by a set of
dummy parties that have the same interfaces as the parties of
8.4 Construction of the Ideal Simulator S
ProtUIP in the real world. As a result, E is able to interact with Next, we detail the construction of S by specifying what actions S
IFUIP in the ideal world the same way it interacts with ProtUIP in should take upon observing instructions from E. As a distinguisher,
the real world. These dummy parties simply pass received input E sends the same instructions to the ideal world dummy parities
from E to FUIP and relay output of FUIP to E, without implementing as those sent to the real world parties.
any additional logic. FUIP controls all keys of these dummy parties. • Upon E gives an instruction to start an inter-BN session between
I and P I , S emulates the G and contract setup (c.f., § 8.5)
PCLI
For the sake of clear presentation, we abstract the real-world par- VES T
ticipants of ProtUIP as five parties {PVES , PCLI , PISC , PNSB , PBC }. and constructs a SessionCreate call to FUIP with parameter (GT ,
The corresponding dummy party of PVES in the ideal world is I , P I ).
contract, PCLI VES
denoted as PVESI . This annotation applies for other parties. I to send an initialization request for a
• Upon E instructs PVES
Based on [28], to prove that ProtUIP UC-emulates IFUIP for any transaction intent T , S extracts T and sid from the instruction
adversaries, it is sufficient to construct a simulator S just for the of E, and constructs a ReqTransInit call to FUIP with parameter
dummy adversary A that simply relays messages between E and I ). Other instructions in the same category are han-
(T , sid, PVES
the parties running ProtUIP . The high-level process of the proof dled similarly by S. In particular, for instruction to SInitedTrans,
 S calls ReqTransInited of FUIP ; for instructions to RInitedTrans, Upon observing an instruction from E (to either dummy party)
S calls ReqTransOpen of FUIP ; for instructions to OpenTrans, S to invoke the smart contract, S uses its saved certificates or Merkle
calls ReqTransOpened of FUIP ; for instructions to CloseTrans, S proofs to invoke PISC in the Hybrid A1 accordingly.
calls ReqTransClose of FUIP . S ignores instructions to Opened- Note that in the real world, the execution of GT is automatic in
Trans and ClosedTrans. S may also extract the Te from the in- the sense that GT can continuously proceed even without additional
struction, which is used by some interfaces of FUIP to ensure the instructions from E after successful session setup. In the Hybrid A1 ,
association between T and Te. although PVES and PCLI are replaced by dummy parties, S, with
• Due to the asymmetry of interfaces defined by PCLI I and P I , S fully knowledge of GT , is still able to drive the execution of GT so
VES
I .
acts slightly differently when observing instructions sent to PVES that from E’s perspective, GT is executed automatically. Further,
In particular, for instructions to InitTrans, S calls ReqTransInited since PISC still lives in the Hybrid A1 , S should not trigger the
of FUIP ; for instructions to InitedTrans, S calls ReqTransOpen TermExecution interface of FUIP to avoid double execution on the
of FUIP ; for instructions to OpenTrans, S calls ReqTransOpened same contract terms. S can still reclaim its funds staked in FUIP via
of FUIP . The rest handlings are the same as those of PVES I . “backdoor” channels since S and FUIP are allowed to communicate
I freely under the UC framework.
• Upon E instructs PVES to invoke the smart contract, S locally
executes the contract and the instructs FUIP to published the Fact 1. With the aforementioned construction of S and FUIP , it is
I . immediately clear that the outputs of both dummy parties in the
updated contract to PISC
Hybrid A1 are exactly the same as the outputs of the corresponding
8.5 Indistinguishability of Real and Ideal actual parties in the real world, and all side effects in the real world
are accurately emulated by S in the Hybrid A1 . Thus, E cannot
Worlds distinguish with the real world and the Hybrid A1 .
To prove indistinguishability of the real and ideal worlds from Hybrid A2 . Hybrid A2 is the same as the Hybrid A1 , expect that
the perspective of E, we will go through a sequence of hybrid PISC is further replaced by the dummy PISC I . As a result, S is
arguments, where each argument is a hybrid construction of FUIP , required to resume the responsibility of PISC in the Hybrid A2 .
a subset of dummy parties of IFUIP , and a subset of real-world In particular, when observing an instruction to execute a GT , S
parties of ProtUIP , except that the first argument that is ProtUIP computes the arbitration code contract, and then instructs FUIP to
without any ideal parties and the last argument is IFUIP without I , which is observable by E. For any
publish the contract on PISC
any real world parties. We prove that E cannot distinguish any
instruction to invoke contract, S locally executes contract with the
two consecutive hybrid arguments. Then based on the transitivity I via F
input and then publishes the updated contract to PISC UIP .
of protocol emulation [28], we prove that the first argument (i.e.,
Finally, upon the predefined contract timeout, S calls the TermExe-
ProtUIP ) UC-emulates the last argument (i.e., IFUIP ). I ) or (sid, P I )
cution interface of FUIP with parameter (sid, PVES CLI
Real World. We start with the real world ProtUIP with a dummy to execute the contract, which emulates the arbitration performed
adversary that simply passes messages to and from E. by PISC in the Hybrid A1 .
Hybrid A1 . Hybrid A1 is the same as the real world, except that the It is immediately clear that with the help of S and FUIP , the out-
I , P I ) pair. Upon
(PVES , PCLI ) pair is replaced by the dummy (PVES I and all effects in the Hybrid A are exactly
CLI put of the dummy PISC 2
observing an instruction from E to execute some dApp executables the same as those in the Hybrid A1 . Thus, E cannot distinguish
GT , S calls the CreateContract interface of PISC (living in the these two worlds.
Hybrid A1 ) to obtain the contract code contract. Upon contract is Hybrid A3 . Hybrid A3 is the same as the Hybrid A2 , expect that
received, S calls the SessionCreate interface of FUIP with parameter I . Since the structure of
I , P I ), which will output a certificate to both PNSB is further replaced by the dummy PNSB
(GT , contract, PVES CLI PNSB and messages sent to PNSB are public, simulating its function-
dummy parties to emulate the handshake result between PVES and ality by S is trivial. Therefore, Hybrid A3 is identically distributed
PCLI in the real world. S also deploys contract on PNSB or PBC in as Hybrid A2 from the view of E.
the Hybrid A1 . Finally, S stakes required funds into FUIP to unblock
Hybrid A4 , i.e., the ideal world. Hybrid A4 is the same as the
its execution.
Hybrid A3 , expect that PBC (the last real-world party) is further
Upon observing an instruction from E (sent to either dummy I . Thus, the Hybrid A is essentially
replaced by the dummy PBC 4
parties) to execute a transaction in GT , based on its construction
IFUIP . Since the functionality of PBC is a strict subset of that of
in § 8.4, S has enough information to construct a call to FUIP
PNSB , simulating PBC by S is straightforward. Therefore, IFUIP is
with a proper interface and parameters. If the call generates a
indistinguishable with the Hybrid A3 from E’s perspective.
certificate Cert, S retrieves Cert to emulate the PoAs staking in
Then given the transitivity of protocol emulation, we show that
the real world. In particular, if in the real world, PVES (and PCLI )
ProtUIP UC-emulates IFUIP , and therefore prove that ProtUIP UC-
publishes a certificate on PNSB after receiving the same instruction
realizes FUIP . Throughout the simulation, we maintain a key in-
from E, then S publishes the corresponding certificate on PNSB
variant: S and FUIP together can always accurately simulate the
in the Hybrid A1 as well. Otherwise, S skip the publishing. Later,
desired outputs and side effects on all (dummy and real) parties
S retrieves (and stores) the Merkle proof from PNSB , and then
in all Hybrid worlds. Thus, from E’s view, the indistinguishability
instructs FUIP to output the proof to the dummy party which, from
between the real and ideal worlds naturally follows.
the point view of E, should be the publisher of Cert.
8.6 Byzantine Corruption Model [9] J.P. Morgan: Blockchain and Distributed Ledger. https://www.jpmorgan.com/
global/blockchain, Accessed on 2019.
Theorem 8.1 considers the passive corruption model. In this section, [10] Nebulas. https://github.com/nebulasio, Accessed on 2019.
we discuss the more general Byzantine corruption model for PVES [11] Oraclize. http://www.oraclize.it, Accessed on 2019.
[12] Polkadot. https://polkadot.network, Accessed on 2019.
and PCLI (by assumption of this paper, blockchains and smart con- [13] rhombus. https://rhombus.network, Accessed on 2019.
tracts are trusted for correctness). Previously, we construct S and [14] Solidity. https://solidity.readthedocs.io/en/v0.5.6/, Accessed on 2019.
FUIP accurately to match the desired execution of ProtUIP . However, [15] Standards for the Cosmos network & Interchain Ecosystem. https://github.com/
cosmos/ics, Accessed on 2019.
if one party is Byzantinely corrupted, the party behaves arbitrarily. [16] Substrate. https://github.com/paritytech/substrate, Accessed on 2019.
As a result, a Byzantine-corrupted party may send conflicting mes- [17] Tendermint Core. https://tendermint.com, Accessed on 2019.
sages to off-chain channels and PNSB . Note that for any transaction [18] Tor Directory Authorities. https://metrics.torproject.org/rs.html#search/flag:
authority, Accessed on 2019.
state, ProtUIP always processes the first received attestation (either [19] Vyper. https://github.com/ethereum/vyper, Accessed on 2019.
a certificate from channels or Merkle proof from the PNSB ) and [20] Al-Bassam, M., Sonnino, A., Bano, S., Hrycyszyn, D., and Danezis, G.
Chainspace: A Sharded Smart Contracts Platform. NDSS (2017).
effectively ignores the other one. The adversary could then inject [21] Back, A., Corallo, M., Dashjr, L., Friedenbach, M., Maxwell, G., Miller, A.,
message inconsistency to make the protocol execution favors one Poelstra, A., Timón, J., and Wuille, P. Enabling Blockchain Innovations with
type of attestations over the other. This makes it impossible for S Pegged Sidechains. URL: tinyurl. com/mj656p7 (2014).
[22] Blackshear, S., Cheng, E., Dill, D. L., Gao, V., Maurer, B., Nowacki, T., Pott,
to always accurately emulate its behaviors, resulting in difference A., Qadeer, S., Rain, Russi, D., Sezer, S., Zakian, T., and Zhou, R. Move: A
between the ideal world and the real world from E’s view. language with programmable resources. Tech. rep., The Libra Association, 2019.
To incorporate the Byzantine corruption model into our security [23] Borders, K., Springer, J., and Burnside, M. Chimera: A Declarative Language
for Streaming Network Traffic Analysis. In USENIX Security Symposium (2012).
analysis, we consider a variant of ProtUIP , referred to as H-ProtUIP , [24] Breidenbach, L., Cornell Tech, I., Daian, P., Tramer, F., and Juels, A. Enter the
that requires PVES and PCLI to only use PNSB as the communication Hydra: Towards Principled Bug Bounties and Exploit-Resistant Smart Contracts.
In 27th USENIX Security Symposium (2018).
medium. Thus, the full granularity of protocol execution is guar- [25] Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., and Maxwell, G.
anteed to be public and unique, allowing S to emulate whatever Bulletproofs: Short proofs for Confidential Transactions and More. In 2018 IEEE
actions a (corrupted) part may take in the real world. Therefore, it Symposium on Security and Privacy (SP) (2018), IEEE, pp. 315–334.
[26] Buterin, V. Chain Interoperability. R3 Reports (2016).
is not hard to conclude the Theorem 8.2. [27] Buterin, V., et al. A Next-Generation Smart Contract and Decentralized Appli-
cation Platform. white paper (2014).
9 CONCLUSION [28] Canetti, R. Universally Composable Security: A New Paradigm for Crypto-
graphic Protocols. In IEEE Symposium on Foundations of Computer Science (2001).
In this paper, we presented HyperService, the first platform that [29] Cheng, R., Zhang, F., Kos, J., He, W., Hynes, N., Johnson, N. M., Juels, A.,
offers interoperability and programmability across heterogeneous Miller, A., and Song, D. Ekiden: A Platform for Confidentiality-Preserving,
Trustworthy, and Performant Smart Contract Execution. In IEEE EuroS&P (2019).
blockchains. HyperService is powered by two innovative designs: [30] Costan, V., and Devadas, S. Intel SGX explained, Accessed on 2019. https:
HSL, a programming framework for writing cross-chain dApps by //eprint.iacr.org/2016/086.pdf.
[31] Dingledine, R., Mathewson, N., and Syverson, P. Tor: The Second-Generation
unifying smart contracts written in different languages, and UIP, Onion Router. In USENIX Security Symposium (2004).
the universal blockchain interoperability protocol designed to se- [32] Eyal, I., Gencer, A. E., Sirer, E. G., and Van Renesse, R. Bitcoin-NG: A Scalable
curely realize the complex operations defined in these dApps on Blockchain Protocol. In USENIX NSDI (2016).
[33] Gao, P., Xiao, X., Li, D., Li, Z., Jee, K., Wu, Z., Kim, C. H., Kulkarni, S. R., and
blockchains. We implemented a HyperService prototype in approx- Mittal, P. SAQL: A Stream-based Query System for Real-time Abnormal System
imately 35,000 lines of code to demonstrate its practicality, and ran Behavior Detection. In USENIX Security Symposium (2018).
experiments on the prototype to report the end-to-end execution [34] Gao, P., Xiao, X., Li, Z., Jee, K., Xu, F., Kulkarni, S. R., and Mittal, P. AIQL:
Enabling Efficient Attack Investigation from System Monitoring Data. In USENIX
latency for dApps, as well as the aggregated platform throughput. ATC (2018).
[35] Garay, J., Kiayias, A., and Leonardos, N. The Bitcoin Backbone Protocol with
10 ACKNOWLEDGMENTS Chains of Variable Difficulty. In Annual International Cryptology Conference
(2017).
We thank the anonymous reviewers for their valuable feedback. We [36] Gazi, P., Kiayias, A., and Zindros, D. Proof-of-stake Sidechains. In IEEE
Symposium on Security & Privacy (2019).
thank Harmony Protocol for their discussion on cross-shard trans- [37] Green, M., and Miers, I. Bolt: Anonymous Payment Channels for Decentralized
actions. This material is based upon work partially supported by Currencies. In ACM CCS (2017).
NSF under Contract Nos. CNS-1717313 and TWC-1518899, and by [38] Herlihy, M. Atomic Cross-Chain Swaps. In ACM PODC (2018).
[39] Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S. M., and Felten, E. W.
National Key Research and Development Program of China under Arbitrum: Scalable, Private Smart Contracts. In USENIX Security Symposium
grant No. 2018YFB0803605 and NSFC under grant No. 61702045. (2018).
Correspondence authors are Zhuotao Liu and Haoyu Wang. [40] Khalil, R., and Gervais, A. Revive: Rebalancing Off-blockchain Payment Net-
works. In ACM CCS (2017).
[41] Kiayias, A., and Zindros, D. Proof-of-work Sidechains. Tech. rep., Cryptology
REFERENCES ePrint Archive, Report 2018/1048, 2018.
[1] Cosmos WhitePaper. https://cosmos.network/resources/whitepaper, 2019. [42] Killian, C. E., Anderson, J. W., Braud, R., Jhala, R., and Vahdat, A. M. Mace:
[2] Harmony: Technical Whitepaper. https://harmony.one/whitepaper.pdf, 2019. Language support for building distributed systems. In ACM PLDI (2007).
[3] Monoxide: Scale Out Blockchain with Asynchronized Consensus Zones. In [43] Kogias, E. K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., and Ford, B. En-
USENIX NSDI (2019). hancing Bitcoin Security and Performance with Strong Consistency via Collective
[4] Open Source Code for HyperService by HyperService-Consortium. https://github. Signing. In USENIX Security Symposium (2016).
com/HyperService-Consortium, 2019. [44] Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., and Ford, B.
[5] Bitcoin Wiki: Atomic Cross-Chain Trading. https://en.bitcoin.it/wiki/Atomic_ OmniLedger: A Secure, Scale-out, Decentralized Ledger via Sharding. In IEEE
swap, Accessed on 2019. Symposium on Security and Privacy (2018).
[6] CoinMarketCap. https://coinmarketcap.com, Accessed on 2019. [45] Kosba, A., Miller, A., Shi, E., Wen, Z., and Papamanthou, C. Hawk: The
[7] Cosmos. https://cosmos.network, Accessed on 2019. Blockchain Model of Cryptography and Privacy-preserving Smart Contracts. In
[8] DPOS Consensus Algorithm. https://steemit.com/dpos/@dantheman/dpos- IEEE Symposium on Security and Privacy (2016).
consensus-algorithm-this-missing-white-paper, Accessed on 2019. [46] Krupp, J., and Rossow, C. teEther: Gnawing at Ethereum to Automatically
Exploit Smart Contracts. In USENIX Security Symposium (2018).
[47] Lamport, L. Time, Clocks, and the Ordering of Events in a Distributed System. [56] Sergey, I., and Hobor, A. A Concurrent Perspective on Smart Contracts. In
Communications of the ACM (1978). Financial Cryptography and Data Security (2017).
[48] Lamport, L., Shostak, R., and Pease, M. The Byzantine Generals Problem. ACM [57] Sommer, R., Vallentin, M., De Carli, L., and Paxson, V. Hilti: An abstract
Transactions on Programming Languages and Systems (TOPLAS) (1982). execution environment for deep, stateful network traffic analysis. In IMC (2014).
[49] Lee, D., Kohlbrenner, D., Shinde, S., Song, D., and Asanović, K. Keystone: A [58] Vallentin, M., Paxson, V., and Sommer, R. VAST: A Unified Platform for
Framework for Architecting TEEs. arXiv preprint arXiv:1907.10119 (2019). Interactive Network Forensics. In USENIX NSDI (2016).
[50] Loo, B. T., Condie, T., Garofalakis, M., Gay, D. E., Hellerstein, J. M., Maniatis, [59] Van Saberhagen, N. CryptoNote v 2.0. https://cryptonote.org/whitepaper.pdf,
P., Ramakrishnan, R., Roscoe, T., and Stoica, I. Declarative networking: 2013.
Language, execution and optimization. In SIGMOD (2006). [60] Wood, G. Ethereum: A secure decentralised generalised transaction ledger.
[51] Luu, L., Chu, D.-H., Olickel, H., Saxena, P., and Hobor, A. Making Smart Ethereum Project Yellow Paper (2014).
Contracts Smarter. In ACM CCS (2016). [61] Zamani, M., Movahedi, M., and Raykova, M. RapidChain: Scaling Blockchain
[52] Luu, L., Narayanan, V., Zheng, C., Baweja, K., Gilbert, S., and Saxena, P. A via Full Sharding. In ACM CCS (2018).
Secure Sharding Protocol for Open Blockchains. In ACM CCS (2016). [62] Zamyatin, A., Harz, D., Lind, J., Panayiotou, P., Gervais, A., and Knottenbelt,
[53] Malavolta, G., Moreno-Sanchez, P., Kate, A., Maffei, M., and Ravi, S. Con- W. XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets. In IEEE
currency and Privacy with Payment-channel Networks. In ACM CCS (2017). Symposium on Security and Privacy (2019).
[54] Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin. [63] Zhang, F., Cecchetti, E., Croman, K., Juels, A., and Shi, E. Town Crier: An
org/bitcoin.pdf, 2008. Authenticated Data Feed for Smart Contracts. In ACM CCS (2016).
[55] Parr, T. Antlr. https://www.antlr.org/, 2014.
A APPENDIX generated by any HyperService sessions into the StatusMT. An
alternative design for building StatusPool is via the CloseureWatch-
A.1 Specification of ProtNSB and ProtBC
ing which proactively watches all underlying blockchains to col-
The detailed protocol description of ProtNSB and ProtBC is given lected the transaction Merkle roots and state roots packaged in
in Figure 12. We model block generation and consensus in ProtNSB recently finalized blocks. This design is more cost efficient for Hy-
(and ProtBC ) as a discrete clock that proceeds in epochs. The length perService users since they do not need to explicitly claim these
of an epoch is not fixed to reflect the consensus. At the end of roots. Meanwhile, the structure of the StatusMT is changed to the
each epoch, a new block is packaged and added to the append-only same as ActionMT since all its stored data now become static.
public Ledger. Figure 12 further specifies the protocol of each individual honest
The block format of ProtNSB is shown in Figure 5. Each block peer/miner in the NSB to ensure the correctness of both interfaces.
packages two special Merkle trees (i.e., ActionMT and StatusMT) By complying with the protocol, honest peers accept any received
and other Merkle trees (e.g., TxMT) that are common in both ProtNSB claim (i.e., a Merkle root or transaction claim) only after receiving a
and ProtBC . StatusMT and ActionMT are constructed using the quorum of approvals for the claim. The protocol provably ensures
items in the StatusPool and ActionPool, respectively. Considering the correctness of both interfaces, given that the number of Byzan-
the size limit of one block, some items in these pools may not be tine nodes in the permissioned NSB is no greater than the security
included (e.g., due to lower gas prices or random selections), and parameter K [48].
will be rolled over to the next epoch. The ActionPool is constructed in a similar manner as the Sta-
StatusPool is constructed via the CloseureClaim interfaces exe- tusPool. In Figure 12, an interface annotated with override is also
cuted by all NSB peers. The CloseureClaim directly listens for trans- implemented by ProtBC , although the implementation detail may be
actions claimed by HyperService users (VESes and dApp clients). different; for instance ProtBC may have different consensus process
This design avoids including irrelevant transactions that are not than ProtNSB in the DiscreteTimer interface.
 1 Init: Data := ∅; Epoch := 0; Ledger := [] 26 Daemon CloseureWatching({ProtBC , ...}): Proactive Streaming Version
2 Daemon DiscreteTimer() override: 27 proactively watch ProtBC for recently finalized blocks { B, ... }
3 continue if the current Epoch is not expired 28 (_, _, StatusPool) := Data[Epoch]; abort if not found
4 (TxPool, ActionPool, StatusPool) := Data[Epoch] 29 retrieve the root Rtx of TxMT and Rstate of StateMT on B
5 initialize a block B with the format shown in Figure 5 30 update StatusPool.Add(Rtx, Rstate )
6 for pool ∈ (TxPool, ActionPool, StatusPool) : 31 # Protocol of an individual honest peer V to ensure correctness
7 construct a (sorted) Merkle tree with selected items in pool 32 Init: V .StatusPool := []
8 populate B with the Merkle tree (TxMT, ActionMT, or StatusMT) 33 Daemon Watching({ProtBC , ...}) and Watching(B, S = {Sig, ... })
9 remove these selected items from pool 34 abort if B is not finalized on ProtBC or B is processed before
10 update Ledger.append(B) and execute trans. captured under TxMT 35 abort if S contains more than K distinguished signatures
11 start a new epoch Epoch := Epoch + 1 36 retrieve the root Rtx of TxMT and Rstate of StateMT on B
12 initialize Data[Epoch] := [TxPool, ActionPool, StatusPool] 37 S.Add(Cert([Rtx, Rstate ]; SigV )); V .StatusPool.Add(Rtx, Rstate )
13 Daemon CloseureClaim(Te, [ChainID, StateRoot, TxRoot ]): 38 multicast (B, S) to other peers of the NSB
14 (_, _, StatusPool) := Data[Epoch]; abort if not found 39 Upon Receive AddAction(Cert):
15 update StatusPool.Add(Te) 40 (_, ActionPool, _) := Data[Epoch]; abort if not found
16 # Protocol of an individual honest peer V to ensure correctness 41 update ActionPool.Add(Cert)
17 Init: V .StatusPool := [] 42 # Similar correctness protocol as in CloseureClaim for honest peers
18 Daemon Watching(Te, S = {Sigpeer, ... }) 43 Upon Receive Exec(Te) override:
19 abort if Te is already in V .StatusPool 44 abort if Te is not correctly constructed and signed
20 abort if S contains more than K distinguished signatures 45 (TxPool, _, _) := Data[Epoch]; abort if not found
21 abort if Te is not finalized on its destination blockchain (ChainID) 46 update TxPool.Add(Te)
22 abort if the reported StateRoot and TxRoot are not authentic 47 Upon Receive BlockHeight() override:
23 update V .StatusPool.Add(Te) 48 return the block number of the last block on Ledger
24 update S.Add(Cert([Te, [ChainID, StateRoot, TxRoot]]; SigV )) 49 Upon Receive MerkleProof(key) override:
25 multicast (Te, S) to other peers of the NSB 50 find the block B on Ledger containing key; abort if not found
51 return a hash chain from key to the Merkle root on B

Figure 12: Detailed protocol description of ProtNSB . Interfaces annotated with override are also implemented by ProtBC . Gray
background denotes the protocol of honest peers in the NSB to ensure the correctness for the corresponding interface.