If you want more cryptocurrency analysis including full-length research reports, trading signals, and social media sentiment analysis, use the code "Publish0x" when subscribing to CryptoEQ.io to make your first month of CryptoEQ just $10! Or simply click the button above!
NEAR Protocol’s Rainbow Bridge
NEAR Protocol’s Rainbow Bridge provides a connection between the NEAR blockchain and Ethereum (and Aurora). It does so in a way that aims to require significantly less trust in third parties, such as WBTC and similar custodial bridges where the custodians and validators are completely trusted. . NEAR is a Proof-of-Stake, dApp platform that is expected to use sharding to introduce fully scalable transaction throughput. NEAR’s Rainbow bridge utilizes Light Client verification to ensure the state of both the sending & destination chain is correctly reported. The bridge officially launched in Q1 2021 and has since seen elevated usage.
Utilizing the NEAR Rainbow bridge only requires trusting Ethereum’s miners, NEAR’s validators and the quality of the code describing the Light Client on-chain (i.e. that it doesn’t have any major bugs). Rather than trusting a third party's reputation, which is effectively staked in something like WBTC (in the sense that, corrupting the bridge would destroy the operator's credibility), or that of a combination of individuals cooperating via multi-sig. Practically all of the largest bridge exploits have involved a critical threshold of validator keys, associated with multi-sig control of the bridge, falling into the wrong hands. This motivates the need for a reliably secure cross-chain (L1 to L1) bridging solution.
A Light Client bridge involves instantiating Light Clients (as opposed to full nodes) in smart contracts. Particularly, in the case of NEAR’s Rainbow bridge, a light client of the NEAR blockchain is instantiated in smart contracts on the Ethereum blockchain, and a light client of Ethereum is instantiated in smart contracts on the NEAR blockchain. Light Clients utilize merkle trees and the fact that each block is linked to the previous block to enable quick verification of whether or not certain transactions actually occurred, without requiring downloading the full history of the blockchain (running smart contracts with GB or TB of data on-chain would be unfeasible). Light Clients are still computationally intensive, though the trade off here is viable to the extent that their utilization ensures bridged chains have reliable information about the status of the other chain. In addition to the light clients running on each chain a system of relayers, connectors and watchers also support the process.
The Ethereum light client on NEAR utilizes precomputed Directed Acyclic Graphs (DAGs) to reduce the hardware requirements on the NEAR chain. It is also assumed that 25 (NEAR) block confirmations will be sufficient for finality of relayed Ethereum blocks.
Relayers read block headers on one chain and send them to the other chain, the connectors prove the cryptographic hash of bridge transfers via the on-chain light clients while the watchers observe the system and are tasked with raising a flag when suspicious behavior is occurring via fraud proofs. Relayers must bond sufficient ETH with their proposed block headers to cover the gas fees associated with a challenge (allegation of fraud), which is then either burned or claimed by a challenger following an accurate allegation of fraud. Anyone can be a watcher and eager users can also provide their own fraud proofs if they so choose, particularly if they’re skeptical of relying on watchers.
To run through an example: A user deposits and locks ETH in a NEAR Rainbow bridge vault on the Ethereum side. Once a connector has verified the cryptographic proof associated with this depositing of funds, a Relayer sends block headers to the ETH Light Client on NEAR. A connector on NEAR then begins the process of issuing this ETH representation on NEAR. The cryptographic proof of the deposit is utilized and the connector compares block headers via the Light Client to independently verify. The confirmation that everything is in order results in the minting of ETH on NEAR. There is now ETH locked in the vault on Ethereum and an equal value representation of ETH issued on NEAR. Should the user want to remove their ETH from the bridge, they must burn their ETH representations on NEAR before unlocking their ETH on Ethereum.
Source: Delphi Digital
The NEAR Rainbow bridge includes a generalized messaging protocol, therefore it has utility beyond just transferring assets. On-chain voting could be supported via the bridge, allowing users to vote on governance items for a chain using their assets from another chain. Additionally, the state of any smart contract on either chain can be reliably communicated to the other bridged chains.
While NEAR’s rainbow bridge represents a major improvement over the existing industry incumbents with regards to security and meaningful decentralization, trade-offs are made. The NEAR light client on Ethereum verifies everything in the block header except the signature, since verifying validator signatures on-chain on Ethereum is prohibitively expensive. This “optimistic” approach is part of the reason watchers are required to keep an eye on the network and submit fraud proofs. The efficacy of such a system has been discussed at length in the Ethereum research community, with concerns around possible conspiracies between miners and watchers. Despite such concerns, it appears this system has already successfully prevented attacks on the NEAR Rainbow bridge. It is also possible that innovations on the Ethereum network might streamline this process further; EIP-665 would precompile signatures and simplify the watcher process.
