Today, Polygon Labs’ engineering teams are sharing a proposed architecture for Polygon 2.0, designed to provide unlimited scalability and unified liquidity, and realize the vision of Polygon as the Value Layer of the Internet.

For its entire history, Web3 has faced an intractable scaling problem. Although new chains can continuously be added to meet demand for blockspace, this inevitably comes at a cost: fragmented liquidity and poor user experience.

Polygon 2.0 is the solution. Just like the Internet is an elastically scalable, unified environment for accessing information, Polygon 2.0 is an elastically scalable, unified environment for accessing value: the Value Layer of the Internet.

We believe this proposal can and should direct all Polygon protocol development efforts moving forward, serving both as the conceptual North Star and the formal development framework.

Since the inception of Polygon, its developers and community have embraced the ethos of experimentation. Rather than trying to predict the future and bet on a single approach, multiple paths to building next-gen blockchain infrastructure were actively encouraged. This aligns with the typical process of creative problem solving where a divergence phase of exploring many ideas and approaches is followed by a convergence phase where those ideas and approaches consolidate and produce a solution to a problem. Given that blockchain is a young, very dynamic industry, this approach was an obvious choice.

In the initial, divergence phase, Polygon developer teams experimented across the entirety of the tech stack. Just to mention a few of these efforts:

• Various blockchain architectures: sidechains, rollups, validiums, etc.;

• Multiple approaches to building ZK-powered execution environments: zkEVM type 1-3, Polygon Miden;

• Multiple blockchain clients: Polygon Edge, existing Ethereum clients and custom built clients like the one currently used by Polygon zkEVM rollup;

• Various solutions for other parts of the stack, e.g. cross-chain messaging, staking, etc.

This phase was incredibly useful; various approaches and technologies were tried and a lot of important lessons were learned. It was time to start filtering and consolidating ideas and efforts.

During the convergence phase, Polygon protocol teams and contributors gradually aligned on the specific protocol architecture, i.e. tech stack, which we are now excited to present as the optimal infrastructure for the Value Layer of the Internet.

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:

• Staking Layer

• Interop Layer

• Execution Layer

• Proving Layer

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:

Validator Manager: Validator Manager is a smart contract that manages the common validator pool that can be leveraged by all Polygon chains. It performs the following operations:

• Maintains the registry of validators;

• Processes staking and unstaking requests by validators;

• Allows validators to subscribe, i.e. restake to an arbitrary number of Polygon chains;

• Processes slashing events.

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

• Defines the required level of decentralization, i.e. number of validators;

• (Optional) Defines additional requirements for validators (e.g. GDPR compliance, stake in another token in addition to Polygon’s native token, etc.);

• (Optional) Defines slashing conditions.

As mentioned above, the Staking Layer offers Polygon chains decentralization “out of the box,” thus enabling these chains’ teams to focus on use case and community rather than infrastructure. To validators, it offers guaranteed rewards in Polygon tokens, as well as an opportunity for additional revenue streams via collecting transaction fees and additional token rewards from chains they validate.

‍

The Interop Layer 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 Interop Layer offers a shared bridge to Ethereum and allows seamless cross-chain transfers of native Ethereum assets.

• Seamless composability**:** The Interop Layer can support near-instant and atomic cross-chain transactions, a core part of the vision of unified liquidity of Polygon 2.0.

The Interop Layer 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:

• Accepts ZK proofs and Message Queues' representations (e.g. Merkle roots);

• Aggregates ZK proofs into a single ZK proof and submit it to Ethereum for verification.

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:

• P2P: Enables nodes (validators and full nodes) to discover each other and exchange messages;

• Consensus: Enables validators to reach agreement on a single worldview, i.e. chain of blocks;

• Mempool: Collects transactions submitted by users and syncs them between validators;

• Database: Stores transaction history;

• Witness generator: Generates witness data required by ZK prover.

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:

• Efficient proof generation and verification;

• Straightforward and efficient proof aggregation;

• Implementation of different ZK state machines;

• Safe cross-chain communication between those state machines.

In the coming days and weeks, we will be sharing deep dives into the Polygon 2.0 protocol layers. We will explore how each of them works on a lower level, and how together they form a unique, optimal architecture for the Value Layer of the Internet.

As always, we invite the community to review this proposal and upcoming deep dives and provide feedback. Let’s make Polygon 2.0 happen!

Website | Twitter | Developer Twitter | Forum | Telegram | Reddit | Discord | Instagram | Facebook | LinkedIn

