Pre-PIP Discussion: Upgrading Polygon PoS to a zkEVM Validium

Introduction

With this post, we invite the community to discuss a proposal for a major upgrade of the Polygon PoS chain – shifting from the current architecture to a zkEVM validium.

We cover the current challenges Polygon PoS is facing, explain zkEVM validium as a solution and its benefits, describe the technical details, as well as potential timelines. We also touch on other relevant aspects, such as user, application and validator requirements, continuous utility of $MATIC, impact on transaction fees and positioning/comparison with the Polygon zkEVM rollup.

Given the major impact on chain security and multiple implicit benefits, we conclude that this upgrade can be pivotal for Polygon PoS in terms of addressing its challenges, preserving relevance and improving its value proposition.

Current Challenges

With 300M+ unique addresses, $2B+ assets bridged from Ethereum and tens of thousands of apps, Polygon PoS is still one of the most used chains not only in the Polygon ecosystem but all of Web3. Many users and developers prefer it because of its strong ecosystem, network effects and very low fees, oftentimes orders of magnitude lower than prominent Ethereum L2s. However, multiple challenges can be observed, mainly tied to its architecture:

  • Security model: Polygon PoS and its canonical bridge to Ethereum are secured by a set of 100 validators with ~$2B worth of $MATIC staked. Even though this offers a significant level of decentralization and economic security, recent advanced L2 technologies, such as Polygon’s zkEVM, can go a step further and fully inherit significantly higher security of Ethereum.
  • Legacy tech stack: The Polygon PoS tech stack relies on forks of Cosmos SDK and Geth. Maintaining these forks is suboptimal given the amount of work required and the existence of more advanced L2 technologies, such as Polygon’s zkEVM.
  • UX issues: Polygon PoS uses a probabilistic consensus algorithm which has occasionally experienced relatively deep chain reorgs. Additionally, fast block times decrease efficiency of the gas estimation model, occasionally causing gas price spikes.

Despite the current level of usage and significance of Polygon PoS for the ecosystem, these challenges pose concerns around its long-term relevance and reliability.

Proposed Solution

Having stated the above challenges, we propose a major upgrade to Polygon PoS to turn it into a zkEVM validium. We believe this upgrade can either fully address or open the path to addressing all of the aforementioned challenges Polygon PoS is currently facing.

Validiums are one of the two main approaches to implementing zk-powered L2s, the other one being rollups (e.g. Polygon zkEVM rollup launched earlier this year). In both approaches, L2 periodically submits ZK proofs, aka validity proofs, to L1 (Ethereum), thus providing equivalent security guarantees as Ethereum for all its transactions as well as its native L2-L1 bridge. In addition to ZK proofs, rollups submit compressed transaction data to Ethereum in order to address a hypothetical situation in which the rollup operator(s) go down and users are not able to withdraw funds they bridged from Ethereum. Validiums do not publish transaction data to Ethereum, but instead try to guarantee the availability of this data in another way.

Validiums have two major advantages compared to rollups: (i) significantly lower fees, since they don’t consume expensive Ethereum gas, i.e. blockspace to store transaction data, and (ii) significantly higher scalability, since rollups’ throughput is bounded by the amount of transaction data Ethereum can store. The downside of validiums is that they have to try to ensure transaction data availability outside of Ethereum, which can be challenging. Fortunately, Polygon PoS already has a decentralized validator set with ~$2B at stake, which can serve as a highly reliable transaction data availability layer.

Considering (i) the aforementioned properties of validiums, (ii) the current architecture and decentralization of Polygon PoS and (iii) the current state of zkEVM technology developed by Polygon teams, we believe that upgrading Polygon PoS to a zkEVM validium is:

  • Viable: We have not been able to identify any major concern with regards to the upgrade;
  • Straightforward: The upgrade would require relatively simple upgrades to Polygon PoS bridge and client implementations, as described in the Technical Details section;
  • Beneficial: The upgrade would introduce a number of direct and indirect benefits, as described in the following section.

Expected Benefits

The upgrade would introduce two major direct benefits:

  • Increased security: Polygon PoS would be able to leverage high security of Ethereum, constituted by ~$40B staked $ETH for economic security and 600k+ validators.
  • Future-proof tech stack: Polygon’s zkEVM is arguably the most advanced technology available in the industry. Moreover, Polygon’s ZK teams and external contributors are fully focused on improving it even further and maintaining it in years to come. Utilizing zkEVM instead of the current legacy architecture would make Polygon PoS future-proof.

