L2Bridge Risk Framework

Together with Vaibhav Chellani from Socket I would like to present a risk framework proposal for assessing the security profile of different bridge architectures. The overall goal is similar to the risk framework for different L2s - to be able to quickly “classify” a given solution to a particular class of solutions having similar characteristic, while at the same time be detailed enough to present users with the security assumptions that they need to accept when using these bridges. Our focus is primarily on the bridges to/from Ethereum to other chain, as these we plan to present shortly on l2beat.com, however the basic reasoning about the security of these solutions apply to bridges from any chain to another chain. At this point we are looking for a broad community feedback on the proposed framework.

Bridge Type

For the end user an asset bridge is something that accepts deposits for an asset on source-chain and gives user the asset on the destination chain. For eg: the typical flow is, Alice transfers funds to the bridge-contract on chainA, Alice received funds on chainB, simple.

Broadly speaking this happens in 2 ways:

  • Message based Token Bridges - These are bridges that allow liquidity flow via messages across-chains. They typically allow for minting assets on a destination chain upon locking or burning an asset on a source chain
    • Examples: Rollup Bridges, Polygon Native bridge, Anyswap(anyCall), Axelar Network
  • Liquidity Networks - These are bridges that swap already minted assets. They allow users to move assets to other chains assuming these assets already were bridged there using “Message” bridges
    • Examples: Connext on top of Nomad bridge, Hop on top of Hop Optimistic Bridge, some other HTLC and conditional transfers(nova etc)

Security for Message Bridges

In this section we try to explain different ways of validating a cross-chain message which has been leveraged by several bridging protocols out there. Token bridges leverage the security of the messaging bridge as shown on the diagram in the section above.

  • Light client Verifying Validity of the State
    • Description: Bridges that verify the validity of a state-transitions for source chain on destination chain. This is done via either zero-knowledge proof validation (state transition is accompanied with a zero-knowledge proof) or a fraud-proof system allowing independent Validators to dispute the validity of a new state root
    • Examples: All rollups are an example of this, L1 validates state-transtitions for L2 either via FraudProof or ValidityProof.
  • Light client Verifying Consensus
    • Description: Bridges that validate the consensus of a source chain on a destination chain. Depending on the consensus being used, this typically involves checking the quorum signatures of the current Validator’s Committee if the source chain uses a PBFT-style propose-and-vote consensus protocol (Tendermint, HotStuff, Casper FFG), or checking the longest chain with a relevant fork-choice rule if the source chain uses PoW or “longest-chain” - style PoS protocol (Ouroboros, ETH 2.0 LMD Ghost, etc…)
    • Examples: NEAR Rainbow bridge (disregarding an Optimistic component related to the complexity of validating NEAR sig scheme there), Polygon PoS bridge (checking consensus of the Heimdall chain), Cosmos IBC (verifying signatures of another Cosmos chain)
  • External Validator Set
    • Description: Bridges that use external Validators (i.e. Validators that form a separate committee than Validators on either source or destination chain) as source of truth. Depending on the implementation these Validators may use a basic MultiSig, run a consensus algorithm (typically from a propose-and-vote family), use Threshold Signature schemes, SGX, etc… Regardless of the technique used, they all lie in this bucket
    • Examples: Wormmhole, Multichain, Axelar, DeBridge, Synapse, Stargate
  • Optimistic Validation
    • Description: Bridges that have a challenge period where honest parties are supposed to prevent fraud lie in this bucket. There are however a few key parameters to consider here:
      • Challenge Duration: The larger the better
      • Watcher-set size: Permissionless > Permissioned
    • Examples: Hop Protocol, Connext Amarok, Across, Nomad Token Bridge
  • Hybrid
    • Description: There exists constructions out there that are a mixture of some of the buckets defined above.

Security for Liquidity Networks

Apart from actually sending an asset cross-chain there is an alternative method, cross-chain swaps, where no assets move across chains but simply change hands, performing a cross-chain swap.

A quick example of this is: Alice on chainA wants to move an asset to chainB. Bob(Liquidity Provider) already has the asset on chainB and offers to swap the asset on chainB for Alice’s balance on chainA for a fee. At the end Alice gets the asset on chainB, Bob gets the assets on chainA+fees.

