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

Original title: "From Modularity to Aggregation: Exploring the Agglayer Core of Polygon 2.0"

Original author: Zeke, YBB Capital Researcher

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 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 a switch. The connecting chain only needs to insert a "network cable" (ZK proof) to access the "local area network" and exchange data. Compared with cross-bridges everywhere, it is faster, easier to use and has better interoperability.

1.2 Shared Validity Sequencing

The idea of Agglayer 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 sorter, the entire system can uniformly handle the transaction sorting and state root publishing of multiple Rollups to ensure atomicity and conditional execution.

The specific implementation logic requires three components:

· Shared sorter that accepts cross-chain operations: receives and processes cross-chain transaction requests;

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

· Shared fraud proof: Shares the fraud proof mechanism between related Rollups to enforce cross-chain operations.

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 pre-compilations. 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 is recorded to burnTree after success;

2. Mint operation on chain B: The sorter records it to mintTree after successful execution.

Invariants and consistency

Consistency of Merkle root: 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 declaration 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 of the whole system is that the shared sorter must publish the transaction batches and declared state roots of the two 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 both 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 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 consistency of the Merkle root mentioned above). In this case, multiple Rollups become similar to a single chain. Compared with monolithic Rollups, this design provides better sharding support, application sovereignty, and interoperability. But the opposite problem is that the burden on node verifiers and sorters is greater, and from many perspectives such as profit 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. In this process, there are three stages of status: pre-confirmation (pre-confirmation allows faster interaction under the assumption of temporary status), 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 connected to a multi-chain environment will cause two major problems: 1. The introduction of different validators and consensus mechanisms will lead to complex security; 2. Optimistic Rollup collection takes 7 days. 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 the worst-case assumption 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 access chains is shared, which can also be called a shared liquidity pool;

● Sovereignty. Compared with the way Optimistic Rollup obtains interoperability through a shared sorter mentioned above, 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 mentioned 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 of the aggregation layer;

● Low cost. The more chains connected to the aggregation layer, the lower the proof fee paid to Ethereum, because this 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 first: 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. However, 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 costs, most cross-chain solutions actually use multi-signature wallet solutions. So even today, you can often see information about the collapse of the xx cross-chain bridge. Now let's take a closer look at this issue from a lower-level perspective. From the summary of Arjun Bhuptani, the founder of Connext, the cross-chain protocol can only choose two of the following three key attributes to optimize:

1. 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: The protocol can be easily applied 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 just specific transaction types or assets. This means that through the 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 et al., who divided cross-chain technology into three categories: hash time lock, witness verification, and relay verification (light client verification), but later 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 mechanism 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 use 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 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 local verification.

Externally Verified:

Externally verified bridges use a third-party validator or validator cluster to confirm the validity of transactions. These validators may be independent nodes, alliance members, or some other form of participants that operate outside the source and target chains. This approach usually involves cross-chain messaging and verification logic that is executed by external entities rather than directly handled 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 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 fees)

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 function properly, users must transmit transactions themselves (i.e., synchronization assumption). Locally verified is the most trust-minimized cross-chain communication method, but it is also 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 the Cosmos SDK.

Current cross-chain solutions "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 achieve 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 based on how it handles assets:

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

○ Destroy/Mint Mode: In this mode, assets on the source chain are destroyed, and an equal amount of the same assets are 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 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 and can be performed 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, realizing 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 assets are transferred from the source chain to the target chain, contract calls on the target chain can be triggered immediately, realizing a variety of cross-chain functions, such as staking, asset exchange, or storing assets in smart contracts 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 adopts a modified version of external verification, that is, LayerZero converts the source of trust for verification into two independent entities-oracle and relayer, and makes up for the defects of external verification in the simplest way. The cross-chain solution belongs to the programmable bridge solution that can realize multiple operations. Logically speaking, 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. Considering only from the perspective of development, 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-based 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 difference 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 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 currently the most promising cross-chain solution. Similar projects that are also 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. Ecosystem connected by Agglayer

Since it is still in its early stages, there are not many Agglayer-connected chains. Here are three projects:

3.1 X Layer

X Layer is an Ethereum Layer2 project based on Polygon CDK. It connects the ETH and Ethereum communities, allowing anyone to participate in a truly global on-chain ecosystem. As a public chain of a leading exchange, it will bring extensive liquidity to projects within the aggregation layer after being connected to Agglayer. 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, 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, entering the aggregation layer realizes a deep connection between EVM and Cosmos, because only Union needs to be used as an IBC gateway to connect Union and then IBC, thereby recombining two separate modular ecosystems.

3.3 Astar

Astar Network is a network of Japanese and global enterprise, entertainment and gaming projects dedicated to promoting "Web3". It provides customizable blockchain solutions using a cross-virtual machine powered by Polygon and Polkadot. As the first fully integrated chain of Agglayer, the project will directly access tens of billions of dollars in liquidity sharing pools 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

This article comes from a contribution and does not represent the views of BlockBeats.

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia