L2Bridge Risk Framework

Methodology & Framework
21

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?

22

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
23

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
24

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

25

I think its the same bridge just different UI, right?

26

Given the recent Nomad hack - we could also add additional data points:

  • audits/number of audits (and if all findings were addressed, see for example https://certificate.quantstamp.com/full/nomad)
  • maybe a risk weighting factor grows linearly with the time a particular version is deployed and not got hacked
2 Likes
27

Both good points, should definitely add it

28

Fantastic interview here outlining this exact topic from Anna Rose + @vaibhavchellani! Really enjoyed this one.

One outstanding question I had is just how people here think about the potential trade-off between theoretical security vs. exploits at the contract level. Thinking being that a bridge with great mechanism design / is theoretically “secure” might be more complex than something less robust from a design POV (but far simpler) may lead to higher likelihood of bugs being introduced?

Pod link: Episode 241: Deconstructing Bridges with Vaibhav Chellani - ZK Podcast

Transcript link: https://assets.fireside.fm/file/fireside-images/podcasts/transcripts/6/66a36787-cf18-4f96-ba6b-d00e9f507731/episodes/b/b7bdc050-525a-4a30-ab1a-dfe967c6c11a/transcript.txt

1 Like
29

Hey, love the work but would be interesting to add a section of trust assumptions as security, censorship resistance and liveliness depend to a good degree on that.
Like most of the external validator bridges, depend on the altruism of 2/3 nodes and a trust minimized bridge will have 1/n trust dependency