Data-driven analysis on EIP-7907

The following report, aims to be a collection of data that will hopefully be a resource that will help ACD to take a decision over EIP-7907.
Also, this hopefully sets a new methodology of backing up EIPs or proposals with as much data as possible, which can definitely help taking better and more informed decisions when scoping forks.

I want to thank @rjl493456442 for his PR adding metrics in Geth and his advice and support during the benchmark collection which has been extremely helpful. And which I’d like to standarize eventually across all clients such that we can compare data easily and collect data easily to inform our decisions on repricings and scaling.

Related Issue:** EIP-7907
Date: 2026-01-13
Benchmark Environment: Geth (dev mode) with mainnet-sized database (~24M blocks), internal caches disabled
Test Configuration: ~18,106 EXTCODESIZE operations per block (all different bytecode contracts), ~50M gas
Hardware: WD Black SN850X NVMe (8TB)

Executive Summary

This report analyzes the performance of the EXTCODESIZE opcode when reading contracts of varying bytecode sizes (0.5KB to 64KB) with Geth’s internal code cache disabled. This represents the worst-case attack scenario where an attacker deploys thousands of unique contracts to force cold disk reads.

The iteration also has the lowest overhead possible leaveraging CREATE2 deterministic address generation.
More information regarding this can be found in:

• feat: add extcodesize_setup scenario for deploying EXTCODESIZE benchmark contracts by CPerezz · Pull Request #161 · ethpandaops/spamoor · GitHub
• feat(benchmark): add EXTCODESIZE bytecode size benchmark for cold access testing by CPerezz · Pull Request #1961 · ethereum/execution-specs · GitHub

Key Findings

EIP-7907 Verdict

Recommendation: Proceed with 64KB as the new maximum contract size. Beyond 64KB would require new data collection once BALs and ePBS’s optimizations are landed in all clients.
If a repricing was required after the data collection mentioned above, such pricing would also require being able to benchmark the rest of the clients as well as looking to the rest of EXTCODE* opcodes.

1. Methodology & Benchmark Setup

1.1 Test Environment

1.2 Attack Scenario Design

This benchmark represents the worst-case attack against EXTCODESIZE:

• 18,100+ unique contracts deployed per size (forces code cache misses)
• Each block reads bytecode from all unique contracts exactly once
• Code cache hit rate: <2% (effectively disabled)
• OS page cache cleared between benchmark runs

1.3 Raw Disk Baseline (fio)

To establish theoretical maximum performance, we measured raw NVMe capabilities:

2. Benchmark Results

2.1 Code Read Time vs Bytecode Size

7907_violin_code_read_time1800×1050 91.5 KB

7907_code_read_vs_size1500×900 55 KB

Core Finding: Code read time scales with bytecode size when cache is ineffective.

Key insight: Code read time grows 8.5x as bytecode size grows 128x. This is sub-linear scaling (not 1:1), but the absolute time impact is significant.

2.2 Bytes Read vs Code Read Time (Correlation)

7907_code_read_vs_total_bytes1500×900 76 KB

The strong positive correlation (R² ≈ 0.96) confirms that code read time scales with total bytes read when caches are ineffective.

2.3 Per-Call Latency

7907_per_call_latency1500×900 59.1 KB

Per-call latency grows with bytecode size:

3. Execution Time Breakdown

3.1 Component Analysis

7907_time_breakdown_stacked1800×1050 69.2 KB

Code read becomes the dominant factor at larger bytecode sizes:

Observation: At 64KB, code read consumes 90% of block execution time. This is dramatically different from warm-cache scenarios where code read is only 8-10%.

4. Block Time Budget Analysis (EIP-7907 Focus)

4.1 Time vs Budget Target

7907_block_time_budget1500×900 60.4 KB

Using a 1-second target for block execution:

Conclusion: 64KB contracts are viable under worst-case attack conditions at 60M gas blocks. The ~1-second execution time is at the budget limit but acceptable. Note that this is a quite conservative limit considering ePBS & BALs will likely reshape what we consider a safe budget in the near future.

4.2 Gas Processing Rate (Mispricing Analysis)

7907_mgas_vs_size1500×900 64.3 KB

Mispricing observed: Same gas cost, but 5x different execution time (236 Mgas/s → 49 Mgas/s). This indicates that under worst-case conditions, larger contracts impose disproportionately higher cost on validators.

Implication for 128KB+: Beyond 64KB, a gas model adjustment would be needed—likely a base cost plus size-dependent component.

Notice this is quite conservative. As in order to “halt” the network or “significantly hurt slow validators”, the setup required would be of hundreds of times the 18k unique contracts. Which incurrs on a massive costs (we can’t reuse them as they would be cached after the first block execution).

5. Raw Disk Baseline (Geth vs NVMe Efficiency)

5.1 Efficiency Comparison

7907_geth_vs_nvme2100×900 64.7 KB

Observation: Geth achieves 20-51% of raw disk performance. The gap is likely due to:

• Pebble/LevelDB overhead (index traversal, bloom filters)
• Key hashing and lookup
• Value deserialization

6. Comparison with Warm Cache Scenario

6.1 Cached vs Uncached Performance

7907_cached_vs_uncached1800×900 64 KB

The “flat cost” finding from warm-cache benchmarks remains valid for normal operation. Cold cache conditions require extreme attack scenarios (18K+ unique contracts).

7. Implications for EIP-7907 & Recommendations

7.1 Summary of Findings

1. Code read time scales with size under attack conditions (8.5x from 0.5KB to 64KB)
2. 64KB is viable at 60M gas blocks—worst-case ~1s execution, within budget
3. This represents the absolute worst case—18K+ unique contracts is impractical to deploy and maintain (you need a new set for each block you want to run the attack).
4. Normal operation is unaffected—warm cache scenarios show flat ~5ms cost
5. Gas mispricing exists under attack (5x execution time variation for same gas)

7.2 EIP-7907 Recommendation

It seems we can just “keep it simple” and provide Smart Contract developers a nice upgrade on the codesize limit without any changes to the protocol besides the 64kB limit and the initcode size increase.

Once we have BALs and ePBS on a more ready state, we will be in a position where data will guide us better towards a good decision on repricing/just proceed to 256kB.
But it feels unnecessary to do a repricing now for something that doesn’t really need it even in it’s worst case.

7.3 Why 64KB is Acceptable

1. Attack impracticality: Deploying 18K+ unique 64KB contracts requires:

   • ~13M gas per contract deployment (32K base + 64K × 200 gas/byte)
   • Hundreds of blocks just for setup
   • Significant ongoing cost to maintain attack surface

2. Block time within budget: Even worst-case ~1s is acceptable for 60M gas blocks

3. Cache effectiveness in practice: Real mainnet blocks reuse contracts; code cache hit rate is typically high

4. Sub-linear scaling: 8.5x time for 128x size growth indicates amortization still helps