PIP-64: Validator-Elected Block Producer

Polygon Improvement Proposals Canonical PIPs
1

PIP: 64
Title: Validator-Elected Block Producer
Author: Jerry Chen ([email protected])
Description: Introduces Validator-Elected Block Producers (VEBloP) for Enhanced Throughput on the Polygon PoS network.
Status: Draft
Type: Core
Date: 2025-04-29
Disclaimer: This document presents a high-level design for Validator-Elected Block Producers. While the architecture and motivations are well-scoped, certain implementation details, parameters, and operational procedures remain under active discussion and subject to refinement.

Abstract

This proposal outlines a new block production architecture for the Polygon PoS chain, introducing a Validator-Elected Block Producer (VEBloP). By designating a single elected producer per span and implementing stateless block validation, this architecture aims to substantially increase network throughput (targeting 10,000 TPS and potentially higher), shorten block confirmation times, and eliminate reorgs, all while maintaining decentralized block verification.

Motivation

The current Polygon PoS network has a theoretical throughput ceiling of around 714 transactions per second (TPS), limited by the 30M block gas limit and 2-second block time. Achieving significantly higher throughput, like 10,000 TPS or more, faces several architectural hurdles within the existing system:

  1. Block Propagation Latency: With potentially over 100 validators producing blocks, rapid propagation across the network is essential for consensus. Attempting to decrease block times below 1 second to boost TPS significantly strains the network, leading to latency issues and mini-reorgs due to inconsistent block views.
  2. Execution Bottlenecks: Executing a full 30M gas block requires considerable time (roughly 125ms on the recommended hardware, 16 cores and 64GB RAM). When combined with validation and propagation overhead, this makes sub-second block times impractical under the current model.
  3. Lack of Single Slot Finality: While PIP-11 introduced faster finality, the current system doesn’t guarantee single-slot finality. Small block ranges can still be reorganized after propagation, negatively impacting user experience and system predictability, especially with faster block intervals.
  4. Economic Unsustainability: Scaling throughput increases hardware demands. For smaller validators, the rising costs may outweigh their diminishing share of transaction fees, potentially reducing validator participation and harming decentralization.
  5. Consensus Overhead: Coordinating ~20 producers per span introduces contention and increases the likelihood of conflicting blocks when aiming for higher transaction inclusion rates.

Simply adjusting parameters like block time or gas limits is insufficient to reach 10k–100k TPS within the current decentralized production model due to the amount of state Polygon chain has; it’s both technically challenging and economically unsustainable. This proposal tackles these challenges by separating block production from validation. A small group of high-capacity producers can build blocks quickly, while the broader validator set focuses on efficient, stateless verification. This allows for significant performance scaling without compromising the core trust assumptions of the consensus mechanism.

Specification

Overview of Architectural Changes

The proposed design fundamentally alters block production through several key changes:

  • Validator-elected Block Producer: A single validator is elected as the exclusive block producer for a given span.
  • Backup Producers: Designated backup producers stand ready to take over if the primary producer experiences downtime or misbehaves.
  • Stateless Validation: Validators use witness proofs for lightweight, stateless block verification when settling milestones, reducing their hardware burden.
  • Decoupling Production and Validation: Separating these roles enhances scalability while preserving trust assumptions.

These modifications aim to simplify block propagation, strengthen finality guarantees, and enable significantly higher throughput.

Validator-elected Block Producer (VEBloP)

To address propagation delays, eliminate contention among producers, and achieve deterministic finality, this proposal introduces the concept of a single, validator-elected block producer (VEBloP) per span. Assigning block creation to one entity ensures blocks are produced predictably and rapidly, drastically reducing the potential for network-wide reorgs and enhancing overall liveness and reliability.

Under this model, spans become indefinite in length, and Heimdall is responsible for selecting the primary block producer for each span. Heimdall also designates backup producers who can step in if the primary producer goes offline, ensuring continuous block production. This contrasts with the current system where around 20 producers operate within a fixed-length span, any of whom can produce a block, leading to potential ordering conflicts and no instant finality. The new approach provides instant finality on transaction ordering and inclusion, though not yet on the block state itself, which will be later finalized by milestones.

Feature Current System Proposed VEBloP System
Producer Set Size per Span ~20 1
Block Producer Determination Any node from the producer set Single node determined by Heimdall
Instant Txn Ordering & Inclusion Finality No Yes
Instant Block State Finality No No

Validator Rotation

