Erigon v3.4 Splashing Saga：为生产稳定性而构建

性能、存储与稳定性

v3.4 为以太坊主网运营者带来的最显著改进是 chaindata 的体积缩小了多达 4 倍，从约 80 GB 降至约 20 GB。这直接提升了链头性能，降低了存储成本，并加快了节点的启动和维护速度。通过全新同步或在现有节点上运行单个 rebase 命令即可实现这一缩减。存储效率因内部数据文件合并方式的重构而进一步提升，优先处理 Domain 而非 History，并将后台维护所需的磁盘空间减半。--persist.receipts 和 --prune.include-commitment-history 等可选的高开销标志对链头性能的影响也已降低。

启动速度更快。索引和修剪不再阻止节点在重启后立即投入使用，Caplin 在链头重启时也不再丢失其历史下载进度——从而缩短了运行频繁维护周期的运营者恢复服务的时间。

v3.4 Splashing Saga 还收回了运营者未曾意识到的磁盘空间损失。在 3.x 周期早期引入的零拷贝 mmap 优化无意中跳过了临时文件清理路径中的 unmap 步骤。在长时间运行的 stage_exec 过程中，已删除但仍被映射的可排序缓冲区累计占用高达 2.8 TB 的幻影磁盘空间，导致报告用量与实际用量之间的差距不断扩大，可能引发无明显原因的磁盘空间不足错误。现在临时文件会在删除前正确取消映射，立即消除这一差距。

关闭现在更加可靠。updateForkChoice 路径中的读事务泄漏（goroutine 在数据库关闭后仍保持打开的 DB 读事务）导致进程在退出时挂起。此外，历史下载阶段使用的是 context.Background() 而非阶段的取消上下文，导致在长时间下载期间对 Ctrl+C 无响应。这两个问题均已解决：关闭过程现在协调有序、干净且更可靠，进程会分别等待 WaitIdle 和 warmup goroutine 最多 5 秒完成。

更多可靠性改进：已修复一个 Pectra 请求哈希验证错误，该错误在主网重新同步时生成了无效的请求根哈希；交易池正确驱逐超过最大 nonce 间隔的陈旧排队交易；调试跟踪 JSON 日志记录器中的逐词堆分配模式已通过零分配内存字编码解决，防止在处理大区块跟踪时出现内存不足情况。

RPC 层：正确性与新方法

对于 RPC 提供者，v3.4 在提供新方法的同时，全面提升了正确性。

debug_traceCallMany 现在能正确地在多区块模拟中应用全局区块和状态覆盖。此前，覆盖会被静默忽略，导致错误的跟踪结果。eth_getBlockReceipts 在高请求率下受到保护，可避免因并发引起的延迟峰值和 OOM。eth_feeHistory 获得了性能优化并支持待定区块。debug_traceCall 修复了状态覆盖与区块覆盖之间的交互问题。eth_blobBaseFee 现在返回正确的值。

v3.4 中的新 RPC 方法：

• trace_rawTransaction：在不向网络广播的情况下跟踪已签名交易
• eth_getStorageValues：单次调用中检索多个账户的多个存储槽
• admin_addTrustedPeer / admin_removeTrustedPeer：无需重启节点即可在运行时添加或移除受信任对等节点
• engine_getBlobsV3：用于 EIP-4844 工具的 blob 数据检索
• 平面跟踪输出格式——为 trace_call 系列方法提供平面跟踪输出支持

运行公共端点的运营者获得了三个新参数来控制资源消耗：区块范围上限（--rpc.blockrange.limit）、日志结果上限（--rpc.logs.maxresults）和并发限制（--rpc.max.concurrency）。这些参数无需单独的反向代理即可实现精确的负载控制。注意，若并发限制设置为零，则采用动态默认值；准入控制不覆盖 WebSocket 请求。

更具弹性的共识层

Caplin（Erigon 内嵌的共识客户端）在 v3.4 中提供了其最重大的可靠性更新——涵盖 blob 保留、验证器可用性、对等节点管理和规范合规性。

Blob 存储现在保持有界。 blob 保留管道中的三个复合错误导致长期运行节点上的 Caplin 存储无限制增长——在介入前，已观察到 Hoodi 部署占用高达 1.6 TB。根本原因：由于分叉选择直接转换到 SleepForSlot，导致 CleanupAndPruning 阶段从未被触及；即便运行了该阶段，修剪范围也偏移自错误的起始槽；并且硬编码的 1,000,000 槽常量用于信标区块索引修剪，而非 blob 侧车修剪（后者使用 128,600 槽），这使得有效窗口过宽，无论何种情况修剪均无法生效。三个问题均已修复。修剪在每个分叉选择周期中正确运行，范围准确，PeerDAS 数据列侧车的保留窗口现在可配置——让运营者能够精确控制 blob 磁盘的长期使用。

