LoginSign Up
← Back to all sparks
H

Hyperledger Besu

FINANCE
Velocity2.5

Enterprise grade Ethereum client for finance workloads

besu.hyperledger.org ↗

Besu tags a release candidate a month, and half of them are titled after changelog chores.

ethereumexecution-clientsnap-syncmemory-boundingrelease-process
◆Current state
Besu cuts a release candidate roughly monthly, and the feed titles each one after whatever commit sat at the head — which means 26.7.0-RC1 and 26.6.1-RC1 are presented to readers as changelog preparation rather than as releases. The candidates with substantive head commits show where the engineering attention is: bounding precompile result caches with a uniform memory ceiling, and fixing a snap-sync probe that treated an empty response as proof a range was fully covered.
◆Where it's heading
The visible work is client resource discipline and sync correctness — the unglamorous half of running an execution client, where a cache without a byte ceiling becomes an operator's memory incident and a sync helper that short-circuits leaves silently missing state. Both fixes are the kind found by reasoning about edge cases rather than by feature planning. The release process itself is the other story: an Unreleased section had to be folded back into 26.5.0 because RC2 was cut from the head of main, which is a process seam rather than a code change.
◆Prediction
The monthly release-candidate rhythm should continue; based on these entries the substantive changes will keep landing in sync correctness and memory bounding rather than in new operator-facing features.

◆Recent moves

  1. 25d ago

    26.7.0 release candidate

    A release candidate whose head commit — and therefore whose title in the feed — is changelog preparation. What else the 26.7.0 candidate contains is not visible from the release entry itself.

    View source ↗
  2. 1mo ago

    26.6.1 release candidate

    Another candidate titled after a changelog rotation commit. As with 26.7.0-RC1, the entry documents the release process rather than the release.

    View source ↗
  3. 2mo ago

    26.6.0-RC1 fixes snap sync treating empty responses as complete ranges

    A snap-sync correctness fix: the range helper short-circuited when a responder returned no keys, so the caller assumed the requested range was complete. The request's start hash is now plumbed through so an empty response still triggers a follow-up probe, closing a path where state could be silently skipped during sync.

    View source ↗
  4. 3mo ago

    26.5.0-RC2 folds Unreleased notes into the 26.5.0 changelog

    Pure release bookkeeping: entries filed under Unreleased were folded into the 26.5.0 sections because cutting RC2 from the head of main made them part of that binary. No code change, but it explains why the 26.5.0 notes grew after RC1.

    View source ↗
  5. 3mo ago

    26.5.0-RC1 caps precompile caches at 16 MB and keys them on semantic input

    Precompile result caches are now keyed on the semantic input prefix each precompile actually reads, so trailing bytes stop creating distinct entries, and all fourteen caches gained a 16 MB byte-weight cap. This converts an unbounded memory surface into a fixed ceiling operators can plan around.

    View source ↗