From Modularity to Aggregation: Exploring Polygon 2.0's Agglayer Core

Author: YBB Capital Researcher Zeke

TLDR

• Agglayer is the core component of Polygon 2.0, unifying decentralized blockchains by aggregating and ensuring atomic cross-chain transactions. Its goal is to provide a seamless user experience at the single-chain level and solve the liquidity and state dispersion problems of the existing blockchain ecosystem.

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

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

1. Agglayer is derived from the modular era

1.1 Introduction to Agglayer

Agglayer is one of the core components of Polygon 2.0. The Agg in its protocol name is the English word aggregation. The abbreviation, the full Chinese name is the aggregation layer. The role of this protocol is essentially the same as that of full-chain interoperability protocols such as Layerzero and Wormhole. Its purpose is to connect the fragmented blockchain world. But there are some differences between the two in terms of construction ideas. In layman’s terms, traditional full-chain interoperability protocols are more like engineering companies that build bridges everywhere, by designing and building bridges for different chains or protocols ( Among them, the adaptation of heterogeneous chains is more difficult) to achieve interconnection. Agglayer, as its name suggests, is more similar to a "local area network" composed of a switch. The connection chain only needs to plug in a "network cable" (ZK proof) to access the "local area network" and exchange data. Faster, easier to use, and more interoperable than crossing bridges everywhere.

1.2 Shared Validity Sequencing

Agglayer’s idea is largely due to Umbra Research’s design of Shared Validity Sequencing (shared validity sorting), which aims to achieve atomic spanning between multiple Optimistic Rollups Chain interoperability. By sharing the sequencer, the entire system can uniformly handle the transaction ordering and state root publishing of multiple Rollups, ensuring atomicity and conditional execution.

The specific implementation logic requires three components:

1. Shared sequencer that accepts cross-chain operations: Receives and processes cross-chain transaction requests;
   
   

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

3. Shared Fraud Proof: Sharing a fraud proof mechanism between related Rollups to enforce cross-chain operations.

This picture shows the working process of the MintBurnSystemContract contract when sharing a sequencer

Since the current Rollup basically has the function of transmitting messages in both directions between Layer1 and Layer2, and Other special precompilations. So as shown in the picture above, Umbra only adds a simple cross-chain system composed of MintBurnSystemContract contracts (Burn and Mint) to complete the three components.

Workflow

1.burn operation on chain A: Any contract or external account can call it, and it will be recorded to burnTree after success;

2.On chain B The mint operation : The sorter logs to the mintTree after successful execution.

Invariance and consistency

Merkle root consistency: The Merkle roots of burnTree on chain A and mintTree on chain B must be equal, so that the consistency and atomicity of cross-chain operations can be guaranteed.

In this design, Rollup A and B share a sequencer. This shared sequencer is responsible for publishing the transaction batches and claim state roots of both Rollups to Ethereum. The shared sorter can be a centralized sorter, like most current Layer 2 Rollup sorters, or a decentralized sorter like Metis. The key point in the overall system is that the shared sequencer must publish the transaction batch and claim state root of both rollups to L1 in the same transaction.

The shared sequencer receives transactions and builds blocks for A and B. For each transaction on A, the sequencer executes the transaction and checks whether it interacts with the MintBurnSystemContract. If the transaction executes successfully and interacts with the burn function, the shared sequencer attempts to execute the corresponding mint transaction on B. If the mint transaction succeeds, the shared sequencer includes the burn transaction on A and the mint transaction on B; if the mint transaction fails, the shared sequencer excludes both transactions.

Simply put, this system is a simple extension of the existing block building algorithm. The sequencer executes transactions and inserts condition-triggered transactions from one Rollup to another. When the main chain performs fraud proof verification, it only needs to ensure that the burning of chain A and the casting of chain B are correct (that is, the above Merkle root consistency). In this case, multiple Rollups become similar to a chain. Compared with single-chip Rollups, this design provides better sharding support, application sovereignty, and interoperability. But the opposite problem is that the burden on node verification and ordering is greater, and the probability of this solution being adopted is still very low from various perspectives such as profit distribution and Rollups autonomy.

1.3 Agglayer’s core components

While absorbing the above solutions, Agglayer has made more efficient improvements and introduced two key components: unified bridge and pessimistic proof.

Unified Bridge: The workflow of Unified Bridge is to collect and summarize the status of all access chains to the aggregation layer, and the aggregation layer regenerates a unified proof to Ethereum. In this process, there are three stages of status: Pre-confirmation (pre-confirmation allows faster interactions under temporary state assumptions), confirmation (confirmation verifies the validity of the submitted proof) and finalization, and finally the proof verifies the validity of all transactions connected to the chain.

Pessimistic proof: Rollups connecting to a multi-chain environment will cause two main problems: 1. The introduction of different validators and consensus mechanisms will lead to complex security; 2. The collection of Optimistic Rollups Payment takes 7 days. In order to solve these two problems, Polygon introduces a novel zero-knowledge proof method, namely pessimistic proof.

The idea of ​​​​the pessimistic proof is to assume that all blockchains connected to AggLayer may have malicious behavior and make worst-case assumptions for all cross-chain operations. AggLayer then uses zero-knowledge proofs to verify the correctness of these operations, ensuring that even if there is malicious behavior, the integrity of cross-chain operations cannot be compromised.

1.4 Features

Under this solution, the following features can be achieved:

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

• Unified Liquidity . The TVL of all access chains is shared, which can also be called a shared liquidity pool;

• Sovereignty. Compared to the way Optimistic Rollup above achieves interoperability through shared sequencers, Agglayer has better sovereignty and AggLayer will be compatible with shared sequencers and third-party DA solutions. Connected chains can even use their native token as Gas;

• faster. It is still a different solution from the Optimistic Rollup above. Agglayer does not need to wait for 7 days for cross-chain;

• Safety. Pessimistic proof only accepts correct actions, on the other hand it also ensures that no chain can withdraw more than the amount deposited, thus ensuring the security of the shared asset pool at the aggregation layer;

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

2. Cross-chain solution

2.1 Why is cross-chain so difficult?

As mentioned above, the purposes of Agglayer and the full-chain protocol are basically the same, so which one is better and worse? Before comparison, we may need to understand two questions: 1. Why is cross-chain difficult, and 2. What are the common cross-chain solutions.

Just like the most famous public chain triangle problem, cross-chain protocols also have interoperability trilemma. Due to the limitation of the major premise of decentralization, the blockchain is essentially a machine that cannot receive external information. Replication state machine for information. Although the existence of AMM and oracles makes up for the missing puzzle pieces of DeFi, for cross-chain protocols, this problem is dozens of times more complicated. From a certain perspective, we can never even take out any real tokens from the original chain. , so there are various packaging tokens such as xxBTC and xxETH. However, the logic of this packaged token scheme is very dangerous and centralized, because you need to lock the real BTC and ETH in the original chain address of the cross-chain bridge contract, and the entire cross-chain design may also face asset incompatibility. The same and different virtual machines lead to protocol incompatibility, trust issues, double-spend issues, latency issues, and other issues. In order to be efficient and reduce expenses, most cross-chain solutions actually use multi-signature wallet solutions. So even today, you can often see information about thunderstorms on the xx cross-chain bridge. Now we will understand this problem in detail from a lower-level perspective. From the summary of Connext founder Arjun Bhuptani, the cross-chain protocol can only choose two of the following three key attributes to optimize:

1. None Trustlessness: It does not need to rely on any centralized trust entity and can provide the same level of security as the underlying blockchain. Users and participants do not need to trust any intermediary or third party to ensure the security and correct execution of transactions;

2. Extensibility (Extensibility) : The protocol can be easily adapted to any blockchain platform or network , not restricted by specific technical architecture or rules. This allows interoperability solutions to support a broad blockchain ecosystem, rather than just a few specific networks;

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

The early classification of cross-chain bridges was generally based on Vitalik and others. They divided cross-chain technology into three categories, hash time lock, witness verification, and relay verification (light client verification), but later based on According to Arjun Bhuptani's classification, cross-chain solutions can be divided into native verification (no trust + scalability), external verification (scalability + versatility), and native verification (no trust + versatility). These verification methods are based on different trust models and technology implementations to meet different security and interoperability requirements.

Natively Verified :

The locally verified bridge relies on the consensus mechanism of the source chain and the target chain itself to directly verify the validity of the transaction. This approach does not require additional layers of verification or intermediaries. For example, some bridges might leverage smart contracts to create verification logic directly between two blockchains, allowing the two chains to confirm transactions through their own consensus mechanisms. The advantage of this approach is increased security, as it relies directly on the inherent security mechanisms of the participating chains. However, this approach can be more technically complex to implement, and not all blockchains support direct local verification.

Externally Verified :

Externally verified bridges use a third-party validator or cluster of validators to confirm the validity of transactions. These validators may be independent nodes, consortium members, or some other form of participants that operate outside of the source and target chains. This approach typically involves cross-chain messaging and verification logic that is performed by external entities rather than being handled directly by the participating blockchains themselves. External verification allows for wider interoperability and flexibility because it is not restricted to a specific chain, but it also introduces an additional layer of trust and potential security risks. (Although there is a huge risk of centralization, external verification is the most mainstream cross-chain method. In addition to being flexible and efficient, it is also low-cost)

Locally Verified:

Native verification refers to the target chain verifying the status of the source chain in cross-chain interactions to confirm transactions and execute subsequent transactions locally. Common practice is to run the light client on the source chain of the target chain VM, or both in parallel. Native verification requires an honest minority or synchronization assumption, at least one honest relayer on the committee (i.e. an honest minority), or if the committee cannot function properly, users must transmit transactions themselves (i.e. a synchronization assumption). Native verification is the cross-chain communication method with the highest degree of trust minimization, but it is also very costly, has low development flexibility, and is more suitable for blockchains with high state machine similarity, such as Ethereum and L2 networks. between, or between blockchains developed based on Cosmos SDK.

Current cross-chain solution『1』

Compromises in different aspects have led to the emergence of different types of cross-chain solutions, in addition to verification methods. Current cross-chain solutions can also be divided into multiple categories, each of which adopts unique methods to achieve asset exchange, transfer and contract invocation.

• Token Exchange: Allows users to trade a certain asset on one blockchain and receive another asset of equal value on another chain. By utilizing technologies such as atomic swaps and cross-chain market makers (AMM), liquidity pools can be created on different chains to achieve exchanges between 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 the assets are processed:

• Locking/Minting Mode : In this mode, assets on the source chain are locked while minting on the target chain Equivalent "bridging assets" are produced. During the reverse operation, the bridging assets on the target chain are destroyed to unlock the original assets on the source chain;

• Destruction/Casting Mode: In this mode, the bridging assets on the source chain are The asset is destroyed and an equal amount of the same asset is minted on the target chain;

• Lock/unlock mode: This method involves locking the asset on the source chain and then in the liquidity pool on the target chain Unlock equivalent assets. Such asset bridges often attract liquidity by offering incentives such as revenue sharing.

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

• Smart contract interoperability: Allow smart contracts on the source chain to call smart contract functions on the target chain based on local data to implement complex cross-chain applications, including asset exchange and bridging operations.

• Programmable Bridge: This is an advanced interoperability solution that combines asset bridging and messaging capabilities. When assets are transferred from the source chain to the target chain, contract calls on the target chain can be immediately triggered to implement a variety of cross-chain functions, such as equity pledge, asset exchange, or storing assets in smart contracts on the target chain.

2.2 Agglayer will have more advantages in the future

