# **Proposer<>Relay Interactions with ePBS**

## **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.

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 `ExecutionPayloadHeader`. The proposer releases a `BeaconBlock` containing the committed `ExecutionPayloadHeader`, which is subsequently attested by validators.

At the 6-second mark within the slot, the `ExecutionPayloadEnvelope` is broadcast to the PTC (Payload Timeliness Committee). Simultaneously, blobs from the `BlobsBundle` are split into data columns and distributed to the PTC.

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

## **High Level Design:**
At a high level, the design operates as follows:
The relay serves as an off-chain entity where builders compete to submit their blocks. Under ePBS, MEV-relay interactions effectively reduce to the scenario of validator self-building. In the case of self building, When a validator chooses to reject bids from the peer-to-peer bid pool in ePBS, the validator must construct the `BeaconBlock` using its own `ExecutionPayloadHeader`, broadcast the `BeaconBlock`, and then broadcast the corresponding `SignedExecutionPayloadEnvelope` to the PTC Committee.
The key distinction is that MEV relays maintain direct TCP connections with proposers, unlike the peer-to-peer bid pool which operates through network propagation.
Relay Interaction Flow
The relay interaction process follows these high-level steps:

1. **Initial Contact:** The proposer queries the relay for the best possible `ExecutionPayloadHeader`.
2. **Payload Header Delivery:** The relay provides an `ExecutionPayloadHeader` to the proposer.
3. **Beacon Block Creation and Distribution:** The proposer constructs a beacon block incorporating this `ExecutionPayloadHeader` and returns it to the relay. Both the proposer and relay can broadcast the beacon block, with the relay typically having superior peer connectivity for distribution.
4. **Envelope Commitment:** The relay creates the `ExecutionPayloadEnvelope` using the beacon block root provided by the proposer. It responds with a commitment to this `ExecutionPayloadEnvelope`.
5. **Commitment Signing:** The proposer signs the commitment and transmits it back to the relay.
6. **Final Broadcast:** The relay publishes both the `ExecutionPayloadEnvelope` and the `BlobsBundleV2` (segmented into data columns) to the PTC Committee.


## **API design:**

**Payload Header Retrival**

Returns the `ExecutionPayloadHeader` from the relay.

Path: `GET /eth/v1/builder/header/{slot}/{parent_hash}/{pub_key}`

**Blinded Beacon Block Submission**

Proposer submits the beacon block with the `ExecutionPayloadHeader` packed in.

Path: `POST /eth/v1/builder/blinded_block`

**Full Payload Retrival**

Proposer requests the `ExecutionPayloadEnvelope` from the relay. Should we pass in the slot, parent hash and pub key here? Doesn't seem necessary.

Path: `GET /eth/v1/builder/execution_payload_envelope`

**Execution Payload Envelope Submission**

Proposer packs the full execution payload into an `SignedExecutionPayloadEnvelope`

Path: `POST /eth/v1/builder/signed_execution_payload_envelope`