# Minimalistic ePBS with Inclusion List

Enshrined Proposer-Builder Separation adds several advantages over today’s reliance on MEV-boost, an out-of-protocol solution. These advantages include decentralising the relay architecture, smoothing developer coordination especially during critical times, and reducing other associated risks. For a detailed explanation of ePBS benefits, check out Mike and Justin’s post [here](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710).

This version of ePBS is based off of the PTC (Payload Timeliness Committee) [proposal](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054) by Mike and Francesco.

## Architecture

<img src="https://ethresear.ch/uploads/default/optimized/2X/9/97e11a0f4f54cc43b6c009ff46344e93bbc6ff6b_2_1380x360.png">

## Workflow

<!--check out the EB PR -->

**(1) Validators are assigned to PTC.**
- Some validators are selected to locally aggregate attestations with similar `attestation_data` to their `attestation` for the assigned `slot`.
- Validators may also be PTC-specific attesters.
- Assignment to the PTC is known one epoch in advance.
- PTC selection is only stable within the context of the current and next epoch.
- If a validator is assigned to be an aggregator for the slot, then they should subscribe to the pubsub topic.

**(2) The builder is required to have a higher stake. They produce and sign execution payloads.**
- A builder is an optional validator block-builder role. A validator can become a builder by posting ETH as collateral to `0x02`. Builders have a withdrawal prefix of `0x0b` and joins a builder registry.

**(3) The proposer must construct and broadcast an InclusionList at the same as a signed `BeaconBlock`. Proposer for slot `N` broadcasts the IL at the beginning of the slot and aggregates its attestations. The builder for the next slot `N+1` is forced to include the IL. The proposer will broadcast the InclusionList to the list subnet (InclusionList pubsub topic).**
- The IL is available from the EL.
- The IL can include a max count of 16 txns andare bound by gas limits. This leaves flexibility for the builder to not include the IL if the block is full. *(**@potuz** notes: If we go with the standard aproach (non-forced) then we can have arbitrarily large ILs. The reason for choosing forced in the first iteration is that 1) they have much stronger censorship resistance features and 2) they are trivial to specify and easier to implement).*

**(5) Attesters should receive a `Summary` along with the IL's list of transactions.**
- Payload attestations can only be included in blocks for N if the attestations are for N-1. This means that there are exactly two valid PTC attestations that can be included: voted for present or voted for not present. Notice that proposers are not even incentivized to include PTC attestations that voted incorrectly so we could even make this 1 attestation.

**(6) Attesters should create and broadcast the payload_attestation_message to the global execution attestation subnet at `SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT` seconds after the slot.**
- PTC attesters must broadcast the payload attestation message.
- PTC attestations are treated like regular attestations in regards to rewards, the proposer that includes them gets rewarded just like a normal attestation and the PTC member is rewarded as if they had gotten head, target and source correctly.

## Definitions & Data Structures

1. **Inclusion List**
2. **Summaries** are lists consisting of addresses sending transactions and their gas limits.
3. **PTC Attestations**

## Open Design Questions & Risks
- Split view attack possible
- Uptake of ePBS is uncertain as relays can still be used
- The fact that proposers can send multiple inclusion lists, even contradicting ones, gives validators plausible deniability and this removes an attack vector on free data availability.
- Fork mechanics to onboard builders from validators that have over 1024?
- Should there be more constraints on IL txs?