Documentation

Default number of bootstrap peers

Minimum number of hot big ledger peers in Genesis mode for trusted state to be signalled to Consensus. This number should be smaller than the targetNumberOfActiveBigLedgerPeers but greater than 1. In Genesis, we may demote a big ledger peer for underperformance, but not promote a replacement immediately to guard against adversaries which may want to slow down our progress.

Inbound governor targets

Principal mode of network operation

Node's peer sharing participation flag

Configuration for FetchDecisionPolicy.

Outbound governor targets Targets may vary depending on whether a node is operating in Genesis mode.

Default peer targets in Praos mode

These targets are established when Genesis mode is enabled in node configuration and when the node is syncing up

Policy which governs how to limit the number of accepted connections.

Configuration for FetchDecisionPolicy. Should be determined by external local node config.

Configurable timeouts

These are configurable for at least the following reasons.

o So that deployment and testing can use different values.

o So that a net running Praos can better cope with streaks of empty slots. (See intersectmbo/ouroboros-network#2245.)

Provides alternate peer selection targets for various syncing modes.

The flag which indicates whether the node runs only initiator or both initiator or responder node.

This data structure has two proposes:

• instruct the diffusion layer if it should listen on incoming connections;
• it is communicated via NodeToNodeVersionData during handshake negotiation. In non-p2p mode we always send InitiatorOnlyDiffusionMode, in p2p mode we send exactly what the diffusion is given. In non-p2p mode every connection outbound port is ephemeral, the remote side cannot connect to it, however in p2p mode the outbound port is actually the port on which the node is listening (if it runs in InitiatorAndResponderDiffusionMode).

Promoted data types.

Adjustable targets for the peer selection mechanism.

These are used by the peer selection governor as targets. They are used by the peer churn governor loop as knobs to adjust, to influence the peer selection governor.

The known, established and active peer targets are targets both from below and from above: the governor will attempt to grow or shrink the sets to hit these targets.

Unlike the other targets, the root peer target is "one sided", it is only a target from below. The governor does not try to shrink the root set to hit it, it simply stops looking for more.

There is also an implicit target that enough local root peers are selected as active. This comes from the configuration for local roots, and is not an independently adjustable target.

Is a peer willing to participate in Peer Sharing? If yes are others allowed to share this peer's address? Information about the node comes from the configuration file, while information about other nodes is received via handshake.

NOTE: This information is only useful if P2P flag is enabled.

Diffusion layer configuration parameter.

The two modes determine which PeerSelectionTargets basis is used by churn and OG. The node's configuration sets this, and diffusion is initiated and remains only in this mode.

This parameter controls the minimum number of active connections with big ledger peers that must be maintained when syncing in Genesis mode such that trusted state can be signalled to Consensus. Exiting syncing / entering deadline mode is predicated on this condition. This should be below targetNumberOfActiveBigLedgerPeers in syncTargets otherwise untrusted state will never be departed. This value is lower than the target, because in Genesis we may demote a big ledger peer for underperformance and not immediately promote one from the warm set in case there are adversaries whom are intentionally trying to slow us down.

Timeout for spsDeactivateTimeout and churn hot to warm demotions.

The maximal timeout on ChainSync (in StMustReply state) is 269s, see maxChainSyncTimeout below.

Timeout for spsCloseConnectionTimeout.

This timeout depends on KeepAlive and TipSample timeouts. KeepAlive keeps agency most of the time, but TipSample can give away its agency for longer periods of time. Here we allow it to get 6 blocks (assuming a new block every 20s).

Number of events tracked by PeerMetrics. This corresponds to one hour of blocks on mainnet.

TODO: issue #3866

The default value for timeWaitTimeout.

Inactivity timeout. It configures how long to wait since the local side demoted remote peer to cold, before closing the connection.

A 20s delay after query result was send back, before we close the connection. After that delay we close the connection.

Amount of time between changes to the salt used to pick peers to gossip about.

Maximum number of peers to respond with in a single request