feat(beacon): gloas validator duties on the beacon node and the validator client

[MegaRedHand]

Motivation

#639 makes the node follow gloas, but every validator duty is refused from the gloas epoch on (refuse_validator_duties_from_gloas, require_fulu_slot), so neither our beacon node nor ethlambda validator can validate past the fork. This PR implements the gloas validator duties on both sides, per consensus-specs v1.7.0-beta.2 (gloas validator.md, builder.md) and the current beacon-APIs (the produceBlockV4 shape lighthouse v8.3.0-rc.0 implements).

Beacon node

Endpoint	What
POST /eth/v4/validator/blocks/{slot}	produceBlockV4: self-built gloas block (bid with BUILDER_INDEX_SELF_BUILD), include_payload returns gloas BlockContents (block, envelope, cell proofs, blobs) or the bare block; JSON or SSZ
POST /eth/v2/beacon/blocks	also takes a bare SSZ gloas SignedBeaconBlock
GET /eth/v1/validator/execution_payload_envelopes/{slot}/{root}	the cached envelope of a block this node produced
POST /eth/v1/beacon/execution_payload_envelopes	signed envelope, with blobs (Eth-Blob-Data-Included: true) or the cached ones; checks bid match, signature and column KZG proofs, builds every gloas column sidecar, gossips envelope + columns and imports them; waits up to 4 s for the block to be imported
POST /eth/v1/validator/duties/ptc/{epoch}	PTC duties (get_ptc_assignment), crossing upgrade_to_gloas from a fulu head
GET /eth/v1/validator/payload_attestation_data?slot=	payload_present from the envelope's arrival time vs PAYLOAD_DUE_BPS, blob_data_available from the custody columns; 204 when the slot has no block
GET/POST /eth/v1/beacon/pool/payload_attestations	validated with gossip's checks, pooled, gossiped; the GET lists aggregates
duties, attestation_data, pool attestations, aggregates	served at gloas epochs; data.index carries the head's payload status (0 same-slot, else 1 iff FULL)

Under the hood:

• engine: PayloadAttributesV4 (slotNumber, targetGasLimit), engine_forkchoiceUpdatedV4 with attributes, engine_getPayloadV6.
• gloas_block_production.rs: payload inputs per prepare_execution_payload (should_build_on_full, apply_parent_execution_payload), the 5-type request list, gloas attestation packing, payload attestation packing (one bit per PTC seat), block + envelope assembly with a self-check of the envelope against the post-state.
• One SharedPayloadAttestationPool filled by gossip and the API, read by block production.
• The envelope's arrival time is recorded in Store for payload_present.
• DefaultBodyLimit raised to 64 MiB on the two publish routes: a blob-heavy block or envelope (21 blobs) was a 413 at axum's 2 MiB default (found on the devnet).

Validator client

• Deadlines pick the fork's basis points (*_DUE_BPS_GLOAS); loop at gloas: propose (block, then envelope), attest at 25%, aggregate at 50%, PTC at 75%.
• Gloas proposal through produceBlockV4 (SSZ), then signs the self-built envelope under DOMAIN_BEACON_BUILDER with the proposer key and publishes it with its blobs.
• Gloas attestations (committee_index omitted, index passed through) and gloas aggregates.
• PTC duties, payload_attestation_data, DOMAIN_PTC_ATTESTER signing and submission; votes even with no attester duty in the slot.

Decisions and deviations (documented in docs/spec_deviations.md)

• Self-build only: no builder bids (p2p or builder API), no SignedProposerPreferences. The BuilderConfig body is decoded and ignored.
• targetGasLimit is the parent bid's gas limit.
• skip_randao_verification is not honored; an invalid reveal is a 400 up front.
• A pre-gloas head counts as FULL for attestation_data.index (the decided boundary rule).
• payload_present reads the envelope's arrival time, which a restart forgets.
• Still out of scope: sync-committee duties in the validator client (it has none at any fork), remote signing, a slashing-protection DB.

Validation

