Validating Messages on Crypto Bridges: 3 Main Ways

In our previous blog we discussed that all bridges have a base infrastructure messaging layer, and various types of bridges are built on top of this layer. Depending on the application, they can be a Token, NFT, Governance, Lending or an ENS bridge. Token bridges can be further classified into Lock and Mint type or Liquidity Network type and finally we looked at the pros and cons of each category. In this article which is Part 2 of two blogs that aim to categorize the various types of bridges, we will dive into the message validation techniques. 

Messaging Infrastructure

Just to recap, the hierarchy is a messaging layer at the base level, then bridge applications on top of it. Additionally, bridges can be categorized based on the different ways of validating a crosschain message. The validation could be achieved in 1. A decentralized way, 2. A centralized way or 3. Some hybrid version of the two.

‍

2.2 Decentralized Validation

These are the most complex to build. Polygon’s plasma bridge, Optimism and Arbitrum rollups use a decentralized validation model. Decentralized verification of crosschain messages can be of two types: 1. Natively Verified and 2. Optimistically Verified. Let’s dive into each of these types. 

Natively Verified Bridge 

This is a type of bridge where the chain’s underlying validators verify the transactions. For example Light Clients or Rollup AMBs(Arbitrary Messaging Bridge) that the polygon PoS bridge uses. This can be achieved in two ways: 

• Light client Verifying Validity of the State

These are the most secure way to do crosschain transactions. They verify the validity of a state transition from the source chain, on the destination chain. ZK rollups or optimistic rollups are an example of this. 

• Light client Verifying Consensus

Although less secure than Light client Verifying Validity of the State, these bridges validate the consensus of a source chain on a destination chain. They only validate that majority of the consensus on the source chain attests to the transaction. They don’t validate the transactions themselves. Polygon PoS bridge (checking consensus of the Heimdall chain), Cosmos IBC (verifying signatures of another Cosmos chain) are great examples of this type.

Optimistically Verified Bridge

This is a type of bridge where 1-of-N watchers can prove fraud within a delay window. With optimistic bridging, if a transaction is initiated, the process assumes the correct amount and details have been submitted. There is a 7-day challenge period, during which nodes can contest the accuracy of the details. If the challenge is made and the fraud is proven, the bridging transaction will fail, and if no challenge is made, the funds will be bridged after the 7-day window. Examples include Hop Protocol, Connext Amarok, Across, Nomad Token Bridge. 

Centralized Validation

Externally Verified Bridge

These bridges rely on an external set of validators who are not a part of either source or destination chains to verify the transactions. Validators can be implemented as multisig, consensus algorithms (typically based on propose-and-vote schemes), threshold signature schemes, SGX (Intel® Software Guard Extensions) etc. Examples include Wormhole, Multichain, Axelar, DeBridge, Synapse, Stargate. The Avalanche bridge is also a centralized bridge that utilizes an externally owned account (EOA) to hold assets. Another variation of externally validated bridges is a Proof of Stake (PoS) bridge. This gives a decent level of compromise on decentralization (depending on numbers of validators) while being practical.

Hybrid

And finally there are other teams that are experimenting with a combination of the above mentioned validation methods. 

In summary, bridges can be designed to validate messages in a decentralized manner, centralized manner or a hybrid version of the two. Decentralized validation can be natively verified or optimistically verified. Native verification can be achieved by light clients validating either the state transitions or the consensus on the source chain. Centralized validation is done by multi-sig, EOAs, SGXs, threshold signature schemes or some form of consensus algorithms. Although decentralized validation is the most trustless, it is extremely complex to build and thus teams are experimenting with hybrid versions at the moment. 

Coinchange research team has written a long-form research report on the Crosschain Interoperability and Security which will be published in the next few weeks, where we do a deep dive on the the various bridge security models and propose solutions for users to make the right choice while selecting a bridge for their transaction. So stay tuned for that, meanwhile kick back and earn yield on your crypto using Coinchange. 

‍