Clarify when the DVC's anti-slashing DB intialisation should take place.

[saltiniroberto]

The Anti-Slashing Measures at the DVC section of the Ethereum Distributed Validator Specification requires that DVCs initialises its anti-slashing DB to the VC's anti-slashing DB.

Currently, the specification is open for interpretation on the following points:

1. Should the DVC's anti-slashing DB initialisation occur every time that the DVC is started?
2. Should the DVC's anti-slashing DB initialisation occur only the first time that the DVC is started?
3. Should the VC's anti-slashing protection be disabled and rely entirely on the DVC's anti-slashing protection?
   • If so and if behaviour 1 above is the desired one, then the VC still needs to keep updating its anti-slashing DB albeit no check is preferred when signing.

[saltiniroberto]

Overall, I think that:

• if we believe that one of the DBs is more reliable than the other, then we should just use the DB that we think is the most reliable for enforcing anti-slashing protection.
• if we believe that the two DBs have the same level of reliability, then we need to design a procedure for reconciling the two DBs if they happen to disagree. Otherwise, the liveness of protocol is likely to be affected.

[adiasg]

@saltiniroberto thanks for raising this issue!

The intended interpretation was:

1. Should the DVC's anti-slashing DB initialisation occur every time that the DVC is started?

The DVC's anti-slashing DB should be initialized every time the DVC is (re)started.

The purpose of an anti-slashing DB at the DVC is to allow for the DVC to validate a proposed consensus value for unslashability against the validator's previously signed messages. While the VC holds such an anti-slashing DB, it does not (currently) provide an API method to access the DB anyhow. An idea to solve this is to replicate the VC's anti-slashing DB at the DVC, and operate the two clients together. When operating together, the VC should only ever sign data provided by the DVC. In this scenario, the DVC's DB should be a superset of the VC's DB (they'll be in perfect sync unless the VC fails to sign a provided value).

if we believe that one of the DBs is more reliable than the other, then we should just use the DB that we think is the most reliable for enforcing anti-slashing protection.

As mentioned above, the motivation of an anti-slashing DB at the DVC is to allow for validation of proposed consensus values without changing the current VC implementation.

we need to design a procedure for reconciling the two DBs if they happen to disagree. Otherwise, the liveness of protocol is likely to be affected.

Admittedly, we made an assumption that the DBs disagreeing is an impossible scenario. In case that happens, both clients need to be shut down, the DB needs to be copied over from the VC to the DVC, and the clients restarted. But we do need better recovery strategies from this scenario! We are still discussing proposals to modify the standard VC interface to allow for the possibility of automatic recovery of the DVC software.

[saltiniroberto]

@adiasg Thanks the clarification.

What do you think of option 3 above?

The idea with Option 3 is to use the VC's anti slashing DB at most for initialisation purposes and then rely only on the DVC's anti slashing DB for protect against slashing.

This may require a modification to the VC's code to allow disabling the anti slashing protection, but this should be quite easy to do.

[adiasg]

Allowing for a configuration where the VC's anti-slashing protection is inactive is dangerous because misconfigurations can lead to slashing. The preference would be to have active (and mandatory) slashing protection as close to the staking keys as possible - so an amended proposal (that we have been discussing) is to have the DB only at the VC and allow the DVC to check unslashability through a modified API endpoint at the VC.

The nuances for the amended proposal are that it requires the VC to run a server that accepts incoming requests - something that does not fit in the security model of the VC. We're thinking of ways to circumvent this while still retaining the benefits of having a single slashing DB (for example, by modifying the VC so that it exports the anti-slashing DB with every request it makes to the DVC).

[OisinKyne]

Hey guys

On this topic of anti-slashing DBs at the DVC level, I have a few thoughts.

• We definitely should not turn off anti slashing at the VC level, I believe that's how staked.us got burned by assuming their proprietary anti-slashing would work.... it did not.

• On when should a DVC anti slashing DB get repopulated, I don't necessarily think it needs to be every restart, I think it should be at a minimum if a DVC restarts and sees no initialised anti-slashing DB on its filesystem, then it would need to initialise one for each of the configured DVs its servicing.

  • This could be by importing a dump from a VC
  • However how I would like to do it if feasible would be for a DVC to simply query the beacon node API automatically, to see if it can find the most recent attestation from the validator pubkey/index. Within that attestation will be source+target values, which should be sufficient for bootstrapping a DVC anti-slashing DB (assuming we can rely on VCs + byzantine fault tolerance to save us if our auto population fails/is stale).
  • To be even more careful, we could also go the route some client teams have of --enable-doppleganger, which basically just tells a client to wait an epoch, see what happens for the validators duty during that epoch, and then move on from there.

[adiasg]

I don't necessarily think it needs to be every restart, I think it should be at a minimum if a DVC restarts and sees no initialised anti-slashing DB on its filesystem, then it would need to initialise one for each of the configured DVs its servicing.

If the VC is operated while the DVC is offline, the two slashing DBs will be inconsistent states. Importing the slashing DB at every DVC start is a good sanity check to avoid such situations.

However how I would like to do it if feasible would be for a DVC to simply query the beacon node API automatically, to see if it can find the most recent attestation from the validator pubkey/index. Within that attestation will be source+target values, which should be sufficient for bootstrapping a DVC anti-slashing DB (assuming we can rely on VCs + byzantine fault tolerance to save us if our auto population fails/is stale).

This is possible, and there's been some efforts around slashing DB rebuild (see branch parse_chain for your suggestion). The risk is that there may be past messages created by the VC that don't appear in the canonical chain, so a "full" rebuild of the slashing DB cannot be achieved.

In general, I think allowing for situations where both the slashing DBs can exist in inconsistent states is risky. We should explore options that allow for automatic import/sync of the slashing DB from the VC to the DVC - one option is described here. This may require (hopefully minor) changes to the VC implementation, but will be worth the advantages to DV infrastructure.