In addition to the aforementioned evident benefits, the upgrade would open the path to a number of other improvements:

  • Reorg elimination: Polygon’s zkEVM will soon support decentralized validator/sequencer sets with deterministic, single block finality. At that point, Polygon PoS would be able to utilize it instead of the current probabilistic consensus, thus completely eliminating reorgs.
  • Faster transaction confirmations: Single block finality itself would significantly reduce transaction confirmation time, from the current 256 seconds (128 consensus confirmations) to 2 seconds (current block time). This could be improved even further by reducing the time required to reach consensus, which can be achieved in a few ways, e.g. tasking validators only with sequencing (not execution).
  • Increased scalability: ZK proofs enable validation of huge batches of transactions in a very short amount of time and with very little computation. This introduces the possibility to increase the throughput of Polygon PoS, which currently relies on native transaction execution.
  • Improved fee estimation: With deterministic, efficient consensus and higher scalability, the gas estimation model would be more reliable.
  • Greater decentralization: As stated above, ZK proofs enable validation of huge batches of transactions quickly and efficiently. These batches can be whole blocks or even whole chains. Specifically, one single (recursive) ZK proof can prove the validity of all Polygon PoS transactions since the genesis block. This enables much higher levels of decentralization of full nodes and, if required, validators.
  • Compatibility with Polygon 2.0: Polygon 2.0 is a new vision for the architecture of the Polygon protocol which aims to turn it into a unified, highly scalable network of ZK-powered L2s (rollups and validiums). This upgrade would make Polygon PoS compatible with that vision and enable it to seamlessly interoperate with every other chain in the Polygon ecosystem.

Technical Details

Polygon PoS and its canonical bridge are currently run and secured by its own validator set:

  • Transaction validity guarantees are provided as transaction blocks are being proposed and agreed upon by the validators. Validators natively execute transactions in every block and more than 2/3 of stake-weighted validator signatures need to be collected for a block to be added to the chain.
  • Bridge security guarantees are provided via regular checkpoints, in which more than 2/3 of stake-weighted validator signatures have to be submitted and verified on Ethereum in order for withdrawals from that checkpoint to be processed.

The upgrade would require two types of changes:

  • Changes to the chain client software;
  • Changes to the canonical bridge.

Changes to the Client

Changes in the chain client software are required to allow it to work with the Polygon’s zkEVM prover. Depending on the version of the prover to be used, the changes would mainly boil down to:

  • Providing the zkEVM prover all the inputs required to generate proofs, e.g. transaction witness data;
  • Making small modifications to the standard EVM implementation to adapt it to the L2 context, e.g. returning zero as difficulty;
  • Adapting the client to support the state data structure used by the prover, e.g. Sparse Merkle Trees.

Specifying the exact deltas, i.e. changes to the client is out of scope of this document and, assuming this initial proposal gathers enough support in the community, would be the topic of a follow-up PIP.

Polygon’s ZK and protocol teams have done extensive prototyping using both Polygon and Ethereum clients and are confident that these changes can be implemented in a short amount of time.

Changes to the Bridge

Changes to the checkpoint logic of the bridge smart contract are required to include zkEVM proof verification as a condition.

As stated above, the bridge accepts a checkpoint if more than 2/3 of stake-weighted validator signatures are submitted and verified on Ethereum. With the upgrade, the bridge smart contract should require both the supermajority of signatures and the ZK proof for all the transactions that were added to the chain within that checkpoint. This way the security introduced by the zkEVM prover would be strictly additive to the current security, i.e. it would not introduce additional security risks. In other words, even if the zkEVM prover is not sound, the chain would be at least as secure as it is currently. At a later point, once the prover is considered sound and battle-tested, the signatures can be proven within the ZK proof itself and excluded from the checkpoint, which would additionally reduce gas consumption on Ethereum.

Timeline

Considering the current status of Polygon’s zkEVM technology, the protocol governance process and other relevant factors, we believe the following timeline could be realistic:

  • Pre-PIP discussion and consensus: June 2023 - July 2023
  • PIP publishing, discussion and consensus: October 2023 - November 2023
  • PIP implementation and testing: November 2023 - January 2024
  • Upgrade, i.e. PIP activation on mainnet: February 2024 - March 2024

Practical Concerns

Here we cover several practical concerns or potential question with regards to the upgrade:

  • User and app requirements: Similarly to other Polygon PoS upgrades, users and applications would not be required to do anything. The upgrade should be seamless for both groups.
  • Validator and full node requirements: Similarly to other Polygon PoS upgrades, validators and full nodes would just have to upgrade to the latest version of Polygon PoS client software, which would run zkEVM prover alongside other, already existing components of the client.
  • Impact on transaction fees: Given that (i) Polygon’s zkEVM technology is already highly efficient both in terms of proof generation ($0.00005 per transfer) and verification (350k gas per zk proof) (ii) ZK proofs can completely replace signatures currently required for checkpoints (described in the Technical Details section) and (iii) validiums do not require transaction data to be stored on Ethereum, the “running costs’’ of Polygon PoS would not increase (or can even decrease) in the long run. Moreover, given that the upgrade would open the path to increase the throughput of the chain, the transaction fees could even be reduced over time.
  • $MATIC utility: $MATIC would remain the staking token; the upgrade does not interfere with the economics of the chain.

Positioning and Comparison with Polygon zkEVM Rollup

Currently, Polygon PoS and Polygon zkEVM rollup are two public networks of the Polygon ecosystem. That would remain the case after the upgrade, with the added benefit of both networks using bleeding edge zkEVM technology, one in the rollup and the other one in the validium mode.

We believe the two networks can meaningfully coexist and complement each other, given the differences between rollups and validiums (described in the Proposed Solution section):

  • Polygon zkEVM rollup already offers the highest level of security (both ZK proofs and transaction data are sent to Ethereum), with the tradeoff of slightly higher fees and limited throughput. It is a great fit for applications that process high value transactions and where security is the priority, e.g. DeFi applications.
  • Upgraded Polygon PoS (zkEVM validium) would offer very high scalability and very low fees, with the tradeoff of storing transaction data locally instead of on Ethereum. It would be a great fit for applications that have high transaction volume and require low transaction fees, e.g. Web3 gaming and social.

Additionally, Polygon 2.0 can unify both networks as well as all application-specific Polygon chains, aka Supernets, making their coexistence even more meaningful and beneficial for users.

Conclusion

We have presented the initial proposal to upgrade Polygon PoS to a zkEVM validium.

As described, the upgrade would be beneficial in multiple ways; it would address challenges Polygon PoS is facing, preserve its relevance and improve its value proposition. It would also make it compatible with the Polygon 2.0 vision, thus enabling it to meaningfully coexist and seamlessly interoperate with other chains in the Polygon ecosystem.

Given the state of Polygon’s zkEVM technology and the current architecture and level of decentralization of Polygon PoS, we conclude that the upgrade is meaningful, viable and straightforward.

Apart from standard engineering and deployment risks that are present for any chain upgrade, we were not able to identify meaningful additional risks or concerns.

We invite the community to analyze, discuss and hopefully reach consensus for implementing the proposal.

37 Likes

Hope the gas fee ll b in matic. :pray:

4 Likes

Polygon Avail leaving with no use of matic token worrisome. Does this proposal increase matic utility?

4 Likes

I love it!

My initial reaction from just looking at the specs: this is a huge win for all parties involved. Current Validators, DeFi Protocols, and - most importantly - Polygon PoS Users will all benefit from this… not to mention the boost in network security, cross-chain composability / data transfer, and bridging experience.

From an MEV standpoint - and with the qualifier that I haven’t seen the bor client changes - I don’t see any immediate issues that would cause me to be concerned. If anything, this may help boost our resilience against some of the nastier attack vectors.

I have many technical questions, particularly around infrastructure requirements for current PoS validators, but I suspect you already have solutions for them. I can’t wait to dive into the code when it’s public. :slight_smile:

I’m very excited for this and can’t wait to see the ways that Polygon 2.0 integrates this upgrade as it revolutionizes DeFi.

4 Likes

That is absolutely amazing! I can’t wait to see this proposal turn into action, as it will most definitely be a giant step forward in Web3 development.

2 Likes

Who will run the prover? Will each of current 100 validators run their own ZkEVM prover? or will it be the same centralized “rocket” that produces the proofs for Polygon ZkEVM?

1 Like

Overall rather a good idea, the economic model of the token is not impacted, would we see a staking of the MATIC token?

3 Likes

From the perspective of someone who runs RPC nodes: Yes please. The RPC nodes feel “wobbly”, because of their legacy tech stack. Whether it’s reorgs, the large amount of “junk peers”, or the recent “heimdalld 0.3.4 will freeze your Bor, but heimdalld 0.3.3 is fine” fun, it feels like there’s always something in Polygon node running that keeps it from being boring in the best sense: Boring as in “things just work”.

This sounds like it’ll add security and allow you to be interesting in the best sense, in the use cases, while becoming boring as far as stability goes. That’s the hope, and getting there in 12-18 months (very optimistic timeline in this proposal is 9 months) sounds doable.

4 Likes

Its not polygon avail. It’s Avail, an entirely separate solution run by Anurag as of a few months ago.
It sits outside the Polgyon Labs ecosystem.

5 Likes

Sounds awesome. As others have asked, would love to know the increased/decreased utility of the MATIC token.

4 Likes

All this is a very good idea, but the gas costs would have to be in matic.

2 Likes

I think it is very important to hash out the details of MATIC utility continuance. Though this is a very important PiP, you cannot deny that it undermines the utility as consumption; gas is a huge part of matic utility. Having left with staking as the only utility, MATIC will be an ever-inflationary financial instrument. Are you considering freezing the supply? Will the staking fees be paid in ETH? We need to elaborate on what continuance exactly mean. As great as the rest of the proposal sounds, this remains to be an important piece of the proposal that should outline the future of MATIC in a more predictable manner. Thanks for opening up the next iteration of polygon for discussion.

3 Likes

UPgrade is needed right now

1 Like

I am strongly in favor!!!

1 Like

Hello! My name is Nanessa from the Laguna Games team. We built Crypto Unicorns on Polygon. Without diving into the technicalities, we’re all for this proposal. Faster and cheaper TX will make for a better user experience. Full support!

4 Likes

Yes please!!! It would be great!

1 Like

I tested polygon zkevm where I saw some quick transactions and we would like to have more defi protocol in the future.

3 Likes

Very exciting updates! A few questions:

  1. how does sequencing with existing POS 100 validators work? 100 sequencers considered too much and will bog down preconfirmation time?

  2. How does your sequencing works to enable MEV protection for your users? any encryption of txs?

  3. Will there be a shared sequencer hub for all polygon L2/3 chains to use & bootstrap sequencing?

  4. does polygon hv any plans to outsource shared sequencing to 3rd party like espresso, flashbots etc? Any pros and cons consideration?

  5. Will polygon provide “rollup as a service” for apps to spin up their customized app specific rollup within mins?

  6. will there be shared provers doing proving for all participating polygon chains to amortize costs across all chains txs?

  7. how will cross-chain communication, txs, composability, execution work?

  8. Estimated finality time between L2-L2 polygon chain txs (simple send/swap)?

Will be great to see details on my questions. Thanks!

4 Likes

Exciting times, great being involved with Polygon since TestNet days and watching it evolve over time.

I have questions

Technology

  • Will the is new approach remove bor and heimdall completely or just add logic to this?
  • If removing bor and heimdall then how will past data be preserved? For example how will archive nodes work with past POS data but still serve new blocks info based on zk validiums?

Matic use cases
The POS chain has been a brilliant place that has and is fueled by Matic token. Currently Matic is used to pay network fees, used for staking and every block burns some matic. However, the ZK chains (optimism, arbitrum) focus on using ETH which brings low use cases to their network coin and in many cases do not need a native coin. In many cases the ZK chains introduced coins as governance token, but due to this has no real value at network level.

So, my question are

  • Will the new POS that will use zkEVM validium use matic for network fees or use eth?
  • Will the new zkEVM validium burn Matic?
  • Will staking still be done using ERC20?
  • Will there be a ntaive matic token on zkEVM validium or use ERC20 version?

Staking
End users receive staking rewards based on how many checkpoints are completed by a validator, also the % each year of matic for staking reduces.

My questions are

  • How will this work in future? Still based on checkpoints?

Conclusion
Look forward to hearing more on this, really excited to see how Polygon evolves.

6 Likes