Nimbus Consensus Layer - past, present, and future

the image above shows 40 of our dependencies purpose built by us for Nimbus and the wider Status ecosystem

It's happening! #eth2 genesis is upon us - stay tuned as we prepare a release with everything necessary to run @ethnimbus!

Thanks to researchers, supporters, other client teams and the community - we're in this together!

— Nimbus (@ethnimbus) November 24, 2020

One year later, and we've barely had a moment to catch our breath!

Since the launch of the Beacon chain last December, we've made a ton of improvements and added a bunch of features to our software. The difference between running a Nimbus node today and back then is night and day.

2021 Highlights

Some high-level highlights from the last 12 months include:

• 26 releases without any major hiccups.

• A close to perfect track record for our internal fleet of validators.

• The first client to release both doppelganger detection and batched attestation verification.

• Successfully shifting the narrative around the importance of client diversity and Ethereum's green credentials.

• Influencing the direction and making contributions to both the spec and EIPs.

• Pushing the limits of what is possible with respect to both CPU and memory usage.

As we touched on in our last post, Nimbus' resource efficiency is not just a nice to have. If decentralisation is the cost to run a full node, then resource efficiency is absolutely crucial to maintaining a sufficiently robust and decentralised network. This is especially true in a post-merge world in which the community is expected to keep block producers in check.

To borrow Dankrad's words:

I don't care about the absolute number of nodes.
I care about the amount of transaction value that is fully secured. That means the user is either running a full node or a fraud proof-protected light client.

— Dankrad Feist (@dankrad) July 14, 2021

Today, Nimbus is able to run performantly on a single core of a Raspberry Pi 4 while also running Geth, RocketPool and monitoring software (Prometheus + Grafana) in the background. We expect this to keep holding true post merge.

We are on it, @go_ethereum Geth + @ethnimbus in the same @Raspberry_Pi. https://t.co/s2lg573Njh

— Ethereum on ARM 🦇🔊 (@EthereumOnARM) June 22, 2021

Perhaps one final thing worth mentioning here is that our language of choice, Nim, has required us to build out nearly all the libraries we rely on ourselves. In the light of recent NPM and Pypi registry attacks, we believe this to be a key strength of ours relative to other clients.

We have very few external dependencies. And these dependencies are all fuzzed, audited, formally verified,  or have similar rock solid guarantees.

Curious which libraries Nimbus depends on? `make deps` shows the full transitive list with the exact version, including the @nim_lang compiler - there is 61 of them right now, counting several that are used only for testing - 40 were purpose-built by @ethstatus! pic.twitter.com/L407vmQKZK

— Nimbus (@ethnimbus) January 10, 2022

Icing on the cake

Having thought deeply about, and written extensively on the importance of trustless staking pools, the icing on the cake for us last year was, without a doubt, the launch of Rocket Pool.

After everything the team has been through, notably the drama around 0x02, it was truly wonderful to see their vision of a trustless and community owned staking pool start to take shape.

We were especially happy to see that, by some estimates, Nimbus is the second most popular Rocket Pool client.

218 @Rocket_Pool proposals, four weeks in: pic.twitter.com/HrLZrjCWWC

— superphiz.eth 🦇🔊🐼 (@superphiz) December 6, 2021

Thank you Joe Clapis for everything you've done to red-pill the community into using Nimbus :)

Zooming in on last quarter

In case you haven't kept up with our latest releases, arguably the three most important features shipped last quarter were:

• Support for the web3signer protocol (currently in BETA)

• A feature complete rest API (still ironing out a few issues)

• A --num-threads option which allows Nimbus to take advantage of multiple CPU cores

v1.5.5 alone saw three significant optimisations worth highlighting here:

• A 6x speed-up in epoch processing

• A 2x speed up in Altair block processing

• A 12% reduction in outgoing GossipSub traffic (bandwidth reduction).

A calm-after-the-altair-storm release with lots of polish across the board - big drop in outgoing network traffic thanks to an elegant libp2p optimization, more flexibility in the REST interface allows you to use Nimbus with a growing amount of 3rd party tools, web3signer.. https://t.co/RTerT29ijA

— Jacek Sieka (@jcksie) December 6, 2021

Both web3signer support and the rest API pave the way for wider adoption of Nimbus. web3signer by allowing for staking pools and other providers with a custom key handling strategy to use Nimbus. And the rest API by allowing for third-party validator clients such as Vouch (or any other validator client for that matter) to use Nimbus as their beacon node.

Special thanks to Jim Mcdonald (@jgm) for helping us test the REST server: It is in large part thanks to your testing that we managed to get to the finish line!

Going forward

There is so much to look forward to in 2022. Here's a quick overview of our priorities:

• The merge, then sharding: the main focus here is on the stellar and timely execution of the merge followed by the sharding specs.

• Wider adoption: we have a new business development unit (welcome Kaushal!) devoted to increasing adoption. The initial focus will be on providing support for staking pools and providers who wish to adopt Nimbus ( a number of which have already committed to running Nimbus this year).

• Diversity++: this will mainly involve implementing all standards which seek to promote client diversity  (e.g. the development of cross-client UIs, migration tools, and the SSV network).

• The great rebranding: we want people to realise at a glance that Nimbus is great for far more than just resource-restricted devices. And, in particular, that there are important advantages to using it for enterprise grade infrastructure. This requires rethinking our branding and how we talk about ourselves.

• Privacy: as part of Status, caring about privacy is in our DNA. We plan on exploring how we can leverage our work on Waku in order to bring more privacy to validators at the networking layer.

• A Nimbus focused UI: we are committing serious resources towards a Nimbus UI which will be an integral part of the Status product roadmap moving forward. Our focus here is on user-friendly approaches for creating, managing, and monitoring validators (no CLI experience needed).

This year will also see us increasingly focused on lowering the technical barriers to running a full node (both consensus and execution) as well as pushing forward with our light client implementation (keep track of our progress here).

As we mentioned in our execution layer recap, one of our main design goals is to make it as easy as possible for our consensus and execution clients to be bundled into a single piece of software. With the Nimbus UI, you'll be able  to manage and monitor your node straight from the Status Desktop app.

I can't wait to run Nimbus straight from Status Desktop #hyped

— Jarrad Hope (@0xc1c4da) August 12, 2020

Complementary to this vision (and part of our longer-term UI roadmap) is an embedded light client running on your mobile phone.

More thank yous

We want to end by saying a big thank you to the Ethereum Foundation for the unbelievably generous incentive program they announced towards the end of last year. We are truly humbled to be valued by you in this way.

A big thank you to all the node runners using Nimbus, without you our work would be, quite frankly, meaningless.

And, last but by no means least, a big thank you to all our Gitcoin supporters: even more important than the financial, is the moral support; the appreciation we feel from every single one of you, each GR round, keeps our spirits high when the going feels tough.

We wish you all the very best of luck this coming year.