Diagnosing Performance Divergence in Ethereum Execution Clients

Abstract

Ethereum execution clients implement identical Ethereum Virtual Machine (EVM) semantics, yet can exhibit substantially different performance in practice. We study this divergence through a three-step systems analysis of two representative clients, Geth and Reth. First, across historical synchronization, live synchronization, and transaction replay, we show that Reth is markedly faster whenever repeated local execution dominates, reducing historical local processing by 3.69× and replay time by 6.87×, while Geth is 2.70× faster end-to-end in live synchronization because verification and canonical commitment lie on the critical path. Second, by replaying 100,000 mainnet blocks and attributing runtime to individual opcodes, we show that this performance gap is overwhelmingly concentrated in read-side state access: SLOAD alone explains 95.8% of the measured inter-client difference, with further asymmetry concentrated in account- and code-lookup opcodes. Third, in a public-view builder case study, we use this diagnosis to reduce how much candidate evaluation reaches the expensive exact-simulation stage: on a frozen test split of 886 blocks, an XGBoost prefilter at top-0.1% ratio to top-2.0% ratio reduces checked candidates by 254,708 to 604,776 relative to an effective-priority-fee baseline at matched Flashbots-hit levels, while speeding the ranking-and-selection stage by about 1.75×. These results show that execution-client divergence is best understood as a critical-path problem: the same semantic interface can expose very different bottlenecks depending on how state access, verification, and workload structure interact.