Mesh vs Hub: Approaches to Rollup Interoperability

Written by Alejandro Ranchal-Pedrosa.

We would like to thank Ben Fisch, Brendan Farmer, and Mark Tyneway for their useful feedback on an initial draft of this post, and acknowledge contributions from other Scroll team members Dom and Sarah.

Introduction

In late 2020, Ethereum embraced a rollup-centric approach to deliver fast and cheap transactions. However, it comes at the cost of increased fragmentation, as users and liquidity scatter across multiple rollups. This fragmentation is an ecosystem-wide challenge that prevents a unified Ethereum experience.

In this article, we will examine the roots of this fragmentation, examine one of the core challenges of rollup interop, equivocation, and categorize the solutions that exist to tackle this issue. By describing the different proposed solutions regarding rollup interoperability and highlighting the trade-offs involved, we hope to provide a glimpse into the future of rollup interoperability and how to build a better-connected rollup future.

The problem of fragmentation

Fragmentation of state across different rollups leads to a poor user experience, reduced capital efficiency, and lack of native composability:

User Experience: Fragmentation forces users to switch networks frequently, manage multiple copies of the same token, and juggle various wallets. This adds friction and complexity, making it harder for users to enjoy a seamless, “just works” Ethereum experience. For example, suppose Alice has her funds on rollup A but wants to buy a token available only on Rollup B. Instead of just clicking “Buy,” she must first switch networks, transfer her funds from A to B, wait for L1 confirmations, and then execute the trade.

Liquidity: With liquidity dispersed across many rollups, trading pairs lack depth and efficiency. This leads to worse prices, reduced yields for lending protocols, and suboptimal trade execution.

Composability: On a single chain, a lending protocol can instantly liquidate a position by calling a DEX contract in the same transaction—everything happens in one atomic, synchronous step. In a fragmented, multi-rollup world, that process becomes asynchronous. The protocol might trigger a liquidation on one rollup, then wait for a message to finalize on another rollup’s DEX. If anything goes wrong, reversing the process isn’t straightforward. There are also no tools natively provided by Ethereum to make cross-rollup contract calls or guarantee fast execution of these calls. This loss of immediate, atomic interactions undermines the composability that makes Ethereum’s ecosystem so powerful.

Interoperability

At its core, interoperability means enabling a transaction that starts on one rollup and updates the state on another — like sending tokens from Rollup A to Rollup B. Ideally, this action is as simple as having your balance on A go down and your balance on B go up, all at once. In practice, achieving such seamless “all-or-nothing” behavior is challenging between different rollups.

Ideally, interactions across rollups would work just like they do on Ethereum L1— synchronously. In a synchronous setting, multiple calls to different contracts in different rollups can be bundled into a single transaction that either succeeds entirely or fails entirely, providing immediate and atomic outcomes.

In contrast, asynchronous composability involves multiple steps spread out over time across different rollups. Instead of a single atomic transaction, an action might trigger an event on one rollup and then wait for confirmation before completing the interaction on another. Asynchronous composability needs to deal with aborts: only one of the rollups may perform the action timely, and then it may need to revert this partial state transition (as the counterpart rollup did not do its part). Synchronous and asynchronous composability share many common challenges that we discuss here.

This article focuses on native rollup interoperability solutions that require protocol-level integration. We exclude external bridging solutions that rely on liquidity providers and only support fungible token transfers.

The challenges of interop

Achieving true interoperability between rollups is not just about sending messages back and forth; it’s about ensuring transactions finalize securely and quickly. Relying solely on Ethereum L1 can mean long delays and high costs. Alice has her funds on rollup A but wants to buy a token available only on Rollup B. Two options are possible:

• Rollup B only accepts Alice's funds if bridged through Ethereum. In this case, Alice needs to withdraw her funds to L1, then deposit them into rollup B, and finally buy the token in rollup B, incurring high delay and cost.
• Rollup B provides a faster, cheaper path by processing the transfer directly rather than settling on Ethereum Layer 1 first. However, as we explain below, this exposes Rollup B to potential reorg risks if Rollup A equivocates, does not settle or submits an invalid state transition.

