`serde_yaml` is now deprecated. The API-compatible `yaml_serde` should be used instead.
Replace `serde_yaml` with `yaml_serde`. This is purely mechanical as the API is 1-to-1.
Co-Authored-By: Mac L <mjladson@pm.me>
Thread head_payload_status from get_head() return through to
CanonicalHead::new(). In restore_from_store, call get_head() on the
loaded fork choice to get the correct status. Removes Pending defaults.
- Add missing payload attestation slot check: spec returns early when
data.slot != block.slot (PTC votes only for assigned block)
- Remove dead ignored tests (need mock EL Gloas support to run)
- Remove unused new_with_gloas and inspect_queued_payload_attestations
- Remove gloas entries from bin.rs (not part of this PR)
- Collapse nested if in payload attestation error handling (clippy)
- Rename env -> envelope in load_parent
- Add TODO(gloas) for parent_head_hash in re-org path
- Remove head_payload_status from ForkchoiceUpdateParameters (lives on
CachedHead, sourced from get_head return)
head_payload_status is internal fork choice state, not an EL
forkchoiceUpdated parameter. It already lives on CachedHead — source
it directly from get_head() return in recompute_head_at_slot instead
of threading through ForkchoiceUpdateParameters.
Also add TODO(gloas) for parent_head_hash in re-org path (V29 nodes
don't carry execution_status).
With LH v8.1.3 supporting Fulu-on-Gnosis, we no longer need these DB migrations. All Lighthouse nodes running in prod will soon be updated to LH v8.0.0+ and schema v28+.
This PR helps with Gloas fork choice changes, by allowing us to avoid updating old schema migrations when adding V29 for Gloas:
- https://github.com/sigp/lighthouse/pull/9025
Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
- Remove wrong latest_message assertions from payload attestation test
(on_payload_attestation writes to PTC bitfields, not vote tracker)
- Fix corrupted comment: "votes.gloas_enabled() to the genesis block"
→ "votes to the genesis block"
- Fix http_api test fallback string: "n/a" → "irrelevant" to match
production code
- Add issue link to #[ignore] test
- Add comment explaining head_payload_status as u8 cast
- Build parent->children index once per find_head call, replacing O(n)
scans in filter_block_tree and get_node_children with O(1) lookups.
- Skip zero block_hash in is_parent_block_full check — default/zero
hashes don't indicate a real payload relationship.
- Fall back to block state_root for genesis when envelope not stored.
- Store execution payload envelope in EF test harness during
on_execution_payload step.
Remove V17/V29 branching in beacon_chain reorg weight computation.
Use total weight for both pre and post-GLOAS, which is correct for
pre-GLOAS and conservative for post-GLOAS. The payload-aware version
will be needed when reorg logic is enabled for GLOAS.
The children filter already skips invalid nodes, so a valid parent
whose only children are invalid becomes a leaf and gets rejected by
node_is_viable_for_head. The top-level check was redundant.
- Add get_filtered_block_tree/filter_block_tree matching the spec's
recursive viability pre-filter for get_head
- Skip invalid execution status nodes in the filter (they aren't in
store.blocks in the spec)
- Fix attestation_score for V17 nodes: fall back to weight() for
Empty/Full since pre-Gloas has no payload separation
- Include head_payload_status in ForkChoiceView so CachedHead updates
when payload status changes
- Update votes test: branch with incompatible finalized leaf is now
correctly excluded by the recursive filter
- Update execution_status test_03: stored weights no longer include
proposer boost
All 30 proto_array/fork_choice tests pass.
All 9 EF fork_choice test suites pass.
The early exit check in recompute_head_at_slot compared only
head_block_root and checkpoints. When on_execution_payload changed
the payload status from Empty to Full without changing the head root,
the CachedHead was not updated. Add head_payload_status to
ForkChoiceView so the change is detected.
Proposer boost is no longer baked into node.weight() — it is applied
on-the-fly in the walk's get_weight via is_supporting_vote. Update
the expected weights in test_03 to reflect pure attestation scores.
- Compute should_apply_proposer_boost once before the walk instead of
per-child per-level
- Clear previous_proposer_boost in apply_score_changes
- Use correct node root in get_ancestor_node error messages
- Add comment explaining is_supporting_vote slot comparison behavior
- Move proposer boost from apply_score_changes to get_weight, matching
the spec's structure where get_weight adds boost via is_supporting_vote
- Implement is_supporting_vote and get_ancestor_node spec functions
- Fix should_extend_payload: return true when proposer_boost_root is zero
- Compute record_block_timeliness from time_into_slot instead of hardcoding false
- Fix anchor block_timeliness to [true, true] per get_forkchoice_store spec
- Add equivocating_attestation_score for is_head_weak monotonicity
- Use payload-aware weight in is_parent_strong
- Add with_status helper on IndexedForkChoiceNode
- Simplify find_head_walk to return IndexedForkChoiceNode directly
Serves envelope by range and by root requests. Added PayloadEnvelopeStreamer so that we dont need to alter upstream code when we introduce blinded payload envelopes.
Co-Authored-By: Eitan Seri- Levi <eserilev@gmail.com>
Co-Authored-By: Eitan Seri-Levi <eserilev@ucsc.edu>
Co-Authored-By: dapplion <35266934+dapplion@users.noreply.github.com>
Closes:
- https://github.com/sigp/lighthouse/issues/9003
Milhouse `List`s use a map in front of the binary tree to cache updates. Ever since we adopted Milhouse, we've been using `VecMap`, which is essentially `Vec<Option<T>>`. Turns out, when you've got 2M indices and only 2 non-`None` entries (changes), this is inefficient.
Milhouse is generic in the choice of map (`U: UpdateMap`) and has always supported `BTreeMap`, so this PR switches us over to `BTreeMap`. In previous benchmarks (years ago) it had been slower than `VecMap`, but now it is vastly superior.
Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
Our release workflow is pretty inefficient and slow. This PR aims to consolidate and cut down on duplicate tasks.
1) We now run the whole build process both on pushing to the `stable` branch and pushing a version tag.
A quick win is to not fire off separate builds.
~~2) The Docker release workflow could re-use the binaries being built instead of doing its own cross-compilation. ~~
we won't take this on _right now_
Co-Authored-By: antondlr <anton@sigmaprime.io>
Co-Authored-By: Michael Sproul <michaelsproul@users.noreply.github.com>
Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
