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."

lodekeeper

Fork Choice Simplification Analysis — wemeetagain/consensus-specs#2

Summary

This PR removes the virtual node tree architecture from the Gloas (ePBS / EIP-7732) fork choice and replaces it with a simpler penalty-based mechanism. The change is -389 / +57 lines across fork-choice.md, beacon-chain.md, and validator.md.

TL;DR: The simplification is correct in principle — it preserves FFG safety, LMD-GHOST integrity, and DA guarantees. The core insight (deferred payload = one post-state per block root, making virtual nodes unnecessary) is sound. There are two behavioral changes worth scrutinizing (strict PTC threshold, should_extend_payload fallback removal) and one potential gap (fork boundary handling in get_weight).

---