Benchmarks¶
How does SSMT perform against Reth's state root?¶
SSMT's advantage is in state-root computation, and that is where these figures sit. Computing the root is roughly a tenth of the work of committing a block; the write path is most of the rest. A faster root does not make a client proportionally faster, and no client-level multiplier follows from the numbers below.
Benchmarks: Ethereum and Base mainnet¶
Three engines — SSMT, Reth's parallel state-root calculator (v2.3) and Reth's sequential calculator (v2.4) — replayed the same real mainnet blocks on the same box: an EC2 i4i.4xlarge with 16 vCPU, 123 GiB of RAM and NVMe storage. Every computed root was compared against the root the chain actually committed, before anything was written; a run that did not match on every block was discarded rather than reported. On Ethereum the run covered 10,001 blocks (25,930,869–25,940,869), gated 10,001/10,001 on all three arms, with all three engines agreeing on every root.
State-root compute, mean / p50 in ms
| Chain | SSMT | Reth parallel | Reth sequential | × parallel | × sequential |
|---|---|---|---|---|---|
| Ethereum | 19.43 / 16.88 | 43.49 / 38.97 | 256.32 / 221.41 | 2.24× | 13.19× |
| Base | 13.05 / 11.54 | 30.22 / 27.55 | 151.43 / 128.45 | 2.32× | 11.60× |
The compute result is the stable one. It holds across percentiles, and it rises with the work in a block: on Ethereum blocks touching 1,000 or more accounts it reaches 2.94× against the parallel engine.
End-to-end depends on how often the client commits¶
Compute is about a tenth of SSMT's end-to-end cost per block. Persisting the block is about 85% of it. Batching several blocks into a single database transaction is the only real lever on the write path, and the three engines answer that lever differently.
SSMT reads its own uncommitted blocks out of its in-memory trie, so batching costs it nothing on the read side. Reth's parallel workers cannot do this: each unflushed block has to ride in an overlay that every worker reads through, and the compute penalty grows with the depth of the batch until it outweighs the commit saving. This is architecture rather than tuning.
End-to-end ms per block by commit cadence — 1,000 Ethereum blocks, every arm gated 1000/1000
| Commit every | SSMT | Reth parallel | Reth sequential |
|---|---|---|---|
| 1 block | 187.54 | 190.27 | 541.54 |
| 8 blocks | 125.19 | 252.29 | 487.40 |
| 32 blocks | 110.34 | 478.10 | 459.40 |
Batching to 32 blocks makes SSMT about 1.7× faster and Reth's sequential engine 1.18× faster. Comparing each engine at the cadence that suits it best, Reth parallel at 190.27 ms against SSMT at 110.34 ms, SSMT is 1.72× faster end-to-end, and it was still improving at 32 blocks.
Scope
These figures describe state-root computation and block persistence in a benchmark harness, not whole-client throughput. The cadence-32 configuration is a benchmark setting, not an operational recommendation: holding 32 blocks before committing means 32 blocks to replay after an unclean shutdown, and recovery was not measured. The measurement is generous to Reth, whose overlay sort falls outside its own timers. It also charges SSMT for cache maintenance that Reth's harness has no equivalent of, which is the honest trade: SSMT pays on the write path for the caches that make its compute faster.