Reth multiproof chunk size benchmark - 10M gas blocks

chunk-size-benchmark-report.md

Multiproof Chunk Size Benchmark Report

Date: 2026-02-16
Commit: f5cf90227b (reth main)
Machine: dev box, 7.8TB NVMe, multi-core
Payload: 345 blocks × ~10M gas each (blocks 24,463,559–24,463,903), gas_limit=60M
Method: reth-bench replay-payloads with --wait-for-persistence --wait-time 400ms

What was tested

The --engine.multiproof-chunk-size parameter controls how many proof targets are grouped per parallel multiproof computation task during state root calculation. Smaller chunks = more parallelism, larger chunks = fewer tasks with more work each.

Default is 60 (V2 proofs use 4× = 240 internally).

Results

Chunk Size	Exec Ggas/s	NP P50	NP P95	NP P99	NP Mean	FCU Mean
15	1.1968	9.73ms	14.88ms	17.62ms	10.32ms	0.30ms
30	1.1969	9.77ms	15.02ms	18.75ms	10.33ms	0.30ms
60 (default)	1.1828	9.81ms	14.84ms	17.37ms	10.44ms	0.31ms
120	1.1507	10.15ms	14.88ms	17.12ms	10.76ms	0.29ms
240	1.0647	11.23ms	15.18ms	17.98ms	11.64ms	0.30ms

Key Findings

1. Chunk size has minimal impact at ~10M gas blocks — all configs within 0.13 Ggas/s of each other (1.06–1.20 Ggas/s).

2. Smaller chunks (15–30) are marginally better — ~1.2% faster than default (60), likely because the ~10M gas blocks have relatively few state changes (~100–175 txs), so smaller chunks distribute work more evenly across workers.

3. Larger chunks (120–240) degrade performance — chunk=240 is 10% slower than chunk=30. With fewer state changes per block, large chunks create fewer parallel tasks, underutilizing available cores.

4. The default (60) is reasonable — it's only 1.2% slower than optimal. The difference is within noise for most practical purposes.

5. P99 latency is similar across all configs (17–19ms), suggesting the tail is dominated by block-specific factors (e.g., heavy state access patterns) rather than chunk size.

Methodology Notes

• All runs used reth stage unwind between runs (takes ~23s) to ensure fair comparison with warm OS page cache
• Each run included a warmup pass (30 blocks) before the measured 345-block run
• FCU latency is negligible (~0.3ms) across all configs — state root is the bottleneck

Conclusion

For ~10M gas blocks, the default chunk size of 60 is near-optimal. Chunk size tuning would be more impactful on larger blocks (30M+ gas) where there are significantly more state changes per block. Consider testing with higher gas targets to find where chunk size becomes a meaningful lever.

combined_latency.csv