- Fix leaf detection in heads_descended_from_finalization (parent()
method call, map away enumerate index)
- Clear best_child and best_descendant in v28->v29 migration (no
longer used, replaced by virtual tree walk)
- Migration now rewrites fork choice data instead of being a no-op
`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>
- 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)
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>
- 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.
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
There are certain crates which we re-export within `types` which creates a fragmented DevEx, where there are various ways to import the same crates.
```rust
// consensus/types/src/lib.rs
pub use bls::{
AggregatePublicKey, AggregateSignature, Error as BlsError, Keypair, PUBLIC_KEY_BYTES_LEN,
PublicKey, PublicKeyBytes, SIGNATURE_BYTES_LEN, SecretKey, Signature, SignatureBytes,
get_withdrawal_credentials,
};
pub use context_deserialize::{ContextDeserialize, context_deserialize};
pub use fixed_bytes::FixedBytesExtended;
pub use milhouse::{self, List, Vector};
pub use ssz_types::{BitList, BitVector, FixedVector, VariableList, typenum, typenum::Unsigned};
pub use superstruct::superstruct;
```
This PR removes these re-exports and makes it explicit that these types are imported from a non-`consensus/types` crate.
Co-Authored-By: Mac L <mjladson@pm.me>
Part of a fork-choice tech debt clean-up https://github.com/sigp/lighthouse/issues/8325https://github.com/sigp/lighthouse/issues/7089 (non-finalized checkpoint sync) changes the meaning of the checkpoints inside fork-choice. It turns out that we persist the justified and finalized checkpoints **twice** in fork-choice
1. Inside the fork-choice store
2. Inside the proto-array
There's no reason for 2. except for making the function signature of some methods smallers. It's not consistent with the rest of the crate, because in some functions we pass the external variable of time (current_slot) via args, but then read the finalized checkpoint from the internal state. Passing both variables as args makes fork-choice easier to reason about at the cost of a few extra lines.
Remove the unnecessary state (`justified_checkpoint`, `finalized_checkpoint`) inside `ProtoArray`, to make it easier to reason about.
Co-Authored-By: dapplion <35266934+dapplion@users.noreply.github.com>
Co-Authored-By: Michael Sproul <michaelsproul@users.noreply.github.com>
Follow-up to the bug fixed in:
- https://github.com/sigp/lighthouse/pull/8121
This fixes the root cause of that bug, which was introduced by me in:
- https://github.com/sigp/lighthouse/pull/8101
Lion identified the issue here:
- https://github.com/sigp/lighthouse/pull/8101#discussion_r2382710356
In the methods that compute the proposer shuffling decision root, ensure we don't use lookahead for the Fulu fork epoch itself. This is accomplished by checking if Fulu is enabled at `epoch - 1`, i.e. if `epoch > fulu_fork_epoch`.
I haven't updated the methods that _compute_ shufflings to use these new corrected bounds (e.g. `BeaconState::compute_proposer_indices`), although we could make this change in future. The `get_beacon_proposer_indices` method already gracefully handles the Fulu boundary case by using the `proposer_lookahead` field (if initialised).
Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
As identified by a researcher during the Fusaka security competition, we were computing the proposer index incorrectly in some places by computing without lookahead.
- [x] Add "low level" checks to computation functions in `consensus/types` to ensure they error cleanly
- [x] Re-work the determination of proposer shuffling decision roots, which are now fork aware.
- [x] Re-work and simplify the beacon proposer cache to be fork-aware.
- [x] Optimise `with_proposer_cache` to use `OnceCell`.
- [x] All tests passing.
- [x] Resolve all remaining `FIXME(sproul)`s.
- [x] Unit tests for `ProtoBlock::proposer_shuffling_root_for_child_block`.
- [x] End-to-end regression test.
- [x] Test on pre-Fulu network.
- [x] Test on post-Fulu network.
Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
