Nimbus update: November 10

Since our last update the Nimbus client has made significant progress across security, performance, and ease-of-use.

In order to celebrate the release of the eth2 deposit contract, today we're announcing our 0.6 alpha release -- hope.

Hope - first binary release

Nimbus is easier and faster to use now than it ever has been. hope includes compiled Linux binaries -- initially x86 64-bit, but Windows, MacOS and additional Linux binaries will be added shortly (see here for the relevant page in the Nimbus book). Rest assured, we'll continue supporting building Nimbus from source, as well as a diversity of hardware.

We've designed this binary to be reproducible: in practice, this means that anyone who wishes to can verify that no vulnerabilities or backdoors have been introduced during the compilation process. For more on the philosophy and importance of reproducible builds see here.

With this release, Nimbus is stable on Medalla and missed attestations are a thing of the past.

A follow-up release is planned for later this week which will include gossipsub 1.1.

Eth2 around the corner

A few things happened last week : the eth2 deposit contract has been deployed, the mainnet launchpad is live, and the Genesis date has been set to December 1st (see here for Danny Ryan's announcement blog post).

We want to make it clear that we recognise the following address as the canonical eth2 deposit contract:

0x00000000219ab540356cBB839Cbe05303d7705Fa

Importantly, you should not send ETH to directly to this address. If you do send ETH directly to the contract address, this will result in a failed transaction. To stake your ETH you should follow the steps outlined in the  Launchpad.

Note that this is not a DeFi contract to ape into. A lot of scams will proliferate in the next few weeks, so please triple check the address before sending off your deposits.

hope includes support for mainnet parameters and will by default monitor the mainnet deposit contract ✨

Security audit wrap-up

We are wrapping up a unique security audit -- in which 3 security vendors were chosen to review the codebase for a timeline of approximately 3 months. We've addressed the majority of the issues found (a detailed write-up will be coming soon).

For the curious among you, we've published an auditors handbook that goes deep into the Nim programming language (as used in the nimbus-eth2 project), the project itself, as well as its dependencies.

On this note, one of our design goals is to minimise reliance on third-party software. Nimbus is special in that the team behind it owns almost the entire codebase. This gives us the possibility of optimising every component of the system, as well as ensuring that eth2 is available for all using the most liberal licensing possible.

In sum, we have almost no external dependencies except those we manually vet for quality and security (most notably, prominent crypto libraries). And we believe this to be a key differentiating factor from a security, performance, and a necessity open-source licensing perspective.

Attestation performance improvements

With respect to attestations, we've pushed a number of libp2p fixes and improvements on the networking side since the 13th October. When non-finality took hold of Zinken, we started to check and improve on inclusion distance. This has resulted in a significantly improved attestation effectiveness.

A moment in time, between 2020-11-04 23:40:08 and 2020-11-05 10:20:08. The cells in red are where the client failed to attest. (Source, thank you Barnabé Monnot 🙏 )

At time of writing, our validators are running with more-or-less perfect attestation records: no inclusion delays and all attestations where they should be (see here, for example).

Slashing mystery resolved

With respect to slashings, a recent Medalla data analysis pointed out an unreasonable percentage of slashed proposers were running Nimbus. To quote directly from one report:

We were, however, able to map the slashed proposers to an overwhelming majority running the Nimbus client.

After some digging, we've tracked this to what looks like one individual or entity (the node ids of all the Nimbus validators that suffered a proposer slashing were within 100 id numbers of each other: 38800, 38801... 38895).

Nearly all of these slashings occurred between epochs 13,300 and 14,500. The most plausible explanation is that the individual in question was running two different instances of Nimbus with the same signing keys -- something slashing protection databases are not designed to protect against.  To clarify, you should never ever do this. If you have had your validators slashed, do get in touch with us so we can thoroughly investigate.

In sum, this is not a cause for concern, our slashing protection database is working as expected. If you do experience a slashing related incident, please get in touch with us 🙏.

Writing, Syncing, and Geth

On the writing front, points of note include an updated website, a Raspberry Pi tutorial that takes you through how to run Nimbus from first principles, and an updated book that takes you through what you need to know to become an eth2 validator.

Syncing in general is much quicker than it was a few weeks ago (this is thanks to the switch to BLST and several other performance improvements). We also have better support for local eth1 nodes (in particular, Geth).

To wrap up, rumour has it there may be a new 1.0 testnet launching soon. If you're itching to get started  before then, you can try syncing Medalla  (steps 1 through 6 in the Nimbus book). If you make your deposit now, your validator should be activated within the next 10-20 days.

Onwards!