Here we compare Agglayer with the current full-chain protocols, taking LayerZero, the most influential full-chain protocol, as an example. The protocol adopts an improved version of external verification, that is, LayerZero transforms the verification source of trust into two independent entities - oracles and relays, to make up for the shortcomings of external verification in the simplest way. The cross-chain solution is a programmable bridge solution that can achieve a variety of operations. Logically speaking, it seems that the so-called impossible triangle has been cracked concisely and neatly. From a grand narrative perspective, LayerZero has the opportunity to become the cross-chain hub of the entire Web3, and it is quite suitable for the problems such as experience fragmentation and liquidity fragmentation caused by the explosion of the chain in the modular era. This is why the leading VCs want to be here. The main reason for crazy betting on the protocol.

But what is the real situation? Let’s not talk about Layerzero’s various recent airdrop operations. From a development perspective, it is actually very difficult for this type of protocol to achieve the ideal situation of connecting the entire Web3, and the issue of decentralization is questionable. In the early V1 version, the oracle machine used by LayerZero was actually hacked and there was a theoretical possibility of the oracle machine doing evil (regarding this, Wormhole used industry organizations as guardian nodes, which was often criticized), until the V2 version The birth of the Decentralized Verification Network (DVN) has quelled the criticism on social networks, but this is also based on a large number of B-side resources.

On the other hand, the development of full-chain protocols also involves the protocols, data formats and operation logic of heterogeneous chains, as well as the calling issues of different smart contracts. To truly realize Web3 interoperability requires not only your own efforts, but also the collaboration of various projects. If you have used the early LayerZero, it should be easy to find that it basically only supports cross-chains of EVM public chains, and there are not many ecological projects that support the entire chain. This is the same for Agglayer, but in terms of interoperability, Agglayer supports ultra-low latency and asynchronous interoperability, which is more like the Internet we use every day than the full-chain protocol.

In summary, Agglayer is aggregated in a way similar to single-chain use, which is overall more concise, efficient and in line with the current modular trend. However, there is no absolute superiority between the two at present. The full-chain protocol still has the broadest liquidity, ecology, stronger initiative, and the advantage of relatively mature development. The advantage of Agglayer lies in the true aggregation of mutually hostile Layer1 and Layer2, breaking up different public chain projects in the era of chain explosion, decentralizing the zero-sum game between liquidity and users, allowing multi-chain low-latency interaction, and natively bringing its own chain Abstraction, shared liquidity pools do not require wrapped tokens, which will be a very good opportunity for long-tail chains and application chains. Therefore, in the long run, Agglayer is currently the most promising cross-chain solution. Similar projects currently in the development stage include Polkadot’s “Join-Accumulate Machine”. There will definitely be more similar solutions in the future. The history of Web3 is Now it has moved from monolithic to module, and the next step will be to convergence.

3. The ecosystem that Agglayer is connected to

Since it is still in the early days, there are not many access chains for Agglayer. Here are three main projects:

3.1 X Layer

X Layer is The Ethereum Layer 2 project based on Polygon CDK connects the Ethereum and Ethereum communities, allowing anyone to participate in a truly global on-chain ecosystem. As the public chain of the leading exchange, after being connected to Agglayer, it will bring extensive liquidity to projects in the aggregation layer. As an access layer for ordinary users, the OKX Web3 wallet may also provide better support for Agglayer.

3.2 Union

Union is a zero-knowledge infrastructure layer built on Cosmos, a project used for general messaging, asset transfers, NFTs 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, a deep connection between EVM and Cosmos is realized, because Union only needs to be used as an IBC gateway to connect to Union and then to IBC, thus reuniting the two modular ecologies that were separated from each other.

3.3 Astar

Astar Network is a network of Japanese and global enterprises, entertainment and game projects, dedicated to promoting "Web3". It provides customizable blockchain solutions utilizing cross-virtual machines powered by Polygon and Polkadot. As Agglayer's first fully integrated chain, this project will directly access the tens of billions of dollars in liquidity sharing pools and achieve real user growth.

References

1.One article to understand blockchain interoperability: 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

The above is the detailed content of From Modularity to Aggregation: Exploring Polygon 2.0's Agglayer Core. For more information, please follow other related articles on the PHP Chinese website!