Trustless interoperability between Rollups: Overview, Builds, and Challenges

Author: Marshall Vyletel Jr. Source:1kx Translation: Shan Oppa, Bitchain Vision

introduce

The number of rollups on Ethereum has seen explosive growth.According to L2Beat data, as of this writing, 91 L2 and L3 have been launched, and 82 are on the go.Therefore, there is also a lot of fragmentation in liquidity, user experience and developer tools.Current interoperability solutions need to be improved because they rely on a combination of third-party bridges, external packaging assets, and intent frameworks, and each solution has its own problems.

1. Liquidity bridges are often the target of the largest cryptocurrency hacker attacks (such as the $321 million wormhole bridge hacker attack)

2. External packaging assets are not popular, and data shows that people are more willing to hold assets in native form whenever possible (for example, according to L2Beat data, the specification bridge assets are worth $22 billion, while external packaging assets are worth only 30%.$100 million)

3. The intent framework relies on third parties that require some trust that cannot be ignored and charge additional fees to facilitate cross-rollup activities (for example, Degen chain users lose more than 80% of their tokens due to official bridge irregularities).A centralized intention framework also means lower competition, which can lead to poor pricing and performance

In this article, we investigate the prospect of trustless interoperability by defining and discussing six levels of interoperability solutions between decentralized Rollup ecosystems.

We start with the default, which is to withdraw asynchronously from the source rollup to L1 and manually bridge to the target rollup, and end with the assumption architecture of span rollup composability in a single transaction.We will explore how each level of interoperability will affect the user experience, developer experience, MEV potential, and the rollup itself (specifically related to infrastructure changes).

This article mainly discusses Ethereum and its L2, and focuses only on trustless interoperability.In this case, “trustless interoperability” refers to in-protocol channels, which do not require a third party to facilitate transmission outside the necessary infrastructure that most rollups already require.

Preparation

definition

Fundamentally, trustless interoperability requires some shared resources, and any two protocols that want to interoperate must be able to access these resources.In the case of Ethereum L1, all smart contracts exist in the same environment that shares the full state of Ethereum, so they will always have the highest level of interoperability.However, L2 shares the settlement layer only through a separate bridge contract, so interoperability is greatly limited.

The key shared infrastructure components that can drive us on the ladder of trustless interoperability are shared sorters, super builders, and shared billing.The guarantees and new features that are open to these sharing layers are related, but are essentially orthogonal.

1. Shared Serializer/Super Builder: Mainly improves speed and user experience.

2. Shared Settlement: No need for external wrapping and in-protocol messaging.

First, we will define the six trustless levels of interoperability mentioned in the introduction:

1. L1 asynchronous:
   → Manual asset transfer through summary settlement L1 to achieve interoperability.

2. Atoms contain:
   → Ensure that all transactions across the Rollup Bundle will be included in the next block of each Rollup involved in that Bundle, or are not included.

3. Shared settlement:
   → Multiple rollups are connected to L1 through the same bridge contract.

4. Atomic execution:
   → Ensure that all transactions across the Rollup bundle will be included in the next block of each Rollup involved in the bundle and executed successfully, otherwise no transactions will be executed.Successful execution means that each transaction is executed without rollback and is reflected in the updated status of each Rollup in the bundle.

5. Block-level composability:
   → The next block across the Rollup Bundle guarantees that it can contain dependent transactions (tx B on Rollup B depends on the result of tx A on Rollup A)

6. Transaction level composability:
   → Smart contract level interoperability requires only one transaction to cause state changes between multiple rollups (no bundling).Using any protocol on any rollup is logically equivalent to using a different smart contract on a chain.Importantly, this means that any state changes before the call can be restored on return.

To learn more about each level, we will cover the following key use cases to demonstrate the capabilities of each level and their impact on users, developers, aggregates, and MEV searchers.

Example:

1. Transfer of the same token
   → Send to yourself: Redeem Eth to Eth between two Rollups, or exchange ERC-20 to ERC-20

2. Token purchase
   → Cross Rollup Limit Order: Use Eth/ERC-20 in Rollup A to purchase a different ERC-20 from DEX on Rollup B and (optionally) send back to Rollup A

meaning:

We will also answer the following questions to further understand the impact on key shareholders in any aggregated ecosystem.

1. User Experience
   How will the user experience change by achieving this level of interoperability?

2. Developer experience
   How will the developer experience change by achieving this level of interoperability?

