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

Author: YBB Capital Researcher Zeke

TLDR

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

• Agglayer employs a novel verification mechanism called pessimistic proof, which assumes that all connected chains are insecure and ultimately utilizes zero-knowledge proofs 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, aligning better with the definition of the next generation of Web3.

I. Agglayer's Derivation from the Modular Era

1.1 Introduction to Agglayer

Agglayer is one of the core components of Polygon 2.0, with "Agg" in its protocol name being an abbreviation for the English word "aggregation." The full Chinese name translates to "aggregation layer." The protocol essentially serves the same purpose as full-chain interoperability protocols like Layerzero and Wormhole, which is to connect the fragmented blockchain world. However, there are some differences in construction philosophy; in simple terms, traditional full-chain interoperability protocols resemble engineering companies that build bridges everywhere, designing and constructing bridges for different chains or protocols (where adapting heterogeneous chains is particularly challenging) to achieve interconnection. In contrast, Agglayer, as its name suggests, is more like a "local area network" composed of exchange institutions, where connecting chains only need to insert a "network cable" (ZK proof) to access the "local area network" and exchange data. Compared to bridging everywhere, it is faster, easier to use, and has better interoperability.

1.2 Shared Validity Sequencing

The concept of Agglayer owes much to Umbra Research's design of Shared Validity Sequencing, which aims to achieve atomic cross-chain interoperability among multiple Optimistic Rollups. By using a shared sequencer, the entire system can uniformly handle transaction ordering and state root publication for multiple Rollups, ensuring atomicity and conditional execution.

The specific implementation logic requires three components:

1. A shared sequencer that accepts cross-chain operations: receives and processes cross-chain transaction requests;

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

3. Shared fraud proof: a mechanism for sharing fraud proofs among relevant Rollups to enforce cross-chain operations.

The diagram illustrates the working process of the MintBurnSystemContract when using a shared sequencer.

Since current Rollups essentially have the capability to transmit messages bidirectionally between Layer1 and Layer2, along with other special precompiles, Umbra here has only added a simple cross-chain system composed of a MintBurnSystemContract (Burn and Mint) to complete the three components.

Workflow

1. Burn operation on Chain A: Any contract or external account can call it, and upon success, it is recorded in the burnTree;

2. Mint operation on Chain B: The sequencer records it in the mintTree after successful execution.

Invariants and Consistency

Consistency of Merkle roots: The Merkle roots of the burnTree on Chain A and 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 the transaction batches and declaring state roots of the two Rollups to Ethereum. The shared sequencer can be a centralized sequencer, like most Layer2 Rollup sequencers today, or a decentralized sequencer like Metis. The key point in the entire system is that the shared sequencer must publish the transaction batches and declare state roots 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 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 will exclude both transactions.

In simple terms, this system is a straightforward extension of the existing block construction algorithm. The sequencer executes transactions and inserts condition-triggered transactions from one Rollup into another, while ensuring that the burn on Chain A and the mint on Chain B are correct during fraud proof verification on the main chain (i.e., the consistency of the Merkle roots mentioned above). In this case, multiple Rollups become similar to a single chain, providing better sharding support, application sovereignty, and interoperability compared to a single Rollup. However, the downside is that the burden on node validation and the sequencer is greater, and from various perspectives such as profit distribution and Rollup autonomy, the probability of adopting this solution is still quite low.

1.3 Core Components of Agglayer

While incorporating 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 aggregate the states of all connected chains to the aggregation layer, which then generates a unified proof to Ethereum. This process involves three stages of state: pre-confirmation (allowing faster interactions under temporary state assumptions), confirmation (validating the effectiveness of the submitted proof), and finalization, after which the proof can verify the validity of transactions across all connected chains.

Pessimistic Proof: The introduction of multiple chains into a Rollup environment creates two main issues: 1. The introduction of different validators and consensus mechanisms complicates security; 2. The collection of Optimistic Rollup requires 7 days. To address these two issues, Polygon has introduced a novel zero-knowledge proof method, namely pessimistic proof.

The idea behind pessimistic proof is to assume that all blockchains connected to AggLayer may exhibit malicious behavior and to make worst-case assumptions about all cross-chain operations. Then, AggLayer uses 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 scheme, the following features can be achieved:

