Update `builder_setFeeRecipientV1` timestamp to sequence number

[ralexstokes]

what

The current spec for builder_setFeeRecipientV1 uses Unix timestamps to order updates from validators and the method requirements suggest that builders will respond with an error in the event that mev-boost suggests an update prior to one the builder already knows about.

I'd suggest instead to use sequence numbers in place of timestamps. A sequence number here is simply a monotonically increasing number the validator provides to order their updates. We can keep the uint64 type and validators are free to use whatever policy they choose but the obvious one is to just start at 0 and increment by one for each update.

why

clock skew

One reason to do this is it eliminates issues of clock skew from this entire API path (from validator to builder to possibly relays). If a validator is having issues with their local clock then they could accidentally confuse builders on which feeRecipient address to use with a potential loss in funds (redirecting fees to an outdated address).

You may consider the builder_setFeeRecipientV1 messages to be infrequent enough that we wouldn't see enough clock skew for this to be an issue in practice. However, relying on that invariant constrains the builder design space (as it assumes a particular usage pattern) and in doing so raises the barrier to entry for builders of all types.

I'll also point to the roughtime bug on Medalla during an early beacon chain testnet so these issues are not as rare as you may think.

looking forward

There is another reason to make this change as well in that it mirrors the consensus networking protocol where we have a similar idea of versioning which attestation subnets a validator is currently listening to (cf. https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#metadata). Making this change now will make it forward compatible with any migration to a more distributed architecture leveraging peer-to-peer networking (e.g. putting recipient updates into a DHT or others in #92). Moreover, the symmetry to these existing concepts means lower conceptual load for implementers, reviewers and others looking at this corner of the ethereum software stack. Use of sequence numbers (over e.g. timestamps) is important in these contexts for the same reasons as clock skew, exaggerated by the fact that you have even higher asynchrony (and resulting partial views) in these more distributed settings.

If there is support for this change, I'm happy to make a PR to update the code + specs.

[metachris]

Makes sense to me 👍

[ralexstokes]

after talking w/ some mev-boost implementers, we decided to keep timestamp as it assists with anti-DoS mechanisms. I'll close this issue