Architecture

The Polygon 2.0 architecture is formalized as a collection of protocol layers, designed to operate together. The most prominent example of such layered architecture is likely the Internet protocol suite, with its four layers (Link, Network, Transport and Application Layer) that power the Internet. Each of the protocol layers facilitates a specific sub-process, and this logical separation simplifies reasoning, implementation and upgrades of the architecture.

Polygon 2.0 consists of four protocol layers, each enabling an important process within the network:

The Staking Layer is a PoS (Proof-of-Stake) based protocol which leverages Polygon’s native token to provide decentralization to participating Polygon chains. It achieves that via a common, highly decentralized validator pool and an in-built restaking model.

The Staking Layer is implemented on Ethereum via two types of smart contracts:

Chain Manager contracts manage validator sets of individual Polygon chains. Every Polygon chain has its Chain Manager contract, performing the following functions:

The AggLayer facilitates secure and seamless cross-chain messaging within the Polygon ecosystem. It abstracts the complexity of cross-chain communication and makes the whole Polygon network feel like a single chain to users, by enabling:

Shared access to native Ethereum assets: Cross-chain bridges typically require users to mint synthetic versions of Ethereum tokens – a UX nightmare. The AggLayer offers a shared bridge to Ethereum and allows seamless cross-chain transfers of native Ethereum assets. Seamless composability: The AggLayer can support near-instant and atomic cross-chain transactions, a core part of the vision of unified liquidity of Polygon 2.0. The AggLayer expands on the design of the LxLy protocol, currently used by Polygon zkEVM rollup, and its concept of Message Queues. Every Polygon chain maintains a local queue of outbound messages in a predefined format, which are included in ZK proofs that the chain generates. Once the ZK proof referring to a specific queue gets verified on Ethereum, any message from the queue can be safely consumed by its recipient chain and address.

Using this design as the foundation, we propose to introduce a one-of-a-kind Aggregator component to further improve cross-chain transactions, making them near-instant and atomic. The Aggregator positions itself between Polygon chains and Ethereum and provides two services:

Once ZK proofs are accepted by the Aggregator, the recipient chains can start optimistically accepting inbound messages (knowing that the eventual and global consistency is guaranteed by ZK proofs), which makes cross-chain interactions seamless. By aggregating ZK proofs, the Aggregator dramatically reduces Ethereum gas consumption for proof verification.

To ensure liveness and censorship resistance, the Aggregator should be operated in a decentralized manner, by Polygon validators from the aforementioned common validator pool.

The Execution Layer enables any Polygon chain to produce sequenced batches of transactions, aka blocks. This protocol layer is relatively commoditized; it is used in a similar format by most blockchain networks (Ethereum, Bitcoin, etc.).

The Execution Layer has multiple components, such as:

Given that this layer is commoditized, yet relatively complex to implement, existing performant implementations (e.g. Erigon) should be reused to the maximum extent possible.

The Proving Layer is a highly-performant, flexible ZK proving protocol. It generates proofs for all transactions – internal and external (i.e. cross-chain) – for every Polygon chain.

The Proving Layer has the following components:

Common prover: Highly performant ZK prover, developed by Polygon’s ZK researchers as the successor of Plonky2, a recursive SNARK which itself pushed the boundaries of proving efficiency by two orders of magnitude and demonstrated the expertise of Polygon’s ZK team. The prover offers a clean interface, designed to support arbitrary transaction types, i.e. state machine formats. Additionally, using a single prover makes proof aggregation and verification straightforward and very efficient. (Optional) State machine constructor: A framework for defining state machines, developed by Polygon’s ZK researchers as the successor of PIL, the framework used to build the initial Polygon zkEVM implementation. Constructor abstracts the complexity of the proving mechanisms and allows developers to construct state machines through an easy-to-use interface. It is modular; allows developers to define parameterizable state machines, making it easier to build, test and audit even large and complex state machines. State machine: The simulation of the execution environment and transaction format that is being proven by the prover. State machines can be implemented using the aforementioned constructor or completely custom, e.g. using Rust. Polygon’s ZK teams offer two state machine implementations – zkEVM and MidenVM – and additional ones (e.g. zkWASM) can be built by the community.

The novel design of the Proving Layer offers several major benefits, namely: