Ethereum privacy EIP hits gap as verifier needs 190,628 gas
A Sept. 5 EIP-8141 draft caps initial validation at 100,000 gas; a Sept. 2 benchmark finds a Groth16 verifier needs 190,628 gas. An amendment would let some nodes accept heavier transactions locally.
A Sept. 5 draft of EIP-8141 sets an initial validation cap of 100,000 gas for Frames transactions on Ethereum. The cap is aimed at limiting node validation work during the initial validation phase. An amendment to the draft was submitted by contributor AnkushinDaniil and is under review.
A Sept. 2 benchmark by mmjahanara measured an optimized Groth16 proof verifier that requires 190,628 gas for execution. The benchmark attributes roughly 181,000 gas to the cryptographic pairing check alone. When the verifier measurements are combined with modeled overhead and a 20,000-execution-gas charge per nullifier, the benchmark’s model shows minimum costs of 211,828 gas for a single-note spend and 351,828 gas for an eight-note spend. The benchmark recommends an allowance of at least 250,000 gas for typical optimized transactions.
The amendment to EIP-8141 would treat the 100,000-gas figure as a baseline that nodes must propagate when they can, while allowing individual nodes with higher capacity to accept transactions that exceed that limit into local or private mempools. The change would not require nodes that accept heavier transactions to relay them across the public network.
Accounting differences in companion drafts affect totals. A related draft, EIP-8250, charges fresh nonce keys to state gas rather than execution gas, which shifts some costs out of the execution budget. The benchmark’s modeled totals reflect its accounting assumptions and are not a verified measurement under the latest combined proposals.
Current nonce rules limit the public mempool to one pending Frame transaction per sender. That rule restricts designs that share a single address across multiple users. EIP-8141 allows transactions that fall outside its public validation rules to be held in local or private mempools. An informational proposal, EIP-8369, describes rules to enforce transaction inclusion for custom submission but would need a binding protocol extension to make inclusion guarantees mandatory.
Public propagation is separate from block validity: a transaction can be valid for inclusion in a block even if some nodes do not propagate it across the public network. Node operators and protocol developers are evaluating how to accommodate higher proof-verification costs while keeping per-node validation workloads bounded and limiting denial-of-service exposure.
The September amendment would provide optional flexibility at the node level. Network-wide support for privacy designs that rely on public submission rather than off-chain relayers would require broader accommodation of higher proof costs across the network.








