This blog explores the Rainbow bridge that supports transferring assets between Ethereum, NEAR, and Aurora.

At Infura, we believe the future of Web3 is multi-chain. It is becoming more and more common for assets that reside on Ethereum to be bridged and used on other blockchain networks. This is why Infura supports several new networks like Arbitrum, Polygon, and Optimism, as together in this multi-chain world, all chains increase the utility and scalability of Ethereum, DeFi and the wider self-sovereign movement that is at the heart of Web3.

But this brings us to the question:

How are assets moved to other networks and what is the trust assumption that ultimately protects the assets?

Over the years, the trust assumption for protecting assets held by bridges has evolved and a summary can be found here.

This blog explores the Rainbow bridge which supports transferring assets between Ethereum, NEAR and Aurora. Of course, Infura supports all 3 networks amongst others, to give developers the broadest choice of options possible.

We will release a step-by-step tutorial for getting started on NEAR on our blog next week and you can learn more about NEAR at the upcoming Infura Community Call on Tuesday, May 31st by RSVPing here.

What is the Rainbow Bridge?

The Rainbow Bridge design is similar to the original sidechain paper and we are only considering the bridge implemented on Ethereum.

It can be broken into a few components:

Staked relayers. Anyone can stake funds and effectively self-appoint themselves to protect the assets held by the bridge. Like most staking systems, a relayer’s deposit will be slashed if they try to cheat the system - an example of crypto-economic security as relayers have skin-in-the-game.

Chain of block headers. A relayer has a single responsibility. They must watch the NEAR blockchain, fetch a block header that is signed by all validators, and publish the signed block header to the bridge contract on Ethereum. This is repeated over time and the bridge contract will have an up-to-date view of NEAR’s canonical chain. Note, only one NEAR block header per epoch (~12 hours) is submitted.

Light client technology. This is the magic behind the Rainbow Bridge and it works thanks to cryptography. Given a NEAR block header, it is possible to convince the bridge contract on Ethereum about events on the NEAR network. For example, we can convince the bridge contract that a user has signalled their intent to withdraw their assets from NEAR to Ethereum. With this information, the bridge can release the funds back to the user.

Thanks to these three components, the bridge contract on Ethereum can keep up-to-date with actions that occur on the NEAR network and be convinced that funds should be released back to the user.

How do fraud proofs work?

Unlike rollups like Arbitrum and Optimism, the fraud proofs do not check whether a block header or its list of transactions is valid. To put it another way, it is not possible to convince the bridge on Ethereum that any transaction on the NEAR network is fraudulent.

The trust assumption for the Rainbow Bridge is the following:

A block header is accepted by the bridge contract if it is signed by the validators on the NEAR network.

As long as the validators on NEAR attest that the database is alive and well, the bridge contract will accept that as fact.

But this raises the question:

Why are there fraud proofs? What fraud is actually being checked?

A NEAR block header has several signatures from the validators. But processing the block headers on Ethereum is expensive, especially since it does not natively support Ed25519 signatures. Thus, the fraud proof system was built to avoid the expensive gas costs on Ethereum. As a fun fact, it isn’t possible to fit signature verification of all validators in a single Ethereum transaction.

Briefly, the NEAR block header (alongside the validator’s signatures) are submitted to the bridge contract on Ethereum. The signatures are not checked by the bridge, but it is stored for a fixed period of time. All watchdogs will fetch the submission, check the signatures locally, and submit a challenge if any signatures are invalid.

There are two potential outcomes:

• Accept after the challenge period. If there is no challenge, then the bridge contract will eventually accept the block header as valid.

• Issue challenge. If there is an invalid signature, then the bridge contract will verify it and decide to reject the block if it is invalid.
  

The challenge process adds a time delay before any actions can be performed by the bridge contract, but it does save significant gas costs for running the bridge.

Malicious Relayer, Functional WatchTowers, and the Dark Forest

On the 1st May, 2022, an attacker tried to steal the funds held by the Rainbow Bridge, and Alex Shevchenko explained how the funds are safu and the attacker was ultimately thwarted.

As detailed in the thread, the attack occurred as follows:

1. • The attacker staked 5 ETH to become a relayer for the Rainbow Bridge.
2. The attacker created a fake block header with invalid signatures and submitted it to the bridge contract (fun fact: their first attempt failed).
3. A watchdog checked the submission and issued a challenge, as they had found invalid signatures.
4. MEV bots on the peer-to-peer network (“the dark forest”) stole the challenge and got their transaction mined first.
5. The watchdog’s transaction failed, but the MEV bots collected the 2.5 ETH bounty (½ the relayer’s stake) and saved the day.

As someone who has worked on fraud proof systems, it truly is remarkable to witness it working in practice.

The most interesting takeaway here, is the role and motivation of the watchdog service. Historically, for almost all challenge-response protocols, the role of a watchdog is to make easy money by monitoring the blockchain and submitting fraud proofs to collect a bounty. Simply put, it should be a for-profit venture that anyone can participate in.

However, as we witnessed, a watchdog service cannot compete with the Dark Forest for transaction delivery. Without sending transactions directly to the miners, I conjecture that the Dark Forest will always steal the watchdog transactions and get them mined first. This is because MEV bots specialise at stealing the payload of others and it is difficult for centralised services to compete with privately run bots.

At first glance, this looks like a bad outcome. The business model of a watchdog is undermined by the existence of the Dark Forest and it does not make sense to run a service to make money. But, I do wonder if, as a community, we have the wrong mental model for watchdogs?

Perhaps companies will run a watchdog as an altruistic service, not to make money, but to protect the underlying system that they rely on. If so, the job of a watchdog becomes one of simply issuing a signal to the Dark Forest and letting the MEV bots take care of the rest.

For once, it is a positive outcome for MEV. :)

With All This in Mind…

Infura believes in the rise of a multi-chain world and the Rainbow Bridge is one of many types of bridges that are being deployed to support interoperability across blockchains.

By supporting networks that can bridge to and from Ethereum, we hope to contribute towards the rise of the entire multi-chain ecosystem and, of course, help cement Ethereum as the ultimate and most decentralised layer one network.

With this in mind, the success of the Rainbow Bridge to defend against a malicious relayer is a wonderful example that underpins our decision to support the NEAR network, a network that boasts a vast ecosystem for a reason. Such resilience demonstrates the technical maturity and robustness of the technology built by the NEAR team.