Block production resolves the fee recipient only from the prepare_beacon_proposer registrations:
feeRecipient, registered := a.validatorParams.GetFeeRecipient(proposerIndex)
Under Gloas a signed ProposerPreferences message can carry one as well. The same closure already reads that message for TargetGasLimit, guarded by pref.Message.ValidatorIndex == proposerIndex, so the value is in scope at the point the fee recipient is chosen.
Two things follow, in increasing order of scope:
- the warning about a missing registration is inaccurate when a matching preference exists, since one is in fact available;
- more importantly, a proposer that registered only through preferences builds with the zero address and gives that block's fees away.
Deciding the precedence between the two sources is the actual question here, which is why it is not folded into #23274.
Reported by @yperbasis and @domiwei while reviewing #23274.
Block production resolves the fee recipient only from the
prepare_beacon_proposerregistrations:Under Gloas a signed
ProposerPreferencesmessage can carry one as well. The same closure already reads that message forTargetGasLimit, guarded bypref.Message.ValidatorIndex == proposerIndex, so the value is in scope at the point the fee recipient is chosen.Two things follow, in increasing order of scope:
Deciding the precedence between the two sources is the actual question here, which is why it is not folded into #23274.
Reported by @yperbasis and @domiwei while reviewing #23274.