Real-time L1 proving: the cost curve marching down and to the left
crypto
ethereum
zk
proving
infrastructure
Somewhere in late 2025 we crossed a line and almost nobody threw a party. A zkVM proved a real Ethereum mainnet block, not a benchmark, an actual block, in less time than the twelve seconds that block was alive. On sixteen gaming GPUs you could buy at retail. That one fact is the thing holding up the Ethereum Foundation's entire plan to snarkify the L1, because it turns a wild idea into a schedule.
The wild idea: stop making every node re-execute every transaction. Instead, one prover does the work once, produces a tiny proof, and every other node spends a few milliseconds checking that the proof is valid. If that's possible fast enough, gas limit stops being a node-hardware constraint. It becomes a prover-hardware constraint, and provers parallelize. That's the whole gigagas story, and it only works if proving finishes inside the slot it's proving.
Two independent teams crossed it within months of each other.
Succinct's SP1 Hypercube proved 99.7 percent of real mainnet blocks in under 12 seconds, 95.4 percent under 10 seconds, on 16 RTX 5090s, roughly a 100K USD cluster (Succinct). Brevis's Pico Prism 2.0 proved blocks in 6.1 seconds on average, 99.9 percent under 12 seconds, also on 16 GPUs (Brevis).
Two teams, no coordination, same hardware budget, same slot, both under it. Vitalik publicly applauded both. That's not a nice tweet, that's the Ethereum Foundation telling you the gigagas roadmap is now load-bearing on a real number instead of a hope.
Today, when a block lands, every full node on Ethereum reruns the whole thing. Every opcode, every storage write, every signature check, independently, on thousands of machines. That redundancy is the entire reason the gas limit can't just go up. Raise it and you raise the floor on what hardware a node needs, which shrinks who can run one, which is the opposite of decentralization.
Proving breaks that coupling. One prover does the expensive work. Every other participant does a cheap, constant-cost check. The asymmetry is the whole point: proving is expensive once, verification is cheap forever, for every node, no matter how big the block gets.
Write it as total network work. Under re-execution, with N nodes each doing the full execution cost W_exec:
total_work_reexec = N * W_exec
Under real-time proving, one prover eats W_prove and every node pays a near-constant verification cost V:
total_work_proving = W_prove + N * V
V is milliseconds and barely moves as blocks get bigger. W_exec and W_prove both grow with the block. But only one actor eats W_prove, and that actor can throw more GPUs at it. N nodes eating V stays cheap no matter how large N gets. That's the lever the rest of this post is about.
Put proving on two axes: latency (how long until the proof exists) and dollars per proof (what it cost in GPU time). The real-time condition is simple: latency has to beat the 12 second slot.
Define proving work per block in GPU-seconds, proportional to gas:
W(block) = c * gas_million # GPU-seconds, c = GPU-s per million gas
With P parallel GPUs and an aggregation overhead factor alpha (always at least 1, because chunking and recursive proof composition aren't free), wall-clock latency is:
T(block) = alpha * c * gas_million / P
The real-time condition is T(block) < 12s for essentially all blocks. There are exactly two ways to hold that true as gas grows: push c down, or push P up. Solve the inequality for the max gas you can support at a given hardware budget:
gas_max = P * 12 / (alpha * c)
That's the whole roadmap in one line. A 5.3x drop in c is directly a 5.3x increase in how much gas you can prove in real time on the same hardware. The curve isn't a vibe, it's the denominator of your gas limit.
Pico Prism went from 8.64 GPU-seconds per million gas in version 1.0 to 1.63 in version 2.0, a 5.3x efficiency jump in one release (Brevis). None of it is a new cryptographic breakthrough. It's unglamorous systems work:
On the SP1 side, the win looked different: Succinct cut the cluster from roughly 200 GPUs to 16 in about six months, a 12.5x efficiency gain, while staying under the slot (Succinct). Same destination, different knob: less hardware for the same latency, instead of less latency on the same hardware. Both moves are the same curve, approached from opposite directions.
The reason the curve keeps bending down as gas rises, instead of flattening out, is that a block doesn't get proved as one monolithic trace. It gets split.
block -> [subblock_1, subblock_2, ..., subblock_k]
subblock_i -> prove_on_gpu_i -> proof_i # k proofs, in parallel
[proof_1 ... proof_k] -> recursiveAggregate -> proof_block
proof_block -> verify (milliseconds, every node)
Each subblock proves independently, on its own GPU, in parallel. A recursive proof then folds all k proofs into one, so the thing that finally gets checked onchain is a single succinct object, not k of them. This is why adding GPUs buys you latency almost linearly instead of hitting a wall: you're not making the math faster, you're running more of it at once. The curve falls because you add GPUs, not because you invent a faster universe.
The on-chain side of this is deliberately boring. An attester doesn't re-derive anything, it just checks a proof against a verifier contract:
function verifyBlockProof(bytes32 blockHash, bytes calldata proof) external view returns (bool) {
// calls the SNARK verifier precompile / contract
// returns pass/fail in milliseconds, independent of block size
return verifier.verify(blockHash, proof);
}Fifteen lines, give or take, and it doesn't care if the block had 30 million gas or 3 billion. That constancy is the entire value proposition.
The objection people reach for immediately: doesn't handing block proving to a handful of GPU clusters centralize Ethereum?
It doesn't, because proving and verifying aren't doing the same job, and only one of them has to be decentralized for safety to hold.
A dishonest prover cannot hurt the chain. The proof system is sound, so a bad proof just fails verification and gets thrown out in milliseconds, same as a malformed transaction today. The trust assumption is that someone produces a valid proof before the slot ends. That's a liveness assumption, not a safety one, and liveness assumptions are much weaker.
Model it with N independent provers, each honest (meaning: online and competent) with probability h. The chain only stalls if every single one fails:
P(stall) = (1 - h)^N
At h = 0.5 and N = 10, P(stall) is about 0.001. You don't need most provers to be reliable, you need one, and the probability that all N fail simultaneously collapses fast as N grows. Compare that to re-execution's trust model, where every node has to independently redo the full work, which costs N times W_exec across the network for zero additional safety benefit, since they're all just checking each other's arithmetic the expensive way.
Verification is the part that stays genuinely decentralized here, and it gets cheaper, not more exclusive, as proving gets better. Anyone with a laptop can run the verifier. The thing concentrating is the much smaller, much more mundane job of generating proofs, and that's fine, because generating a wrong proof is harmless.
Put the inequality and the trust model together and the plan writes itself. Raise the gas limit, and the burden shifts almost entirely onto the prover, who scales horizontally by buying more GPUs or writing tighter CUDA kernels. The node's burden, verification, stays flat. That decoupling is the only reason anyone can seriously talk about 10,000 TPS on an L1 without also talking about requiring every validator to run a server farm.
The curve hasn't finished moving, and it shouldn't be read as "solved." Three real bottlenecks remain. Proof latency has variance, not just an average, and the roadmap has to survive the tail, not the median block. Hardware access matters: a 100K USD cluster of RTX 5090s is a very different proposition depending on whether GPU supply, electricity, and uptime SLAs cooperate, which they don't always. And the gap between "a research cluster proved blocks in a controlled test" and "this is wired into consensus with data availability and proof-of-custody in production" is still a real gap, even after the threshold is crossed.
The curve underneath real-time L1 proving isn't an Ethereum-specific curve. It's the generic shape of verifiable compute: prove once, cheaply, somewhere; verify everywhere, almost free. The same cost/latency tradeoff governs zkML, where you're proving a model's inference instead of a block's execution, and the same 1-of-N honest-prover trust model is the primitive that makes decentralized inference markets safe without requiring every participant to redo every computation. That's the part of this I actually spend my days on at B3, building the verifiable infrastructure that assumes this curve keeps bending the way it has for two years.
The honest caveats, stated plainly rather than buried: 99.7 percent is not 100 percent, and the missing 0.3 percent is the adversarial, max-calldata block that the roadmap has to design around, not average away. These numbers are single-prover, single-block results in controlled conditions, and integrating them into live consensus with data availability and proof-of-custody is unfinished work. The 100K USD cluster figure describes optimized retail hardware, and real prover economics include electricity and uptime that the sticker price doesn't. And 1-of-N honest provers only holds if N is actually large and actually independent, which is a social and economic fact about who bothers to run a prover, not a cryptographic guarantee.
The dot has been marching down and to the left for two years, and the people moving it aren't slowing down. When it reaches gigagas, every node on Earth will validate Ethereum by checking a proof that fits in a tweet, and the work that used to live in your node will live in a rack of GPUs that any honest stranger can run. Build the prover that moves the dot another notch, and show me the latency.
Sources: