# Two slots PBS with unconditional payment

Author: @terencechain

Over the last few days, I reviewed Vitalik's post on [two slot proposer builder separation](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980). The main idea is to split the current mev-boost's commit-reveal scheme into an in-protocol two-slot scheme. Where the builder submits the header, the proposer proposes the blind block, some attesters vote for the blind block, and when there are enough blind block votes, the builder reveals the full block. The rest of the attesters and aggregators perform the rest of the duties similar to today post attestation cut off time at 1/3 of the slot. In the following sections, I'll break down the interactions into steps, then wrap up the post with some analysis of attack vectors and open challenges.

### Terminologies
- **Slot**: Where one beacon block gets proposed
- **Header (or proposer) slot**: The first half of the slot. Think of it like a commit slot
- **Payload (or builder) slot**: The second half of the slot. Think of it like a reveal slot. The original post had it as an intermediate slot
- **Execution header**: Execution information where transactions are blinded
- **Execution payload**: Execution information where transactions are in clear
- **Blind Beacon block**: Block contains execution header
- **Beacon block**: Block contains execution payload
- **Blind block attester**: Vote for blind block
- **Attester**: Vote for beacon block

### Step 0: Builder registration on the beacon chain
Builder is part of the consensus actor and registered in the beacon chain. Similar to the validator deposit workflow, we need a builder deposit workflow. Builder will be part of `BeaconState` and probably look close to the `Validator` registry structure.

Open challenges:
- UX

### Step 1: Builder header submission
Builder submits an `ExecutionHeader` with `Bid` to the `builder_header_subnet` as close to the start of the slot as possible. Proposer receives them and does basic p2p validations on the subnet. It checks the following.
- Builder is registered
- Builder has not been slashed. (Will there be any slashing conditions?)
- Builder has enough balances to pay the bid

There's not much reason to re-gossip the header back to peers given there's just one proposer per slot, and the proposer is incentivized to be well-connected to all the builders.

Open challenges:
- New gossip network for the builder to submit header + bid to the proposer
- Unlikely DOS vectors for the proposer

### Step 2: Proposer header selection and blind block submission
At the start of the slot, the proposer will choose the "best" `ExecutionHeader` to include for blind block proposal at the header slot. The "best" here is a little subjective, it could be the header with the highest bid. Or it could be the header with the highest bid that satisfies some inclusion list property. It's unclear whether the notion of "best" should be part of the consensus protocol (i.e mev burn?) or just let the proposer choose whatever it wants. The proposer will submit the blind block to the `beacon_blind_block_subnet`. Proposer boost is applied to the on-time blind block.

Open challenges:
- Proposer header selection
- Slashing condition for signing more than one blind block
- New gossip network for proposer to submit blind block

### Step 3: Attester attestation submission for blind block
Before the attestation cutoff threshold during the header slot, some attesters (think one committee worth) will attest the blind block to be valid and canonical. There's no notion of execution validity here since the blind block can't be executed. The attesters will attest to the blind block for consensus validity, and it's the head of the chain.
Given the beacon block root is the same between blind block and beacon block. The existing Attestation structure can likely be reused (nice!)
Attester will broadcast the attestation to the `blind_block_attestation_subnet` as soon as the blind block is validated with consensus rules and fork choice.

Open challenges:
- New gossip subnet for blind block attestation
- Attester committee selection and shuffling. I mentioned one committee, but it could be more than one committee. How do we determine what size of the committees is safe enough? What is the trade-off here?
- The builder and proposer trust the attester committee here through honest majority assumption. What malicious things can blind-block attesters do? How likely or damaging are attacks like post-ex reorg?
- Fork choice complexity on the client implementation. We need (slot, block) combo. The client implements different structures. Most clients use a proto array, Prysm uses a doubly linked list.
- Given attestation structure is the same, we might be able to re-use the existing attestation subnet. Is that worth optimization for?

### Step 4: Builder reveals blind block and submits full beacon block
Bulders listen on both the `blind_block_attestation_subnet` and the `beacon_blind_block_subnet`. When the builder sees that the following conditions are satisfied
- Its execution header has been included in a blind block
- There are enough attestations from the blind block attesters for its blind block to be "safe" (subjectively reorg-resistent)

The builder will then reconstructs the full beacon block, which includes `ExecutionPayload` and the attestations that voted the blind block and broadcast it out at the start of the payload slot to the `beacon_block_subnet` (same subnet that we have been using for the beacon block today)

Open challenges:
- Confidence to determine that the blind block is "safe"

### Step 5: Attesters and aggregators vote for the beacon block. Same as today
Once the builder broadcasts the beacon block, the rest of the interactions between attesters and aggregators remain similar to today's attester cut-off and aggregator cut-off times. The subtle difference here is that the attester verifies full beacon block originated from the builder rather than the proposer. Builder releasing the block on time should have a proposer boost. (or builder boost? lol)

Open challenges:
- Same trust assumption as today. Attester committees via honest majority to not reorg the chain for MEV stealing
- Similar Fork choice complexity on client implementation as step 3

### Attack vectors and open questions
- A single slot is now split into two intermediate slots. The duration will be increased. How does that affect UX. I believe portions of steps can be overlapped, it's worth studying how much parallelization can be achieved
- Blind attester committee shuffling. How often? How many committees and the trade-offs
- Skip slot scenarios
- Proposer is offline during header slot
- Builder is offline during payload slot
- Both are offline
- Can the protocol optimize these skip slot scenarios so that we don't have waste / idle time
- How does the builder determine when it's safe to reveal the full payload
- Fockchoice complexities. Do we need to account for (block, slot) combo?
- General design makes it hard for the builder to screw the proposer given unconditional payment. Can the proposer screw the builder in any other ways? (ie self slash, try to reorg the chain, special attacks... etc)