Author: YBB Capital Researcher Zeke

TLDR

• Agglayer is the core component of Polygon 2.0, unifying decentralized blockchains through aggregation and ensuring atomic cross-chain transactions. Its goal is to provide a seamless user experience at the single-chain level, addressing the liquidity and state fragmentation issues in the existing blockchain ecosystem.

• Agglayer utilizes a novel verification mechanism called pessimistic proof, which assumes that all access chains are insecure, ultimately using zero-knowledge proofs to ensure the correctness of cross-chain operations.

• Agglayer is more concise and efficient, and its ultimate form will achieve a more ideal chain abstraction, more in line with the definition of the next generation of Web3.

I. Derivation of Agglayer from the Modular Era

1.1 Introduction to Agglayer

Agglayer is one of the core components of Polygon 2.0. The "Agg" in the protocol name is an abbreviation of the English word "aggregation," and the full Chinese name is "聚合层" (Aggregation Layer). The essential role of this protocol is essentially no different from other whole-chain interoperability protocols such as Layerzero and Wormhole, which aim to connect fragmented blockchain worlds. However, in terms of construction ideas, there are indeed some differences. In simple terms, traditional whole-chain interoperability protocols are more like engineering companies building bridges everywhere, by designing and building bridges for different chains or protocols (the adaptation of heterogeneous chains is more difficult) to achieve interconnection. Agglayer, on the other hand, is just as its name suggests, more like a "local area network" composed of a switch, where connecting chains only requires inserting "network cables" (ZK proof) to access the "local area network" and exchange data. Compared to building bridges everywhere, it is faster, easier to use, and has better interoperability.

1.2 Shared Validity Sequencing

The idea of Agglayer is largely attributed to Umbra Research's design of Shared Validity Sequencing, which aims to achieve atomic cross-chain interoperability between multiple Optimistic Rollups. Through shared sequencing, the entire system can uniformly handle transaction sequencing and state root publication for multiple Rollups, ensuring atomicity and conditional execution.

The specific implementation logic requires three components:

1. Shared sequencer for cross-chain operations: receives and processes cross-chain transaction requests;

2. Block construction algorithm: the shared sequencer is responsible for constructing blocks containing cross-chain operations, ensuring the atomicity of these operations;

3. Shared fraud proof: shares fraud proof mechanism between relevant Rollups to enforce cross-chain operations.

The figure shows the working process of the MintBurnSystemContract contract when sharing a sequencer.

Since the current Rollups already have the functionality to bidirectionally pass messages between Layer1 and Layer2, as well as other special precompilations, as shown in the figure, Umbra here only added a concise cross-chain system composed of a MintBurnSystemContract contract (Burn and Mint) to complement the three components.

Workflow

1. Burn operation on Chain A: can be called by any contract or external account, and is recorded in the burnTree upon success;

2. Mint operation on Chain B: recorded in the mintTree by the sequencer upon successful execution.

Invariants and Consistency

Consistency of Merkle roots: the Merkle root of the burnTree on Chain A and the Merkle root of the mintTree on Chain B must be equal, ensuring the consistency and atomicity of cross-chain operations.

In this design, Rollup A and B share a sequencer. This shared sequencer is responsible for publishing transaction batches and state root declarations for both Rollups to Ethereum. The shared sequencer can be a centralized sequencer, like most Layer2 Rollup sequencers at present, or a decentralized sequencer like Metis. The key point of the entire system is that the shared sequencer must publish transaction batches and state root declarations for both Rollups to L1 in the same transaction.

The shared sequencer receives transactions and constructs blocks for A and B. For each transaction on A, the sequencer executes the transaction and checks if it interacts with the MintBurnSystemContract. If the transaction is successfully executed and interacts with the burn function, the shared sequencer attempts to execute the corresponding mint transaction on B. If the mint transaction is successful, the shared sequencer includes the burn transaction on A and the mint transaction on B; if the mint transaction fails, the shared sequencer excludes these two transactions.

In simple terms, this system is a simple extension of the existing block construction algorithm. The sequencer executes transactions and inserts condition-triggered transactions from one Rollup to another, and when fraud proof verification is performed on the main chain, it only needs to ensure that the burning on Chain A and the minting on Chain B are correct (i.e., the consistency of the Merkle roots mentioned earlier). In this scenario, multiple Rollups become similar to a single chain. Compared to a single Rollup, this design provides better sharding support, application sovereignty, and interoperability. However, the downside is that the burden on node verification and sequencers is greater, and the probability of adopting this solution is still low from various perspectives such as profit distribution and Rollup autonomy.

