Polygon 2.0: Protocol Vision and Architecture

Polygon 2.0: Vision and Architecture

Author: Polygon Compiled by: Plain-language Blockchain

Today, Polygon Labs’ engineering team is sharing the proposed architecture of Polygon 2.0, which aims to provide infinite scalability and unified liquidity, and to achieve Polygon’s vision as the internet’s value layer.

Throughout its history, Web3 has always faced tricky scaling issues. Although new chains can be continually added to meet the needs of block space, this inevitably comes at a cost: fragmented liquidity and poor user experience.

Polygon 2.0 is the solution. Just as the internet is a flexible, unified information access environment, Polygon 2.0 is also a flexible, unified value access environment: the value layer of the internet.

• Polygon 2.0: Providing Infinite Scalability and Unified Liquidity
• Will OP+ZK Hybrid Rollup become the ultimate future of Ethereum sca...
• Exploring the Applications of Artificial Intelligence in the Financ...

We believe that this proposal can and should guide all Polygon protocol development work going forward, both as a conceptual North Star and as a formal development framework.

Background: Divergence and Convergence

Since its inception, the developers and community of Polygon have been guided by an experimental spirit. We actively encourage multiple pathways to building the next generation of blockchain infrastructure, rather than trying to predict the future and bet on a single method. This is consistent with the typical process of creative problem-solving, in which the divergence phase of exploring many ideas and methods is followed by the convergence phase, in which these ideas and methods are consolidated and produce solutions to problems. Given that blockchain is a young and very dynamic industry, this approach is an obvious choice.

In the initial divergence phase, the Polygon development team experimented across the entire technology stack. Just a few of the efforts:

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

• Multiple methods for building ZK-supporting execution environments: zkEVM types 1-3, Polygon Miden

• Multiple blockchain clients: Polygon Edge, existing Ethereum clients, and custom clients such as the one currently used for Polygon zkEVM rollups

• Various solutions for other parts of the stack, such as cross-chain message passing, staking, etc.

This stage was very useful. Various methods and techniques were tried and many important lessons were learned. It’s time to start filtering and integrating ideas and efforts.

In the fusion phase, the Polygon protocol team and contributors gradually converge on a specific protocol architecture (i.e. technology stack), which we are now pleased to present as the best infrastructure for the Internet of Value.

Protocol Architecture

The Polygon 2.0 architecture is formalized as a collection of protocol layers designed to work together. The most prominent example of this layered architecture is perhaps the Internet Protocol Suite, whose four layers (link layer, network layer, transport layer, and application layer) power the Internet. Each protocol layer has a specific sub-process, and this logical separation simplifies the reasoning, implementation, and upgrade of the architecture.

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

• Staking layer

• Interoperability layer

• Execution layer

• Verification layer

Staking Layer

The staking layer is a PoS (Proof of Stake)-based protocol that leverages Polygon’s native token to provide decentralization for participating Polygon chains. It achieves this goal through a common, highly decentralized validator pool and a built-in re-staking model.

The staking layer is implemented on Ethereum via two types of smart contracts:

Validator Manager: The Validator Manager is a smart contract used to manage the public validator pool that all Polygon chains can utilize. It performs the following operations:

• Maintains the registration of validators;

• Processes requests for validator staking and unstaking;

• Allows validators to subscribe, i.e. re-stake to any number of Polygon chains;

• Processes slashing events.

Chain Manager: The Chain Manager contract manages the validator set for each Polygon chain. Each Polygon chain has its own Chain Manager contract, which performs the following functions:

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

• (Optional) Define additional requirements for validators (e.g., GDPR compliance, holding other tokens besides the Polygon native token);

• (Optional) Define slashing conditions.

As described above, the Stake Layer provides out-of-the-box decentralization for Polygon chains, enabling teams building on these chains to focus on use cases and communities rather than infrastructure. For validators, it provides guaranteed rewards in Polygon tokens, as well as opportunities to earn additional income streams by collecting transaction fees and extra token rewards from the chains they validate.

Interoperability Layer

