mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-16 19:32:55 +00:00
9667dc2f03
## Issue Addressed Closes #1891 Closes #1784 ## Proposed Changes Implement checkpoint sync for Lighthouse, enabling it to start from a weak subjectivity checkpoint. ## Additional Info - [x] Return unavailable status for out-of-range blocks requested by peers (#2561) - [x] Implement sync daemon for fetching historical blocks (#2561) - [x] Verify chain hashes (either in `historical_blocks.rs` or the calling module) - [x] Consistency check for initial block + state - [x] Fetch the initial state and block from a beacon node HTTP endpoint - [x] Don't crash fetching beacon states by slot from the API - [x] Background service for state reconstruction, triggered by CLI flag or API call. Considered out of scope for this PR: - Drop the requirement to provide the `--checkpoint-block` (this would require some pretty heavy refactoring of block verification) Co-authored-by: Diva M <divma@protonmail.com>
28 lines
939 B
Rust
28 lines
939 B
Rust
use serde_derive::{Deserialize, Serialize};
|
|
use types::Checkpoint;
|
|
|
|
#[derive(Debug, PartialEq, Eq, Clone, Deserialize, Serialize)]
|
|
pub struct ChainConfig {
|
|
/// Maximum number of slots to skip when importing a consensus message (e.g., block,
|
|
/// attestation, etc).
|
|
///
|
|
/// If `None`, there is no limit.
|
|
pub import_max_skip_slots: Option<u64>,
|
|
/// A user-input `Checkpoint` that must exist in the beacon chain's sync path.
|
|
///
|
|
/// If `None`, there is no weak subjectivity verification.
|
|
pub weak_subjectivity_checkpoint: Option<Checkpoint>,
|
|
/// Determine whether to reconstruct historic states, usually after a checkpoint sync.
|
|
pub reconstruct_historic_states: bool,
|
|
}
|
|
|
|
impl Default for ChainConfig {
|
|
fn default() -> Self {
|
|
Self {
|
|
import_max_skip_slots: None,
|
|
weak_subjectivity_checkpoint: None,
|
|
reconstruct_historic_states: false,
|
|
}
|
|
}
|
|
}
|