1.3 Core Components of Agglayer

While incorporating the above solution, Agglayer has made more efficient improvements and introduced two key components: Unified Bridge and Pessimistic Proof.

Unified Bridge: The workflow of the unified bridge is to collect and summarize the states of all access chains to the aggregation layer, and then generate a unified proof to Ethereum. In this process, there are three stages of states: pre-confirmation (allows faster interaction under temporary state assumptions), confirmation (verifies the validity of the submitted proof), and final confirmation. The proof can ultimately verify the validity of transactions on all access chains.

Pessimistic Proof: Introducing multiple Rollups into a multi-chain environment will create two main problems: 1. The introduction of different validators and consensus mechanisms will complicate security; 2. Receipts for Optimistic Rollups will take 7 days. To address these two issues, Polygon has introduced a novel zero-knowledge proof method, namely pessimistic proof.

The idea of pessimistic proof is to assume that all blockchains connected to AggLayer may exhibit malicious behavior and make worst-case assumptions for all cross-chain operations. Then, AggLayer will use zero-knowledge proofs to verify the correctness of these operations, ensuring that even in the presence of malicious behavior, the integrity of cross-chain operations cannot be compromised.

1.4 Features

Under this solution, various features can be achieved:

• Native token. By using the unified bridge, the assets within the aggregation layer are all native assets, without any wrapped tokens, and there is no need for a third-party trust source for cross-chain transactions, everything is seamless;

• Unified liquidity. The TVL of all access chains is shared, also known as a shared liquidity pool;

• Sovereignty. Compared to the way Optimistic Rollup in the previous text achieves interoperability through a shared sequencer, Agglayer has better sovereignty. AggLayer will be compatible with shared sequencers and third-party DA solutions. Connecting chains can even use their native tokens as gas;

• Faster. Unlike the previous Optimistic Rollup solution, Agglayer does not require a 7-day wait for cross-chain transactions;

• Security. Pessimistic proof only accepts correct behavior and also ensures that no chain can withdraw more than the amount deposited, thereby ensuring the security of the shared asset pool in the aggregation layer;

• Low cost. The more chains connected to the aggregation layer, the lower the proof fees paid to Ethereum, as this is shared. Agglayer does not charge additional protocol fees.

II. Cross-Chain Solutions

2.1 Why is Cross-Chain so Difficult?

As mentioned earlier, Agglayer's purpose is basically the same as that of whole-chain protocols, so which one is better? Before making a comparison, we may need to understand two questions: 1. Why is cross-chain difficult, 2. What are the common cross-chain solutions?

Similar to the most famous blockchain trilemma, cross-chain protocols also face the interoperability trilemma. Due to the limitation of decentralization, blockchain is essentially a replicated state machine that cannot receive external information. Although the existence of AMM and oracles fills the missing pieces of DeFi, for cross-chain protocols, this problem is multiplied many times over. In a sense, we may never be able to withdraw any real tokens from the original chain, hence the existence of various wrapped tokens such as xxBTC and xxETH. However, the logic of this wrapped token solution is very dangerous and centralized, as you need to lock the real BTC and ETH in the original chain addresses of the cross-chain bridge contract, and the entire cross-chain design may also face various problems such as asset incompatibility, protocol incompatibility due to different virtual machines, trust issues, double spending, and latency. To be efficient and cost-effective, most cross-chain solutions actually use a multi-signature wallet approach. So even today, you often see information about xx cross-chain bridges collapsing. Now let's take a closer look at this problem from a lower level. According to Arjun Bhuptani, the founder of Connext, cross-chain protocols can only optimize two out of the following three key attributes:

1. Trustlessness: Does not rely on any centralized trust entity, providing the same level of security as the underlying blockchain. Users and participants can ensure the security and correct execution of transactions without trusting any intermediaries or third parties;

2. Extensibility: The protocol can easily adapt to any blockchain platform or network, without being restricted by specific technical architectures or rules. This allows interoperability solutions to support a wide range of blockchain ecosystems, not just a few specific networks;

3. Generalizability: The protocol can handle any type of cross-domain data or asset transfer, not limited to specific transaction types or assets. This means that different blockchains can exchange various types of information and value through this bridge, including but not limited to cryptocurrencies, smart contract calls, and other arbitrary data.