• Native tokens. By using the unified bridge, the assets within the aggregation layer are all native assets, with no wrapped tokens and no need for third-party trust sources for cross-chain operations; everything is seamless;

• Unified liquidity. The TVL of all connected chains is shared, also referred to as a shared liquidity pool;

• Sovereignty. Compared to the method of achieving interoperability through shared sequencers in Optimistic Rollups mentioned above, Agglayer has better sovereignty, as AggLayer will be compatible with shared sequencers and third-party DA solutions. Connected chains can even use their native tokens as gas;

• Faster. Unlike the Optimistic Rollup scheme mentioned above, Agglayer does not require a 7-day wait for cross-chain operations;

• Security. Pessimistic proof only accepts correct behavior, and on the other hand, it ensures that no chain can withdraw more than the deposited amount, thus guaranteeing the security of the shared asset pool in the aggregation layer;

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

II. Cross-Chain Solutions

2.1 Why is Cross-Chain So Difficult?

As mentioned earlier, Agglayer and full-chain protocols have essentially the same goal, so which is superior? Before comparing, we may need to understand two questions: 1. Why is cross-chain difficult? 2. What are the common cross-chain solutions?

Similar to the well-known blockchain trilemma, cross-chain protocols also face an interoperability trilemma. Due to the constraints of decentralization, blockchains are essentially replication state machines that cannot receive external information. Although the existence of AMMs and oracles fills the missing puzzle in DeFi, this issue is exponentially more complex for cross-chain protocols. From a certain perspective, we may never be able to extract any real tokens from the original chain, which is why various wrapped tokens like xxBTC and xxETH exist. However, this wrapped token solution is very dangerous and centralized because you need to lock real BTC and ETH in the cross-chain bridge contract's original chain address, and the entire cross-chain design may face various issues such as incompatible assets, different virtual machines leading to protocol incompatibility, trust issues, double-spending problems, and latency issues. To be efficient and reduce costs, most cross-chain solutions still adopt multi-signature wallet schemes. Therefore, even today, you can often see news about xx cross-chain bridges collapsing. Now, let’s take a closer look at this issue from a lower-level perspective. According to Connext founder Arjun Bhuptani, cross-chain protocols can only optimize two of the following three key attributes:

1. Trustlessness: No reliance 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 apply to any blockchain platform or network, unrestricted 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 through this bridge, different blockchains can exchange various types of information and value, including but not limited to cryptocurrencies, smart contract calls, and other arbitrary data.

Early cross-chain bridges were generally categorized based on figures like Vitalik, who divided cross-chain technology into three types: hash time locks, witness validation, and relay validation (light client validation). However, later classifications by Arjun Bhuptani further divided cross-chain solutions 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 varying security and interoperability needs.

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 method does not require an additional verification layer or intermediary. For example, some bridges may utilize smart contracts to create verification logic directly 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 approach may be technically more complex, and not all blockchains support direct local verification.

Externally Verified:

Externally verified bridges use third-party validators or validator clusters to confirm the validity of transactions. These validators may be independent nodes, consortium members, or other forms of participants operating outside the source and target chains. This method typically involves cross-chain messaging and verification logic executed by external entities rather than directly handled by the participating blockchains. External verification allows for broader interoperability and flexibility, as it is not limited by specific chains, but it also introduces an additional layer of trust and potential security risks. (Although there are significant centralization risks, external verification is the most mainstream cross-chain method, combining flexibility and efficiency with low costs.)

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 within the target chain's virtual machine or run both in parallel. Local verification requires an honest minority or synchronization assumptions, where at least one honest relayer exists in the committee (i.e., an honest minority), or if the committee cannot operate normally, users must transmit transactions themselves (i.e., synchronization assumption). Local verification is the cross-chain communication method with the highest degree of trust minimization, but it is also costly, has lower 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 the Cosmos SDK.

Current Cross-Chain Solutions "1"

The compromises in different aspects have led to the emergence of various types of cross-chain solutions, aside from verification methods. Current cross-chain solutions can also be categorized into several types, each adopting unique approaches to achieve asset exchange, transfer, and contract invocation.

• 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 across different chains to facilitate exchanges between different assets.

• Asset Bridge: This method involves locking or destroying assets on the source chain via smart contracts and unlocking or creating new assets on the target chain through corresponding smart contracts. 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, while equivalent "bridged assets" are minted on the target chain. The reverse operation destroys the bridged assets on the target chain to unlock the original assets on the source chain;

