EIP-8379 提议让共识客户端在追块后直接把区块喂给执行客户端，并在引擎 API 里新增一个查询执行层区块头与执行头的接口。本文拆解这份 2026 年 8 月的草稿改了什么、没改什么。

新节点做快照同步时，修复状态要一轮轮追问零散节点数据。EIP-8189 提议把同步协议升到 snap/2：用区块访问清单一次性问全。本文拆解这份 Review 阶段草稿。

新节点同步时，getblockchaininfo 里的 verificationprogress 常常卡在 0.99 附近纹丝不动，甚至偶尔回退。它不是已下载字节的百分比，而是一个基于链上交易总数的估算。本文拆解这个字段的定义、和 blocks 与 headers 两个高度的关系，以及该用哪些字段判断同步到底完没完成。

go-ethereum 的 syncmode 有 snap 与 full 两档，默认值是 snap。快照同步不再逐块重放历史交易，而是向网络索取一段段连续的状态数据，在本地重建默克尔树，只在接近链尖时才回退到逐块执行。本文拆解两种模式的成本结构、快照为什么必须先造一次、以及节点停在快照阶段时的排查顺序。

loadtxoutset 让节点几分钟追到链尖、后台补验历史，被假设的只有源码里那串经评审的 UTXO 集合哈希。本文拆解快照链state与后台验证双线并行机制，划清它与检查点、轻节点的信任边界，并给出剪枝与磁盘规划上的运维要点。

本文解释节点同步的几种方式：全量交易重放（snap/peers）、状态快照同步（snap sync）、检查点同步的原理与代价，以及为什么新节点“追上链”需要时间和磁盘。