PaperlayerView exact revision on arXiv

Source-linked AI summary

HyperService: Interoperability and Programmability Across Heterogeneous Blockchains

Zhuotao Liu, Yangxi Xiang, Jian Shi, Peng Gao, Haoyu Wang, Xusheng Xiao, Bihan Wen, Yih-Chun Hu

arXiv:1908.09343v3cs.CR

TL;DR

Existing interoperability protocols mostly focus on atomic token exchange, although smart-contract blockchains support programmable state machines. HyperService combines a unified cross-chain programming framework with a cryptography protocol; its prototype reports end-to-end execution latency in the order of seconds. The paper also identifies a boundary: UIP cannot revert smart-contract state updates when a dApp terminates prematurely.

  • Problem

    Existing interoperability proposals mostly center on atomic token exchange, while programmable blockchains make cross-chain dApps executable across disconnected state machines relevant.

    Source: §1 · p. 1

  • Method

    HyperService pairs a unified programming framework for cross-chain dApps with UIP, a cryptography protocol that securely realizes their operations on blockchains.

    Source: §1 · p. 2

  • Results

    End-to-end dApp execution latency is in the order of seconds, and HyperService can continuously incorporate new production blockchains.

    Source: §1 · p. 2

  • Takeaways & Limitations

    HyperService provides a platform offering interoperability and programmability across heterogeneous blockchains.

    Source: §9 · p. 18

    UIP cannot revert smart-contract state updates if dApps terminate prematurely, so the current system is not fully dApp-atomic.

    Source: §6.4 · p. 14

Abstract

from arXiv · show

Blockchain interoperability, which allows state transitions across different blockchain networks, is critical functionality to facilitate major blockchain adoption. Existing interoperability protocols mostly focus on atomic token exchange between blockchains. However, as blockchains have been upgraded from passive distributed ledgers into programmable state machines (thanks to smart contracts), the scope of blockchain interoperability goes beyond just token exchange. In this paper, we present HyperService, the first platform that delivers interoperability and programmability across heterogeneous blockchains. HyperService is powered by two innovative designs: (i) a developer-facing programming framework that allows developers to build cross-chain applications in a unified programming model; and (ii) a secure blockchain-facing cryptography protocol that provably realizes those applications on blockchains. We implement a prototype of HyperService in about 35,000 lines of code to demonstrate its practicality. Our experiment results show that HyperService imposes reasonable latency, in order of seconds, on the end-to-end execution of cross-chain applications

1 INTRODUCTION

HyperService extends blockchain interoperability beyond token exchange to programmable dApps across heterogeneous chains. It combines a unified developer framework with UIP and reports prototype execution latency in seconds.

1 INTRODUCTION

  • Existing interoperability protocols mostly center on atomic token exchange, while programmable blockchains call for dApps executable across disconnected state machines.The paper argues interoperability is complete only with programmability.Source: §1 · p. 1
  • Cross-chain dApps need a unified way to specify interactions among heterogeneous contracts and accounts, plus decentralized coordination of transactions with preconditions and deadlines.The paper identifies virtualization and trust-free transaction coordination as separate challenges.Source: §1 · p. 1
  • HyperService provides a developer framework with USM and HSL, then compiles HSL dApps into executables for the underlying cryptography protocol.The framework virtualizes heterogeneous blockchains, while UIP securely realizes the resulting dApps on-chain.Source: §1 · p. 2
  • UIP is designed to realize complex cross-chain operations beyond token exchange, and its security properties are expressed as an ideal functionality that UIP is proven to realize in the UC framework.The paper describes UIP as fully trust-free.Source: §1 · p. 2
  • End-to-end dApp execution latency is in the order of seconds, and the platform can continuously incorporate new production blockchains.The prototype comprises approximately 35,000 lines of code and was evaluated with three categories of cross-chain dApps.Source: §1 · p. 2

2 HYPERSERVICE OVERVIEW

HyperService combines lightweight dApp clients, VES blockchain drivers, the NSB, and ISCs with a programming model that treats heterogeneous blockchain objects as local. HSL specifies cross-chain operations and dependencies; UIP coordinates their verifiable execution under stated assumptions.

2.1 Architecture

  • The architecture has four components: lightweight dApp clients, VES blockchain drivers, the NSB for unified execution status, and ISCs for arbitration and financial rollback.VESes compile client programs into blockchain-executable transactions; NSB status supports ISC arbitration of correctness or violations.Source: §2.1 · p. 2

2.2 Universal State Model

  • USM virtualizes heterogeneous blockchains as entities with public state and functions, and specifies operations and their dependencies as if the objects were local.Its entities include accounts and contracts; operations include payments and contract invocations, while dependencies include preconditions and deadlines.Source: §2.2 · pp. 2–3

2.3 HyperService Programming Language

  • HSL is the programming language for writing cross-chain dApps under the USM model.The language demonstrates how developers can express operations over objects on different chains.Source: §2.2 · p. 2, §2.3 · p. 3

2.3.1 An Introductory Example for HSL Programs

  • The option example uses a shared ChainX Broker for strike prices in Option contracts on ChainY and ChainZ, allowing investors to exercise with preferred cryptocurrencies.The example addresses the difficulty of making an oracle dependable and accessible across blockchains.Source: §2.3.1 · p. 3

2.3.2 HSL Program Compilation

  • The HSL compiler checks programs and multi-language contract interfaces, then emits Transaction Dependency Graph executables with transactions, metadata, preconditions, and deadlines.VESes own the compiler and offer dApps service models with reachability, fees, and insurance plans.Source: §2.3.2 · pp. 3–4

2.4 Universal Inter-Blockchain Protocol (UIP)

  • UIP securely executes HSL executables on public-ledger blockchains, using the NSB for unified transaction-status views and action proofs and ISCs to arbitrate correctness and accountability.The paper states that UIP realizes its ideal functionality in the UC framework.Source: §2.4 · p. 4

2.5 Assumptions and Threat Model

  • Security assumes secure cryptography and blockchain finality with public ledgers, an honest NSB quorum, and at least one uncompromised protocol participant.The stated NSB assumption is that at least K consensus nodes are honest.Source: §2.5 · p. 4

3 PROGRAMMING FRAMEWORK

The programming framework compiles HSL programs into transaction dependency graphs, using a unified model for heterogeneous contracts and validations to check their operations and dependencies. These graphs direct UIP’s cross-chain execution.

3 PROGRAMMING FRAMEWORK

  • The HSL compiler extracts program and contract information, applies a unified type system, validates semantics, and outputs an executable transaction dependency graph.Its two front ends extract entities, operations, and dependencies from HSL and public variables and methods from deployed contracts.Source: §3 · p. 4

3.1 Unified Type System

  • The Unified Type System maps supported contract-language types to common types so HSL can express invocations across heterogeneous contract entities.Complex data types as contract-function parameters are not fully supported in production and are left for future work.Source: §3.1 · p. 5

3.2 HSL Language Design

  • HSL defines entities, payment and invocation operations, and dependencies that specify operation preconditions and deadlines.Invocation arguments can include literals or other entities’ state variables; deadlines can be specified in NSB blocks or time units.Source: §3.2 · pp. 5–6

3.3 Semantic Validation

  • Semantic validation checks invocation argument type compatibility and public verifiability, and ensures dependencies uniquely define a directed acyclic graph.Method return values that are not persisted on-chain are ineligible as invocation arguments, supporting publicly verifiable attestations during execution.Source: §3.3 · p. 6

3.4 HSL Program Executables

  • Each transaction-graph vertex carries information for computing a blockchain-specific transaction, while its edges encode HSL preconditions.Metadata includes fund-reversion information and, when downstream transactions use a transaction’s resulting state, a state proof; cross-chain payments generate multiple transactions using VES-owned relay accounts. Deadlines are measured in NSB blocks, with time intervals converted to blocks.Source: §3.4 · p. 6

