同步卡在最后一块回执上？eth/70 的分页收据列表

以太坊节点同步时，除了区块本体，还要向邻居索取每笔交易的回执（gas 用了多少、日志、状态根等）。这些回执在 P2P 协议里按请求批量传输，而主流客户端对单条 P2P 消息普遍设有一条约 10 MiB 的尺寸红线。矛盾随着区块越装越大而浮现：一个装满交易、日志密集的极端区块，它的整块回执列表可能逼近甚至超过这条线。协议没有“分次给一块的回执”的说法，于是索取方要么拿到超限消息被直接断连，要么同步逻辑卡死在这块上重试，表现为快照同步在某个高度反复失败的顽固现象。EIP-7975 提议把这层尴尬拆掉。

一个比特的解法

改动集中在两条 P2P 消息上。回执消息（0x10）原来的载荷是“请求编号加一组按块分组的回执列表”；eth/70 在两者之间插入一个布尔字段 lastBlockIncomplete。当这个标志为真，意思是“列表里最后一块的回执我给全了前一段，剩下的块内还有，请另发请求继续取”。配套地，索取消息（0x0f）也扩展出表达“从某块的某个位置继续”的能力。这样，任何大小的回执列表都可以被切成不超过消息上限的若干页，而前面整块的部分保持一次性传输，日常同步的开销几乎不变。

依赖链与阅读姿势

提案列明依赖 EIP-7642 与 EIP-7825：前者是 eth/69 引入的请求侧能力公告改造，后者给单笔交易设了 Gas 上限以控制最坏情况。这套关系透露了设计哲学：先用交易上限封住最坏单块回执的膨胀速度，再用分页兜住残余的极端情形，两手一起把同步失败面压平。状态上，EIP-7975 是 Networking 类、Review 阶段（创建于 2025 年 6 月 16 日），属于仍在评审讨论中的网络协议提案，尚未构成任何现网版本节点之间的默认行为；你的节点此刻跑的是 eth/68 或 eth/69 一类子协议，遇到回执超限仍要靠版本升级或配置缓解解决。

排障视角

今天真的撞上“同步到某个高费区块反复掉线”时，值得记录的信息包括：卡住的高度、该块回执字节估算、日志里对端断开前最后一条消息类型；在客户端仓库检索同类问题的 Issue 时，尺寸超限与 eth/70 关键词是好用的组合。这类问题也解释了为什么节点软件更新对同步稳定性是实质性运维项，而不是可选优化。

消息尺寸从哪里来

值得补一句数量级：以太坊一个区块的交易数在费市火热时可达数百上千笔，每笔回执除日志外还有地址、主题、布隆字段等固定开销，粗算下来极端块的回执总量达到数兆字节到十几兆字节并不夸张。同一条 P2P 通道还要承载区块体、状态分片等其他消息，把红线无限抬高会让恶意邻居用一条巨型消息耗尽带宽与内存，因此“限制加分页”组合比“单纯抬高限制”稳健得多。这也是评审里常见折中：限制保留，语义补齐。

断连与降级的日常

在没有分页的年代，节点对超限消息的默认反应是断链重连，用户视角表现为同步进度在某个高度反复倒退、日志里对端频繁消失。运维层面的临时缓解是换用更新版本或调大个别配置项，但根因修复必须落在协议层——这正是 eth/70 分页语义存在的意义：把“整块回执是一次性交付物”这个隐含假设正式废除。

快速问答

问：分页会拖慢同步吗？ 答：只有超限的最后一块才多一次往返，其余保持批量。

问：普通用户要做什么？ 答：无需操作；这是节点间协议层的事。

问：与 light client 有关吗？ 答：不同路径——轻客户端的按区块范围取证是另一套请求格式，eth/70 管的是全节点同步的回执消息。

风险提示：本文仅描述网络协议提案，不构成投资建议；节点软件版本与配置变更请遵循官方发布说明。