Grandine 0.4.0 and 0.4.1 releases are the first release series after our Ethereum consensus layer client was opensourced. It’s a huge release with new features, performance improvements, and fixes. So this post will cover only a small part of the changes.
Holesky optimizations
This release contains numerous optimizations implemented after we started to run 50,000 Holesky validators on one of our developer’s machines. The goal was to confirm that it’s possible to run a huge amount of Ethereum validators at virtually no cost on a machine with an existing workload and some spare resources. It was a fun experiment at first, but eventually, it yielded multiple optimizations that improved the overall performance of the client on the mainnet.
A new attestations packer
The new attestation packer that aims to optimally pack attestations was shipped in this release. Attestation packing is an NP-hard problem so clients usually use heuristic algorithms that are fast and not always optimal. Finding the optimal solution is time and resource-intensive. For this reason, we start packing 1 second before the slot and repack if there is still some time left until the slot to include the attestations that arrive after the start of the previous packing. Our testing shows that our algorithm can pack attestations significantly better than other clients when participation rates are not very high and slightly better in nearly ideal mainnet conditions. This leads to a slight rewards improvement for mainnet validators and significantly better packing during turbulent conditions.
In-memory mode
In-memory mode is another interesting feature. Grandine was an in-memory-only client at the very beginning. However, at some point the chain became too large to fit into memory so we added a thin persistence layer. We refactored that layer to make adding a new persistence backend much easier. So now Grandine not only can run on diskless systems, but it’s also way easier to add a new persistence backend.
Compatibility with other VCs
This release includes numerous improvements achieved during integrations with the Ethereum ecosystem. Ethereum Foundation DevOps team tested Grandine BN against Lighthouse, Prysm, Teku, Lodestar, and Nimbus validator clients. It helped to find minor incompatibilities with some of the validator clients. After these fixes, Grandine is compatible with Lighthouse, Lodestar, Nimbus, Prysm, and Teku validator clients. In addition to this, we continuously test Grandine with Vouch. Let us know if you find any incompatibility between your service and Grandine BN. Thanks to @BarnabasBusa and @_pk910_ for testing.
Eth-docker integration
We also implemented multiple new features (Keymanager API, etc.) needed for integration with Eth-docker. So now everyone using Eth-docker can easily switch to Grandine. It’s also probably the easiest tool that allows you to easily setup and try Grandine. Thanks to Yorickdowne for the feedback and integration!
Ethereum on Arm integration
Ethereum on Arm is another exciting integration. Grandine is not only high-performance Ethereum consensus client. Grandine is a resource-efficient client too. It needs less than 3GB of memory on the mainnet. Such a low footprint makes Grandine a great fit for low-cost and energy-efficient ARM machines. Thanks to @ethereumonarm for integration and testing on ARM.
Audit
We started the auditing process with an automated audit conducted by the Antithesis team. The Antithesis team was impressed by Grandine's performance because Grandine never got stuck or crashed during the testing. The client was very robust during Antithesis audit, and only minor issues were discovered that we are addressing.
What’s next?
The stable release is shipped and the team is busy working on Electra hardfork for devnet-0. After the interop, we are going to shift focus towards improving the client further based on the feedback we received so far. A separate Validator Client is one of the biggest upcoming features together with further optimisations. Stay tuned!
