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.
Discussion: https://forum.polygon.technology/t/pip-64-validator-elected-block-producer/20918
Status: Peer Review
Type: Core
Date: 2025-04-29

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 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, 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 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

Block Producer Election

In VEBloP, Heimdall employs a validator voting mechanism to select span producers. Validators cast their votes by submitting a ranked list of preferred producer candidates.
A candidate’s position is determined by a weighted score that considers both their rank in a validator’s vote and the validator’s stake. This score is calculated using the formula: weight = (max_possible_producers - position) × validator_stake. This method gives greater weight to higher-ranked candidates, ensuring that validator preferences are reflected in proportion to their stake.
After scoring, candidates are ranked by their total weighted score, with ties broken deterministically by their candidate ID. To qualify, a candidate must meet a security threshold, securing at least ⌊(max_possible_weighted_vote_at_position × 2/3)⌋ + 1 of the voting power. The maximum possible weighted vote for a given position P is (max_possible_producers - P + 1) × total_stake. The selection process halts if any candidate fails to meet this 2/3+1 threshold to maintain security guarantees.
Finally, Heimdall selects the next producer from the list of qualified candidates who have maintained an active status by regularly voting on milestones (see the Active Block Producer section). The selection cycles through the list, proceeding from the current producer. Initially, the consensus rules permit a maximum of 3 candidate block producers.

Active Block Producer

An active block producer is a validator that has demonstrated recent participation in the consensus mechanism by submitting milestone propositions that achieve majority consensus. This concept is central to VEBloP’s liveness guarantees and ensures that only engaged validators are qualified for block production duties.

Definition and Criteria

A validator is considered an active block producer if it:

  1. Participated in the Most Recent Milestone Voting: The validator submitted a vote extension containing a milestone proposition that was part of the 2/3+ majority consensus for the latest milestone
  2. Maintained Good Standing: The validator is not in the “failed producer” list (validators who have failed to perform their block production duties)

The system maintains the active producer set through a continuous milestone consensus process where validators propose milestones through vote extensions during consensus rounds, and those milestone propositions that achieve ≥2/3 of total voting power support determine the new “latest active producer” set from the validators who supported the majority milestone, with each successful milestone consensus completely replacing the previous active set.

Span Rotation on Producer Failure

VEBloP implements an automatic span rotation mechanism to maintain network liveness when block producers fail to perform their duties. This failover mechanism prevents the blockchain from stalling due to inactive or unresponsive producers.

Trigger Conditions

Span rotation is automatically triggered when the following conditions are met:

  1. Insufficient Milestone Proposition Support: No milestone proposition reaches 1/3+ voting power support
  2. Time Threshold Exceeded: More than 5 Heimdall blocks (approximately 5-6 seconds) have passed since the last successful milestone was processed.

This combination indicates that the current producer is likely inactive or the network is experiencing consensus issues that require intervention.

Rotation Process

When rotation is triggered, the current producer responsible for blocks starting from the block immediately after the last successful milestone is marked as failed due to their inability to produce blocks that could be finalized by milestones. A new span is created with its start block set to the block immediately after the last successful milestone. The end block is set to the end block of the immediate next span. This calculation prevents excessive rotation frequency, especially when failures occur near span boundaries. The new producer set excludes both the current failed producer and any producer that isn’t in the active producer set. Upon successful rotation, the failed producer is added to the failed producer list, and a 10-heimdall-block grace period is established before the next rotation check to prevent cascading failures.

Example

Scenario

  • Span length: 100
  • Current span: [200-299]
  • Future span: [300-399]
  • Producer failure occurs at block 280
  • Last successful milestone ended at block 279

Rotation Process

  1. Failure Detection: The Heimdall consensus identifies the producer responsible for blocks 200-299 as failed
  2. New Span Creation: A replacement span is created with:
    • Start block: 280 (the block immediately after the last successful milestone)
    • End block: 399 (inherits the future span’s end block)
  3. Producer Assignment: The new span [280-399] is assigned to a different producer from the active set (excluding the failed producer)

Continued Failure Handling
If the new producer also fails and no progress is made in 10 Heimdall blocks, another rotation would create span [280-400] with yet another producer, continuing until a functioning producer successfully advances the chain.

Bor Block Validation Under VEBloP

In VEBloP, Bor retrieves all validator and block producer information directly from Heimdall, eliminating dependency on block headers from previous blocks. Key changes include:

  • Direct Heimdall Queries: Block producer eligibility is determined by Heimdall’s span data rather than deriving from the validator set in previous block headers
  • Removed Sprint Validators: The validator set byte array previously embedded in block headers at sprint boundaries is removed post-VEBloP
  • Removed producer delay: The producer delay (4 seconds) between each sprint is removed post-VEBloP

Bor Block Validation Rules

When a new block arrives, Bor applies the following validation logic:

Case 1: Same Producer as Parent Block

This scenario typically occurs when a producer continues their assigned span.

  1. Fast Path (within 4 seconds): If a block arrives within 4 seconds of its parent, it is considered timely. Bor validates it against the current producer span on Heimdall. The 4-second threshold accounts for a standard 2-second block time plus 2 seconds for fluctuation in network latency.

  2. Slow Path (after 4 seconds): If the block is delayed, Bor initiates a “span rotation detection” process to check if a producer change has occurred. It polls Heimdall every 200ms for up to 8 seconds.

    • If a new span is found, the block is rejected. This means a rotation occurred, and the old producer is no longer valid.
    • If no new span is found, the block is accepted, confirming the original producer is still valid.

Case 2: Different Producer from Parent Block

This scenario indicates an expected producer rotation.