A crucial aspect of the VEBloP model is ensuring seamless transitions between block producers to maintain network liveness, even if the primary producer fails or acts maliciously. This rotation mechanism prevents extended downtime or conflicting block proposals.

Heimdall monitors the network for missing blocks. If it detects that the primary producer is offline, it proposes a new span, designating a backup producer to take over. To prevent overlaps or reorgs during transitions, producer changes are carefully coordinated using time-based spans. Instead of defining spans by block numbers, new spans specify a future Unix timestamp after which the newly selected producer can begin creating blocks. This ensures all validators have sufficient time to recognize the span change before it takes effect, preventing inconsistencies. The block timestamps produced by the new producer must be strictly greater than the startTimestamp defined in the new span proposal. Backup producers can then take over smoothly, maintaining chain continuity without causing reorgs. Mechanisms for producers to signal their readiness to Heimdall are also part of this design.

Forced Transactions

To guarantee censorship resistance, even with a single block producer who could potentially misbehave, a mechanism for forcing the inclusion of critical transactions is necessary. This ensures a deterministic pathway for both user and system-level transactions to be executed, upholding protocol guarantees.

This proposal leverages Polygon PoS’s existing state sync mechanism in Bor. Users can submit transaction calldata and a target address to a designated L1 contract. This contract then triggers a state sync message directed to Bor. At the end of each sprint (currently every 16 blocks), the active block producer queries Heimdall for any pending state syncs. The producer must then include a transaction that calls a special L2 contract, which interprets the state sync data and executes the user’s original transaction. Validators verify the correct inclusion and execution of these forced transactions as part of their standard consensus process. If a block producer fails to include a required forced transaction, validators will reject the block as invalid, which in turn triggers Heimdall to initiate a producer rotation.

Stateless Verification

To make block validation efficient and scalable, particularly as throughput increases, this proposal incorporates stateless verification. This eliminates the need for validators to maintain and constantly update the full chain state, significantly lowering their hardware requirements and encouraging broader participation.

Stateless verification relies on cryptographic witnesses generated by the block producer (or any full node) during block construction, based on established techniques (e.g., Execution layer cross-validation). These witnesses contain the necessary state information for a block to be verified without access to a full state database. Witnesses are computed and propagated across the network, potentially via a dedicated peer-to-peer protocol like the Ethereum Witness Protocol (wit). Validators receive a block and its corresponding witness, allowing them to re-execute the block’s transactions and confirm its validity statelessly. Validators only need to store recent verified blocks necessary for settling milestones and checkpoints. Strategies like witness caching (for both code and state) are being explored to minimize the data propagated per block.

Economic Incentives

Given that this change will impact validator economics, in particular their receiving transaction fees and any out-of-band MEV fees, the team will continue analysis on this economic impact and adopting additional changes to maintain economic incentives to provide validation services. For example, an option would be to redistribute all transaction fees and MEV fees to validators based on their proportional stake, reserving a portion as commission to the selected block producer.

Due to its size and complexity, the detailed economic model is considered out of scope for this architectural specification and will be addressed in a separate proposal. Crucially, this proposal does not alter the existing staking rewards validators receive for participation in checkpoint proposing and signing on Heimdall and L1.

Rationale

This design strikes a balance between performance and decentralization. Centralizing block production allows for lower latency and higher throughput by removing the bottleneck of coordinating many producers for each block. Simultaneously, maintaining decentralized verification through stateless validation ensures that trust assumptions are upheld, as a broad set of validators confirms the chain’s integrity. This separation of concerns enables significant scaling while preserving the core security properties of the network.

Backwards Compatibility

  • Both Heimdall and Bor are required to implement the new time-based span structure, producer election/rotation logic, and stateless witness verification. A hardfork will be required when the new architecture is rolled out.
  • Existing validators can choose to run stateless Bor clients, reducing their hardware needs without needing to operate full nodes.
  • The processes for checkpoints and milestones remain unchanged.

Security Considerations

  • Network Trust: The model assumes the block producer connects to at least some honest RPC nodes to prevent issues like block withholding.
  • Witness Integrity: The security of stateless validation hinges on the integrity of witnesses. Validators must be able to reliably detect and reject invalid blocks based on incorrect or manipulated witnesses. Robust witness generation and propagation are critical.

References

4 Likes
2

This is awesome. Let’s push this through, full steam ahead. Polygon has been losing ground shiny new 10k TPS chains recently. Time to eat their lunch.

