查一个地址在某个历史区块的 ETH 余额，全节点和归档节点的结果完全不同：全节点大概率返回错误，归档节点返回准确数值。关键不在"哪个查得更快"，而在于全节点根本没有保留那些历史状态数据，它只有最近约 128 个区块的状态快照。你要查的余额如果落在更早的区块，全节点没有能力回答，归档节点才有。
全节点为什么查不了旧余额
以太坊的"状态"记录了每个账户的余额、nonce、合约代码和存储。全节点在运行时会验证所有区块和交易，但它只保留最近约 128 个区块的状态，更早的状态会被修剪掉。这是为了控制磁盘占用：全节点需要跟随链头、验证新交易，最近的状态足够应对链重组和日常交互，历史状态对网络运行不是必需品。
所以当你用 eth_getBalance 传入一个几百个区块之前的区块号时，全节点会返回类似 missing trie node 或 historical state not available 的错误。这不是节点故障，而是它本来就没有存那份数据。
理论上，全节点可以通过重新执行从创世块到目标区块的所有交易，把历史状态"算回来"。但这个过程消耗大量 CPU 和时间，对于普通的 RPC 查询来说不现实。你在全节点上调用旧区块的余额查询，得到的不是"算得慢一点的结果"，而是直接失败。
归档节点存了什么，所以能查
归档节点的配置与全节点不同：它保留从创世块开始的每一个历史状态快照，不修剪。每个区块产生后的账户余额、合约存储，归档节点都存着。当你查询某个历史区块的余额时，它直接从磁盘读取对应状态返回，不需要重新执行交易。
代价是存储。以太坊归档节点需要的空间远超全节点。以太坊基金会文档提到，多数客户端的归档需要超过 12TB，Erigon 可以把同样数据压缩到 3TB 以内。Geth 的路径型归档节点在完整平坦状态历史下约需 2TB，若同时保留历史 trie 数据则约 6.5TB。全节点则通常在 1TB 左右。归档节点不是"升级版全节点"，它是为特定用途（区块浏览器、审计、税务核算、安全分析）准备的基础设施，普通用户日常转账、交易完全不需要它。
一个容易踩的坑：归档是启动配置，不是查询参数
不能指望在全节点上通过多传一个参数就"临时变成归档模式"。节点在启动时通过客户端配置决定是否保留历史状态，例如 G eth 的 --gcmode archive 或 Erigon 的状态历史模式。你在 RPC 调用中指定一个旧区块号，节点只能用它已有的数据来响应；没有存的状态，传什么参数都拿不到。
如果你使用的是第三方 RPC 服务商，同样需要确认对方的端点是否由归档节点支持。公共或免费端点通常不是归档节点，对旧区块的状态查询会失败。付费的归档端点会明确标注支持历史状态查询，但保留深度和价格因提供商而异。
实际查询时的判断方法
如果你拿到一个 RPC 端点，不确定它是不是归档节点，用一个已知的旧区块做测试。选一个离当前较远的区块号，调用 eth_getBalance 查一个知名地址在该区块的余额。如果返回具体数值，说明端点是归档节点或至少保留了该区块的状态；如果返回 missing trie node 之类的错误，说明它是全节点或修剪过的节点。不要用 latest 标签去测试，那个任何节点都能回答。
如果你只是查当前余额，全节点就够了，用 latest 区块标签即可。只有当你需要某个过去时间点的余额时，才需要归档节点。这也是为什么区块浏览器能显示任意地址在任意区块的余额——它们背后依赖的是归档数据或经过索引的历史状态，而不是一个普通全节点。
参考资料
- ethereum.org·以太坊归档节点 2026-10-29
- OnFinality·以太坊归档节点与历史RPC：查询过去的余额、日志和状态 2026-10-29
- Chainstack·EVM node returns "Missing trie node" 2026-10-29
- go-ethereum·Archive mode 2026-10-29
- QuickNode·How to access historical blockchain data 2026-10-29
