Authors: Rongjian Lan, Ganesha Upadhyaya, Stephen Tse, Mahdi Zamani (Visa Research)

Harmony ONE-ETH Bridge

1 Introduction

A unifying vision of the distributed ledger technology is to connect multiple distributed systems together. While the disruption of financial infrastructure is still early, now is the time to bring many protocols together to scale their innovations for broader adoption. Cross-chain bridges provide broader access of users and assets to decentralized finance. In particular, lending Bitcoin for high-yield financial instruments on Ethereum has surpassed US $1B on-chain management. Cross-chain transactions are more than asset transfers via atomic swaps with hash time locked contracts.

A relay bridge implements a bi-directional relay of block headers between two blockchains. In such a bridge, block headers of blockchain A are constantly being submitted to a smart contract in blockchain B, which implements a light client logic to verify the validity of the headers. And analogously headers from blockchain B are submitted to a smart contract in blockchain A.

A simple example is the BTC relay which implements a uni-directional relay from Bitcoin to Ethereum. There, the Ethereum smart contract computes the difficulty of the submitted Bitcoin headers. A proof for the validity of each header amounts to checking it resides on the longest chain of submitted headers.

Light clients [1–3] can be used to perform cross-chain transactions efficiently. Such transactions can happen when exchanging cryptocurrencies [4, 5], transferring assets to sidechains [2, 6, 7], or sharding blockchains [8, 9]. Such clients enable a user to generate short cryptographic inclusion proofs about past events recorded on a blockchain. In a proof-of-work (PoW) blockchain such as

Bitcoin [10] and Ethereum [11], this can be done by providing the sequence of all block headers to prove to any verifier that the event is recorded on the honest chain that is the longest, or more precisely, the most computationally-difficult chain.

An important characteristic of many light client proofs is portability, i.e., they can be forwarded to other nodes on other blockchain networks to convince them that a certain event was recorded on the source blockchain. While light clients for PoW chains have been proposed starting with Bitcoin’s SPV client [10] and later in PoPoW [2, 12] and FlyClient [3], no light client has been proposed for proof-of-stake chain that rely on Byzantine fault tolerance (BFT) for consensus. Designing a light client for such chains is challenging. While aggregate signatures contain a sufficient number of attestations, we do not know if those attestations actually come from validators that actually have stake. The only way to know this is if we know the balance (i.e., state) of every validator which is what a full node does.

[This work was done when the author Mahdi Zamani was affiliated with Yale University.]

1.1 Our Contributions

We propose a gas-efficient, cross-chain bridge protocol to transfer assets from a BFT blockchain to another blockchain (e.g., Ethereum) which supports basic smart contract execution. To achieve this, our paper makes the following contributions:

• We construct a super-light client for BFT chains that allows a client to prove to any external entity that a transaction has been recorded on the BFT chain by providing cryptographic proof that is constant size in the length of the chain.
• We construct a bridge smart contract on the destination chain for atomic verification of super-light client proofs that guarantee a certain amount of tokens are locked on the BFT chain. The contract also can unlock/mint an equal amount of tokens on the destination blockchain once the verification succeeds.
• We construct a relay node that periodically transmits to the contract constant-size, check-point information as commitments to the BFT chain. This information allows the contract to later verify super-light client proofs submitted by the client to the contract. While the total amount of information submitted by the relay to the contract for all checkpoints is linear to the chain length, the frequency of checkpoints could be adjusted in practice to curb this overhead.
• We propose an efficient chain commitment mechanism that allows the client to prove inclusion of a block in a blockchain with a constant-size commitment and logarithmic blockchain inclusion proofs.
• We further propose a stateless bridge contract design that allows the client to send a small, self-sufficient cross-chain transaction to the contract that does not require any pre-relayed checkpoint information. Our solution requires the client to include only a logarithmic-size (in the chain length) inclusion proof in its message, making it the first BFT bridge protocol that requires logarithmic-size, cross-chain proofs.