以太坊源码解析：区块同步协议的核心实现

核心关键词：以太坊、区块同步、ProtocolManager、StatusMsg、downloader、fetcher、Handshake、NewBlockMsg、白名单区块

引言

区块链之所以称为分布式总账技术，核心在于节点间实时同步区块数据。以太坊使用 go-ethereum 作为主客户端，在大概率部署场景下，节点需要保证本地链视图与网络一致，这就要依赖稳定和可扩展的区块同步协议。本文聚焦protocol 层面：握手、消息路由、广播策略以及同步触发条件，不涉及 P2P 网络拓扑或 libp2p 底层实现。

👉 想要更系统地复盘挖矿、同步和广播的全链路流程？点我直达！

源码目录与分支信息

仓库：ethereum/go-ethereum，commit 257bfff316e4efb8952fbeb67c91f86af579cb0a
关键目录：
- eth/handler.go：入口消息调度
- eth/peer.go ：单连接抽象
- eth/sync.go ：定时同步调度
- downloader/ ：Sync 算法核心
- fetcher/ ：缓存与广播协同

轻节点切换靠 cmd/utils/flags.go 的配置：

if cfg.SyncMode == downloader.LightSync {
    return les.New(...)
}

网络运行框架总览

以太坊的网络层由 ProtocolManager 统一管控，职责涵盖：

新节点握手
区块/交易广播
同步策略决策
消息路由（HandleMessage）

1. 节点连接生命周期

握手（Handshake）

与对端建立 TCP 连接后的第一件事是交换 StatusMsg，结构如下：

type statusData struct {
    ProtocolVersion uint32
    NetworkId       uint64
    TD              *big.Int
    CurrentBlock    common.Hash
    GenesisBlock    common.Hash
}

TD：Total Difficulty，判断“谁的链更长”。
Genesis：防止跨网络误连。

peer.Handshake 采用双 go-routine 发送&接收 + 2s 超时的并行模式，提前建立信任基线。

可信任节点

如果 peers.Len() >= maxPeers 且不是 TrustedPeer，直接 DiscTooManyPeers。
通过节点控制台 admin.addTrustedPeer("enode://...") 白名单即可绕过连接数限制。

请求白名单区块

握手后立刻向新节点索要配置里的 whitelist 区块（高度+哈希一旦不一致立即断连），防止早期分叉污染。

2. 消息处理主循环

ProtocolManager.handleMsg 采用「大 switch」模式，消息码表 1:1 对应功能：

消息码	作用
GetBlockHeadersMsg	请求某区间的 block header
BlockHeadersMsg	回应 header 列表
NewBlockMsg	广播整条新块
NewBlockHashesMsg	广播新区块哈希列表（带宽更轻）
TxMsg	广播交易

提示：
Eth63 在 Eth62 基础上又加了GetNodeDataMsg / GetReceiptsMsg，用于状态健校验。

fetcher 与 downloader 的职责分野

fetcher：只负责处理由 NewBlockHashesMsg 触发的轻度拉取，核心是填充本地缓存。
downloader：处理骨架同步（skeleton sync）、批量回填、状态下载，是复杂 BFS/DFS 算法的实现端。

所以 handleMsg 中先 fetcher.Filter，再 downloader.Deliver——多路复用不打架。

广播：NewBlockMsg vs NewBlockHashesMsg

场景	propagate=true（NewBlockMsg）	propagate=false（NewBlockHashesMsg）
默认广播半径	sqrt(总节点)	所有节点
触发条件	本地挖出 / fetcher即将入库	常规同步完成汇报最新块
网络带宽	大量数据一次放闸	轻量哈希广播

这样设计可在“尽快传播”和“防止洪泛”之间做权衡，减少同步高峰时段的网络抖动。

👉 自己动手做一次广播实验，可视化节点间的全网洪水模式！

同步触发时机

ProtocolManager.Start() 会拉起 syncer goroutine：

新节点加入 newPeerCh，立刻尝试 synchronise()。
定时器 forceSync 每 10s check，与 TD 最大的 BestPeer 拉高度差。

BestPeer 选择逻辑：max(TD) ，“骨架节点”永远是当前难度最高的，确保同步数据“根正苗红”。

一旦 downloader.Synchronise 结束，主动广播 NewBlockHashesMsg 让全网更新本地 head。

peer 与 peerSet：内存中的微账本

peer 对象维护三类“已知数据”：

head, td：最新主链指针
knownBlocks：对方已拥有的 block 哈希集合
knownTxs：对方已拥有的交易哈希集合

Lazy Set：基于 BloomFilter 的衰减集合，防抖动 & 防重广播。

peerSet：线程安全的容器，BestPeer() 每次加读锁遍历取 TD 最大。

FAQ

Q：StatusMsg 只交换一次，后续如何知道对方 TD 更新了？
A：在收到 NewBlockMsg 后，若 trueTD > peer.td 会调用 peer.SetHead 即时刷新。NewBlockHashesMsg 则需先调用 fetcher.Notify 拉取 header 才能更新。
Q：为什么 whitelist 哈希只需 1 个就可以？
A：高度是单调递增的，只要 whitelist 区块之后的分叉检测即会看到 TD 增长异常，单点即可阻止大多数分叉攻击。
Q：fetcher 相比 downloader 来说“轻”在哪里？
A：fetcher 仅对最新_tip做增量化，一次最多拉 1~2 个区块；downloader 做全区间重排，要遍历成百上千的区块。
Q：NewBlockMsg 会触发双重广播吗？
A：不会。peer.knownBlocks 会一直做 Port 过滤，保证一个 peer 不会收到同一区块两次。
Q：最大连接数如何配置比较合理？
A：50~100 是大多数验证者节点的默认值，可用 sysctls 调大；需要 TrustedPeer 名单以防无效连接占用额度。
Q：LightSync 模式下 les 与 eth 目录的协议差别？
A：les 是轻节点协议，只做 header+proof 拉取，协议码定义在 les/peer.go 的 LPP_ 前缀消息；逻辑不能复用 downloader，而是用 les/fetcher。

总结：一张图读懂区块同步协议

节点启动 → 建立 TCP → Handshake → Whitelist Check → MainLoop(handleMsg)
       ↑     ↓
   peerSet.Add  peerSet.BestPeer ←【定时/事件】Syncer↓
       ↑                               ↓
fetcher ←→ NewBlockHashesMsg   ←→ downloader.Synchronise → 后续骨架回填
       ↑                                                        ↓
   本地Head广播 ← NewBlockMsg ← 挖矿区块 / 缓存入库

整条链路中：

ProtocolManager 像操作系统调度器；
peerSet 相当于内存中“路由表”；
NewBlockMsg / NewBlockHashesMsg 解决快速广播与减少重复数据；
TrustedPeer 与 Whitelist 是防御女巫与分叉的第一道闸。

掌握以上 4 个关键点，即可对整个同步协议有端到端的认知。