Reth speeds up Ethereum execution

Reth 2.3.0, published by Paradigm on June 10, brings a measured performance gain to the Rust-based Ethereum execution client. The release notes say benchmark throughput moved from about 1.4 to 1.5 Ggas/s, an 8.1% increase, through improvements to parallel execution, payload building, tries (the data structures used to index state), and the transaction pool. This is not a broad marketing claim about speed. It is a plumbing change for operators and developers who build, relay, or verify Ethereum blocks.

The point matters because of the role an execution client plays in Ethereum. It applies transactions, maintains chain state, and communicates with consensus clients. When that layer becomes faster and more predictable, validators, block builders, infrastructure providers, and application teams get more headroom. Reth 2.3.0 targets several of those friction points: cheaper transaction-pool insertion, faster proof and trie paths, reduced payload-building overhead, and correctness fixes around eth_simulate, proof deserialization, chain-state overlays, RLPx buffering, and database handling for RocksDB and MDBX.

The release also advances support for Block Access Lists, or BALs. A BAL describes in advance which parts of state a block is expected to touch. In simpler terms, it can help clients prepare the work instead of discovering every access during execution. Reth adds BAL validation, storage, networking, RPC, and payload-builder support in this version. That is still a technical layer, but it points to a larger Ethereum direction: better knowledge of state access can make execution more parallel, easier to reason about, and less costly to verify.

Paradigm’s notes say node operators using default configurations do not need migration steps. The action item is mainly for SDK users and teams with custom integrations around payloads, transaction pools, or consensus, who are told to review breaking changes. The useful signal is understated: Ethereum capacity does not only move through highly visible hard forks. It also moves through client releases that make execution faster, better instrumented, and less brittle for the infrastructure that keeps the network running.