Efficiently Bridging EVM Blockchains

Relay Networks V2

My last article discussed the concept of a relay, which connects two Ethereum-based (EVM) blockchains together. A relay enables users to move their assets between the chains because those assets are replicated in both environments and map 1:1. Any number of separate blockchains may be joined to the Ethereum mainnet to offload transactions and scale the ecosystem to a much higher degree. This design is augmented by sharding and indirectly increases Ethereum’s capacity beyond what sharding itself allows.

In this article I will discuss an updated version of my relay design. This is an exciting update because it makes two dramatic improvements:

Relay data is packed much more efficiently. Instead of relaying each transaction, a Merkle root for a set of consecutive block headers is relayed with latency proportional to the cost of saving the hash. The centralized relayer is removed in lieu of a decentralized network of token stakers who run a standalone relay client, which can operate in a resource constrained environment with only moderate bandwidth requirements.

Before introducing Relay Networks V2, I will review the concept of a relay. You can skip this part if you understand the concept of a relay.

Part 1: Existing Relays

Relays have been discussed widely for a while under various names (bridges, sidechains, blockchain connectors). There are idiosyncrasies to every design, but the overarching concept is that you do something on one blockchain (e.g. depositing tokens) and prove it was done on another, which triggers some event on the new chain (e.g. withdrawing tokens).

The first production example in the Ethereum world was BTC-Relay (built by Joseph Chow of ConsenSys in 2016), which connects the Bitcoin blockchain to the Ethereum blockchain. BTC-Relay works like this:

Community members “relay” consecutive block headers every 10 minutes. This saves the header and the block index to the Ethereum smart contract. User makes a transaction on Bitcoin. User submits the transaction data to the BTC-Relay smart contract and includes the associated block and the data needed for a Merkle proof (to prove the transaction was in the block). Smart contract verifies the Merkle proof and triggers an event.

BTC-Relay has been running for over a year. Community members are still saving block headers every 10 minutes to the contract.

The above scheme is trustless because a user can prove her transaction was included in a block whose header has been relayed previously. BTC-Relay also calculates changes in difficulty so users can determine if any given block has insufficient work behind it. In order to submit incorrect data, an attacker would need to overcome the work that went into the canonical Bitcoin block.

Overcoming the DAG

Bitcoin tracks difficulty with leading zeros, while Ethereum requires a 16GB DAG to be populated in order to verify difficulty using ethash. There are various programs which can perform this computation (example), but creating a DAG inside the EVM is extremely expensive.

This problem is relatively well documented. PeaceRelay is a project that uses a very similar architecture as BTC-Relay to connect EVM chains block by block. The design includes smart contracts developed by SmartPool, a decentralized mining pool built on Ethereum. SmartPool claims difficulty verification can be performed in roughly 3M gas, which is enough to fit in a transaction but is still quite expensive.

With Casper, the problem of difficulty verification goes away and is replaced with a new problem of proving social consensus. Since proving social consensus is likely impossible in a deterministic system, the consensus itself has to be replicated. This will be discussed in further detail later.

Block by block by block

Even if validation that a block took sufficient work to mine is possible (or if we are validating a Casper block via social consensus), the greater concern with this architecture is that it requires a new header be submitted every block. Bitcoin blocks only occur every 10 minutes, but if you imagine a faster side chain being connected to the mainnet, real costs begin to accumulate.

Suppose we wish to relay a sidechain with 2 minute block times using this architecture. Let’s assume the processing takes 4000 gas (a conservative estimate), the storage takes 20,000 gas (STORAGEADD from this list), and the base fee costs 21,000 gas. This costs 45,000 gas to store our header.

We need to process and store each consecutive block header (stored in an array) so we need to pay 45,000 gas every 2 minutes. Using an ether price of $1000 and a current safe low gas price of 1 Gwei this is:

$1.35/hour

$32.40/day

$972.00/month

This recurring fee may be palatable if running a relay is core to your business model, but I suspect it is cost-prohibitive for many use cases. If you can find a way to incentivize users to incur those costs, it may become feasible but as the saying goes: there’s no free lunch (i.e. you need to pay for gas if you are unilaterally responsible for the relay).

There is, however, a trick that has not yet been utilized by any bridges of which I’m aware. But before I get to that, I want to review Merkle proofs. Again, feel free to skip this section if you are a Merkle proof expert.

Part 2: How a Merkle Proof Works

A transaction can be proven to have existed in a block with a Merkle proof. If you want to read more in-depth about these, you can check out Vitalik’s article from 2015.

Merkle Trees

Suppose you have a block with 8 transactions. If you line them up, you can construct a tree of hashes, where each hash is a hash of the children. A picture is worth 1000 words here: