L2 Bridging Risk Architecture

Vaibhav Chellani and I from Socket wanted to propose a risk architecture to assess the security profile of different bridging architectures.

As with the various L2 risk frameworks, our overall goal is to be able to quickly “categorize” a solution into a specific solution category with similar characteristics, while presenting users in enough detail what security assumptions they need to accept when using these bridges.

We mainly focus on bridging between Ethereum and other chains, as we’ll cover these in l2beat.com, but the basic reasoning about the security of these solutions also applies to bridging any chain to another. At this moment, we are looking for feedback from the wider community on this proposed framework.

Bridge type

L2 Bridging Risk Architecture

For end users, asset bridging refers to receiving deposits of an asset from a source chain and calling that asset to a user on the destination chain.

For example, a typical bridging process is for Alice to transfer funds to the bridge contract on chain A, and Alice then receives funds from the bridge on chain B.

Broadly speaking, this process happens in two ways:

Token-based Token bridges – these bridges allow liquidity to flow across chains in the form of messaging. Typically, they allow an asset to be minted on the target chain after it has been locked or destroyed on the source chain. Example: Rollup bridging, Polygon native bridging, Anyswap (anyCall), and Axelar networking.

Liquidity network – there are also bridges that exchange some minted assets. They allow users to move assets to other chains, assuming that those assets have been transferred ahead of time through a “message-passing” bridge. Examples: Connecxt based on Nomad bridging, Hop based on Hop Optimistic Bridge, some other HTLC (Hash Time-Lock Contract) and conditional transfers (such as nova, etc.).

Security for messaging bridging

In this section, we will try to explain the different ways in which these are used by multiple bridging protocols to validate cross-chain messages. As shown in the figure above, the Token bridge leverages the security of a messaging bridging.

· Light client verifies state validity

Description: A bridge that verifies the validity of source chain state transitions on the target chain. This verification process is either done 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 count as examples here, and L1 verifies L2’s state transitions via FraudProof or ValidityProof.

· Light client verifies consensus

Description: A bridge that verifies 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 its source chain uses a PBFT-style propose-and-vote consensus protocol (such as Tendermint, HotStuff, Casper FFG). Alternatively, if the source chain uses the PoW protocol or the “longest chain” PoS protocol (such as Ouroboros, ETH 2.0 LMD Ghost, etc.), the longest chain is checked using the relevant fork rules.

Example: NEAR Rainbow bridging (ignoring the Optimistic component associated with the complexity of the NEAR signature mechanism verification process), Polygon’s PoS bridging (checking consensus on the Heimdall chain), and Cosmos IBC (verifying the signature of another Cosmos chain).

· Set of external validators

Description: Using external validators as a bridge to the source of fact, i.e. validators who form an independent committee, rather than validators on the source chain and target chain. Depending on the implementation these validators employ, they may use MultiSig, run consensus algorithms (usually from the propose-and-vote category), use the Threshold Signature mechanism (TSS, threshold signature mechanism), SGX, etc… Regardless of the technology they use, they fall under this type of verification.

Example: Wormmhole、Multichain、Axelar、DeBridge、Synapse、Stargate。

· Optimistic validation

Description: A bridge with a challenge period during which other validators can challenge the validity of a bridge message if it is found invalid.

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 here:

1. Duration of the challenge period: The longer the better

2. Watcher set scale: no license required > requires permission

Example: Hop Protocol、Connext Amarok、Across、Nomad Token Bridge。

· Hybrid authentication mode

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

Security of liquidity networks

In addition to actually sending assets across chains, there is another way: cross-chain swap, which can be exchanged across chains simply by changing hands without moving assets across chains. (Translator’s note: A change of hands means that one party’s assets become owned by the other 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 asset 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 section only describes the security of the “exchange” protocol, i.e. how likely the LP is to abscond with the money after accepting your deposit on the source chain. These exchange assets have the security of the messaging bridging from which they are minted.

There are also some other ways to exchange assets:

·HTLC: Also known as a hash time lock contract, it can be used to atomically exchange assets between two parties across a chain. Usually only two steps are required for the user, one is to lock and the other is to unlock. A failure that can happen is that your funds are locked up for a fixed “dormant” period. Example: Connext NXTP、Liqualit。

·Conditional Transfer: Allows LPs to bridge via shortcut messages, allowing LPs to immediately fund end users and receive funds from messaging bridges whenever funds are bridged. In the event of a failure, if no LP provides liquidity, the slow path is activated. Example: Hop、Connext Amarok、MakerDAO Teleport。

·External validators: Allows users to transfer funds to a trusted bridge provider, who promises to release funds to another chain. A possible failure here is that your funds will be lost. Example: Binance

Censorship resistance

We’ll look at security assumptions about the likelihood that a single message emitted by a bridge will be reviewed. 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 (whether the funds will be returned to the user or stuck in the “transfer” state).

Typical solution:

·Take advantage of the censorship resistance of the base chain (e.g., some rollups)

·Rely on the honesty of the validator set

Total activity failure

In terms of overall active failure, we will look at the consequences of “shutting down” bridging. For example, for a bridge that uses an external validator set, we can look at the security of user funds in an event where these validators are offline for an extended period of time, possibly indefinitely. Common situations that can occur include:

·Activate Slow Path: The default mode is Slow Path and no money is lost

·Staking yourself: Users can stake to participate in the network, become validators and handle stuck transfers themselves

·Freeze: Pauses the system until the bridge operator is online


In this part, we will try to analyze the liquidity available to bridge assets. Can bridges mint assets, do LPs are needed, can users withdraw or transfer any number of tokens they choose all the time, or they rely on external LPs and bridges can “run out of funds”.

·Unrestricted (bridges can mint native/authoritative tokens)

·License required (liquidity provided by bridge operator)

·No license required (any LP can provide liquidity)

Other thoughts and indicators


·Permitted actors are required

·The amount of money transferred in the last 24 hours

·Unique transfer within the last 24 hours

·Available liquidity

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/l2-bridging-risk-architecture/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-11-05 09:47
Next 2022-11-05 09:52

Related articles