• In order for blockchains to communicate with one another, we need intermediaries. These intermediaries have frequently been the number targets of blockchain hacks. There are projects trying to minimize the trust in these intermediaries.

• Fraud proof is the proof system that proves fraud or misconduct in a system. As long as any proof isn’t generated, the system proceeds honestly. That’s the reason why the systems utilizing fraud proofs are called optimistic. Fraud proof based bridges are based on the assumption of 1/N honesty. This article will be detailing Nomad and Rainbow bridges, which adopt the optimistic approach.
• Due to a vulnerability on Nomad bridge smart contract, approximately $190 millions of assets were stolen. We will be elaborating the details of this hack in this article.
• While Nomad bridge can easily be utilized between many different EVM chains, Rainbow bridge was only operational between Ethereum and Near.

Bridges and Details of Hacks

Communication between blockchains and bridges is one of the subjects that has been studied for the last couple of years. In recent years, various bridge architectures utilizing a number of different technologies have emerged:

• Solutions using Intel SGX technology (Avalanche Bridge)
• Consensus level solutions (IBC)
• Light client (Rainbow) bridges 
• Validity proof-based bridges (Nil bridge between Ethereum and Mina)

For the bridges, security is at least as important as being fast and affordable. Today, assets on most bridges are secured by a multisig wallet with just a few signers; and in recent years, more than $1 billion cryptocurrency has been subject to theft as a result of bridge hacks. Since most of these hacks are the result of human errors, eliminating the factor of trusting humans is essential in terms of blockchain security. For example, in Ronin bridge hack, the hacker opens up a fake company and announces that they are hiring engineers. Afterward, the hacker sends an infected PDF, including a rather generous offer, to the individuals they interviewed from Ronin team. As a result, the hacker is able to seize authority over the bridge validators. And this simple phishing attack resulted in a $540 million hack. In this article, we will both be discussing the details of Nomad bridge (an optimistic bridge) hack as well as Rainbow bridge.

Every day, different blockchain solutions keep emerging and each of them attempts to provide solutions to a variety of problems. Although this diversity is embraced and welcomed, as blockchains are designed like closed circuit systems, they are not able to communicate with one another without an intermediary. The need for bridges in order for different ecosystems to interact with one another is increasing day by day. There are many different types of bridge architectures approaching decentralization and trustlessness from different perspectives:

A) Central and Trusted Bridges: There are certain actors who transfer the messages to the other chain using these bridges. Central bridges often require trusting one or more actors. The security of these bridges is based on the reputation of these actors. “Binance Bridge” established by Binance corporation is an example of bridge architecture that can be defined as central and trusted. Technically, while the security of the funds is ensured by Binance, trust in the bridge depends on the user base of this company as well as its reputation. Since this architecture is rather easy to build and usually affordable, we often encounter similar bridges. However, as the security of the locked assets on the bridge requires trust in only certain actors, we may argue that the level of security is low.

B) Bridges Using Threshold Signature Scheme: Thanks to this technology, it is possible to develop bridges allowing wider participation rather than bridges relying on a few signers. This scheme allows collecting signatures from a high number of addresses to be used as a single signature. Synapse and Thorchain can be given as examples using this technology. Although the distribution of trust is way better than central bridges in terms of security, it is still necessary to trust the majority of validators for communication between two chains. Additionally, BLS-based bridges are expected to be developed with the future BLS upgrade. Thanks to BLS, hundreds or even thousands of signatures can be made into a single signature as long as the quorum is reached. When hundreds or thousands of signatures are made into a single signature, it will be possible to transfer the messages without the need for any interaction with the validators. Hence, it will be possible to develop trust-minimized bridges based on BLS signatures between two blockchains.

C) Decentralized and Trust Minimized Bridges: These bridges aim to minimize trust in the intermediary. Some examples of these types of bridges are Rollup bridges, IBC, XCM, and Optimistic bridges. Technically, the development of these bridges is rather challenging despite being secure and decentralized, and their compatibility with different blockchain technologies is low. In this article, our main focus will be optimistic bridges that are based on fraud proofs.

But, what is fraud proof?

Fraud proofs prove that a state transition is wrong. Each state transition in systems that use fraud proofs is accepted with the assumption that it is valid, and only if an error/fraud is detected, a fraud-proof is generated. That is, no proof is generated as long as the system proceeds honestly. However, there is a critical challenge when generating a fraud-proof: Data Availability. If someone wants to prove that a state transition is wrong, they need to access the entire data. Hence, data availability becomes more important in systems based on fraud proofs. In the following sections of this article, we will be discussing this subject again in optimistic bridge architectures.

