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.
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.