Early cross-chain bridges were generally classified according to Vitalik and others, who divided cross-chain technologies into three categories: hash time lock, witness verification, and relay verification (light client verification). However, according to Arjun Bhuptani, cross-chain solutions can also be divided into native verification (trustlessness + extensibility), external verification (extensibility + generalizability), and native verification (trustlessness + generalizability). These verification methods are based on different trust models and technical implementations to meet different security and interoperability requirements.

Natively Verified:

Bridges using native verification rely on the consensus mechanisms of the source and target chains to directly verify the validity of transactions. This method does not require an additional verification layer or intermediary. For example, some bridges may use smart contracts to directly create verification logic between two blockchains, allowing these two chains to confirm transactions through their own consensus mechanisms. The advantage of this method is increased security, as it directly relies on the inherent security mechanisms of the participating chains. However, this method may be more complex in technical implementation and not all blockchains support direct native verification.

Externally Verified:

Bridges using external verification use third-party validators or validator clusters to confirm the validity of transactions. These validators may be independent nodes, consortium members, or some other form of participants, operating outside the source and target chains. This method usually involves cross-chain message passing and verification logic executed by external entities, rather than directly processed by the participating blockchains themselves. External verification allows for broader interoperability and flexibility, as it is not limited by specific chains, but it also introduces additional trust layers and potential security risks. (Although there is a great risk of centralization, external verification is the most mainstream cross-chain method, as it is flexible, efficient, and cost-effective.)

Locally Verified:

Locally verified refers to the target chain verifying the state of the source chain in cross-chain interactions to confirm transactions and execute subsequent transactions locally. The usual practice is to run a light client on the source chain in the virtual machine of the target chain, or run them in parallel. Native verification requires an honest minority or synchronous assumption, with at least one honest relayer in the committee (i.e., an honest minority), or if the committee cannot function properly, users must transmit transactions themselves (i.e., a synchronous assumption). Native verification is the most trust-minimized form of cross-chain communication, but it is also costly, less flexible in development, and more suitable for blockchains with a high degree of state machine similarity, such as between Ethereum and L2 networks, or blockchains developed based on the Cosmos SDK.

Current Cross-Chain Solutions "1"

Compromises in different aspects have led to various types of cross-chain solutions, in addition to verification methods. Current cross-chain solutions can also be divided into multiple categories, each taking a unique approach to asset exchange, transfer, and contract calls.

• Token Exchange: Allows users to trade a certain asset on one blockchain and receive an equivalent asset on another chain. By utilizing atomic swaps and cross-chain automated market makers (AMMs), liquidity pools can be created on different chains to facilitate the exchange of different assets.

• Asset Bridge: This method involves locking or destroying assets through smart contracts on the source chain, and unlocking or creating new assets through corresponding smart contracts on the target chain. This technology can be further divided into three types based on how assets are handled:

• Lock/Mint Mode: In this mode, assets on the source chain are locked, and equivalent "bridged assets" are minted on the target chain. When reversing the operation, bridged assets on the target chain are destroyed to unlock the original assets on the source chain;

• Burn/Mint Mode: In this mode, assets on the source chain are burned, and an equal amount of the same asset is minted on the target chain;

• Lock/Unlock Mode: This method involves locking assets on the source chain and then unlocking equivalent assets in the liquidity pool on the target chain. These types of asset bridges often attract liquidity by providing incentives such as revenue sharing.

• Native Payments: Allows applications on the source chain to trigger payment operations using native assets on the target chain, and can also trigger cross-chain payments based on data from one chain on another chain. This method is mainly used for settlement and can be based on blockchain data or external events.

• Smart Contract Interoperability: Allows smart contracts on the source chain to call smart contract functions on the target chain based on local data, enabling complex cross-chain applications, including asset exchanges and bridge operations.

• Programmable Bridge: This is an advanced interoperability solution that combines asset bridging and message transmission functionality. When assets are transferred from the source chain to the target chain, contract calls on the target chain can be triggered immediately, enabling various cross-chain functions such as staking, asset exchange, or storing assets in smart contracts on the target chain.

2.2 Agglayer's Future Advantages

Here we compare Agglayer with the current whole-chain protocol, using LayerZero, the most influential whole-chain protocol, as an example. The protocol adopts an improved version of external verification, where LayerZero transforms the trust source for verification into two independent entities - oracles and relayers, to address the shortcomings of external verification in the most minimalist way. In terms of cross-chain solutions, it belongs to the programmable bridge solution that can implement multiple operations. Logically, it seems to elegantly solve the so-called impossible triangle. From a grand narrative perspective, LayerZero has the opportunity to become the cross-chain hub of the entire Web3, and it aligns well with the experience fragmentation and liquidity fragmentation issues generated by the modular era and the reason why top VCs are crazy about betting on such protocols.

But what is the real situation? Let's not discuss the various tricky operations of LayerZero regarding airdrops for now. From a development perspective, it is actually very difficult for such protocols to achieve the ideal situation of connecting the entire Web3, and the issue of decentralization is questionable. In the early V1 version, LayerZero's use of oracles actually had the potential for being compromised and theoretically allowed for malicious behavior by oracles (on this point, Wormhole uses industry institutions as guardian nodes, but is often criticized for this), and it wasn't until the birth of the decentralized verification network (DVN) in the V2 version that the criticisms on social media were quelled, but this was also based on a large amount of B-side resources.

On the other hand, the development of whole-chain protocols also involves the protocols, data formats, and operational logic of heterogeneous chains, as well as the issue of calling different smart contracts. To truly achieve interoperability in Web3, it not only requires its own efforts, but may also require collaboration from various projects. If you have used the early version of LayerZero, you should have no trouble noticing that it basically only supports cross-chain with EVM-based public chains and has limited support for projects in the entire ecosystem. This point also applies to Agglayer, but in terms of interoperability, Agglayer supports ultra-low latency and asynchronous interoperability, which is more like the internet we use in our daily lives compared to whole-chain protocols.

In summary, Agglayer aggregates in a way similar to single-chain usage, overall it is more concise, efficient, and in line with the current modular trend. However, there is no absolute superiority or inferiority between the two at present. Whole-chain protocols still have the advantage of the broadest liquidity, a stronger ecosystem, and more mature development. The advantage of Agglayer lies in the true aggregation of the antagonistic Layer1 and Layer2, breaking the zero-sum game of liquidity and users in the era of chain explosion, allowing low-latency interaction between multiple chains, and inherently providing chain abstraction. The shared liquidity pool does not require wrapped tokens, which is a great opportunity for long-tail chains and application chains. Therefore, in the long run, Agglayer is currently the most promising cross-chain solution, and there are similar projects in the development stage, such as Polkadot's "Join-Accumulate Machine", and there will certainly be more similar solutions in the future. The history of Web3 has transitioned from a single piece to modular, and the next step will be towards aggregation.

III. Ecosystem Connected by Agglayer

As it is still in the early stages, Agglayer does not have many connected chains. Here, we mainly mention three projects:

3.1 X Layer

X Layer is an Ethereum Layer2 project based on the Polygon CDK, connecting the OOE and Ethereum communities, allowing anyone to participate in a truly global on-chain ecosystem. As a leading exchange chain, after entering Agglayer, it will bring extensive liquidity to projects within the aggregation layer. And the OKX Web3 wallet, as an access layer for ordinary users, may also provide better support for Agglayer.

3.2 Union

Union is a zero-knowledge infrastructure layer built on Cosmos, used for general message passing, asset transfer, NFT, and DeFi. It is based on consensus verification and does not rely on trusted third parties, oracles, multi-signatures, or MPC. As an access chain, after entering the aggregation layer, it achieves deep connection between EVM and Cosmos, as it only needs to act as an IBC gateway to connect Union and then connect to IBC, recombining two modular ecosystems that were previously separated from each other.

3.3 Astar

Astar Network is a network for Japanese and global enterprise, entertainment, and gaming projects, dedicated to driving "Web3". It provides customizable blockchain solutions using cross-virtual machines supported by Polygon and Polkadot. As the first fully integrated chain of Agglayer, it will directly access a shared liquidity pool of billions of dollars and achieve real user growth.

References

1. Understanding Blockchain Interoperability in One Article: https://blog.chain.link/blockchain-interoperability-zh/

2. AggLayer: Why Polygon’s Scalability Solution is a Game Changer in 2024 & Beyond?: https://www.antiersolutions.com/agglayer-why-polygons-scalability-solution-is-a-game-changer-in-2024-beyond/

3. The Aggregation Age is Coming: https://polygon.technology/agglayer

4. Shared Validity Sequencing: https://www.umbraresearch.xyz/writings/shared-validity-sequencing

5. Union: https://www.rootdata.com/zh/Projects/detail/Union?k=MTAxMjY%3D

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。