There are some actors operating off-chain in optimistic bridge architectures. While these vary from architecture to architecture, basically, these two actors are the relayer (updater) and the watcher. A user who wants to transfer assets from chain A to chain B first interacts with the bridge contract on-chain in chain A to confirm this transaction. Afterward, the relayer transfers this data from chain A to chain B. And unless a fraud-proof is not generated on chain B, the transaction is deemed valid. In case the relayer transfers incorrect data or attempts to validate data twice (double spending), the watcher generates a fraud-proof, which in turn penalizes the relayer and rewards the watcher. In optimistic systems, it is sufficient as long as one of the watchers (1/N) is honest in order for the system to be maintained without any problem. Optimistic Bridges are much more secure compared to the architecture requiring trust in the vast majority of the validators (K/N), which is the standard in bridges based on the Threshold Signature Scheme. Although optimistic bridges are architecturally secure, complicated smart contract structures bring along smart contract risks.

Nomad Bridge

In recent years, many different Layer-1 projects such as Near, Avalanche, and Polkadot have been able to achieve remarkable success. These projects have also been able to reach a large user base on top of the wide ecosystem over them. As new Layer-1 projects keep getting developed, communication between these chains and their interoperability has become an even greater challenge. Here, trust minimized or trustless bridges have begun to attract attention. 

Nomad, designed with the influence of optimistic rollup design, is a fraud-proof-based protocol. The reason why it is called a protocol is the fact that it does not only serve as a bridge but also supports cross-chain governance and applications. Hence, it is possible to develop a variety of products on top of this protocol. The protocol consists of on-chain contracts and off-chain actors.

On-chain contracts

On-chain contracts are Home Chain and Replica Chain. Home Contract is the contract where the messages are sent. The user who wants to make a transaction interacts with this contract. Replica Contract, on the other hand, is the contract where messages are received and off-chain actors interact. As on-chain contracts are designed to be upgradeable with the signature of 3 of the 5 actors and the smart contracts have a complex structure, there is smart contract risk here.

Off-chain actors

Off-chain actors are Updater, Watcher, Relayer and Processor.

• Updater is elected by the DAO on the origin chain. This DAO consists of 5 people and is secured by a Gnosis Safe. To be updated, a minimum of 3 signatures are required from the DAO. Updater is responsible for observing the Home Contract on the origin chain, processing messages and updating the roots. Honest operation of the Replica Contract requires full reliance on Updater’s honest behavior. In Nomad’s architecture, it is possible for Updaters to transmit inaccurate data unlike Optimistic rollups. For this reason, Updaters are required to lock cryptocurrency to guarantee that they will act honestly on the origin chain. In case the replica sends inaccurate data to the chain, other off-chain actors generate a fraud proof and the crypto assets locked on the origin chain are seized. This forces the Updaters to act in honesty.

• Watcher is responsible for observing the Updater’s interaction with the Home Contract, monitoring the replica contracts and generating fraud proofs. In order for Watcher to generate fraud proof, the entire data must be available. In this context, as the data to be observed by the Watchers increase with the widespread use of Nomad, they may have to compromise on decentralization in the future. On the other hand, as the system is based on the assumption of 1/N trust, it may not actually create any problem in terms of trust.

• Relayer is responsible for sending the updates in the home contract to one or more replica contracts. Additionally, it can monitor the updates on the replica contract to generate fraud proofs.
  
• Processor proves the validity of the pending messages and sends these to the end recipient. Processor is also able to check the honesty in the system by generating fraud proofs.

Details of Nomad Bridge Hack

What enabled the hack?

