1. No single chain, whether L1 or L2, can support the throughput required to reach Internet scale.

2. Scaling blockchains means scaling access to liquidity and shared state. Adding blockspace via multiple chains doesn’t work if it fragments liquidity.

This represents a challenge to both the modular and the monolithic views of blockchain scalability. (1) is a challenge to the monolithic view, which holds that a single high-throughput chain is the best way to scale. (2) is a challenge to the modular view, because it means that a multi-chain or multi-rollup ecosystem is not sufficient for scaling in a meaningful sense: increasing access to shared state and liquidity..

If (1) and (2) are true, then solving the scalability problem requires scaling access to shared state and liquidity across many chains. Polygon’s solution is the Aggregation Layer, or “AggLayer.” The AggLayer provides safety for near-instant cross-chain transactions and enables unified state and liquidity across chains.

This post will dive into what the AggLayer is, how it works, and how it’s different from a shared sequencer or prover.

The Problem

There’s a problem with L2s: liquidity and state are fragmented across rollups and the L1.

This is bad from a usability perspective because it introduces complexity, but it’s also expensive. Fragmented liquidity means higher slippage and worse execution. Optimistic Rollups (ORs) require users to pay expensive third-party bridges to avoid the seven-day withdrawal delay. Even ZK Rollups (ZKRs) require users to round-trip to Ethereum for trustless cross-chain transactions.

Finality and Validity

Here’s why low-latency, trustless cross-chain transactions aren’t currently possible.

Suppose there are two rollups, Chain A and Chain B, that share a bridge to L1. Alice on Chain A would like to pay Bob on Chain B, so Alice locks or burns tokens on Chain A in order to transfer to Chain B.

Two things are required for Chain B to safely credit those tokens to Bob.

1. The batch containing Alice’s transaction must be finalized on Ethereum L1.

2. Chain B must be able to verify that the resulting state of Chain A is valid after Alice’s transaction.

If the batch containing Alice’s transactions isn’t finalized on Ethereum, then Chain A could equivocate to Chain B and double-spend by keeping Alice’s funds on Chain A and minting Bob’s funds on Chain B. Likewise, if Chain B doesn’t check a validity proof for A, then Chain A could include an invalid transaction and steal funds from B.

(1) and (2) mean that trustless cross-chain transactions can’t have low-latency. (1) currently requires 12 minutes, while (2) requires waiting for the duration of the challenge period in ORs and a few minutes for proof generation on ZKRs.

Good UX is incompatible with 20-minute latency. The Aggregation Layer is designed to solve this problem.

The Aggregation Layer

Polygon is an ecosystem of ZK-powered L2s that settle to Ethereum. The Aggregation Layer is a decentralized protocol operated by staked nodes that ensures safety for low-latency, cross-chain transactions and a unified bridge [1].

In this context, “safety” means the following:

It’s impossible for a rollup’s state to be finalized/settled on Ethereum if that chain state relies on an invalid or non-finalized state from another chain, or if it includes a transaction from an atomic [2] bundle that has not executed successfully on all other chains.

In other words, a state of Chain B cannot be finalized on Ethereum if it depends on an invalid or non-finalized state of Chain A.

This guarantee is important. It allows Chain B to safely interoperate with Chain A at super low latency, before the state of Chain A has finalized on Ethereum or a proof has been generated.

How the Aggregation Layer works

The Aggregation Layer functions in three phases. Suppose that Chain A is a ZK-powered chain running in the Polygon ecosystem.

1. Pre-Confirmation: Chain A submits a header for a new block/batch $$A_1$$ to the AggLayer along with a light client proof. The header includes commitments to all other blocks and bundles that $$A_1$$ depends on ($$B_i$$, $$C_i$$, etc). When the new batch is accepted without a validity proof, it’s considered “pre-confirmed” by the AggLayer.

2. Confirmation: Chain A, or any full node of A, generates a proof for $$A_1$$ and submits it to the AggLayer. Once the proof is verified by the AggLayer, $$A_1$$ is confirmed if all batches that it depends on are also confirmed.

