Horizon [Research Paper]: A Gas-Efficient Trustless Bridge for Cross-Chain Transactions

TL;DR

• If you’re technically inclined, skip to the bottom of the post and read the technical white paper (Scroll 👇 or Download White Paper Here), authored with top researcher Mahdi Zamani.
• A bridge with cross-chain light clients, relayers, and prover full nodes, all trustless, no additional trust assumptions beyond the two blockchains that the bridge is connected to.
• A gas-efficient Harmony light client on Ethereum (could be generalized to other chains) that only requires checkpoint blocks (1 block every x blocks, where 1 ≤ x ≤ 16384, 16384 is the #blocks per epoch) to verify any number of Harmony transaction proofs by the clients.
• A constant-size Harmony light client proof that any user needs to send cross-chain (e.g., Ethereum) to claim their Harmony transaction.

Harmony recently launched Horizon, a bridge for transferring any ERC20 assets between Ethereum and Harmony, powered by a set of trusted validators. Within a couple of weeks after Horizon, Harmony also launched SWOOP, a decentralized exchange (DEX) for swapping assets bridged from Ethereum. Together, Horizon and SWOOP were able to demonstrate Harmony’s low-cost, high-speed, and seamless asset exchange experience for our users (with TVL ~200K USD).

We did not stop there! Harmony’s long-term vision is to provide a trustless, decentralized and open blockchain platform for all people, and cross-chain bridges are no exception. We are proud to release our trustless bridge design whitepaper that describes our innovations on creating a trustless and gas-efficient bridge.

A cross-chain bridge is an application that connects two blockchains and enables transfer of assets between them. The asset transfer is typically done by locking up the asset on one blockchain and minting the equivalent amount of asset on the other blockchain with a facility to burn the minted asset after use to release the locked asset. A typical cross-chain bridge can be categorized based on the mechanism that is used to validate the cross-chain transactions:

1. cross-chain light clients with block relays, e.g., NEAR’s Rainbow bridge
2. cross-chain validators (aka oracles or guardians), e.g., Solana’s Wormhole bridge

Harmony’s trustless bridge took similar approach as 1, but we managed to solve the problem of making the bridge gas-efficient while still keeping it fully trustless with gas-efficient light clients and block relays. To understand our bridge’s design and innovations, let’s take a deeper look at the asset transfer between Ethereum and Harmony.

Ethereum to Harmony

For transferring an asset (e.g., ERC20) from Ethereum to Harmony:

• a client (or a user) first performs a lock transaction that transfers user’s asset to bridge smart contract on Ethereum
• there exists a relay that regularly downloads and sends Ethereum block headers to ELC smart contract on Harmony, such that ELC has sufficient information to verify Proof of lock which will be sent by the clients
• the client may request any full node to obtain Proof of lock and submit a mint transaction to Harmony; the Proof of lock is a simple SPV light client proof that ELC smart contract can verify for lock transaction inclusion
• the bridge smart contract on Harmony mints an equivalent amount of asset to user account after verifying the Proof of lock

Due to Harmony’s low gas cost, every Ethereum block header can be relayed and SPV light client proofs from clients can be effectively verified. This is not the case for Harmony to Ethereum flow due to several reasons:

• Harmony is a Proof of stake BFT-based chain that produces blocks every 3 seconds (more frequent than proof of work chains)
• Verifying Harmony block header requires expensive BLS signature verification and it cannot be done as part of client’s single unlock transactions (very high gas for BLS signature verification on Ethereum in the absence of BLS12-381 precompile)

To solve the above challenges, we have made several innovations as described below.

Harmony to Ethereum

When a user (or a client) wants to redeem their asset (or in other words, burn asset on Harmony and unlock on Ethereum):

• the client will invoke a burn transaction and includes the Ethereum account to receive the redeemed asset
• there exists a relay that downloads and sends one checkpoint block every x blocks, where 1 ≤ x ≤ 16384; the checkpoint block contains the accumulated merkle roots of all the blocks until the previous checkpoint block (MMR root). The HLC smart contract on Ethereum performs one BLS aggregated signature verification to accept the checkpoint block
• the client may request any full node to obtain Proof of burn and submit an unlock transaction to Ethereum; the Proof of burn is a combination of block inclusion proof over MMR and burn transaction inclusion proof that HLC smart contract can verify for burn transaction inclusion
• the bridge smart contract on Ethereum unlocks an equivalent amount of asset that was burned to user account after verifying the Proof of burn

The key components of our trustless bridge are:

• cross-chain light client smart contracts: Ethereum Light Client (ELC) on Harmony and Harmony Light Client (HLC) on Ethereum. The light clients accept the relayed block header after verification, stores them, and also validates proof of lock and proof of burn sent from the clients
• relayers (or relays): Ethereum2Harmony relay sends SPV-style block headers to ELC smart contract on Harmony, whereas Harmony2Ethereum relay sends checkpoint blocks to HLC smart contract on Ethereum
• full nodes (or provers): clients can obtain proof of lock from any Ethereum full node and proof of burn from any Harmony full node

Our key innovations are:

• a checkpoint based Harmony light client on Ethereum that requires only one BLS verification for accepting the checkpoint block (1 block every x blocks, where 1 ≤ x ≤ 16384)
• a constant-size light client proofs of Harmony transactions which can be verified on Ethereum in a gas effective manner

A detailed whitepaper formally describing our trustless and gas-efficient bridge 👇 – or download the pdf file directly.

We have started working on developing this trustless bridge and our progress can be tracked here. We also welcome developers to participate in the bridge development during our upcoming cross-chain hackathon.

Our research paper is accepted for Crosschain Communication 2021. Here is the abstract of the talk. Harmony’s gas-efficient light client and its application to cross-chain in the form of Harmony<>Ethereum two-way bridging.

Harmony is a sharded, Proof of Stake, Byzantine consensus based layer-1 blockchain with 2-second block finality and a network of 1000 decentralized nodes. Harmony’s cross-chain infrastructure is based on its novel design of gas-efficient light client. The gas efficiency is important especially when the light client is deployed cross-chain, like Ethereum.

Harmony produces blocks at a very fast rate of 2 seconds, making it impossible for an SPV-style light client to be cost effective for cross-chain application. Harmony light client employs several innovations to be efficient for cross-chain application.

First, the epoch-based syncing. A light client is a program that downloads and verifies blockchain headers. A simple light client is SPV light client that downloads and verifies every block header. A light client of a Proof-of-Stake blockchain only needs to verify the signatures of the validators who signed the blocks. Since the validator set does not change within an epoch (which is nearly 1 day), the light client only needs to download 1 block header that contains the validator set per epoch. This in itself reduces the light client complexity substantially (1/32768 blocks).

Next, the BLS signature aggregation. Harmony’s consensus mechanism requires a quorum of 2/3 or more validators to sign each block to commit it to the blockchain. Harmony validators use BLS signatures to sign the blocks. Instead of having each of these signatures be separately stored on-chain, one aggregated signature is stored on-chain — a nice property of BLS, which allows such aggregation. This further reduces the work that the light client has to perform for verifying the block.

Finally, the checkpointing based on Merkle Mountain Range (MMR), similar to FlyClient. The epoch-based syncing and BLS signature aggregation alone does not make the light client gas-efficient for cross-chain application. The BLS signature verification performs elliptic curve pairing causing 400K gas on Ethereum per verification. Harmony light client adopts a novel approach of MMR-based checkpointing for skipping frequent expensive pairing based verification.

Within every epoch, all blocks are connected to each other in the form of a MMR and the MMR root is included in every block header. By verifying the MMR commitment, it become possible for light client to validate the block, without having to perform expensive BLS signature verification.

Reference and more resources on https://harmony.one/layer2s.

Become ONE with Harmony

Developers can build on Harmony today, a fast and open blockchain for decentralized applications. Harmony Mainnet supports state sharding with instant finality. Our staking mechanism reduces centralization while supporting delegation and slashing.

We ❤️ Developers.

Got an idea? Build it on Harmony and Apply for a Grant.

Telegram | Twitter | Discord | Youtube | Medium | Facebook | LinkedIn | Reddit | Instagram