DLT Interoperability and More ⛓️#11 ⛓️ — SoK: Validating Bridges as a Scaling Solution for Blockchains

In this series, we analyze papers on blockchain and interoperability (and both).

This edition covers a recent paper on layer 2 technology.

Photo by Luke Besley on Unsplash

➡️ Title: SoK: Validating Bridges as a Scaling Solution for Blockchains
➡️ Authors: Patrick McCorry, Chris Buckland, Bennet Yee, Dawn Song

➡️ Paper source: https://arxiv.org/abs/2208.07119

➡️ Contributions:

This work is about validating bridge contract, an important component that enforces security properties on layer 2 solutions. These contracts assure the safety and liveness of the off-chain system especially if the operators turn out to be malicious.

— the authors systematize the components of a validating bridge, and present a list of relevant research problems for researchers to tackle relative to bridges

— the authors evaluate the state-of-art implementations to present their design choices, the financial cost of operation, and future direction. Please, also check our survey on blockchain interoperability!

Background:

• We have three components: a source blockchain, a bridge (called by the authors validating bridge contract), and a layer 2 (L2) system. The bridge contract is “only used to automate the withdrawal process for users and it cannot enforce, or even inspect, the off-chain system’s integrity”. The off-chain system (L2) aims to execute transactions (performing offloading from the source blockchain). In other words, it leverages blockchain interoperability (the bridge) to improve the scalability of the source blockchain. The bridge locks assets from the source blockchain and mints tokens that users can use on the L2 system to pay transaction fees, while retaining the underlying blockchain’s security.
• The layer 2 has a runtime and a widely replicated database that anyone can independently recompute. Thus, anyone can verify if updates on the layer 2 system are valid. Periodically, this verification is done in the form of a commitment (validity proofs vs. fraud proofs). In a fraud proof system, the bridge contract “initiates a challenge process for a commitment. This provides an opportunity for a challenger to submit evidence if there is an invalid state transition and for the bridge contract to reject the commitment. If there is no evidence of fraud by the time the challenge expires, then the bridge contract accepts the commitment as final.”. The paper explains the different types of fraud proofs. In a validity proof system, “The executor must present evidence alongside the commitment to prove that all state transitions are valid. There is no challenge period and the bridge contract can accept the commitment immediately.”. There are trade-offs between those that we can explore in a future article.
• We have four parties participating in the ecosystem: users, sequencers, executors, and challengers. Users lock their funds to execute transactions in an L2 — typically they lack the computational resources or technical expertise to verify it in real-time. Sequencers order transactions on the bridge contract, that reflect the execution order in the L2. Executors execute such transactions and are responsible for creating commitments that assert the validity of such executions, that are posted on the bridge. Challengers monitors executors by validating commitment proofs — if executors provide an invalid proof of execution, challengers can submit a challenge (typically called fraud-proof), resulting in the slashing of the executor and the emission of an award to the challenger.
• For the interested reader, see, for example, https://l2beat.com/. This website contains a compendium with L2 solutions, their total value locked, threat model, technical description, latency for withdrawals, and others. It is an excellent primer repository.

💪 Strong points:

• Provides a simple, clear, and general introduction to L2. A good first paper to get into the area.

😞 Limitations:

• Not exactly a limitation: could be interesting for a more technical audience the formalization of the security properties and the different L2 models.
• I feel that the paper could be much more enlightening if it had a few more figures. Imagining those processes is not trivial.

🔥 Points of interest:

• “Protocol assumptions We only consider protocol assumptions for the underlying blockchain that is hosting the bridge contract” — those are lock producers of the underlying blockchain are not colluding with the sequencers, executors, or challengers; Eventual delivery;
• We assume an adversary can corrupt all sequencers and executors, but they cannot manipulate the challenger, bridge contract, or honest user. However, the adversary cannot prevent the delivery of messages to the bridge contract (this would imply control over a substantial amount of nodes on the source blockchain).
• Security Properties

1. “The bridge contract can verify the data is publicly available such that anyone can recompute the database independently.” — known as the data availability problem. Typically, to solve this problem, L2s post the data directly on the bridging contract (we typically call them rollups). Platforms like Celestia are attempting to provide infrastructure to alleviate this problem.

2. “The bridge contract is convinced that all transactions executed in the commitment are valid and the commitment represents a valid new state of the database.”

3. “The bridge contract can enforce the eventual ordering and execution of transactions to ensure users can always unwind their positions and withdraw their funds.” — censorship resistance. Questions like “is MEV possible to exploit in L2 systems” depends on specific implementations — in principle, sequencers can benefit from MEV (sandwich attacks, for example). However, there are some proposals for fair-ordering protocols that would minimize nefarious effects of MEV. We talked a bit about MEV in our previous article.

• Different ways to elect executors are delegated vote (set of users can vote to appoint a member to become a sequencer (or executor) based on their weight in tokens) and weighted stake (any user can stake funds in the bridge contract and self-appointed themselves to a role).
• “Our aim is to restore composability for smart contracts that are instantiated on their own off-chain system.6 or deployed on one (or more) off-chain systems7 Protocols that focus on cross-chain communication [106] can help re-introduce atomic composability which can be broken into message delivery and value transfer” — this is precisely what our paper Hermes aims to do.
• It is not very clear to me “Unlike a validating bridge, the sidechain approach assumes the off-chain system safety (the integrity of its ledger) and liveness (continuous progress of confirmed transactions) is outside the scope of the bridge contract. As such, the sidechain’s bridge contract can verify the state of the off-chain system, but it cannot verify its integrity or force its progression.” — why can’t a bridge contract verify the integrity of a sidechain? Similarly, it is not very clear how some projects “enforce a minimum number of transactions to be processed”, or enforce

🚀 How does it relate to our work at Técnico Lisboa, INESC-ID, and Blockdaemon? (views are my own and do not necessarily reflect the opinions of my employer)

• Enabling secure, scalable interoperability is an important part of what we do at Blockdaemon. Studying cross-chain security allows a better understanding of the technology, and therefore more secure implementations of protocols.

🚀 What are the implications for our work?

• This work helps us build more secure blockchain interoperability middleware.