Ethereum协议与geth协同工作机制及初始对等节点发现问题咨询

初始首个对等节点的发现逻辑 #

以太坊客户端启动时的初始节点来源有两个，完全不需要依赖广播，也不会导致架构中心化：

• 内置引导节点列表：geth等主流客户端的代码中默认内置了一批由社区共同维护的引导节点（Bootnode）地址，首次启动无本地缓存时，客户端会主动点对点连接这些引导节点，请求其存储的活跃节点列表。引导节点本身没有任何特殊权限，仅承担节点信息分发的作用，不参与交易验证、区块同步等核心逻辑，所有用户都可以自行修改客户端的引导节点配置、甚至自建引导节点，不存在中心化的服务端依赖。
• 本地节点缓存：只要你之前成功接入过以太坊主网，客户端会将曾经连接过的活跃节点信息存储在本地数据库中，后续启动时会优先尝试连接这些缓存节点，无需每次都访问引导节点。

节点发现为何不会产生广播风暴 #

以太坊采用基于Kademlia DHT改进的节点发现协议（v4/v5），全程没有全网广播逻辑：

• 拿到初始节点信息后，客户端会向这些初始节点点对点发送FIND_NODE请求，查询和自身节点ID距离最近的K个节点信息；拿到返回的新节点列表后，再向这些新节点重复发送FIND_NODE请求，通常迭代3-4轮就能获取到足够多的活跃对等节点，全程所有报文都是点对点发送，不存在广播转发的环节，自然不会导致公网被请求报文淹没。

关于报文TTL的设计说明 #

节点发现使用的UDP报文确实配置了TTL参数，默认值为128，这个设计和TCP报文的TTL作用完全一致：仅用于避免报文在公网路由转发的过程中出现异常环路时无限游荡，由于发现逻辑本身不存在报文转发机制，TTL并不承担防循环的功能，设计完全合理。

低节点发现效率的常见解决方法 #

如果你遇到geth启动5-6分钟仅能发现2-3个节点的问题，大概率是两类网络问题导致：

• 你的网络出口封禁了geth默认的UDP发现端口30303，可以尝试切换网络或者调整端口配置
• 你的节点没有公网IP，无法被其他节点主动发现，可以在启动参数中添加--nat extip:你的公网IP来优化发现效率

内容的提问来源于stack exchange，提问作者Shobhit Tewari