验证器不间断连接。 当验证器客户端在 Caplin 尚未同步到链头之前轮询时，验证器认证数据处理程序中的空指针异常问题已解决。修复措施添加了对头状态的访问锁定和空值保护，确保处理程序在同步生命周期的任何时刻都能正确响应。

对等节点质量自动提升。 Caplin 此前错误地惩罚了一类以太坊规范规定应直接忽略的 gossip 消息。随着时间的推移，这通过禁止有效对等节点，悄然降低了对等节点集质量。v3.4 Splashing Saga 使 Caplin 的行为完全与规范对齐，虚假禁止停止，对等节点集质量无需运营者干预即可自动恢复。由从对等节点接收的畸变数据引起的另一个崩溃也已解决。

MCP 服务器：Erigon 作为 AI 原生节点

v3.4 附带了模型上下文协议（MCP）服务器，使 Erigon 成为首个具有原生 AI 工具集成的以太坊执行客户端。MCP 服务器通过结构化接口公开区块、交易、状态、日志和跟踪等节点数据，AI 助手、开发工具和自动化管道可直接查询。

MCP 服务器默认启用，允许用户以自然语言查询 Erigon 节点，作为只读接口。这为节点运行者开启了一系列用例，例如交互式区块链分析、故障排除、节点调试等。

Gnosis 链

Erigon v3.4 还包含两项针对 Gnosis 的改进。Chiado 引导节点已更新以匹配 Lighthouse 内置的 Chiado 配置，在 Chiado 测试网 Fusaka 激活前增加了对 Fulu 共识层组件的支持。一个导致 Gnosis 节点在负载下停滞的活性问题已解决：每次过期时冗余的 ENR 续订调用会向 gossip 层发送重复的日志条目，造成日志栈中的互斥锁竞争，从而在压力下降低吞吐量。ENR 生命周期现在正确触发，日志降级为调试级别，并且高请求率下的日志记录器互斥锁竞争问题已解决。

运营者注意事项

升级前需要采取行动或注意的变更摘要：

需要 Go 1.25。 Erigon v3.4 将 Go 1.25 设为源码构建的最低构建/工具链版本。从源码构建或管理自己 Go 安装的运营者应在部署 v3.4 前升级。

以太坊主网的对等节点发现变更。 discv5 现已成为以太坊主网的默认对等节点发现协议；discv4 默认禁用。对大多数运营者来说这是无缝的。但对于那些具有与 discv4 相关的防火墙规则或静态对等节点配置的运营者，应在升级前检查其网络设置。

新的 RPC 速率限制默认值。 区块范围、日志结果和并发限制现在默认启用并采用保守值。运行当前接受大型区块范围或高日志结果数的公共端点的运营者应在升级前检查这些默认值，以避免破坏现有集成。

历史 eth_getProof 现已稳定。 该功能在 v3.3 中作为实验性功能引入，在 v3.4 中升级为生产就绪。要求不变：节点需使用 --prune.include-commitment-history 同步，且至少有 32 GB 内存。

以太坊主网的 chaindata 缩小 4 倍，可按需使用。 存储缩减适用于以太坊主网，并非自动生效——需要全新同步或运行 rebase 命令（./build/bin/erigon seg step-rebase --datadir=<你的路径> --new-step-size=390625）。其他链上的运营者可以手动应用相同命令以按比例缩减。现有节点无需任何操作即可正常工作。

无需数据迁移。 v3.4 是 v3.3 的直接替换升级。除非你打算利用新存储功能，或希望对历史 eth_getProof 应用最新的数据正确性修复，否则无需重新同步。如需重新同步，请使用 --prune.include-commitment-history。

在此查看完整的发布说明。

宏观视角

Erigon v3.4 明确将生产环境的可靠性放在首位。存储改进真实且立即可见：更小的 chaindata、无幻影磁盘、有界 blob 保留、减半的合并开销。可靠性改进同样具体：干净关闭、无崩溃的验证器启动、正确的对等节点管理以及全面的准确 RPC 结果。

在此基础之上：通过 MCP 服务器向新型 AI 工具开放的节点、五个新的 RPC 方法以及面向公共基础设施的精确资源控制。

对于质押者和验证者而言，这意味着一个在边缘条件下仍能保持稳定且从第一次启动起就能可靠连接的共识层。对于 RPC 提供者而言，这意味着可信的查询结果以及在负载下保护基础设施的控制措施。对于所有运营者而言，这意味着一个占用更少空间、重启更快、在最需要时保持稳定的坚实基础。

• 原文链接： erigon.tech/blog/erigon-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～