Per-slot unique RequestAuth vs Per-Builder unique RequestAuth

[bharath-123]

With ePBS, builders don't have to relay their bids through relayers and can directly connect to proposers.

The builder-specs currently specifies the proposer to sign a per-builder unique RequestAuth.

Having a per-builder unique RequestAuth can make sidecar consolidation trickier if we want to make sidecars optional with ePBS.

With ePBS, clients can absorb MEV-Boost functionality and make the need of a sidecar like MEV-Boost redundant. It would be ideal to make sidecars optional rather than a requirement like today so that innovation and experimentation can happen externally without requiring CL changes.

A per-builder unique RequestAuth will require the sidecars to access validator keys and sign the requests to get the bid.

If instead we have a per-slot RequestAuth which is unique across slots but common across builders, which can be defined like the following:

class RequestAuth(Container):
    parent_hash: Hash32
    parent_root: Root
    pubkey: BLSPubkey
    slot: Slot

The CL can just proxy the signature as a header to the sidecar and the sidecar can send requests to builders with the signature as needed.

A per-slot unique RequestAuth might be a reasonable tradeoff given the below 2 angles as to why we would want an auth:

1. Builder wants to query other builder's valuations: In this case, A builder gets a request for an ExecutionPayloadBid, the builder takes the signature and queries other builders. Now the builder needs to update their latest bid if they find a bid with a higher valuation than the ones they have, they would have to update the payment tx, recompute state root etc which seems to be generally high latency and the proposer will just timeout their request by then. So IMO it doesn't seem like a very harmful situation?
2. Builders want to cause DOS to reduce quality of service of a builder: I think Builders should have general DOS protection in this case.

[eserilev]

From a CL perspective I am in favor of this simplification. I wonder how builders feel about this?

[bharath-123]

It might be more ideal to have a per-builder auth as builders can update their bids in response to other builder bids very fast. Making the builder auction very assymetric in terms of bid update latencies.
Having a per-builder auth might be useful in making the block auction more symmetric across builders.

[vladimir-ea]

Declaration of interest: I work at Gattaca which run Titan builder and Titan relay.

I would challenge some of the assumptions in this proposal:

• 'With ePBS, clients can absorb MEV-Boost functionality and make the need of a sidecar like MEV-Boost redundant.'

I am not convinced this is the case. There are many uses for sidecars beyond relay / builder selection - for example proposers that want to support pre-confirmations.

• 'Now the builder needs to update their latest bid if they find a bid with a higher valuation than the ones they have, they would have to update the payment tx, recompute state root etc which seems to be generally high latency and the proposer will just timeout their request by then.'

Updating the bid on the block can be executed in microseconds. State root, tx root, receipt root can all be recomputed using proofs generated during block building. So it will happen that builders react to other builder bids.

• DOS protection: using signed bids increases the potential for DOS of builders rather than reducing it - validating signatures is much heavier computationally than responding to a plain request.

Should a third option of 'no signing' be added? This is the current situation with proposers connecting to relays.

Also, more generally, who benefits from the signing of bids?

The two arguments in favour I have seen are:

1. DOS protection - which I think is actually incorrect for reasons above
2. Avoiding "slow" builders being out bid by "fast" builders in an open auction

A bid from a "slow" builder being bettered by bids from "fast" builders is actually good for the proposer - they receive a higher price.

Is the intention to protect "slow" builders?

[bharath-123]

Apologies for the delayed response here, I think we need to make a decision on whether we want to support RequestAuth signatures or not as raised by Jason in #156.

I would first push that discussion in the issue raised above and then IF the community decides that we need request auth at all, then we can decide on how it should be. I think I generally agree that we should have a Per-Builder unique RequestAuth if we have it at all as builders can very quickly update their bids.

[bharath-123]

I think we can use a Per Builder Unique Request Auth if we go forward with the following structure:

class RequestAuth(Container):
   builder_pubkey: BLSPubkey
   slot: Slot

Clients can pre-sign the requests before the slot so there would be no latency in the slot with it.