3. MEV Potential
   If we achieve this level of interoperability, is it possible to have new MEV opportunities?

4. The impact of Rollup
   Does Rollup have to opt in to any new infrastructure to achieve this?What are the changes in the cost structure of Rollup?What are the potential benefits of Rollup’s involvement in this infrastructure?

Advanced Overview

Six stages of trustless interoperability

1. L1 asynchronous

Required infrastructure:

not applicable

By definition, this refers to the current default trustless interoperability mode.All rollups are defined this way because they are built on L1 as settlement layers and can only be accessed by bridge contracts, and they periodically publish status updates to protect the network.

In this case, the only canonical way to perform any trustless cross-rollup activity is to extract the asset from the source Rollup through the canonical bridge and manually deposit it into the target Rollup once available on L1.

For Optimistic Rollup, considering the error-proof window, the withdrawal delay is about 7 days.In ZK Rollup, withdrawal delays are not quite certain, but it may be between 15 minutes and a full day, which is the case with ZkSync.

Additionally, it is also possible to use smart contracts for point-to-point atomic exchange, but this is a smaller use case and cannot be scaled effectively.

It is worth noting that there are currently third-party solutions:

1. Fluidity bridge

2. Intent Framework

Both of our examples require third-party solutions to assist.

Send to yourself:

1. Standardized practices:
   → Extract assets from Rollup A
   → Manually save Rollup B

2. Third Party:
   → Liquidity Bridge / Solver Network

Cross-rolling limit orders

1. specification:
   → Extract assets from Rollup A
   → Manually save Rollup B
   →Execute limit orders
   →To send back, the target ERC-20 must be externally packaged

2. Third party
   → Emerging solution space across aggregated limit orders
   → There are open designs that promote this around the intent of use

Since this is the default, there is no need to discuss changes in UX, DevEx, MEV, and summary.

2. Atomic Contains

Required infrastructure

Shared Serializer *

Atomic inclusion is only guaranteed that the cross-summarization bundle will be included in the next block.

This requires a shared sorter, but theoretically, if the sorters on two given rollups do not reach maximum throughput, it can be done manually (just submit two transactions to each rollup separately).That’s why we added asterisks to the required infrastructure.

However, we do not assume that the shared sorter runs the full node of each connected rollup, so it is impossible to guarantee the successful execution of a set of transactions.In this case, the shared sorter can only ensure that the transaction is formatted correctly and will be included in the next block, but it may not be executed successfully.

Since there is no execution guarantee, it is impossible to programmatically exploit the atomic inclusion in any meaningful way without incurring the risk of one of the transactions being revoked.So we are essentially in the exact same situation as L1 Async interoperability.

Consider starting a simple cross-sum exchange with only atomic inclusion guarantees:

1. Swap bundles across Rollup
   → Tx 1: Lock/destroy tokens on source Rollup
   → Tx 2: Mint the token to the user address on the target Rollup

We may have atomic inclusion guarantees, i.e. both transactions are actually included in the next block of each summary, but if the first transaction rolls back and the second transaction does not roll back, the user will be incorrect on the target chainWe will have double payment problems by allocating funds without locking or burning them on the source chain.

Any interoperability solution, whether it is a liquidity bridge, intent framework or xERC-20 exchange, is vulnerable to this risk and cannot mitigate it.Due to this risk, the current solution requires that the initiation of a transaction must have been successfully executed and included in a block on the source chain before the relay can be used to pass the outgoing message and execute a second transaction on the target chain.

Important: Atomic inclusion will not have a significant impact on interoperability potential

3. Shared settlement

Required infrastructure:

Proof Aggregation Layer //Shared Bridge Contract

This is where things start to get more interesting.Due to the existence of a shared bridge contract, all liquidity deposited from L1 into the rollup ecosystem can be freely moved between all connected rollups.Until then, we were unable to exchange between rollups without going through standardized channels, external packaging assets, or using third-party solutions.

Why establish a shared bridge contract?To understand why a shared bridge contract allows us to transfer assets across Rollup in a trustless way, first consider if you can have Eth in Rollup A, destroy it, and then mint natively on Rollup B without building on Layer1Shared bridge contract, what happens.

We see that each rollup is out of sync with the bridge contract on the mainnet.The rollup B bridge contract still has 50 Eths, so the user cannot extract 1 of its Eths to L1.

