The ValidatorRegistration duty currently does not include the fee recipient, but instead relies on a dynamic duty struct for all duties. The fee recipient is taken from a state that can be modified by an event handler (FeeRecipientUpdate) during the pre-consensus process. This introduces the potential for a data race, which may result in the signing root of the ValidatorRegistration struct being altered. If this happens, the reconstruction of the partial signatures will fail, causing the duty itself to fail.
A refactor is needed to ensure that the fee recipient is handled safely within the ValidatorRegistration process, preventing race conditions and ensuring the consistency of the duty.
The
ValidatorRegistration
duty currently does not include the fee recipient, but instead relies on a dynamic duty struct for all duties. The fee recipient is taken from a state that can be modified by an event handler (FeeRecipientUpdate
) during the pre-consensus process. This introduces the potential for a data race, which may result in the signing root of theValidatorRegistration
struct being altered. If this happens, the reconstruction of the partial signatures will fail, causing the duty itself to fail.A refactor is needed to ensure that the fee recipient is handled safely within the
ValidatorRegistration
process, preventing race conditions and ensuring the consistency of the duty.In https://github.com/ssvlabs/ssv-spec/issues/368#issuecomment-2009613235, it was suggested to make independent structs for each duty type, which could be a more robust approach for preventing such issues.