We started to build Grandine back in 2019 when there were already two Rust Ethereum 2.0 clients at that time — Lighthouse and Shasper. So the space was already crowded with two Rust clients and multiple other clients written in other languages. The only realistic option we had was to raise non-public-goods funding and experiment in stealth mode. We aimed to explore the possibility of converting our efforts into a public good if we succeeded in creating something valuable for the community. The positive feedback from early adopters of our pre-releases fueled our commitment to open-source Grandine.
What is Grandine?
We had a goal to build a very fast and lightweight Ethereum client. So we built an original core that focused on parallelisation and low memory footprint. The set of the initial ideas Grandine was built around is quite different from other clients, especially compared to another Rust client Lighthouse:
* Grandine had an original fork choice implementation when every other client used the protoarray fork choice. This approach helped to find a bug in protoarray implementation;
* Grandine uses tree-states from the beginning. The entire client is built around the idea that states are cheap. It is a very different architecture compared to the clients based on flat states;
* Grandine was an in-memory client without any persistent storage for a long time. This approach contributed a lot to the high performance and low memory footprint, and made our storage layer very thin — it’s possible to add another database backend by only writing ~100 lines of code;
* It had a built-in validator client from the beginning. It’s not the best architecture in the long run because a separated client is a more flexible architecture, however, it’s a very light approach in line with our initial performance and lightness goals.
People often ask us if Grandine is a fork of Lighthouse. It’s not. Grandine started with a different design idea that led to a different core consensus implementation. However, it doesn’t mean that Grandine doesn’t use excellent libraries maintained by other client teams. For example, Grandine uses “rust-libp2p” based networking libraries developed by the Lighthouse team since the beginning. Lighthouse’s “eth2_libp2p” library was generic back then and we still use a fork of it now. We also used “libmdbx-rs” bindings library by Akula maintainer and now we use a fork of it maintained by Reth team. So we focus on the original consensus core because it’s the unique value Grandine offers for the community, but we also love to use some great crates developed by other client teams and the community. We also love to build libraries such as “rust-kzg” that are useful for the other client teams too. Grandine would not be where it is now without the efforts of the other client teams and the community! Huge thanks to everyone!
Who can use Grandine?
Grandine is both a high-performance and lightweight client. It means the client fits a wide range of stakers from solo stakers running on low-resource devices such as Raspberry Pi to large institutional stakers running tens of thousands of validators. We already see adoption growing among solo stalkers who are looking for a fast and lightweight client. We believe that this adoption gradually will reach larger institutional stakers because the client can handle a huge amount of validators per machine which converts to significant savings. For example, we run 50,000 Holesky validators on one of our developer’s machines. It’s virtually no cost to run that many validators!
What’s next?
We are going to fully focus on user feedback in the coming months. Very often new users report to us details that are relatively easy to implement and it makes the client more finished. Now is the best time to become an early adopter because your feedback will get the most attention. In parallel, we will get more involved in the activities that the other client teams are involved in, such as participation in early testnets for new hard forks, protocol research, etc. Longer longer-term focus will be on the larger structural changes such as a separate Validator Client. We also will need to fully convert to a public goods project. This also means public goods funding and revenue models involving Grandine such as node operators activities because the funding model we had so far just doesn’t work in the open-source public goods model. So if you love Grandine we will appreciate your efforts in supporting us. We thank everyone who supported us so far (Optimism Retro PGF etc.)!
What are the long-term goals?
Our first long-term goal is to help diversify the Ethereum consensus layer to the point where every client has less than 1/3 of mainnet validators share. This not only would mean that a single client bug can’t cause non-finality, but it also means that it requires the same bug in at least 3 clients to finalize an invalid chain. The community has already successfully migrated away from having a super-majority consensus layer client and we are eager to see the next step achieved. It will only happen with the support of the community! So let’s do it together!
Special thanks to Thorsten Behrens, Isidoros Passadis, James Smith for feedback on the draft of this announcement.
