2021 Q1 Hyperledger Besu
Created by Grace Hartley, last modified by Arun S M on Apr 29, 2021
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.
- Have you switched from master to main in all your repos ? No, awaiting final Berlin Mainnet activation then will switch
- 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
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 makes it easy to create a config file for an Ethereum client at startup
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.
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:
- London network upgrade
QiBFT a cross-client BFT algorithm specified by the EEA.
- 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.
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)
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.
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
- ✅ Angelo De Caro
- ✅ Arnaud J Le Hors
- ✅ Arun S M
- 🔲 Baohua Yang
- ✅ Bobbi Muscara
- ✅ Danno Ferrin
- ✅ David Enyeart
- ✅ Gari Singh
- ✅ Grace Hartley
- ✅ Hart Montgomery
- ✅ Maria Teresa Nieto
- ✅ Mark Wagner
- ✅ Nathan George
- ✅ Tracy Kuhrt
- ✅ Troy Ronda
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