Author: Marshall Vyletel Jr. Source: 1kx Translation: Shanoba, introduces the explosive growth in the number of rollups on Ethereum. According to L2Beat data, as of the time of writing this article, 91 L2 and L3 have been launched, and 82 are about to be launched. Therefore, there is also a significant amount of fragmentation in terms of liquidity, user experience, and developer tools. The current interoperability solutions still need improvement, as they rely on a combination of third-party bridges, external packaging assets, and intent frameworks, and each solution has its own issues. Liquidity bridges are often the biggest targets of cryptocurrency hacking attacks (such as the $321 million wormhole bridge hack). Externally packaged assets are not popular, and data shows that people are more willing to hold assets in their native form whenever possible (for example, according to L2Beat data, standardized bridge assets are worth $22 billion, while externally packaged assets are worth only $3 billion). Intention frameworks rely on third parties who require some significant trust and charge additional fees to facilitate cross Rollup activities (for example, Degen chain users lost over 80% of their tokens due to non-standard official bridges). The centralized intent framework also implies lower competition, which may lead to suboptimal pricing and performance. In this article, we investigate the prospects of trustless interoperability by defining and discussing six levels of interoperability solutions between decentralized Rollup ecosystems. We start with the default scenario of asynchronous withdrawal from the source rollup to L1 and manually bridging to the target rollup, and end with the assumption of composability across rollups in a single transaction. We will explore how interoperability at each level will affect user experience, developer experience, MEV potential, and rollup itself (specifically related to infrastructure changes). This article mainly discusses Ethereum and its L2, and only focuses on trustless interoperability. In this case, 'trustless interoperability' refers to channels within the protocol that do not require third parties to facilitate transmission outside of the necessary infrastructure that most rollups already require. Fundamentally speaking, trust free interoperability requires some shared resources, and any two protocols that wish to interoperability must be able to access these resources. In the case of Ethereum L1, all smart contracts exist in the same environment that shares the complete state of Ethereum, so they will always have the highest level of interoperability. However, L2 only shares the settlement layer through a separate bridging contract, which greatly limits interoperability. The key shared infrastructure components that can propel us forward on the ladder of trustless interoperability are shared sorters, super builders, and shared settlements. The guarantees and new features opened by these shared layers are related, but essentially orthogonal. Shared sequencer/super builder: mainly improves speed and user experience. Shared settlement: Asset exchange that does not require external packaging or message transmission within the protocol. Firstly, we will define the six trustless interoperability levels mentioned in the introduction: L1 asynchronous: → manual asset transfer through L1 aggregated settlement to achieve interoperability. Atomic inclusion: → Ensure that all transactions across Rollup bundles will be included in the next block of each Rollup involved in that bundle, or not included at all. Shared settlement: Multiple rollups are connected to L1 through the same bridging contract. Atomic Execution: → Ensure that all transactions across Rollup bundles 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 refers to each transaction being executed without rollback and reflected in the update status of each Rollup in the bundle. Block level composability: → The next block across Rollup Bundles is guaranteed to contain dependent transactions (tx B on Rollup B depends on the result of tx A on Rollup A) Transaction level composability: → Smart contract level interoperability requires only one transaction to simultaneously cause state changes between multiple Rollups (without bundling). Using any protocol on any rollup is logically equivalent to using different smart contracts on a chain. Importantly, this means that any state changes prior to the call can be restored upon return. To further understand each level, we will introduce the following key use cases to demonstrate the functionality of each level and its impact on users, developers, aggregators, and MEV searchers. Example: Same token transfer → Send to oneself: Exchange Eth for Eth between two Rollups, or exchange ERC-20 for ERC-20 token purchase → Cross Rollup limit order: Use Eth/ERC-20 in Rollup A, purchase different ERC-20s 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. What changes will occur in user experience by achieving this level of interoperability? How will the developer experience change by implementing this level of interoperability? If we achieve this level of interoperability, is it possible for new MEV opportunities to emerge? Does Rollup have to choose to add any new infrastructure to achieve this? What are the changes in Rollup's cost structureWhat potential benefits may Rollup's participation in this infrastructure bring? Advanced Overview: Six Stages towards Trustless Interoperability 1 L1 asynchronous infrastructure required: Not applicable by definition, this refers to the current default untrusted interoperability mode. All rollups are defined in this way because they are built as settlement layers on L1 and can only be accessed through bridging contracts. They regularly publish status updates to protect the network. In this case, the only standardized method to perform any trustless cross Rollup activity is to extract assets from the source Rollup through a standardized bridge and manually store them in the target Rollup once they are available on L1. For Optimal Rollup, considering the error prevention window, the withdrawal delay is about 7 days. In ZK Rollup, the withdrawal delay is uncertain, but it may range from 15 minutes to a whole day, which is the case with ZKSync. In addition, it is also possible to use smart contracts for point-to-point atomic exchange, but this is a small use case and cannot be effectively extended. It is worth noting that there are currently third-party solutions available: the liquidity bridge intention framework. Both of our examples require third-party solutions to assist. Send to oneself: Standard practice: → Extract assets from Rollup A → Manually deposit into Rollup B Third party: → Liquidity Bridge/Solver Network Cross rolling Limit Order Specification: → Extract assets from Rollup A → Manually deposit into Rollup B → Execute limit orders → To send back, external packaging of the target ERC-20 must be done with a third party → Emerging solution space for cross aggregated limit orders → Open design around usage intent to facilitate this. As this is the default situation, there is no need to discuss changes in UX, DevEx, MEV, and aggregation. 2. Atomic inclusion requires infrastructure sharing sequencer * Atomic inclusion only guarantees that cross aggregation bundles 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 manually implemented (simply 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 complete nodes of each connected rollup, so we cannot guarantee the successful execution of a set of transactions. In this case, the shared sorter can only ensure that the transaction format is correct and will be included in the next block, but it may not necessarily be executed successfully. Due to the lack of execution guarantees, it is impossible to utilize atomic inclusions in any meaningful way through programming without incurring the risk of one of the transactions being revoked. Therefore, we are essentially in the same situation as L1 Asynchronous interoperability. Consider launching a simple cross aggregation exchange with only atomic inclusion guarantee: cross Rollup exchange bundling → Tx 1: lock/destroy tokens on the source Rollup → Tx 2: cast tokens to the user address on the target Rollup. We may have atomic inclusion guarantee, which means that both transactions are actually included in the next block of each aggregation. However, if the first transaction rolls back and the second transaction does not, the user will incorrectly allocate funds on the target chain without locking or burning them on the source chain, and we will encounter a double payment problem. Any interoperability solution, whether it's a liquidity bridge, intent framework, or xERC-20 exchange, is susceptible to this risk and cannot mitigate it. Due to this risk, the current solution requires that the initiating transaction must have been successfully executed and included in the block on the source chain before the relay can be used to transmit the sent message and execute the second transaction on the target chain. Important note: Atomic inclusion will not have a significant impact on interoperability potential The infrastructure required for shared settlement: proof of aggregation layer//shared bridge contract. This is where things start to become more interesting. Due to the existence of shared bridge contracts, all liquidity stored in the rollup ecosystem from L1 can freely move between all connected rollups. Prior to this, 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 manner, first consider what would happen if we could have Eth in Rollup A, destroy it, and then cast it natively on Rollup B without the need to establish a shared bridge contract on Layer1. We see that each rollup is out of sync with the bridging contract on the main network. The rollup B bridging contract still has 50 Eth, so users cannot extract 1 Eth to L1. To address this issue, we have established an external asset packaging protocol and issued external packaged versions of tokens in the aggregation, which symbolize native versions elsewhere in the network. With the shared settlement layer, the situation is different. Since all liquidity of each connected rollup is locked into the same bridge contract, people can move freely between rollups because the total value in the bridge contract remains constant and can always be extracted. It is indeed necessary to update at the L1 contract level to understand where the liquidity is, in order to allow users to withdraw from anywhere, but this is simple because the summary of all connections can be read/written into the shared contract. Using a shared settlement layer, for simple sending to oneself, the process may look like the followingSend to oneself: User creates initial transaction: → Tx 1: Extract Eth on Rollup A (and mint it on Rollup B) → Transactions are batched and submitted to L1 contract → It is aggregated into the transaction root, which imports all shared settlement Rollup groups Rollup B into this transaction root. The relay submits the transaction to the mint and submits the Merkle proof to Rollup B. Rollup B uses Merkle Proof and transaction root to verify the destruction of the transaction. The user has minted Eth on Rollup B and submitted the proof to L1. We can extend this process to any ERC-20 with contracts in all summaries in the shared settlement ecosystem. We can consider the shared bridge contract as an intra protocol message passing layer that aggregates all connections, so theoretically this process can actually be extended to any arbitrary message passing standard. This brings us closer to composability, but due to the fact that aggregation proofs and message passing are only required after reflecting state changes on L1, the latency is higher (although significantly lower than in the asynchronous case of L1). In addition, any complex cross Rollup activity (such as using DEX to start a cross Rollup limit order from assets on Rollup A on Rollup B) remains a tedious process for users as they still have to send themselves and manually exchange assets on the target Rollup. In this case, it is not possible to create atomic cross Rollup bundles. Another important benefit of shared settlement is that it reduces 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 complete withdrawal window to manage cross Rollup liquidity. Impact on stakeholders: Users: Assets can now be transferred in native form without L1 withdrawal period. Developers: Changes are limited to token issuers, who can now use protocol messaging to issue ERC-20 native versions on all connected Rollups. MEV searchers: As this situation occurs on multiple blocks of each Rollup, there is no new MEV potential. Rollups: Rollups must choose to use shared bridge contracts and may add precompilation to handle cross Rollup messages. Important note: Shared settlement allows non externally wrapped asset transfers and arbitrary message delivery in all aggregates of shared bridge contracts and proof aggregation layers, but there will still be significant delays (although shorter than L1 Asynchronous). And it is not possible to create cross aggregated atomic beams. 4. Infrastructure required for atomic execution: Shared Sorter//Super Builder Atomic execution allows us to ensure successful execution of cross volume bundles, but as we will see, the number of use cases for cross volume bundles without transaction dependencies is less than initially expected. If any single transaction in a set of dependent transactions is revoked, all other transactions will become invalid and must also be revoked, just like the case of cross rollup destruction and token minting. The minting of tokens on the target rollup depends on whether they have been destroyed or locked on the source rollup, so we can say that a set of destruction and minting transactions is a set of dependent transactions. If there is no intermediary (such as a super builder) who can create the target transaction, it is impossible to create this bundle. Consider what conditions must be met for the construction of cross Rollup exchange bundles without the involvement of any parties other than the user. We must create a bundle to lock/burn assets on the source Rollup and cast assets on the target Rollup, but we encountered an issue: contracts on the source Rollup can only send messages when locking/destroying the original source assets, and they cannot call and create transactions on the target Rollup. This is the reason why message protocols and relay networks exist. The message can be used to construct what the call on the target should be, but it cannot actually create the transaction itself. Create a second transaction on the target rollup for minting: → Users cannot create this tx themselves because they do not have the right to mint tokens on rollup B → That is, the target chain needs to prove that the token has been burned/locked on the source chain, but this proof can only be used after the initial transaction is executed, which would violate our requirement for atomicity. In theory, any other party capable of creating a second transaction with casting rights can create a "casting" transaction on the target chain at any time without first creating a "burn" or lock on the source chain, which is a huge loophole. We can see that even though we can ensure the execution of cross aggregation bundles, we have encountered difficulties in how to first build them to transfer valuable assets. However, there are still some atomic execution cases that do not rely on cross roll up bundles. One of them is cross roll 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 atomic execution assurance first, Rollup must choose a shared sorter and super builder to run the complete nodes of all connected Rollup, so the step from atomic execution to block level composability is very small, and all shared sorting solutions will achieve this. The only necessary change is that the block builder or other third party must be able to create transactions on behalf of the user to complete the dependent cross rollup bundleIt is unlikely to build an infrastructure that only allows atomic execution without further achieving composability. Considering that the infrastructure already has atomic execution capabilities, the relative benefits of achieving full block level composability far exceed the difficulty of achieving this goal. Impact on stakeholders: Users: There may not be any changes, although third parties may provide solutions like intent, the specific implementation is still unclear. Developers: MEV may not change. Searchers: Considering atomic execution, cross rollup arbitrage is safer. Rollup: Rollup must choose to use a shared sorter/super builder to submit blocks containing transactions from each Rollup they wish to interact with, which may change Rollup's revenue structure. It is currently unclear how it will change- The sorting market may increase Rollup's revenue by allowing mature builders to purchase ToB space. Important note: Although cross Rollup bundles ensure atomic execution, it is unclear how these bundles will be built without creating super builders for the bundle portion, so atomic execution itself is unlikely to affect interoperability. By default, shared sequencers/super builders should build block level composability. 5. Infrastructure required for block level composability: shared sorter//super builder//proof aggregation layer */shared bridge contract * (*=optional) In most discussions about shared sequencers and shared settlement layers, the term commonly used to describe this level of interoperability is "synchronous composability". We have slightly modified this term to make it more descriptive. Updating the term to 'block level composability' means that cross rollup transaction packages can be combined between two rollups, which will be included and successfully executed in the next block. Synchronized composability may be confused with transaction level composability, which we will explore in the next section. Importantly, this requires an intermediary (shared sorting infrastructure) that can become the executor and creator of dependent transaction packages. At this level, we begin to see true composability between Rollups, rather than simply sending it to ourselves to participate in another dapp on Rollup. By adding a shared sequencer that can create transactions, we can now create cross currency packages that developers can utilize through programming. There are two situations to consider: block level composability, block level composability, and shared settlement layer. In both cases, we can create cross aggregation bundles for more complex activities. However, in the second case, through shared settlement, we can use native assets, which may have a better price impact on cross aggregation DEX activities. By leveraging block level composability, we have both the advantage of atomic execution and the additional ability to create dependent transaction packages. Let's take a look at our two illustrative examples. Same token transfer through xERC-20 (no shared settlement): User owns ERC-20 User creates tx through dapp: → stores ERC-20 in xERC-20 lockbox to receive xERC-20 wrapper version → destroys xERC-20 → sends a message to the shared sorting infrastructure indicating that cross rollup transfer has been initiated, with relevant data attached to facilitate the exchange Superbuilder picks up transactions and creates cross Rollup bundles → Tx 1: above wrapper and destruction transactions → Tx 2: casts xERC-20 Superbuilder on Rollup B and submits this cross rollup to the shared sorter → Since Superbuilder is running two complete nodes of connected rollups, they will simulate transactions to ensure the successful execution of the bundle. If any transaction is rolled back, the entire bundle will be rolled back. The shared sorter submits the block containing two transactions to the DA layer and the node xERC-20 that performs state changes to be cast to users on Rollup B. With the shared settlement layer, the process is further simplified because there is no need to first package ERC-20 as xERC-20 for exchange. Now let's take a look at cross Rollup limit orders, which involve using the initial (different) ERC-20 from Rollup A to purchase ERC-20 on Rollup B and sending 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 for additional external packaging of assets. The following is the transaction required in this case: Package and destroy ERC-20 on A, MintxERC-20 on B, and exchange initial xERC-20 with target ERC-20 on B. Package and destroy MintxERC-20 on target ERC-20 on B. The following is its possible workflow: Flow: The user initiates the first transaction: → Package 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 sent back or not). The super builder sees the transaction and creates a bundle: → Tx 1: The user creates the above transaction → Tx 2: Casting xERC-20 at the destination (the super builder must have casting permission) → Tx 3: Using data from tx 1 for limit orders → Tx 4: Packaging and destroying ERC-20 on B, assuming the limit order has been fully fulfilledAnd send messages on the source chain for casting → Tx 5: Cast the target xERC-20 from the exchange output on the source chain. Since the super builder creates blocks and sorts transactions, it can simulate each transaction and omit the bundle package when any transaction is revoked. For example, if a user is found unable to fully fulfill their limit order, the bundle will be omitted before executing the block. In the absence of a shared sorting infrastructure with a shared settlement layer, it is necessary to use externally packaged versions of Eth and xERC-20, which may lead to a deterioration in the market conditions of DEX as the liquidity pool of packaged assets becomes thinner. In this case, users may have to use looser restrictions, have a higher tolerance for slippage, and may receive suboptimal prices. If USDC is involved, there is an exception. A shared sorter without shared settlement may collaborate with Circle to obtain exclusive rights to cross rollup USDC contracts, in order to facilitate native USDC transfer and exchange across rollup. With a shared settlement layer, this external packaging is no longer necessary, and due to the deeper liquidity pool of native asset exchange, it may provide better prices, but the process is basically the same. Optimistically trusting the sequencer Rollup requires optimistically trusting the shared sequencer/super builder to create effective cross Rollup bundles. This is mainly because this cross Rollup bundle contains dependent transactions, and each Rollup cannot verify these transactions until the block is added to each Rollup's chain and aggregated to the settlement layer on L1. An example is the initial destruction and casting of Eth from source to destination. It is crucial that Eth is actually destroyed on the source chain before being minted 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 a state that was invalid before the block itself (for example, if the user did 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 indeed contain effective dependencies in the cross aggregation bundle. Afterwards, proof can be submitted to prove the validity of each transaction. However, when using packaged assets, this is not as important as they have no impact on the native liquidity stored in L1, but there must still be a fallback mechanism to offset the risk of errors in malicious sorters or code that allow transaction bundles to be executed together with restored dependent transactions. Impact on stakeholders: The user experience has undergone a large-scale upgrade, allowing for cross aggregation limit orders in a single block. Developers need to have cross Rollup awareness for cross Rollup activities and may need to utilize custom precompilation. Developers must think from the perspective of bundles, not just transactions, but super builders and custom Rollup infrastructure may eliminate complexity for most developers. MEV searchers have similar opportunities to use L1 strategy on cross aggregated bundles, but this depends on the implementation of PBS (proposer builder separation). Cross aggregation bundles are essentially considered as individual transactions, so MEVs can be found by preemptively trading or clamping these bundles, as long as they do not cause prices to exceed tolerable slippage amounts (as the entire bundle will recover and MEV attempts will fail). Rollups needs to choose to join the shared sorting infrastructure (including super builders) and allow access to Eth destruction/casting in the shared sorter with a shared settlement layer. MEV 6 can be internalized by selling block space to builders Infrastructure required for transaction level composability: 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 the call can be restored if the call fails to return. 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 settlement layer and super builder, this also requires VM level changes to all connected rollups. We have described a possible mechanism at a high level here. To our knowledge, this construction is attributed to the Espresso team. Firstly, users submit cross rollup transactions to all rollups whose states have been changed by the transaction or to super builders who can build blocks on all relevant rollups. The super builder simulates transactions and forms a list of input-output pairs, one for each relevant rollup, which specifies the necessary and expected cross rollup messages in the transaction. (Please note that super builders can only do this if they have secure sorting rights for all relevant rollups for a certain period of time). Then, the super builder sends the simulated blocks along with a list of expected input-output pairs for each cross rollup transaction to each proposer of the rollup. During execution, each rollup will execute its own state transition function normally, assuming that the input from the cross rollup transaction list is correct. During the settlement period, the input-output list can be cross compared and proven to be secure in the proof aggregation stage of the shared settlement layer. Specifically, if any expected input of a cross Rollup transaction does not match the output specified by another Rollup, the settlement process will reject the entire cross Rollup transaction. Although the new features that can be unlocked by transaction level composability are limited, apart from Lightning LoanBut the experience of developers creating cross Rollup applications can be greatly improved. Being able to create dapps that interact with all connected chains without considering cross Rollup bundles will make innovation much easier in multi Rollup environments. In addition, new use cases and behaviors may also emerge. There are many unresolved design issues in terms of transaction level composability. Firstly, it is necessary to carefully consider how developers choose to join or exit cross Rollup calls for their smart contracts. Allowing arbitrary composability without restrictions means we return to a single Rollup. We believe that the answer here is for developers to clearly indicate where cross Rollup composability is required in their contracts, such as marking certain entry points of the contract as callable cross Rollup through Solidity modifiers (such as "composable"). Impact on stakeholders: Users: Same meaning as block level composability and with other advanced features such as lightning loans → UX and chosen dapps use almost the same chain → Developers: Due to dapp developers being able to locally call contract cross aggregation and use the output of these calls (such as single aggregation calls), the developer experience is greatly improved → Superbuilder/Sequencer Infra still has to place transactions in aggregated blocks affected by cross aggregation calls, but does not have to build the same bundle like block level composability. MEV Searcher: Cross rollup bundles are now essentially equivalent to a single transaction on a chain, so MEV potential is high. Rollups: require virtual machine level changes, as well as the selection of shared sorters and shared settlement layers → before being able to verify the state through proof, it is necessary to trust the input and output of other rollups, which involves additional trust assumptions, but reduction mechanisms can alleviate the trust burden. Summary and ecosystem diagram: After understanding the technical details of each interoperability level defined here, we can summarize that shared settlement allows for cross rollup exchange without external asset packaging, And create a protocol based message delivery path sharing sorting/Superbuilders between all connected rollups, allowing for the next block execution to be provided on cross rollup bundles, ensuring block level composability and creating complex, fast, and interdependent cross rollup bundles, thereby achieving a composable ecosystem from near smart contract to smart contract level. It is possible to create transaction level composability across Rollup bundles without using external packaging assets by adding shared settlements. Although the newly opened use cases may target more complex users, it has the potential to greatly upgrade the cross aggregation development experience. Currently, there are many projects emerging aimed at creating these native interoperable ecosystems. The following is a high-level overview of the field: Ecosystem Map. Conclusion: There are still some unresolved issues regarding the technical details in the framework listed in this article. For example, building bundled packages for cross aggregated limit orders in a blockchain level composable ecosystem may require more detailed design to handle partial fulfillment and market order slippage tolerance. We offer a potential solution here, where cross aggregation limit order bundles can be restored 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 increasing sharing of ideas in the current application chain field. The application chain is a long tail L2, either generic or licensed, aimed at isolating specific related protocols on one L2. When we reach block level composability, we are likely to also start seeing significant appeal in the application chain environment due to the native composability between all connected networks. At present, it is still difficult to introduce liquidity into these application chains, but once larger chains are connected as entry points for interoperable environments, we are likely to see a walled garden ecosystem around shared infrastructure. Another important unresolved issue is how the design space around the super builder will be resolved. The development in this area is still in its early stages, and it is currently unclear how to create a complex builder network that can create cross aggregation packages in the most effective way. These cross aggregation packages will be included in the block in the best way possible, and the impact on aggregation revenue is an unresolved issue, with many teams exploring different strategies. Ultimately, the future may involve a combination of intra protocol and out of protocol bridging solutions that will work together to provide better interoperability processes for everyone. 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