You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MultiValidatorService implements a check, ensuring that a proposer or an attester can propose/attest only once per slot.
However, validator spec slashing conditions are defined per epoch. I.e. there should not be two or more conflicting block/attestations signed during the same epoch.
Since, there can be forks with different shuffling, a validator may be assigned in a proposer/attester role to different slots for different slots.
It is probably extremely rare for the proposer role, but quite possible for the attester role.
So, there can happen some scenarios, when a validator assigned to a slot as an attester for one fork, then head is switched to another fork, and the same validator assigned as an attester at some later slot. So, if both slots are during the same epoch, then our implementation will violate the first slashing condition for the validator.
So, there should be logic implemented which prevents issuing an attestation more than once for any particular epoch. Analogous check should be implemented for block proposals. That also means, the information about blocks and attestations to be issues should be stored to a disk, so that the info survived crashes. See validator specs for details.
The text was updated successfully, but these errors were encountered:
MultiValidatorService implements a check, ensuring that a proposer or an attester can propose/attest only once per slot.
However, validator spec slashing conditions are defined per epoch. I.e. there should not be two or more conflicting block/attestations signed during the same epoch.
Since, there can be forks with different shuffling, a validator may be assigned in a proposer/attester role to different slots for different slots.
It is probably extremely rare for the proposer role, but quite possible for the attester role.
So, there can happen some scenarios, when a validator assigned to a slot as an attester for one fork, then head is switched to another fork, and the same validator assigned as an attester at some later slot. So, if both slots are during the same epoch, then our implementation will violate the first slashing condition for the validator.
So, there should be logic implemented which prevents issuing an attestation more than once for any particular epoch. Analogous check should be implemented for block proposals. That also means, the information about blocks and attestations to be issues should be stored to a disk, so that the info survived crashes. See validator specs for details.
The text was updated successfully, but these errors were encountered: