PIP-18: Polygon 2.0 Phase 0 - Frontier

Polygon Improvement Proposals Canonical PIPs
1

PIP-18: Polygon 2.0 Phase 0 - Frontier

Authors: David Schwartz, Mihailo Bjelic, Mudit Gupta, Grace Torrellas, Mateusz Rzeszowski, Daniel Gretzke, David Silverman, Paul Gebheim

Type: Informational

Table of Contents:

  • Abstract
  • Motivation
  • Definitions
  • Specification
    • Frontier Roadmap
  • Security Considerations
  • Backward Compatibility

Abstract

This proposal specifies Phase 0 of Polygon 2.0, a multi-phased upgrade to the Polygon Ecosystem. In Phase 0, the functioning of Polygon PoS and Polygon zkEVM are entirely unaffected for end users. Multiple changes are proposed to be implemented in the system smart contracts of these chains on Ethereum. In an homage to the original Ethereum release, we propose calling this initial phase of changes, “Frontier”.

The core of the proposed changes are:

  1. The initiation of the POL upgrade
  2. The upgrade from MATIC to POL as the native (gas) token for PoS
  3. The adoption of POL as the staking token for Polygon PoS
  4. The launch of the Staking Layer and migration of Polygon public chains to consequently leverage it

We propose a high-level outline for these changes, which should be deployed incrementally, with further detail on each coming through separate proposals to be published for community review.

Motivation

Polygon 2.0 envisions a network of interconnected ZK-powered L2 chains that, on aggregate, expand Ethereum blockspace and create the Value Layer of the Internet. This environment is seamlessly interoperable, offering access to unified blockspace across all Polygon chains as well as infinite scalability.

The end goal is to extend Ethereum blockspace in a fashion that more resembles a mesh network topology like the internet. With ZK technology, Ethereum blockspace can scale to the size of the Internet for the first time in blockchain history.

From the start, the Polygon ecosystem has been committed to sustainably scaling Ethereum, bringing the idea of credibly neutral, decentralized blockchains to developers of all skill levels, while also ensuring that these blockchains remain cheap and accessible for all users.

This proposal represents the next step in this journey, defining the initial tasks to bring the Polygon 2.0 vision to life.

Specification

Phase 0 is specifically designed to ensure that there will be no required changes for end users and developers already on the PoS or zkEVM chains. All proposed adjustments are targeted toward the various contracts and systems controlling the Polygon 1.0 ecosystem on Ethereum.

The following milestones will make up Phase 0:

POL Upgrade

  • Initiate upgrade of POL, a technical upgrade to MATIC, designed to power the Polygon 2.0 ecosystem.
  • Adopt POL as the native (gas) token for Polygon PoS. This will be accomplished by an upgrade to the Plasma Bridge, changing the MATIC withdrawal logic to only output POL.
  • Adopt POL as the staking token for Polygon PoS.
  • Upgrade the Polygon PoS validator rewards from MATIC to POL.

Staking Layer

  • Launch the Staking Layer, a series of smart contracts that enable validators in the Polygon ecosystem to use their stake to participate in multiple services across the Polygon 2.0 ecosystem such as Validation, Sequencing, Proving, and Data Availability services for a variety of chains.
  • Migrate Polygon PoS staking and validation to a new service on the Staking Layer.
  • Migrate validator rewards from the legacy Polygon PoS staking contract to the new PoS Staking Layer service.

1600Ă—583 103 KB

Backward Compatibility

This proposal seeks to lay out a roadmap that includes backwards incompatibility through the introduction, deprecation, and modification of Polygon system smart contracts on the Ethereum mainnet. As a result, this proposal covers a proposed order of operations and directly informs the creation of future PIPs to implement the functionality laid out in the “Specification” section. Relevant parties should carefully consider the changes laid out in this post, and monitor the eventual PIPs detailing them further to be prepared for any incompatibilities that will be introduced.

Security Considerations

Polygon 2.0 is a significant technical upgrade of the Polygon system with broadscale changes to the PoS network, as well as the introduction of several novel systems. There are inherent risks in this migration, however, each component will undergo extensive testing, auditing, and public scrutiny prior to activation. The staging of the PIPs and the methodical, piecemeal upgrade of the system is intended to ensure there is sufficient time for testing, auditing and scrutiny.

References

Copyright

All copyrights and related rights in this work are waived under CC0 1.0 Universal.

14 Likes
4

I’m looking forward to see this becoming a reality. The plan as it is, is perfect to me!

1 Like
5

I support the update if it will increase the security of the blockchain and make it more recognizable

1 Like
6

Hello,

It’s great to see this transition taking shape! I have a few questions:

-On the infrastructure front, can operators select the type of infrastructure they wish to run?

-Regarding data availability and composability: If chains choose to publish data into different services, they can still achieve compatibility as long as they share the same Ethereum L1 contracts, the same prover, and the same zk circuits, right?

-I presume one of the primary challenges might be the sequencer’s speed (i.e having one sequencer for all these chains would not be optimal). To solve this bottleneck, can these chains opt for a shared sequencer or even develop their own, while maintaining compatibility with other Polygon chains?

Looking forward to your insights. Thanks!

1 Like
7

yes, a staker will be able to chose which services they want to operate

I’m not sure I’m understanding the question right but essentially the chains will utilise the same prover and circuits but every chain has their own contracts on L1. They will be still interoperable as long as they use our prover and circuits.

The type of sequencer depends on the use case of the network. A centralised entity that needs a network for their app, probably doesn’t need a decentralised sequencer network and can work with a centralised sequencer or can use a shared sequencer. We intend this to be flexible while maintaining interoperability with other networks in the ecosystem.

2 Likes
8

As the new staking layer will be out, what will happen to the existing Heimdall Layer of Polygon PoS?

9

Hey @gretzke

Can the swap be operated while MATIC is still staked with a validator?

Also, how should infrastructure providers get ready for this upgrade? Is the swap contract ready? We have users asking about timelines.

Thank you!

10

No, you would need to withdraw your MATIC to migrate, however, POL cannot be staked or delegated to a staker right now, so if you chose to withdraw and migrate, you won’t be able to restake. Staking with POL will come at a later point in time, until then there is no immediate need to migrate to POL.

The contracts are going live in the upcoming days, but no action is really necessary at this point in time.

11

do you have any rough estimates of when the actual functions of MATIC (staking, gas token etc.) will be switched to POL after todays contract launch?

12

Can’t wait for the future development! Awesome network and community!

1 Like
13

At this stage, early next year. More defined timelines and dates will be provided when they are scheduled.

14

Congrats on the hard work, seems like a great pathway forward!

I’m curious if staking layer will be managed by the existing polygon validator set, or if there will be a different set of rules that apply to being able to join the network as a node operator? The only other information I could find maybe tangential is in PIP-26

15

May I ask if the MATIC on the Plasma Bridge and Staking Contract will be migrated gradually or in one go once Phase 1/2 arrives?