github.com/aakash4dev/cometbft@v0.38.2/spec/p2p/legacy-docs/node.md (about)

     1  # Peer Discovery
     2  
     3  A CometBFT P2P network has different kinds of nodes with different requirements for connectivity to one another.
     4  This document describes what kind of nodes CometBFT should enable and how they should work.
     5  
     6  ## Seeds
     7  
     8  Seeds are the first point of contact for a new node.
     9  They return a list of known active peers and then disconnect.
    10  
    11  Seeds should operate full nodes with the PEX reactor in a "crawler" mode
    12  that continuously explores to validate the availability of peers.
    13  
    14  Seeds should only respond with some top percentile of the best peers it knows about.
    15  
    16  ## New Full Node
    17  
    18  A new node needs a few things to connect to the network:
    19  
    20  - a list of seeds, which can be provided to CometBFT via config file or flags,
    21    or hardcoded into the software by in-process apps
    22  - a `ChainID`, also called `Network` at the p2p layer
    23  - a recent block height, H, and hash, HASH for the blockchain.
    24  
    25  The values `H` and `HASH` must be received and corroborated by means external to CometBFT, and specific to the user - ie. via the user's trusted social consensus.
    26  This requirement to validate `H` and `HASH` out-of-band and via social consensus
    27  is the essential difference in security models between Proof-of-Work and Proof-of-Stake blockchains.
    28  
    29  With the above, the node then queries some seeds for peers for its chain,
    30  dials those peers, and runs the CometBFT protocols with those it successfully connects to.
    31  
    32  When the peer catches up to height H, it ensures the block hash matches HASH.
    33  If not, CometBFT will exit, and the user must try again - either they are connected
    34  to bad peers or their social consensus is invalid.
    35  
    36  ## Restarted Full Node
    37  
    38  A node checks its address book on startup and attempts to connect to peers from there.
    39  If it can't connect to any peers after some time, it falls back to the seeds to find more.
    40  
    41  Restarted full nodes can run the `blockchain` or `consensus` reactor protocols to sync up
    42  to the latest state of the blockchain from wherever they were last.
    43  In a Proof-of-Stake context, if they are sufficiently far behind (greater than the length
    44  of the unbonding period), they will need to validate a recent `H` and `HASH` out-of-band again
    45  so they know they have synced the correct chain.
    46  
    47  ## Validator Node
    48  
    49  A validator node is a node that interfaces with a validator signing key.
    50  These nodes require the highest security, and should not accept incoming connections.
    51  They should maintain outgoing connections to a controlled set of "Sentry Nodes" that serve
    52  as their proxy shield to the rest of the network.
    53  
    54  Validators that know and trust each other can accept incoming connections from one another and maintain direct private connectivity via VPN.
    55  
    56  ## Sentry Node
    57  
    58  Sentry nodes are guardians of a validator node and provide it access to the rest of the network.
    59  They should be well connected to other full nodes on the network.
    60  Sentry nodes may be dynamic, but should maintain persistent connections to some evolving random subset of each other.
    61  They should always expect to have direct incoming connections from the validator node and its backup(s).
    62  They do not report the validator node's address in the PEX and
    63  they may be more strict about the quality of peers they keep.
    64  
    65  Sentry nodes belonging to validators that trust each other may wish to maintain persistent connections via VPN with one another, but only report each other sparingly in the PEX.