Interoperability without trust between rollups: overview, construction, and challenges

Author: Marshall Vyletel Jr. Source: *1kx Translation: Shanolba, Golden Finance

Introduction

The number of rollups on the Ethereum network has experienced an explosive rise. According to data from L2Beat, there are currently 91 L2 and L3 rollups live, with 82 more coming soon. As a result, there is a lot 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, wrapped assets, and intent frameworks, each with their own set of issues.

1. Liquidity bridges are often the primary target of cryptocurrency hacker attacks (such as the $321 million Bug Bridge hacker attack)
2. External packaged assets are not welcome. Data shows that people prefer to hold assets in their native form whenever possible (for example, according to L2Beat data, the value of bridge assets is 220 billion US dollars, while the value of externally packaged assets is only 30 billion US dollars).
3. The intent framework relies on third parties that require some non-negligible trust and charge additional fees to facilitate cross-rollup activities (for example, due to non-standard official bridges, Degen chain users lost more than 80% of their tokens). A centralized intent framework also means lower competition, which may result in suboptimal pricing and performance.

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

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

This article mainly discusses Ethereum and its L2, and only follows the trustless interoperability. In this case, “trustless interoperability” refers to the protocol’s channels, which do not require third parties to facilitate transfers beyond the necessary infrastructure that most rollups already require.

Preparation

Definition

Fundamentally, interoperability without the need for trust requires some shared resources, which any two protocols wishing to interoperate must be able to access. In the case of Ethereum L1, all Smart Contracts exist in the same environment with shared Ethereum full state, so they will always have the highest level of interoperability. However, L2 only shares the settlement layer through separate bridge contracts, so interoperability is greatly limited.

The key shared infrastructure components that can drive us forward on the trustless interoperability ladder are shared sorters, super builders, and shared Settlement. The guarantees and new features opened up by these shared layers are relevant but essentially orthogonal.

1. Shared Sequencer/Super Builder: Mainly improve speed and user experience.
2. Shared Settlement: asset swap without the need for external packaging and protocol internal message delivery.

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

1. L1 asynchronous: → Manually transfer assets through the aggregation of L1 Settlement to achieve interoperability.
2. Atom includes: Ensure that all transactions across Rollup Bundles will be included in the next block of each Rollup involved in the Bundle, or none at all.
3. 共享Settlement： Multiple rollups are connected to L1 through the same bridge contract.
4. Atomic Execution: → Ensure that all transactions in the cross-Rollup bundle will be included in the next Block of each Rollup involved in the bundle and successfully executed, otherwise no transactions will be executed. Successful execution means that each transaction is executed without Rollback and reflected in the updated state of each Rollup in the bundle.
5. Block-level composability: → The next Block of the Cross Rollup Bundle ensures that it can include dependent transactions (tx B on Rollup B depends on the result of tx A on Rollup A)
6. Trading Level Combinability: → Interoperability at the smart contract level only requires one transaction to simultaneously cause state changes between multiple rollups (unbundled). Using any protocol on any rollup is logically equivalent to using different smart contracts on-chain. Importantly, this means that any state changes before a call can be reverted upon return.

To further understand each level, we will introduce the following key use cases to demonstrate the features of each level and its impact on users, developers, aggregators, and MEV searchers.

Example:

1. Transfer of the same Token Send to yourself: exchange Eth for Eth between two Rollups, or exchange ERC-20 for ERC-20.
2. Token purchase → Cross Rollup Limit Order: Use Eth/ERC-20 on Rollup A to buy different ERC-20 tokens on DEX on Rollup B and (optional) send back to Rollup A

Meaning:

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

1. User Experience What changes will happen to the user experience by achieving this level of interoperability?
2. Developer Experience By achieving this level of interoperability, how will the developer experience change?
3. MEV Potential If we achieve this level of interoperability, is it possible to have new MEV opportunities?
4. Impact of Rollup Does Rollup have to choose to join any new infrastructure to achieve this? What are the changes in the cost structure of Rollup? What potential benefits may Rollup bring to participating in this infrastructure?

Advanced Overview

Six Stages Toward Trustless Interoperability

