By Nimbus Team in News & Announcements —

Nimbus Update: v1.0.7 release (doppelganger detection)

Nimbus Update: v1.0.7 release (doppelganger detection)
Image credit: Afri Schoedon's Ethereum 2.0 Mainnet Clients report

We're excited to announce that our new v1.0.7 release is out! This is a big one for us.

In a sentence, it includes  some significant performance improvements across the board as well as additional protection against accidental slashings.


To give you a flavour, our initial impressions are:

  • Sync speed is approximately 50% faster
  • CPU utilization has more than halved
  • Rewards are higher: We've optimised the processing of blocks to be more CPU efficient, which means we're able to provide attestations with lower inclusion distances (which means higher rewards).In fact, today is the highest revenue day for our fleet (excluding lucky days with block proposals).

We encourage you to check out the full release notes for more (we've included both arm64 and windows binaries).

The rest of this post will both introduce and dig deeper into the additional slashing protection measure.

Poka-yoke: slashing protection at the gossip layer

An accidental slashing is one of the greatest fears haunting any staker (and rightly so!). It follows that the more protection we can offer against it, the lower the threshold for aspiring stakers. Put another way, efforts to reduce the risk of slashing for honest validators can be a major contributor to decentralisation.

While the slashing protection database -- together with the Validator client interchange format  as described in EIP-3076 -- is a good start, it implicitly assumes that the user has turned off one device before moving their keys to another.

In other words, it doesn't prevent a validator who has just come online, with the same key as another validator who is still online, from sending a (potentially conflicting) message (i.e. double voting).

This accidental error, which is all too easy to make, has been one of the primary causes of slashings so far (together with fancy validator redundancies that bypass the slashing protection mechanisms).

Even though awareness within the community has grown substantially,  we can do better. Ideally, we should be aiming to make it impossible for users to shoot themselves in the foot -- or, to borrow a japanese phrase, we should be adhereing as closely as possible  to a Poka-yoke philosophy.

In this release, we've added some extra logic  to try to bring users a little closer to this ideal -- we've taken inspiration from superphiz and called it Doppelganger detection (to test it out, check out our new release here).

Note: This idea is not original to Nimbus, it's been a feature request on the ethstaker discord channel, and similar ideas have been discussed by pretty much all client teams both on GitHub and discord.

How does it work? In short, when a validator is started (or restarted) it prudently listens for 2 epochs (more on this choice later) for attestations from a validator with the same index (a doppelganger), before sending an attestation itself.

In that time, if it notices a message from a validator with the same index, it shuts down the local validator with a warning message:

We believe you are currently running another instance of the same validator. And that we've disconnected you from the network as this presents a significant slashing risk.

Along with instructions on what to do next:

Make sure you've disconnected your validator from your old machine before restarting the client. If you've already done so, please wait a little longer before restarting the client.

In sum, it's a simple way of handling the case where one validator comes online with the same key as another validator that's already online (i.e one device was started without switching the other off).

While this strategy requires the client to wait two whole epochs on restart before attesting, a couple of missed attestations is a very minor price to pay in exchange for significantly reducing the risk of an accidental slashing.

You can think of it as a small penalty that you pay only on first launch and restarts. When you take into account the total runtime of your validator, the impact should be minimal.

Why two epochs?

Two epochs seemed like a good compromise between minimising accidental slashing risk, and maximising returns. The number certainly isn't set in stone however: we will revisit it if we see evidence that a different period of time may be more effective (in fact, we'll be optimising this significantly in a future release).

In theory, there is a risk that you could be slashed as far back as the weak subjectivity period, but this should only be possible in a forked environment.

Caveats

This is not meant to be a replacement for the slashing protection database, but a complement. The slashing protection database protects your validator from contradicting itself on your local machine, and together with the interchange format (which will be included in our next release) allows you to safely change clients and/or devices assuming you remember to turn the original client/device off.

The doppelganger detection on the otherhand prevents your validator from contradicting itself if you have accidentally left it running on another machine: in other words, it's a safeguard against running two clients at the same time with the same keys (to re-iterate, this is the only type of slashing we've seen so far).

If you'd like to keep up to date with our progress, please join us on discord or subscribe to our mailing list. For all things validator related, we encourage you to check out our guide at nimbus.guide 💛