Ethereum ePBS: towards a minimal spec

## Ethereum enshrined PBS ### Towards a minimal spec *Terence Tsao* Core Dev @ Offchain Labs ---  ## Agenda * *Why* | *What* | *How* PBS? * Towards a **minimal** ePBS spec * Required changes * Open questions * Next steps ---  ## What is PBS? - Split block construction into *two* roles - Execution construction -> builder - Everything else -> proposer ---  ## PBS in Proof of Work - Builder trusts miner to not steal - Miner trusts builder to pay ```mermaid graph LR; builder-->miner_1; builder-->miner_2; builder-->miner_3; miner_1-.-block_N; miner_2-.-block_N-1; miner_3-.-block_N-2; block_N-1-->block_N; block_N-2-->block_N-1; block_N-3-->block_N-2; ``` ---  ## PBS in Proof of Stake - 600000 validators, wat do? ```mermaid graph LR; builder-->validator_1; builder-->validator_2; builder-->validator_3; builder-->validator_4; builder-->validator_600000; validator_1-.-block_N; ``` ---  ## builder and validator relationship * Becomes much weaker in PoS * On average, every validator proposes one block every 6 months * How do we re-establish trust? ---  ## The rise of relays * Trusted by builder to not steal * Trusted by validator for payment * Validate builder block, builder payment, and validator signature ```mermaid graph LR; builder-->relay-->validator ``` ---  ## validators and builders can choose ```mermaid graph LR; builder_1-->relay_1-->validator_1 builder_2-->relay_1-->validator_2 builder_3-->relay_1-->validator_3 builder_2-->relay_2-->validator_4 builder_3-->relay_2-->validator_5 builder_4-->relay_2-->validator_6 relay_1-->validator_4 relay_1-->validator_5 relay_1-->validator_6 relay_2-->validator_1 relay_2-->validator_2 relay_2-->validator_3 ``` ---  ## Today's stats ![](https://hackmd.io/_uploads/SkxN2RE_h.png) [source](https://mevboost.pics/) ---  ## Why PBS? * Preserve validator decentralization * Reduce vertical integration * Make solo-staking competitve ```mermaid graph LR; builder-->|$$$|relayer relayer-->|$$$|$$$_validator_$$$ $_solo_validator_1_$ $_solo_validator_2_$ $_solo_validator_N_$ ``` ---  ## How PBS? * Today: hybrid (out-of-band) approach * Tomorrow: enshrined (in-protocol) approach ---  ## Hybrid version * mev-boost is a relayer aggregator * rational validator subscribes to many relayer through **commit and reveal** ```mermaid graph LR; builder_1-->relayer_1-->mev_boost builder_2-->relayer_1 builder_3-->relayer_1 builder_2-->relayer_2 builder_3-->relayer_2-->mev_boost builder_4-->relayer_2 builder_3-->relayer_3-->mev_boost builder_4-->relayer_3 mev_boost-->validator ``` --- ## Hybrid workflow ```mermaid sequenceDiagram; participant validator participant mev_boost participant relayers participant block_p2p_topic validator->>mev_boost: get_header mev_boost->>relayers: get_header mev_boost->>mev_boost: chooses best header mev_boost->>validator: header validator->>validator: sign validator->>mev_boost: signed_header mev_boost->>relayers: signed_header relayers->>block_p2p_topic: broadcast block ``` ---  ## Why enshrine? * Small set of centralized forces * Weak safety assumption. Takes only one bad relayer! * Weak fault attribution out-of-band * Difficult to coordinate out-of-band * Cost ---  ## Recent events - [low carb crusader](https://collective.flashbots.net/t/post-mortem-april-3rd-2023-mev-boost-relay-incident-and-related-timing-issue/1540) - [shapella prysm bug](https://collective.flashbots.net/t/impact-of-the-prysm-invalid-signature-bug-on-the-mev-boost-ecosystem-at-the-shapella-fork/1623) - [relay response to unbundling](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus) ---  ## Counter arguments on enshrine * "If it ain't broken don't fix it" * Address it application side * Higher precedence items on the roadmap * Hesitation to enshrine until everything is figured out * block vs. slot auction ---  ## epbs desired properties(1/2) * Consensus stability * Discourage proposer & builder & attesters colluding * Builder Payment guarantee * Permissionless to entry * Censorship resistance ---  ## epbs desired properties(2/2) * Proposers and attesters determine the head of the chain. Builder does not * Builder only reveals under **strong** guarantee block will be canonical * Proposer gets paid for including payload * Proposer can choose to use local payload * Anyone can be a builder ---  ## epbs high level * Remove relayer * Enshrine relayer to the protocol * Enshrine builder to the protocol * Attester takes on the relayer role by attesting * Consensus is valid * Execution is available * Invalid execution is **unavailable** ---  ## Quick refresher of attester duty ![](https://hackmd.io/_uploads/H13D8kru2.png) [source](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus) ---  ## Attester roles(1/2) * First 1/2 of slot: consensus validation * source, target (FFG) * head (LMD GHOST) * Second 1/2 of slot: execution validation * Did the builder reveal on time? * Is the execution valid? ---  ## Attester roles(2/2) First half vs. second half of slot ```mermaid= graph LR; attester-->|consensus validation|slot:N,root:M attester-->|execution validation|revealed,not_revealed ``` ---  ## How it would look in practice? ```mermaid sequenceDiagram; participant builder participant proposer participant attester participant bid_p2p participant blind_block_p2p participant full_block_p2p participant execution_p2p participant attestation_p2p builder->>bid_p2p: submit bids proposer->>blind_block_p2p: submit block+bid attester->>attestation_p2p: attest consensus validity builder->>full_block_p2p: reveal full execution payload attester->>attestation_p2p: attest execution availability ``` ---  ## New slot anatomy ![](https://hackmd.io/_uploads/Syk8JexY2.png) @mikeneuder ---  ## New consensus objects - Block contains builder bid - Attestation contains execution reveal status - Builder contains pubkey, balance, status - Execution slashing ---  ## New consensus changes - Add builder to consensus state - Account for unavailable execution. Things like withdrawal can't happen on the same slot - Process builder payment to the proposer - Slash invalid execution reveal - Execution committee slashing handling ---  ## New p2p topics - Builder bid - Proposer block with bid - Attestation for revealed execution - Invalid execution ---  ## New fork choice changes - Premise: block-slot voting or can re-org late block - Emptiness should be possible on block-subtree - View merge over block equivocations - Payload timeliness vote - Available, N/A or equivocation - Only apply to slot `N+1` - New `timeliness_score` calculation ---  ## Builder protection - Protect txs by bounding them to slot ---  ## Open questions - Are we safe from split views? - Builder reveal assurance - Builder & execution committee ex-ante attack N+1 - Do we need to attribute forkhcoice weight to builder? - What are the new UX implications? - What are the new slot intervals? --- ## Thank you! 🙏 (h/t @mikeneuder and @fradamt for most of these) Reach me at @terencechain or ttsao@offchainlabs.com