The interoperability layer facilitates secure, seamless cross-chain messaging within the Polygon ecosystem. It abstracts the complexity of cross-chain communication and makes the entire Polygon network appear to users as if it were one chain, 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 interoperability layer provides a shared bridge to Ethereum and allows for seamless cross-chain transfer of native Ethereum assets.

• Seamless composability: The interoperability layer can support near-instant atomic cross-chain transactions, which are a core part of the Polygon 2.0 unified liquidity vision.

The interoperability layer builds on the design of the LxLy protocol currently used by the Polygon zkEVM rollup and its concept of message queues. Each Polygon chain maintains a local outbound message queue in a pre-defined format, containing: the message (a digital asset, i.e., a token or arbitrary message), the target chain, the target address, and metadata. The message queue has a corresponding ZK proof. Once a ZK proof referencing a particular queue is validated on Ethereum, any messages from that queue can be securely used by their receiving chain and address.

Building on this design, we propose the introduction of a unique Aggregator component to further improve cross-chain transactions, making them near-instant and atomic. The Aggregator is positioned between Polygon chains and Ethereum and provides two services:

• Accepts representations of ZK proofs and message queues (e.g., Merkle roots);

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

Once a ZK proof is accepted by the aggregator, the receiving chain can begin optimistically accepting inbound messages (knowing that final global consistency is ensured by the ZK proof), making cross-chain interactions seamless. By aggregating ZK proofs, the aggregator greatly reduces the Ethereum gas consumption used for proof verification.

To ensure liveness and censorship resistance, the aggregator should be run in a decentralized manner by Polygon validators from the aforementioned public validator pool.

Execution Layer

The execution layer enables any Polygon chain to generate batches of ordered transactions, also known as blocks. This protocol layer is relatively commoditized; most blockchain networks (Ethereum, Bitcoin, etc.) use it in a similar format.

The execution layer has multiple components, such as:

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

• Consensus: Enables validators to agree on a single worldview (i.e., the blockchain);

• Mempool: Collects user-submitted transactions and synchronizes them among validators;

• Database: Stores transaction history;

• Witness Generator: Generates witness data required by ZK provers.

Given that this layer is commoditized but relatively complex to implement, existing high-performance implementations (such as Erigon) should be reused wherever possible.

Verification Layer

The proof layer is a high-performance, flexible ZK proof protocol. It generates proofs for all transactions (internal and external [i.e., cross-chain]) of each Polygon chain.

The proof layer has the following components:

• General Purpose Prover: A high-performance ZK prover developed by Polygon’s ZK researchers as a successor to Plonky2, a recursive SNARK that itself pushed the boundaries of proof efficiency by two orders of magnitude and showcased the expertise of the Polygon ZK team. The prover provides a clean interface aimed at supporting any transaction type, i.e., state machine format. Additionally, using a single prover makes proof aggregation and verification simple and extremely efficient.

• (Optional) State Machine Constructor: Used to define the framework of the state machine, developed by Polygon’s ZK researchers as a successor to PIL, the framework used to build the initial Polygon zkEVM implementation. The constructor abstracts the complexity of the proof mechanism and allows developers to construct state machines through an easy-to-use interface. It is modular; it allows developers to define parameterizable state machines, making it easier to build, test, and audit large and complex state machines.

• State Machine: A simulation of the execution environment and transaction format that the prover is proving. The state machine can be implemented using the above construction function or can be completely customized, such as using Rust. Polygon’s ZK team provides two state machine implementations – zkEVM and MidenVM – and the community can build other state machine implementations (such as zkWASM).

The proof layer and its high-performance, flexible provers offer several key benefits, including (i) simple and efficient proof generation, aggregation, and verification, and (ii) cross-chain communication between different state machines.

Looking Ahead

In the coming days and weeks, we will dive deeper into the Polygon 2.0 protocol layers. We will explore how they each work at a lower level and how they collectively form the unique and optimal architecture of the internet of value layer.

As always, we invite the community to review this proposal and the upcoming in-depth research and provide feedback. Let’s build Polygon 2.0 together!

• Polygon