3. Finalization: After $$A_1$$ is confirmed, its proof is aggregated alongside batches from other rollups into a single proof that is posted to Ethereum. The aggregated proof enforces that dependent chain states and bundles are consistent.

Chains can navigate the tradeoff space between latency and liveness guarantees for themselves. A chain might choose to interoperate with another chain after the pre-confirmation step for super low-latency cross-chain transactions, but fundamentally, this model is compatible with chains waiting for confirmation, or even for finalization.

The safety guarantee for cross-chain transactions is enforced at the third step. Let’s dig further into how this design enables safe cross-chain interaction.

Asynchronous Interoperability

Take the first example of a cross-chain transfer. Alice on Chain A wants to lock or burn some tokens in block $$A_1$$ in order to mint and transfer tokens to Bob on Chain B. If Chain B doesn’t wait until $$A_1$$ is finalized on Ethereum with a valid proof, then Chain A could equivocate or give Chain B an invalid state.

The Aggregation Layer solves this in a simple way. Chain B can temporarily assume that $$A_1$$ is valid and will be finalized on Ethereum, without even waiting for a proof. The sequencer for Chain B commits to the claimed Chain A state root $$A_1$$ as a dependency in the header for $$B_1$$ (as $$B^{A_1}_1$$ ) before submitting to the Aggregation Layer. The latency required for Chain B to build $$B_1$$ decreases from 20 minutes to, at most, a few seconds.

In the Confirmation step, the Aggregation Layer builds a dependency graph for each block/batch submitted. For instance, if $$A_1$$ depends on $$B_1$$, which in turn depends on $$C_1$$, $$C_1$$ is confirmed as soon as a proof $$\pi_{C_1}$$ is submitted. But, even if $$\pi_{A_1}$$ is received, $$A_1$$ is only confirmed with both $$\pi_{B_1}$$ and $$\pi_{C_1}$$.The critical aspect of this design is that the proof aggregation circuit enforces consistency across dependencies. If $$B^{A^\prime_1}1$$ is inconsistent with the block $$A_1$$ that Chain A submits, or a proof is missing for $$A^\prime{1}$$, then $$B_1$$ cannot be included in the aggregated batch finalized on Ethereum.

This mechanism guarantees that if Chain A equivocates or submits an invalid block, say $$A^\prime_1$$, then any batch that depends on an invalid or equivocated state root for Chain A cannot be finalized/settled on Ethereum. Even if the AggLayer itself equivocates, chains have a cryptographic guarantee that any block that depends on an invalid or equivocated block cannot be finalized, because two proofs for chain states that are inconsistent or invalid cannot be aggregated together in the proof aggregation circuit. This ensures that the safety property described above is preserved.

Atomic Interoperability

The safety mechanism can be extended to the atomic case. Suppose that a user submits an atomic bundle of transactions to multiple chains. This bundle is ordered, so the result of executing the transaction on Chain A is passed to Chain B, and likewise Chain B’s updated state is passed to Chain C, etc. If all transactions execute successfully across all chains, then the bundle is included; otherwise, it’s rejected.

It would be ideal to provide the ability to include atomic transactions without:

1. Requiring the operator of Chain B to run a full node for all other chains included in a bundle; or

2. Accepting the risk that the bundle might be partially included on Ethereum (harming participating chains).

This raises a similar safety issue as in the asynchronous case: Chain A might equivocate and submit a batch that doesn’t actually include the atomic bundle, or send an invalid result to Chain B.

Fortunately, the same mechanism from the async case can be reused for the atomic case. Chain B commits to bundles and received transaction results from other chains. The Aggregation Layer (and proof aggregation circuit) checks that bundles are consistent across chains. A batch containing a bundle from Chain B can only be finalized/settled on Ethereum if all transactions in the bundle are executed successfully.

Cross-Chain Composability

