种子节点
种子节点是新节点接入网络时的第一个接触点。 它们会返回一份已知活跃对等节点的列表，然后断开连接。 种子节点应运行启用了 PEX reactor 的全节点，并以“爬虫”模式运行， 持续探索网络以验证对等节点的可用性。 种子节点只应返回其所知质量最优的一部分顶级对等节点。新建全节点
一个新节点要连接到网络，需要具备以下内容：- 一份种子节点列表，可通过配置文件或启动参数提供给 CometBFT， 也可以由进程内应用硬编码到软件中
- 一个
ChainID，在 p2p 层也称为Network - 区块链的一个近期区块高度 H，以及对应的哈希 HASH
H 和 HASH 必须通过 CometBFT 之外的方式获取并交叉验证，而且该方式应由用户自行确定——例如通过用户所信任的社会共识。
这种要求通过带外方式和社会共识来验证 H 与 HASH，
是工作量证明与权益证明区块链在安全模型上的本质区别。
具备上述信息后，节点会向一些种子节点查询其所属链的对等节点，
拨号连接这些对等节点，并对成功建立连接的节点运行 CometBFT 协议。
当该对等节点追赶到高度 H 时，它会确认区块哈希是否与 HASH 一致。
如果不一致，CometBFT 将退出，用户必须重试——这意味着他们要么连接到了恶意对等节点，
要么其社会共识本身无效。
重启后的全节点
节点在启动时会检查其地址簿，并尝试连接其中记录的对等节点。 如果在一段时间后仍无法连接到任何对等节点，它会回退到种子节点以发现更多节点。 重启后的全节点可以运行blockchain 或 consensus reactor 协议，
从上次停止的位置继续同步到区块链的最新状态。
在权益证明场景下，如果它们落后过多（超过解绑期的长度），
则需要再次通过带外方式验证一个近期的 H 和 HASH，
以确保自己同步到的是正确的链。
验证者节点
验证者节点是与验证者签名密钥交互的节点。 这类节点对安全性的要求最高，因此不应接受入站连接。 它们应仅维护到一组受控“哨兵节点”的出站连接， 由这些哨兵节点作为代理屏障，代表其与网络其余部分交互。 彼此了解并互相信任的验证者可以互相接受入站连接，并通过 VPN 维持直接的私有连接。哨兵节点
哨兵节点是验证者节点的守卫者，为其提供访问整个网络其余部分的能力。 它们应与网络中的其他全节点保持良好连接。 哨兵节点可以是动态的，但应在彼此之间维护到某个不断演化的随机子集的持久连接。 它们应始终预期会接收来自验证者节点及其备用节点的直接入站连接。 它们不会在 PEX 中报告验证者节点的地址， 并且可能会对所保留对等节点的质量采取更严格的标准。 属于彼此信任的验证者的哨兵节点，可能希望通过 VPN 相互维持持久连接，但在 PEX 中只应有限地通告彼此。A CometBFT P2P network has different kinds of nodes with different requirements for connectivity to one another. This document describes what kind of nodes CometBFT should enable and how they should work.
Seeds
Seeds are the first point of contact for a new node. They return a list of known active peers and then disconnect. Seeds should operate full nodes with the PEX reactor in a “crawler” mode that continuously explores to validate the availability of peers. Seeds should only respond with some top percentile of the best peers it knows about.New Full Node
A new node needs a few things to connect to the network:- a list of seeds, which can be provided to CometBFT via config file or flags, or hardcoded into the software by in-process apps
- a
ChainID, also calledNetworkat the p2p layer - a recent block height, H, and hash, HASH for the blockchain.
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.
This requirement to validate H and HASH out-of-band and via social consensus
is the essential difference in security models between Proof-of-Work and Proof-of-Stake blockchains.
With the above, the node then queries some seeds for peers for its chain,
dials those peers, and runs the CometBFT protocols with those it successfully connects to.
When the peer catches up to height H, it ensures the block hash matches HASH.
If not, CometBFT will exit, and the user must try again - either they are connected
to bad peers or their social consensus is invalid.
Restarted Full Node
A node checks its address book on startup and attempts to connect to peers from there. If it can’t connect to any peers after some time, it falls back to the seeds to find more. Restarted full nodes can run theblockchain or consensus reactor protocols to sync up
to the latest state of the blockchain from wherever they were last.
In a Proof-of-Stake context, if they are sufficiently far behind (greater than the length
of the unbonding period), they will need to validate a recent H and HASH out-of-band again
so they know they have synced the correct chain.