作者: YBB Capital Researcher Zeke
TLDR
Agglayer is the core component of Polygon 2.0, which 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 and be more in line with the definition of the next generation Web3.
1. Agglayer derives from the modular era
1.1 Agglayer Introduction
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 indeed 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 (where heterogeneous chains are more difficult to adapt). Agglayer is just as its name suggests. In form, 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 crossing bridges everywhere, it is faster, easier to use and has better interoperability.
1.2 Shared Validity Sequencing
The idea of Agglayer owes much to Umbra Research's design of Shared Validity Sequencing, which aims to achieve atomic cross-chain interoperability between multiple Optimistic Rollups. Through a shared sequencer, the entire system can uniformly handle transaction ordering and state root publishing for multiple Rollups, ensuring 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 and ensuring the atomicity of these operations;
Shared Fraud Proofs: Fraud proof mechanisms are shared between related Rollups to enforce cross-chain operations.
This figure shows the working process of the MintBurnSystemContract contract when sharing a sequencer
Since the current Rollup basically has the function of bidirectional message transmission between Layer1 and Layer2, as well as other special pre-compilations, 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.
work process
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 to mintTree after successful execution.
Invariants 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 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 of the entire 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 if it interacts with the MintBurnSystemContract. If the transaction executes successfully 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 building algorithm. The sorter executes transactions and inserts conditionally triggered transactions from one Rollup to another. When verifying the fraud proof on the main chain, 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 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 benefit 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 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. It takes 7 days for Optimistic Rollup to collect 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 proofs to verify the correctness of these operations, ensuring that even if there is malicious behavior, the integrity of cross-chain operations cannot be destroyed.
1.4 Features
Under this solution, 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 without the need for a third-party trusted source 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 obtains interoperability through a shared sorter, Agglayer has better sovereignty. 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;
Security. Pessimistic proofs only accept 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 at 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?
Just 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 wrapped tokens such as xxBTC and xxETH. However, the logic of this wrapped 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 need to face different assets, different virtual machines caused by protocol incompatibility, trust problems, double-spending problems, delay problems and other problems. In order to be efficient and reduce expenses, most cross-chain solutions actually adopt the multi-signature wallet solution. 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 problem from a lower level. From the summary of Arjun Bhuptani, founder of Connext, cross-chain protocols 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;
Extensibility: The protocol can be easily adapted 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;
Generalizability: The protocol is able to handle any type of cross-domain data or asset transfer, not limited to 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 technologies 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:
Locally validated 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 additional verification layers or intermediaries. For example, some bridges may utilize 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 validated bridges use third-party validators or validator clusters 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 typically involves cross-chain messaging and verification logic that is performed by external entities rather than directly processed 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:
Native verification refers to the target chain verifying the state of the source chain in cross-chain interaction to confirm transactions 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. Native verification 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., the synchronization assumption). Native verification 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 solution [1]
Compromises in different aspects have led to the emergence of different types of cross-chain solutions. In addition to the verification method, the current cross-chain solutions can also be divided into multiple categories, each of which adopts a unique method to achieve asset exchange, transfer and contract call.
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 based on how assets are handled:
Lock/Mint Mode: In this mode, the assets on the source chain are locked, and the 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.
Destruction/minting mode: In this mode, the assets on the source chain are destroyed, and an equal amount of the same assets are minted on the target chain;
Lock/Unlock Model: This 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 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 assets are transferred from the source chain to the target chain, the contract call on the target chain can be triggered immediately to achieve 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 repeater, making 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 making crazy bets on such protocols.
But what is the real situation? Let’s not talk about the recent airdrop operations of Layerzero. From a development perspective, it is actually very difficult for such protocols to achieve the ideal situation of connecting the entire Web3, and the decentralization issue 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, not only does it require one's own efforts, but it may also require 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 aggregation is similar to the use of a single chain, 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 the most promising cross-chain solution at present. 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. The ecosystem connected by Agglayer
Since it is still in its early stages, there are not many Agglayer access chains. Here are three projects:
3.1 X Layer
X Layer is an Ethereum Layer2 project based on Polygon CDK. It connects OY and the Ethereum community, 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 accessing 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. The project is used for general messaging, 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, a deep connection between EVM and Cosmos is realized, because only Union can be used as an IBC gateway to connect Union and then IBC, so that the two separated modular ecosystems can be reunited.
3.3 Speed
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. 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