4 UIP DESIGN DETAIL

UIP executes HSL-generated transaction graphs through protocols for clients, VESes, the NSB, and the ISC. It tracks transaction states and attestations to support execution, verification, and arbitration.

4 UIP DESIGN DETAIL

  • ProtUIP has an execution phase that posts transactions specified by HSL executables and an insurance-claim phase that arbitrates execution correctness or violations.Its preliminary protocols specify behavior for VESes, clients, the NSB, the ISC, and general-purpose blockchains.Source: §4 · p. 7

4.1.1 Runtime Transaction State

  • Each transaction advances through ordered runtime states, with an attestation for each non-unknown state; ProtISC uses the collective transaction states to arbitrate the HSL program’s outcome.The progression is unknown, init, inited, open, opened, then closed.Source: §4.1.1 · p. 7

4.1.2 Off-Chain State Channels

  • Off-chain state channels support low-latency ProtVES–ProtCLI exchanges, while Proofs of Actions preserve execution steps on the NSB for accountability when exceptions occur.The NSB serves as a publicly observable fallback communication medium, preserving the exchange’s full granularity if needed for accountability enforcement.Source: §4.1.2 · p. 7

4.1.3 Architecture of the NSB

  • NSB blocks add StatusRoot and ActionRoot to common blockchain fields, committing relevant underlying-chain status and execution-action certificates.StatusMT stores relevant blockchain transaction status; ActionMT stores VES and client certificates that can be proven against committed NSB blocks. The StatusMT structure supports sharding by underlying blockchain as HyperService adds chains.Source: §4.1.3 · p. 7

4.2.1 Post Compilation and Session Setup

  • After graph generation, ProtVES initializes an execution session by creating an insurance contract with ProtISC, obtaining client agreement, and deploying it on the NSB.Both ProtVES and ProtCLI deposit funds to cover reversions of committed transactions; the stake can account for dependency requirements in the graph.Source: §4.2.1 · pp. 7, 9

4.2.2 Protocol Exchange for Transaction Handling

  • ProtVES handlers process transaction attestations, check freshness against NSB height, and post the executable transaction to its destination chain after correctness checks.Closing a transaction uses both destination-chain finalization evidence and an NSB status proof; the former also supports verification of state used by downstream transactions.Source: §4.2.2 · p. 9

4.2.3 Proactive Watching Services

  • ProtVES proactively watches underlying chains and the NSB to detect finalization, retrieve proofs, progress eligible transactions, and recover certificates missing from the off-chain channel.If a client is slow or unresponsive after a closing request, ProtVES can retrieve the NSB status-proof component of the complete on-chain proof.Source: §4.2.3 · pp. 9–10

4.2.4 ProtISC Invocation

  • ProtVES invokes ProtISC with the most advanced available attestation for each transaction, because lower-ranked attestations are ignored.Source: §4.2.4 · p. 10

4.3 Execution Protocol by dApp Clients

ProtCLI defines client-side handlers that match ProtVES handlers for initializing, opening, and closing transactions. Its watching requirements are deliberately lighter than ProtVES’s.

4.3 Execution Protocol by dApp Clients

  • ProtCLI pairs handlers with ProtVES to process attestations for client-originated and VES-originated transactions and to negotiate closing attestations.It need not watch underlying blockchains or dynamically compute eligible transactions, but it watches the NSB as a fallback communication medium and should check self-originated transaction status to request closing.Source: §4.3 · p. 10

4.4 Protocol Realization of the ISC

ProtISC creates and executes an insurance contract that tracks transaction states and evaluates submitted attestations. At timeout, it settles the contract by checking deadlines and assigning responsibility for dirty transactions.

4.4 Protocol Realization of the ISC

  • ProtISC generates arbitration code from the dApp executable, tracks transaction states as attestations arrive, and executes contract terms at timeout.After timeout execution, the contract’s funds are depleted and it does not run again.Source: §4.4 · pp. 10–11

4.4.1 Insurance Claim

  • ProtISC accepts dual-signed certificates or complete Merkle proofs, checking proof certificates’ signers, transaction associations, and timestamp freshness.For timestamp freshness, the certificate’s tsopen must be within a bounded difference of the NSB block height attaching the proof.Source: §4.4.1 · p. 11

4.4.2 Contract Term Settlement

  • At settlement, ProtISC marks deadline-compliant closed transactions correct; execution succeeds only when no eligible transaction remains dirty.Otherwise, its decision tree assigns responsibility based on transaction state: the originator is responsible for open, opened, or closed states, while other states assign responsibility to the destination, dApp client, or VES as specified.Source: §4.4.2 · p. 11

4.5 Specification of ProtNSB and ProtBC

This section specifies conceptual protocols for general-purpose blockchains and the NSB, then states the security goal and proof strategy for UIP.

4.5 Specification of ProtNSB and ProtBC

  • ProtBC models consensus nodes agreeing on public global state, while ProtNSB extends that general-purpose blockchain specification with additional capabilities.ProtBC is treated as conceptually trusted for correctness and availability, including correct execution of predefined computations and handling requests despite unbounded response latency.Source: §4.5 · p. 11

4.6 Security Theorems

  • FUIP defines UIP’s desired correctness and security properties by assuming a trusted entity.It serves as the ideal functionality against which the decentralized protocol is proved.Source: §4.6 · p. 11
  • ProtUIP is proved to realize FUIP in the UC framework without trusted authorities.The detailed proof, including simulator construction, is deferred to § 8.Source: §4.6 · p. 11

5 IMPLEMENTATION AND EXPERIMENTS

The prototype implements HyperService across heterogeneous blockchains and three cross-chain dApp categories. Experiments profile execution latency and NSB throughput, while the discussion estimates aggregate capacity and describes onboarding additional blockchains.

5 IMPLEMENTATION AND EXPERIMENTS

  • The prototype comprises approximately 35,000 lines of code and incorporates Ethereum, a Tendermint-based permissioned blockchain, and the NSB.The implementation includes the HSL framework, UIP, NSB, and cross-chain dApps.Source: §5 · p. 11, §5.1 · p. 11

5.1 Platform Implementation

  • Adding a blockchain is described as requiring no UIP or blockchain protocol changes, but may require a parser for its programming language and extending VES visibility.The HSL compiler parses programs and contracts, converts contract entities to unified types, and validates entities, operations, and dependencies.Source: §5.1 · pp. 11–12

5.2 Application Implementation

  • The implemented dApps cover financial derivatives, cross-chain asset movement, and federated computing, including options, hybrid asset transfers, and federated voting.The prototype uses blockchains as data oracles for the financial-derivatives application.Source: §5.2 · p. 12

5.3.1 End-to-End Latency

  • The experiments evaluate all three dApps and report HyperService-introduced end-to-end latency, including compilation, session creation, and batched NSB staking and proof retrieval.Measurements average more than 100 runs and include global Internet networking, but exclude on-chain execution and offline ISC insurance claims.Source: §5.3.1 · p. 12, Table 3 · p. 12
  • Session creation is the most time-consuming phase across the three evaluated dApps, including client–VES handshakes and ISC deployment and initialization.CryptoAsset has lower HSL compilation latency because it involves one smart contract; the other two dApps import three contracts.Source: §5.3.1 · p. 12, Table 3 · p. 12

5.3.2 NSB Throughput and HyperService Capacity

  • As certificate batch size grows, NSB throughput converges to about 1000 kilobytes per second, while further batching raises staking failure rates.The failure-rate increase indicates that the NSB is fully loaded.Source: Figure 10 · p. 12, §5.3.2 · p. 13
  • With all client–VES off-chain channels broken, the estimated lower bound is about 170000/s, where s is average certificate size in bytes.This bound assumes up to six NSB transactions per dApp transaction; the authors anticipate sharding and the share of non-cross-chain traffic will keep the NSB from becoming a future bottleneck.Source: §5.3.2 · p. 13

6 DISCUSSION

The discussion identifies extensions and scope boundaries for HyperService, including dynamic transactions, cross-shard use, service-provider roles, dApp atomicity, and privacy-preserving chains.

6.1 Programming Framework Extension

  • Future UIP extensions target dynamic transaction graphs, enabling conditional execution and state-dependent repetition, with static and dynamic verification planned for HSL.The current programming framework’s extension is framed as future work.Source: §6.1 · p. 13

6.2 Cross-Shards and Cross-Worlds

  • HyperService’s blockchain-neutral HSL model can also describe cross-shard dApps, which the authors say are simpler to develop for homogeneously sharded chains.They note that an NSB for homogeneous shards is more lightweight; centralized platforms could also be incorporated if their public state has verifiable proofs and finality.Source: §6.2 · p. 13

6.3 Cross-Chain Interoperability Service Providers

  • VESes are envisioned as Cross-chain Interoperability Service Providers, with reachability, liquidity, service fees, and insurance plans shaping their offerings.The authors envision a UIP-connected CSP liquidity network; dApps may also be co-executed by multiple VESes when no single provider has sufficient reachability or staking funds.Source: §6.3 · pp. 13–14

6.4 Complete Atomicity for dApps

  • The current UIP cannot revert smart-contract state updates after premature dApp termination, a challenge the authors connect to blockchain finality.They propose stateless smart contracts that load state from blockchains, allowing later dApps to load clean state from an earlier agreed block.Source: §6.4 · p. 14

6.5 Privacy-Preserving Blockchains

  • Privacy-preserving blockchains lack a generic abstraction as programmable state machines, so the proposed interoperability approach is application-specific.One suggested approach is using fast zero-knowledge proofs to certify state extracted from those blockchains.Source: §6.5 · p. 14

7 RELATED WORK

The related-work discussion contrasts HyperService’s heterogeneous, programmable cross-chain stack with token-focused proposals and industry interoperability projects.

7 RELATED WORK

  • Academic interoperability proposals mostly move tokens between two chains, while smart contracting across heterogeneous chains is largely ignored.The cited approaches include side-chains, atomic cross-chain swaps, and cryptocurrency-backed assets.Source: §7 · p. 14
  • Unlike Cosmos’s network-level IBC communications, HyperService combines a unified dApp programming framework with a provably secure execution protocol.The passage also characterizes Cosmos’s and Polkadot’s then-current directions and development status.Source: §7 · p. 14
  • HyperService’s HSL unifies heterogeneous contract languages and types, whereas existing domain-specific languages cited here target other domains.The passage names Solidity, Vyper, Go, Javascript, and C++ among the contract languages and tailored languages discussed.Source: §7 · p. 14

8 SECURITY THEOREMS

Section 8 defines an ideal functionality for UIP and proves that the decentralized protocol realizes it under stated cryptographic assumptions. It then sketches the UC simulation proof and extends Byzantine security through a PNSB-only variant.

8.1 Ideal Functionality FUIP

  • FUIP takes a transaction dependency graph and arbitration contract at session setup, tracks transaction status and on-chain counterparts, and attests state updates to both parties.Its blockchain abstraction assumes only public-ledger queries and transaction-triggered state transitions, without constraints on ledger format or consensus logic.Source: §8.1 · p. 15
  • After the agreed timeout, FUIP yields correct completion with preconditions and deadlines satisfied, or failure with financial reversion, and holds misbehaving parties accountable.With bounded transaction-finality latency, Op is guaranteed to finish correctly if both parties are honest; the contract is public, while privacy-preserving blockchains remain future work.Source: §8.1 · p. 15

