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
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?
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
graph LR;
builder-->relay-->validator
validators and builders can choose
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
Why PBS?
Preserve validator decentralization
Reduce vertical integration
Make solo-staking competitve
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
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
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
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
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
source
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
graph LR;
attester-->|consensus validation|slot:N,root:M
attester-->|execution validation|revealed,not_revealed
How it would look in practice?
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
@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
Resume presentation
Ethereum enshrined PBS Towards a minimal spec Terence Tsao Core Dev @ Offchain Labs
{"title":"Ethereum ePBS: towards a minimal spec","description":"Why","slideOptions":"{\"theme\":\"solarized\"}","contributors":"[{\"id\":\"be26a7ab-c8e0-4a30-bd7e-266f9e3700bf\",\"add\":20685,\"del\":12078}]"}