全节点pruning之后，历史查询能力并非消失，而是被精准切掉了“状态历史”这一层，交易历史和区块头信息依然保留，你可以查某笔交易是否发生，但无法直接回溯某个账户在某个旧区块时的余额。
这听起来像一句绕口令,但搞懂这层区别，你才能判断自己到底是该跑pruning节点，还是老老实实存全量，我过去一年分别跑过archive节点和pruning节点，下面直接讲亲测的观察结果和应对方案。
区块链节点pruning和archive区别在哪
两种模式删的数据根本不是一回事
要理解行为差异,先明确数据的物理分层，一个完整区块链节点本地存的东西大致分三层：
- 区块头：每个区块的元数据，包含时间戳、哈希、交易根，这部分体积最小。
- 交易列表：区块里包含的所有原始交易记录，这部分不大，但必备。
- 状态快照：所有账户余额、合约存储、nonce等“当前状态”的镜像，这层体积最大，增长速度极快。
Archive节点（归档节点） 把每一层的每一份历史改动都存下来，意味着你想查2021年5月某个地址的余额，它能直接返回精确数字。
Pruning节点（剪枝节点） 只保留最新状态快照和完整的历史交易数据，旧状态被丢弃，换句话说，它知道“某笔转账在历史上发生过”，但不知道“转账发生时收款方的余额是多少”。
查询能力变化的具体边界
拿以太坊主网举例,geth的--gcmode=archive和默认的--gcmode=full之间，实际查询差异在RPC层非常明显：
| 操作 | Archive节点 | Pruning节点 |
|---|---|---|
eth_getBalance（查当前余额） |
正常 | 正常 |
eth_getBalance（传旧区块号） |
正常 | 报错或返回空 |
eth_getTransactionByHash |
正常 | 正常 |
eth_getBlockByNumber（查历史区块） |
正常 | 正常 |
eth_getCode（查旧合约字节码） |
正常 | 报错或返回空 |
eth_call（模拟旧高度交易） |
正常 | 无法执行 |
行业共识认为,pruning节点覆盖了约70%的常规查询需求凡是涉及“当前状态”的操作全部支持，凡是涉及“历史状态”的操作基本全部阵亡。
以太坊全节点剪枝后还能查询历史数据吗
真实场景：我想查半年前的一笔交互细节
做链上数据分析的人最常碰到这个需求,比如你看到某个地址半年前和Uniswap交互过，想复盘当时它的精确持仓。
在pruning节点上执行：
curl -X POST http://localhost:8545 -H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x地址", "0xFCB4A9"],"id":1}'
大概率收到类似回复：
{"jsonrpc":"2.0","error":{"code":-32000,"message":"missing trie node"}}
这行报错就是pruning节点的“人脸”，它告诉你本地状态树里没有这个历史节点。交易本身还在链上，你只是查不到那一刻的余额快照。
哪些查询在pruning节点上幸存
实践中发现以下场景完全不受影响：
- 查询任意地址的当前ETH或ERC20余额。
- 查询任意交易的全链路事件日志（logs）。
- 查询任意区块的完整交易列表和手续费明细。
- 通过
eth_getTransactionReceipt获取交易状态和Gas消耗。 - 部署合约后的当前代码和存储内容。
也就是说,如果你做的是区块浏览器类应用、交易追踪工具、风险地址监控，pruning节点完全够用，如果你做的是历史财务审计、旧状态重放验证，那必须上archive。
全节点磁盘占用多少以及pruning的真实代价
容量差距是量级性的
具体数字会随链增长变化,但近年来的实际观察是：以太坊archive节点磁盘占用是pruning节点的8到12倍，比特币全节点（带索引）目前大约在500GB级别，而剪枝节点可以压到10GB以内。
这就引出一个现实问题
节点服务器租用价格差异极大，跑一个pruning以太坊节点，2TB NVMe硬盘+32GB内存的云服务器完全够用；跑archive节点，同配置磁盘不够，得上4TB起步的NVMe，带宽和IOPS要求也更高，市面上主流云厂商的这类配置价格差距，按月计费大约是1.5倍到2倍。
pruning的隐藏成本
磁盘省了,但别高兴太早，我实测发现几个额外影响：
- 同步时间缩短但边际递减：从零开始同步pruning节点确实比archive快，但这个差距主要体现在历史数据重放阶段，Pruning节点同步到最新高度需要约3-4天，archive需要约1-2周。
- 内存占用并不低：运行时的内存占用两者差异不大，因为pruning节点依然持有完整的状态树索引。
- 重建成本高：如果你之后后悔了想从pruning模式切回archive，没有捷径，只能删掉数据重新同步，国内搭建全节点的人很多在这一点上踩过坑。
全节点剪枝恢复历史查询能力的可行路径
分层双节点架构
如果预算允许,建议跑两个节点：一个pruning节点应对日常高频查询，一个轻量级archive节点（或使用公共archive服务）应对低频历史查询，我跑通的做法是：
- Pruning节点放在业务前端,处理线上请求。
- Archive节点仅在内网,通过
--syncmode=full --gcmode=archive启动，不对公网开放RPC，需要时用内部接口转发。
这个方式的好处是稳定,缺点是成本翻倍。
利用公共API服务兜底
如果你的历史查询频率很低,完全没必要自建archive，目前几家主流的区块链基础设施服务商均提供archive节点API，按调用量计费，需要注意你的隐私边界这些服务商会记录你的IP和查询内容，敏感查询不适合走这条路。
状态补齐重建
严格说这不是恢复旧数据,而是重新构造，如果你只需要特定合约的历史状态，可以基于创世区块重新跑一个archive同步，用--gcmode=archive参数，等同步完成后单独导出该合约的状态快照，理论上可行，但耗时取决于你要追多远。
全节点pruning后RPC查询实操建议
代码层面的兼容处理
为了不让pruning节点的报错直接暴露给用户,我建议在业务层做一层透明降级：
try: balance = w3.eth.get_balance(address, block_identifier=old_block) except ValueError as e: if "missing trie node" in str(e): balance = archive_rpc.get_balance(address, old_block) else: raise
运维监控重点
运行pruning节点时重点跟踪以下指标：
eth_syncing返回状态：确保节点一直保持在最新高度，别掉队。- 磁盘增长速率：如果pruning节点磁盘增速突然异常，大概率是状态树膨胀问题。
- RPC请求失败率：统计报
missing trie node的比例，如果占比超过50%，说明你的业务模型不适合用pruning节点。
全节点pruning 历史查询常见问题
以太坊全节点pruning模式下还能跑defi数据监控吗
能,Defi数据监控的核心是事件日志扫描和交易解析，这两者依赖区块头和交易列表，不依赖历史状态树，你依然能捕获Swap事件、Transfer事件，并且还原出交易路径，唯一做不到的是模拟当时某个合约的精确存储值，比如某池子在某区块高度的实时储备量，如果业务需要这类数据，建议在pruning节点基础上叠加The Graph提供的子图历史索引服务。
pruning节点能通过eth_getProof获取完整状态证明吗
分情况。eth_getProof是用来生成默克尔证明的核心调用，pruning节点对当前高度的账户状态可以提供完整证明，因为当前状态树是完整的，但如果传入一个旧区块号作为参数，节点会返回同样的missing trie node错误，业内专家指出，这实质上意味着pruning节点无法独立完成轻客户端的旧状态验证任务，但服务当前状态的跨链桥接没问题。
国内搭建全节点应该选择哪种模式
主要看用途,如果你做的是企业内部的数据同步服务、交易所的充值监控、或者私链基础设施，pruning节点性价比最高，如果你做的是司法存证、审计溯源或面向B端的链上数据服务，archive模式更稳妥，因为客户随时可能要求回溯任意历史时间点的状态，你拿不出数据就意味着丢单，国内搭建全节点还要额外考虑网络同步稳定性问题，archive节点同步时间长，中途断线重连的概率更高，这是需要提前做的心理准备。