On August 2, a vulnerability was spotted on the Nomad Bridge and $190 million in cryptocurrency got stolen. The root cause enabling this hack was a smart contract bug due to an update. Before going into the details of this hack, let us first take a look at why this update was performed. On May 27, a bug was spotted on the contract, and an update was made to fix this (https://github.com/nomad-xyz/monorepo/pull/289). The bug included the ability to process messages even when they are sent under a fraudulent root. As a result, the governance had to delete every fraudulent transaction. The update in question was performed to eliminate this bug.

While the contract was being upgraded, there were 3 different roots checked in the contract. One was responsible for identifying whether the message was approved or processed, the other was responsible for verifying the message was accurate after the challenge period was over without any fraud-proof being generated, and the other one was about the verification of the message. Typically, 0 root, that is, the root containing the invalid messages should not have been included in the whitelist in order not to be approved by the contract. However, as it was forgotten in the whitelist, the hackers were able to make the contract approve any message they desired. As a result, $190 million cryptocurrency locked in the contract got stolen.

While there is no information whether Nomad bridge contracts underwent additional audits by independent organizations, this bug had not been mentioned in any audit report. It is essential to understand that the bug here was not due to the optimistic bridge structure of the bridge, but due to a bug in the smart contract. Smart contract risk is a risk that we are always exposed to when we interact with decentralized applications, and despite some exceptions, we are exposed to similar risks when we interact with bridges as they also operate with smart contracts.

How did the hack turn into “looting”?

The vulnerability on the contract was first spotted by a hacker; however, Nomad contracts were looted by dozens of people. In the beginning, the hacker carried out the hack with ETH withdrawn from a mixer about 45 days before the hack. After the hacker stole around $30 million in cryptocurrencies, lots of posts started to pop up on social media, indicating that anyone can replicate the hacker’s transactions to steal money from the bridge. Subsequently, people exploiting this information started to withdraw crypto assets locked in the contract. By replicating the transactions of the initial hacker, approximately $150 million worth of assets were literally looted by both blackhat and whitehat hackers.

According to data from Peckshield, there are 42 wallets that stole over $100.000 from the bridge. The remaining $40 million in assets were stolen by other users. So far, approximately $32 million have been returned by 36 whitehats.

Rainbow Bridge

Since its inception, Ethereum has been responding to numerous needs for both developers and users. However, the scalability challenges on Ethereum are pushing these users and developers to other competing blockchain solutions. Among others, Near is one of them.

 Aurora, utilizing Near sharding technology, is Near’s EVM-running solution. Unlike rollups, Aurora is a solution where execution, data availability, and settlement rely on NEAR mainnet. The delay problem of the rollup bridges due to their modular structure is a non-issue for Aurora’s bridge. Since Aurora is a separate blockchain and as mentioned earlier, blockchains are designed like a closed box, there are some obstacles for the chain to communicate with other chains. Here, protocol-level solutions such as IBC and Light Client Bridges stand out. Near’s solution in this regard is Rainbow Bridge. Light client bridges are those that work by monitoring the final state of two blockchains. The most important component of these bridges are Light Clients.

Light Client

Blockchains consist of Header, Transaction, State and Cache data. The header contains the smallest data for us to validate the data in a blockchain as well as some basic information such as the hash and timestamp of the previous block. As light clients are responsible for validating the data on the header, they do not have to download all the data in the blockchain. However, due to this, light clients rely on the honest majority of full nodes. To overcome this challenge, various solutions such as DAS (Data Availability Sampling) are being developed. On networks such as Bitcoin and Polkadot, light clients are used for interacting with the blockchain or validating the transactions on the blockchain in bridge designs.

Light Client Bridges

ssentially, light clients are computer programs. In blockchains supporting smart contracts – provided that there are cryptographic infrastructures – it is possible to run light clients as smart contracts. Thanks to light clients that work as their counterparts, block headers of two blockchains – without the need of a 3rd party – are possible to be validated; and trustless blockchain bridges can be designed.

Rainbow Bridge Technical Details

Rainbow Bridge was designed by 1inch CTO, Anton Bukov. As in the case for all other blockchain bridges, Rainbow is also controlled by both off-chain and on-chain actors. On-chain actors of the bridge consist of an Ethereum light client written in Rust on Near side and a Near light client written in Solidity on Ethereum side. There are some cryptographic barriers in the implementation of light clients, though. This will be discussed in detail later in the article.

• EthOnNearClient: It is the Ethereum light client written with Rust on Near side. This client stores Ethereum headers. If a new header was stored on Near in each state change, storage cost would constantly increase, which would result in an increase in transaction costs for this bridge. (You need the lock $Near tokens to store data in Near blockchain.) For this reason, the data transferred from the bridge are only stored for 7 days. In other words, in case transactions from Ethereum to Near are not completed within 7 days, the assets may remain locked forever. Even though this is not a major problem, it is a significant example of how cryptographic challenges can affect the user experience.
• NearOnEthClient: It is the Near light client written with Solidity on Ethereum side. This client works similar to EthOnNearClient. In order to sign the validator messages validating the blocks, Near uses ED25519 signature method. Since this signature method is not compatible with Solidity, it is both a challenge and expensive to run on Ethereum. And this is exactly where the optimistic approach comes into play. With NearOnEthClient, all information in the header except for the signatures on Near are assumed valid, and a 4hour period begins afterward. During this 4-hour period, Watchdogs check the validity of the data; and in case of a fraud attempt, it is sufficient for only one of them to generate a fraud proof to prevent the fraud.

• Provers: Actually, this actor has only one purpose. To be able to communicate events on a blockchain to the other one. For this reason, prover is required to be added to both client contracts. While EthOnNearProver approves Ethereum transactions on Near, NearOnEthProver approves Near transactions on Ethereum. Thanks to provers, Rainbow bridge design becomes more secure.

Rainbow Bridge with Numbers

Rainbow Bridge was actually designed in a trustless structure just like IBC. However, standardization challenges of Solidity and Ethereum renders the optimistic approach in certain parts of the design. Architecturally, Rainbow is probably the most secure bridge between two independent ecosystems.

Among Ethereum bridges, Rainbow bridge is the 4th largest bridge in terms of total value locked. Since the vast majority of bridge liquidity of both Aurora and Near mainnet are kept in Rainbow, we can claim that it was easily adopted by the users. So far, over $2.5 billion in assets have been transferred through Rainbow bridge, which has hosted 13.317 users and a total of 39.930 transfer transactions. As it stands now, it is observed that the bridge is still in its earlier stages as it is adopted by only a handful of users.

The Future of Rainbow Bridge

The optimistic approach implemented on Rainbow Bridge is due to the cryptographic challenges. Although this fraud-proof-based bridge has been able to survive 1 attempt of the hack, there are certain problems in fraud-proof-based systems such as verifier’s dilemma and delay. According to Aurora Labs CEO, Alex, Rainbow bridge will transition to a validity (zero knowledge) proof-based architecture from its current fraud-proof-based architecture. Currently, the research for the transition to zero knowledge based architecture for Rainbow bridge is being conducted by Electron Labs. Additionally, according to Illia, one of the co-founders of Near protocol, in the future, interoperability between Rainbow and IBC bridges will be possible due to the similarity of their architecture. It seems that Rainbow will probably appear with many different architectures.

Verifiers Dilemma

In systems, if the calculation is extremely expensive, the cost of calculation is aimed to be reduced by either turning data into a small proof by utilizing Validity (ZK) proofs or by using a fraud proof-based system. That is exactly why these proofs are used in both bridges that we have discussed so far. As the validity of the data is directly proven in systems based on validity proof, their rewarding and penalty mechanisms are simpler compared to fraud-proof-based systems. On the other hand, as only fraud is proven in fraud proof-based systems, we do not know whether the system is monitored unless there’s fraud in the system. To explain it with a simpler analogy, let us assume a house is protected by a watchman. We can only find out if the watchmen is protecting the house only if a thief attempts to enter the house. Moreover, in case the watchman is bribed well enough, the watchman might even prefer ignoring the theft.

This was clearly seen in the attempted hack on Rainbow Bridge. The hacker tried to send an invalid transaction from Ethereum to Near. The Watchers generated a fraud-proof; however, the MEV bot, upon catching this transaction in the mempool, frontrun the Watcher’s transaction to receive the reward, which was supposed to be sent to the Watcher and which the hacker attempted to steal.

We may propose to reward the actors working as watchers even if they do not find any fraud. However, it will not be possible to distribute rewards fairly as we will not be able to know whether they actually work. That’s why this is a problematic solution. Again, we may also propose to reward the watchers with penalties from the fraudulent actors (seizing their tokens, for instance). In that case, the watchers will not be able to receive any reward unless there’s fraud on the network, or even in the case of a reward, they may be subject to a MEV attack. Again, another problematic solution. Although it seems that fraud-proof-based systems will stay in our lives for a long time because ZK technology is yet to mature, we may foresee that ZK-based systems will become more popular due to these reasons.

Final Remarks

Bridges are one of the most problematic components of blockchains in terms of security. There are many different technologies developed to render these bridges more secure and to eliminate the need for trust in the bridges. The problem with these technologies is that the computation costs are not affordable. The high cost of computation forces developers to utilize fraud and validity (zk) proofs (except for consensus-level solutions such as IBC). Validity proof-based bridges have some advantages over fraud proofs: Speed, computation cost, trust assumption, etc. However, as ZK technology is still in its early stages and it is difficult to develop these, the developers tend to prefer fraud-proof based bridges. My personal opinion is that validity-proof-based systems will replace the fraud-proof based system as Zero Knowledge technology becomes more mature in the future. While being able to upgrade smart contracts via multisig wallets poses a problem in terms of decentralization, there’s also a security problem as each upgrade has to be subject to a separate audit. Therefore, instead of smart contract level bridges, I think that protocol level solutions (IBC, XCM, enshrined rollup bridge) will have a much more important role in our lives and will play an important role in building the multi-chain future.

Disclaimer: This article has been written for informational and educational purposes only, does not contain investment advice, and should not be considered by the reader as an advisory text. Financial losses may occur on dApps developed on blockchains due to software vulnerabilities. Users are recommended to do their own research before using and investing in projects. The author or Lytera may not be held responsible for any losses that may occur.