18 posts tagged with "execution"

Erigon 3.5.0 landed with a very good headline: parallel block execution is on by default. That should make Ethereum block validation feel less serial, at least where the workload and configuration let it pay off.

The builder-class telemetry I checked had the opposite shape. Two observed Erigon 3.5.0-dev-8b4c6990 nodes processed the same 7,174 mainnet payloads as the other eip7870 builder nodes. Giving every implementation its fastest observed node in each slot, Erigon's median was 283 ms. The fastest non-Erigon observation in each slot had a 24 ms median; Reth's own per-implementation median was 25 ms. Erigon won one fastest slot.

Storage diffs sound like state growth. Sometimes they are just a tiny piece of state getting hammered over and over. Last week one contract labelled Oracle changed the same three already-nonzero storage slots 117,150 times, spread across 39,050 transactions. By June 19 it was showing up in about five out of six canonical blocks.

Correction, 2026-07-14: I called these rows "logical execution instrumentation for ETH balance reads." The count was right, but the noun was wrong. Xatu gets this table from Cryo's projection of Geth's prestateTracer, so each row is a transaction-account prestate record, not a BALANCE opcode or repeated-read counter. The fee-recipient one-row-per-transaction result survives. I wrote up the correction here.

USDT was not the hottest address in the balance-read table.

I expected the usual suspects: USDT, USDC, WETH, routers, precompiles, some unlabeled contract that every block touches. They are all there. But the biggest line in the one-day sample was a builder fee recipient, because the execution path records a balance read against the block author once per transaction.

That sounds obvious after you see it. It was not obvious from the table name.

The new Xatu execution tables are exactly the kind of thing I like: raw enough to be dangerous, tidy enough to query without crying. Then I opened canonical_execution_native_transfers and got a very silly-looking leaderboard.

USDT was the top native-transfer recipient.

I opened the new contract-creation table expecting the usual factory soup: account abstraction wallets, Uniswap pools, NFT leftovers, random deployer spam. XEN was sitting in the middle of it again, quietly copying the same tiny contract over and over.

Not metaphorically tiny. Forty-five bytes.

Ethereum block execution isn't a fixed-cost operation. For small blocks the state LRU cache handles nearly everything. But push past ~45 Mgas and something breaks: cache misses compound, state reads triple in overhead, and p95 execution latency blows past 100ms for a single block.

Nobody talks about this because mgas/s benchmarks measure throughput — not the hidden cost of cold cache reads. The gas limit doubling from 30M to 60M made this matter.

I started this looking for evidence that high-MEV blocks are harder for execution clients to process. The intuition is obvious: MEV blocks are full of complex DeFi interactions, sandwich attacks, arbitrage — all the state-thrashing stuff. Surely they're heavier to execute.

They're not. The correlation between MEV block value and newPayload execution time is r = −0.004. Essentially random noise.

What actually predicts execution latency is simpler and more boring: how much gas the block used.

Analyzing 52,104 blocks over 7 days: mean interval is 12.05s, median is 12s. Only 0.38% of blocks are delayed beyond 12 seconds. The network maintains remarkably tight timing.