mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-17 11:52:42 +00:00
df40700ddd
## Description The `eth2_libp2p` crate was originally named and designed to incorporate a simple libp2p integration into lighthouse. Since its origins the crates purpose has expanded dramatically. It now houses a lot more sophistication that is specific to lighthouse and no longer just a libp2p integration. As of this writing it currently houses the following high-level lighthouse-specific logic: - Lighthouse's implementation of the eth2 RPC protocol and specific encodings/decodings - Integration and handling of ENRs with respect to libp2p and eth2 - Lighthouse's discovery logic, its integration with discv5 and logic about searching and handling peers. - Lighthouse's peer manager - This is a large module handling various aspects of Lighthouse's network, such as peer scoring, handling pings and metadata, connection maintenance and recording, etc. - Lighthouse's peer database - This is a collection of information stored for each individual peer which is specific to lighthouse. We store connection state, sync state, last seen ips and scores etc. The data stored for each peer is designed for various elements of the lighthouse code base such as syncing and the http api. - Gossipsub scoring - This stores a collection of gossipsub 1.1 scoring mechanisms that are continuously analyssed and updated based on the ethereum 2 networks and how Lighthouse performs on these networks. - Lighthouse specific types for managing gossipsub topics, sync status and ENR fields - Lighthouse's network HTTP API metrics - A collection of metrics for lighthouse network monitoring - Lighthouse's custom configuration of all networking protocols, RPC, gossipsub, discovery, identify and libp2p. Therefore it makes sense to rename the crate to be more akin to its current purposes, simply that it manages the majority of Lighthouse's network stack. This PR renames this crate to `lighthouse_network` Co-authored-by: Paul Hauner <paul@paulhauner.com>
88 lines
3.7 KiB
Rust
88 lines
3.7 KiB
Rust
use super::manager::SLOT_IMPORT_TOLERANCE;
|
|
use beacon_chain::{BeaconChain, BeaconChainTypes};
|
|
use lighthouse_network::{SyncInfo, SyncStatus as PeerSyncStatus};
|
|
use std::cmp::Ordering;
|
|
|
|
/// The type of peer relative to our current state.
|
|
pub enum PeerSyncType {
|
|
/// The peer is on our chain and is fully synced with respect to our chain.
|
|
FullySynced,
|
|
/// The peer has a greater knowledge of the chain than us that warrants a full sync.
|
|
Advanced,
|
|
/// A peer is behind in the sync and not useful to us for downloading blocks.
|
|
Behind,
|
|
}
|
|
|
|
impl PeerSyncType {
|
|
pub fn as_sync_status(&self, info: &SyncInfo) -> PeerSyncStatus {
|
|
match self {
|
|
PeerSyncType::FullySynced => PeerSyncStatus::Synced { info: info.clone() },
|
|
PeerSyncType::Behind => PeerSyncStatus::Behind { info: info.clone() },
|
|
PeerSyncType::Advanced => PeerSyncStatus::Advanced { info: info.clone() },
|
|
}
|
|
}
|
|
}
|
|
|
|
pub fn remote_sync_type<T: BeaconChainTypes>(
|
|
local: &SyncInfo,
|
|
remote: &SyncInfo,
|
|
chain: &BeaconChain<T>,
|
|
) -> PeerSyncType {
|
|
// auxiliary variables for clarity: Inclusive boundaries of the range in which we consider a peer's
|
|
// head "near" ours.
|
|
let near_range_start = local.head_slot - SLOT_IMPORT_TOLERANCE as u64;
|
|
let near_range_end = local.head_slot + SLOT_IMPORT_TOLERANCE as u64;
|
|
|
|
match remote.finalized_epoch.cmp(&local.finalized_epoch) {
|
|
Ordering::Less => {
|
|
// The node has a lower finalized epoch, their chain is not useful to us. There are two
|
|
// cases where a node can have a lower finalized epoch:
|
|
//
|
|
// ## The node is on the same chain
|
|
//
|
|
// If a node is on the same chain but has a lower finalized epoch, their head must be
|
|
// lower than ours. Therefore, we have nothing to request from them.
|
|
//
|
|
// ## The node is on a fork
|
|
//
|
|
// If a node is on a fork that has a lower finalized epoch, switching to that fork would
|
|
// cause us to revert a finalized block. This is not permitted, therefore we have no
|
|
// interest in their blocks.
|
|
//
|
|
// We keep these peers to allow them to sync from us.
|
|
PeerSyncType::Behind
|
|
}
|
|
Ordering::Equal => {
|
|
// NOTE: if a peer has our same `finalized_epoch` with a different `finalized_root`
|
|
// they are not considered relevant and won't be propagated to sync.
|
|
// Check if the peer is the peer is inside the tolerance range to be considered synced.
|
|
if remote.head_slot < near_range_start {
|
|
PeerSyncType::Behind
|
|
} else if remote.head_slot > near_range_end
|
|
&& !chain.fork_choice.read().contains_block(&remote.head_root)
|
|
{
|
|
// This peer has a head ahead enough of ours and we have no knowledge of their best
|
|
// block.
|
|
PeerSyncType::Advanced
|
|
} else {
|
|
// This peer is either in the tolerance range, or ahead us with an already rejected
|
|
// block.
|
|
PeerSyncType::FullySynced
|
|
}
|
|
}
|
|
Ordering::Greater => {
|
|
if (local.finalized_epoch + 1 == remote.finalized_epoch
|
|
&& near_range_start <= remote.head_slot
|
|
&& remote.head_slot <= near_range_end)
|
|
|| chain.fork_choice.read().contains_block(&remote.head_root)
|
|
{
|
|
// This peer is near enough to us to be considered synced, or
|
|
// we have already synced up to this peer's head
|
|
PeerSyncType::FullySynced
|
|
} else {
|
|
PeerSyncType::Advanced
|
|
}
|
|
}
|
|
}
|
|
}
|