Partnered With:

L2 Bridging Risk Architecture

Read this article in 14 Minutes

Propose a risk framework for evaluating the security profile of different bridging architectures

Original title: "L2 Bridging Risk Architecture"

Original source: bartek.eth, ETH Chinese

Me and Vaibhav Chellani from Socket would like to propose a risk framework for evaluating the security profile of different bridging architectures.

As with various L2 risk frameworks, our overall goal is to be able to quickly "classify" a solution into within a particular class of solutions with similar characteristics, while being granular enough to present users with the security assumptions they need to accept when using these bridges.

We are mainly focusing on bridges between Ethereum and other chains, as we will introduce these soon on l2beat.com Author's Note: The Bridging column is currently live), however, the basic reasoning about the security of these solutions also applies to the bridging of any chain to another chain. At this time, we are looking for feedback from the wider community on this proposed framework.

Bridge type

For end users, asset bridging refers to receiving an asset from a source chain Deposit and send this asset to the user on the destination chain.

For example, a typical bridge process is that Alice transfers the funds to the bridge contract of the A chain, and then Alice receives the funds on the B chain to funds from the bridge.

Broadly speaking, there are two ways this process can occur:

· Token bridges based on message passing - these bridges allow liquidity to flow across chains in the form of message passing. Typically, they allow an asset to be minted on the 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 Network - There are also bridges that will exchange some minted assets. They allow users to transfer assets to other chains, assuming that these assets have been transferred there in advance through the "Message Bridge". Examples: Connecxt based on Nomad bridge, Hop based on Hop Optimistic Bridge, some other HTLC (Hash Time-Lock Contract, hash time-lock contract) and conditional transfer (such as nova, etc.).

Security of Messaging Bridging

In this section, we will try to explain the different ways of verifying cross-chain messages used by various bridging protocols. As shown in the figure above, token bridging leverages the security of messaging bridging.

· Light Client Validation Status

Description: A bridge that verifies the validity of the state transition of the source chain on the target chain. This verification process is achieved through zero-knowledge proofs (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 examples here, L1 will pass FraudProof (fraud proof) or ValidityProof (validity proof) verifies the state transition of L2.

· Light client verification consensus

Description: A bridge that verifies the consensus of the source chain on the target chain. This depends on the consensus mechanism used by the origin chain, which usually includes a check of the quorum signature of the current validator committee, if its origin chain uses a PBFT-style propose-and-vote consensus protocol (such as Tendermint, HotStuff, Casper FFG protocols). Alternatively, if the source chain uses a PoW protocol or a "longest chain" PoS protocol (such as Ouroboros, ETH 2.0 LMD Ghost, etc.), then use the relevant fork rules to check the longest chain.

Example: NEAR Rainbow Bridge (ignoring the Optimistic components), Polygon’s PoS bridge (checking the consensus of the Heimdall chain), and Cosmos IBC (verifying the signature of another Cosmos chain).

External Validator Set

Description: Use external validators as a bridge to the source of truth, i.e. validators who form an independent committee, rather than validators on the source and target chains. Depending on the implementation used by these verifiers, they may use MultiSig (multi-signature), run a consensus algorithm (usually an algorithm from a class of proposals and voting), use Threshold Signature mechanism (TSS, threshold signature mechanism) or SGX etc.. whatever technology they use fall under this type of authentication.

Examples:Wormmhole, Multichain, Axelar, DeBridge, Synapse, Stargate.

Optimistic Validation

Description: Bridge with challenge period

The honest party in this type of verification avoids including fraudulent information during this period. However, here are a few key parameters to consider:

1. Challenge period length: the longer the better

2.Watcher Set Size: No Permission Required> Permission Required

Examples: Hop Protocol, Connext Amarok, Across, Nomad Token Bridge.

· Mixed Authentication

Description: There is a structure that mixes the above various authentication methods.

Security of the Liquid Network

In addition to actually sending assets across chains, there is another method: cross-chain swap (swap), which can perform cross-chain swaps only by 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 owner of the asset changes.)

A simple Example: Alice on chain A wants to transfer assets to chain B. Bob (liquidity provider, LP) already has an asset of the same value on the B chain, and he uses his own assets on the B chain to provide exchange services for Alice's balance on the A chain and charge a service fee. In the end, Alice will get the asset on the B chain, and Bob will get the asset + service fee on the A chain.

This part only describes the security of the "exchange" protocol, that is, after LP accepts your deposit on the source chain , How likely is it to abscond with the money. These exchange assets have the security of the messaging bridge that minted them.

There are also someother ways to exchange assets:

· HTLC: Also known as hash time lock contract, it can be used for atomic exchange of assets between two parties across the chain. Usually only requires the user to do two steps, one is to lock, and the other is to unlock. A possible failure is that your funds are locked for a fixed "dormant" period. Examples: Connext NXTP, Liqualit.

· Conditional Transfer: Allow LP to bridge through shortcut messages to This allows LPs to instantly fund end users and receive funds from messaging bridges whenever funds are bridged. In case of failure, if no LP provides liquidity, the slow path is activated. Examples: Hop, Connext Amarok, MakerDAO Teleport.

· External Validators: Allow users to transfer funds to trusted bridge providers At the provider, the provider promises to release funds to another chain. A possible failure here is that your funds will be lost. Example:Binance

Censorship Resistance

We will look at the security assumptions regarding the possibility of a single message sent by the bridge being censored. More practically, we will also explore whether a single message (Token transfer) will be censored or ignored by the bridge, and if so, what will happen to the user's funds (these funds will be returned to the user, or stuck in the "transfer "in" state).

Typical solution:

· Leverage the censorship resistance of the base chain (e.g. some Rollups)

· Depends on the honesty of the validator set

Overall Liveness Failure

In terms of liveness failures in general, we will look at the consequences of "turning off" the bridge. For example, for bridges that use an external set of validators, we can look at the safety of user funds in the event that those validators go offline for an extended period of time, possibly indefinitely. Generally possible situations include:

· Activate slow path: the default mode is slow Fast path, no loss of funds

· Pledge by yourself: users can pledge to participate in the network, become a validator and handle it by themselves Stuck transfer transaction

· Freeze: Pause the system and cannot run until the bridge operator comes online

Liquidity

In this section we An attempt will be made to analyze the liquidity available to the bridging assets. Can the bridge mint assets, 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 (Bridge can cast native/authoritative Token)

· Permission required (liquidity provided by bridge operator)

· No permission required (any LP can provide liquidity)