8.2 Main Security Theorems

  • Under the stated consensus, hash, and signature assumptions, ProtUIP UC-realizes FUIP against passive corruption; H-ProtUIP achieves Byzantine-corruption security under the same assumptions.H-ProtUIP requires PVES and PCLI to use PNSB as their only communication medium.Source: §8.2 · p. 15

8.3 Proof Overview

  • The UC proof compares real and ideal executions by showing that, for each adversary, a simulator can make the environment's outputs differ by at most a negligible amount.The ideal protocol wraps FUIP in dummy parties that relay inputs and outputs; the simulator reproduces real-world effects such as attestations and contract invocations.Source: §8.3 · pp. 15–16

8.4 Construction of the Ideal Simulator S

  • The simulator maps environment instructions for session setup and transaction-state changes to corresponding FUIP calls, handling the VES and client interfaces differently where needed.For contract invocation, it locally executes the contract and instructs FUIP to publish the updated contract.Source: §8.4 · pp. 16–17

8.5 Indistinguishability of Real and Ideal Worlds

  • The proof replaces real parties with ideal dummies in stages; the simulator and FUIP preserve outputs and side effects so the environment cannot distinguish the real and ideal worlds.The proof includes replacing PNSB with its dummy, whose public structure and messages make simulation straightforward.Source: §8.5 · p. 17

8.6 Byzantine Corruption Model

  • Conflicting attestations from Byzantine-corrupted parties can prevent faithful simulation when the protocol accepts only the first received attestation; H-ProtUIP addresses this by requiring PNSB-only communication.With this restriction, execution details are public and unique, allowing the simulator to emulate a corrupted party's actions.Source: §8.6 · p. 18

9 CONCLUSION

HyperService offers interoperability and programmability across heterogeneous blockchains through HSL and UIP. A 35,000-line prototype was used to assess practicality, end-to-end dApp execution latency, and platform throughput.

9 CONCLUSION

  • HyperService combines HSL, which unifies smart contracts written in different languages, with UIP, which securely realizes dApp operations across blockchains.UIP is designed for complex operations defined by cross-chain dApps.Source: §9 · p. 18
  • The authors implemented a HyperService prototype in approximately 35,000 lines of code to demonstrate its practicality.Source: §9 · p. 18
  • Experiments on the prototype report end-to-end dApp execution latency and aggregated platform throughput.Source: §9 · p. 18

A.1 Specification of ProtNSB and ProtBC

ProtNSB and ProtBC model block generation and consensus in epochs, with each epoch adding a block to the public ledger. Pool items feed special Merkle trees, while peer protocols require quorum approvals for claims.

A.1 Specification of ProtNSB and ProtBC

  • At each epoch’s end, a new block is added to the append-only public ledger; epoch length is variable to reflect consensus.Block generation and consensus are modeled as a discrete clock.Source: §A.1 · p. 20
  • ProtNSB blocks package ActionMT and StatusMT from their respective pools, alongside common Merkle trees such as TxMT.Items omitted because of block-size limits, lower gas prices, or random selection roll over to the next epoch.Source: §A.1 · p. 20
  • StatusPool collects user-claimed transactions through ClosureClaim, avoiding unrelated transactions; ClosureWatching instead collects roots automatically and is more cost efficient for users.With ClosureWatching, StatusMT has the same structure as ActionMT because its stored data are static.Source: §A.1 · p. 20
  • Honest NSB peers accept a root or transaction claim only after quorum approval, ensuring both interfaces’ correctness when Byzantine nodes do not exceed K [48].Source: §A.1 · p. 20
  • ActionPool is built similarly to StatusPool; interfaces marked override in Figure 12 are also implemented by ProtBC, whose implementation may differ.Figure 12’s gray background marks the protocol of honest NSB peers used to ensure interface correctness.Source: §A.1 · p. 20, Figure 12 · p. 21
Loading 1908.09343v3…