Jim McDonald

I think that there may be a case for asynchronous verification of validator registrations, but before this the synchronous path should be optimized to see if it is really necessary...

A few notes on this after investigating this for the beacon APIs: - for requests that read data, the relay should support Accept headers with q parameters such as "application/octet-stream;q=1,application/json;q=0.9"...

This is a change to the server rather than the endpoints, so I'd really rather not see it resulting in incrementing versions. It's possible for clients to work out what...

> Once the builder has built the execution payload, it returns the execution payload header along with the list of transaction roots that was used to derive the transaction field...

Including the tx hashes in `getHeader` seems too late in the process, I think there needs to be an earlier message so that the list of tx hashes can be...

> If `N` is large it might be simpler to simply send the transaction root list rather than multiple proofs. You would simply need to compute it once rather than...

> The list doesn't need to be sent to the builder. That would make it potentially very difficulty for any given builder to get lucky and have the required txs...

Trouble with bundling that far in advance is that the tx hashes will become stale. It's possible to change the tx list semantics to mean "must be included in _or...

The existing systems all seem to have issues. Pre/post balance for the proposer fee recipient address works most of the time, but will fail if funds are moved in or...

> Obtaining a "pure" mev score is only really useful for the sake of analysis. Surely it is also useful for comparison purposes, which is a part of why we...