- 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
- 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
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.
- 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>
https://github.com/sigp/lighthouse/issues/8012
Replace all instances of `VariableList::from` and `FixedVector::from` to their `try_from` variants.
While I tried to use proper error handling in most cases, there were certain situations where adding an `expect` for situations where `try_from` can trivially never fail avoided adding a lot of extra complexity.
Co-Authored-By: Mac L <mjladson@pm.me>
Co-Authored-By: Michael Sproul <michaelsproul@users.noreply.github.com>
Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
#7815
- removes all existing spans, so some span fields that appear in logs like `service_name` may be lost.
- instruments a few key code paths in the beacon node, starting from **root spans** named below:
* Gossip block and blobs
* `process_gossip_data_column_sidecar`
* `process_gossip_blob`
* `process_gossip_block`
* Rpc block and blobs
* `process_rpc_block`
* `process_rpc_blobs`
* `process_rpc_custody_columns`
* Rpc blocks (range and backfill)
* `process_chain_segment`
* `PendingComponents` lifecycle
* `pending_components`
To test locally:
* Run Grafana and Tempo with https://github.com/sigp/lighthouse-metrics/pull/57
* Run Lighthouse BN with `--telemetry-collector-url http://localhost:4317`
Some captured traces can be found here: https://hackmd.io/@jimmygchen/r1sLOxPPeg
Removing the old spans seem to have reduced the memory usage quite a lot - i think we were using them on long running tasks and too excessively:
<img width="910" height="495" alt="image" src="https://github.com/user-attachments/assets/5208bbe4-53b2-4ead-bc71-0b782c788669" />
#6970
This allows for us to receive `SingleAttestation` over gossip and process it without converting. There is still a conversion to `Attestation` as a final step in the attestation verification process, but by then the `SingleAttestation` is fully verified.
I've also fully removed the `submitPoolAttestationsV1` endpoint as its been deprecated
I've also pre-emptively deprecated supporting `Attestation` in `submitPoolAttestationsV2` endpoint. See here for more info: https://github.com/ethereum/beacon-APIs/pull/531
I tried to the minimize the diff here by only making the "required" changes. There are some unnecessary complexities with the way we manage the different attestation verification wrapper types. We could probably consolidate this to one wrapper type and refactor this even further. We could leave that to a separate PR if we feel like cleaning things up in the future.
Note that I've also updated the test harness to always submit `SingleAttestation` regardless of fork variant. I don't see a problem in that approach and it allows us to delete more code :)
