为什么区块链数据基础设施不会统一到单一技术栈

区块链数据领域的难题从来不是数据量。每年数据量都在增长，更快的链也在不断堆积，但原始增长只是这个故事里平淡的一半。真正影响你如何构建系统的另一半却很少被提及：每个人都在读取同一条链，但几乎没人想要同样的数据切片。

一家交易公司、一个稳定币发行方、一个 DeFi 协议、一个钱包、一个游戏工作室、一个风控部门，它们都从相同的区块中拉取数据，却向这些数据提出完全不同的问题。没人想要相同的数据模型、延迟或控制程度。

因此，区块链数据不会收敛到单一的架构上。它会像传统基础设施那样碎片化：大多数公司从云服务商那里租用，技术实力强的公司自建运维，少数公司则付费托管（colo），因为几毫秒的延迟或监管要求让这笔成本变得合理。没有一种设置是普遍正确的；正确的设置取决于具体工作负载。

链上数据正朝着同样的方向发展。一个团队可能会构建自定义索引器、使用原始数据流、依赖通用 API，或者将所有数据存入数据仓库进行分析，而大多数严肃产品会同时采用其中几种方式。Subgraph 能够在所有这些方案中立足，是因为它解决了几乎每个链上应用都会遇到的问题：合约发出活动，而应用需要将这些活动转化为可查询的状态。

数据越多，索引越难，而非越易

索引所有内容已经很昂贵了。一个完整的归档以太坊节点目前需要高达 18+TB（geth），而一旦加上解码的事件、代币转账、追踪、标签以及在其上构建的衍生表，一个浏览器级别的分析数据库可能需要数倍于此。更快的链和更密集的用法只会让这个数字继续攀升。账单规模随链的速度、运行在其上的合约数量以及每个应用希望从这些合约产出中获取自己那份数据的需求而增长。

大多数应用并不需要整个链，只需要与其产品相关的切片。

• 一个永续合约交易所关注的是仓位、抵押品、资金费、结算和成交。
• 一个借贷协议关注的是市场、借入、偿还、清算和账户健康度。
• 一个稳定币发行方需要追踪铸币、销毁、转账、供应量和跨链流动。

这些数据都不是开箱即用的。它们是应用特定的数据模型，需要有人去构建它们。

原始链数据并非应用状态

链是为执行、共识和验证而构建的。一个区块包含交易；交易提供日志、收据、调用和状态变更，但这些数据虽然完整，却几乎无法直接使用。

应用想知道的东西更加实际：

• 这个用户的当前仓位，
• 资金池的深度，
• 哪些账户即将被清算，
• 以及上次合约升级后的变化。

所有这些答案都需要解读。有人必须决定哪些合约和事件是重要的，这些事件如何改变状态，以及结果如何被后续查询。这项工作就是索引，而对于大多数智能合约应用来说，subgraph 是实现这一目标最实用的方式。

Subgraph 实际上提供了什么

一个 subgraph 包含应用关心的内容：要监控的合约、要处理的事件、每个事件如何更新模型，以及结果如何通过 GraphQL 对外提供。对于一个 DEX 来说，这些内容就是资金池、交易、流动性头寸、刻度以及每小时交易量。一个借贷市场需要抵押品、借入、清算和仓位；一个稳定币则需要铸币、销毁、持有者和供应量。

其目的从来不是索引一切，而是精确定义要索引什么，然后随着应用的发展不断重新定义：新合约上线、新市场启动、旧合约升级、添加另一条链、仪表盘需要增加一个视图。你编辑清单，添加合约，调整处理器，扩展模式，然后重新索引。

这并非没有代价。模式变更可能强制重新索引；许多合约发出的数据不足以重构你需要的一切，映射逻辑出错则会产生垃圾结果。但相比之下，如果你自己构建数据摄取、解码、重组处理、回填、存储、监控和查询服务，subgraph 这条路径要轻量得多。

为什么流和 API 不够用

当你需要将原始数据直接输入自己的管道时，流是很好的选择：区块、日志、追踪和解码的事件，按到达顺序交付。但传输字节与维护状态不是一回事。你仍然需要转换、存储、对账、处理重组、回填、暴露查询，并保持下游所有内容的一致性。

通用 API 解决的问题范围较窄：常见的读取操作，如余额、转账、代币元数据、价格、NFT 和钱包历史。它们速度快，而且在你需要与合约绑定的协议特定状态或业务逻辑之前，它们一直工作得很好。但一旦需要这些，API 终结点背后的固定模式就会失效。自定义索引能给你完全的控制权，但也需要你拥有整个管道。Subgraph 则位于两者之间，比 API 更灵活，又比构建自己的索引器轻量得多。这个中间地带正是 subgraph 的用武之地。

自定义索引会增长，但不会取代 subgraph

技术成熟的团队会继续更多地自建。交易公司、数据提供商和大型机构希望对延迟、模型、执行路径和对账拥有严格控制，对于它们来说，自定义索引是值得的。但需要自定义数据视图的应用数量，始终会超过能够承担构建并运行完整索引基础设施的团队。大多数链上团队不想在产品上线前花三个月时间在管道建设上。他们只想列出重要的合约和事件，定义所需的数据形态，然后进行查询并信任结果。这正是 subgraph 一直在做的事情。

区块链数据栈将保持分层

没有单一工具能胜出，因为工作负载差异太大。RPC 仍用于直接链访问、交易提交和调试。流将实时数据移入私有管道，通用 API 服务于常见的读取模式。数据仓库承载分析和历史研究。自定义索引器属于那些有预算掌控一切的团队，而 subgraph 则处理应用特定的索引和可查询的合约状态。一个严肃的产品会同时使用多种工具，就像一个严肃的后端系统在缓存、队列和数据仓库旁运行 Postgres 而不会有人称之为优柔寡断一样。

采用率的增长不会让这一切变得更简单。它只会让数据更加多样化和专门化，并将这些数据更深地推入生产环境中，在那里犯错会付出真金白银的代价。团队会根据他们正在构建的内容以及他们能负担得起的运行成本来选择不同的基础设施。而在这一切之下，将合约活动转化为结构化的、可查询的状态，Subgraph 以一种大多数团队都能实际接受的方式满足了这一需求，这就是为什么即使在技术栈的其他部分发生变化时，它们仍会存在。

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