Hyperledger Besu is Hyperledger's Principal Ethereum project. It is focused around 3 key pillars: a fully functional client for public networks, a customizable client for private networks, and libraries to support the use of Ethereum technologies in Besu and other projects.

  • Fully Functional Client for Public Networks
    Besu explicitly and "out of the box" supports the following networks, including planned future upgrades
    • Ethereum Mainnet
      • Pre-Merge Ethash Proof-of-Work Client
      • Post-Merge Execution Client, pairablre with any fully-functional Consensus Client such as Lighthouse, Loadstar, Nimbus, Prysm, or Teku
    • Ethereum Mainnet Testnets
    • Ethereum Classic
    • Ethereum Classic Testnets
  • Customizable Client for Private Networks
    • Multiple Consensus Engines such as Clique, IBFT2, or QBFT.
    • Optional private transaction technology
    • Optional Integration with Privae Enclaves such as Tessera
    • Optional  Node Access
  • Libraries to support the use of Ethereum technologies
    • EVM Engine Library


To support these 3 pillars are the following 6 systems.

  • EVM Engine
  • Consensus Protocols
  • Peer-to-peer communications
  • JSON-RPC Communications
  • Data Storage
  • Block Production
  • No labels

3 Comments

  1. Sally MacFarlane

    We've been having discussions in our team about making privacy a plugin - or at least modularising it out better. One complication though is that GoQuorum-compatible privacy is more tightly coupled in with the mainnet code.

  2. Gary Schulte

    I think as part of the roadmap we should list explicit support for modular blockchain in general.  The future of ethereum and arguably blockchain in general is modularity.  Besu has started down this road already:

    • Besu as an execution engine, whether in the merge or in support of roll-up chains
    • Block proposer/builder separation and MEV are not yet implemented in besu, and arguably can be fit into the existing systems description under 'block production' and 'p2p'.  But since this is a deviation from the monolithic blockchain paradigm it is might be worth mentioning explicitly as a targeted/supported configuration.

    Also, as discussed on the HLF besu-contributors call I think there is broad support for use-case-specific artifact creation.  Besu can support many different networks, consensus mechanisms and use cases, but the UX leaves a lot to be desired.  Distribution artifacts can include just the features, configurations, and defaults necessary to support their use case, e.g.:

    • Ethereum PoW mainnet
    • Ethereum Classic
    • Execution engine in PoS or roll-up chains
    • Private/consortium chains

    This should improve the UX, decrease attack surface, and allow for greater agility for R&D efforts.  Whether we want to support distributions as part of the monolithic repo or create distribution-specific "sub-repositories" is an open question.  

  3. Justin Florentine

    I love this whole proposal. I fully expect the partitioning of Besu into modules to be difficult, but incredibly valuable. 

    When we start to talk implementation details, there is a design issue I would like to make sure is considered early: cross cutting concerns. For instance; EVM, consensus, p2p, etc all have similar concerns like security and observability within their modules.

    I think using the EVM isolation that has already been done as a case study would be helpful. I would love to hear what value that has added (is Hedera using it?) and what kind of lessons we learned from it that can be applied to other cases.