This section only describes the security of the “swapping” protocol i.e how likely is it that your LP who accepts deposits on the source chain is going to run away with your deposit. The asset holds the security of the message bridge it was minted from.

There are a few different ways to do this as well:

  • HTLC: Also known as Hash Timelock Contracts, can be leveraged to atomically swap assets between 2 parties across-chains. Usually takes 2 actions from the user, once to lock and once to unlock. The failure case is, your funds are locked for a fixed “expiry” period
    • Examples: Connext NXTP, Liquality
  • Conditional Transfers: Allows a Liquidity provider to short circuit a message bridge such that the LP provides the funds instantly to the end user and accepts the funds from the message bridge whenever they are bridged. The failure case here is that a slow path is activated if LP is unavailable.
    • Examples: Hop, Connext Amarok, MakerDAO Teleport
  • External Validator: Allows users to transfer funds to a trusted bridging provider, who promised to release funds on the other side. The failure case here is that your funds are lost.
    • Examples: Binance

Censorship Resistance

We will look at the security assumptions related to the possibility of censorship of an individual message by the bridge. More practically we will ask whether an individual message (token transfer) can be censored/ignored by the bridge, and if this happens, what will be the consequence to the users funds (will they be returned to the user, or they will be stuck “in transit”). Typical solutions:

  • Leveraging censorship resistance of the underlying chain (e.g. some Rollups)
  • Relying on the honesty of the validator set

General Liveness Failure

For a general liveness failure we will look at the consequence of “switching off” the bridge. For example, for bridges using external Validator Sets we will have a look at the security of users funds in the event of these Validators going down for an extended period of time (possibly indefinitely). Typical scenarios include:

  • Slow Path Activated: Defaults to slow path: No loss of funds
  • Self Stake: Users can stake, join the network, become a validator and self process stuck transfers.
  • Frozen: System paused, cannot progress until the bridge operator comes online.

Liquidity

In this section we will try to analyse the liquidity available for bridging assets. Can the bridge mint assets, are LPs required, can users always withdraw/move whatever amount of tokens they choose to move or they rely on external liquidity providers and the bridge can “run out of funds”

  • Unlimited (bridge can mint native/canonical tokens)
  • Permissioned (bridge-operator provided)
  • Permissionless (any LP can provide liquidity)

Additional Considerations and Metrics

  • Upgradability
  • Permissioned Actors
  • Volume transferred in a last 24 hours
  • Unique transfers in a last 24 hours
  • Liquidity available
  • Supported tokens/chains
17 Likes

Great work putting up this overarching framework to evaluate the whole interop space with a helicopter view. Certainly the mavericks will share the technical point of view but I’m surely following up to see what the community has to say on these different risk trade-offs that we need to make when choosing to pick a specific protocol or system. Kudos @vaibhavchellani @Bartek for putting this up!

1 Like

Great work and great idea. I will be interested in following. I recently began trying to construct a table on bridges and their trust assumptions but it got messy after only ~3 rows haha. There’s tons of nuance and particulars that do not lend itself to a clean table. So I commend you.

6 Likes

Hey everyone,

Odysseas from Nomad are here. I have been diving into the overall space in an effort to a) better understand the design space from first principles and b) educate people on the tradeoffs of the various designs and how to reason about them. With the space slowly heating up from marketing-speak, it’s important to help people(end-users, protocols, etc.) make educated decisions in terms of what protocols they want to use for different use cases.

I would love to participate in this effort and be a resource :slight_smile:

For now, I would suggest that if someone wants to dive into existing literature, the following paper “SoK: Communication Across Distributed Ledgers”, was released in 2019 and still highlights the space almost in its entirety.

https://eprint.iacr.org/2019/1128

5 Likes

Hey guys, I’m Alex from deBridge. Thanks for your efforts in setting up the framework to evaluate various bridging protocol designs. I’d like to add some input based on my understanding/vision of different bridge designs.

Correct me if I’m wrong, but I haven’t seen light-client-based bridges that enable generic message transfers since cryptographic verification of arbitrary data in a light client couldn’t be achieved efficiently with reasonable gas costs.

That’s why all the light client-based bridges are focused on value transfers only (including Rainbow bridge from Near)

The only way to pass generic messages effectively is to have an external validator set or to have an optimistic design where the watcher is an optimistic alternative to the validator. Therefore, in order to have a meaningful and practical security framework, it would probably make sense to categorize all bridges into two groups:

  • bridges focused on cross-chain value transfers (cross-chain swaps)

  • bridges focused on generic messages transfers