1. L1 Asynchronous

Required Infrastructure:

Not applicable

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

In this case, the only spec-compliant way to execute any trustless cross-Rollup activity is to extract assets from the source Rollup via a spec-compliant bridge and manually deposit them into the target Rollup once available on L1.

For Optimistic Rollup, considering the safety window, the withdrawal latency is about 7 days. In ZK Rollup, the withdrawal latency is uncertain, but it may be between 15 minutes and a whole day, ZkSync is such a case.

In addition, it is also possible to use smart contracts for peer-to-peer atomic swaps, but this is a smaller use case and cannot be effectively scaled.

It is worth noting the current third-party solutions:

1. Liquidity Bridge
2. Intent Framework

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

Send to yourself:

1. Standard practice: → Withdraw assets from Rollup A → Manually deposit Rollup B
2. Third Party: → Liquidity Bridge / Solver Network

Cross-rolling limit order

1. Specification: → Withdraw assets from Rollup A → Manually deposit Rollup B → Execute Limit Order
   To return, the target ERC-20 must be externally wrapped
2. Third Party → Emerging solution space for cross-aggregate limit orders → There is an open design around the use intention to promote this.

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

2. Atomic Inclusion

Required Infrastructure

Shared Sequencer *

The atomic inclusion only guarantees that the cross-aggregated bundle will be included in the next block.