When two L2s interact at faster-than-Ethereum latency (i.e., before they even commit or settle their state transitions to L1), there are three fundamental issues that rollups need to deal with: equivocation, invalidity, and non-settlement.

1. Equivocation: A rollup broadcasts conflicting states to different chains, effectively promising the same assets multiple times.
2. Invalidity: A state transition might never be provably correct on L1.
3. Non-settlement: The proof generation or settlement process might stall indefinitely.

Let’s reiterate here that all these issues can be trivially solved by waiting for L1 finality - when state transitions are fully settled on Ethereum. However, we're interested in enabling secure cross-rollup interactions at faster-than-Ethereum latency. We explore solutions that maintain security while operating in this sub-finality window.

Let us illustrate these challenges with an example: suppose Alice owns 10 ETH on Scroll mainnet and wants to transfer them to Bob in Arbitrum. Ideally, Alice would be able to move liquidity between these two chains natively at faster-than-Ethereum latencies. Suppose such a solution existed, in that Arbitrum credited Alice with 10 ETH in Arbitrum before Scroll submitted anything to L1, what can go wrong for Arbitrum?

1. Equivocation: Scroll equivocates by committing on L1 a different state transition in which Alice's transaction is not included, effectively robbing 10 ETH from Arbitrum (which needs to reorg to be able to settle).
2. Invalidity: Scroll does not equivocate, but the state transition that contained the transaction is invalid, and thus Scroll can never settle it (i.e. prove it) on L1 and give the funds to Arbitrum. Again, Arbitrum needs to reorg to be able to settle.
3. Non-settlement: Scroll does not equivocate and the state transition is valid, but Scroll's designated provers go offline and thus settlement never happens. Arbitrum needs to reorg again.

By Arbitrum integrating the 10 ETH sent from Alice in Scroll before Scroll commits on L1 (in the case of equivocation) and before Scroll settles (in the case of invalidity and non-settlement), Arbitrum takes a risk in its chain dependent on the security considerations of Scroll.

A critical aspect of rollup interoperability is how systems handle equivocation. Different architectures take different approaches. In some systems like the OP Superchain, rollups are designed to reorg together - if one rollup equivocates, all connected rollups must reorg their state to maintain consistency across the system, a property called cross-chain contingent blocks. Other architectures focus on preventing equivocation entirely through various mechanisms we'll explore below.

Both non-settlement and invalidity will be trivially solved once real-time generation of zk proof becomes practical (a.k.a. real-time proving). The problem of equivocation is however fundamentally different. A zk proof can prove that Alice sent 10 ETH to Bob on Arbitrum, but it does not guarantee that Scroll will commit this transition on L1. Zk proofs alone do not solve and will never solve equivocation. Then again, waiting for L1 settlement solves equivocation but at the price of the rollup's speed advantage. Thus, we focus on pre-settlement equivocation, i.e., equivocation-prevention guarantees before settlement to Ethereum. As we will see, each approach involves different trade-offs, notably in term of trust assumptions that we discuss below.

Interop architecture

We present two different approaches that have been explored for interoperability at faster-than-Ethereum latency, which we call the mesh and the hub.

In short, the mesh model is where rollups are directly interconnected with each other in a clique where they all trust each other not to equivocate in order to achieve pre-settlement finality.

The hub model introduces a shared layer, which rollups rely on to handle equivocation-prevention of cross-chain interactions at faster-than-Ethereum latency. Let’s explore what this difference means in practice.

Mesh

The mesh model works just like you might expect, with rollups communicating with each other directly while still being in charge of settling to Ethereum L1 themselves:

As more and more rollups become interconnected in this big mesh, the transitivity of trust and dependencies becomes a problem for scalability. If Arbitrum trusts Scroll but not zkSync, then Scroll cannot trust zkSync while maintaining Arbitrum's trust. Only disjoint "trust groups", i.e. cliques of rollups, can interact with each other in a mesh. This dependency problem is amplified as more and more rollups are involved in complex interop cases, where the security of the whole is limited to the security of the weakest rollup.

While mesh systems rely on trust for pre-settlement safety, they can detect equivocation at settlement, triggering reorgs across all connected rollups.

