# ePBS Testing Scenarios (EIP-7732) ## Slot Timeline Reference - **t=0s**: Proposer broadcasts beacon block containing `SignedExecutionPayloadBid` - **t=4s**: Attestation deadline — validators attest to consensus block (execution validation NOT required) - **t=6s**: Builder reveal deadline — builder broadcasts `SignedExecutionPayloadEnvelope` - **t=9s**: PTC attestation deadline — PTC members broadcast `PayloadAttestationMessage` - **t=10s**: Blob availability deadline **Slot States:** FULL (beacon block + payload), EMPTY (beacon block, no payload), SKIPPED (no beacon block) --- ## 1. Happy Path ### 1.1 Basic Block Production & ePBS Flow | ID | Scenario | Verify | Status | |----|----------|--------|--------| | HP-1 | Builder submits valid bid, proposer includes it, builder reveals on time, PTC votes PAYLOAD_PRESENT | State transitions correctly, proposer receives payment, execution payload processed, slot is FULL | :x: | | HP-2 | Multiple consecutive FULL slots across an epoch | Epoch processing succeeds, builder pending payments roll to pending withdrawals, finality achieved | :x: | | HP-3 | Builder bid with maximum blob commitments (`MAX_BLOB_COMMITMENTS_PER_BLOCK`) | All blob KZG commitments validated, blobs available, PTC attests correctly | :x: | | HP-4 | Builder bid with zero blobs | Valid bid, FULL slot, no blob availability issues | :x: | | HP-5 | Multiple builders submit competing bids for the same slot | Proposer selects one, only selected builder's payment deducted, losing builders unchanged | :x: | | HP-6 | Proposer self-builds using `BUILDER_INDEX_SELF_BUILD` (no external builder) | Valid block produced, no builder signature required, no builder balance deducted | :x: | | HP-7 | Proposer receives payment from builder upon beacon block inclusion (not upon reveal) | Unconditional payment — payment occurs regardless of subsequent payload reveal | :x: | | HP-8 | Builder pending payments tracked during slot, rolled into pending withdrawals at epoch boundary | Correct epoch boundary processing via `process_builder_pending_payments` | :x: | ### 1.2 Validator Operations | ID | Scenario | Verify | Status | |----|----------|--------|--------| | HP-9 | Validator submits attestation for a FULL slot | Attestation processed, fork choice weight updated, participation tracked | :x: | | HP-10 | Validator submits attestation for an EMPTY slot (beacon block present, no payload) | Attestation valid for consensus block, processed normally | :x: | | HP-11 | Sync committee member produces `SyncAggregate` contribution | Sync aggregate included in next block, light client protocol functions | :x: | | HP-12 | Proposer slashing — valid evidence of proposer equivocation submitted | Slashing processed, offending validator penalized and force-exited, whistleblower rewarded | :x: | | HP-13 | Attester slashing — valid evidence of attester equivocation submitted | Slashing processed, offending validators penalized, whistleblower rewarded | :x: | | HP-14 | Validator submits `SignedVoluntaryExit` | Exit initiated, validator enters exit queue, withdrawable after exit period | :x: | | HP-15 | Validator `BLSToExecutionChange` — switch withdrawal credentials from BLS (`0x00`) to execution address (`0x01`) | Withdrawal credentials updated, validator eligible for automatic withdrawals | :x: | | HP-16 | Validator full withdrawal — exited validator's balance swept to execution address | Balance withdrawn via execution payload withdrawals in a FULL slot | :x: | | HP-17 | Validator partial withdrawal — excess balance above `MAX_EFFECTIVE_BALANCE` auto-swept | Partial withdrawal included in execution payload, balance reduced to max effective | :x: | | HP-18 | EL-triggered voluntary exit via `WithdrawalRequest` (EIP-7002) with `amount=0` | Validator exit initiated from execution layer, no BLS key needed | :x: | | HP-19 | EL-triggered partial withdrawal via `WithdrawalRequest` (EIP-7002) with `amount>0` | Partial withdrawal processed, specified amount queued for withdrawal | :x: | ### 1.3 Deposit Operations | ID | Scenario | Verify | Status | |----|----------|--------|--------| | HP-20 | Legacy Eth1 deposit — new validator deposit via deposit contract Merkle proof | Deposit processed, validator added to `pending_deposits`, activated after eligibility delay | :x: | | HP-21 | EL-triggered deposit via `DepositRequest` (EIP-6110) — new validator | Deposit request in execution payload processed, validator queued for activation | :x: | | HP-22 | EL-triggered top-up deposit for existing validator | Validator balance incremented, effective balance updated at epoch boundary | :x: | | HP-23 | Validator consolidation via `ConsolidationRequest` (EIP-7251) — merge two validators into one | Source validator exits, balance transferred to target, target effective balance increases (up to 2048 ETH) | :x: | ### 1.4 Builder Lifecycle Operations | ID | Scenario | Verify | Status | |----|----------|--------|--------| | HP-24 | Builder registration — deposit with `0x03` withdrawal credentials prefix | Builder added to `state.builders` registry, assigned builder index, can submit bids | :x: | | HP-25 | Builder top-up deposit — additional deposit to existing builder pubkey | Builder balance incremented, can cover larger bid values | :x: | | HP-26 | Builder voluntary exit via `SignedVoluntaryExit` with builder-encoded index | `withdrawable_epoch` set to `current_epoch + MIN_BUILDER_WITHDRAWABILITY_DELAY` (64 epochs) | :x: | | HP-27 | Builder exit via EL-triggered `WithdrawalRequest` from builder's execution address | Builder exit initiated from execution layer | :x: | | HP-28 | Builder withdrawal — exited builder reaches `withdrawable_epoch`, balance swept | Builder balance returned to `execution_address`, builder removed from active set | :x: | | HP-29 | Builder bid payment settlement — pending payment honored after PTC attests PRESENT | Payment deducted from builder balance, credited to proposer | :x: | | HP-30 | Builder bid payment voided — PTC attests ABSENT, builder still charged | Builder loses bid amount (unconditional payment to proposer) | :x: | | HP-31 | Multiple builders register across several epochs | Builder indices assigned correctly, all builders can submit bids independently | :x: | ### 1.5 PTC Duties | ID | Scenario | Verify | Status | |----|----------|--------|--------| | HP-32 | PTC member produces and broadcasts `PayloadAttestationMessage` for timely payload | Message accepted on gossip, included in next block's `payload_attestations` | :x: | | HP-33 | Proposer includes aggregated PTC attestations from previous slot in beacon block | Up to `MAX_PAYLOAD_ATTESTATIONS` (4) aggregates included, all validated | :x: | ### 1.6 Epoch Boundary Processing | ID | Scenario | Verify | Status | |----|----------|--------|--------| | HP-34 | Epoch transition with mix of FULL and EMPTY slots | Justification/finalization computed, pending payments settled, rewards/penalties applied | :x: | | HP-35 | Epoch transition processes `builder_pending_payments` into `builder_pending_withdrawals` | All pending payments from the epoch correctly rolled over | :x: | | HP-36 | Epoch transition applies validator rewards and penalties | Attestation rewards, sync committee rewards, proposer rewards all computed correctly | :x: | | HP-37 | Epoch transition processes pending validator deposits and activations | Validators in activation queue activated up to churn limit | :x: | | HP-38 | Epoch transition processes validator exits and ejections | Validators below ejection balance force-exited, voluntary exits finalized | :x: | | HP-39 | Epoch transition updates effective balances | Effective balances adjusted based on actual balances with hysteresis | :x: | | HP-40 | Epoch transition shuffles committees and assigns new PTC | New PTC committee selected for next epoch's slots via RANDAO-based shuffling | :x: | --- ## 2. Builder Behavior ### 2.1 Honest Builder | ID | Scenario | Verify | Status | |----|----------|--------|--------| | BH-1 | Builder reveals payload at t=2s (well before deadline) | PTC unanimously votes PAYLOAD_PRESENT, FULL slot, `BUILDER_REVEAL_BOOST` applied | :x: | | BH-2 | Builder reveals payload at t=5.9s (just before PTC deadline) | Some PTC members may not see it in time, mixed votes, behavior depends on threshold | :x: | | BH-3 | Builder reveals payload with valid state root matching post-state | State root commitment in envelope matches computed state | :x: | ### 2.2 Dishonest Builder — Withholding | ID | Scenario | Verify | Status | |----|----------|--------|--------| | BD-1 | Builder wins bid, never reveals payload | PTC votes ABSENT, slot EMPTY, proposer still receives payment, builder loses bid amount | :x: | | BD-2 | Builder reveals payload after PTC deadline (t=10s+) | Payload rejected as untimely, slot EMPTY, PTC voted ABSENT | :x: | | BD-3 | Builder withholds blobs but reveals payload body | Blob availability check fails, PTC votes ABSENT, slot EMPTY | :x: | | BD-4 | Builder withholds payload for multiple consecutive slots | Chain progresses with EMPTY slots, withdrawal processing paused until FULL slot | :x: | | BD-5 | Builder withholds payload at epoch boundary slot | Epoch processing handles EMPTY final slot, pending payments processed correctly | :x: | ### 2.3 Dishonest Builder — Equivocation | ID | Scenario | Verify | Status | |----|----------|--------|--------| | BD-6 | Builder sends two different `SignedExecutionPayloadEnvelope` for same slot | Only one accepted, gossip validation rejects duplicates | :x: | | BD-7 | Builder sends payload with incorrect block hash (doesn't match bid) | Rejected by gossip validation, slot EMPTY | :x: | | BD-8 | Builder sends payload with incorrect `beacon_block_root` | Rejected, does not match beacon block containing bid | :x: | | BD-9 | Builder sends payload with incorrect `state_root` | State root mismatch detected during async execution validation | :x: | | BD-10 | Builder submits bid with value > balance | Bid rejected during `process_execution_payload_bid` | :x: | | BD-11 | Builder reveals payload to only a subset of PTC members (selective reveal) | Mixed PTC votes, threshold determines FULL or EMPTY, fork choice handles split view | :x: | ### 2.4 Free Option Problem | ID | Scenario | Verify | Status | |----|----------|--------|--------| | BD-12 | Builder commits at t=0, monitors market, withholds if unfavorable | EMPTY slot if withheld, payment still deducted from builder | :x: | | BD-13 | Builder exercises free option during high-volatility period (multiple consecutive withholdings) | Network liveness maintained, slot production continues | :x: | | BD-14 | Builder withholds blobs specifically (longer window to t=10s vs payload at t=6s) | Blob withholding detected by PTC, slot EMPTY | :x: | --- ## 3. Proposer Behavior ### 3.1 Honest Proposer | ID | Scenario | Verify | Status | |----|----------|--------|--------| | PH-1 | Proposer selects highest-value valid bid from available builders | Correct bid selected, payment matches bid value | :x: | | PH-2 | Proposer includes PTC attestations from previous slot in beacon block body | `MAX_PAYLOAD_ATTESTATIONS` (4) limit respected, attestations validated | :x: | | PH-3 | Proposer broadcasts beacon block at t=0 | Propagation within attestation deadline, attesters can validate consensus portion | :x: | ### 3.2 Dishonest Proposer | ID | Scenario | Verify | Status | |----|----------|--------|--------| | PD-1 | Proposer includes invalid builder bid (invalid signature) | Block rejected by other validators | :x: | | PD-2 | Proposer includes bid from builder with insufficient balance | Block rejected during state transition | :x: | | PD-3 | Proposer delays beacon block to t=3.5s (timing game) | Reduced attestation participation, possible SKIPPED from some validators' perspective | :x: | | PD-4 | Proposer includes stale PTC attestations from wrong slot | Attestation slot validation fails, block rejected | :x: | | PD-5 | Proposer includes more than `MAX_PAYLOAD_ATTESTATIONS` | Block rejected | :x: | | PD-6 | Proposer equivocation — two different beacon blocks with different builder bids | Slashing condition triggered, fork choice handles competing blocks | :x: | | PD-7 | Proposer withholds beacon block entirely | Slot SKIPPED, next proposer builds on previous head | :x: | | PD-8 | Two consecutive proposers (same entity) attempt to reorg builder's payload from slot N | `BUILDER_REVEAL_BOOST` protects honest reveals, reorg fails unless attacker controls >20% stake | :x: | | PD-9 | Proposer at N+1 forces EMPTY version of slot N (ignoring builder's timely reveal) | Fork choice prevents this when PTC voted PRESENT | :x: | --- ## 4. PTC Voting ### 4.1 Normal Operation | ID | Scenario | Verify | Status | |----|----------|--------|--------| | PTC-1 | All 512 PTC members vote PAYLOAD_PRESENT for timely reveal | `BUILDER_REVEAL_BOOST` applied, FULL slot, unanimous | :x: | | PTC-2 | All 512 PTC members vote PAYLOAD_ABSENT for withheld payload | EMPTY slot, parent block gets boost | :x: | | PTC-3 | Exactly `PAYLOAD_TIMELY_THRESHOLD` members vote PRESENT | Threshold met, FULL slot, boost applied | :x: | | PTC-4 | One fewer than threshold votes PRESENT | Threshold NOT met, slot may become EMPTY despite some validators seeing payload | :x: | ### 4.2 Split Views | ID | Scenario | Verify | Status | |----|----------|--------|--------| | PTC-5 | 50/50 split — half PTC sees payload, half does not (network partition within PTC) | Fork choice resolves based on threshold, no consensus split | :x: | | PTC-6 | PTC members in different regions see payload at different times | Members receiving before deadline vote PRESENT, others ABSENT | :x: | | PTC-7 | Some PTC members offline (e.g., 100 of 512) | Threshold calculation accounts for missing votes | :x: | | PTC-8 | All PTC members offline or fail to vote | Default EMPTY behavior, chain continues | :x: | ### 4.3 Equivocation & Attacks | ID | Scenario | Verify | Status | |----|----------|--------|--------| | PTC-9 | PTC member votes both PRESENT and ABSENT for same slot | Equivocation handled, one or both rejected | :x: | | PTC-10 | PTC member votes PRESENT without receiving payload | Protocol can't directly enforce, fork choice weight reflects majority | :x: | | PTC-11 | Attacker controls minority of PTC, attempts to manipulate outcome | With 512 members and random selection, manipulation requires impractical stake | :x: | | PTC-12 | PTC member sends attestation for wrong `beacon_block_root` | Rejected by gossip validation | :x: | | PTC-13 | PTC member sends attestation for future slot | Rejected, slot validation fails | :x: | ### 4.4 Aggregation | ID | Scenario | Verify | Status | |----|----------|--------|--------| | PTC-14 | Proposer at N+1 aggregates PTC attestations from slot N into `payload_attestations` | Correct aggregation, fits within `MAX_PAYLOAD_ATTESTATIONS` (4) | :x: | | PTC-15 | PTC attestations arrive late (after N+1 proposer builds block) | Late attestations not included in that block, handled by fork choice directly | :x: | --- ## 5. Fork Choice ### 5.1 Head Selection with Payload Status | ID | Scenario | Verify | Status | |----|----------|--------|--------| | FC-1 | Two competing tips: FULL slot vs EMPTY slot | FULL preferred when `BUILDER_REVEAL_BOOST` applies and PTC threshold met | :x: | | FC-2 | Chain tip has PENDING payload status (within reveal window) | Fork choice defers head selection, attesters can still attest to consensus block | :x: | | FC-3 | Fork: 3 consecutive EMPTY slots vs 2 FULL slots | Attestation weight correctly computed, FULL branch preferred with more weight | :x: | | FC-4 | FULL slot at tip but execution validation fails async | Fork choice updated to treat slot as EMPTY/invalid, chain reorgs to valid branch | :x: | ### 5.2 Boost Mechanics | ID | Scenario | Verify | Status | |----|----------|--------|--------| | FC-5 | `BUILDER_REVEAL_BOOST` applied when PTC threshold reached, removed after window | Boost is ephemeral, does not persist into subsequent slots | :x: | | FC-6 | Competing blocks at same height, one boosted, one not | Boosted block wins during window, after expiry normal LMD-GHOST applies | :x: | | FC-7 | Proposer boost and builder reveal boost interact at slot boundary | Both boosts applied correctly, no double-counting | :x: | ### 5.3 Deferred Execution | ID | Scenario | Verify | Status | |----|----------|--------|--------| | FC-8 | Execution payload received but EL returns INVALID after full validation | Fork choice transitions block from FULL to invalid, chain reorgs | :x: | | FC-9 | EL slow to validate (>6 seconds) | Consensus continues without waiting, PTC votes based on receipt not validity | :x: | | FC-10 | EL crashes during payload validation | CL continues consensus, marks payload PENDING until EL recovers | :x: | --- ## 6. Network Partition & Latency ### 6.1 Builder Partitioned | ID | Scenario | Verify | Status | |----|----------|--------|--------| | NP-1 | Builder partitioned from all validators after committing bid | Cannot reveal, PTC votes ABSENT, slot EMPTY, builder loses bid | :x: | | NP-2 | Builder partitioned from PTC only (reaches some validators) | PTC votes ABSENT, slot EMPTY | :x: | | NP-3 | Builder reconnects and reveals after PTC deadline but before next slot | Late reveal ignored, slot remains EMPTY | :x: | ### 6.2 Proposer Partitioned | ID | Scenario | Verify | Status | |----|----------|--------|--------| | NP-4 | Proposer partitioned, beacon block not seen by attesters by t=4s | No attestations, slot effectively SKIPPED | :x: | | NP-5 | Proposer's beacon block arrives late (t=3s) due to latency | Reduced attestation weight, competing chain head may emerge | :x: | ### 6.3 General Partitions | ID | Scenario | Verify | Status | |----|----------|--------|--------| | NP-6 | Network splits 50/50 for one epoch | Neither side finalizes, chain heals on resolution, finality resumes in 2-3 epochs | :x: | | NP-7 | One side has builder+proposer, other has majority attesters | Majority side treats slot as SKIPPED | :x: | | NP-8 | Asymmetric partition: payload reaches 60% of PTC, 40% does not | PTC threshold determines outcome, majority PRESENT makes slot FULL | :x: | ### 6.4 High Latency | ID | Scenario | Verify | Status | |----|----------|--------|--------| | NP-9 | Global latency spike (all messages delayed 2-3 seconds) | Deadlines still met with reduced margins, some missed attestations, chain continues | :x: | | NP-10 | Latency spike at builder reveal time (payload arrives at PTC at deadline) | Borderline PTC votes, fork choice must converge | :x: | | NP-11 | Latency between CL and EL on same node (Engine API delayed) | Deferred execution tolerates this, PTC attestation unaffected by EL slowness | :x: | --- ## 7. Reorg Scenarios ### 7.1 Single-Slot Reorgs | ID | Scenario | Verify | Status | |----|----------|--------|--------| | RO-1 | Slot N block arrives late, slot N+1 proposer builds on N-1 | If slot N has sufficient weight (incl. PTC boost), it reorgs back in | :x: | | RO-2 | Builder reveals at N, proposer N+1 builds on EMPTY version of N | `BUILDER_REVEAL_BOOST` prevents this when PTC attested PRESENT | :x: | | RO-3 | Proposer equivocation at slot N (two beacon blocks) | Fork choice selects one deterministically, slashing evidence generated | :x: | ### 7.2 Multi-Slot Reorgs | ID | Scenario | Verify | Status | |----|----------|--------|--------| | RO-4 | Three EMPTY slots, then FULL slot on alternate branch from 3 back | Chain follows branch with more cumulative weight | :x: | | RO-5 | Reorg across epoch boundary (last slot of K, first of K+1) | Epoch processing (pending payment rollover) re-executed on new canonical chain | :x: | ### 7.3 Reorg Impact on Builder Payments | ID | Scenario | Verify | Status | |----|----------|--------|--------| | RO-6 | Builder's FULL slot gets reorged out | Builder's payment reversed on new canonical chain | :x: | | RO-7 | Builder's bid included in beacon block on orphaned branch | On canonical branch, builder balance not deducted | :x: | | RO-8 | Builder reveals, PTC attests PRESENT, but reorg makes slot EMPTY | `BUILDER_REVEAL_BOOST` should prevent this unless attacker has >20% stake | :x: | --- ## 8. Slot & Epoch Boundary Edge Cases ### 8.1 Timing | ID | Scenario | Verify | Status | |----|----------|--------|--------| | SB-1 | Builder reveals at exactly t=6s | Deterministic handling — accepted or rejected, no ambiguity | :x: | | SB-2 | PTC member sends attestation at exactly t=9s | Accepted if within tolerance | :x: | | SB-3 | Beacon block arrives at t=3.99s (just before attestation deadline) | Attesters processing in time attest, others do not | :x: | | SB-4 | Clock skew between nodes (500ms ahead/behind) | Chain converges despite minor differences | :x: | ### 8.2 Epoch Boundaries | ID | Scenario | Verify | Status | |----|----------|--------|--------| | SB-5 | EMPTY slot at last slot of epoch (slot 31) | `process_builder_pending_payments` handles correctly, withdrawals not processed | :x: | | SB-6 | EMPTY slot at first slot of epoch (slot 0) | New PTC committee from new shuffling, builder balance changes finalized | :x: | | SB-7 | All 32 slots in an epoch are EMPTY | No execution state transitions, consensus continues, withdrawal processing paused | :x: | | SB-8 | Builder's withdrawal epoch arrives mid-epoch | Builder excluded from new bids, existing pending payments still processed | :x: | ### 8.3 Genesis / First Slot | ID | Scenario | Verify | Status | |----|----------|--------|--------| | SB-9 | First slot after ePBS fork activation | New state fields initialized, PTC selected, builder registry empty, first bid works | :x: | | SB-10 | No builders registered at fork activation | Proposers can still produce valid blocks without bids | :x: | | SB-11 | Builder registers in same epoch as fork activation | Builder immediately available after deposit processing | :x: | --- ## 9. Transition / Upgrade | ID | Scenario | Verify | Status | |----|----------|--------|--------| | TR-1 | Clean fork transition from pre-ePBS to ePBS at designated epoch | All new state fields initialized, new gossip topics activated | :x: | | TR-2 | Fork transition with pending execution payload in last pre-fork slot | Last pre-fork slot uses old processing, first post-fork uses builder bid | :x: | | TR-3 | Fork transition during missed/skipped slots | Fork activation proceeds correctly even with missed slots around fork epoch | :x: | | TR-4 | Node restart during fork activation epoch | Node identifies correct fork rules based on slot, resumes participation | :x: | | TR-5 | Beacon state migration — new fields initialized | Hash tree root changes correctly at fork boundary | :x: | | TR-6 | Checkpoint sync after fork activation | Node loads ePBS state, PTC duties assigned, can process bids | :x: | | TR-7 | Historical state queries for pre-fork blocks | Pre-fork blocks queryable, old format, no ePBS fields expected | :x: | | TR-8 | Emergency rollback — ePBS fork fails, nodes fall back | Nodes restart with pre-fork config, chain rolls back to last pre-fork finalized state | :x: | --- ## 10. Client Diversity ### 10.1 Multi-Client Interop | ID | Scenario | Verify | Status | |----|----------|--------|--------| | CD-1 | Mixed CL clients (Prysm, Lodestar, Lighthouse, Teku, Grandine, Nimbus) all producing FULL slots | All clients agree on state root, PTC attestations compatible, finality achieved | :x: | | CD-2 | Each CL client paired with each EL client (Geth, Nethermind, Besu, Erigon, Reth, EthereumJS) | Engine API changes work across all pairs, deferred execution handled correctly | :x: | | CD-3 | Different clients handle PTC vote aggregation and gossip differently | All clients converge on same fork choice head despite implementation differences | :x: | | CD-4 | PTC members running different CL clients vote on same payload | All `PayloadAttestationMessage` objects valid and accepted across clients | :x: | ### 10.2 Performance Under Load | ID | Scenario | Verify | Status | |----|----------|--------|--------| | CD-5 | All clients produce FULL blocks at max gas limit with max blob count | All validate within deferred execution window, no client consistently behind | :x: | | CD-6 | Stress test PTC gossip: 512 members broadcast `PayloadAttestationMessage` simultaneously | Gossip layer handles burst, messages arrive before aggregation deadline | :x: | --- ## 11. MEV-Related ### 11.1 Builder Market Dynamics | ID | Scenario | Verify | Status | |----|----------|--------|--------| | MEV-1 | Single builder dominates all slots in an epoch | Protocol functions correctly, no special treatment | :x: | | MEV-2 | Builder submits bid with value=0 | Valid bid, proposer receives nothing, builder builds the block | :x: | | MEV-3 | No builders submit bids for a slot | Proposer can self-build or produce empty beacon block | :x: | ### 11.2 MEV and Withholding | ID | Scenario | Verify | Status | |----|----------|--------|--------| | MEV-4 | Builder discovers higher MEV after committing bid | Cannot change committed block hash, must reveal or withhold | :x: | | MEV-5 | Builder uses blob withholding for longer option window | PTC detects blob unavailability, EMPTY slot | :x: | ### 11.3 Proposer Timing Games | ID | Scenario | Verify | Status | |----|----------|--------|--------| | MEV-6 | Proposer delays beacon block to t=3s for later/higher bids | Reduced attestation participation, diminished proposer reward | :x: | | MEV-7 | Proposer submits own bid as registered builder (self-building) | Valid behavior, net neutral on balance, gets to include own MEV | :x: | | MEV-8 | Builder subsidizes bids (bids more than block is worth) | Protocol processes overpaid bids correctly | :x: | --- ## 12. Gossip & P2P Layer ### 12.1 Topic Validation | ID | Scenario | Verify | Status | |----|----------|--------|--------| | P2P-1 | `SignedExecutionPayloadBid` on gossip | Only valid bids propagated, invalid rejected | :x: | | P2P-2 | `SignedExecutionPayloadEnvelope` on gossip | Only envelopes matching committed bid propagated | :x: | | P2P-3 | `PayloadAttestationMessage` on gossip | Only from actual PTC members for correct slot/root | :x: | | P2P-4 | Duplicate gossip messages | Deduplication, no double processing | :x: | | P2P-5 | Malformed gossip messages (corrupted SSZ) | Rejected at gossip validation layer | :x: | ### 12.2 Ordering & Timing | ID | Scenario | Verify | Status | |----|----------|--------|--------| | P2P-6 | `SignedExecutionPayloadEnvelope` arrives before beacon block | Envelope buffered, processed after block arrives | :x: | | P2P-7 | `PayloadAttestationMessage` arrives before beacon block | Buffered or rejected per spec, no crash | :x: | | P2P-8 | Beacon block arrives but referenced bid never seen on gossip | Block still processable (bid embedded in block body) | :x: | ### 12.3 DoS & Spam | ID | Scenario | Verify | Status | |----|----------|--------|--------| | P2P-9 | Attacker floods network with invalid bids | Gossip validation rejects quickly, no impact on legitimate processing | :x: | | P2P-10 | Attacker sends `PayloadAttestationMessage` from non-PTC validators | PTC membership checked, messages rejected, peer scored down | :x: | --- ## 13. Withdrawals & Deposits | ID | Scenario | Verify | Status | |----|----------|--------|--------| | WD-1 | Validator withdrawals processed in FULL slot | Withdrawals computed, deducted from beacon, credited in execution layer | :x: | | WD-2 | Validator withdrawals in EMPTY slot (builder withholds) | Withdrawals NOT processed, `payload_expected_withdrawals` tracks outstanding | :x: | | WD-3 | Multiple consecutive EMPTY slots then FULL slot | Accumulated withdrawal backlog processed correctly, no withdrawals lost | :x: | | WD-4 | Max withdrawal queue at epoch boundary with EMPTY slot | Withdrawal processing deferred correctly, no overflow | :x: | | WD-5 | Builder initiates exit with pending payments in current epoch | Pending payments honored, balance decremented for outstanding bids | :x: | | WD-6 | Builder balance goes to exactly 0 after bid payment | Builder can't submit new bids, existing bid honored | :x: | | WD-7 | Builder attempts bid with value > balance | Bid rejected during gossip validation or block processing | :x: | --- ## 14. Finality & Justification | ID | Scenario | Verify | Status | |----|----------|--------|--------| | FN-1 | Normal finality: 2 epochs with >2/3 participation, all FULL | Checkpoint justified and finalized as expected | :x: | | FN-2 | Finality with scattered EMPTY slots | Finality still achievable (EMPTY slots have beacon blocks with attestation weight) | :x: | | FN-3 | Finality delay due to many EMPTY slots | Finality resumes when FULL slots return | :x: | | FN-4 | Inactivity leak during prolonged EMPTY slot period | Inactivity scores increase for non-attesting validators, builder behavior doesn't trigger leak for attesters | :x: | --- ## 15. Recovery & Misc Edge Cases | ID | Scenario | Verify | Status | |----|----------|--------|--------| | EC-1 | Builder bid with maximum possible value (entire balance) | Payment processed, balance goes to 0 | :x: | | EC-2 | Very large execution payload at gas limit with max blobs | Propagation, validation, PTC attestation all complete within deadlines | :x: | | EC-3 | Zero-transaction execution payload (empty block) | Valid, FULL slot, builder still pays bid value | :x: | | EC-4 | Builder registry reaches high count (thousands of builders) | No performance degradation in bid processing | :x: | | EC-5 | PTC committee members are also the proposer for same or next slot | Dual duties handled correctly | :x: | | EC-6 | Same validator is PTC member and attester in same slot | Both duties performed, no interference | :x: | | EC-7 | CL node restarts mid-slot during PTC voting phase | Node recovers, doesn't vote twice, resumes duties next slot | :x: | | EC-8 | EL node crashes during deferred execution | CL continues consensus, EL recovers and processes retroactively | :x: | | EC-9 | Full node restart (CL + EL) after missing several slots | Node syncs forward, processes FULL and EMPTY slots correctly | :x: | --- ## Summary | Category | Count | |----------|-------| | Happy Path — Block Production & ePBS Flow | 8 | | Happy Path — Validator Operations | 11 | | Happy Path — Deposit Operations | 4 | | Happy Path — Builder Lifecycle | 8 | | Happy Path — PTC Duties | 2 | | Happy Path — Epoch Boundary Processing | 7 | | Builder Behavior | 17 | | Proposer Behavior | 12 | | PTC Voting | 15 | | Fork Choice | 10 | | Network Partition & Latency | 11 | | Reorg Scenarios | 8 | | Slot & Epoch Boundaries | 11 | | Transition / Upgrade | 8 | | Client Diversity | 6 | | MEV-Related | 8 | | Gossip & P2P | 10 | | Withdrawals & Deposits | 7 | | Finality & Justification | 4 | | Recovery & Misc | 9 | | **Total** | **~176** |