Clarify relationship b/t builder, relay and proposer

[ralexstokes]

There is an ambiguity right now with the pubkey contained in the SignedBuilderBid and the signature included in that message.

We want to know which builder produced a given bid/block for accountability reasons and so the signed message should include an identifier (and ideally a signature) for the builder.

Proposers also want to be able to know (and importantly, prove to others) which relays they use when obtaining blocks from the external builder network. We ideally have a separate identifier and signature to bind a particular relay to a bid they forward to validators.

Right now, there is only one set of (pubkey, signature) in the SignedBuilderBid message and it is not clear in the specs which set of actors they refer to.

To remedy, one solution is:

1. Include a builder public key and signature in the BuilderBid message that signs over the header and value data.
2. Include a relay public key along with an outer signature in the SignedBuilderBid message.

And ideally the relay validates the signature from the builder and the proposer validates the signature from the relay and builder. Proposers could skip builder verification if they want, or perhaps do offline in situations where it becomes relevant.

Another solution that reduces the overhead here compared to the status quo is to make the builder opaque to the proposer (so that the SignedBuilderBid only has pubkey and signature for the relay) with an option to also have the relay sign over the builder identity (so include a second pubkey for the builder in the BuilderBid message). If it is not clear from the messages exchanged in the builder APIs which builder was responsible for a block, then I think there should be a separate protocol put in place to increase accountability between builders and relays but if we go this route then this concern can be handled elsewhere.

[metachris]

Yes, we've been thinking about this too, and are currently experimenting with API design between builder and relay. The idea is that builders push full blocks to the relay, and the relay creates the final BuilderBid.

Just a note: the current spec includes the builder pubkey and the relay signature: https://github.com/ethereum/builder-specs/blob/main/types/bellatrix/bid.yaml

We should make this more explicit by calling the field builder_pubkey, and including a relay_pubkey! Having the relay pubkey will be very useful in any way, to not only depend on the startup configuration of mev-boost.

[metachris]

I feel like adding a builder signature would be good.

An alternative to the signature addition suggested above could be to embed both public keys into BuilderBid and have both signatures over the flat structure. This requires the builder to know the relay pubkey beforehand, which should be fine but might have other implications for builders (needing to prepare a Bid for each relay it wants to send to).

[metachris]

I'd like to propose https://github.com/ethereum/builder-specs/pull/30/files as first step, adding both the builder and relay pk into the BuilderBid. This is useful for many cases, including not only relying on the relay pk pre-configured in mev-boost at startup.