• Unit and router tests per piece, plus validator_client_tests.rs driving the real validator client against the real router over a socket at a gloas slot: attest + aggregate, PTC duties/data/submission, and a full proposal (with and without a blob) against a fake execution client answering forkchoiceUpdatedV4/getPayloadV6.
• cargo test --profile release-fast --lib: rpc 170, validator 269, engine 26, storage 152, state-transition gloas 87 / block_production 19; clippy -D warnings and fmt clean. Spec fixture suites not run locally.
• Kurtosis devnet on ethlambda-5, fulu genesis, gloas_fork_epoch: 5, 12 nodes x 128 keys: ethlambda CL + VC on 6 nodes (50% of the stake; geth, ethrex 29.0.1, nethermind, besu, reth, erigon), the other half lighthouse v8.3.0-rc.0, teku 26.9.1, nimbus v26.10.0, prysm v7.2.0, lodestar v1.49.0, grandine 3.0.0-rc.0 (Platåberget releases). Image built from this branch merged into tmp/bci-626-63-64-633-636-638-gloas-live.
  • Every node on one head through the fork; finality kept advancing (justified 7, finalized 6 at slot 286, gloas from slot 160).
  • Epochs 4 (last fulu) and 5 (first gloas): all 1536 validators earned source, target and head rewards (/eth/v1/beacon/rewards/attestations).
  • Gloas slots 160 to 286: no missed slot; ethlambda proposed 54 blocks and teku holds the envelope for all 54 (74/74 for the other clients); ethlambda VCs published every envelope and a PTC vote in every slot, none rejected, no VC errors.

Known, not addressed here

