nflaig

glamsterdam-devnet-4 Stall — Incident Report

Date observed: 2026-05-26 Network: glamsterdam-devnet-4 (Gloas/ePBS + PeerDAS testnet) Affected: All 4 Lodestar nodes (lodestar-nethermind-1/2, lodestar-ethrex-1/2), most other clients on various minority forks Investigator scope: Lodestar nodes only (SSH limited to lodestar-* hosts)

Executive summary

The chain did not stall — it fragmented into 6+ minority forks after a network-wide PeerDAS data column propagation failure caused asymmetric block delivery during low participation. Each client's fork choice algorithm correctly picked the heaviest branch in its local view, but different P2P delivery paths gave different clients different "local views." Lodestar nodes converged on the 22907 fork (head root 0x5792…3034); Prysm-nethermind-1 + bootnode-1 + lighthouse-nethermind-1 converged on a separate fork (head slot 31200+). The chain has had no finalization since epoch 710 (slot 22720) at 14:03 UTC on 2026-05-25.

nflaig

EIP-8061 and the Weak Subjectivity Period: Analysis Notes

Research notes on EIP-8061 ("Increase exit and consolidation churn") and its impact on the weak subjectivity period (WSP). Implemented in consensus-specs#5061, merged into the Gloas fork.

1. What EIP-8061 changes

Three churn knobs replace the single-budget design from Electra/EIP-7514:

nflaig

FFG Checkpoint Root Design — Historical Research Notes

Research notes on why the eth2 FFG checkpoint uses the block at slot 0 of the epoch (with skipped-slot fallback) as opposed to a dependent-root style (block at the last slot of the previous epoch). Compiled 2026-05-12.

The question

In specs/phase0/beacon-chain.md:

nflaig

slot	proposer	graffiti	bid type
4910	2064	nimbus-geth-1	self-build
4914	2032	nimbus-geth-1	self-build
5005	2007	nimbus-geth-1	self-build
5006	1302	teku-geth-2	self-build
5007	1038	teku-geth-1	self-build
5011	2049	nimbus-geth-1	self-build
5030	2068	nimbus-geth-1	self-build
5066	2010	nimbus-geth-1	self-build

nflaig

should_extend_payload scenarios in prepare_execution_payload

Context

prepare_execution_payload (proposer at slot N+1, parent_root = slot N block) calls:

parent_root = hash_tree_root(state.latest_block_header)
if parent_root in store.payloads and should_extend_payload(store, parent_root):
 # FULL path: apply parent payload, compute fresh withdrawals

nflaig

Validators may optionally act as builders to submit execution payload bids for block inclusion. This requires registering with builder-specific withdrawal credentials (BUILDER_WITHDRAWAL_PREFIX).

• fetch execution payload bid via GET /eth/v1/validator/execution_payload_bid/{slot}/{builder_index} from beacon node
• validator signs execution payload bid and submits via POST /eth/v1/beacon/execution_payload_bid to be gossiped
• cache fields required to construct ExecutionPayloadEnvelope (similar to our current --blindedLocal)
• If bid is selected by proposer in their SignedBeaconBlock
  • fetch execution payload envelope via GET /eth/v1/validator/execution_payload_envelope/{slot}/{builder_index} from beacon node
  • validator signs execution payload envelope and submits via POST /eth/v1/beacon/execution_payload_envelope
• must be submitted and propagated on gossip before PAYLOAD_ATTESTATION_DUE_BPS (9 seconds into the slot)

nflaig

This is in response to some previous discussion about this topic in the Free Madeira telegram group.

The Bitcoin value overflow incident in 2010 was a rollback of the chain and I don't see how this is a convoluted way of thinking about it... but let me try to elaborate on that.

So first, does it make a difference that this was a soft fork and not a hard fork?

I don't see any difference, the outcome is exactly the same, but it was more convenient and helped to make the recovery smoother as nodes that still had the bug eventually followed the longest valid chain again. To me this is really just a

nflaig

{
  "attestation_1": {
    "attesting_indices": [
      "20013",
      "20040",
      "20075",
      "20102",
      "20106",
      "20109",
      "20225",

nflaig

participants:
  # Lighthouse
  - el_type: geth
    el_image: ethereum/client-go:stable
    cl_type: lodestar
    cl_image: chainsafe/lodestar:next
    vc_type: lighthouse
    vc_image: sigp/lighthouse:latest
    count: 1
  - el_type: geth

nflaig

participants:
  # Lighthouse
  - el_type: geth
    el_image: ethereum/client-go:stable
    cl_type: lodestar
    cl_image: nflaig/lodestar:ssz-api
    vc_type: lighthouse
    vc_image: sigp/lighthouse:latest
    count: 1
  - el_type: geth