归档节点与全节点：真正的区别是什么？

简短回答：全节点 vs 归档节点 vs 追踪节点

全节点和归档节点之间的核心区别在于它们保留了多少历史状态。以太坊上的全节点会修剪超过128个区块（约5分钟）的状态数据，仅保留最新的状态树和最近的区块数据。归档节点保留自创世以来的每一次状态变化，允许你查询任何历史区块的状态。追踪节点更进一步，存储每笔交易的执行追踪，支持深度重放和调试。

这种区别对于eth_call、eth_getBalance和eth_getStorageAt等RPC调用至关重要。在全节点上，这些调用仅适用于最新区块或保留窗口内的区块。在归档节点上，你可以指定任何区块号并获取该点的确切状态。例如，使用0x1000000（区块16,777,216）作为区块参数的eth_call调用在全节点上会失败，但在归档节点上会成功。

权衡在于存储和成本。以太坊全节点需要约1 TB的磁盘空间，而归档节点可能需要2-4 TB或更多，具体取决于客户端和修剪设置。这直接转化为更高的硬件和运营成本。对于许多应用，全节点就足够了，但如果需要历史数据，则需要归档访问。

• 全节点：存储最新状态（以太坊上最后128个区块），并能提供当前数据。
• 归档节点：存储所有历史状态变化，支持在任何区块查询。
• 追踪节点：存储执行追踪，支持重放和深度调试。

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000000","data":"0x"}, "0x1000000"],"id":1}'

全节点如何修剪状态：128区块窗口

要理解为什么全节点无法提供历史状态，你需要了解以太坊客户端如何管理状态。以太坊使用Merkle Patricia树来存储账户余额、nonce和合约存储。当处理一个区块时，树会被更新。为了控制磁盘使用，大多数客户端实现了状态修剪：它们删除不再被最新状态引用的树节点。在以太坊上，默认保留最近128个区块的状态，大约5分钟。

这种修剪对共识是安全的，因为网络只需要最新状态来验证新区块。然而，这意味着如果你查询超过128个区块的旧区块，节点无法重建状态，因为树节点已不存在。节点仍然可以提供区块头、交易和收据，但不能提供状态。

其他链有不同的保留策略。例如，Solana的全节点（称为验证者）保留当前epoch的状态，并可以配置保留更多，但它们也会修剪历史状态。Polkadot的全节点默认保留最近256个区块的状态，但可以配置为归档所有状态。原则相同：全节点通过丢弃历史状态来优化磁盘使用。

这就是为什么当你使用由全节点支持的公共RPC端点时，查询历史状态可能会遇到类似"message":"missing trie node"的错误。节点根本没有这些数据。

• 以太坊全节点修剪超过128个区块（约5分钟）的状态。
• Solana验证者默认修剪超过当前epoch的状态。
• Polkadot全节点默认保留256个区块的状态，除非另行配置。

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x1000000"],"id":1}'

归档节点实际存储什么

归档节点存储自创世以来的每一次历史状态变化。这意味着对于每个区块，它保留该区块处理后的完整状态树。这允许你查询任何区块号的状态，而不仅仅是最新的。例如，你可以使用多年前的区块号调用eth_getBalance，并获得当时的准确余额。

存储需求显著更高。根据ethereum.org，归档节点需要2-4 TB的磁盘空间，而全节点约需1 TB。这是因为归档节点存储状态树的多个版本，并且树节点永远不会被删除。

确切大小取决于客户端及其修剪设置。例如，Geth的归档模式存储所有状态，而Erigon的归档模式使用更节省磁盘的数据结构。一些客户端还提供“快照”同步，可以减少初始同步时间，但归档数据仍会随时间增长。

由于更大的磁盘和I/O需求，归档节点的运行成本更高。它们需要更快的磁盘（NVMe SSD）和更多的RAM来处理增加的读写负载。这就是为什么许多开发者选择使用提供归档访问的RPC提供商，而不是自己运行归档节点。

• 归档节点存储每个区块后的完整状态树。
• 磁盘使用：以太坊归档节点需要2-4 TB，并随时间增长。
• 更高的硬件要求：NVMe SSD、更多RAM和更快的CPU。

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getStorageAt","params":["0x6B175474E89094C44Da98b954EedeAC495271d0F", "0x0", "0x1000000"],"id":1}'

追踪节点：历史数据的下一级别

追踪节点通过存储每笔交易的执行追踪，超越了归档状态。这些追踪记录了EVM执行的每一步，包括操作码、gas消耗和状态变化。这启用了强大的调试和分析工具，如debug_traceTransaction和trace_block。

追踪节点被区块浏览器、分析平台和需要理解交易如何执行的开发者使用。例如，你可以重放交易以查看其失败原因，或计算每个内部调用消耗的gas。

存储成本甚至高于归档节点，因为追踪是冗长的。对于以太坊，追踪节点可能需要5-10 TB的磁盘，具体取决于客户端和存储的详细程度。一些提供商将追踪端点作为高级功能提供。

如果你只需要历史状态（余额、存储、调用），归档节点就足够了。如果需要调试交易或分析执行细节，则需要追踪节点。

• 追踪节点存储每笔交易的执行追踪。
• 启用debug_traceTransaction和trace_block等方法。
• 以太坊追踪节点的磁盘使用可能达到5-10 TB。

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"trace_block","params":["0x1000000"],"id":1}'

如何测试你的RPC端点是归档还是全节点

