Struct SyncNode

pub struct SyncNode {}

SyncNode is a node that downloads and validates the blockchain. This node implements: - NodeContext - UtreexoNode<SyncNode, Chain>

see node_context and node.rs for more information.

Trait Implementations

impl Clone for SyncNode

fn clone(&self) -> SyncNode

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for SyncNode

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for SyncNode

fn default() -> SyncNode

Returns the “default value” for a type.

impl NodeContext for SyncNode

fn get_required_services(&self) -> ServiceFlags

Get the required services for the SyncNode.

The SyncNode is active during IBD, and therefore requires that peers support:

• NETWORK: the peer is capable of serving the entire blockchain.
• WITNESS: the peer is capable of serving blocks and transactions with witness data.
• UTREEXO_ARCHIVE: the peer is capable of serving inclusion proofs for the entire blockchain.

const REQUEST_TIMEOUT: u64 = 120u64

How long we wait for a peer to respond to our request

const MAX_INFLIGHT_REQUESTS: usize = 100usize

Max number of simultaneous inflight requests we allow

const MAINTENANCE_TICK: Duration

How often we perform the main loop maintenance tasks (checking for timeouts, peers, etc.)

const MAX_OUTGOING_PEERS: usize = 10usize

Max number of simultaneous connections we initiates we are willing to hold

const ASK_FOR_PEERS_INTERVAL: u64 = 3_600u64

We ask for peers every ASK_FOR_PEERS_INTERVAL seconds

const PEER_DB_DUMP_INTERVAL: u64 = 30u64

Save our database of peers every PEER_DB_DUMP_INTERVAL seconds

const TRY_NEW_CONNECTION: u64 = 10u64

Attempt to open a new connection (if needed) every TRY_NEW_CONNECTION seconds

const ASSUME_STALE: u64 = 900u64

If ASSUME_STALE seconds passed since our last tip update, treat it as stale

const IBD_REQUEST_BLOCKS_AGAIN: u64 = 30u64

While on IBD, if we’ve been without blocks for this long, ask for headers again

const FEELER_INTERVAL: u64 = 30u64

Interval at which we open new feeler connections

const ADDRESS_REARRANGE_INTERVAL: u64 = 3_600u64

Interval at which we rearrange our addresses

const BAN_TIME: u64 = 86_400u64

How long we ban a peer for

const BLOCK_CHECK_INTERVAL: u64 = 300u64

How often we check if we haven’t missed a block

const SEND_ADDRESSES_INTERVAL: u64 = 3_600u64

How often we send our addresses to our peers

const CONNECTION_TIMEOUT: u64 = 10u64

How long should we wait for a peer to respond our connection request. This shouldn’t be greater than TRY_NEW_CONNECTION in order to clear timed-out requests at the same pace.

const BLOCKS_PER_GETDATA: usize = 5usize

How many blocks we can ask in the same request

const MAX_CONCURRENT_GETDATA: usize = 10usize

How many concurrent GETDATA packages we can send at the same time

const NEW_CONNECTIONS_BATCH_SIZE: usize = 4usize

How many connections we try at once