# Builder-API post ePBS for Off-Protocol Builders Design 1

This document aims to one design on 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.
2. If the proposer accepts this bid, it sends a `SignedBeaconBlock` with the `ExecutionPayloadBid` embedded into it to the relay via a POST request.
3. The relay now has enough information to construct the `ExecutionPayloadEnvelope` from the `SignedBeaconBlock` sent. We detail more about constructing the `ExecutionPayloadEnvelope` in an upcoming section.
4. The proposer queries the relay for the `BlindedExecutionPayloadEnvelope` corresponding to the `ExecutionPayloadBid`. The relay returns the corresponding `BlindedExecutionPayloadEnvelope`.
5. The proposer signs it and sends the `SignedBlindedExecutionPayloadEnvelope` back to the relay.
6. The relay is responsible for broadcasting the `SignedExecutionPayloadEnvelope` to the PTC commitee.

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.
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`.

POST `/eth/v1/builder/beacon_block`

### BlindedExecutionPayloadEnvelope Retrival

The proposer queries this API and receives the blinded execution payload envelope corresponding to the execution payload bid.

GET `/eth/v1/builder/blinded_execution_payload_env`

### BlindedExecutionPayloadEnvelope Commitment

The proposer signs the `BlindedExecutionPayloadEnvelope` and sends it to the relay. The relay is responsible for broadcasting the `SignedExecutionPayloadEnvelope` to the PTC commitee.

## Sequence Diagram


## Creating the ExecutionPayloadEnvelope

When the relay receives the beacon block from the proposer via `sendSignedBeaconBlock`, they need to construct the `ExecutionPayloadEnvelope`.
The `payload`, `execution_requests` and `blob_kzg_commitments` will be available to the relay since they are part of the block submitted by the builder to the relay.
The `beacon_block_root` will be available from the signed beacon block submitted by the proposer.
The latest `slot` will be available to the relay.
The relay will have to compute the `state_root` of the `ExecutionPayloadEnvelope`.

It will have to compute this state root by running [process_execution_payload](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/beacon-chain.md#new-process_execution_payload) on the beacon state after running STF on the beacon block with `beacon_block_root`.

## 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?
6. One big question we have is state_root computation of the ExecutionPayloadEnvelope. The relay can compute the state_root of the execution payload envelope but will require the proposer to sign it. This involves another signing step.

## 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.
9. The beacon block has to be propagated in time for attesters to attest to it by the attestation deadline. Payload attestations are broadcasted at t=9s so there is enough time to broadcast an Execution payload envelope.

## Why 4 API calls? Could we not reduce that?

It is better to have 4 API calls and have a simpler to reason about system than try to reduce the API calls and have a more complicated system to reason about.

We could also do the following:

1. Proposer gets the `ExecutionPayloadBid`
2. It receives the bid along with the blob_kzg_commitments and execution_requests.
3. It creates the signed beacon block and does a weird `process_execution_payload` without the full payload where it essentially skips the engine api call to verify the payload. It creates a BlindedExecutionPayloadEnvelope from this.
4. It sends the signed version of the `BlindedExecutionPayloadEnvelope` along with the beacon block.

This can just be 2 API calls but will involve clients writing a new type of `process_execution_payload` just for the case of unstaked builders which is unecessary complexity and more co-ordinate among clients.

The proposer design is also easier to reason about and is 50% similar to the builder-api with staked builders except the part where the proposer needs to reach out to the relay to get the `BlindedExecutionPayloadEnvelope`. Being more in parity with the builder-api with staked builders can help us explain the system better.

## TODO

Add links to types