Original article: L2Bridge Risk Framework
Author: bartek.eth
Vaibhav Chellani from Socket and I wanted to propose a risk framework for evaluating the security profile of different bridge architectures.
As with various L2 risk frameworks, our overall goal is to be able to quickly “classify” a solution into a particular class of solutions with similar characteristics, while being granular enough to present to users what security assumptions they need to accept when using these bridges.
We are primarily focusing on bridges between Ethereum and other chains as we will soon be introducing these on l2beat.com, but the basic reasoning about the security of these solutions also applies to bridging any chain to another chain. At this time, we are looking for feedback from the broader community on this proposed framework.
Bridge Type
For end users, asset bridging means receiving a deposit of a certain asset from the source chain and transferring the asset to the user on the destination chain.
For example, a typical bridging process is that Alice transfers funds to the bridge contract on chain A, and then Alice receives funds from the bridge on chain B.
Broadly speaking, there are two ways this process can happen:
Token Bridges Based on Message Passing — These bridges allow liquidity to flow across chains in the form of message passing. Generally, they allow an asset to be minted on a target chain after it has been locked or burned on the source chain. Examples: Rollup Bridge, Polygon Native Bridge, Anyswap (anyCall), and Axelar Network. Liquidity Networks — There are also bridges that redeem some minted assets. They allow users to transfer assets to other chains, assuming that the assets have been transferred there in advance via a "message passing" bridge. Examples: Connecxt based on Nomad Bridge, Hop based on Hop Optimistic Bridge, some other HTLCs (Hash Time-Lock Contracts), and conditional transfers (such as nova, etc.).
Security of Messaging Bridges
In this section, we will try to explain the different ways of verifying cross-chain messages used by various bridge protocols. As shown in the figure above, token bridges will leverage the security of message-passing bridges.
Light client verifies state validity
Description: A bridge that verifies the validity of the source chain state transition on the target chain. This verification process is achieved through zero-knowledge proof (the state transition process is accompanied by the generation of a zk proof) or a fraud proof system (allowing independent verifiers to dispute the validity of the new state root).
Example: All Rollups are considered examples here, and L1 will verify the state transition of L2 through FraudProof or ValidityProof.
Light client verifies consensus
Description: Verify the bridge of the source chain consensus on the target chain. This depends on the consensus mechanism used by the source chain, and usually includes checking the quorum signature of the current validator committee if the source chain uses a PBFT-style propose-and-vote consensus protocol (such as Tendermint, HotStuff, Casper FFG protocol). Or, if the source chain uses a PoW protocol or a "longest chain" PoS protocol (such as Ouroboros, ETH 2.0 LMD Ghost, etc.), check the longest chain using the relevant fork rules.
Examples: NEAR Rainbow bridge (ignoring the Optimistic component related to the complexity of the NEAR signature mechanism verification process), Polygon’s PoS bridge (checking the consensus of the Heimdall chain), and Cosmos IBC (verifying signatures of another Cosmos chain).
External validator set
Description: Use external validators as a bridge to the source of truth, that is, validators that form an independent committee, rather than validators on the source and target chains. Depending on the implementation adopted by these validators, they may use MultiSig, run a consensus algorithm (usually an algorithm from the category of proposals and voting), use Threshold Signature mechanism (TSS, threshold signature mechanism) or SGX, etc. ... No matter what technology they use, they belong to this verification method.
例子：Wormmhole、Multichain、Axelar、DeBridge、Synapse、Stargate。
Optimistic Validation
Description: A bridge with a challenge period.
The honest party in this type of verification will avoid including fraudulent information during this period. However, there are a few key parameters to consider:
Challenge period length: The longer the better Watcher set size: No permission required > Permission required
Examples: Hop Protocol, Connext Amarok, Across, Nomad Token Bridge.
Hybrid Authentication Method
Description: There is a structure that mixes the above authentication methods.
Security of the Liquidity Network
In addition to sending assets across chains, there is another method: cross-chain swap, which can be performed by simply changing hands without moving assets across chains. (Translator's note: changing hands means that one party's assets become owned by another party, that is, the asset owner changes.)
Let’s take a simple example: Alice on chain A wants to transfer her assets to chain B. Bob (liquidity provider, LP) already has assets of the same value on chain B. He uses his assets on chain B to provide exchange services for Alice’s balance on chain A and charges a service fee. In the end, Alice will get the assets on chain B, and Bob will get the assets on chain A + service fees.
This section only describes the security of the "exchange" protocol, i.e. how likely it is that an LP will abscond with your funds after accepting your deposit on the source chain. These exchange assets have the security of the messaging bridge that minted them.
There are also some other ways to exchange assets:
HTLC: Also known as hash time lock contract, it can be used to atomically exchange assets between two parties across chains. Usually only two steps are required for users, one is to lock, and the other is to unlock. The possible failure is that your funds will be locked for a fixed "dormant" period. Examples: Connext NXTP, Liqualit. Conditional Transfer: Allows LPs to bridge through shortcut messages, so that LPs can immediately provide funds to end users at any time of bridging funds and receive funds from the messaging bridge. In the event of a failure, if no LP provides liquidity, the slow path will be activated. Examples: Hop, Connext Amarok, MakerDAO Teleport. External Validator: Allows users to transfer funds to a trusted bridge provider, who will promise to release the funds to another chain. The possible failure here is that your funds will be lost. Example: Binance
Censorship resistance
We will look at the security assumptions surrounding the possibility of censorship of a single message sent by the bridge. More practically, we will also explore whether a single message (token transfer) can be censored or ignored by the bridge, and if so, what the consequences are for the user’s funds (will they be returned to the user, or will they be stuck in the “transfer in progress” state).
Typical solutions:
Leverages the censorship resistance of the base chain (e.g. some Rollups) Relies on the honesty of the validator set
Overall active failure
In terms of liveness failures in general, we will look at the consequences of “closing” a bridge. For example, for a bridge that uses an external validator set, we can look at the security of user funds in the event that those validators are offline for a long period of time (possibly indefinitely). Typical scenarios that could occur include:
Activate Slow Path: The default mode is slow path, and no funds will be lost. Stake Yourself: Users can stake to participate in the network, become validators and handle stuck transfers themselves. Freeze: Pause the system and cannot run until the bridge operator comes online.
fluidity
In this section, we will try to analyze the liquidity available to the bridge asset. Can the bridge mint the asset, does it require LPs, can users always withdraw or transfer any amount of tokens they choose, or are they dependent on external LPs and the bridge could "run out of funds".
Unrestricted (bridges can mint native/authoritative tokens) Permissioned (liquidity provided by bridge operators) Permissionless (any LP can provide liquidity)
Other considerations and metrics Upgradability Permissioned actors Transfer volume in the last 24 hours Unique transfers in the last 24 hours Available liquidity Supported tokens/blockchains