Misleading fee recipient used in payload_attributes event

[michaelsproul]

Describe the bug

In the SSE /events API, Prysm emits a misleading fee recipient in the payload_attributes field:

prysm/beacon-chain/rpc/eth/events/events.go

Lines 471 to 477 in 7c81c7d

	attributes = &structs.PayloadAttributesV3{
	Timestamp: fmt.Sprintf("%d", t.Unix()),
	PrevRandao: hexutil.Encode(prevRando),
	SuggestedFeeRecipient: hexutil.Encode(headPayload.FeeRecipient()),
	Withdrawals: structs.WithdrawalsFromConsensus(withdrawals),
	ParentBeaconBlockRoot: hexutil.Encode(parentRoot[:]),
	}

This is the fee recipient of the current head block, which would become the parent of a new block built with these payload attributes. It would be incorrect for any consumer of this event stream (e.g. a block builder) to use the fee-recipient provided, because it would pay the block's fees to the proposer of the previous block, rather than the actual proposer!

I think a better solution would be to use the fee recipient of the true proposer, if that proposer is connected locally. In the most common case where they are not connected, a dummy value or beacon-node-wide default value could be used. This is the approach we use in Lighthouse.

For consumers of the stream, this makes it clearer that they need to get the proposer's correct fee recipient from elsewhere. Proposers can change their fee recipients between proposals, so the only up-to-date source of this information comes from off-chain, likely from a block relay in the current system.

Has this worked before in a previous version?

Not sure

🔬 Minimal Reproduction

No response

Error

No response

Platform(s)

No response

What version of Prysm are you running? (Which release)

No response

Anything else relevant (validator index / public key)?

No response

[james-prysm]

agree, it's a bug. will be discussing internally an appropriate solution based on Sproul's suggestion.

that being said for those reading this issue

It would be incorrect for any consumer of this event stream (e.g. a block builder) to use the fee-recipient provided, because it would pay the block's fees to the proposer of the previous block, rather than the actual proposer!

please note on the beacon API this comment
https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Events/eventstream

The fee recipient may also be set via beacon node config, but should likely be ignored by block builders and most other API consumers.

instead, the validator registration fee recipient should be used