如何使用子图访问加密数据

ormilabs 发布于 2026-03-26 阅读 42

本文介绍如何通过子图(Subgraphs)高效访问和查询链上数据。文章首先指出原始区块链数据不易查询(结构为追加式、顺序存储),然后对比了运行节点、使用RPC提供商、数据仓库、第三方API等常见方法的优缺点。重点解析了子图的工作原理:它通过监听智能合约事件、转换数据格式并存入数据库,通过GraphQL接口提供结构化查询。文章还讨论了子图在DEX、NFT市场等场景的广泛应用、其优势(实时性、协议特定数据模型)以及限制(索引延迟、重组织处理、事件依赖性等)。最后介绍了Ormi等托管服务如何优化子图基础设施。

使用子图访问加密数据

如果你曾经尝试从区块链中提取结构化数据,很可能遇到过这种情况。

原始的链上数据并不是为查询而设计的。它只能追加,按顺序存储,并且分散在成千上万个区块中。

要得到一个像“这个代币过去30天的总交易量是多少”这样简单问题的清晰答案,通常意味着你需要运行自己的节点、使用数据仓库,或者将多次 API 调用拼接起来,并自行解码所有数据。

有一种更好的方式可以访问加密数据。子图(Subgraphs)在很大程度上解决了这个问题,但它们也有权衡之处。本指南将介绍它们的工作原理以及为什么它们已成为标准。

加密数据的问题

每个链上操作都记录为交易内部的事件日志,而交易存在于区块中。这种结构对于共识机制很友好,但对于查询来说效率低下。

如果你想回答一些基本问题,比如:

回答这些问题需要从原始日志中重建状态,而不是查询数据库。

在实践中,你通常有以下几种选择:

运行自己的节点

这使你可以完全访问原始的区块链数据,但你需要负责同步、存储以及构建自己的索引层。仅以太坊的归档节点就需要 15 TB 以上 的存储空间。

使用商业 RPC 提供商

像 Alchemy 或 QuickNode 这样的服务可以让你无需管理基础设施即可访问节点。但你仍然在查询原始数据。每次请求都需要进行 ABI 解码、区块迭代以及自定义逻辑,才能将事件日志转换为可用的数据。

购买数据仓库服务

像 Dune 或 Flipside 这样的平台提供了预先索引的区块链数据,并带有 SQL 接口。它们对于分析功能很强大,但大规模使用时成本高昂,并且不适合实时应用数据。

使用加密数据 API

第三方 API 屏蔽了复杂性,但你会被限制在它们的数据模型、速率限制和定价中。对于较新的协议,覆盖范围通常不完整。

每种方法在成本、灵活性、延迟和维护负担之间都有权衡。子图提供了一种不同的平衡方式。

什么是子图(Subgraph)?

子图是位于区块链之上的一个索引数据层。它监听智能合约发出的事件,将数据映射到你定义的架构中,并通过 GraphQL API 暴露出来。

其核心思想借鉴了数据工程。ETL 管道几十年来一直在做类似的事情:提取原始数据,将其转换为结构化数据,并加载到可查询的地方。子图对区块链数据做了同样的事情,不过其复杂之处在于数据源是一个去中心化且不可变的账本,而不是关系型数据库。

实际来说:你无需逐个区块地遍历事件日志来计算用户在 DEX 上的总交换量,而是查询子图,并在毫秒级内得到答案。

为什么子图成为加密数据的标准

Graph 协议在 2020-2021 年左右普及了子图模型,时机恰到好处。DeFi 正在爆发。每个新协议都需要一种方式,将其链上数据展示到仪表盘、分析工具和第三方集成中。为每个协议运行一个完整的归档节点是不可行的。中心化的数据提供商又慢又贵。子图填补了这一空白。

如今,子图支撑着加密分析背后相当大一部分数据层,涵盖了从 DEX 交易仪表盘到 NFT 市场再到借贷协议监控的一切。如果你使用过 Uniswap 的分析页面,那么你实际上就在访问某个子图。

它们成为默认选择的原因如下:

  • GraphQL 接口:开发者已经熟悉 GraphQL。这种查询语言表达能力丰富且自带文档。
  • 开放的架构:子图的架构是公开的,因此你可以精确检查哪些数据可用以及它们是如何组织的。
  • 历史和实时数据:一个索引良好的子图可以通过同一个端点同时提供当前状态和历史查询。
  • 协议特定:每个协议都可以定义与其自身逻辑相匹配的数据模型,这比通用的区块浏览器有用得多。

子图索引的工作方式

理解机制有助于在出现问题时进行排查。而问题迟早会出现。

当你部署一个子图时,需要提供三样东西:

  1. 清单文件(manifest):指定要监控哪些合约、在哪些链上、从哪个区块开始。
  2. 架构(schema):定义数据模型的 GraphQL 类型。
  3. 映射处理函数(mapping handlers):将原始链上事件转换为架构实体的 AssemblyScript 函数。

索引器会监听指定合约发出的事件(如 SwapTransferMint),为每个事件运行相应的处理函数,并将结果写入基于 Postgres 的存储中。查询通过 GraphQL 层访问该存储。

需要理解的关键点是:子图主要索引事件日志,而不是原始存储。虽然映射函数可以通过调用读取合约状态,但大多数子图以事件作为主要数据源。

这是一个重要的限制。某些链上状态变化不容易被观测到。当一个合约触发另一个合约中的函数而没有发出被追踪的事件时,你的数据就会出现缺口。提前了解这一点可以节省大量调试时间。

相关阅读优化子图索引的 4 个最佳实践

使用子图访问加密数据

一旦子图被索引,访问数据就很简单了。你向端点发送一个 GraphQL 查询,然后收到 JSON 格式的响应。