The Aggregation Layer enables super low-latency cross-chain composability through asynchronous cross-chain calls. This is an incredibly powerful primitive: contracts can safely call contracts on other chains at super low latency, without waiting for Ethereum finality. A user could onramp via the OKX chain on Polygon and immediately deposit into a highly-liquid lending market on Aave on a different chain in one click, without needing to swap out of a wrapped synthetic asset.

Emergent Coordination Infrastructure

The AggregationLayer guarantees that near-instant cross-chain interactions will be safe [3]. But this is only half the battle. How do chain operators share and trust each other’s chain states? How do they coordinate the production of atomic bundles?

A design goal for the AggLayer is that it should be minimal. Its purpose is to guarantee safety and provide a foundation that allows anyone to build coordination infrastructure that offers liveness in a variety of different settings.

The operators of chains can freely choose between emergent coordination mechanisms depending on their trust assumptions - these could include relays, shared prover infrastructure, or shared validity sequencer [4] clusters. These protect chains against liveness issues when depending on other chain states or bundles.

The Polygon ecosystem prioritizes choice and sovereignty for chains. Chains can run their own modified execution environments, use their own tokens for staking and gas fees, choose their own data availability mechanisms, etc. Similarly, chains should decide how to handle tradeoffs between interoperability and the risk of liveness faults. There are several options:

1. Chain B can opt out of fast interoperability and the aggregator layer entirely. It can simply submit batches and proofs directly to Ethereum and finalization is never delayed.

2. Chain B can accept Chain A’s state only when Chain A’s state is confirmed by the AggLayer. Chain B will be delayed only if the AggLayer equivocates.

3. Chain B can accept Chain A’s state when Chain A is pre-confirmed by the AggLayer. Chain B will be delayed if the AggLayer equivocates or Chain A fails to produce a proof.

4. Chain B can accept Chain A’s state in a peer-to-peer setting, without checking that Chain A is pre-confirmed on the AggLayer. Chain B will be delayed if Chain A equivocates or fails to produce a proof.

An important thing to note is that users cannot cause liveness faults, only misbehaving or malfunctioning chains. Equivocation and the submission of an invalid block can be heavily penalized, either via slashing or by ejecting chains from the AggLayer and precluding their ability to seamlessly interoperate. Therefore, a liveness fault should be extremely rare.

Chains can take additional precautions to minimize the risk of liveness issues, by maintaining white- or blacklists of other chains with which they interoperate and setting limits on the number of chains that can be collectively involved in any batch. They could rely on third parties running full nodes to ensure that if a chain goes offline before it can produce a proof, there’s a backup prover.

The mechanism by which chains coordinate to accept atomic bundles is also flexible. For instance, a subset of chains could interoperate in a shared validity sequencing cluster for extremely low latency, or they could rely on relays.

A cryptoeconomically-secured relayer could enable interoperability between Chains A and B by running a full node for both chains, and attesting that states from each chain are valid. Even if Chain A or B pre-confirms a new batch and then goes offline, shared prover infrastructure can step in to generate a proof.

You can imagine novel coordination infrastructure emerging on top of the foundation of safety provided by the AggLayer, enabling new and better forms of interoperability and shared liquidity. Crucially, the entire Polygon ecosystem does not need to share the same infrastructure or trust assumptions. It doesn’t need to operate under a single shared validity sequencer or prover. This is an extremely important advantage relative to ORs.

Closing

The Aggregation Layer fundamentally allows us to create a multi-chain ecosystem that feels like using a single chain. It’s the synthesis of the monolithic and modular theses: unified state, liquidity, and composability, with the unbounded scalability of a multi-chain ecosystem.

Aggregation in ZK vs Optimistic Systems

This is a vision that is fundamentally only available to ZK-based systems. I’ll expand on this point in a future post, but Optimistic ecosystems that wish to enable fast interoperability must rely on shared validity sequencers. This is a bad deal for chains: it restricts them from redistributing sequencer fees and MEV, shared validity sequencers force chains to potentially accept restrictions on their execution environments, and interoperability in OR-based systems force chains to accept additional trust assumptions in exchange for low latency.

