Besu makes Ethereum RPC calls less brittle

Besu published version 26.6.1 of its Ethereum client on June 17, with a small but meaningful change for teams running nodes or chain access services. Several JSON-RPC calls, including eth_getBalance, eth_getCode, eth_getStorageAt, eth_getTransactionCount, eth_getProof, and eth_getStorageValues, now accept a missing block parameter and default it to latest. JSON-RPC is the interface applications, wallets, explorers, and indexers use to request data from a node.

The change looks minor, but it sits in a sensitive compatibility zone between Ethereum clients. Before this release, Besu rejected those requests when they did not specify the target block. Other execution clients already accept the same pattern by treating the missing block as a request against the latest known state. Besu is therefore aligning with that behavior, which can reduce hard-to-debug failures in services that need to work across several RPC providers or switch from one client implementation to another. For an application team, the visible effect may simply be that a call keeps working after a provider change, without any user-facing feature being added.

The release also fixes a bug around engine_getBlobsV2 during full sync on post-merge networks, such as Hoodi. The official note says Besu could return UNSUPPORTED_FORK while the node was still catching up. The fix makes the client recognize the syncing state more accurately, so it does not validate the request as though its pre-fork chain head already represented the final context. For operators, this is not a visible user feature, but it matters in the phases when a node is coming back into service or joining a network from scratch. Those sync windows are exactly where monitoring can blur temporary noise with genuine failure.

Besu 26.6.1 is described as an optional update, not an urgent protocol deadline. That is exactly why it is worth watching. Blockchain infrastructure often improves through edge-case adjustments that make production stacks less brittle. The release also repeats several upcoming deprecations, including the planned removal of Proof of Work consensus from Besu and the renaming of some experimental options. For Ethereum teams, the practical message is straightforward: check RPC assumptions, test clients while they are syncing, and handle deprecations before they turn into breaking changes. A small client release can become a useful rehearsal for cleaner operations.