The second group of technologies is more generalized and can be used in order to create value-transferring bridges (cross-chain swap solutions) and liquidity networks

Since in many bridges risk is borne by liquidity providers (not users), it also worth understanding who is the target audience for the security framework:

  • Liquidity providers
  • Users that perform cross-chain swaps
  • Projects/protocols that leverage generic message transfers and cross-chain calls between smart contracts

Amount of liquidity and Volume are parameters that are more related to the usability and adoption side of things rather than security.

Here is what matters for the security of the generic-message transferring bridges:

  1. Does bridge has isolated security model for every chain? What will happen with the liquidity of the bridge if there is a vulnerability/consensus problem in any supported chain/layer2 that enables an attacker to mint arbitrary assets? Whitehat Saurik received $2M for this kind of vulnerability found in Optimism (https://www.saurik.com/optimism.html). If exploited, the attacker could withdraw liquidity of many bridges, which are locked in other chains
  2. How do validators communicate, do they expose their IP addresses? How is signature verification performed?
  3. Are there any state-consistency checks performed by validators (e.g. if Wormhole had balance sheet validation, $320M wouldn’t be stolen)
  4. How good is the entropy/randomness of the transactions’ hash and how tx nonces are assigned? Is there any possibility of nonce or hash collisions? What happens with the bridge in case of 51% attack on the chain
  5. What are transactions’ finality rules?
  6. How many security audits did the project pass? Who are auditors, is there any bug bounty program live?
  7. How is the protocol authority controlled? Who are signers of the multisig
7 Likes

I haven’t seen light-client-based bridges that enable generic message transfers since cryptographic verification of arbitrary data in a light client couldn’t be achieved efficiently with reasonable gas costs.

I am not sure what you mean. All Rollup bridges can validate arbitrary messages. But you don’t need to be a Rollup. If you can relay BlockHeader containing state root as e.g. Polygon does, you can check that state root on Ethereum for any arbitrary message (Polygon Wiki)

2 Likes

Liked the overall structure, and the idea of identifying the target reader/consumer is super imp. The distinction b/w lite client verification and others is for the experts to make as I’m unaware of these nuances but overall, the focus on key security primitives, and base set of criteria to build an overarching framework is perhaps a good first step.

I didn’t consider L2 canonical bridges since they provide only L1<->L2 connection only and I don’t think the security framework that is being developed is supposed to also target canonical bridges.

Is there any light-client-based bridges that enable any<->any message transfers between chains?

Vaibhav, Bartek, fantastic to see you both starting to work on this and super important to have done right in general. We’re happy to be as helpful as we can on our end in fleshing out a framework and would love to collaborate. A few things we don’t see mentioned that might be helpful to consider (albeit some of these are more for general message bridges):

Flexibility of parameters - does the protocol have the ability to change key parameterizations (i.e. block confs from source) and could this be done maliciously / do the applications implementing have any preventative measures against this

Wrapped assets vs native assets - Wrapped assets obviously carry significantly different security assumptions and risk for the user than native assets

Will give it some more thought over the week but appreciate you both taking the lead on this and glad the community will have a consolidated source of information.

2 Likes

I would certainly consider IBC to be a light-client bridge allowing for arbitrary message passing.

NEAR Rainbow bridge that you have mentioned uses light client on the Ethereum side that verifies the proof of Burn event on the NEAR side. What would be the reason why any arbitrary event could not be verified using similar technique ?

As I mentioned, Polygon PoS bridge (on the Ethereum side) could be considered a light client as it verifies Tendermint consensus of the Heimdall chain and it allows you to pass any arbitrary message from Polygon to Ethereum.

Again, IMO, there is really nothing special about token transfers as most work by providing proof-of-burn (or proof-of-lock) to allow unlocking/minting on the destination side if the Token Bridge is built on top of the Messaging Bridge.

The Messaging Bridge can be built using external Validators (most are), but it also can be built using Light Clients.

Hey guys. I really like this effort of a bridge taxonomy!

We (Gnosis Chain, formerly xDAI) are about to develop another example for a “Light client Verifying Consensus” that can pass arbitrary messages. Currently our “arbitrary message bridge” (that underlies the token bridge: Omni-bridge) uses an external validator set.

However - a team (0xParc) is currently building a proof of concept to run an actual light client of Gnosis Chain within Ethereum (and vice versa) using ZK-Snarks. With Snarks, we might be able to not even require to run the light client “optimistically”. As Gnosis Chain will be using ETH2 consensus (https://beacon.gnosischain.com/) we can directly follow the spec of an Ethereum light client (sync committee…)

Read more about this effort here

2 Likes

Hey Martin, thank you for your support, we are aware of your efforts ! It will certainly be a novel construction as so far I am not aware of using zk-proofs used in practice to verify consensus. It this is developed, it will certainly not only enable new, more secure bridges (light clients are difficult to implement and indeed NEAR does have an optimistic component built into it due to the complexity of verifying signatures), but it will also allow Rollups to decentralise Sequencers and include such light client on ETH side to check the consensus amongst them

1 Like

value-transfer bridges like NEAR allow arbitrary message passing. for example the NearProver contract proves the validity of the events and the contract @Bartek showed parses it.

regarding risk: sometimes a transferFrom is exploited for active approvals, often infinite like what happened in AnySwap. so sometimes users are at risk while the bridge funds (if any) are not.

1 Like

Great work, thank you @Bartek and @vaibhavchellani !

Yes, I think that the picture from @Michael shows that there is a confusion. Rollups do not use light clients verifying the validity of the state – they use full clients, because they guarantee that the state is also canonical. An example of light client verifying validity of the state would be bridging Mina to Ethereum with a ZK bridge that can check the validity of the Mina state (but not whether or not you are on the canonical branch).

2 Likes

Hey Alex, thank you for your feedback. The terminology is definitely something we can change here. Patric McCorry uses the terms Validating Bridges for what we called “Light client verifying validity of the state” and Consensus Bridges for what we called “Light client verifying consensus”.

I proposed “Light client” as for me a “Full client” is a node that re-executes all transactions and computes the state itself but I guess it is a matter of the definition.

I don’t know exactly how Mina works but I am not sure why would you build a bridge that verify the validity of the state but not the consensus ? It would be as if you checked the validity of the state signed by one random Validator in Tendermint while the 2/3s signed a different one

1 Like

Thanks for putting this together @Bartek and co!

I agree with gluk64 that “light client” is a bit overloaded as is, and probably shouldn’t be used for rollups; one framing is that for rollups, the clients are “full” (perform full state validation), but the proofs (fraud or validity) about one chain’s state to another are succinct… succinct proof bridges? idk

1 Like

Because with cross-chain bridges you can NEVER verify the consensus, for a fundamental reason: you don’t know if there are forks that the community finds more canonical. Full consensus must go all the down to Layer 0: the social consensus.

Forkability is blockchains’ superpower. Without it, we are all at mercy of the honest (or not so honest) majority.

Even without forks, you can never be sure if there is no alternative branch also signed by 2/3 of the validators stake.

For rollups, this problem does not exist: if there is a fork of L1, then you will simply have a fork of your rollup too.

Therefore, we must make a huge clear distinction between native bridges within a single zone of sovereignty, and non-native bridges crossing zones of sovereignty.

There are more nuances I would like to address, for example in Liquidity: in my opinion native tokens have very different properties than virtual tokens with parked counterparts. Is it worth maybe organizing a call to go through it together?

BTW, the slush paper is very insightful.

3 Likes

I appreciate the response. Strangely, Consensys just put out a bridge piece and it included this " 1. Rollups can be seen as highly secure bridges. The validity of messages and resulting states can be proven on layer-1. They implement a light client on layer-1 that checks the validity of the state root from layer-2. That way, rollups have the fewest trust assumptions of all bridges. The bridge will only release the funds if there is a mathematical or cryptoeconomic proof of correctness. This proof happens on layer-1 and that way those bridges inherit the security of the layer-1 blockchain." Is this incorrect?

Yeah, they mention this post as the source, which highlights the need to finalize the terminology and concepts ASAP, before confusing ideas propagate.

I don’t think there is clear definition of “light client” outside of the node implementation. But when you look at how “light node” and “full node” are defined, it’s clear that the rollup bridge functionality is exactly the same as the functionality of a “full node”. Thus, using the term “light client” will definitely cause confusion (it does for me).

2 Likes