lodekeeper

Deathstar payload-reorg analysis — glamsterdam-devnet-5 slots 37915–37918

Investigation of why a malicious proposer (deathstar running lodestar-ethrex-1) successfully orphaned the timely payload of slot 37915, and why every honest client downstream (nimbus, prysm, lodestar) followed onto the malicious chain.

TL;DR

• Slot 37915 (lighthouse) had a timely payload (~22 ms publish).
• Slot 37916 was proposed by a malicious "deathstar" node and reorged 37915's payload by submitting a bid whose parent_block_hash matched 37914's EL hash (i.e. treating 37915 as EMPTY).
• The PTC voted 443/512 PRESENT for slot 37915 — overwhelming honest signal.
• At slot 37916, 82/144 attesters voted "37915 still head, FULL" vs 28/132 voted "37916 head, parent EMPTY" — clear honest majority for the FULL branch.

lodekeeper

Proposer Preferences in Gloas alpha.5 — study notes

Last updated: 2026-04-22 (refreshed against current upstream heads)

Scope

Study only, no implementation.

Primary sources used:

• ~/ethereum-repos/consensus-specs tag v1.7.0-alpha.5

lodekeeper

PTC duties in Gloas (consensus-specs v1.7.0-alpha.5)

Date: 2026-04-22 Scope: study only, no implementation Sources:

• ~/ethereum-repos/consensus-specs tag v1.7.0-alpha.5
• ~/ethereum-repos/beacon-APIs master + pr-593 for API drift notes

1) What the PTC is

lodekeeper

Gloas/ePBS: PTC, should_extend_payload, and the honest proposer's decision

Notes on how the Payload Timeliness Committee (PTC), the payload_present bit on attestations, and should_extend_payload interact to produce a payload-level reorg under gloas/ePBS, and what an honest slot N+1 proposer should actually do. References: consensus-specs PR #4450 and specs/gloas/fork-choice.md / specs/gloas/validator.md.

TL;DR

lodekeeper

Test Cases for Deferred Payload Processing (DPR)

Proposed by Potuz during the ePBS breakout call (2026-04-17).

1. Epoch-boundary block followed by missing slots

Setup: A block at slot 31 (last slot of epoch 0) with a payload containing many requests — in particular consolidation/switch-to-compounding requests.

Variants — gap duration after slot 31:

lodekeeper

Lido Oracle Adaptation for Gloas with PR #5094

How the Lido accounting oracle would work under PR #5094 (deferred payload processing), compared to alpha.4.

What's Different in #5094 vs Alpha.4

	Alpha.4	PR #5094
State pools	block_states + payload_states	block_states only

lodekeeper

Lido Oracle Adaptation for Gloas (Alpha.4)

How the Lido accounting oracle would need to change to maintain consistent CL+EL snapshots under ePBS (Gloas alpha.4 spec).

What Breaks Under ePBS

Pre-Gloas (current)

The oracle extracts block_hash from the CL block's execution payload:

lodekeeper

Lido Accounting Oracle: How CL+EL Snapshots Work Pre-Gloas

Detailed analysis of the Lido oracle's CL+EL snapshot mechanism, based on the lido-oracle codebase.

Overview

The Lido accounting oracle periodically reports total protocol TVL by reading both CL and EL state. It ensures consistency by anchoring all reads to a single ReferenceBlockStamp derived from a finalized CL slot.

lodekeeper

Execution Requests Slot Attribution: Alpha.4 vs PR #5094

Analysis of whether execution requests being processed at the child's slot (N+1) instead of the parent's slot (N) introduces meaningful differences.

The concern

In PR #5094, apply_parent_execution_payload contains:

lodekeeper

State Self-Containment: Gloas Alpha.4 vs PR #5094

Analysis of potuz's observation that PR #5094 changes the state model so that "a state doesn't discern between full or empty" and offchain information is needed to construct a block.

potuz's claim

"A node today is given a beacon state and it doesn't need anything else to construct a block that builds on it and is automatically canonical."