🤖 新推出：《Quicknode 》AI 烹饪指南 10个经过验证的AI编程教程agents 。
查看食谱 访问历史区块链数据：节点与数据补全 |Quicknode
我们的通讯中包含丰富的免费资源、Quicknode 动态、Web3行业洞察等内容。
CLI、Admin API 、MCP、SDK ，以及支持 75 多个区块链的原生 AI 工具。由开发者打造，专为开发者服务。
涵盖 Python、Ruby 和 JavaScript 的最新代码示例。关于智能合约、NFT 和去中心化应用（dApp）的深入指南。
通过 SOC 2 II 类认证 · ISO 27001
答案 > 了解索引与区块链数据 > 如何访问历史区块链数据 简而言之： 要访问区块链的历史数据，需要使用存档节点（该节点存储了从创世区块开始的每个状态快照），或者使用数据回填工具——该工具可检索并存储过去的区块，将其存入可查询的数据库中。标准的完整节点仅保留最近的 128 个区块的状态数据，并会修剪掉更早的所有数据，因此若在完整节点上查询六个月前的钱包余额，将无法成功。 主要有两种方法：通过归档节点的RPC接口进行特定时间点的状态查询，以及使用流式补全技术来构建全面的历史数据库。
VIDEO
简明解释 区块链会记录所有曾发生的交易，但这并不意味着每条历史数据都能轻易获取。关键区别在于交易数据与状态数据的区别。交易数据（即谁向谁发送了什么、调用了哪些合约、触发了哪些事件的记录）是永久性的，且在每个区块中均可查阅。而状态数据（即任意时刻的余额、存储值和合约状态）则属于另一类story 。
全节点（即大多数 RPC 提供商运行的标准节点）会存储区块和交易的完整历史记录，但仅维护当前状态以及近期状态快照的滚动窗口（通常为Ethereum 上的最后 128 个区块，约 25 分钟）。 它们会修剪较旧的状态数据以节省存储空间。这意味着，全节点可以告诉你第 15,000,000 个区块中发生了哪些交易，但无法告诉你某个钱包在第 15,000,000 个区块时的余额，除非该区块位于最近的保留窗口内。
当您的应用程序向全节点发送包含历史区块号的 RPC 调用（如“eth_getBalance”）时，由于该区块的状态数据已被修剪，节点会返回“缺失 trie 节点”错误。这是开发人员在首次处理历史数据时最常遇到的意外情况。从所有交易都被记录下来的意义上说，区块链“记住”了一切，但要恢复历史中任意时间点的状态，则需要特殊的基础设施。
全节点和存档节点有什么区别？ 要快速理解历史数据访问机制，最有效的方法是比较大多数服务商运行的两种节点类型。全节点会保存区块和交易的完整历史记录，但会修剪旧的状态；而存档节点则会保存每个历史状态快照。如果您只需要近期数据，全节点成本更低且速度更快；但若要查询特定时间点的历史状态，则需要使用存档节点。如需更深入的解析，请参阅我们关于“全节点与存档节点对比”的 指南，以及“什么是区块链节点”的 概述。
能力
全节点
存档节点
州级保留
最近的约128个区块（在Ethereum 上约25分钟）
从最初到最新，每个状态
存储占地面积
大约1TB的Ethereum
12TB或以上Ethereum
历史状态查询
因缺少 trie 节点而报错
返回任意区块高度时的状态
运营成本
较低
显著更高
最适合
当前余额和近期交易记录
审计、税务申报、取证、分析
用于特定时间点查询的归档节点 存档节点通过保留从创世区块开始的所有状态快照来解决状态精简问题。一个Ethereum 存档节点存储的数据量超过 12TB，而全节点仅需约 1TB，因此其运行和维护成本要高得多。但它提供了一项关键功能：能够查询任何账户、合约或存储槽在任意历史区块高度时的精确状态。
这对多种应用场景而言至关重要。财务审计需要重建特定日期的账户余额；税务申报需要确定年末持仓的价值；取证分析需要通过历史状态转换来追踪资金的flow ；智能合约调试则利用历史状态来重现并分析过去的漏洞或攻击行为；DeFi 协议分析则通过查询过去区块高度处的资金池状态，来计算历史 TVL、APY 及其他指标。
运行自己的归档节点会消耗大量资源。初始同步需要数周时间，存储成本高昂，且该节点需要持续维护、客户端更新和监控。大多数团队都是通过基础设施提供商访问归档数据，而不是自行运行节点。在评估提供商时，关键的考虑因素是：归档访问功能是否已包含在您的套餐中，还是作为高级附加功能收费；以及该提供商是否支持您应用程序所需的所有链上的归档数据。
可以查询多早的区块链历史数据？ 借助存档节点，您可以查询任何账户、合约或存储槽的状态，其追溯范围可一直回溯至创世区块。即使在标准的完整节点上，每个区块的交易和事件数据均可获取，但历史余额和合约存储数据只能通过存档节点恢复。当您需要决定是获取特定时间点的状态，还是需要完整的历史活动记录时，这一区别至关重要——我们在“实时区块链数据与历史区块链数据”一节中 探讨了这一权衡。 如果您的查询屡屡失败，通常是因为请求发送到了全节点，因此了解RPC 请求的工作原理 有助于您正确路由这些请求。
历史数据库的流式补录 存档节点可响应特定时间点的状态查询，但许多历史数据用例需要的是另一种方案：一个包含过去区块、交易、事件日志和跟踪记录的完整且可查询的数据库。要构建区块链分析仪表盘、代币转账历史 API 或全面的区块浏览器，就需要将历史区块数据处理并存储在结构化数据库中，而不仅仅是按需查询存档节点。
构建该数据库的传统方法是编写一个脚本，该脚本逐个遍历区块，通过 RPC 获取每个区块的数据，解码交易和日志，并将结果插入到数据库中。这种方法虽然可行，但在大规模处理时速度极其缓慢且稳定性差。 通过顺序 RPC 调用补全Ethereum 的完整历史数据（2000 多万个区块）可能需要数周甚至数月。该脚本必须处理速率限制、连接失败、节点超时、重试以及区块排序等问题。如果脚本在执行中途崩溃，则需要相应的逻辑来从中断处继续处理，同时确保数据中不会出现缺口或重复。
基于推送的回填工具通过处理提供商侧的基础设施复杂性，解决了这些运营难题。 您只需指定区块范围，选择所需的数据集（区块、交易、收据、追踪记录、日志），并可选择应用过滤条件，系统便会将数据推送至目标位置，同时保证数据送达、顺序正确，并在失败时自动重试。历史数据补全完成后，同一数据管道可切换至实时流处理模式，随着新区块的生成，确保您的数据库始终保持最新状态。
历史数据补全需要多长时间？ 数据补全时间取决于区块链、区块范围以及您请求的数据集。一个通过标准 RPC 逐个获取区块的顺序脚本，处理 2000 万个区块可能需要数周甚至数月时间，而且它必须自行处理重试、排序和恢复等操作。托管式推送型数据补全服务可将工作并行化处理，速度最高可达七倍，并在您开始之前显示成本和预计完成时间。 底层RPC 基础设施 的吞吐量是任何自助式方案的主要瓶颈。
历史数据的其他方法 The Graph 及其他索引协议通过子图（subgraphs）为特定的智能合约提供预索引的历史数据。如果有人已经为你需要获取数据的协议（如 Uniswap、Aave 或 Lido）部署了子图，你无需构建自己的数据管道，即可通过其 GraphQL API 查询历史数据。其局限性在于，子图是针对特定合约和特定模式的，因此你只能查询子图作者选择索引的内容。
Dune Analytics、Flipside Crypto 和 Nansen 等第三方数据提供商维护着覆盖主要区块链网络的全面历史数据库，并通过 SQL 接口或 API 提供访问。这些数据虽然便于分析和研究，但会带来对第三方数据时效性、准确性和可用性的依赖。对于需要自主掌控数据管道的生产级应用而言，基于原始区块链数据（通过存档节点或数据回填streams ）进行构建，能够提供更大的控制权和更高的可靠性。
特定区块链的浏览器和 API（如 Etherscan 的 API）为获取历史数据提供了另一种途径，但它们通常对免费套餐实施严格的速率限制，且可能无法提供生产级应用所需的细粒度或完整性。
应该使用哪种方法来访问区块链的历史数据？ 并没有一种放之四海皆准的最佳方法：正确的选择取决于您需要的是特定时间点的状态、可进行全量查询的数据库，还是预聚合的分析数据。下表总结了主要选项。如果您的目标是高效地重复访问，而非一次性查询，请在做出决定前对比RPC 与索引技术 ，并了解什么是区块链索引 ，因为大规模查询区块链数据 比乍看之下要困难得多。
方法
最适合
主要局限性
归档节点 RPC
任意区块的特定时间点状态
不是一个大型数据库
流式回填
构建一个可查询的完整数据库
需要一个存储数据的目标位置
索引协议和子图
特定合同的历史数据
仅限于已收录的内容
第三方数据 API
分析与研究
对供应商的依赖
区块链浏览器 API
快速查询
严格的速率限制和有限的粒度
Quicknode 如何提供历史数据访问功能 Quicknode 所有套餐均包含对存档节点的访问权限，从而无需单独管理或支付存档基础设施的费用。每个Quicknode RPCendpoint 均可处理从创世区块到最新区块的任意区块高度的历史状态查询。Quicknode 的 QRoute 技术会自动将历史状态请求路由至存档节点，将当前状态请求路由至全节点，并通过单一的endpoint URL 提供这两类请求，且无需任何配置。
在构建历史数据库时，Quicknode Streams 提供一键式数据补全模板，可帮助您将 20 多个区块链网络的完整链上历史数据导入数据库。您只需选择区块链、数据集类型（区块、交易、收据、交易轨迹或全能组合）以及目标存储（PostgreSQL、Snowflake、Amazon S3、Azure Storage、webhooks ），Streams 便会推送数据，并保证数据成功送达、区块顺序正确，同时具备内置重试机制。 在开始之前，系统会显示成本和预计完成时间，确保您完全了解情况。数据回填的速度比传统的基于 RPC 的脚本快达七倍，完成后，同一数据流可以继续实时mode ，以保持您的数据库处于最新状态。
延伸阅读
常见问题解答
什么是区块链历史数据？ 区块链历史数据是指过去链上活动的任何记录，包括区块、交易、事件日志、交易轨迹以及特定区块高度下的状态（余额和合约存储）。交易数据在每个节点上都是永久保存的，但历史状态则需要存档节点或存储的补全数据。
为什么在旧区块上调用 eth_getBalance 会失败？ 标准的完整节点会修剪大约最后 128 个区块之前的状态，因此对历史时期的 eth_getBalance 调用会返回“缺失 trie 节点”错误。查询存档节点（该节点保留了每个状态快照）即可解决此错误。
我需要一个归档节点才能访问历史数据吗？ 若要在任意区块高度进行特定时间点的状态查询，您需要获取存档访问权限。如果您仅需历史交易和事件日志，可以从全节点读取这些数据，或通过回填将其存储在您自己的数据库中。
什么是区块链数据回填？ 回填操作会检索过去的一段数据块及其数据集，并将它们加载到数据库或存储目标中。基于推送的回填会处理排序、重试和交付保证，并在追上实时数据后切换为实时流式处理。
Ethereum 归档节点能存储多少数据？ 一个Ethereum 存档节点大约存储12TB或更多的数据，而全节点则约为1TB。额外的存储空间用于保存所有历史状态快照，这也是存档基础设施的运行成本更高的原因。
// Publisher
Quicknode
更新于2026年6月2日
2026年2月3日 — 阅读时间10分钟
