# ePBS design spaces notes

Author: @terencechain

**Looking at the two approaches in**
- https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877
- https://ethresear.ch/t/two-slot-proposer-builder-separation/10980

**General theme**
- All solutions using a commit-reveal based approach. This mirrors hybrid-PBS / mevboost today

**Common questions: what does it to replace the relayers?**
*Minimal requirements*
- New attester duties
- New fork choice rule
- New p2p gossip networks
- Which leads to open designs (fun!)

**Attester duty for builder header**
- Some shuffling and committee selection algo is required
- Leverage the same trust assumption as existing beacon chain
- What "validations" done on the header is open design space. This dictates the proposer "freedom". What should the protocol enforces that leads to possible extensions:
- MEV burn
- Inclusion list (IL)

**New forkchoice rule(s)**
- Protocol wants to discourage:
- builder & proposer "colluding"
- proposer stealing from builder (ie unbundling attack)
- Maybe slashing rule? Header equivocation
- Maybe a new LMD GHOST rule? remove equivocation weights and move them to parent
- Re-org late block (poor man's block slot). Currently implemented for Prysm and Lighthouse Proposer-based. but useless in dealing builder and proposer from colluding
- (Block, slot). Attester-based re-org late block
- SSF
- Honorable mention: "head lock". Can we just apply this on top of existing fork choice rule and call it done?

**P2P gossip network**
- New new gossip nets for attesters, builders, and proposers to exchange data
- Gossip for header (commit-phase)
- Gossip for attestation on header (commit-phase)
- Builder block, attestation and aggregated attestation can re-use existing gossip networks
- DOS is discouraged if builder identity is on the chain
- Harder question: when do builder reveals full block? Wait for header to contain enough weight. Interesting tradeoffs

**New cryptography**
- Threshold cryptography is only needed for distributed availability oracle
- Avoid if possible

**UX**
- How to onboard builders to the beacon chain?
- Builder is also a validator?
- New "type" of client?

**Open questions**
- Do we want IL?
- Do we want mev-burn?
- What is the new node requirement? Mostly bandwidth addition. Don't think it's too bad
- How to choose duty intervals?
- Invalid payload will cause a missing slot, even with unconditional payment, which still needs improvement. Can we do better?
- How to efficiently fill in skip slot gaps? If the proposer is offline, can we do something useful in the second 8s slot?