Span Verification: Bor checks Heimdall for a new span that authorizes the new producer.

  • If the new span exists, the block is accepted as a valid rotation.
  • If the new span does not exist, the block is rejected.

Timing Parameters

Parameter Value Purpose
Base timeout 4 seconds Base timeout for block propagation
Span check interval 200 milliseconds Polling frequency when waiting for span updates
Same-producer wait 8 seconds Maximum wait when expecting possible rotation (2x base timeout)

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

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

5 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.

3 Likes
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.

5 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.

3 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 : )

4 Likes
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.

4 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.

3 Likes
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.

14

This is the most controversial and disrupting proposal I’ve seen since I’ve joined as a Polygon Governance delegate.

Could you please answer these questions

  • How much revenue will validators lose?
  • How much less capital(stakes) will be required to attack the chain?
  • Planned milestones and schedules
  • Technical diagrams, technical specifications, and pull requests

I do agree with the benefits, so I will give Weak Accept.

Longer answer here:
https://medium.com/@nodeinfra/polygon-governance-pip-64-e83cb7228b91

15

As the hardware requirements for running a validator node is going to reduce with stateless verification, this will not be a limiting factor for validators. So, it is expected that have all validators currently (100+ of them) to participate.

This relies on the security assumption that the majority of validators are honest. If necessary, the election threshold could be increased, e.g. to 80%, for block producer elections to make sure a super majority agree on the election.

16

It’s important to acknowledge that MEV extraction is possible within the existing Polygon PoS structure. Currently, a block producer has significant control over ordering and inclusion within their assigned 16-block sprint, including the ability to capture MEV across multiple blocks within that sprint (potentially up to 8 blocks before risking reorg by backups).

While the VEBloP model extends the duration a single producer is active, it isn’t immediately evident that this inherently makes malicious MEV significantly more lucrative or harder to detect compared to the existing sprint-based opportunities. A quantitative analysis, likely based on specific MEV modeling under both architectures, would be necessary to definitively assess the change in risk profile.

However, the centralization of block production does necessitate robust safeguards against potential MEV exploitation. PIP-65 outlined two layers of mitigation strategies:

  1. Social Consensus & Off-Chain Coordination: In the immediate term, if a block producer is widely perceived by the validator set to be acting maliciously or unfairly exploiting MEV, validators can coordinate to trigger a producer rotation, effectively electing a new producer via Heimdall.
  2. Future Automated Checks (Optional): Longer-term, the protocol could potentially incorporate basic MEV monitoring or heuristics during block validation. If detectable malicious MEV patterns exceeding defined thresholds are identified, the system could automatically trigger a producer rotation as an enforced protocol rule. Designing robust and manipulation-resistant automated checks remains an area for future research and development.

These strategies provide both immediate recourse through validator consensus and a path towards automated enforcement, ensuring mechanisms are in place to address potential abuses related to MEV.

The elected block producer can continue working with Fastlane, similar to how validators are using Fastlane today. There aren’t changes to how transactions are propagated from this new architecture.

1 Like
17

Incredible! This is a MAJOR upside that should definitely be part of the messaging for the roll out. I’m hugely in support

1 Like
18

If the elected block producers are just the validators that are already making blocks then what exactly is the point?

The validator set is already limited. If there’s an issue with some validators not being able to run the hardware to build blocks then wouldn’t it be much much much easier for the foundation to just give them a grant to beef up their infra?

19

Thank you @jerry for sharing this proposal, and to everyone who joined the discussion, these conversations are crucial for the future of the network.
The goal of the proposal is clear: increasing throughput and improving network efficiency through a dedicated Block Producer role. If executed properly, the expected jump in TPS could position the network more competitively against emerging L1 and L2 solutions.

However, it’s hard to make a solid judgment without more clarity on the actual design. A cautious approach seems appropriate here, with focus on the key open questions that could significantly affect the network’s decentralization, validator incentives, and security.

Some of the main areas that need further clarification:

  • How will this change affect non-block-producing validators in practice? What percentage of revenue might they lose under the new model?
  • How exactly will the BP selection and voting mechanism work? What are the conditions for re-election or removal if something goes wrong?
  • What happens if the elected BP goes offline — not just in terms of slashing, but in terms of chain halt and recovery? What is the fallback process, and how long could it take to switch to a new producer?
  • Delegating block production to a single validator — especially over spans like 1,600 consecutive blocks — raises serious concerns around centralization and MEV (especially multiblock MEV). This could degrade user experience and open the door to harmful behaviors without strong safeguards.
  • The span duration remains undefined. Understanding how often BPs rotate is crucial for evaluating both decentralization and risk mitigation.
  • What’s the proposed rollout timeline? Will this be tested on a testnet first, or is the intention to move straight to mainnet?
  • We need more insight into the incentive structure — how rewards are distributed, how smaller validators will remain viable, and whether the new model still motivates all validators to maintain network security and performance.

In general, it’s promising to see performance-focused evolution of the protocol, but more detail is needed to properly assess the trade-offs. I’m following closely and would be glad to contribute to further discussion once more specifics are available.

20

PIP-64 proposes introducing a Validator-Elected Block Producer (VEBloP) to scale Polygon PoS to 10,000+ TPS by electing a single block producer per span and enabling stateless validation. This new architecture reduces latency, eliminates reorgs, and separates block production from validation—preserving decentralization while enhancing throughput. Forced transactions and backup producers ensure liveness and censorship resistance. Stateless verification lowers validator hardware requirements. A hardfork will be required, and economic adjustments will follow in a future proposal. This is a major step toward scaling Polygon while maintaining trust and validator participation.

1 Like