2021 Q1 Hyperledger Besu

Created by Grace Hartley, last modified by Arun S M on Apr 29, 2021

Hyperledger Besu

Project Health

Hyperledger Besu remains a strong project with a growing community network of contributors. This quarter the team has focused on Ethereum protocol improvements as well as many performance improvements, included in the Hyperledger Besu 21.1.0 Release, which was launched on February 24th. The team is currently building towards its Q2 2021 release.

Required Information

  1. Have you switched from master to main in all your repos ? No, awaiting final Berlin Mainnet activation then will switch
  2. Have you implemented repolinter.json in all your repos ? Yes, via github actions.

Questions/Issues for the TSC

We continue to have issues with contributors giving up committing when encountered with the DCO sign off, especially with  documentation requests. Any suggestions on how to make the process easier and with less friction would be appreciated.

One possibility is to relax the DCO check  within  the PR for repositories who only do squash-merges and if the contributor makes a clear and unambiguous statement in the PR comments that their contribution conforms to the DCO standards. The commits to any main or non pull-request branch, however, would still require a DCO  Signed-off-by  line.

Releases

Hyperledger Besu has completed seven  releases, including the quarterly major release cycle of 21.1.0. The releases included 20.10.2 on Dec. 16th, 20.10.4 on Jan 13, 21.1.0-RC1 on Jan 27th, 21.1.0-RC2 on Feb 10th, 21.1.0 (full release) on Feb. 24th, 21.1.1 on March 8th, 21.1.2 on March 15th. We had an extra release in addition to our regular bi-weekly schedule because we identified a bug related to the Berlin Hard Fork that we needed to fix.

Some functional improvements include:

Berlin Network Upgrade 

The team has been preparing Hyperledger Besu to be compatible with the next Ethereum hard fork, Berlin. The   Berlin Network upgrade   will include several improvements to the Ethereum mainnet, such as the addition of subroutines to the EVM, the introduction of “transaction envelopes”; which make it easier for Ethereum to support several different kinds of transactions, and changes in gas costs to increase the security of the network.

Mainnet Launcher

Mainnet Launcher makes it easy to create a config file for an Ethereum client at startup

Node Hibernate:

This is  a proxy that monitors a node’s API traffic and hibernates the node when inactive. This reduces infrastructure costs by ensuring only nodes receiving API requests, or nodes required to establish consensus are running.

Bonsai Tries – Early Access Bonsai Tries is a new database format which reduces storage requirements and improves performance for access to recent state. While this feature is being developed as a way to deal with mainnet’s large state size, any network with a comparable state could benefit from it. With Bonsai Tries instead of a multi-trie key value store, there is one trie, one set of indexed leafs, and a series of diffs that can be used to move the trie forward or backwards. This will reduce chain head count and state read and write amplification from its current 10x-20x levels to 1x-2x for non-committed access. This feature is early access and may break between each release, and is hence not production recommended yet.

Go to the   Changelog   for more details.

Overall Activity in the Past Quarter

There have been some significant maintainer contributions from decentralized maintainers

  • Bonsai Tries by Danno Ferrin in an individual capacity.
  • OpenTracing support langed provided by Antoine Tolume from Splunk.

The remainder of the maintainers have been focusing on continuing mainnet compatibility work and adding cross-client support for GoQuorum within the Besu codebase.

Current Plans

  1. The project team remains currently working towards its 21.4.0 Release, scheduled forJuly of 2021. The 21.4 Release is expected to include the following features:

    1. London network upgrade
  3. EIP-1559

  4. QiBFT a cross-client BFT algorithm specified by the EEA.

  5. Similar to last quarter, Besu is also continuing to engage with its community and grow the diversity and decentralization of its maintainer and contributor base. 

Maintainer Decentralization

Our maintainer decentralization had a small increase from the prior quarter. Danno Ferrin has moved from ConsenSys to Reddit, but will continue to contribute in a personal capacity. David Mechler has moved to earn.com.

The four organizations include:

  • ConsenSys Quorum (FKA PegaSys)
  • Web3Labs
  • Chainsafe
  • Splunk 

We are in the process of voting on making 3 maintainers emeritus status and adding 1 new maintainer. There were no other changes to the maintainer roster.

Prior to the pending actions 5 of 23 (21%) maintainers were non-ConsenSys. The maintainers breakdown if all the pending actions pass is:

  • 19% non-ConsenSys (4 of 21) - an increase of 3% from last quarter. 

Contributor Diversity

LF Analytics for Besu from 8 Dec 2020 to 22 Mar 2021

Commits from  2020-12-08 to 2021-03-22 : 262

Committers from 2020-12-08 to 2021-03-22:  26 (13 non-PegaSys)

Identified Orgs   2020-12-08 to 2021-03-22:  5

Additional Information

Reviewed By

Comments:

The DCO issue has been something that we have talked about as a TSC for pretty much forever, but have never really done anything about.  

Here's my "dream" solution (not necessarily practical):  I've always maintained that we should tie github IDs to LFIDs.  When you want to issue a PR, you have to first create an LFID where you list your github account (note that this linking is not necessarily public–only the LF needs to know the connection between your LF account and github).  You can sign some kind of generic DCO when you create an LFID.  When you want to issue a PR to a HL repository, your github gets checked against the approved list from the LF.  If you don't have an LFID and try to create a PR, you are just prompted to get an LFID (which takes a couple of minutes max, and honestly should be lower friction than dealing with the DCO).  This also means that repeat contributors only have to deal with DCO once, which is nice.

This would take a number of changes from not just us but the LF as well, so it's not totally practical.  But I'd definitely be curious to see if you all (as the relative newcomers to HL) have some fresh ideas for DCO.  Thanks for the report!

Posted by hartm at Mar 22, 2021 21:44

... contributors giving up committing when encountered with the DCO sign off


Why are they giving up?

Posted by mastersingh24 at Mar 25, 2021 07:08

Their first PR doesn't have a DCO line, usually because they didn't read CONTRIBUTING.md, or because they forgot to add the CLI switch or IDE checkbox. They then see the build errors (because the DCO check in github from hyperledger validates PRs). one of the maintainers gives the CLI incantation to add the DCO. Contributor ghosts us.

Posted by shemnon at Mar 25, 2021 13:58