Interoperability Development: How is it Going?
Author: Nick Pai, Katie Chiou / Source: https://archetype.mirror.xyz/LskN487jd3aRva3_ypT3yGZJeu9OKri
Translation: HuoHuo / Plain Language Blockchain
1. Introduction
The positioning of new interoperability projects in the infrastructure stack is crucial for making wise investment decisions. The technological stack of blockchain infrastructure has undergone significant changes over the years, requiring corresponding adjustments to understand the framework of interoperability.
Through this article, we hope to reflect on the evolution of the blockchain interoperability stack, analyze its various components, and share our thoughts on the upcoming models.
Native Layer1
Native Layer1 (L1): In 2017, the blockchain landscape consisted of isolated chains that could only be connected to a certain extent through CEX.
"Alt L1": As Ethereum gained market share, it became a bet for other blockchains to have a native bridge to Ethereum without always relying on CEX. These connections further solidified Ethereum's dominant position over other chains, creating the narrative of "Alt L1".
1. "Alt" Layer 1
Centered around Layer 2 (L2): The next development is for new networks to not only connect to Ethereum but also use it as a data availability layer. These networks, such as Arbitrum and Optimism, provide enhanced user experience but lack transaction security as they use Ethereum as the settlement layer. Naturally, they are referred to as "Ethereum L2" or rollups.
2. Centered around Layer2
This brings us to today, where L2 has gained significant momentum, and Ethereum's roadmap is "rollup-centric," with connections between every L2, a significant improvement compared to the state of blockchain infrastructure five years ago.
Today, the design issues around blockchain interoperability typically revolve around the following factors:
1) L2 providing very fast and cheap UX
2) L2 and L3 (application chains) as the location for new user applications
3) More chains leveraging shared security and infrastructure
4) Focus on communication between L2 chains, not just between L1 and L2 chains
3. How will it develop in the future?
The increasing connections between blockchains have made it more ambiguous for those who want to better understand how everything works.
How can my token move from L2 to L2?
Who is protecting my data? Who implicitly do I trust to ensure the security of my data?
To answer these questions, we need to understand every layer of the stack.
4. Content to be introduced in this article:
1) L2s
Why L2 is fast and cheap and how secure they are
Relationship between L2 and Ethereum (L1)
Relationship between L2 and data availability (DA) layer
2) Sequencer
What is a sequencer
Shared sequencers
3) Fraud proof, validity proof, and authority proof (PoA)
4) Bridges
Types of bridges
Bridgers and sequencers
5) Intent
What is intent
Intent and bridges
6) CEX and DEX
Now let's delve deeper.
2. Main Text
1. Layer 2
Users interact with dApps, and they demand these dApps to be fast and cheap. That's why today's dApps are often deployed on L2s like Polygon, Arbitrum, and Optimism, rather than on Ethereum.
1) Why is L2 cheaper than L1?
L2 processes off-chain transactions and periodically publishes batches of final transactions to an upper layer of the chain to ensure the data has indeed been published and is available for verification (data availability). L2 can be so fast because they record off-chain user interactions on private servers, providing a "web2" experience. In the background, L2 publishes batches of these transactions to the data availability layer, providing additional transparency and security.
How do L2s currently publish and store transaction data/history?
Choosing a secure data availability layer is the most important security decision L2 makes. If L2 is an "Ethereum Rollup," it will publish its transaction data to Ethereum.
There are two reasons for choosing Ethereum. First, Ethereum is the "most immutable" layer. Once the transaction data is aggregated and published to Ethereum, the cost of reversing finality on Ethereum is very expensive. Therefore, L2 can publish its state to Ethereum and be very confident (after about 13 minutes of finalization period on Ethereum or 2 epochs of 32 slots, each slot taking 12 seconds) that their transactions will not be reverted. The second reason is the high availability of Ethereum data. Ethereum has a large number of nodes to replicate and verify transaction data, making it unlikely for the data to disappear or become completely unavailable.
However, the cost of using Ethereum to obtain data is well known. While Ethereum is generally the most secure data availability layer, it is not optimized for storing data only—it is a general-purpose computer. Before the implementation of EIP4844, there was no way to request block space only; you had to pay the same gas fee as sending regular transactions on Ethereum. Therefore, if L2 chooses to publish its state on Ethereum, it opts for the blue-chip option but also pays a premium for its security.
For L2s that want to reduce the fees paid to state governments, what are their options? That's entering the DA layer.
Data availability (DA) layers like Celestia are optimized to specifically provide data availability with lower demand for block space and cheaper block space itself.
Naturally, the downside is that newer DA layers have lower economic security at launch compared to Ethereum, considering the necessity and time required to bootstrap the network. Another drawback of pure DA layers like Celestia is that you cannot naturally compute data, adding complexity in arbitration or validation proofs. When sending transactions on L2, you should ask: to which DA layer does this L2 publish its state, do I trust it, and how can I access the data in the future?
Modular DA layer
2) Why do L2s need to pay to publish data?
Publishing state on an external DA layer eliminates the centralization vector of L2, as it allows permissionless independent verification of the state. In the case of Optimistic Rollup, data availability is needed to generate fraud proofs. For ZK rollups, data availability is needed to ensure audit resistance and liveness.
If L2 never publicly publishes its state on-chain, it will only reside in private servers. Users will be entirely at the mercy of the L2 operator, raising concerns about liveness (what if the centralized operator goes offline?).
If L2 publishes its state on a relatively insecure chain, users will also be subject to the dominance of that chain. For example, if L2 publishes its historical snapshot on Tron, Justin Sun will have the ability to alter the history of L2.
This is why most L2s choose to publish their state on highly secure and proven chains (such as Ethereum). Users want to know that they can control their own data and that their transactions will not be tampered with or reversed.
A key point worth reiterating: the security of L2 depends on its DA layer/L1 to which it publishes its state.
Aggregation without DA:
3) Does this mean that DA layers are competitive with Ethereum?
They are vying for a large amount of data. After EIP4844, these DA layers will directly compete with Ethereum's "Blob" market.
For other types of transactions, such as sending tokens or interacting with DeFi applications, Ethereum competes with other Turing-complete blockchains (such as Solana, BSC, and Avalanche) that do not publish their state to Ethereum.
2. Sequencer
1) What is a Sequencer?
The sequencer is the participant who actually publishes L2 state to the DA layer. They are responsible for determining the canonical order of transactions on L2 and publishing a snapshot of that history to the DA layer. Sequencers pay fees to the DA layer to publish data and earn income by collecting all fees paid by users sending transactions on L2. Sequencers can be a single whitelisted party or competitors in a decentralized market vying to publish the next set of L2 states. Typically, sequencers need to understand:
Declaration on the DA layer so that it can publish data to it/mint bridged assets (if the DA layer supports smart contracts)
The state on the L2 layer to order L2 transactions
Most dynamic assumptions assume that sequencers are also block producers (which is correct for today's production sequencers), but these roles can be decoupled based on the design/development of decentralized sequencers, shared sequencers, and PBS.
2) What is a shared sequencer?
In general, proposals for shared sequencers separate transaction ordering and execution; shared sequencers do not execute transactions. This design decision makes shared sequencers scalable—they are fast, have low requirements for sequencer nodes, as ordering is stateless, and decentralized sequencer sets become relatively easy to manage.
However, because these sequencers do not execute transactions, this imposes centralization of power on the block builders (the actual parties executing state transitions across domains). The more rollups connected to the shared sequencing layer, the higher the requirements for competitiveness for the block builders across domains. The higher the resource requirements, the greater the centralization risk at the block builder level. The design space around decentralized block building and the separation of proposers and block builders is vast, and for the sake of scope, this issue will not be explored in depth here.
Another issue: shared sequencers do not provide atomic conditional transaction execution across rollups.
For example, a common requirement is for a user to bridge a token from Optimism to Arbitrum and then exchange the token on Arbitrum. Ideally, the user wants these two operations to be executed in sequence or not at all. In the worst case, the user ends up with unswapped tokens on Arbitrum.
To enable this conditional execution of transactions between Rollup A and B, the shared sequencer needs to order A and B and publish the shared L2 state to the DA layer containing the two conditional transactions.
This is likely the next step in the development of shared sequencers: interdependent L2 states protected by "shared fraud proofs" or ZKP. To achieve this goal, changes must be made to the behavior of shared sequencers and system contracts to support the publication of multiple L2 states in a single L1 transaction.
Prediction: If shared sequencing becomes the dominant paradigm for single sequencing, the validity of states between L2s using shared sequencers will be interdependent.
Another potential issue with shared sequencers is that teams using the shared sequencer network may lose control over certain operational parameters and opportunities for value capture. For example, shared sequencers can extract MEV within the rollup itself that is valuable. Given that this will be a clear zero-sum competition in the shared sequencer market, shared sequencers are more likely to focus on extracting MEV between rollups, and in any case, individual sequencers will not have easy access to this MEV.
3. Fraud Proof, Validity Proof, and Authority Proof
We have established that L2 should publish its data to a transparent place, but how do we verify the data?
If the L2 sequencer's publication of data to L1 is considered valid, what prevents the L2 sequencer from publishing an incorrect snapshot of L2 history? Can't the sequencer pay a little extra ETH from the user's wallet?
1) Fraud Proof
In Optimistic Rollup, L2 states are published optimistically and are not considered final until a challenge window (e.g., a 7-day challenge window) has passed. During this challenge window, anyone can dispute the L2 state commitment if they believe it lacks the correct transaction history. To submit a dispute, a fraud proof must be published, which is used to resolve disputes in an interactive process.
The main advantage of fraud proofs is that they only need to be generated when there is a dispute.
2) Validity Proof
Validity proofs claim that the L2 state is valid and prove this at the time of publication. There is no dispute window; if the proof is verified by L1 contracts designed to verify such proofs, the L2 state is considered valid.
The main advantage of using validity proofs to prove the L2 state is that the L2 state published to L1 can be immediately considered final. This means that L1 contracts can immediately treat the L2 state as "final" and take action on it. This is why the withdrawal speed from L2 to L1 in ZK Rollups is very fast (about 24 hours), while the challenge window in Optimistic Rollups is 7 days.
3) Authority Proof (PoA)
The last method of verifying the L2 state is through an authority proof (PoA) mechanism. In this case, the sequencer publishing the L2 state essentially has the authority to declare, "This is valid because I am publishing it." This is how many rollups operate in practice today: sequencers run licensed full rollup nodes and verify the state through PoA. There is no challenge window, and no proof is required. Users simply have to trust that these sequencers will not modify the L2 state.
4) How do fraud and validity proofs actually work?
These proofs are very difficult to implement and very expensive to verify. They essentially require simulating a set of so-called L2 transactions and the execution of the initial state of the L2 VM. If the resulting state after those so-called transactions on the initial state differs from the result published to L1 by the sequencer, then the state is disputed.
These proofs must be verified on the same DA layer to which the L2 state is published, making the cost of verification high.
The main trade-offs between fraud and validity proofs:
A) Cost of verification: Validity proofs are typically much more expensive than fraud proofs.
B) Speed: Fraud proofs use a Dispute Time Delay (DTD) system (challenge window), which means that transactions will not be finalized on L1 until the window has passed, while validity proofs are verified immediately in a single transaction.
C) Implementation complexity: Both types of proof verification contracts are difficult to build. Validity proofs rely more on the succinctness of cryptographic tools so that they can simulate the L2 state in a single transaction. Fraud proofs are interactive, requiring fewer cryptographic tools but more off-chain infrastructure to support an interactive proof system.
D) L2 VM implementation complexity: L2 states verified through validity proofs typically require modifications to the EVM to make validity proof verification cheaper. L2 states verified through fraud proofs can more easily and accurately reflect the EVM.
E) Operating cost of the sequencer: Validity proofs require payment for each submission to L1, while fraud proofs only incur costs when a challenge is submitted. However, in the case of submitting a challenge, fraud proofs require payment for each interaction between the disputing parties (interactive), while each validity proof is generated in a single transaction (non-interactive).
F) Risk capital limit: If a fraudulent sequencer goes unchallenged, all L2 funds are at risk. If a sequencer fails to submit a valid validity proof, the L2 state will be effectively frozen, but the funds will not be lost.
G) Operating cost for validators: In an anti-fraud system, there should always be at least one honest validator monitoring the sequencer's submissions. In a validity proof system, assuming a validity proof is submitted, no external validators are required.
It is worth noting that the design of non-interactive fraud proofs is under development, although it is technically more challenging to implement.
4. Bridges
Before delving into specific examples, it is necessary to clarify the subtle differences in the way bridges are discussed in different contexts.
The Arbitrary Message Bridge (AMB) is a protocol that tracks arbitrary cross-chain states—arbitrary meaning from token transfers to data storage to anything else. Simply put, the message bridge essentially makes the state of one chain available on another chain. (This sounds very similar to a shared sequencer.)
A token bridge is an application of the message bridge that utilizes cross-chain states to transfer assets/capital between chains.
For example, if the Token Bridge sees transaction A, where 10 ETH is "burned" on Optimism, it would instruct the contract on Arbitrum to release 10 ETH to the user. If the burn of 10 ETH disappears from the transaction history, the Token Bridge may be liable for this loss. The Token Bridge is built on top of the message bridge because it needs to understand the state on the source and target chains and also needs to know when the transaction is completed on the source chain before it can act on the target chain.
The safest (though slowest) way to move assets between L2s is to extract them from the source L2 through a standard Token Bridge to L1 and then deposit them into the target L2 through the target L2's standard Token Bridge. Using the standard Token Bridge is usually a slow process because it depends on the exit from L2 to L1.
The "standard Token Bridge" is essentially a special service provided by the L2 sequencer. Depositing through the standard Token Bridge means locking the funds in the sequencer contract on L1 and requiring the L2 sequencer to mint an equivalent amount of funds on the L2 chain.
Withdrawing from L2 requires sending the funds to a specific contract on L2 for "burning" and waiting for the sequencer to publish proof of this burn to L1. Once this proof is confirmed, the sequencer's L1 contract can release the tokens to the user, just like any other L2 state published by the sequencer to L1.
The speed of using the standard Token Bridge is as slow as waiting for the full node to finalize the L2 state on L1, but it is also as "safe" as interacting with L2.
A faster way to transfer assets between L2s is to use a fast bridge. The fast bridge temporarily holds your funds in a non-sequencer contract and then places your funds on the target chain. This means that users temporarily trust the fast bridge not to modify their information or steal their funds.
How fast do bridges work:
The diagram above shows the flow of funds where users can quickly receive funds, the fees earned by the bridger for providing fast bridging services, and the ultimate risk borne by the bridger for the user's deposit.
First, the fast bridge subtracts the bridged amount from the required amount on the target chain and credits it to the user. In this example, this is 10 ETH minus the 0.1 ETH fee. The user leaves happily, having received the expected amount of funds so quickly.
Suppose this bridge prefers to hold assets on Ethereum. Therefore, without the user's knowledge, the bridging protocol extracts the user's deposit through the slower standard bridge on Ethereum. Once the standard bridge withdrawal is completed (e.g., 7 days later in the example above), the bridging protocol eventually generates a surplus of 0.1 ETH fee on Ethereum (10 ETH user deposit minus the credited 9.9 ETH to the user).
In exchange for compensation for providing this service, the bridge bears the ultimate risk of the user's deposit: if the user's deposit is recovered by the sequencer on the source chain at any time during the 7-day finalization period, the bridge will lose the funds. This is because the bridge has credited the user's funds on the target chain but will no longer receive the user's original deposit through the standard bridge.
Bridgers and Sequencers
How can users be sure that if they deposit 10 ETH on the source chain, they will receive 10 ETH (minus fees) on the target chain? This comes down to the security mechanisms of the respective bridges, which we will see look very similar to the security mechanisms of sequencers.
When the bridger credits the user on the target chain, users need a way to verify that the bridged funds have been received correctly. Ideally, the bridger can also provide recourse options in case of errors. One way the bridge provides this assurance is by allowing users to challenge the bridge during a challenge window. Similar to the fraud proof process, this allows users to have their security in their own hands and provide fraud evidence in case they did not receive the funds as expected. This is why it is crucial for the bridge to publish its transaction history to an immutable DA layer, providing transparency to users and assuring them that if they do challenge the bridge, the bridge cannot alter its history and must rectify any errors.
So, it is now clear that both fast bridges and sequencers require a DA layer to make users believe they are handling transactions honestly.
The security of the bridge depends on the DA layer to which it publishes its state and its dispute mechanism.
These fast bridges can provide users with economic atomicity without requiring technical atomicity. If users can express their preference to execute a transaction on one rollup and condition it on another transaction, and are willing to make the payment only if both conditions are met, fast bridges provide users with the property of technical atomicity by offering these economic incentives, outsourcing their execution to specialized institutions in the absence of certain actual communication or shared sequencing layers between different rollups.
Bridges can also provide security assurances to users through the publication of accompanying messages to the target chain and validity proofs. These types of bridges are called ZK bridges. The target chain needs to deploy a contract that can simulate the consensus of the source chain and can verify if the events declared on the source chain have occurred. Validity proofs are used as input to this verification contract to prove to the contract that the message sent to the target chain is an accurate representation of the request sent on the source chain.
Of course, if the bridge does not want to transparently and immutably publish data anywhere, it can also use PoA.
5. Intent
Intent is a set of preferences that users want to fulfill, including the target chains on which they want to fulfill these preferences.
The intent market provides a standardized history of intent stored across one or multiple chains. The intent market allows users to express their preferences, relayers to fulfill these preferences, and provides verification for fulfilling these preferences. If users believe that relayers have not correctly implemented their intent, the intent market should provide a way for users to dispute or challenge the relayers.
This sounds very much like a bridge.
Intent vs. Bridges
Intent is innovative because it opens up design space for different and more flexible mechanisms/languages for expressing and executing transactions.
The intent market is not necessarily cross-chain, but it is ready for cross-chain because it has already defined a new paradigm and language for expressing preferences and storing standardized intent history.
Therefore, cross-chain intent markets can be considered a more specific form of general message bridging.
The Archetype team outlined specific examples of intent systems (SUAVE, Anoma) in a previous article.
6. CEX/DEX
We began this article by reviewing how CEX became the primary hub for crypto assets in the crypto era millions of years ago. Given all the evolutions we have just outlined, where do CEX/DEX stand in today's framework?
The essential function of CEX is similar to dApps and Token bridges, as you can use them as a way to transfer tokens from one network to another. You can almost think of CEX as an authority proof bridge. If a user's funds are stolen, the trading platform can hardly provide recourse for the user. The main avenue is to legitimately challenge the CEX. GLHF. DEXs existing on a single chain are dApps. Cross-chain DEXs are like Token bridges plus dApps.
Three, Conclusion
Let's review the complete diagram of the model we have built:
The blockchain interoperability stack has undergone multiple iterations over the past few years, leaving valuable insights for those closely following the field. Regardless of the use of whichever trendy buzzword (sequencers, bridges, and cross-chain intent markets), interoperability infrastructure starts from the same primary functional principles:
1) Order transactions in a standardized manner (whether single-chain or cross-chain)
2) Publish data to a transparent and immutable DA layer
3) Provide data proof/validation mechanisms
Keeping these principles in mind, we can ask better questions and better assess where value will be generated in the future interoperability stack.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