• At each epoch boundary the validator client's next-epoch attester-duty lookahead gets a 400 ("epoch is not within one epoch of the head state's"): the node bounds the epoch by its head state rather than the wall clock, and the VC asks at slot 0, before the new epoch's first block. Pre-existing (fulu too); current-epoch duties still arrive in time.
• The fulu POST /eth/v2/beacon/blocks with blobs (feat(beacon): blob-carrying blocks and the operation pool #646) needs the same body-limit raise; the tmp merge carries it.

[github-actions]

🤖 Claude Code Review

Review of PR 662

Scope: The checkout I can see has one uncommitted change, to CLAUDE.md (+3/−32). I reviewed that. If the PR includes other files, I haven't seen them.

Blocking: the edit makes CLAUDE.md wrong.

• The diff deletes the paragraphs that describe gloas validator duties. These cover self-build only, gloas_block_production.rs, rpc/src/beacon/gloas_proposal.rs and ptc.rs, SharedPayloadAttestationPool, PayloadAttributesV4 and get_payload_v6, and the validator client's gloas slot schedule.
• In their place it adds: "The node stays a follower: the validator-client endpoints still refuse a gloas epoch (refuse_validator_duties_from_gloas)."
• That sentence is false for this tree.
  • grep finds no refuse_validator_duties_from_gloas in any .rs file.
  • state_transition/src/beacon/gloas_block_production.rs and payload_attestation_pool.rs exist.
  • crates/validator/src/payload_attestation.rs exists.
  • HEAD is the merge into feat/beacon-gloas-validator-duties.
• The change looks like it came from a stale base, or a merge or rebase that kept the older CLAUDE.md. Either way, it would send future readers and agents toward a refusal guard that no longer exists and hide the modules that do exist.

Suggested fix:

• Drop this CLAUDE.md change, or rebase onto the branch tip and restore the removed paragraphs.
• If the aim is to shorten the doc, keep the facts that aren't obvious from the code:
  • the self-build-only limit;
  • the 4 s envelope-POST wait for its block;
  • the shared PTC pool;
  • the missing slashing-protection record for PTC votes and envelopes.
• Before keeping the old "no slashing-protection record" line, check it against attestation_guard.rs and proposal_guard.rs in crates/validator/src. The old text may already be partly out of date.

No code, consensus-logic or security changes are in what I could review.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

⚠️ Warning: Diff was truncated from 12042 to 10000 lines. Some changes were not reviewed.

Found one material correctness bug; otherwise the PR looks thoughtfully implemented and well-tested for a large consensus/API addition.

• crates/net/rpc/src/beacon/ptc.rs:328 — payload_present uses seen_ms < due_ms. The spec text in your own comments says “before get_payload_due_ms() into the slot”, which usually means at or before the deadline. As written, an envelope seen exactly at the cutoff votes false. Given this feeds PTC voting and therefore fork-choice weight, this is a consensus-relevant off-by-one. Suggest seen_ms <= due_ms unless the spec explicitly requires strict inequality.
• crates/validator/src/lib.rs:340 — serve_slot_duties runs attestation/aggregation first and only then sleeps until the PTC deadline. If attestation or aggregation overruns past PAYLOAD_ATTESTATION_DUE_BPS, the PTC vote is sent late instead of being independently scheduled. That can cause missed or stale PTC votes exactly in the stressed conditions this PR is trying to handle. This is correctness/performance relevant because PTC membership is independent of attester duties. Consider spawning the PTC path concurrently once the slot starts, or computing its deadline relative to slot start rather than “after attestation work finishes”.
• crates/net/rpc/src/beacon/gloas_proposal.rs:313 and crates/net/rpc/src/beacon/gloas_proposal.rs:828 — the cache is keyed only by (slot, block_root) and later trusted for blob/proof recovery when Eth-Blob-Data-Included: false. That is fine if block_root uniquely commits to the bid/blob commitments, but it would be safer to assert the cached envelope matches the posted signed envelope’s bid-relevant fields before reusing cached blobs. Right now cache.get ignores the cached envelope entirely, so a future refactor could accidentally serve mismatched cached side data without tripping this code path.
• crates/net/rpc/src/beacon/gloas_proposal.rs:809-823 — the bid/envelope consistency check only compares builder_index and payload.block_hash. If the protocol requires more of the envelope to be consistent with the block’s signed bid than just those fields, this check is too weak. I suspect later signature/STF paths catch most misuse, but this endpoint is security-sensitive enough that I’d prefer explicit validation of every bid-bound field here, or a comment stating why these two fields are sufficient.
• crates/validator/src/payload_attestation.rs:192 — held + HISTORY_SLOTS > slot can theoretically overflow on very large held. It is harmless in practice for chain slot ranges, but held.saturating_add(HISTORY_SLOTS) > slot is the idiomatic safe form.

Overall, the design choices around earliest-envelope tracking, bounded duty execution, and keeping PTC duties independent from attester duties are solid. If you want, I can turn the two stronger points above into ready-to-post GitHub review comments.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

[github-actions]

🤖 Kimi Code Review

⚠️ Warning: Diff was truncated from 12042 to 10000 lines. Some changes were not reviewed.

I'll review this PR focusing on the critical areas for a consensus client. This is a large change introducing Gloas (EIP-7732) support with payload envelopes, payload timeliness committees (PTC), and self-built block production.

Critical Issues

1. Missing slashing protection for PTC votes and envelopes (Security)

crates/net/rpc/src/beacon/ptc.rs:284-285

// It still keeps no slashing-protection record; PTC votes have an in-memory
// `(validator, slot)` dedup only, and envelopes are unguarded.

This is documented in CLAUDE.md but represents a critical security gap. The PayloadAttestationPool only deduplicates by (validator, slot) in memory (line 75 of payload_attestation_pool.rs), but:

• No persistent slashing protection for PTC votes
• Envelopes have no deduplication at all — a validator can sign multiple envelopes for the same slot, creating slashable offenses

Recommendation: Add persistent slashing protection before mainnet deployment, or at minimum document this as a known limitation with risk assessment.

2. Race condition in envelope seen timestamp (beacon_envelope.rs:565-568)

let seen_ms = held.event_ms.saturating_sub(config.genesis_time_ms());
self.store.insert_beacon_envelope_seen(root, slot, seen_ms);

The comment says "When it arrived, not when it finished verifying" — but event_ms is set when the envelope first arrives at P2P, before validation. A malicious peer could flood late envelopes with forged early timestamps. The event_ms should be from trusted network receipt, not arbitrary P2P message time.

Recommendation: Use a trusted clock source or validate event_ms against local time bounds.

3. gloas_data_column_sidecars recomputes cells instead of verifying proofs (gloas_block_production.rs:296-317)

let per_blob_cells = blobs
    .iter()
    .map(|blob| super::kzg::compute_cells(blob))
    .collect::<Result<Vec<_>>>()?;

The function receives cell_proofs from the execution client but recomputes cells from blobs rather than verifying the provided proofs against commitments. This wastes CPU and ignores the proofs entirely for cell construction. More critically, if the execution client provides invalid proofs, they're passed through unchecked to the sidecars.

Recommendation: Verify the provided cell proofs against the commitments and computed cells, or document why this is safe (the KZG proof verification in gloas_verify_data_column_sidecar_kzg_proofs happens later).

4. PayloadCache uses Mutex without poisoning recovery (gloas_proposal.rs:97-116)

fn insert(&self, slot: Slot, block_root: H256, payload: CachedPayload) {
    let mut entries = self.0.lock().expect("payload cache lock poisoned");
    // ...
}

Multiple .expect("... lock poisoned") calls will panic on poisoned locks. In a consensus client, this is a denial-of-service vector.

Recommendation: Use lock().unwrap_or_else(|e| e.into_inner()) for graceful recovery, or parking_lot::Mutex which doesn't poison.

5. assemble_gloas_block clones entire state unnecessarily (gloas_block_production.rs:462-470)

let mut post = state.clone();
let BeaconState::Gloas(_) = &post else {
    unreachable!("checked above")
};
stf::gloas::process_block(&mut post, &block, config, &CommitteeCache::default())?;

The state is cloned to compute the state root, but process_block mutates post. For large states, this is expensive. The CommitteeCache::default() is also passed — if this triggers committee recomputation on every block, it's a significant performance hit.

Recommendation: Verify that CommitteeCache::default() doesn't recompute committees, or pass a cached one.

Correctness Issues

6. pack_gloas_attestations filter logic may drop valid attestations (gloas_block_production.rs:180-196)

let includable = |attestation: &electra::Attestation| {
    let data = &attestation.data;
    data.index < 2
        && is_attestation_same_slot(state, data)
            .is_ok_and(|same_slot| !same_slot || data.index == 0)
};

The condition !same_slot || data.index == 0 means: if same-slot, index must be 0. But is_attestation_same_slot checks if the attestation is for the block's own slot. For a gloas slot, attestations for the current block should indeed have index == 0 (no payload yet). However, this filter runs before pack_attestations, which may have its own filtering. Ensure no double-filtering drops valid attestations.

7. get_ptc_assignments returns first slot only, not all slots (helpers/gloas.rs:718-740)

assignments.entry(validator_index).or_insert(slot);

Per the comment: "A validator with several seats gets its first slot." But the specification's get_ptc_assignment returns one slot per validator. If a validator has multiple seats in the same slot, this is correct. If they have seats in different slots, this loses information.

Verify: Does the PTC allow one validator in multiple slots per epoch? If yes, this is a bug.

8. post_envelope waits for block with busy-polling (gloas_proposal.rs:1034-1049)

async fn wait_for_block(
    store: &Store,
    root: H256,
    timeout: Duration,
) -> Option<(containers::SignedBeaconBlock, Arc<BeaconState>)> {
    let deadline = Instant::now() + timeout;
    loop {
        if let (Ok(Some(block)), Ok(Some(state))) =
            (store.get_signed_block(&root), store.get_state(&root))
        {
            return Some((block, state));
        }
        if Instant::now() >= deadline {
            return None;
        }
        tokio::time::sleep(BLOCK_POLL_INTERVAL).await;
    }
}

This polls every 50ms for up to 4 seconds. Under load, this wastes CPU. The store should support a notification mechanism (watch/channel) for block arrival.

Recommendation: Add tokio::sync::Notify or similar to the store for block arrival events.

Performance Issues

9. aggregate_payload_attestations does O(n×m) signature aggregation (gloas_block_production.rs:245-280)

for (position, validator) in ptc.iter().enumerate() {
    if let Some(signature) = votes.get(validator) {
        aggregation_bits.set(position, true).ok()?;
        signatures.push(*signature);
    }
}
let seats = signatures.len();
let attestation = PayloadAttestation {
    aggregation_bits,
    data,
    signature: bls::aggregate(&signatures).ok()?,
};

For each distinct PayloadAttestationData, this iterates the entire PTC and looks up in a BTreeMap. With PTC_SIZE potentially large, and many distinct data values, this is O(k × n × log n) where k = distinct data count.

Optimization: Pre-group by validator index, or use a Vec instead of BTreeMap for the small PTC size.

10. SSZ deserialization without size limits (gloas_proposal.rs:622-640, post_envelope)

let (signed, supplied) = if blob_data_included {
    match GloasSignedEnvelopeContents::from_ssz_bytes(body) {

body can be up to MAX_PUBLISH_BODY_BYTES (64 MiB), but from_ssz_bytes may allocate proportionally. No streaming or incremental validation.

Recommendation: Add depth limits and pre-validate sizes before full deserialization.

Rust Best Practices

11. Multiple expect on mutex locks throughout

Pattern seen in:

• gloas_proposal.rs:101, 104, 411, 417, 425, 431, 1042
• pool.rs:pool.lock().expect("...")
• ptc.rs:pool.lock().expect("...")

Use parking_lot::Mutex or handle poisoning gracefully.

12. gloas_block_production.rs test support exposes internals

The test_support module is pub with #[cfg(any(test, feature = "test-utils"))]. This exposes randao_reveal, sign_block, sign_envelope — signing functions that could be misused.

Recommendation: Make these pub(crate) or restrict further.

Minor Issues

13. decode_builder_config SSZ parsing is fragile (gloas_proposal.rs:147-162)

let offset = body
    .get(16..20)
    .map(|bytes| u32::from_le_bytes(bytes.try_into().expect("four bytes")));
return match offset {
    Some(20) => Ok(usize::from(body.len() > 20)),
    _ => Err(ApiError::BadRequest("the body is not a BuilderConfig")),
};

This assumes little-endian 32-bit offset at bytes 16-20, and that offset==20 means empty list. This is correct for SSZ but hardcoded without schema validation.

14. payload_attestation_data uses SystemTime::now() directly (ptc.rs:431-434)

let now_ms = std::time::SystemTime::now()
    .duration_since(std::time::UNIX_EPOCH)
    .map(|elapsed| elapsed.as_millis() as u64)
    .unwrap_or(0);

This should use the store's configured genesis time and slot clock for consistency, not wall clock.

Positive Observations

1. Good test coverage: Extensive tests for gloas block production, PTC duties, envelope publication, and validator client integration.
2. Clear fork versioning: The ForkName checks are explicit and reject unknown forks.
3. Self-build only: Correctly refuses builder bids (BUILDER_INDEX_SELF_BUILD), simplifying security surface.
4. Envelope arrival tracking: The envelope_seen_ms cache correctly tracks earliest arrival for PTC timeliness.
5. State transition validation: assemble_gloas_block runs process_block before signing, catching errors early.

Summary

Priority	Issue	Location
Critical	No slashing protection for PTC/envelopes	CLAUDE.md, ptc.rs
Critical	Race condition in envelope timestamp	beacon_envelope.rs:565
High	Mutex poisoning panics	Multiple files
High	Cell proof verification skipped	gloas_block_production.rs:296
Medium	Busy-polling for block arrival	gloas_proposal.rs:1034
Medium	SystemTime::now() instead of slot clock	ptc.rs:431
Low	O(n×m) aggregation	gloas_block_production.rs:245

The PR is generally well-structured for a major fork addition, but the missing slashing protection and mutex poisoning issues should be addressed before production use.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt