registerValidator is used to relay to the beacon node that it should register the validator to receive blinded beacon blocks from an external builder.
The getHeader endpoint does indeed return a header with a fee_recipient and gas_limit, but by convention the fee_recipient is actually the builder's address, and payment is handled in the transaction list of the block. The gas_limit settings may or may not be respected, I haven't checked, but I doubt a client team will treat a blinded block gas limit conflict as worthy of rejecting.
If we feel this language is valuable somewhere, I would suggest we add it to the produceBlock v3 description. There, we can include an soft admonition about signing blinded blocks from trustworthy sources only, as the fee_recipient may not reflect expectations, and the gas_limit preferences of the validator can be ignored by the builder.
N.B. these changes do not apply to prepareBeaconProposer as
Unlike registerValidator, prepareBeaconProposer does not require a validator signature, which makes it easier to attack
Unlike registerValidator, the node operator has the explicit expectation that the fee_recipient in the block header will always match their configured value.
This is possibly just a nit.
registerValidator is used to relay to the beacon node that it should register the validator to receive blinded beacon blocks from an external builder.
The getHeader endpoint does indeed return a header with a
fee_recipientandgas_limit, but by convention thefee_recipientis actually the builder's address, and payment is handled in the transaction list of the block. The gas_limit settings may or may not be respected, I haven't checked, but I doubt a client team will treat a blinded block gas limit conflict as worthy of rejecting.If we feel this language is valuable somewhere, I would suggest we add it to the produceBlock v3 description. There, we can include an soft admonition about signing blinded blocks from trustworthy sources only, as the fee_recipient may not reflect expectations, and the gas_limit preferences of the validator can be ignored by the builder.
N.B. these changes do not apply to prepareBeaconProposer as