The Prover Upgrade Problem: Hard Forks and Fragmentation

Prover upgrades require hard forks. Changing a ZK-Rollup's cryptographic proving system, like moving from Groth16 to Plonky2, modifies the core consensus rules. This invalidates all existing infrastructure, from nodes to bridges like Across and Stargate, forcing a coordinated network restart.

The fragmentation risk is permanent. A failed hard fork coordination creates a permanent chain split, as seen in Ethereum's DAO fork. For a rollup like zkSync or StarkNet, this splits liquidity and user bases, creating two incompatible networks from one.

Evidence: Ethereum's Shanghai upgrade required 18 months of testing and client coordination. A rollup attempting a prover upgrade every 12-18 months faces this existential risk repeatedly, with less social consensus than Ethereum.

Prover upgrades are hard forks. Changing a ZK prover invalidates all existing proofs, forcing a coordinated network-wide upgrade. This is not a client update; it is a protocol-level consensus break.

The result is ecosystem fragmentation. Projects like zkSync and Polygon zkEVM face a dilemma: delay new features for network unity or fork the chain. This splits liquidity and developer mindshare.

Provers wield political power. A prover team like RiscZero or Succinct Labs controls the upgrade roadmap. Their technical decisions dictate the economic rules for every dApp built on the chain.

Evidence: The Ethereum Merge required years of coordination. A prover upgrade for a high-throughput chain like Starknet would require similar effort but with more frequent iteration cycles, creating chronic instability.

Prover upgrades require hard forks. Changing a ZK rollup's prover logic is a consensus-breaking change. This forces all nodes, including sequencers and verifiers, to upgrade simultaneously, creating a single point of failure.

Fragmentation is the immediate consequence. A failed hard fork splits the chain. Users on the old chain lose access to the canonical bridge, creating a stranded asset problem similar to Ethereum Classic.

The security model degrades. A fragmented chain loses the aggregated security of the main L1. Attackers can target the weaker fork, as seen in the Polygon zkEVM and zkSync Era upgrade processes where testnet forks were required.

Evidence: Starknet's planned prover upgrade to Stwo will necessitate a coordinated hard fork, testing its decentralized sequencer network and risking temporary fragmentation if adoption is uneven.

Hard forks require consensus. A prover upgrade is a protocol-level hard fork. This demands unanimous coordination among node operators, sequencers, and dApp developers. The Ethereum Merge succeeded because the economic and ideological alignment was absolute; a rollup's upgrade lacks this existential pressure.

Fragmentation is the default outcome. Inevitable delays create competing canonical chains. Users and assets split between the old and new state, replicating the liquidity fragmentation problem that rollups were built to solve. This is the Sovryn/Bitcoin Cash dilemma on a micro-scale.

Evidence: The Polygon zkEVM to Polygon zkEVM 2.0 migration required a planned, multi-phase sunset. Even with a benevolent, centralized sequencer, the process took months and risked ecosystem splintering. A truly decentralized sequencer set makes this coordination impossible.

Hard forks are governance failures. Upgrading a monolithic prover like zkSync's Boojum or Polygon's Plonky2 requires a coordinated hard fork, which is a political and technical bottleneck. This process centralizes control with the core team, creating a prover monarchy that dictates the pace of innovation for the entire L2.

Prover markets solve fragmentation. A competitive market of provers, like those enabled by Risc Zero's zkVM or SP1, allows L2s to adopt new proving systems without forking. Rollups can auction execution proofs, creating a verifiable compute market where the fastest, cheapest prover wins each block.

This mirrors the EVM client dynamic. Just as Ethereum runs multiple execution clients (Geth, Nethermind, Besu), a rollup should support multiple provers. This eliminates single points of failure and creates incentive-aligned competition, driving down costs and accelerating proof-time improvements without consensus-breaking changes.

Evidence: The zkEVM wars. Polygon zkEVM, Scroll, and zkSync each built proprietary provers, creating incompatible ecosystems. A market standard like Type 1 zkEVMs or a shared proof aggregation layer would let them share prover R&D, reducing redundancy and preventing ecosystem splintering.