Besu : Besu Roadmap & Planning

Created by Felipe Faraggi, last modified by Matthew Whitehead on Oct 02, 2024

The Zenhub has up-to-date Epics that Besu development is targeting over various releases. See the roadmap tab on the Public Zenhub here: https://app.zenhub.com/workspaces/hyperledger-besu-61fc06f457da1c0017f6347d/roadmap

This document represents the current working roadmap for Besu. It is a living document, which will evolve and change over time. In particular the features in later versions are likely to change.

We use the approach of #now, #next, #later used by foursquare, with a slightly different time horizon. Our #now scale is about 3 months, #next about 6 months, and #later is 12+ months.

The enterprise roadmap is currently led by Matthew Whitehead from Kaleido. To discuss the enterprise roadmap items reach out to matthew.whitehead on the discord server.



Public Roadmap

Enterprise Roadmap

Now

Node Operator Experience

Related releases 24.1.x

- Bonsai-friendly Archive Mode

- Besu as the Linea client

- Sync improvements, speed & robustness

- Besu as a Snap Sync Server

- Verkle Trie ongoing development

- Cancun delivery, Prague scoping/prep


Related releases 24.4.x

- Public / Private network feature parity (sync!)

- Codebase cleanup for better multi-use-case 

- Packaged PoS images for Mainnet with neatly integrated CL client

- Revitalized plug-in strategy, technical documentation

Reduce unnecessary storage

  • Empty-block period (PR merged, due to be included in 24.10.1)

Bonsai archive

  • PR 7475 
  • Part of the journey towards Bonsai replacing Forest DB
  • Make Bonsai an option for retrieving state at arbitrary blocks in the chain

Next

Developer Experience

Related releases 24.7.x

- Besu as a customizable L2/L3 sequencer

- Besu on more Layer 2 networks 

- Prague: dev/test/ship

- Verkle Trie ongoing development

- Modularity of the protocol schedule

- Ongoing performance work

Move QBFT snap sync out of experimental

  • Has been in out since 24.7.1

Bonsai archive with state proofs

  • Build on PR 7475 to provide proofs for historic state

Improve QBFT recovery time

  • Empty block periods make this especially noticeable because the BFT request
    timeout has to be proportional to the empty block period which increase
    BFT recovery times after a node outage

Later

Prague Fork, Client Evolution

Related releases 24.10.x

- Prague: dev/test/ship

- Verkle Tries: 

- Light client exploration

- Besu as a customizable L2/L3 sequencer

- Modularity everywhere

- Ongoing performance work

Ongoing Protocol Research

  • Besu as an Ethereum reference client in Java
  • Verkle Tries
  • History / State Expiry research 
  • Portal network PoC / EIP-4444

Move empty block periods out of experimental

  • Has been in out since 24.7.1