Jim McDonald

Could this be solved by requiring a validator client to call `prepare_beacon_proposer` prior to requesting a block? It seems a cleaner solution than the conflicts that could occur when we're...

I would suggest that a simple load balancer is not really suitable for multiple beacon nodes. Calls like `prepare_beacon_proposer` and subscriptions, for example, should be sent to all nodes to...

In this proposal, if a fee recipient is not already known then a block will be returned only after an execution payload has been built, which could take a significant...

My apologies @paulhauner just realised I haven't replied to this. I think that your suggestion gives us the best of all worlds. It gives validator clients flexibility to follow either...

I think that this conversation has veered out of scope for an endpoint definition. In my opinion, this endpoint should be added to the beacon APIs same as the others,...

> At the least, the checkpoint API is incredibly lightweight and probably safe for the vast majority of people to just expose freely. It's a DoS vector, especially given the...

> A middleware client intercepting these V2 requests and calculating the aggregation selection could subsequently call the CL's /V1/ endpoint ... To date the V2 of an endpoint causes the...

There's no information in here on how far back the "epoch" parameter can/should go. Is it expected that this could be called for any epoch, or for only the most...

JSON isn't built for speed or size of response, so I'm not sure that attempting to optimize for that within any JSON response is a useful path to go down....

A more general comment, but does it make sense to start a v2 version of the API that contains enhancements such as those suggested above, as well as the alterations...