怒省 500GB 硬盘空间!以太坊执行客户端正式支持历史数据过期
从今天开始,所有以太坊执行客户端都已支持按照 EIP-4444 [1] 实现的部分历史数据过期(Partial History Expiry)功能。虽然完整的滚动历史数据过期机制(Rolling History Expiry)仍在开发中,但用户现在已经可以通过删除「合并(Merge)」之前的区块数据,将以太坊节点所需的磁盘空间减少约 300-500 GB,从而使整个节点能够轻松运行在一个 2TB
作者 | Matt Garnett
🔗 原文链接:https://blog.ethereum.org/2025/07/08/partial-history-exp
从今天开始,所有以太坊执行客户端都已支持按照 EIP-4444 [1] 实现的部分历史数据过期(Partial History Expiry)功能。虽然完整的滚动历史数据过期机制(Rolling History Expiry)仍在开发中,但用户现在已经可以通过删除「合并(Merge)」之前的区块数据,将以太坊节点所需的磁盘空间减少约 300-500 GB,从而使整个节点能够轻松运行在一个 2TB 的硬盘上。下文将提供各个客户端的具体信息。
链上历史
区块链的定义是一条从创世点开始的区块链。对于以太坊来说,这个创世点是 2015 年 7 月 30 日 [2]。每个区块都包含有关协议本身的信息,例如当前的 gas 上限、用户交易列表以及由交易回执(receipt)封装的交易结果。这些数据有多种用途:
完全验证(Full validation):需要执行每一个历史区块,以确保不仅当前的状态(head state)是正确的,而且从创世块至今的所有历史状态都是正确的。
构建链上索引,例如:追踪某个账户余额的历史变化,或某个应用状态的演变。
对于那些使用 calldata 发布交易的 Layer 2 网络(L2),需要主链的历史数据来完全验证它们的链,或构建相关索引。
一些与「过去操作的证明(proof-of-past)」相关的应用,例如证明某笔交易确实在某个时间点被发送过。
在极少数情况下,某些 NFT 数据。不过,目前主流的链上 NFT 存储方式是将数据存储在合约的存储中,或引用如 IPFS 这类外部数据源。
这些历史数据通常不会被普通以太坊用户频繁使用,而是面向高级用户或开发者。进行账户余额查询、交易执行、资产借贷等操作不会受到历史数据过期的影响。从创世块以来就未发生变动的账户也不会受到影响,因为每个账户的当前状态仍会被维护。
但需要注意的是,以太坊仅维护当前状态,所以用户在某个特定历史时刻的余额并不容易仅通过当前链上数据推导出来。这类查询需要通过具备专用索引能力的归档节点(archive node)[3] 来完成,才能查出过去某一时刻的账户状态。
权益证明下的区块验证机制
在以太坊最初使用工作量证明(Proof-of-Work, PoW)时,默认的区块验证方式是从创世区块开始进行完整验证。后来,客户端陆续引入了 snap sync 等同步机制,允许客户端基于“最重链规则”直接跳转到链的最新头部,再下载所有合约和账户的当前状态。对于那些认为“最重链规则”不足以验证链完整性的人,仍然可以选择完整同步(Full Sync)。
随着以太坊转向 权益证明(Proof-of-Stake, PoS) 并完成「合并(The Merge)」后,同步策略也随之发生了变化。由于在 PoS 模式下生成签名几乎没有成本,客户端需要锚定一个可信的最新检查点(checkpoint),这被称为 弱主观性检查点(Weak Subjectivity Checkpoint)[4]。这一机制使新用户能够快速接入链网络,同时防止遭受那些早已退出验证者集合的节点发起的长程攻击(long-range attacks)。
「主观性(subjectivity)」的引入进一步减少了用户对每一个历史区块进行完整验证的必要性。因此,在多种原因的推动下,客户端普遍采用了一种新的 反向同步策略(reverse sync),即从链的头部向创世块方向回溯下载历史数据。
如今,大多数客户端并不会完全执行整条链,因此也就没有理由强制所有以太坊节点从 P2P 网络中下载超过 1TB 的历史数据。通过实施历史数据过期机制(history expiry),以太坊转向了一种 1-of-N 的信任假设:只要有一个实体能够提供历史区块数据,节点就可以通过链下方式(out-of-protocol means)检索历史信息,这与其他区块链网络的做法相似。
这种历史数据过期机制的默认安全模型,并没有改变目前以太坊的安全基线。事实上,客户端在过去 五年多的时间里已经不再默认从创世块执行全链验证。执行层仍然会提供所有区块头(header),从而可以通过加密手段验证整条链的有效性。这一机制有助于防止客户端接受到无效的历史数据。
可用性,依然有保障
直到今天,以太坊网络上的每一个节点都会从创世区块开始存储每一个区块。这种做法为历史数据的可用性提供了极高的保障 —— 任何人在任何时间都能下载完整的历史记录。我们相信,在确保高可用性的同时,有可能减少存储完整历史的节点数量。我们通过以下几种分发方式实现这一目标:
机构提供者 —— 愿意在自有服务器上托管历史数据归档的组织或企业;
种子网络(Torrent) —— 开放、自愿、去中心化的归档历史托管方式;
点对点网络(P2P) —— 与以往相同的检索机制,但若部分节点选择不再存储历史数据,整体的可用性可能会有所下降。
有关镜像站和种子文件的列表,请访问由社区维护的文档页面:
👉 https://eth-clients.github.io/history-endpoints/
各客户端的使用命令说明
以下信息是截至发布时的最新内容,但不同客户端的命令和参数可能会更新。最准确的信息请查阅对应客户端的官方文档。
每一个面向完整节点的客户端都支持运行一个不包含合并前数据(pre-merge data)的节点,但具体操作因客户端而异。下面是运行精简节点(pruned node)的各执行客户端指南。
请注意:仅主网(Mainnet)和 Sepolia 测试网具有「非合并链前缀(non-Merge chain prefix)」,因此只有这两个网络支持历史数据修剪。特别是 Sepolia 的非合并部分很小,因此修剪后节省的磁盘空间可能有限。
Go-Ethereum(Geth)
自 v1.16.0 [5] 版本起支持。
完整文档地址:https://geth.ethereum.org/docs/fundamentals/historypruning
对于已有节点:
正常关闭 geth;
执行离线修剪命令:
geth prune-history --datadir=</path/to/data>
重新启动 geth。
对于新节点:
使用参数 -history.chain postmerge 可跳过下载合并前的区块数据。
Nethermind
从 v1.32.2 [6] 起默认启用历史数据过期功能。
历史数据仅在新同步节点上会被移除。未来版本将加入自动修剪功能。
完整文档地址:https://docs.nethermind.io/fundamentals/history-expiry/
如需禁用该功能:
使用以下参数:
-Sync.AncientBodiesBarrier 0 --Sync.AncientReceiptsBarrier 0
Besu
自 v25.7.0 [7] 起支持。
完整文档地址:https://besu.hyperledger.org/public-networks/how-to/pre-merge-history-expiry
对于已有节点:
1. 离线修剪方式:
正常关闭 Besu;
执行修剪命令:
besu --data-path=</path/to/data> storage prune-pre-merge-blocks
使用 -history-expiry-prune 参数启动 Besu;
等待空间被回收(约需 24–48 小时);
移除 -history-expiry-prune 参数,重启 Besu。
2. 在线修剪方式:
启动时添加 -history-expiry-prune 参数即可。
对于新节点:
使用参数:-sync-mode=SNAP
Erigon
自 v3.0.12 [8] 起支持。
适用于新节点与已有节点:
启动客户端时添加参数:-history-expiry
Reth
自 v1.5.0 [9] 起支持。
适用于新节点与已有节点:
主网使用参数:
-prune.bodies.pre-merge --prune.receipts.before 15537394
Sepolia 使用参数:
-prune.bodies.pre-merge --prune.receipts.before 1450409
🔗 相关链接
[1] https://eips.ethereum.org/EIPS/eip-4444
[2] https://etherscan.io/block/0
[3] https://ethereum.org/en/developers/docs/nodes-and-clients/archive-nodes/
[4] https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/
[5] https://github.com/ethereum/go-ethereum/releases/tag/v1.16.0
[6] https://github.com/NethermindEth/nethermind/releases/tag/1.32.2
[7] https://github.com/hyperledger/besu/releases/tag/25.7.0
[8] https://github.com/erigontech/erigon/releases/tag/v3.0.12
[9] https://github.com/paradigmxyz/reth/releases/tag/v1.5.0