Further, cross-chain interoperability breaks an important property for ORs. With single-chain ORs, anyone can run a full node for an OR and immediately confirm that transactions are valid and finalized as soon as they’re posted to L1s. This is no longer true in the multi-chain case - now it’s necessary to run a full node for every chain with which the OR interoperates.

By contrast, Polygon’s vision is one where chains are sovereign. They can use any execution environment, can rely on any centralized or decentralized sequencers, and can navigate tradeoffs between cross-chain latency and liveness for themselves.

This is a vision that mirrors the existing Internet. The Internet is an elastically scalable, permissionless, and unified environment. Likewise, the AggLayer is scalable and permissionless - it imposes no restrictions on participating chains - and allows users to move assets and state seamlessly across the ecosystem, presenting a unified interface for the value layer of the Internet.

This is the future of Polygon: not monolithic, not fully modular, but aggregated.

[1] Part of ensuring unified liquidity is getting rid of the terrible UX of wrapped synthetic tokens on bridges. Users of Polygon’s LxLy bridge can seamlessly transfer assets across chains while preserving fungibility. However, in order to do this safely, we need to protect against weakest-link security - or an attacker corrupting a single chain and draining all funds across all chains in the bridge. I’ll discuss how to do this in a future post, but the AggLayer can leverage the proof aggregation step to enforce chain-level accounting, avoiding weakest-link security.

[2] When I reference atomic cross-chain transactions, what I mean is the ability for a user to submit a “bundle” or set of transactions across multiple chains. The atomic bundle has the property that its transactions are included in each relevant chain if and only if all transactions execute successfully. If a single transaction fails, then the bundle cannot be included on any chain.

The most basic example is again our cross-chain transfer. Let’s say that Alice wants to send 1 ETH to Bob, but Alice is on Chain A, and Bob is on Chain B. Assuming a shared native bridge for both rollups, Alice can burn her ETH on Chain A and mint ETH on Chain B which is transferred to Bob. But it’s critical to guarantee that she can’t mint ETH without burning it or vice-versa - either she could lose her ETH or under-collateralize the bridge.

This is why atomic transactions are so important. In order to allow low-latency interactions between chains and make using the Polygon ecosystem feel like using a single chain, atomic guarantees are needed.

[3] This is a subtle point, but from the perspective of the ecosystem - the AggLayer provides safety, but from the perspective of a single chain, this design prioritizes liveness over safety, as Chain B can depend on a chain state from Chain A that is invalid. In this case, Chain B will not be accepted by the AggLayer (enforced by the proof aggregation circuit) and will need to build a new block without the dependency on A.

[4] Our approach as a whole owes a lot to the Shared Validity Sequencing design from Umbra Research.

2/9/24 - Updated this draft to clarify some comparisons between aggregation and shared sequencing. The aggregated thesis depends on mechanisms like shared sequencers, relays, and builders to facilitate coordination between chains. The agg layer in turn guarantees safety.

This debate is meaningful because Optimium chains, particularly Arbitrum AnyTrust chains like Arbitrum Nova, are in production and described as L2s. This post will argue that AnyTrust chains have equivalent security to sidechains by constructing a sidechain design that offers the same security properties as AnyTrust.

My view is that the core problem with sidechains is that validators can collude to directly steal user funds. In this sense, any design that allows any number of colluding validators to steal funds is as insecure as a sidechain. But - reasonable people disagree, so this argument will go further and aim to show that Optimium/AnyTrust offers the same safety and liveness guarantees as a sidechain.

Preliminaries

We care about two properties when we talk about security: safety and liveness.

Safety: no two nodes have a conflicting view of the state of the chain (in the L2 context, the state cannot be the result of the invalid execution of a transaction)

Liveness: a subset of malicious validators cannot indefinitely delay the chain.

Safety guarantees that user funds cannot be stolen by the operators of a chain, while liveness guarantees that user funds cannot be held hostage by the operators of a chain. These properties are typically framed in terms of a threshold; for example, if >2/3 of nodes are honest, safety is guaranteed.

