# Builder-API post ePBS for Off-Protocol Builders

This document aims to explore how the Builder-API can evolve post ePBS for off-protocol builders.

## Introduction

As the name suggests, ePBS (enshrined Proposer-Builder Separation) integrates a builder entity directly into the Ethereum L1 protocol. It separates execution block validation from consensus block validation, creating a cleaner architectural division.

The enshrined builders can send bids to proposers through the p2p network but proposers retain the flexibility to build blocks using out-of-protocol entities such as MEV relays. This document explores how the interface between proposers and the builder market evolves with ePBS implementation.

Under ePBS, the proposer receives bids from both enshrined builders and external entities like relays, then commits to a specific `ExecutionPayloadBid`. The proposer releases a `BeaconBlock` containing the committed `ExecutionPayloadBid`, which is subsequently attested by validators.

The `ExecutionPayloadEnvelope` is broadcast to the PTC (Payload Timeliness Committee) by the builder/off-protocol relays. Simultaneously, blobs from the `BlobsBundle` are split into data columns and distributed to the network.

The PTC observes the `ExecutionPayloadEnvelope` and sends a `PayloadAttestation` which indicates whether the payload has been seen or not. It ensures that the payload has been released in a timely fashion by the builder.

Builders might have strong incentives to route their bids through off-chain relays rather than the enshrined system. Off-chain relays provide direct TCP connections with proposers, bypassing the peer-to-peer network infrastructure. This direct connection enables bid cancellation capabilities—a highly valuable feature for builders managing their strategies.

Consequently, MEV relays may consistently offer higher-value blocks, which rational proposers will naturally gravitate toward to maximize their returns.

## Type definitions

We define some of the types we will be frequently using in our discussion of the API.

class ExecutionPayloadBid(Container):
    parent_block_hash: Hash32
    parent_block_root: Root
    block_hash: Hash32
    prev_randao: Bytes32
    fee_recipient: ExecutionAddress
    gas_limit: uint64
    builder_index: ValidatorIndex
    slot: Slot
    value: Gwei
    execution_payment: Gwei
    blob_kzg_commitments_root: Root

class SignedExecutionPayloadBid(Container):
    message: ExecutionPayloadBid
    signature: BLSSignature

class ExecutionPayloadEnvelope(Container):
    payload: ExecutionPayload
    execution_requests: ExecutionRequests
    builder_index: ValidatorIndex
    beacon_block_root: Root
    slot: Slot
    blob_kzg_commitments: List[KZGCommitment, MAX_BLOB_COMMITMENTS_PER_BLOCK]
    state_root: Root

class SignedExecutionPayloadEnvelope(Container):
    message: ExecutionPayloadEnvelope
    signature: BLSSignature

class BlindedExecutionPayloadEnvelope(Container):
    payload: Root
    execution_requests: Root
    builder_index: ValidatorIndex
    beacon_block_root: Root
    slot: Slot
    blob_kzg_commitments: Root
    state_root: Root

class SignedBlindedExecutionPayloadEnvelope(Container):
    message: BlindedExecutionPayloadEnvelope
    signature: BLSSignature

## Builder-API with ePBS

ePBS enshrines builders into the protocol. Builder's are enshrined into the protocol by staking some collateral(at least 32Eth). Using this collateral, builders can trustlessly pay proposers when their bids get selected.

Not all builders might want to be enshrined into the protocol for various reasons, so we might still have off-protocol trusted relays and builders. For such cases, we want to understand how the Builder-API in such cases would look like.

Client teams have mentioned that they may not implement the Builder-API(by not supporting MEV-Boost). Regardless of this, it is important to have a definition of the Builder-API which would work in such cases.

When the proposer sources bids from external relays/builders using the Builder-API, it has to behave as if it is self-building to the protocol.

On a high level, the proposer<>relay/builder interactions would look like the following (Note that we use relay and builder interchangably):

1. The proposer queries the relay for an `ExecutionPayloadBid`. The relay sends an `ExecutionPayloadBid` and sets the `execution_payment` field to the value of the bid. The relay also sends the hash tree roots of the `payload` and `execution_requests`. This so that the proposer can provide the relay with the signature of the `ExecutionPayloadEnvelope` We can define this interaction as `getExecutionPayloadBid`
2. If the proposer accepts this bid, it sends a `SignedBeaconBlock` with the `ExecutionPayloadBid` embedded into it to the relay via a POST request. The proposer can also construct the `SignedBlindedExecutionPayloadEnvelope` and send it to the relay as the proposer now knows the `beacon_block_root`. We can define this interaction as `sendSignedBeaconBlock`. The relay and proposer broadcast the `signedBeaconBlock` to the beacon commitees for the slot.
3. The relay now has enough information to construct the final `SignedExecutionPayloadEnvelope` with the signature of the `SignedBlindedExecutionPayloadEnvelope`. It then is responsible for broadcasting the `SignedExecutionPayloadEnvelope` to the protocol.

The API is generally unopinionated about how the builder pays the proposer but we can assume the status quo as today where the builder inserts a payment transaction at the end of the block to the proposer's fee recipient.

## API definitions

### Execution Payload Bid retrival

The proposer queries this API and receives the `SignedExecutionPayloadBid` for this slot. The relay also returns to the proposer the `payload` root and `execution_requests` root for the proposer to construct a `SignedBlindedExecutionPayloadEnvelope`.

GET `/eth/v1/builder/execution_payload_bid/{slot}/{parent_hash}/{pub_key}`

### Execution Payload Bid commitment

The proposer commits to the `ExecutionPayloadBid` by sending back to the relay, the `SignedBeaconBlock` which embeds the `ExecutionPayloadBid`. The proposer also sends back the `SignedBlindedExecutionPayloadEnvelope`. The relay can construct the `SignedExecutionPayloadEnvelope` from the `SignedBlindedExecutionPayloadEnvelope` and broadcast it to the PTC commitee.

POST `/eth/v1/builder/beacon_block`

## Sequence Diagram


## Security Considerations

1. The proposer trusts the relay to make the payment according to the value provided by `execution_payment`.
2. The proposer trusts the relay to broadcast the execution payload envelope on time.
3. The proposer trusts the relay to provide the correct payload and execution requests root along with the bid.

## Questions

1. Should the relay wait for the BeaconBlock to get enough attestations before broadcasting the `SignedExecutionPayloadEnvelope`. If the BeaconBlock doesn't get enough attestations, it could be re-orged out and the relay could avoid broadcasting the full payload to avoid paying for a block that might be re-orged out. Very unlikely to happen tho.
2. Should we have a push based system where the relay can push the bid to the proposer instead of the proposer querying the relay. The main issue with this is that the relays have to trust the proposer to pick the latest bid(and not the highest bid). It is generally not a good idea to trust the proposer.
3. We can rename the APIs.
4. We can add payment proofs in the when the proposer receives the bid. Inspired by: https://github.com/ethereum/builder-specs/pull/51
5. Do we still need to specify the slot, pubkey and parent_hash in the request to get the execution payload bid?

## Notes

1. If the relay fails to deliver the ExecutionPayloadEnvelope, then it will result in a missed slot. The relay and proposer would have to settle the payment offchain in such cases.
2. The relay doesn't have to return the ExecutionPayloadEnvelope back to the proposer since it will be a very large object. This is similar behaviour to the `getPayloadV2` API.
3. With `execution_payment` being specified in ExecutionPayloadBid, we can have mechanisms on-chain going forward to validate whether the payment has been indeed made by the off-chain builder.
4. The MEV-Relay probably would want the beacon block to get enough attestations before publishing the Envelope to avoid any potential unbundling attacks by the proposer.
5. Based on my knowledge, some client teams mentioned that they wouldn't support MEV-Boost or the builder-api. Regardless of what client teams do, there might be demand for out of protocol bids and it would be good to have a specification on how to source these bids.
6. Exercising the free-option problem is much easier with off-protocol bids because the payment is done via the execution payload. If the builder chooses to not broadcast the envelope than the proposer would not get paid too. We need to trust the relay to broadcast the execution payload envelope in time to the PTC.
7. The relay and builder will get the fee recipient of the validator via validator registrations.
8. We ideally don't want to return the full `ExecutionPayloadEnvelope` to the proposer as the `payload` size can go up as we increase the gas limit.

## Builder-API Spec

https://github.com/ethereum/builder-specs/pull/138

## TODO

Add links to types