RFC: Expanding scope of API

[lightclient]

The current design of the API is focused on simplicity, with the goal of providing an interface for receiving blocks from a single, trusted builder. This scenario is contrived though, because in reality there will be additional software involved, such as a multiplexer like mev-boost and relays which create a buffer between builders and proposers.

Expanding the scope of the API beyond the contrived architectural view may make sense to better accommodate these designs, so I would like others to weigh in.

status Endpoint

The status endpoint is defined to return whether the builder is operating normally and able to produce blocks. It's undefined what the response for this endpoint should be when called against a multiplexer. It could return "OK" as long as one connected relay is up, or maybe only return "OK" if all configured relays are up.

I am okay with this being an implementation detail of the multiplexer. As long as that software believes it can retrieve blocks, it should return "OK".

Both relay and builder signature in Bid

Expanding the definition of the Bid object to include signatures from both the relay and the builder would give the proposer additional insight into the entity that actually built the block.

I think an issue with this is that the relay can simply fill out the builder signature with another key pair they have on hand and continue masking the builder's real identity.

--

My current opinion is to not expand the scope, but rather focus on the functionality provided by the API to make sure it is adequate to build more complicated systems on top of. Right now, only the most basic protocol for retrieving external blocks is defined. This allows a great deal of flexibility. For example, CLs who want to implement mev-boost natively do not have specialized fields for mev-boost that they need to worry about.

If there are other compelling examples / reasons for expanding the scope, please share them here.

[metachris]

my 2c:

• status endpoint: is now already part of the spec (status.yaml) and returns 200 if it is running. We could define an additional response payload indicating further system status, but I agree that 200 (and no payload) is the basic response if it believes it can retrieve blocks.
• signatures: the current setup is that the bid contains the builder pubkey and the relay signature. This should be enough since the builder must trust the relay anyway. The communication between builders and relays might be very different from the current request/response interaction, for instance setting up an authenticated connection and then have the builder stream blocks to the relay without additional signatures. This will be worked on soon, and I think we could keep the spec as-is until we'll know more about the implementation details.

[lightclient]

Going to close this as we have a few other issues/PRs tracking these things. I think there was a miscommunication at some point though, but I think the signature and pubkey of an object should by in sync. I wasn't explicit above by saying the relay could replace the signature with their own - I also meant they would replace the pubkey, because without this property the signature would not be verifiable in isolation.