The validator client should support the proof-of-stake notion of weak subjectivity; essentially, accepting a recent finalized hash from the network and using this to ensure the validator client is accessing the same fork of the chain as the rest of the validator set we wish to join (as there could be many, in theory...)
More discussion: ethereum/trinity#1482 (comment)
Tied up w/ this issue is having the validator client make some checks to ensure the beacon node it is connected to is one servicing the same network we wish to join.
Given the construction of the beacon chain, verifying a recent beacon state hash (and that the data we prefer is in the pre-image of that hash) is sufficient to solve the previous task. A weaker/less compact process is to just verify various parts of the state point-wise, i.e. "does the genesis time match?" NOTE: Checking the state may be blocked on what is currently available under the eth2 APIs...
A nice sanity check related to this topic is ensuring that all of the pubkeys we discover for validators we control as a validator client are in the beacon state and moving towards or are already in an active state.
A related point here is ensuring that the validator client spot checks any data we get back from the beacon node to ensure the data is as we expect, e.g. if I request a beacon block at some slot, do I get back a block w/ the correct slot?
The validator client should support the proof-of-stake notion of weak subjectivity; essentially, accepting a recent finalized hash from the network and using this to ensure the validator client is accessing the same fork of the chain as the rest of the validator set we wish to join (as there could be many, in theory...)
More discussion: ethereum/trinity#1482 (comment)
Tied up w/ this issue is having the validator client make some checks to ensure the beacon node it is connected to is one servicing the same network we wish to join.
Given the construction of the beacon chain, verifying a recent beacon state hash (and that the data we prefer is in the pre-image of that hash) is sufficient to solve the previous task. A weaker/less compact process is to just verify various parts of the state point-wise, i.e. "does the genesis time match?" NOTE: Checking the state may be blocked on what is currently available under the eth2 APIs...
A nice sanity check related to this topic is ensuring that all of the pubkeys we discover for validators we control as a validator client are in the beacon state and moving towards or are already in an active state.
A related point here is ensuring that the validator client spot checks any data we get back from the beacon node to ensure the data is as we expect, e.g. if I request a beacon block at some slot, do I get back a block w/ the correct slot?