To solve this problem, we established an external asset packaging protocol to issue external packaging versions of tokens in the summary, which symbolize native versions elsewhere in the network.

With a shared settlement layer, the situation is different.Since all liquidity of each connected rollup is locked in the same bridge contract, one can move freely between rollups because the total value in the bridge contract remains the same and can always be extracted.

It does need to be updated at the L1 contract level to understand where liquidity is to allow users to withdraw money from anywhere, but this is simple because the summary of all connections can be read/write to shared contracts.

Using a shared billing layer, the process may look like the following for simple sending to yourself.

Send to yourself:

1. User creates initial transaction:
   →Tx 1: Extract Eth on rollup A (and cast on rollup B)
   →The transaction is submitted in batches and submitted to the L1 contract
   →It is aggregated into the transaction root, which groups all shared settlement rollups

2. Rollup B imports this transaction root

3. Repeater submits the transaction to the mint and submits Merkle certificate to rollup B

4. Rollup B uses Merkle Proof and transaction root to verify the destruction of transactions

5. User cast Eth on Rollup B

6. Rollup B submits proof to L1

We can extend this process to any ERC-20 that has contracts in all aggregates in the shared settlement ecosystem.

We can think of a shared bridge contract as an in-protocol messaging layer between all connection aggregations, so in theory this process can actually be extended to any arbitrary messaging standard.

This brings us closer to composability, but since the aggregation proof and message delivery is required only after state changes are reflected on L1, the latency is high (although significantly lower than the L1 asynchronous case).Additionally, any complex cross-Rollup activity (such as using DEX on Rollup B to conduct cross-Rollup limit orders from assets on Rollup A) remains a tedious process for users, as they still have to send to themselves and inManually exchange assets on the target Rollup.In this case, it is impossible to create atomic cross-rollup bundles.

Another important benefit of shared settlement is that there is less friction for liquidity providers or solvers who execute orders in multiple environments.Since their liquidity across all connected Rollups is reflected in the same bridge contract, they do not have to wait for a full withdrawal window to manage cross-rollup liquidity.

Impact on stakeholders:

1. user:
   Assets can now be transferred in native form without the need for L1 withdrawal period

2. Developer:
   Changes are limited to token issuers who can now issue native versions of ERC-20 on all connected Rollups using in-protocol messaging

3. MEV Searcher:
   Since this happens on multiple blocks per rollup, no new MEV potential exists

4. Rollups:
   Rollups must choose to use a shared bridge contract and may add precompilation to handle cross-rollup messages

Important: Shared Settlement allows non-external packaging of asset transfers and arbitrary messaging in all summaries of shared bridge contracts and proof aggregation layers, but there is still a non-negligible latency (although much shorter than L1 Async) and cannot be createdAcross atomic beams.

4. Atomic execution

Required infrastructure:

Shared sorter // Super Builder

Atomic execution allows us to guarantee successful execution of cross-volume bundles, but as we will see, there are fewer use cases for cross-volume bundles that do not rely on transactions than originally expected.

If any single transaction in a set of dependency transactions is revoked, then all other transactions will become invalid and must also be revoked, as is the case with token destruction and minting across rollups.Tokens minting on target rollups depend on whether they have been destroyed or locked on source rollups, so we can say that a set of destruction and minting transactions are a set of dependency transactions.

This bundle is not possible without an intermediate party (such as Super Builder) that can create a target transaction.

Consider what conditions must be met for a build across Rollup swap bundle without the participation of other parties other than users.A bundle has to be created to lock/burn assets on the source Rollup and mint assets on the target Rollup, but we have a problem:

1. Contracts on source rollups can only send messages when locking/destroying the original source assets, and they cannot call and create transactions on target rollups.
   →This is why the message protocol and relay network exist.
   → The message can be used to construct what the call on the target should be, but it can’t actually create the transaction itself.

2. Create a second transaction on the target rollup to mint:
   → Users cannot create this tx themselves because they do not have the right tokens on rollup B
   → i.e.) The target chain needs to prove that the token has been burned/locked on the source chain, but this proof is not available until the initial transaction is executed, which will destroy our requirement for atomicity.→ In theory, any other can
   The party that creates a second transaction with casting rights can create a “cast” transaction on the target chain at any time without first creating a “burn” or lock on the source chain, which is a huge vulnerability.

We can see that even though we can guarantee execution of cross-summarized bundles, we have difficulties in how to build them first to transfer valuable assets.