Sidechain Security

On a sidechain, a set of validators process transactions outside of the main L1 chain. Existing sidechains require >2/3 of validator signatures (weighted by stake) for each new block.

This means that >2/3 of validators can collude and steal user funds, simply by producing an invalid block of transactions (fraudulently minting enough tokens to drain the bridge, stealing funds from a user without a signature, etc). This is a safety failure.

1/3 of validators can prevent the chain from progressing by withholding signatures, while 2/3 can launch a data withholding attack. These are liveness failures.

AnyTrust Design

AnyTrust is described in more detail here. It’s easy to understand in contrast to an Optimistic Rollup (OR). On an OR, all transaction data is posted to L1, so anyone can recover the latest state of the chain and create a fraud proof if the claimed state of the OR is invalid.

On an AnyTrust chain, a Data Availability Committee (DAC) attests that all transaction data is available. The DAC is permissioned, with members chosen by governance. AnyTrust requires that N-1 members of the DAC attest that data is available in each block. This means that as long as 2 members of the DAC are honest, we have a strong guarantee that data cannot be withheld from users and funds are safe.

Conversely, if N-1 members of the DAC are malicious, they can steal user funds directly by colluding with the sequencer. Data must be available to create a fraud proof, so the sequencer could include an invalid block (say, minting 1b ETH), as long as the DAC withholds data during the challenge period, and then drain the bridge.

If < N-1 members of the DAC attest that block data is available, then the AnyTrust chain converts to an optimistic rollup and posts data on L1.

The Argument for AnyTrust Security

The argument that AnyTrust is more secure than a Sidechain has two parts.

1. Stealing funds from a sidechain requires corrupting 2/3N + 1 validators, but stealing funds from an AnyTrust chain requires corrupting N-1 validators, so it is more secure for N>6.

2. AnyTrust has better liveness properties, in that it can continue operating as a rollup if members of the DAC go offline. The liveness threshold is 2/N, vs 2/3 N for a sidechain.

But rather than debating these points ad nauseam, if we can construct a sidechain that has the same liveness and safety guarantees as an AnyTrust chain, then we will have shown that AnyTrust has the same security as a sidechain. Let’s do so.

A Sidechain Equivalent to AnyTrust

Sidechains have traditionally inherited their assumptions about honesty thresholds from the BFT literature. But as Daniel Lubarov observed, they don’t have to. Sidechains inherit finality from the L1, just as rollups or AnyTrust chains do.

Therefore, we can build a sidechain that requires N-1 approvals, just like AnyTrust. In fact, we can have an analogous setup to AnyTrust, with a sequencer and a Validity Committee (with permissioned membership, like AnyTrust) that attests that blocks are valid. We require N-1 approvals from the Validity Committee for each block to be accepted by the L1, so funds are safe if 2 members of the committee are honest.

This construction gives an identical safety guarantee to AnyTrust chains because the threshold for safety is the same: 2/N.

Now let’s address liveness. We can add a recovery mechanism similar to AnyTrust, but instead of rollup mode, chain governance simply replaces validators that are unavailable for a long period. I can hear the complaints already, but hear me out.

In AnyTrust, membership in the DAC is permissioned. Governance initially selects the members of the committee and can add or replace members. Therefore, relying on governance to change the committee doesn’t introduce new trust assumptions[1], especially if governance also controls the bridge contracts for AnyTrust chains.

As long as 2/N validators are honest, block data cannot be withheld and the sidechain will not halt indefinitely. Therefore, this construction gives an identical liveness guarantee to AnyTrust chains because the threshold for liveness is the same: 2/N.

This recovery mechanism is arguably superior to AnyTrust because rollup mode forces users to wait for seven days to exit assets like NFTs. For high-usage chains, users might not be able to exit via L1, whereas governance recovery would allow the chain to continue operating after a short time. Governance can select validators with 99.99% uptime, so users should not be impacted by outages.

Debating Trust Assumptions