• Burn/Mint Mode: In this mode, assets on the source chain are destroyed, 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. Such asset bridges often attract liquidity by providing incentives like revenue sharing.

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

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

• Programmable Bridges: 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, it can immediately trigger contract calls on the target chain, achieving various cross-chain functions such as staking, asset exchange, or storing assets in smart contracts on the target chain.

2.2 Agglayer's Advantages in the Future

Here, we compare Agglayer with current full-chain protocols, taking LayerZero, the most influential full-chain protocol, as an example. This protocol adopts an improved version of external verification, transforming the trust sources of verification into two independent entities—an oracle and a relayer—addressing the shortcomings of external verification in the simplest way. In terms of cross-chain solutions, it belongs to a programmable bridge solution capable of performing various operations. Logically, it seems to neatly break the so-called impossible triangle. From a grand narrative perspective, LayerZero has the opportunity to become the cross-chain hub of the entire Web3, fitting well with the issues of experience fragmentation and liquidity fragmentation caused by the explosion of chains in the modular era, which is why leading VCs are making aggressive bets on such protocols.

But what is the real situation? Without discussing the recent various manipulations regarding LayerZero's airdrop, from a developmental perspective, it is actually very difficult for such protocols to achieve the ideal scenario of connecting the entire Web3, and the decentralization issue is questionable. In the early V1 version, the oracle used by LayerZero was actually vulnerable to hacking and theoretically had the potential for oracle malfeasance (regarding this, Wormhole employs industry institutions as guardian nodes, which is often criticized). It wasn't until the birth of the decentralized verification network (DVN) in the V2 version that the social media backlash subsided, but this was also based on a large amount of B-end resources.

On the other hand, the development of full-chain protocols also involves heterogeneous chain protocols, data formats, and operational logic, as well as issues related to calling different smart contracts. Achieving true interoperability in Web3 requires not only self-effort but also collaboration among various projects. If you have used early LayerZero, you should not find it difficult to see that it basically only supports cross-chain operations among EVM-compatible public chains, and there are not many ecosystem projects that support full-chain. This is also true for Agglayer, but in terms of interoperability, Agglayer supports ultra-low latency and asynchronous interoperability, which is more akin to the internet we use daily than full-chain protocols.

In summary, Agglayer aggregates in a manner similar to single-chain usage, making it overall more concise, efficient, and aligned with the current modular trend. However, there is no absolute superiority between the two at present; full-chain protocols still possess the broadest liquidity, ecosystem, and stronger proactivity, along with the advantages of more mature development. Agglayer's advantage lies in genuinely aggregating mutually opposing Layer1 and Layer2, breaking the zero-sum game of different public chain projects in the era of chain explosion, allowing for low-latency interactions across multiple chains, and natively incorporating chain abstraction. The shared liquidity pool does not require wrapped tokens, which presents a great opportunity for long-tail chains and application chains. Therefore, in the long run, Agglayer is currently the most promising cross-chain solution. Similar projects in the development stage include Polkadot's "Join-Accumulate Machine," and more similar solutions will undoubtedly emerge in the future. The history of Web3 has now transitioned from single chains to modular, and the next step will be towards aggregation.

III. Ecosystem Connected by Agglayer

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

3.1 X Layer

X Layer is an Ethereum Layer2 project built on Polygon CDK, connecting the OKX and Ethereum communities, allowing anyone to participate in a truly global on-chain ecosystem. As a public chain of a leading exchange, its integration with Agglayer will bring extensive liquidity to projects within the aggregation layer. 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, designed for general messaging, asset transfer, NFTs, and DeFi. It is based on consensus verification and does not rely on trusted third parties, oracles, multi-signatures, or MPC. As a connected chain, it achieves deep integration between EVM and Cosmos upon entering the aggregation layer, as it only needs to connect Union as an IBC gateway to connect Union and then IBC, thereby recombining two previously disconnected modular ecosystems.

3.3 Astar

Astar Network is a network for enterprises, entertainment, and gaming projects in Japan and globally, dedicated to promoting "Web3." It utilizes cross-virtual machine capabilities supported by Polygon and Polkadot to provide customizable blockchain solutions. As the first fully integrated chain with Agglayer, this project will directly access a shared liquidity pool worth hundreds of billions and achieve real user growth.

References

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