Original author: bartek.eth
Vaibhav Chellani from Socket and I 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 a specific solution category with similar characteristics, while being granular enough to present users with What are the security assumptions that need to be accepted.
first level title
bridging type
For end users, asset bridging refers to receiving a deposit of an asset from the source chain and transferring the asset to a user on the destination chain.
For example, a typical bridge process is that Alice transfers funds to the bridge contract of the A chain, and then Alice receives funds from the bridge on the B chain.
Broadly speaking, this process occurs in two ways:
Messaging-Based Token Bridge— 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 networkfirst level title
Security for Messaging Bridging
In this section, we try to explain the different ways these are used by several bridging protocols to verify cross-chain messages. As shown in the diagram above, token bridges leverage the security of messaging bridges.
Light client verifies state validity
Light Client Validation Consensus
external validator set
optimistic validation
Challenge period length: the longer the better
Watcher set size: No license > License required
Hybrid authentication method
describe: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, and L1 will verify the state transition of L2 through FraudProof (fraud proof) or ValidityProof (validity proof).
describe: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 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 the signature of another Cosmos chain).
describe: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 the proposal and voting class), use the Threshold Signature mechanism (TSS, threshold signature mechanism) or SGX etc.. whatever technology they use fall under this type of validation.
example:Wormmhole、Multichain、Axelar、DeBridge、Synapse、Stargate。
describe:Bridges with challenge period
An honest party in this type of verification avoids including fraudulent information during this period. However, here are a few key parameters to consider:
example:Hop Protocol、Connext Amarok、Across、Nomad Token Bridge。
describe:first level title
Security of the Liquidity 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.)
To give 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 service fees. In the end, Alice will get the asset on the B chain, and Bob will get the asset on the A chain + service fee.
This section only describes the security of the "exchange" protocol, that is, how likely LPs are to abscond with your money after accepting your deposit on the source chain. These exchange assets have the security of the messaging bridge that minted them.
also have 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. What can fail is that your funds are locked for a fixed "dormant" period. Examples: 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 case of failure, if there are no LPs providing liquidity, the slow path will be activated.example:Hop、Connext Amarok、MakerDAO Teleport。
first level title
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 happens to the user's funds (will the funds be returned to the user, or stuck in the " transfer" status).
Typical solution:
Take advantage of the censorship resistance of the underlying chain (e.g. some Rollups)
first level title
overall active failure
We'll look at the consequences of "turning off" bridges in terms of overall liveness failures. For example, for bridges that use an external set of validators, we can look at the security of user funds in the event that those validators go offline for an extended period of time, possibly indefinitely. Common situations that may occur include:
Activate the slow path: the default mode is the slow path, no funds will be lost
Staking by yourself: users can stake to participate in the network, become a validator and handle stuck transfer transactions by themselves
first level title
fluidity
In this part, we will try to analyze the liquidity available to the bridge 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 mint native/authority tokens)
Permission required (liquidity provided by bridge operators)
first level title
Other Thoughts and Indicators
Upgradability
Actors requiring permission
Transfer volume in the past 24 hours
unique transfers in the past 24 hours
available liquidity
Original link
