一个以太坊节点的“全节点”身份，其实是由两个程序拼起来的：共识客户端负责信标链与分叉选择，执行客户端负责跑交易、算状态。长期以来的默认分工是——两者各自从网络里把区块抄一份回来：共识层通过 gossip 与 req/resp 收块，执行层则走 devp2p 自己请求区块头与区块体。EIP-8379 想改掉这层重复：共识客户端按常规同步追到前沿之后，把紧接在执行客户端头部之后的那些区块逐个“喂”下去，直到执行客户端追平。这个模式被称作 top-up sync（补链同步）。这份提案在 2026 年 8 月初创建，目前是草稿状态，没有进入任何已排期的主网升级。
两套客户端各拉一遍块，到底浪费在哪
同一批区块要经过两条独立通道进入同一台机器：共识客户端先从网络收一遍，执行客户端再从 devp2p 拉一遍。对带宽是双份开销，对实现是双份的同步逻辑，对排障则意味着“执行层为什么落后”这个问题要同时看两套下载器。EIP-8379 的目标不是推翻 devp2p——快照同步和内存池交易分发仍然留在 devp2p——而是把“区块体分发”这一件事收敛到单一入口，并为将来淘汰 eth 协议里的 GetBlockHeaders、BlockHeaders、GetBlockBodies、BlockBodies 这几类区块分发消息铺路。
引擎 API 里先加一个“数头”的问题
补链的前提是共识客户端知道该从哪一块开始喂。EIP-8379 在引擎 API 里新增 engine_getSyncStatus：请求没有参数，超时定为 500 毫秒，客户端必须在提案激活起支持它，并通过 engine_exchangeCapabilities 广播这个能力。返回的 SyncStatus 对象里有四个字段：headBlockHash 与 headBlockNumber 描述“区块链的头”，也就是从执行头（若无执行头则从创世块）出发、沿着最新一次 engine_forkchoiceUpdated 选定的规范链能连续拿到的最新区块；executedBlockHash 与 executedBlockNumber 描述“已执行链的头”，即执行客户端已经验证过、并且持有其后状态的最新规范块——换句话说，这是它“有能力执行的下一个块”的前一块，两者允许为空。一个刚初始化、还没做过任何状态同步的客户端，报告的就是创世块。当执行客户端收了块但还没执行完（比如靠快照方式快进状态）时，这两个头天然不同，而提案的编排逻辑正是利用这个差值。
把“为什么执行不了”拆成两种答案
过去 engine_newPayload 回一个 SYNCING，共识客户端其实分不清对方是缺这个块之前的状态，还是缺更早的区块历史——两种情况的补救动作完全不同。EIP-8379 收紧了载荷状态的语义：对父块正好是自己区块头的调用，执行客户端必须回 VALID、INVALID 或 MISSING_STATE 之一，缺前状态从此与缺历史可区分。有了明确的头部查询加明确的失败原因，共识客户端就能确定性地编排补块节奏，而不是靠重试碰运气。
快速问答
问：这等于用共识层通道替代快照同步吗？ 答：不是。快照式状态下载和内存池仍走 devp2p，被接管的只是区块体分发这一环。
问：现在能用吗？ 答：这是草稿状态的提案，未激活、未进主网，具体接口以提案仓库的最新文本为准。
问：对普通运行节点的人有什么用？ 答：如果落地，同步循环的因果会更清楚——落后时少一些无方向的重试，排障时也少猜一层“另一套下载器在干嘛”。
边界在哪
把区块供给交给共识客户端，等于让执行层在同步期更依赖对端的编排质量：喂错、喂漏都会直接体现在同步速度上，这是分工收敛必然带来的耦合。另外，“区块头”和“执行头”两个概念的区分此前散落在各家实现内部，这份提案的价值之一是把它们抬进正式的 API 契约里，谁实现都不能再含糊。
风险提示：本文是对公开提案文本的解读，不构成投资建议；提案内容可能随社区讨论修改或作废，请以提案仓库页面为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。