This requires a shared sorter, but in theory, if the sorters on two given rollups do not reach maximum throughput, it can be manually implemented (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 we cannot guarantee the successful execution of a set of transactions. In this case, the shared sorter can only guarantee that the transaction format is correct and will be included in the next Block, but it may not be successfully executed.

Without enforcement guarantees, it is not possible to programmatically take advantage of atomicity in any meaningful way without risking one of the transactions being rolled back. Therefore, we are essentially in the same situation as L1 Async interoperability.

Consider launching a simple cross-collateralized exchange with only atomic inclusion guarantees:

1. Cross-Rollup Exchange Bundling → Tx 1: Locking / Destroying Token on the source Rollup → Tx 2: Mint Token to the user Address on the target Rollup

We may have atomic inclusion guarantees, where two transactions are actually included in each subsequent block of a summary, but if the first transaction Rollbacks and the second transaction does not Rollback, the user will incorrectly allocate funds on-chain at the destination without locking or burning them on-chain at the source, and we will encounter a Double Spending problem.

Any interoperability solution, whether it’s a liquidity bridge, an intent framework, or an xERC-20 exchange, is susceptible to this risk and cannot mitigate it. Due to this risk, current solutions require the initiating transaction to have been successfully executed and included in the source on-chain Block before the relay can pass the message and execute the second transaction on the target on-chain.

Important reminder: Atomic swaps 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. Thanks to the existence of the Shared Bridge contract, all Liquidity deposited from L1 into the rollup ecosystem can move freely between all connected rollups. Prior to this, we could not exchange assets between rollups without going through formal channels, external wrapping of assets, or using third-party solutions.

Why build a shared bridge contract? To understand why a shared bridge contract can allow us to transfer assets across Rollups in a trustless manner, first consider what would happen if you could have Eth in Rollup A, destroy it, and then mint it natively in Rollup B without the need for a shared bridge contract on Layer1.

We see that each rollup will be out of sync with the bridge contract on the Mainnet. The bridge contract for rollup B still has 50 Eth, so users cannot withdraw their 1 Eth to L1.

To address this issue, we have established an external asset packaging protocol to aggregate and issue external versions of Tokens that represent the native versions elsewhere in the network.

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

It is indeed necessary to update at the L1 contract level to understand where Liquidity is and to allow users to withdraw from anywhere, but this is simple because all connected aggregations can read/write to the shared contract.

Using a shared settlement layer, for simple cases of sending to oneself, the process may look like the following.

Send to yourself:

1. User creates initial transaction: →Tx 1: Withdraw Eth on rollup A (and mint on rollup B) The trading is batched and submitted to the L1 contract It is aggregated into the transaction root, which groups all shared Settlement rollup.
2. Import this transaction root into Rollup B
3. The relay submits the transaction to the minter and submits the Merkle proof to rollup B.
4. Rollup B uses Merkle Proof and transaction root to verify the destruction of transactions
5. The user minted ETH on Rollup B.
6. Rollup B submits proof to L1

We can extend this process to any ERC-20 with contracts in all aggregations in the shared Settlement ecosystem.

We can think of the Shared Bridge contract as a message passing layer within the protocol that aggregates all connections, so in theory, this process can actually be extended to any arbitrary message passing standard.

This brings us closer to composability, but due to the need for aggregation proof and message passing only after reflecting state changes on L1, the latency is higher (although significantly lower than the L1 asynchronous case). In addition, any complex cross-Rollup activity (such as using DEX on Rollup B to initiate cross-Rollup limit orders from assets on Rollup A) remains a cumbersome process for users, as they still have to send to themselves and manually exchange assets on the target Rollup. In this case, atomic cross-Rollup bundling cannot be created.

Another important benefit of sharing Settlement is that there is less friction for Liquidity providers or resolvers who execute orders in multiple environments. Because their Liquidity across all connected Rollups is reflected in a single bridging contract, they do not need to wait for a complete withdrawal window to manage cross Rollup Liquidity.

Impact on Stakeholders:

1. User: Assets can now be transferred in their native form without the need for L1 withdrawal period.
2. Developers:
   The change is limited to Token issuance, and they can now use the messaging within the protocol to issue native versions of ERC-20 on all connected Rollups.
3. MEV Seeker: Due to this situation happening on multiple Blocks of each rollup, there is no new MEV potential
4. Rollups: Rollups must choose to use a shared bridge contract and may add pre-compilation to handle cross-rollup messages.

Important tip: Shared Settlement allows for non-externally wrapped asset transfers and arbitrary message passing in all aggregations of shared bridge contracts and proof aggregation layers, but there will still be an unavoidable latency (although much shorter than L1 Async) and it is not possible to create cross-aggregate atomic bundles.

4. Atomic Execution

Required Infrastructure:

Shared Sorter // Super Builder

Atomic execution allows us to ensure the successful execution of cross-volume bundling, but as we will see, the number of use cases for cross-volume bundling without dependent transactions is less than initially expected.

If any single transaction within a group of dependent transactions is revoked, all other transactions will become invalid and must also be revoked, just like the case of destroying and minting tokens across rollups. Whether minting tokens on the target rollup depends on whether they have been destroyed or locked on the source rollup, so we can say a set of destroy and mint transactions is a set of dependent transactions.

It is not possible to create this bundle without an intermediary (such as a super builder) capable of creating the target transaction.

Consider what conditions must be met to build a bundled package for cross-Rollup exchange without the participation of other parties outside of users. A bundled package must be created to lock/mint assets on the source Rollup and mint assets on the target Rollup, but we have encountered issues: 01928374656574839201

1. Contracts on the source rollup can only emit messages when locking/burning the original source assets, and they cannot call and create transactions on the target rollup. → This is the reason for the existence of the message protocol and Relay network. → The message can be used to construct what should be called on the target, but it actually cannot create the transaction itself.
2. Create a second transaction on the target rollup for minting: → Users cannot create this tx themselves because they do not have the minting rights for Token on rollup B → That is, the target chain needs proof that the Token has been burned/locked on the source chain, but this proof is only available after the initial transaction is executed, which would violate our requirement for atomicity. → In theory, any other entity that is able to Any party involved in creating the second transaction with minting rights can create a ‘mint’ transaction on the target on-chain at any time without first creating a ‘burn’ or lock on the source on-chain. This is a huge loophole.

We can see that even though we can ensure the execution of cross-summary bundles, we have encountered difficulties in how to first construct them to transfer valuable assets.

However, there are still some atomic execution use cases that do not require dependence on cross-rollup bundles. One of them is cross-rollup Arbitrage:

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

However, in order to first obtain atomic execution assurance, rollup must choose a shared sequencer and a super builder to run the complete Node of all connected rollups, so the step from atomic execution to Block-level composability is very small, and all shared sequencing solutions will achieve this. The only change needed is that the Block builder or other third parties must be able to create transactions on behalf of users to complete dependent cross-rollup bundles.

It 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 outweigh the difficulty of achieving this goal.

Impact on Stakeholders:

1. User: There may not be any changes, although third parties may offer solutions like intents, it is not clear how they will be implemented.
2. Developer: May not change
3. MEV Seeker: Considering atomic execution, cross rollup Arbitrage is more secure
4. Rollup： Rollup must choose to use a shared sequencer/superbuilder to submit blocks containing transactions from each Rollup that wishes to interoperate, which could change the revenue structure of the Rollup. It is currently unclear how it will change. The sorting market may increase the income of Rollup by allowing mature builders to purchase ToB space

Important note: Although cross-rollup bundling guarantees atomic execution, it is unclear how these bundles will be constructed without a super builder for the bundling portion, so atomic execution itself is unlikely to affect interoperability. By default, the shared sequencer/super builder should build block-level composability.

5. Composability at the Block Level

Required Infrastructure:

Shared Sorter // Super Builder // Proof Aggregation Layer* // Shared Bridge Contract*

(* = optional)

In much of the discussion 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 batches can be combined between two rollups, which will be included and successfully executed in the next Block. Synchronous composability may be confused with transaction-level composability, which we will discuss in the next section. Importantly, this requires an intermediary (shared ordering infrastructure) that can act as both an executor and creator dependent on transaction batches.

At this level, we are beginning to see the true composability between Rollups, rather than simply sending to oneself to participate in another Rollup’s dapp.

By adding a shared sequencer that can create transactions, we can now create cross-collateral packages, which 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 cross-collateralized bundles for more complex activities, but in the second case, by sharing Settlement, we can use native assets, for example, this may have a better price impact on cross-collateralized DEX activities.

With block-level composability, we not only have the advantage of atomic execution, but also the additional ability to create dependent transaction packages. Let’s take a look at our two illustrative examples.

Transfer the same Token via xERC-20 (without shared Settlement):

1. Users have ERC-20
2. User creates tx through dapp: → Deposit ERC-20 into xERC-20 lockbox to receive xERC-20 wrapped version. →Destroy xERC-20
   → Send a message to the shared ordering infrastructure indicating that cross-rollup transfer has been initiated and include relevant data to facilitate the exchange
3. Superbuilder picks up transactions and creates cross-rollup bundling. → Tx 1: The above packaging and destruction transactions → Tx 2: Mint xERC-20 on Rollup B
4. Superbuilder submits this cross-rollup to the shared sorter → As Superbuilder is running full Nodes for two connected rollups, they will be paper trading to ensure the bundled packages are executed successfully. If any transaction Rollback occurs, the entire bundled package will Rollback.
5. The shared sorter submits the Block containing two transactions to the DA layer and the Node for state changes execution
6. xERC-20 minted on Rollup B to users

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

Now let’s take a look at the Cross-Rollup Limit Order, which is to use the initial (different) ERC-20 in Rollup A to purchase ERC-20 on Rollup B, and send the generated ERC-20 back to Rollup A. In this case, we don’t assume that we have a shared settlement layer, although a similar process exists in the presence of a shared settlement layer. The only difference is that there is no need to externally wrap the assets.

The following are the transactions required in this case:

1. Package 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. Wrap and destroy the target ERC-20 on B.
5. A 上的Mint xERC-20

Here is its possible workflow:

Flow:

1. User initiates the first transaction:
   Pack and destroy xERC-20, and send a message to specify exchange parameters (target chain, DEX Address, ERC-20 to be exchanged, limit order price, boolean value for return)
2. Super Builders see the transaction and create a bundle: → Tx 1: User creates the above transaction → Tx 2: Mint xERC-20 at the destination (Super Builder must have minting permission) → Tx 3: Place a limit order using data from Tx 1. → Tx 4: Wrap and destroy ERC-20 on B, assuming the limit order has been fully executed, and send a message on the source chain to mint → Tx 5: Output the mint target xERC-20 from the exchange on the source chain

Because the super builder will create Block and sort transactions, it can simulate each transaction and omit the bundling when any transaction is revoked. For example, if it is found that the user cannot fully fulfill its limit order, the bundling will be omitted before executing the Block.

In the absence of a shared Settlement layer for shared ordering infrastructure, external wrapped versions of ETH and xERC-20 may need to be used, which could lead to deterioration of the DEX market conditions as the liquidity pools for wrapped assets thin out. In this scenario, users may have to tolerate looser restrictions, higher slippage tolerance, and may receive suboptimal prices. There is an exception when it comes to USDC. A shared sorter without a shared Settlement may collaborate with Circle to obtain exclusive access to the USDC contract across rollups, facilitating the transfer and exchange of native USDC across rollups.

With the shared settlement layer, this external packaging is no longer necessary, and because the liquidity pool of the native asset swap is deeper, it may provide better prices, but the process is basically the same.

Trust the sequencer optimistically

Rollup requires optimistic trust in the shared sequencer/super-builder to create an effective cross-Rollup bundle. This is mainly because the cross-Rollup bundle contains dependent transactions, which cannot be verified by individual Rollups until the block is added to the on-chain of each Rollup and aggregated to the settlement layer on L1. An example is the initial destruction and minting of Eth from the source to the destination. It is crucial that Eth must be actually destroyed on the source on-chain and then minted on the target on-chain, otherwise Double Spending may occur.

However, to execute this entire bundle in one Block, all transactions must exist in the Block, even if the transactions represent a state that is invalid before the Block itself (e.g., if the user does not have any Eth before the Block, there is Eth on-chain in the target exchange). Therefore, we must trust that the sequencer does include valid dependencies across aggregated bundles. Proofs can be submitted afterwards to demonstrate the validity of each transaction.

However, when using wrapped assets, this is less important because they do not affect the native Liquidity stored on L1, but there must still be a fallback mechanism to mitigate the risk of malicious sorters or errors in the code, which allow transaction bundles to be executed together with the restored dependent transactions.

Impact on Stakeholders:

1. User A large-scale upgrade has been made to the user experience, allowing cross-collateral limit orders within a single Block.
2. Developers
   It is necessary to have cross-Rollup awareness for cross-Rollup activities, and custom precompilation may be needed. Developers must think from the perspective of the Bundle, not just transactions, but the super builder and custom Rollup infrastructure may eliminate most of the complexity for developers.
3. MEV Searcher The opportunity for MEV searchers to use L1 strategies on cross-summary bundling is basically the same, but it depends on the implementation of PBS (Proposer-Builder Separation). → Cross-asset bundle is essentially treated as a single transaction, so MEV can be found by front-running or sandwiching these bundles, as long as they do not cause the price to exceed an acceptable Slippage amount (because then the entire bundle would revert and the MEV attempt would fail).
4. Rollups
   You need to choose to join the shared sorting infrastructure (including Super Builder), and allow access to Eth destruction/mint in the shared sorter under the shared settlement layer. → MEV can be internalized by selling Block space to miners

6. Composability at the Transaction Level

Required Infrastructure:

VM level change // Shared Settlement // Super Builder

Transaction-level composability refers to the same level of functionality shared by an EVM on-chain Smart Contract. In this case, a single transaction can simultaneously update the states of multiple rollups and ensure that any state changes before a failed call can be reverted. In practice, atomic transaction packages in a block-level composability environment can be completed in a single cross-rollup and cross-VM transaction. This requires VM-level changes to all connected rollups, in addition to shared settlement layers and superbuilders.

We describe at a high level a possible mechanism here. (To the best of our knowledge, this structure is attributed to the Espresso team). First, the super builder submits cross-rollup transactions to all rollups whose states are being traded or can build Blocks on all relevant rollups. The super builder paper trading and forming input-output pairs list, one for each relevant rollup, specifying the necessary and expected cross-rollup messages in the transaction. (Please note that the super builder can only do this if it has secure ordering rights for all relevant rollups for a period of time). Then, the super builder will send the simulated Block along with the expected input-output pairs list for each cross-rollup transaction to the proposers of each rollup. During execution, each rollup will execute its own state transition function normally, assuming that the inputs from the cross-rollup transaction list are correct. During the Settlement period, the input-output lists can be cross-compared and proven to be secure in the proof aggregation phase of the shared Settlement layer. Specifically, if any expected input from 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 unlocked by transaction-level composability are limited apart from Flash Loans, the experience for developers creating cross-Rollup applications can be greatly improved. Being able to create dapps that interact with all connected chains without having to consider cross-Rollup bundling will make innovation in multi-Rollup environments much easier. Additionally, new use cases and behaviors may emerge.

There are many unresolved design issues in terms of transaction-level composability. First, it is necessary to carefully consider how developers choose to join or exit their Smart Contract cross-Rollup calls. Allowing unrestricted composability means we return to a single Rollup. We believe the answer here is for developers to explicitly indicate where in their contracts cross-Rollup composability is needed, for example by marking certain entry points of the contract as callable cross-Rollup through Solidity modifiers (such as “composable”).

Impact on Stakeholders

1. User: Equivalent to blockchain composability and with other advanced features such as Flash Loans. → UX and the dapp selected to join use the same chain almost
2. Developers: Because dapp developers can locally invoke the cross-aggregation of contracts and use the outputs of these invocations (such as single-aggregate invocations), therefore Developers experience great Improvements→ Superbuilder/Sequencer infrastructure still needs to place transactions in blocks affected by cross-aggregate invocation, but not necessarily build the same bundles as block-level composability.
3. MEV Seeker: A cross-rollup bundle is now essentially equivalent to an on-chain single transaction, so the MEV potential is high.
4. Rollups: The changes at the Virtual Machine level are needed, as well as the selection of shared sorters and a shared Settlement layer. Before being able to verify the state through proof, it is necessary to trust the inputs and outputs of other rollups, which involves additional trust assumptions, but the reduction mechanism can alleviate the trust burden.

Summary and Ecosystem Diagram

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

1. Shared Settlement allows cross rollup exchange without the need for external wrapped assets, and creates an internal message passing path between all connected rollups.
2. Shared sorting/Superbuilders allows for providing the guarantee of executing the next block across bundled rollups.
3. Block-level composability allows for the creation of complex, fast, interdependent cross-rollup bundles, enabling a composable ecosystem at nearly the level of smart contracts to smart contracts. → By adding shared Settlement, these cross-Rollup bundles can be created without the need for external wrapped assets
4. Transaction-level composability is possible, and although newly opened use cases may target more sophisticated users, it has the potential to greatly upgrade cross-aggregation development experience.

Currently, there are many projects emerging aimed at creating these natively interoperable ecosystems. Here is a high-level overview of the field:

Ecosystem Map

Ecological System Map

Conclusion

There are still some unresolved issues regarding the technical details in the frameworks listed in this article. For example, in the block-level composable ecosystem, building bundled packages for cross-aggregated limit orders may require more detailed design to handle partial fulfillment and Slippage tolerance of market orders. We provide a potential solution here, where bundled cross-aggregated limit orders can be restored if the orders are not fully completed, but the design space is open.

In addition, it is worth mentioning that this is related to the increasingly rising idea of ​​sharing in the AppChain field. AppChain is a long-tail L2, either generic or permissioned, aimed at isolating specific related protocols on an L2. When we achieve block-level composability, we are likely to begin to see significant attractiveness of the AppChain environment due to the native composability between all connected networks.

Currently, it is still difficult to introduce Liquidity for these application chains, but once larger chains are connected as entry points to interoperable environments, we are likely to see walled garden ecosystems around shared infrastructure.

Another important unresolved issue is how the design space around the super builder will be addressed. This aspect is still in its early stages of development, and it is currently unclear how to create a complex builder network that can create cross-collateralized packages in the most effective way. The inclusion of these cross-collateralized packages in Block in the best possible way, as well as the impact on aggregated income, is a pending issue, and many teams are exploring different strategies.

Ultimately, there may be a combination of solutions involving bridging within and outside the protocol, working 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 a more seamless cross-rollup interoperability for end-users.