From modularity to aggregation: Exploring the Agglayer core of Polygon 2.0

Author: YBB Capital Researcher Zeke

TLDR

• Agglayer is a core component of Polygon 2.0 that unifies 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 fragmentation 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, which is 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 abbreviation of the English word aggregation, and its full Chinese name is aggregation layer. The role of this protocol is essentially the same as that of full-chain interoperability protocols such as Layerzero and Wormhole, and its purpose is to connect the fragmented blockchain world. However, there are some differences in the construction ideas. In layman's terms, the traditional full-chain interoperability protocol is more like an engineering company that builds bridges everywhere, and achieves interconnection by designing and building bridges for different chains or protocols (heterogeneous chains are more difficult to adapt). Agglayer is just as its name suggests. It is more like a "local area network" composed of switches. The connecting chain only needs to insert a "network cable" (ZK proof) to access the "local area network" and exchange data. Compared with building bridges everywhere, it is faster, easier to use and has better interoperability.

1.2 Shared Validity Sequencing

Agglayer's idea is largely due to Umbra Research's design of Shared Validity Sequencing, which aims to achieve atomic cross-chain interoperability between multiple Optimistic Rollups. Through the shared 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 sorter that accepts cross-chain operations: receives and processes cross-chain transaction requests;

2. Block construction algorithm: The shared sorter is responsible for building blocks containing cross-chain operations to ensure the atomicity of these operations;

3. Shared fraud proof: in related Rollup

This figure shows the working process of the MintBurnSystemContract contract when sharing a sorter