Therefore, although this interop model has some shortcomings, it is entirely suitable for cases where the desired cross-chain operations are limited to major rollups that have proven to be secure and/or trustworthy, and that are willing to create this trust dependency in their systems. However, it quickly becomes apparent that this model doesn’t scale well if we want to add more and more rollups, other L2s, and even appchain L3s in the mesh.

Hub

In the hub model, the shortcomings of the mesh model are addressed by introducing a shared layer. Each rollup needs to trust this layer, which acts as the source of truth for interactions, so linking one more rollup to the layer is much easier. Naturally, we need this layer to be as secure as possible to offer the best non-equivocation guarantees at a faster-than-Ethereum latency.

The advantage of this solution is that adding extra rollups in the mix doesn’t create more dependency problems, since the interop layer acts as a “shield” between each rollup. This can include any arbitrary L2 chains, as well as L3s and app rollups - all they have to do is get integrated into the hub and enjoy the benefits.

The major tradeoff of this approach is that all rollups have a common shared dependency in the hub, that gains significant power.

Specifically, for pre-settlement equivocation-prevention, we must ensure that the hub will not collude with an equivocating rollup. Hub systems thus replace the mutual trust between rollups in the mesh design, with trust in a single shared layer that must not collude with other rollups to equivocate.

It is thus no surprise that the hub must be built with security and decentralization in mind. There are a few different options for constructing such a hub:

• Using an existing rollup: This option has the advantage of being the simplest one, as the rollup already exists and has presumably been battle-tested, and it would be a matter of deploying smart contracts on it.
• Creating a dedicated component: Instead of asking rollups to rely on all the security properties of an existing rollup, we instead create a new dedicated component to act as the hub. The advantage here is this new component would have a minimized bug/exploit surface vector by being specifically tailored for cross-chain needs (and could even be formally verified!).
• Using Ethereum L1 itself: This option involves using based preconfirmations directly on Layer 1 to have the best of both worlds: use the maximally decentralized layer for peak liveness and security while having near-instant confirmations, minimized withdrawal times, etc.

Assuming zk proofs are being used, all three of these options can leverage the concept of proof aggregation to further reduce the costs involved, by having the L1 verify a single proof that batches many individual proofs from all the rollups that are supported by the hub.

Existing systems

Multiple projects have proposed various interop solutions, which can be categorized as follows.

Mesh systems. OP Superchain and Arbitrum's Chain-clusters are mesh systems, where chains must cross-settle together - if one chain equivocates, all connected chains must reorg. Chains must trust each other for pre-settlement confirmations.

These solutions might transition towards using some kind of hub as the cliques of trust cannot scale beyond a few big rollups to achieve pre-settlement finality.

Hub systems. Espresso and zkSync's Elastic Chain are hub systems. At Scroll, we have been exploring a hub design that could enable more scalable and trustless interop solutions. Our presentation at the Columbia CryptoEconomics Workshop 2024 provides an overview of the design, with more details to follow in an upcoming post.

Other systems. Based rollups have the potential to enable synchronous composability not just with each other, but even with Ethereum L1, and can in turn use Ethereum L1 for equivocation-prevention.

Polygon’s AggLayer is another type of hub system that provides a shared layer with which rollups all communicate. However, it differs by avoiding additional trust assumptions in that shared layer. Instead they wait for settlement and use *pessimistic proofs* to provide security. Equivocation is thus prevented only at settlement time. Pre-confirmations could optionally be used to offer faster finality guarantees. The AggLayer recently announced a partnership with Espresso Systems, that provides a shared sequencing mechanism.

Conclusion

Developing an equivocation-prevention mechanism for faster-than-Ethereum interop comes with all sorts of tradeoffs that need to be carefully considered for the sake of security, decentralization, and credible neutrality. While this post focused on equivocation-prevention, there are several other critical interop challenges we haven't deeply discussed here, such as data availability, settlement layer design (e.g., implementation of shared bridge and rollup contracts between different rollups), message passing protocols, and the economic incentives needed to make the system work. But as Vitalik said in a recent tweet, we are closer to solving these cross-chain problems than most people think. In this interop endgame, we believe users will truly feel like they are “using one Ethereum”, as opposed to individual rollups like today.