Today, Polygon Labs’ engineering teams are sharing a proposed architecture for Polygon 2.0, designed to provide unlimited scalability and unified liquidity, and realize the vision of Polygon as the Value Layer of the Internet.

For its entire history, Web3 has faced an intractable scaling problem. Although new chains can continuously be added to meet demand for blockspace, this inevitably comes at a cost: fragmented liquidity and poor user experience.

Polygon 2.0 is the solution. Just like the Internet is an elastically scalable, unified environment for accessing information, Polygon 2.0 is an elastically scalable, unified environment for accessing value: the Value Layer of the Internet.

We believe this proposal can and should direct all Polygon protocol development efforts moving forward, serving both as the conceptual North Star and the formal development framework.

Since the inception of Polygon, its developers and community have embraced the ethos of experimentation. Rather than trying to predict the future and bet on a single approach, multiple paths to building next-gen blockchain infrastructure were actively encouraged. This aligns with the typical process of creative problem solving where a divergence phase of exploring many ideas and approaches is followed by a convergence phase where those ideas and approaches consolidate and produce a solution to a problem. Given that blockchain is a young, very dynamic industry, this approach was an obvious choice.

In the initial, divergence phase, Polygon developer teams experimented across the entirety of the tech stack. Just to mention a few of these efforts:

• Various blockchain architectures: sidechains, rollups, validiums, etc.;

• Multiple approaches to building ZK-powered execution environments: zkEVM type 1-3, Polygon Miden;

• Multiple blockchain clients: Polygon Edge, existing Ethereum clients and custom built clients like the one currently used by Polygon zkEVM rollup;

• Various solutions for other parts of the stack, e.g. cross-chain messaging, staking, etc.

This phase was incredibly useful; various approaches and technologies were tried and a lot of important lessons were learned. It was time to start filtering and consolidating ideas and efforts.

During the convergence phase, Polygon protocol teams and contributors gradually aligned on the specific protocol architecture, i.e. tech stack, which we are now excited to present as the optimal infrastructure for the Value Layer of the Internet.

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:

• Staking Layer

• Interop Layer

• Execution Layer

• Proving Layer

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:

Validator Manager: Validator Manager is a smart contract that manages the common validator pool that can be leveraged by all Polygon chains. It performs the following operations:

• Maintains the registry of validators;

• Processes staking and unstaking requests by validators;

• Allows validators to subscribe, i.e. restake to an arbitrary number of Polygon chains;

• Processes slashing events.

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

• Defines the required level of decentralization, i.e. number of validators;

• (Optional) Defines additional requirements for validators (e.g. GDPR compliance, stake in another token in addition to Polygon’s native token, etc.);

• (Optional) Defines slashing conditions.

As mentioned above, the Staking Layer offers Polygon chains decentralization “out of the box,” thus enabling these chains’ teams to focus on use case and community rather than infrastructure. To validators, it offers guaranteed rewards in Polygon tokens, as well as an opportunity for additional revenue streams via collecting transaction fees and additional token rewards from chains they validate.

‍

The Interop Layer 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 Interop Layer offers a shared bridge to Ethereum and allows seamless cross-chain transfers of native Ethereum assets.

• Seamless composability**:** The Interop Layer can support near-instant and atomic cross-chain transactions, a core part of the vision of unified liquidity of Polygon 2.0.

The Interop Layer 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:

• Accepts ZK proofs and Message Queues' representations (e.g. Merkle roots);

• Aggregates ZK proofs into a single ZK proof and submit it to Ethereum for verification.

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:

• P2P: Enables nodes (validators and full nodes) to discover each other and exchange messages;

• Consensus: Enables validators to reach agreement on a single worldview, i.e. chain of blocks;

• Mempool: Collects transactions submitted by users and syncs them between validators;

• Database: Stores transaction history;

• Witness generator: Generates witness data required by ZK prover.

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:

• Efficient proof generation and verification;

• Straightforward and efficient proof aggregation;

• Implementation of different ZK state machines;

• Safe cross-chain communication between those state machines.

In the coming days and weeks, we will be sharing deep dives into the Polygon 2.0 protocol layers. We will explore how each of them works on a lower level, and how together they form a unique, optimal architecture for the Value Layer of the Internet.

As always, we invite the community to review this proposal and upcoming deep dives and provide feedback. Let’s make Polygon 2.0 happen!

Website | Twitter | Developer Twitter | Forum | Telegram | Reddit | Discord | Instagram | Facebook | LinkedIn