My main question is:
How many validators do we expect to participate given hardware requirements compared to now? And then downstream of that, what other safe guards can we put in place to avoid Validators colluding to elect producers based on mutual benefit rather than network health?

This is basically the trade-off: massive increase in thru-put, but slightly more risk of a cartel forming that monopolizes MEV on the chain.

One suggestion I have for managing the trade-off is adding weighted voting, based on research. Validators get larger weights based on good behavior.
I would strongly support this either way.

1 Like
3

Strongly opposed to this.

  • Centralizing block production is how rollups work. Rollups, however, have the luxury of being able to trust their sequencer. Polygon PoS does not.
  • From an MEV perspective, multiblock MEV is the greatest current risk to the protocol and this would exacerbate the problem.
  • it’s not clear to me that this solves any actual problem - blockspace is cheap and abundant already. TPS is a vanity metric.
  • From a competitive standpoint, Polygon PoS represents an opinionated stance on decentralization where its competition - L2s - represent centralized sequencers. To me, this proposal actively undermines Polygon PoS’s best competitive advantage.

Due to its size and complexity, the detailed economic model is considered out of scope for this architectural specification and will be addressed in a separate proposal.

The economic model is the most important part. There are many reasons why no L2 has decentralized their sequencer yet - most of them related to MEV and cryptoeconomics. It is worrisome that this proposal is being made without attempting to address these issues.

At the very least, a proposal like this would need to be accompanied by some sort of consensus-level transaction sorting requirement (e.g., priority gas price ordering). Otherwise, this gives the selected block builder the MEV equivalent of a blank check.

4

Instead of having validators elect the block producer on heimdall, why not have them run an auction for the validator slot on Heimdall and burn the POL used in the auction.

While thing doesn’t give you an perfect MEV burn, it does return some of the expected value of MEV to the POL token holders and front runs the formation of an off chain bribing market to vote for specific validators who will capture the MEV.

3 Likes
5

MEV rewards accrue on the polygon blockchain but staking happens on Ethereum.

There’s no direct access to the information needed to map MEV accrual and stake. Getting that visibility to the polygon PoS execution side has been my #1 ask for a while now but it is technologically very difficult.

Right now both MEV and block rewards accrue to the block.coinbase address of the proposer. The MEV is initially held inside a smart contract in the hope that eventually we can tie it to the stakers, but we also allow the validators to withdraw it.

For them to pay the stakers directly they’d have to then bridge the funds to eth L1 and then submit a ton of transfers.

Running an auction for the validator slot would lead to cartelization and would push out most validators because it wouldn’t tie the staked amount to the block rewards in any meaningful way. In other words, it’d stop being proof of stake.

6

I’d argue that this structure is much more decentralized and reliable than what a rollup offers. The validators can choose to rotate out the “sequencer” if it doesn’t perform well. The “sequencers” that validators vote for should reputation comparable or higher than the rollup sequencers.

  • From an MEV perspective, multiblock MEV is the greatest current risk to the protocol and this would exacerbate the problem.

On networks where next block producer can be predicted including Ethereum, multi block MEV is already feasible and people need to be careful. However, we can take advantage of the limited block producers here. Validators can vote for only the block producers that commit to not extracting MEV. Arguably, it then becomes even better than the current architecture if our goal is to avoid MEV. This new architecture gives us the flexibility.

  • it’s not clear to me that this solves any actual problem - blockspace is cheap and abundant already. TPS is a vanity metric.

It’s not cheap enough. Other chains are leaving PoS behind in terms of cost. This proposal also solves the reorg problem and offers practical instant finality, unlocking lots of usecases for retail payments etc.

  • From a competitive standpoint, Polygon PoS represents an opinionated stance on decentralization where its competition - L2s - represent centralized sequencers. To me, this proposal actively undermines Polygon PoS’s best competitive advantage.

PoS will still remain much better than other L2s with forced transactions, failover block producers, validator elected block producers etc.

4 Likes
7

Instead of having validators elect the block producer on heimdall, why not have them run an auction for the validator slot on Heimdall and burn the POL used in the auction.

I like that idea but it has much larger cryptoeconomics risk that we need to study in detail before committing to it. Perhaps we can move towards that over the upcoming years.

8

I think if you feel like the voting based mechanism will have a soft social expectation against full max extract behavior initially then I think starting with voting and transitioning to an auction might work well.

1 Like
9

Some really good feedback above.

If we look at the big picture, we’ve hit the limits of tuning gas limits and block times. To keep growing, we need to separate block creation (fast, reliable, single slot) from validation (lightweight, trust-minimized, stake-based) especially if it is going to give us such high TPS.

I strongly agree with @maxsam4 that PoS right now is not cheap enough.

PIP-64 is that first piece of a multi-proposal roadmap.

2 Likes
10

Seemingly well thought out proposal. It is great that Polygon is doing a big update like this. Barring discovery of any big downsides, onward and forward, lets do it : )

1 Like
11

After reviewing PIP-64, I’m overall supportive of the proposal’s ambition to enhance Polygon PoS’s scalability and throughput. Introducing a single, validator-elected block producer (VEBloP) per span, coupled with stateless validation, is a good move towards achieving higher TPS and reducing reorgs.

However, while the proposal offers significant benefits, it’s crucial to consider the implications for Maximal Extractable Value (MEV) that has already been raised by others. Granting a single producer control over multiple consecutive blocks (16 in this case) can amplify MEV opportunities. This control enables complex strategies like multi-block arbitrage or sandwich attacks, potentially leading to unfair advantages and undermining transaction fairness.​

To mitigate these risks, I suggest implementing transparent MEV guidelines on what is considered appropriate behavior and setup monitoring tools to detect exploitative MEV practices by block producers. There can also be provisions for community governance to intervene in the election of block producers if they abuse their position.

Overall, I’m very supportive of this proposal and look forward to seeing it implementing alongside some mitigation measures to address multi-block MEV risks.

2 Likes
12

We appreciate @jerry s’ detailed proposal and the clear motivation to push Polygon PoS throughput beyond current limits. The idea of validator-elected block producers combined with stateless validation offers an innovative path to reduce propagation latency and reorgs, which have long challenged scaling efforts.

As @maxsam4 noted, the ability for validators to elect and rotate block producers does provide a governance mechanism to maintain decentralization better than traditional rollup sequencers. However, we share @Thogard’s concerns about the MEV implications of granting a single producer control over 16 consecutive blocks. Multi-block MEV strategies could become highly lucrative and difficult to detect or prevent, potentially undermining transaction fairness and user trust.

While the proposal targets 10,000 TPS, is there sufficient demand on Polygon PoS today to justify this leap? If the blockspace remains relatively cheap and abundant as Thogard pointed out, prioritizing decentralization and economic sustainability might better serve the network’s long-term health.

We also wonder about the economic incentives for smaller validators under this model. If hardware demands rise and block production centralizes, will smaller validators be pushed out, further concentrating power? The proposal’s acknowledgment that detailed economic modeling is out of scope leaves a critical gap.

Overall, PIP-64 opens an important conversation about scaling Polygon PoS but needs deeper analysis on MEV risks, economic impacts, and demand justification before moving forward.

1 Like
13

To be clear, a single block producer currently has control over a sprint, which is 16 consecutive blocks. The producer can delay and capture multiblock MEV for a max of 8 of them (any more and their backup will reorg them).

This proposal is for a single block producer to control a span, which is 100 sprints, which is 1600 blocks. (Please let me know if my info is out of date or wrong but I don’t recall this changing since the 64->16 sprint length change). Note that this proposal also mentions making span length “indefinite.”

Most multiblock MEV mitigation comes from the fact that if a block builder doesn’t propose a block with a transaction then another one will. This makes it unprofitable for a builder to “sit” on transactions that have value that is super linear with blocktime (most MEV transactions fall in this category).

The forced inclusion lists are a nice way to mitigate this problem, but theyre delayed. Competition is a better mechanism.

What’s unclear to me is this concept of “voting” that some of you are referencing but that doesn’t appear in the proposal. There is a validator-elected block producer, but that doesn’t necessarily mean that all validators vote on the producers.

It’s hard to make any judgement about the proposal without the economic architecture / mechanism design.

Also, let’s be straight forward - this is extremely centralized like L2s. That’s explicitly the point:

The difference is the validation mechanism (PoS consensus vs fraud proof), not the centralization of the sequencer.

But it also remains to be seen that validators will elect a sequencer that will behave as nicely as the validators currently are behaving. From FastLane’s point of view, this would be a fundamental change from a bundle propagation architecture to a full proposer-builder separation design - the latter of which is strictly worse for users if left unchecked.

Enshrined PBS would be ideal if additional safeguards for users are added to consensus (e.g., priority fee sequencing) - and perhaps this proposal is a roundabout way of implementing exactly that - but it’s impossible to analyze it without the economic / mechanism design.