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>
15 lines
341 B
Rust
15 lines
341 B
Rust
//! Syncing for lighthouse.
|
|
//!
|
|
//! Stores the various syncing methods for the beacon chain.
|
|
mod backfill_sync;
|
|
pub mod manager;
|
|
mod network_context;
|
|
mod peer_sync_info;
|
|
mod range_sync;
|
|
|
|
pub use manager::{BatchProcessResult, SyncMessage};
|
|
pub use range_sync::ChainId;
|
|
|
|
/// Type of id of rpc requests sent by sync
|
|
pub type RequestId = usize;
|