However, there are still some atomic execution use cases that do not need to rely on cross-rollup bundles.One of them is cross-rollup arbitrage:

Since there is no strict dependency between these transactions, anyone can create this atomic package and submit it to a shared sequencer that guarantees atomic execution.

However, in order to obtain the atomic execution guarantee first, the rollup must select the shared sorter and the superbuilder to run the full node of all connected rollups, so the step from atomic execution to block-level composability is very small, all shared sorting solvesThe plan will do this.The only change required is that the block builder or other third party must be able to create transactions on behalf of the user to complete the dependency cross-rollup bundle.

It is unlikely to build an infrastructure that allows only atomic execution without further implementing composability.Given that infrastructure already has atomic execution capabilities, the relative benefits of achieving full block-level composability are far more difficult than achieving this goal.

Impact on stakeholders:

1. user:
   There may not be any changes, although third parties may offer solutions like intent, it is unclear how to implement them

2. Developer:
   Probably not changing

3. MEV Searcher:
   Cross-rollup arbitrage is safer considering atomic execution

4. Rollup:
   Rollup must choose to use a shared sorter/super builder to submit a block containing transactions from each Rollup you wish to interoperate with, which may change the revenue structure of Rollup.It is not clear how it will change.-
   The sorting market may increase Rollup revenue by allowing mature builders to buy ToB space

Important: While cross-rollup bundles guarantee atomic execution, it is not clear how these bundles will be built without a super builder that creates the bundle parts, so atomic execution itself is unlikely to affect interoperability.By default, the shared sequencer/super builder should build block-level composability.

5. Block-level composability

Required infrastructure:

Shared sorter // Super builder // Proof aggregation layer * // Shared bridge contract *

(* = optional)

In most of the discussion about shared sequencers and shared settlement layers, the term commonly used to describe this level of interoperability is “synchronous composability.”

We modified the term slightly to make it more descriptive.Updating the term to “block-level composability” means that cross-rollup transaction packets can be combined between two rollups that will be included in the next block and executed successfully.Synchronous composability may be confused with transaction-level composability, which we will explore in the next section.Importantly, this requires an intermediate party (shared sorting infrastructure) that can become the executor and creator of relying on transaction packages.

At this level, we start to see true composability between Rollups, not just simply sending it to yourself to participate in the dapp on another Rollup.

By adding a shared sequencer that can create transactions, we can now make a span summary package that developers can programmatically leverage.

There are two situations to consider:

1. Block-level composability

2. Block-level composability + shared settlement layer

In both cases we can create a span summary bundle for more complex activities, but in the second case we can use native assets through shared billing, for example, this may result in a span summary DEX activityBetter price impact.

With block-level composability, we have both the advantages of atomic execution and the additional ability to create dependent transaction packages.Let’s take a look at our two illustrative examples.

Transfer of the same token via xERC-20 (no shared settlement):

1. User owns ERC-20

2. Users create tx through dapp:
   →Save ERC-20 into the xERC-20 lock box to receive the xERC-20 packaged version
   →Destroy xERC-20
   →Send a message to the shared sorting infrastructure indicating that a cross-rollup transmission has been initiated and relevant data is attached to facilitate exchange

3. Superbuilder picks up transactions and creates cross-rollup bundles
   → Tx 1: The above packaging and destruction transactions
   → Tx 2: Cast xERC-20 on Rollup B

4. Superbuilder submits this cross rollup to the shared sorter
   → Since Superbuilder is running two full nodes connected to rollups, they simulate transactions to ensure the bundle is executed successfully.If any transaction is rolled back, the entire bundle will be rolled back.

5. The shared sorter submits the block containing two transactions to the DA layer and the node that performs the state changes

6. xERC-20 cast to users on Rollup B

With the shared settlement layer, the process is further simplified because there is no need to first package the ERC-20 as xERC-20 for exchange.

Now let’s look at cross-Rollup limit orders, i.e., purchase the ERC-20 with the initial (different) ERC-20 in Rollup A on Rollup B and send the generated ERC-20 back to Rollup A.In this case, we do not assume that we have a shared settlement layer, although similar processes exist in the case of a shared settlement layer.The only difference is that there is no need to extra external packaging of the assets.

Here are the transactions required in this case:

1. Pack and destroy ERC-20 on A

2. Mint xERC-20 on B

3. Exchange the initial xERC-20 with the target ERC-20 on B

4. Pack and destroy target ERC-20 on B

5. Mint xERC-20 on A

Here are its possible workflows:

flow:

1. The user initiates the first transaction:
   →Pack and destroy xERC-20 and send a message to specify the exchange parameters (target chain, DEX address, ERC-20 to be exchanged, limit order price, Boolean value whether to send back)

2. Super Builder sees the deal and creates the bundle:
   → Tx 1: User creates the above transaction
   → Tx 2: Cast xERC-20 at the destination (super builders must have casting permissions)
   → Tx 3: Use data from tx 1 to perform limit orders
   → Tx 4: Package and destroy ERC-20 on B, assuming the limit order has been fully fulfilled and send a message on the source chain for casting
   → Tx 5: Casting target xERC-20 from exchange output on the source chain

Since the super builder creates blocks and sorts transactions, it can simulate each transaction and omits the bundle when any transaction is revoked.For example, if a user is found unable to fully fulfill their limit order, the bundle is omitted before executing the block.

In the absence of a shared sorting infrastructure for the shared settlement layer, external packaging versions of Eth and xERC-20 are required, which may cause the market conditions of DEX to worsen as the liquidity pool of packaging assets becomes thinner.In this case, users may have to use looser restrictions, higher slippage tolerance, and may receive suboptimal prices.If USDC is involved, there is one exception.A shared sorter without shared billing may work with Circle to gain exclusive rights to USDC contracts across rollups to facilitate native USDC transfers and exchanges across rollups.

With a shared settlement layer, this external packaging is unnecessary, and since the liquidity pool of native asset exchanges is deeper, it may offer better prices, but the process is basically the same.

Optimistically trust the sequencer

Rollup requires optimistic trust in shared sorters/super builders to create efficient cross-rollup bundles.This is mainly because this cross-rollup bundle contains dependent transactions that individual Rollups cannot verify until after blocks are added to each Rollup chain and aggregated to the settlement layer on L1.An example is the initial destruction and casting of Eth from source to destination.Crucially, Eth must be actually destroyed on the source chain before minting on the target chain, otherwise double payments may occur.

However, to execute this complete bundle in a block, all transactions must exist in that block, even if the transaction represents an invalid state before the block itself (e.g., if the user does not have any Eth before the block,Then there is Eth on the target chain of the exchange).Therefore, we must believe that the sorter does include valid dependencies in the cross-sum bundle.Certificates can be submitted afterwards to prove the validity of each transaction.

However, this is less important when using packaged assets, as they have no effect on native liquidity stored in L1, but there must still be a fallback mechanism to offset the risk of errors in malicious sorters or code, These errors allow the transaction bundle to be executed together with the restored dependent transaction.

Impact on stakeholders:

1. user
   Massive upgrades to the user experience, allowing cross-summarized limit orders in a single block

2. Developers
   You need to have cross-rollup awareness about cross-rollup activities and may need to leverage custom precompilation.Developers have to think from a Bundle perspective, not just deals, but super builders and custom Rollup infrastructure may remove the complexity of most developers.

3. MEV Searcher
   The chances of MEV searchers using the L1 strategy on a cross-sum bundle are basically the same, but it depends on how PBS (Proposer-Builder Separation) is implemented.
   → Cross-sum bundles are essentially considered a single transaction, so MEVs can be found by pre-trading or clamping these bundles, as long as they don’t make the price exceed the tolerable slippage amount (because the entire bundle will recover, MEV attempt will fail)

4. Rollups
   Requires opt-in to the shared sorting infrastructure (including super builders) and allows access to Eth Destruction/Casting in the shared sorter in the case of a shared billing layer.
   → MEV can be internalized by selling block space to builders

6. Transaction-level composability

Required infrastructure:

VM Level Change // Shared Settlement // Super Builder

Transaction-level composability refers to the same level of functionality shared by smart contracts on an EVM chain.In this case, a single transaction can update the state of multiple rollups simultaneously and ensure that any state changes before any call can be restored if the call does not return successfully.In fact, atomic transaction packages in block-level composable environments can be completed in a single cross-rollup and cross-VM transaction.In addition to the shared billing layer and super builder, this requires VM-level changes to all connected rollups.

We hereby describe a possible mechanism from a high level.(To the best of our knowledge, this construct is attributed to the Espresso team).First, the user submits a cross-rollup transaction to a rollup whose state is changed or a super builder who can build blocks on all relevant rollups.The super builder simulates the transaction and forms a list of input and output pairs, one for each related rollup, which specifies the necessary and expected cross-rollup messages in the transaction.(Note that super builders can do this only if they have secure sorting rights for all relevant rollups over a period of time).The super builder then sends the simulated blocks to each rollup proposer along with the expected input and output pairs of each rollup transaction.During execution, each rollup executes its own state transition function normally, assuming that the input from the list of cross-rollup transactions is correct.During settlement, the input and output lists can be cross-compared and proved safe during the proof aggregation phase of the shared settlement layer.Specifically, if any expected inputs across Rollup transactions do not match the output specified by another Rollup, the settlement process rejects the entire cross Rollup transaction.

Although there are limited new features that transaction-level composability can unlock in addition to Lightning Loan, the experience of creating cross-Rollup applications can be greatly improved.The ability to create dapps that interact with all link chains without considering cross-rollup bundles will make it much easier to innovate in multiple Rollup environments.In addition, new use cases and behaviors may emerge.

There are many unsolved design problems in transaction-level composability.First, careful consideration is needed to be given to how developers opt in or out of cross-rollup calls to their smart contracts.Allowing arbitrary composability without being restricted means we return to a single Rollup.We think the answer here is to let developers point out clearly where they need cross-rollup composability in their contracts, such as marking certain entry points of a contract as callable cross-rollup via Solidity modifiers (such as “composite”).

Impact on stakeholders

1. user:
   The same meaning as block-level composability and has other advanced features such as Lightning Loan
   → UX uses almost the same chain as opt-in dapp

2. Developer: Since dapp developers can locally call contract cross-summarization and use the output of these calls (such as single summary calls),
   The developer experiences greatly
   Improvement → Superbuilder/Sequencer infra still has to place transactions in a summary block affected by cross-summarization calls, but does not have to build the same bundle like block-level composability.

3. MEV Searcher:
   Cross-rollup bundles are now basically equivalent to a single transaction on a chain, so the MEV potential is high

4. Rollups:
   Need a virtual machine level change, as well as the selection of a shared sorter and a shared billing layer
   →Before being able to verify the state through proof, the input and output of other rollups must be trusted, which involves additional trust assumptions, but the cut mechanism can reduce the trust burden

Abstract and ecosystem map

After understanding the technical details of each interoperability level defined here, we can summarize:

1. Shared billing allows for exchange across rollups without external wrapping assets and create in-protocol messaging paths between all connected rollups

2. Shared sort/Superbuilders allows next block execution guarantees on cross-rollup bundles

3. Block-level composability allows the creation of complex, fast, interdependent cross-rollup bundles, enabling a composable ecosystem that is near smart contract to smart contract level.
   → Create these cross-rollup bundles without using external packaging assets by adding shared billing

4. Transaction-level composability is possible, and while newly opened use cases may target more complex users, it has the potential to greatly upgrade the cross-summary development experience.

Currently, many projects are emerging to create these native interoperable ecosystems.Here is a high-level overview of the field:

Ecosystem map

Conclusion

There are still some unanswered questions regarding the technical details in the framework listed in this article.For example, building a bundle for cross-summary limit orders in a block-level composable ecosystem may require more detailed design to handle slippage tolerance for partial fulfillment and market orders.We offer a potential solution here to restore the cross-summary limit order bundle if the order is not fully completed, but the design space is open.

In addition, it is worth mentioning that this is related to the growing sharing of ideas in the field of application chains at present.The application chain is a long-tail L2, either universal or licensed, with the goal of isolating a specific related agreement on one L2.When we reach block-level composability, we will most likely start to see application chain environments gain significant appeal due to native composability between all connected networks.

At present, introducing liquidity to these application chains is still difficult, but once larger chains are connected as an entrance to interoperable environments, we will likely see a walled garden ecosystem surrounding shared infrastructure.

Another important unanswered question is how the design space around the superbuilder will be solved.This development is still in its infancy and it is not clear how to create a complex network of builders that can create across aggregated packages in the most efficient way.These cross-summarized packages will be included in the block in the best way, and the impact on aggregated revenue is an open question, and many teams are exploring different strategies.

Ultimately, the future may involve a combination of in- and out-of-protocol bridging solutions that will work together to provide everyone with a better interoperability process.We believe that the progress defined in this article can serve as a guide for developers and builders who focus on providing more seamless cross-rollup interoperability for end users.