Ethereum’s privacy push hits a numbers problem: one proof needs nearly twice the proposed gas allowance
The gas mismatch (short version)
Here’s the gist: a recent change proposed to EIP-8141 would make a 100,000-gas validation budget the public minimum that every node must propagate, while letting fancier nodes accept heftier transactions locally. Cute idea, until someone ran the math on privacy proofs and discovered they’re absolute gas hogs.
A benchmark published in early September measured an optimized Groth16 proof verifier chewing through about 190,628 gas just to verify — and its cryptographic pairing check alone burns roughly 181,000 gas. So that neat 100,000 public guarantee? It’s nowhere near enough for these proofs.
The same benchmark’s fuller model pushes the totals higher: about 211,828 gas for a single-note spend and roughly 351,828 gas for an eight-note spend. Those figures bake in the verifier’s execution cost, estimated overhead and a 20,000-execution-gas charge per nullifier (the thing that prevents double-spending). Bottom line: some real-world privacy transactions can require two to three times the proposed public budget.
Why this is a headache — and what could help
There are a few moving parts that make this more than a simple math fight. First, another draft (EIP-8250) handles some charges differently: it puts fresh nonce keys into state gas — a separate pot — instead of execution gas. That accounting difference means benchmark totals aren’t a perfect one-to-one match with the latest drafts, but it doesn’t erase the big gap between verifier cost and the public allowance.
The benchmark author suggests bumping the budget to at least 250,000 gas for typical optimized transactions, but even that wouldn’t cover the modeled eight-note cases. The model also assumes a bunch of optimizations: moving non-verification work into later frames, squeezing proof inputs tighter, and improving verifiers. Some options, like using SHA-256 compression, shift burden to the user’s device by making proof creation heavier.
There’s also a protocol-and-network wrinkle: allowing a node to accept heavier transactions locally doesn’t mean those transactions will travel across the public network and be relayed everywhere. EIP-8141’s proposed change would let nodes be flexible, but unless the whole network accepts bigger proof costs, you won’t get guaranteed public propagation. Toss in EIP-8250’s rule that only one pending public-mempool transaction is allowed per sender, and you’ve got another constraint that privacy apps sharing addresses must dance around.
Finally, public propagation is not the same as block validity. EIP-8141 would permit transactions that don’t meet the public validation floor to live in local or private mempools, but forcing those into the public record would require additional protocol-level work. A separate informational draft (EIP-8369) sketches how inclusion rules could be enforced in the future, though that would need a binding protocol extension to actually have teeth.
So where does that leave us? The practical choice is balancing privacy-proof complexity against node workload and denial-of-service risk. The September proposal gives node operators optional flexibility, which helps, but if privacy-focused designs want guaranteed public accessibility they’ll need the network to agree to handle the heavier proof costs. In short: proofs are hungry, nodes have limits, and someone’s going to have to feed the network — or redesign the meal.
