So, we've Merged...

Thank you again for your patience in using and testing minority clients as we strive to create a top-tier Mainnet client in Besu. The Merge was a bit of a bumpy ride for Besu, though, as it exposed a number of issues that slipped through the cracks in testing. We know many of you experienced missed attestations and production of empty blocks, and some of you had issues with sync and the database. Now that we have collected ourselves from the 22.7.x release series, which saw many improvements, we have more to share on our progress going into our next quarterly release 22.10.0.

For the Stakers

We have tuned performance in many areas to specifically target attestations. There are also changes to the transaction pool to avoid transactions that are NOT executable (#4425) to keep blocks profitable and full for stakers, without reverted or empty transactions taking up block space in proposals. We have also added some DOS mitigations around future transaction spam and single users filling the pool (#4417). 

There are a number of changes around attestation performance, but we’ll list a few. In many cases, Besu was missing attestations due to not importing the block fast enough for the consensus client to attest to it and share its vote with the network. This block import step has to be completed in around a second to be of value. 

To address this requirement, we have made changes in Besu including:

  • Threading and memory usage, 

  • Database upgrades (#4517),

  • Added additional caching, 

  • Parallelization to hashing calculations to process and validate blocks as fast as possible, which will help with attestations and other operations like Full sync time (#4568),

  • Introduced performance improvements in the EVM (thanks to Swirld Labs contributors #4540),

  • Updated native cryptographic libraries to more performant versions, 

  • Tweaked the Engine API to improve performance with the Consensus Layer,

  • Cleaned up errors and introduced fixes to improve performance and user experience.

A lot of these updates have too many code changes to list, so I encourage you to check out the full changelog here!



Resilience Improvements

We have made a big change to Bonsai to incorporate snapshots that will greatly improve its resiliency. This new feature can be enabled with the flag --Xbonsai-use-snapshots=true. If you have seen the dreaded “worldstate root mismatch” in your terminal, this feature will allow for a much more robust rollback/forward and retry mechanism in Bonsai that will make it more stable in Proof of Stake networks (#4409) that are re-org heavy. You can read more here about how Bonsai supports stakers by reducing storage requirements.

Some grab bag items are tweaks to sync that many users will find helpful. We have tweaked logging to be more clear on sync progress and what stage is occurring (#4486), have refactored snap sync specifically for Proof of Stake networks (#4462, #4488), and have added a mechanism to allow for resumption of snap sync after a failure or restart (#4381). This update also includes small bug fixes galore. 

What's Next

We are not done yet! For lower-powered hardware such as RasPi that may still struggle with performance, we are implementing changes around the database to flatten it and provide faster access while reducing IO that may slow down attestations. We also have more parallelization improvements for hash calculations for attestation performance. Importantly, Besu is prototyping changes for Ethereum’s upcoming Shanghai hardfork! 

Again, I want to extend a big thank you for helping secure Ethereum’s decentralization and economics by choosing a minority client. We are still improving and hope you can enjoy Bonsai and some of the other great features in Besu to help keep your staking rig lean. 

Reach out to us on Discord to report bugs and test with the team, or to connect with us for advice on hardware and software set-ups, configuration details, and more. We'll keep building, stay tuned!