How large can EIP-8141's validation budget be? A mempool DoS benchmark

How Large Can EIP‑8141’s Validation Budget Be?

TL;DR – The current `MAXVERIFYGAS` limit of 100 k gas per frame transaction blocks important privacy and post‑quantum schemes. Raising the cap to 300 k gas is feasible, but only if the client temporarily suspends mempool validation while importing or building a block; otherwise the extra CPU can delay block processing enough to cause missed attestations.

---

1. Why the 100 k Cap Matters

EIP‑8141 introduces frames that allow arbitrary EVM code to run during transaction verification. Unlike the cheap `ecrecover` check in legacy transactions, a frame’s `VERIFY` step can be arbitrarily expensive. To prevent a denial‑of‑service (DoS) vector—where an attacker sends failing transactions that consume CPU for free—the spec caps unpaid validation at `MAXVERIFYGAS` (currently 100 k).

Unfortunately, many emerging use‑cases exceed this budget:

| Scheme | Approx. VERIFY gas | |--------|-------------------| | Groth16 shielded transfer | ~212 k | | PLONK verifier | ~298 k | | SPHINCS+ (hash‑based) | 94 k‑276 k | | BLS signatures (EIP‑7951) | 130‑140 k | | Lattice‑based post‑quantum (ML‑DSA‑44) | >1 M |

Thus, a higher cap is required for privacy, post‑quantum, and advanced multi‑signature wallets to be practical.

---

2. Benchmark Methodology

We evaluated the impact of raising `MAXVERIFYGAS` on a Nethermind node running the EIP‑8141 validation logic. Three hardware tiers were used:

• High – AMD EPYC 4344P (8 c/16 t), representing a local block builder.
• Mid – GCE c2‑standard‑8 (4 c/8 t), a typical validator.
• Low – GCE n1‑standard‑8 (4 c/8 t), approximating a full‑node with limited spare CPU.

Two worst‑case failing‑transaction payloads were crafted:

1. Keccak‑wide – Repeated `KECCAK256` over 4 KB until the gas budget is exhausted.
2. Sig‑stuffed – Sequential `secp256k1` signature verifications, with the final signature failing.

For each cap (100 k, 250 k, 300 k, 400 k, 500 k) we flooded the node with a steady stream of such transactions, measuring:

• Block‑import delay – Extra time to import a median mainnet block.
• Block‑building delay – Extra time for a proposer to assemble a block.
• Honest transaction admission – Fraction of legitimate frame transactions that still enter the mempool under load.

A safe load is defined as keeping the added delay ≤ 25 ms, which corresponds to a ≤ 0.2 % increase in missed attestation deadlines on today’s network.

---

3. Key Findings

| Machine | Safe gas‑per‑second (validation) | Cap that stays within 25 ms at 100 tx/s | |---------|--------------------------------|------------------------------------------| | High (builder) | ~30 M gas/s | 300 k (with client protection) | | Low (full node) | ~15 M gas/s | 100 k (no protection) |

• Without protections the node processes roughly 100 failing transactions per second per connection. At a 300 k cap this translates to 30 M gas/s, which exceeds the low‑tier node’s 15 M gas/s budget, causing > 25 ms block‑import delay.
• With in‑client mitigation (pause validation while a block is being imported or built) the effective CPU share taken by validation drops dramatically. Import delay falls to ≈ 2 ms even on the slowest machine, allowing a 300 k cap to stay within budget at 100 tx/s.
• Honest transaction admission suffers under heavy flood. At 100 tx/s with a 300 k cap, the low‑tier node admits only 12 %–27 % of honest frame transactions, indicating a trade‑off between higher caps and mempool throughput.

---

4. Practical Recommendations

1. Raise `MAXVERIFYGAS` to 300 k – This accommodates most privacy and post‑quantum schemes while keeping the validation budget within a realistic range.
2. Implement a validation pause – Clients should suspend frame validation while importing or building a block. Nethermind’s `#13994` patch demonstrates a simple and effective approach.
3. Rate‑limit failing transactions per connection – Limiting to ~100 failing tx/s per peer reduces the attack surface without harming normal traffic.
4. Monitor mempool health – Nodes should expose metrics on validation CPU usage and honest‑tx admission rates, allowing operators to adjust limits dynamically.

---

5. Conclusion

The 100 k gas cap in EIP‑8141 is a bottleneck for advanced cryptographic use‑cases. Our benchmarks show that a 300 k cap can be safely adopted, provided clients employ a lightweight mitigation that yields CPU to block processing during critical phases. This balances the need for richer verification logic with the network’s resilience against DoS attacks.