L2Bridge Risk Framework

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
5 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 (State Transfer | Polygon Technology | Documentation)

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

3 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.

2 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

Thanks @gluk64 and others for the comments, I took a good amount of time to digest this. IMHO the point is definitely valid, there exists a difference between “light client verifying state” and “rollup-bridges”

Any proposals on how to resolve this?

Should we use Consensus Bridges, Validity Bridges, Validity Bridges Pegged to a Zone?

Thanks @vaibhavchellani and @Bartek , you are definitively the persons that know most about bridges.

The framework looks fantastic and seems to have the right balance of abstraction and concreteness. I also like the user-centric angle.

I just post all the feedback that I have and all the minor points that stood out, please ignore what you think is not helpful:

  1. The “diagram showing hierarchy” indicates to me that there are 3 types of bridges, but there are only 2. Maybe you can clarify that?
  2. Somehow, I have problems making a clear cut between Message based bridges and liquidity Networks. Both exchange messages across chains, right? There would be no cross-chain communication without a message. Is the difference Lock-and-Mint vs. Lock-and-Release? If so, anyswap allows for both, right? The question here is also if this difference makes sense from the user perspective, most users bridge stables, right? So for the majority of bridges it should be Lock-and-Release. But maybe I am missing something.
  3. To me, one important point is that you only look at the security of the protocol in the section “Security of Message Bridges”. That means the security of the examples you need to analyse for L2Beat, also highly depends on how the protocol is implemented and audited. To me, Peter Robinson et al. have collected some other points to assess bridge security, see here
  4. I personally don’t agree that rollups and bridges are congruent. But rollups have a bridge built in. So maybe formulate Light client Verifying Validity of the Globale L2 State. And as Patrick pointed out, those bridges are the only ones that require the user to prove the validity before funds are released. All other bridge protocols “trust” a set of validators / watchers / stakers that a specific message is valid - if one accepts the game-theoretic proof of Optimistic Rollups as proof.
  5. I think Consensus Light Clients (if PoS is used) and Validator bridges are pretty close regarding the trust assumptions. In both cases, one trusts a set of validators that a message is valid. However, typically, the Validators of a blockchain is a more extensive set, and it might be more at stake. But if you bridge from BSC to TRON using cBridge, you might have more validators on your bridge than on the underlying blockchains.
  6. Are you sure that the Polygon PoS bridge is a Light Client Bridge and not a plain validator bridge? Maybe I got this wrong here
  7. Connext Amarok is an example in Message Bridges and Liquidity Networks - those are mutually exclusive in your framework, right?
  8. How do you define security? I might have missed this.
1 Like

Yeah good point, will try to clarify more, there are 2 ways to send tokens across-chains, we wanted to provide some context on how both of these ways are interdependent in some way

The way I like to think about it is, cross-chain transfers and cross-chain swaps, in cross-chain swaps no actual cross-chain communication happens, instead you work with a market maker and swap with him. There is no movement of tokens across-chains, token supply on both chains remain the same, only the ownership of those assets change. There is no minting of new assets, just updating ownership of already minted assets. Hope that helps a-bit, it is indeed a bit tricky, let me know if you find a better explanation somewhere else.

For the anyswap case, anyswap has anyswap-router which is indeed a liquidity network and anyswap which is the messaging bridge. anyswap-router and anyswap both have the same security as both are dictated by anyswap message-bridge the only difference being in router you lock and release and in normal ansywap-token-bridge you burn and mint.

  1. Are you sure that the Polygon PoS bridge is a Light Client Bridge and not a plain validator bridge? Maybe I got this wrong here

You are right, thanks for pointing this out, I forgot about this one. Its light client from Polygon-Ethereum because the SC on ethereum verifies polygon-consensus. But form ethereum-polygon is normal validator-set as they dont validate eth-consensus on Polygon.

  1. Connext Amarok is an example in Message Bridges and Liquidity Networks - those are mutually exclusive in your framework, right?

AFAIK, Connext Amarok is also a light wrapper on top of nomad that allows it to do cross-chain calls. Connext Amarok design is a liquidity network on top of nomad with messaging powered by Nomad.

Tbh I think it would make sense to keep Connext Amarok only in Liquidity Networks section

Thanks for the comments @Dominik, I will think abit over the comments I havent addressed yet, as they are more broad.

1 Like

Do you have any thoughts good or bad about the newly designed bridge to Arbitrum that was announced today?