We’ve given a construction of a sidechain that has 2/N liveness and safety. This construction has equivalent security to AnyTrust as long as it doesn’t rely on additional trust assumptions.

A counterargument that AnyTrust relies on fewer trust assumptions is the following:

The sidechain scheme depends on governance to ensure liveness, but this isn’t necessarily the case for AnyTrust. An “ungoverned” AnyTrust chain can be created, such that governance cannot change members of the DAC after the committee is set. In this case, AnyTrust can recover from a liveness failure without any intervention from governance, whereas the sidechain cannot.

I think that this argument is valid as stated, but in practice, AnyTrust chains will always be “governed.” We aren’t debating the security of AnyTrust as an abstract technology, but rather the security of the AnyTrust chains that will be deployed. There should be a mechanism to rotate keys and committee members on the DAC, controlled by governance, as described here. Without the ability to rotate the committee, there’s a high risk that the chain will be permanently stuck in rollup mode.

Therefore, given that the design of AnyTrust explicitly allows for governance to change committee members, the sidechain construction that we’ve described has identical safety and liveness thresholds as AnyTrust, without any additional trust assumptions.

Another natural response is:

Polygon zkEVM or [insert rollup here] still relies on a multisig for upgrades or accepts governance upgrades without a timelock. Shouldn’t the argument that governance can replace proofs apply equally to those chains?

The crucial difference is that existing rollups have training wheels that protect users until the underlying technology is battle-tested. However, these training wheels are temporary, whereas AnyTrust chains must permanently allow governance to rotate members of the committee; otherwise, if any two members of the committee became unavailable or lost access to their keys, the chain would permanently become a rollup.

Improving AnyTrust

If we’ve successfully shown that AnyTrust is equivalent in security to a sidechain, then it’s fair to say that much of its design is security theater that unnecessarily penalizes users. For example, users are required to wait for the full seven day challenge period to withdraw from the native bridge. This leads to capital inefficiency and duration risk.

Fraud proofs are supposed to guarantee “single-honest-party” safety - meaning that as long as one person in the entire world is honest and able to construct fraud proofs, user funds are safe. However, AnyTrust only has 2/N safety, where N is likely << 100. Therefore, fraud proofs don’t contribute to AnyTrust security in DAC mode.

We can create a better version of AnyTrust by simply accepting that it is a sidechain. We can rename the DAC to “Validity Committee”, and require validators to attest to the validity of execution rather than just data availability. We can completely get rid of fraud proofs and the challenge period, without any additional security assumptions.

Closing

There is nothing inherently wrong with sidechains. The Polygon PoS chain is a sidechain that has filled an essential scaling need for Ethereum. Moreover, sidechains might offer the best tradeoff between cost and security for some apps, like games.

However, the Ethereum community has collectively decided that sidechains are not L2s, and there are other designs that offer greater security at similar cost.

For example, a Validium offers the same cost-savings in off-chain data availability as an Optimium but with greater security. Optimiums require data availability for both safety and liveness (data must be available to construct a fraud proof), but validiums require data to be available only for liveness; safety is guaranteed by a zero-knowledge proof.

These discussions are important because they inform how chain infrastructure is built in the future. Do we want to accept permissioned validator sets and sidechain security, or do we want to build solutions that offer low cost and higher security, protected by cryptography? These are substantive conversations that are worth having in a respectful and considered way.

[1]: An objection here is the following:

AnyTrust can impose a governance delay, such that users can exit the chain in rollup mode via forced transactions before the committee changes. Sidechains cannot support forced transactions.

The sidechain can be modified to impose a governance delay and allow users to force-exit the chain via simulated transactions on Ethereum. Users could provide a merkle path for their account balance and a signature (or a ZKP) and immediately withdraw funds. This scheme could even support simulating more complicated transactions on Ethereum. Note that for the purposes of this argument, it suffices only to show that the sidechain offers the same liveness guarantee as AnyTrust, which it does.

Thanks to Daniel Lubarov for providing feedback on an early draft of this post.