Since the current Rollup basically has the function of bidirectional message transmission between Layer1 and Layer2, as well as other special precompilations. So as shown in the figure above, Umbra only adds a simple cross-chain system consisting of a MintBurnSystemContract contract (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 in burnTree after success;

2. Mint operation on chain B: the sorter records it in mintTree after successful execution.

Invariants and consistency

Merkle root consistency: The Merkle root 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.

Under this design, Rollup A and B share a sorter. This shared sorter is responsible for publishing the transaction batches and declared state roots of the two Rollups to Ethereum. The shared sorter can be a centralized sorter, like most of the current Layer2 Rollup sorters, or a decentralized sorter like Metis. The key point in the whole system is that the shared sorter must publish the transaction batches and declared state roots of both Rollups to L1 in the same transaction.

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

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

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 the unified bridge is to collect and summarize the status of all access chains to the aggregation layer, and the aggregation layer then generates a unified proof to Ethereum. There are three stages of status in this process: pre-confirmation (pre-confirmation allows faster interaction under the temporary state assumption), confirmation (confirmation verifies the validity of the submitted proof) and finalization. Finally, the proof can verify the transaction validity of all access chains.

Pessimistic proof: Rollups accessing a multi-chain environment will cause two major problems: 1. The introduction of different validators and consensus mechanisms will lead to complex security; 2. It takes 7 days for Optimistic Rollup to receive payments. In order to solve these two problems, Polygon 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 have malicious behavior and make worst-case assumptions for all cross-chain operations. Then, AggLayer will use zero-knowledge proof to verify the correctness of these operations to ensure that even if there is malicious behavior, the integrity of cross-chain operations cannot be destroyed.

1.4 Features

Under this scheme, the following features can be achieved:

• Native tokens. By using a unified bridge, all assets in the aggregation layer are native assets, without any wrapped tokens, and no third-party trusted source is required for cross-chain, everything is seamless;

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

• Sovereignty. Compared with the way Optimistic Rollup above obtains interoperability through a shared sorter, Agglayer has better sovereignty, and AggLayer will be compatible with shared sorters and third-party DA solutions. The connected chain can even use its native token as Gas;

• Faster. Still different from the Optimistic Rollup solution above, Agglayer does not need to wait 7 days for cross-chain;

• Safe. Pessimistic proof only accepts correct behavior. On the other hand, it also ensures that no chain can withdraw more than the deposited amount, 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 fee paid to Ethereum, because it is amortized, and Agglayer does not charge additional protocol fees.

2. Cross-chain solution

2.1 Why is cross-chain so difficult?

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

Like the most famous public chain triangle problem, cross-chain protocols also have interoperability trilemma. Due to the limitation of the premise of decentralization, blockchain is essentially a replicated state machine that cannot receive external information. Although the existence of AMM and oracle makes up for the missing puzzle 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 packaged tokens such as xxBTC and xxETH. But the logic of this token packaging 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 various problems such as protocol incompatibility caused by different assets and virtual machines, trust issues, double-spending issues, and delay 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 the collapse of xx cross-chain bridges. Now let's take a closer look at this issue from a lower-level perspective. From the summary of Arjun Bhuptani, founder of Connext, the cross-chain protocol can only choose two of the following three key attributes to optimize: 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;

The early classification of cross-chain bridges was generally based on Vitalik et al., who divided cross-chain technology into three categories: hash time lock, witness verification, and relay verification (light client verification). However, according to Arjun Bhuptani's classification, cross-chain solutions can be divided into native verification (trustless + scalability), external verification (scalability + versatility), and native verification (trustless + versatility). These verification methods are based on different trust models and technical implementations to meet different security and interoperability requirements.

Natively Verified:

Natively verified bridges rely on the consensus mechanisms of the source and target chains themselves to directly verify the validity of transactions. This approach does not require an additional verification layer or intermediary. For example, some bridges may utilize smart contracts to create verification logic directly between the two blockchains, allowing the two chains to confirm transactions through their own consensus mechanisms. The advantage of this approach is increased security because it directly relies on the inherent security mechanisms of the participating chains. However, this approach may be more complex in technical implementation, and not all blockchains support direct native 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, members of a consortium, or some other form of participant that operates outside of the source and target chains. This approach typically involves cross-chain messaging and verification logic that is performed by an external entity rather than handled directly by the participating blockchains themselves. External verification allows for broader interoperability and flexibility because it is not restricted to a specific chain, but it also introduces additional layers of trust and potential security risks. (Although there is a great risk of centralization, external verification is the most mainstream cross-chain method. In addition to being flexible and efficient, it also has the characteristics of low cost)

Locally Verified:

Locally Verified:

Locally Verified means that the target chain verifies the state of the source chain in the cross-chain interaction to confirm the transaction and execute subsequent transactions locally. The usual practice is to run a light client on the source chain of the target chain virtual machine, or both in parallel. Locally verified requires an honest minority or synchronization assumption, where there is at least one honest relayer in the committee (i.e., an honest minority), or if the committee cannot operate normally, users must transmit transactions themselves (i.e., synchronization assumption). Native verification is the most trust-minimized cross-chain communication method, but it is also very costly, has low development flexibility, and is more suitable for blockchains with high state machine similarity, such as between Ethereum and L2 networks, 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 takes a unique approach to achieve 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 leveraging technologies such as atomic swaps and cross-chain market makers (AMMs), liquidity pools can be created on different chains to enable exchange 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 according to the way it handles assets:

• Lock/Mint Mode: In this mode, the assets on the source chain are locked, and the target chain casts an equivalent "bridge asset". In the reverse operation, the bridge asset on the target chain is destroyed to unlock the original asset on the source chain;

• Destroy/Mint Mode: In this mode, the assets on the source chain are destroyed, and the same amount of the same assets are cast on the target chain;

• 18px;">Lock/Unlock Mode: This involves locking assets on the source chain and then unlocking an equivalent asset in a liquidity pool on the target chain. Such asset bridges often attract liquidity by offering 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 on one chain based on data 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 exchange and bridging operations.

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

2.2 Agglayer has more advantages in the future

Here we compare Agglayer with the current full-chain protocol, taking LayerZero, the most influential full-chain protocol, as an example. The protocol uses an improved version of external verification, that is, LayerZero transforms the source of verification trust into two independent entities - the oracle and the relay, and makes up for the defects of external verification in the simplest way. The cross-chain solution belongs to a programmable bridge solution that can realize multiple operations. Logically, it seems to have solved the so-called impossible triangle in a simple and neat way. From a grand narrative perspective, LayerZero has the opportunity to become the cross-chain hub of the entire Web3, and it is quite in line with the problems of experience fragmentation and liquidity fragmentation caused by the chain explosion in the modular era. This is the main reason why the top VCs are betting wildly on such protocols.

But what is the real situation? Let's not talk about the recent Layerzero airdrop operations. From the perspective of development alone, it is actually very difficult for such protocols to achieve the ideal situation of connecting the entire Web3, and the decentralization problem is questionable. In the early V1 version, the oracle used by LayerZero was actually hacked and there was a theoretical possibility that the oracle could do evil (in this regard, Wormhole uses industry organizations as guardian nodes, which is often criticized). It was not until the birth of the V2 version of the decentralized verification network (DVN) that the criticism on social networks was quelled, but this was also based on a large number of B-side resources.

On the other hand, the development of the full-chain protocol also involves the protocols, data formats and operation logic of heterogeneous chains, as well as the calling issues of different smart contracts. To truly achieve the interoperability of Web3 requires not only one's own efforts, but also the collaboration of various projects. If you have used the early LayerZero, it should not be difficult to find that it basically only supports the cross-chain of the EVM public chain, and there are not many ecological projects that support the full chain. The same is true for 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 than the full-chain protocol.

In general, Agglayer aggregates into a method similar to single-chain use, which is simpler, more efficient and in line with the current modular trend. However, there is no absolute high or low between the two at present. The full-chain protocol still has the broadest liquidity, ecology, stronger initiative, and more mature advantages. The advantage of Agglayer is that it truly aggregates the mutually hostile Layer1 and Layer2, breaking the zero-sum game of different public chain projects in the era of chain explosion, dispersing liquidity and users, allowing multi-chain low-latency interaction, and native self-contained chain abstraction. Sharing liquidity pools does not require packaging tokens, which will be a very good opportunity for long-tail chains and application chains. Therefore, in the long run, Agglayer is 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 has now moved from monolithic to modular, and the next step will be to aggregate.

3. The ecosystem connected by Agglayer

Since it is still in its early stages, there are not many access chains to Agglayer. Here we mainly mention three projects:

3.1 X Layer

X Layer is an Ethereum Layer2 project based on Polygon CDK. It connects OUY and the Ethereum community, allowing anyone to participate in a truly global chain ecosystem. As the public chain of the head exchange, after access to Agglayer, it will bring extensive liquidity to the projects in the aggregation layer. As the 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, which is 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 MPCs. As an access chain, after entering the aggregation layer, the deep connection between EVM and Cosmos is realized, because only Union can be used as an IBC gateway to connect to Union and then to IBC, so that the two separated modular ecosystems can be reunited.

3.3 Astar

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

References

1. Understand 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