一个从 DEX 子图获取近期交换操作的基本查询可能如下所示:

{
  swaps(
    first: 100,
    orderBy: timestamp,
    orderDirection: desc,
    where: { token0: "0xabc..." }
  ) {
    id
    timestamp
    amount0In
    amount0Out
    amountUSD
    sender
  }
}

这比从 RPC 节点查询原始事件日志要清晰得多。无需 ABI 解码或区块迭代。数据已经被整洁地结构化,可以直接使用。

对于更复杂的分析,包括时间序列聚合、跨实体连接以及带过滤的历史时间窗口,你可以利用 GraphQL 的过滤和分页功能构建更复杂的查询。大多数设计良好的子图都支持 where 过滤器、时间范围查询和嵌套实体解析。

子图与其他加密数据解决方案的比较

方案 最适合的场景 局限性
RPC 节点 原始的、无过滤的访问 需要自定义索引逻辑;复杂查询速度慢
数据仓库 历史分析、研究 大规模使用时成本高;非实时;基于 SQL
第三方 API 快速集成 覆盖范围有限;有速率限制;受限于其架构
子图 实时应用数据、协议特定查询 因基础设施提供商不同而差异很大

对于需要结构化、可查询、实时的区块链数据而又不想构建自定义基础设施的应用来说,子图是一个理想的折中方案。

当你需要与应用程序逻辑相匹配的、针对特定协议的数据模型时,子图尤其强大。

子图的局限性

子图很强大,但本身并非完整的解决方案,与其他数据产品一样:

索引延迟:在网络活动高峰期,子图索引可能落后于链的顶端。如果应用程序要求实时数据用于交易或清算监控,那么在专用基础设施上运行高性能的托管子图至关重要。

重组敏感性:区块链会发生重组。区块会被丢弃或替换。一个没有正确处理重组的子图最终会包含“幽灵”数据,这些数据实际上从未在最终链上真实发生过。

事件依赖:如前所述,子图索引事件。如果所需的智能合约数据没有作为事件发出,你将需要通过合约调用或补充数据源来解决这个限制。

AssemblyScript 学习曲线:子图映射是用 AssemblyScript 编写的,它看起来像 TypeScript,但在内存管理和 BigInt 处理方面有些 quirks。如果你来自纯 TypeScript 背景,可能会遇到一些摩擦。

部署和维护:必须有人负责部署、监控和维护子图。架构变更需要重新索引。映射逻辑中的错误需要重新部署。

对许多团队来说,解决方案是使用像 Ormi 这样的托管子图提供商,由他们处理基础设施、正常运行时间和性能优化。

如何开始使用子图

开始使用子图很简单。但要正确使用则需要更多的思考。

你至少需要定义三个东西:

  • 架构:这是你的数据模型。定义哪些实体存在、它们之间的关系,以及你将来要查询什么。
  • 清单文件:它告诉索引器要监控哪些合约、哪些事件重要,以及从哪个区块开始同步。
  • 映射函数:这些是处理函数,负责将原始链上事件转换为结构化数据。

一旦部署完毕,索引器会完成其余工作。它会回填历史数据,与新块保持同步,并将所有内容写入数据库中,你可以通过 GraphQL 查询。

这是理想情况。

团队通常会卡住的地方不是让子图运行起来,而是让它在生产环境中可用。

  • 架构决策会影响查询速度。
  • 映射逻辑会影响索引性能。
  • 事件设计决定了你能访问哪些数据。

子图决定了区块链数据如何存储和访问。

如果早期就把这部分做对,下游的一切都会更容易。

那么为什么要选择 Ormi?

子图提供了结构,但它们不能保证性能、新鲜度或可靠性。

这部分完全取决于运行它们的基础设施。在实践中,大多数问题都出现在这里。

  • 当链处理交易更快时,索引会落后于链头
  • 随着数据集增长,查询速度会变慢
  • 端点在持续流量下会失败
  • 重组会引入难以调试的不一致性

这些都不是子图本身的问题,而是它所构建的架构和基础设施的问题。

Ormi 就是为了处理这些情况而构建的。

  • 即使在负载下,子图也能与链头保持同步
  • 查询性能随使用规模扩展而保持一致
  • 数据保持准确,即使经历重组
  • 你无需考虑节点、故障转移或扩展问题

目标很简单:你设置好就不用管了。这就是 Ormi 旨在填补的空白。

常见问题解答

子图和区块链 API 有什么区别?

RPC API 暴露原始区块链数据:区块、交易和合约存储。子图是建立在其之上的索引化、结构化层。查询事件模式时使用子图;直接读写时使用 RPC。

子图能提供实时数据吗?

在大多数情况下,它们会在几秒钟内索引新块。实际延迟取决于基础设施、网络条件和子图复杂度。生产系统需要索引器在持续负载下保持接近链头。

如何查询子图?

向子图端点发送一个包含 GraphQL 查询的 POST 请求即可。客户端库可以简化此操作,但并非必需。

如何查询稳定币数据?

稳定币数据可以通过子图或 API 使用索引化的区块链数据来查询。这包括追踪转账、供应变化、铸造和销毁事件以及跨链活动。

子图是免费使用的吗?

Graph 协议按查询付费,而 Ormi 提供免费的开发者计划,供用户进行测试和原型开发。

子图支持哪些链?

这取决于索引提供商。大多数平台覆盖主要的 EVM 链:Ethereum、Arbitrum、Optimism、Polygon 和 Base。对于较新或高吞吐量的链,覆盖范围各不相同。

什么是 Ormi 的 0xGraph?

0xGraph 是 Ormi 的托管子图基础设施。它为索引化的区块链数据提供 GraphQL 接口,同时处理索引可靠性、同步、重组管理和多链覆盖。

  • 原文链接: blog.ormilabs.com/crypto...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论