Do not init slashing DB when slashing protection is disabled

[ricardolyn]

Description

Whenusing --disable-slashing-protection-web3signer, it looks like we still need to use --init-slashing-protection even if there's no slashing protection database around. This feels off since we're using web3signer and won't need it.

Version

• Lighthouse Version: 5.0.0
• From: stable

What's Happening

So, we set --disable-slashing-protection-web3signer thinking we wouldn't need the slashing protection DB. But, the system is still asking for --init-slashing-protection to be set, which doesn't make sense to us since we're using web3signer and not the DB.

What Should Happen

It would make more sense if --init-slashing-protection was optional when we're using --disable-slashing-protection-web3signer. That way, it fits with not needing the DB.

[dapplion]

@ricardolyn can you paste here the full error you as seeing in the logs? I would assume a message starting with One or more validators not found in slashing protection database...

[AntoTG]

Hello, this issue is still occurring in version 7.0.0-beta.4.

The error is:

Mar 20 19:35:25.215 CRIT Failed to start validator client, reason: One or more validators not found in slashing protection database.

It seems that not only must the database exist, but the validators must also exist in it even though the parameter --disable-slashing-protection-web3signer is present. This is because we first initialize the VC with --init-slashing-protection and then remove that parameter and add the validators in the validators_definition.yaml file. Even then, it still gave an error when starting up because it's not only necessary for the database to exist, but also for the validators from the definition file to be in the database.

[michaelsproul]

@chong-he is going to take a look at this!

[michaelsproul]

Hi @ricardolyn, after some cost-benefit analysis we have decided not to proceed with implementing a fix for this issue. As we understand it, the impact is very minor (need to add --init-slashing-protection) but the remedy would necessitate adding a lot of complexity to the VC. This is because the VC contains the slashing protection database as a non-optional field, and expects to be able to refer to it. In order to make it optional, we would have to refactor the whole VC to deal with the case where the slashing protection database is absent. We could use an enum like this:

pub enum OptionalSlashingProtection {
    Initialized(SlashingProtectionDatabase),
    Disabled
}

But then we would need to add methods to this that proxy all the methods on SlashingProtectionDatabase. These methods would have to return errors in the case where the enum is set to Disabled.

This also raises the question of how we should handle a node that at startup has all web3signer keys, but then at runtime has new non-web3signer keys added via the HTTP API. The simplest thing would be to error, the more complex thing would be to initialize the DB on the fly and change from Disabled -> Initialized.

Given these considerations, we are inclined not to make any changes. Instead the web3signer documentation will be updated to mention that this flag (and the database) are required.