1 of 16

PEEPanEIP:

EIP-7732 Enshrined Proposer-Builder Separation Consensus Spec Notes

2 of 16

https://eips.ethereum.org/EIPS/eip-7732

3 of 16

Disclaimers

  • This is NOT a talk about MEV
  • This is NOT a talk on why we should do EIP-7732
  • This is a talk on WHAT is EIP-7732 within the context of consensus specs
  • Aimed at client implementors and those interested in exploring EIP-7732

4 of 16

Key changes

  • Builder is staked on beacon chain and perform consensus duty like validator
  • New committee: Payload Timeliness Committee
    • New validator duty: Payload Timeliness Attestors
  • Beacon block body includes header instead of the full payload
  • A slot is divided into four intervals:
    • Header commitment (0s)
    • Beacon attestation release (3s)
    • Aggregation release / payload release (6s)
    • Payload timeliness attestation release (9s)
  • A slot can be full, skipped, or empty:
    • Full: Both block and execution payload are included on-chain
    • Skipped: Block is missing
    • Empty: Block is on-chain, execution payload is missing
  • Processing of a slot is pipelined into the consensus phase and execution phase
  • Execution validation is has until the next beacon block validation

5 of 16

Specifications Changes

  • Consensus layer
    • Beacon chain: how to run state transitions (both consensus and execution)
      • https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7732/beacon-chain.md
    • Fork choice: how to determine head of the chain
      • https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7732/fork-choice.md
    • P2P: how to accept and forward objects
      • https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7732/p2p-interface.md
    • Honest Validator: how to perform new duties
      • https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7732/validator.md
  • Execution layer
    • Nothing!
  • Engine API
    • Nothing for block auction

6 of 16

Beacon Chain Changes (Containers)

  • New Containers
    • Payload Attestation
      • Single message (signed by PTC members)
      • Aggregated message (included in beacon block body by proposer)
    • Signed Execution Payload Header (included in beacon block body by proposer)
    • Signed Execution Payload Envelope (released by builder)
  • Updated Beacon State Container
    • Modfied execution payload header
    • New new fields: latest block hash, full slot, and withdrawals root
      • Used to verify withdrawals
      • Used to track when a block / state was empty or full

7 of 16

Beacon Chain Changes (State Transition Function)

​

  • Modified Process Withdrawals
    • Cache withdrawals root in beacon state, withdrawals redeemed in the execution phase
  • New Process Payload Attestations
    • Reward PTC members for correct votes
  • New Process Execution Payload Header
    • Verify header, transfer payment from builder to validator, cache header
  • New Process Execution Payload Envelope
    • Verify and process payload, cache latest state
  • Process Deposit, Withdrawal, Consolidation Requests
    • Moved to the execution reveal phase

8 of 16

Validator Changes (New PTC Duty)

  • Figure out when you will perform PTC duty just like beacon attestation duty
    • Use get PTC from spec
  • Figure out how to vote for payload timeliness
    • Current slot consensus block missing = do nothing
    • Payload late = vote absent
    • Payload on time
      • Withheld = vote withheld
      • No withheld = vote present
  • Sign your vote, gossip it to payload attestation subnet

9 of 16

Validator Changes (Solo proposer)

  • Beacon block body construction
    • Filter and aggregate PTC votes (should reflects head state) from the previous slot
  • Execution payload header construction
    • Request execution payload and blobs from EL client
    • Convert execution payload to execution header
    • Sign execution header, include it in the block, broadcast beacon block
  • Broadcast blobs (if any)
  • Execution payload construction
    • Sign execution payload
    • Broadcast execution payload

10 of 16

Validator Changes (Proposer using builders)

  • Select the best value header across three sources:
    • Local EL
    • Signed headers from P2P
    • Signed headers from RPC by pulling directly from builders (Builder-API)
      • Verify the headers are valid
  • If the header from Local EL has the best value
    • Follow the solo proposer path
  • If the header from P2P or RPC has the best value
    • Include the header in the block and gossip the block

11 of 16

P2P Changes

  • Beacon Block gossip:
    • Execution payload validation is no longer required
  • Execution header gossip:
    • Verify header is valid and forward to peers
    • Track only the highest value bid for each parent hash/root
  • Execution payload gossip:
    • Verify payload is valid and forward to peers
  • Payload attestation message gossip:
    • Verify payload attestation mesage is valid and forward to peers
  • Execution payload RPC:
    • Requests can be made by root or range, primarily for syncing purposes

12 of 16

Fork choice changes

  • Modified and New Boost Values:
    • Proposer boost: 40% → 20%
    • Payload withhold boost: 40%
    • Payload reveal boost: 40%
  • (Block, Slot, Reveal) Fork Choice:
    • A node tracks also payload was present
    • A vote tracks both root and slot
  • Fork Choice Store Additional Fields:
    • Execution payload state: Cache execution state
    • PTC votes
    • Payload withhold boost root and full (boolean)
    • Payload reveal boost root

13 of 16

Fork choice handler changes

  • Modified `on_block`
    • Pre-state depends on the parent block root and block hash
    • Blob data availability is deferred until the execution reveal phase
  • New handler `on_payload_attestation_message`
    • Verify the payload attestation message
    • Cache the vote and update the reveal or withhold boost if thresholds are exceeded
  • New handler `on_execution_payload`
    • Verify that blob data is available
    • Process the execution payload state transition function
    • Cache the post state based on the payload

14 of 16

Fork choice get new head

Head is now dependent on the reveal status and new boosts:

  1. Start from the justified (slot, block, reveal_status) (i.e. best block)
  2. Get children that are descendants of the best block and matches the parent reveal status
  3. Add self to the possible children
  4. Find the best child with the most weight, using several tie-breakers
  5. Weight is determined by the summation of attestation votes, ancestor of proposer, reveal boost, and withhold boosts
  6. With the best child, repeat step 2

15 of 16

Miscellaneous

  • Attestation duty
    • PTC can skip attestation duty
  • Changes to accommodate builder
    • Get fork choice weight of a block (Beacon-API)
  • Builder based circuit breaker
    • Client implementation details
  • Builder API changes
    • New get header request
  • Compatible designs
    • Slot auction
    • Inclusion list
    • Peer das

16 of 16

Call to help

​