你可以通过向一个非常旧的区块发起简单的eth_call或eth_getBalance请求，轻松确定RPC端点是由归档节点还是全节点支持。如果节点返回结果，则是归档节点；如果返回类似"missing trie node"或"header not found"的错误，则是全节点。

以下是一个curl命令，你可以针对任何以太坊RPC端点运行。将URL替换为你的端点，并选择一个过去的区块号（例如，0x1000000对应区块16,777,216，大约在2021年）。

curl -s https://your-rpc-endpoint -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x1000000"],"id":1}'

如果响应包含带有十六进制值的result字段，则端点具有归档数据。如果包含error字段，则可能是全节点。请注意，一些提供商可能有单独的归档端点，请查阅其文档。

对于其他链，原理类似。例如，在Polkadot上，你可以使用过去的区块哈希查询state_getStorage。在Solana上，你可以使用特定slot查询getAccountInfo，但请注意Solana的归档节点不太常见，通常需要特殊配置。

• 使用旧区块号的eth_getBalance测试归档可用性。
• 成功的结果表示归档数据；错误表示全节点。
• 检查提供商文档以了解归档专用端点。

curl -s https://your-rpc-endpoint -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x1000000"],"id":1}'

何时真正需要归档访问？

大多数应用只需要当前状态。如果你正在构建钱包、DEX前端或简单的分析仪表板，全节点就足够了。只有当你需要历史状态时，才需要归档访问。

归档节点的常见用例包括：

• 历史分析：查询特定过去区块的余额或存储，用于研究或报告。

• 审计与合规：证明某个状态在某个时间点存在。

• 智能合约调试：重放交易或检查状态随时间的变化。

• 构建索引器：为子图或自定义索引器回填需要历史状态的数据。

• 治理与投票：检查过去快照区块的投票权。

如果需要归档访问，你有两个选择：运行自己的归档节点或使用提供归档端点的RPC提供商。运行自己的归档节点可以完全控制，但需要大量硬件和维护。使用提供商更简单，通常更具成本效益，尤其是对于小型团队。

在OnFinality，我们为多个网络提供归档RPC端点，包括以太坊、Polkadot和Solana。你可以查看我们的网络页面了解可用性，以及定价了解成本。

• 对于大多数只需要当前状态的dApp，全节点就足够了。
• 历史查询、审计和调试需要归档访问。
• 考虑使用托管RPC提供商以避免运营负担。

成本与存储权衡：全节点 vs 归档节点

主要权衡是存储和成本。以下是基于以太坊典型需求（截至2026年）的比较表：

这些是粗略估计；实际成本因云提供商、磁盘类型和网络而异。归档节点需要NVMe SSD来处理I/O负载，这增加了成本。托管RPC提供商通常按请求或按月收费，但他们为你处理基础设施。

如果你运行自己的节点，考虑使用像Erigon这样的客户端，它在归档模式下更节省磁盘。根据Erigon文档，与Geth相比，Erigon可以将归档存储减少高达50%。

对于许多团队来说，使用托管RPC提供商比内部运行归档节点更具成本效益，尤其是当你考虑维护、监控和正常运行时间时。查看我们的RPC定价了解透明成本。

• 归档节点需要的磁盘是全节点的2-4倍。
• 托管RPC提供商对于归档访问可能更具成本效益。
• Erigon相比Geth减少了归档存储。

常见陷阱及如何避免

在使用全节点和归档节点时，开发者经常遇到几个陷阱：

• 假设所有RPC端点都是归档：许多公共端点是全节点。在依赖历史查询之前，始终使用旧区块进行测试。

• 在全节点上使用带区块号的eth_call：对于保留窗口之外的区块，这将失败。使用eth_call时使用latest或最近的区块。

• 不考虑状态增长：归档节点随时间增长。规划磁盘扩展或使用处理扩展的提供商。

• 忽略客户端差异：不同客户端有不同的修剪和归档行为。在你使用的特定客户端上测试你的查询。

• 为归档访问过度支付：如果你只需要偶尔的历史查询，考虑使用按请求付费的提供商，而不是专用的归档节点。

为了避免这些陷阱，始终针对你选择的端点测试查询，并了解你使用的节点的保留策略。对于生产应用，考虑使用提供全节点和归档端点的托管RPC服务，以便根据需要切换。

• 在依赖历史查询之前，测试你的RPC端点是否支持归档。
• 了解你的节点或提供商的保留策略。
• 对于偶尔的归档查询，使用按请求付费的定价。

下一步：为你的项目选择合适的节点

要在全节点和归档节点之间做出决定，首先列出你的查询模式。如果只需要当前状态，全节点就足够了。如果需要历史状态，则需要归档访问。如果需要执行追踪，则需要追踪节点。

考虑以下决策清单：

• 你是否查询超过5分钟前的区块状态？如果是，则需要归档。

• 你是否需要调试交易或检查内部调用？如果是，则需要追踪。

• 你是否拥有硬件和专业知识来运行自己的节点？如果没有，请使用托管提供商。

• 你的预算是多少？归档节点更昂贵，但托管RPC可能具有成本效益。

一旦决定，你可以使用我们的区块链节点托管指南等指南设置自己的节点，或使用托管RPC服务。OnFinality为多个网络提供归档和追踪端点；查看我们的网络页面了解详情。

有关访问历史数据的更多信息，请参阅我们的文章访问历史区块链数据。要优化RPC调用，请阅读JSON-RPC批处理最佳实践。

• 使用清单确定你的节点类型。
• 考虑托管RPC的简单性和成本效益。
• 探索OnFinality的归档和追踪端点。