讲透 archive 节点：你付的钱究竟买到了什么
各家 RPC 服务商对 “archive” 一词的用法都很随意，而一个真正的 archive 节点与一个被包装成 archive 的 full 节点之间的差别，就是一次查询正常返回、与一次查询直接 404 之间的差别。下面讲清楚 archive 在存储层到底意味着什么，以及它为什么对你要跑的查询至关重要。
full 节点 vs. archive 节点
full 节点会校验每一个区块，并保存当前的状态树（state trie）以及大约最近 128 个区块的历史状态。它能告诉你某个账户此刻的余额，但如果你问它在区块 10,000,000 时的余额，它什么都算不出来 —— 中间那些状态早已被裁剪。archive 节点则保留每一个历史状态根（state root），因此可以直接回答任意历史区块上的状态查询。这种完整性正是它的全部价值所在，也是它全部成本所在。
为什么磁盘账单占了大头
Ethereum 的 archive 状态达数 TB，且持续增长；BNB Smart Chain、Polygon 这类高吞吐链按比例也是如此。archive 节点必须跑在 NVMe 上，因为对数 TB 的 trie 做随机读，其延迟会在机械硬盘上把吞吐彻底拖垮。正是这份 NVMe 占用 —— 而非 CPU、也非带宽 —— 才使得几乎在所有地方，archive 访问的定价都高于普通 RPC。
哪些查询必须用到它
任何带历史区块标签的 eth_call 或 eth_getBalance、对旧交易执行的 trace_block 与 debug_traceTransaction、用于对账的代币余额重建，以及绝大多数分析类回填（backfill），都需要 archive 状态。如果你的产品要计算历史持仓、对平账本，或者重放交易，那么恰恰是在这些最要紧的请求上，full 节点会悄无声息地失败。
如何验证服务商是否真的提供 archive
别信标签 —— 去实测。挑一个合约调用，带上一个几百万区块之前的区块标签去跑，确认你拿到的是结果，而不是 “missing trie node” 或 “state not available” 之类的报错。再对一个旧的交易哈希跑一次 debug_traceTransaction。只要有一项失败，那不管定价页怎么写，你用的都是 full 节点。
常见问题
我是不是永远都需要 archive 节点？
不是。如果你只读当前状态和近期区块，那么 full 节点更便宜、也够用。一旦你要查询历史状态、追踪旧交易，或回填分析数据，你就需要 archive。
archive 数据和索引（indexed）数据是一回事吗？
不是。archive 节点通过 RPC 提供原始的历史状态；索引器（indexer）则在此之上派生出更高层的数据集（随时间变化的余额、代币转账等）。可靠的索引，底层依赖的正是一个 archive 数据源。
相关
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵，简单调用很便宜。
获取 API 密钥