全面对比分析 EVM 数据索引的各种解决方案

EVM索引的现状

欢迎阅读这份关于区块链索引工具发展趋势的综合指南。

在本指南中，我们旨在清晰、全面地概述当今的索引生态系统，包括The Graph、Ponder、Envio、Subsquid、Goldsky、Sim IDX和自研方案，比较了它们在数据源、性能、链支持、数据转换、查询API、托管控制成本和开发者体验等方面的优劣、权衡和实际应用。

本报告是 Dune 和每天使用这些工具的开发人员共同努力的成果。

特别感谢我们的贡献者和敬业的审阅者：

• Andrew Hong，Herd 创始人
• Billy，Api3 的开发者关系
• CryptoFede，Mode Network 前 DevRel 负责人
• Danning Sui，Flashbots 的数据科学家
• Johnnatan Messias，MPI-SWS 的研究科学家
• Kanishk Khurana，Across/UMA 的开发关系工程师
• Leilani Ledingham，Across/UMA 的产品营销经理
• Nader Dabit，Eigenlayer 的开发者关系
• Pool，Berachain 的数据

他们的见解确保了本指南反映了真实的用户体验。

索引领域发展迅速。 现有解决方案不断添加新功能，并且每隔几个月就会出现新的解决方案。 尽管本指南试图反映截至 2025 年中期的状况，但我们建议你在选择解决方案时补充你自己的研究。

我们希望此资源能够帮助构建者充满信心地驾驭索引领域。

— Dune 团队

I. 简介

为什么要索引？

在一个理想的世界中，应用程序开发人员可以直接连接到区块链并立即检索其应用程序所需的数据——无论是钱包的当前余额、Token的价格还是协议的最新活动。 广义上讲，这些需求分为三类：

1. 账户数据（例如，余额、转账历史）
2. 资产数据（例如，Token价格、元数据）
3. 协议数据（例如，合约事件、财务状况）

虽然账户和资产数据通常可以从 API 提供商处获取，但协议数据通常需要自定义索引。

无论你是运行节点还是使用提供商，连接到区块链通常意味着远程过程调用 (RPC)。 RPC 通过允许你与函数交互并提取智能合约开发人员包含在其协议中的事件来启用数据访问。 但是，除非智能合约开发人员包含一个可以准确回答你问题的函数，否则你还有一些工作要做。

事实上，通常都是这样。 区块链状态旨在允许合约开发人员安全地编写和管理其协议所需的状态。 毕竟，所有这些都需要 gas——向 optimizoors 致敬。 它当然没有针对区块链应用程序构建商的数据访问要求进行优化。

关于要完成的工作，它至少涉及跨区块范围拉取日志并执行转换和/或聚合。 根据具体的数据点，可能包括扫描数百万个区块、解码事件签名、解释复杂的交易轨迹以及执行复杂的国家重建。 尝试通过直接从节点实时读取每个请求来执行此操作的速度会非常慢，以至于你会在应用程序加载之前放弃它。 这种性能差距就是从 Uniswap 到 Aave 再到 OpenSea 的每个成功的区块链应用程序都依赖于一个关键的基础设施：索引器的原因。

以下是我们观察到的使用基于 RPC 的索引构建区块链数据应用程序的标准设计模式：

‍

使用基于 RPC 的索引构建应用程序

什么是索引器？

索引器将区块链的原始、仅附加日志转换为针对应用程序需求量身定制的结构化、可查询的数据库。 它通过持续跟踪链上活动、解析数据和维护相关状态的实时视图，将 30 秒（或某些情况下为 30 小时）的扫描转换为 30 毫秒的 API 响应。

The Graph 通过子图开创了事件驱动的索引编制，为开发人员如何与区块链数据交互设定了标准。 从那时起，生态系统演变为工具和理念多样化的局面。 有些优先考虑开发人员的体验，而另一些则侧重于性能、灵活性或可验证性。 它们在提取、转换和服务链上数据的方式上做出了不同的权衡。

选择正确的索引器是一项关键的架构决策。 不合适的选择可能会导致代价高昂的迁移和不断增加的技术债务。 区块链生成大量新数据。 虽然原始的 Ethereum 节点每年可能只会增长数百 GB，但派生和索引的数据集（尤其是那些为应用程序设计的数据集）每年可能会膨胀到 TB 级。 结构化、可查询和精细化的视图越多，需要处理和存储的数据就越多。

如果这还不够难，像账户抽象和基于意图的协议这样的新原语和模式打破了关于如何以及应该如何索引链上活动的传统假设。 随着应用程序跨链扩展，额外的复杂性也会增加。

驾驭这一点需要的不仅仅是比较功能。 它需要了解核心架构的权衡。 对于重组保护，你可以容忍多少索引延迟？ 你需要访问原始追踪或完整的合约状态吗？或者日志就足够了？ 你是在优化开发人员的速度、数据完整性还是大规模的性能？ 你需要在单个数据库中进行跨链数据吗？ 托管 API 和托管数据库对你的团队来说至关重要吗？或者你更喜欢完全控制？ 为了更快地上市，可以接受供应商锁定吗？

本报告是一份清晰、实用的现代索引堆栈指南。 它由每天运行生产级系统的团队和数据专家塑造，揭示了真正的权衡和经验教训。

II. 索引基本原理和权衡

数据来源

你对索引解决方案的选择在很大程度上取决于你需要什么数据。 对于某些用例，你可以完全跳过索引并使用来自 CoinGecko、Sim API 或 Zerion 等提供商的 API。 这些不在本报告的范围内，但通常是务实的选择。 通常，你只需要从一些已知的合约中发出的日志，但有些用例需要更深入地访问追踪、原始数据存储或完整的合约状态。

假设你正在构建一个包含 Uniswap 交易的应用程序。 在 V2 和 V3 中，Swap 事件在单个结构化日志中发出关键详细信息——金额、发送者、接收者、池地址。 V4 引入了自定义Hook，可以在交换之前、期间和之后启用任意逻辑。 因此，Swap 事件可能不再反映完整的资产流。 现在，索引需要追踪访问和逻辑才能将核心行为与Hook效果分开。

通过 Uniswap X，优化器已经接管，甚至追踪也显得不足。 大部分逻辑都存在于报价引擎和签名的链下意图中，由中继器提交最终结算。 索引这意味着解析 calldata 并从链外重建执行路径。

实时和回填性能

大多数应用程序需要实时数据：由新区块触发的亚秒级更新。 如果你看过 Dune.com 并且想知道是否可以在你的应用程序中使用这些数据，那么你并不孤单。 但是 Dune 针对灵活的分析进行了优化，而不是针对实时的查找。

实时性能只是故事的一半。 回填速度通常是影响开发人员速度的最大因素。 如果重新索引需要两周时间，你会犹豫是否要进行更改。 如果需要两个小时，你会不断迭代。 快速回填不仅可以帮助你从中断中恢复，还可以实现紧密的反馈循环、更快的功能发布和更多的实验。

理想的索引器可以跟上最新的区块，并且可以根据需要处理多年的历史数据。

链支持

随着应用程序跨链扩展，数据量和架构复杂性都会增加。 索引器必须支持多个 EVM 链（有时是非 EVM 链）并提供一种一致的方式来跨链查询。 对于某些用例，单独索引每个链就可以了。 对于其他用例，你可能希望在同一系统中统一跨链数据。

数据转换与聚合

不要让朋友在 Solidity 中进行数学运算。 无论你是将原始余额除以 Token的小数位数，还是聚合数千个交换来计算损益，你的应用程序都需要转换和聚合。

许多协议将其逻辑拆分到多个合约中。 例如，Uniswap V3 预置涉及 NFTPositionManager 和池合约，从而发出不同的拼图。 为了重建完整的上下文，你的索引器需要支持跨事件连接和延迟排放。

转换发生的位置各不相同：有些管道内联处理它们，另一些在 ETL/ELT 阶段处理它们，另一些在查询时处理它们。 正确的答案取决于你的用例和你的堆栈。

查询和 API 层

你的数据库模式和索引策略直接影响查询性能。 在像区块链这样的高吞吐量、附加重的环境中，索引不良的表可能会瓶颈，甚至简单的查询也会受到影响。

工具在公开数据的方式上也有所不同：REST、GraphQL、SQL。 开发人员可能会使用像 Drizzle 这样的 ORM 来保证类型安全，或者使用像 Kysely 这样的查询构建器。 每种方法都在控制、灵活性和开发人员的熟悉度方面提供了不同的权衡。 某些索引器允许你定义自定义端点； 其他索引器则提供开箱即用的标准模式。 无论如何，你的 API 层必须随着使用情况而扩展，而不是在其下崩溃。

托管、控制和成本

可能有一些核心团队在运行自己的节点、完整的管道和自定义基础设施——但大多数团队至少购买了堆栈的一部分：

• 节点/RPC 访问
• 索引引擎
• 托管数据库
• 托管 API 服务

索引器在他们抽象的内容上有所不同。 有些是完全托管的。 有些需要你来管理基础设施、存储和扩展。 你的选择取决于你对开发运维的容忍度、对控制的需求以及内部专业知识。

成本是另一个关键因素。 自托管解决方案会产生诸如计算、存储、RPC 带宽、工程时间之类的费用。 托管索引器通常按查询量、计算时间、数据量或索引时间收费。 免费层可以帮助你进行原型设计，但成本可能会快速扩展。 如果你要索引许多合约或链，定价模型可能会成为决定因素。 了解你要支付的费用，以及这些成本如何随着使用情况而变化。

开发者体验

开发人员体验决定了团队可以多快地交付、迭代和调试。 关键因素包括:

• 用于表达索引逻辑的语言（TypeScript、Solidity、YAML）
• 本地开发人体工程学（热重载、可测试性）
• 可观察性（日志、指标、错误显示）

某些工具与 Git 工作流程集成，从而可以实现快速部署和预览环境。 其他工具则需要更多手动设置。 快速测试和迭代的能力，尤其是在早期产品阶段，可能是几天与几周才能交付的区别。

III. 当前的索引格局：解决方案深度剖析

如上一节所述，索引管道的设计是一个复杂的决策，它根植于围绕执行环境、数据源、转换需求和开发人员人体工程学的权衡。 有了这样的基础，我们现在转向市场上的实际工具，每个工具都针对不同的优先级和开发人员需求量身定制。

本节深入探讨当今可用的主要索引解决方案。 我们将探讨每种工具是什么、它如何应对前面描述的挑战，以及它如何在上一节中定义的关键维度上进行比较。 这样做的目的是对当前的索引格局提供一种可靠、公正的看法，而不规定一种万能的解决方案。

‍

The Graph

子图是一种被广泛采用的用于索引链上数据的框架。 它们定义了如何跟踪智能合约事件并将其转换为可查询的 GraphQL API。 虽然最初是作为 The Graph 协议的一部分创建的，但子图现在也受到 Alchemy 和 Goldsky 等第三方平台的支持，也可以在自托管环境中运行。

The Graph 指的是更广泛的去中心化索引协议和托管服务，它们开创了子图。 开发人员使用 TypeScript 编写映射，并使用 YAML 定义模式。 The Graph 在去中心化的索引器网络中或通过 Subgraph Studio 在中心化的托管版本中运行这些程序。

从历史上看，子图被认为对于高级连接不灵活，或者支持新链的速度很慢。 近年来，The Graph 引入了诸如 Substreams 和 Firehose 之类的工具，这些工具提供了更高的吞吐量数据提取和更高效的子图执行。

与其他解决方案相比，The Graph 抽象了大部分基础设施，并且可以抵抗单点故障。 其去中心化的模型、广泛的链支持和成熟的工具使其成为许多索引需求的流行默认选择。

对比说明

• 数据来源： 主要基于事件日志和通过 ABI 解码的状态映射。
• 性能： 由于逐块处理，历史上速度较慢。 像 Firehose 和 Substreams 这样的新增功能实现了更快的查询和快速的回填。 在良好支持的链上，几乎可以实现即时更新。
• 链支持： Subgraph Studio 支持的 网络超过 60 个，产品套件中超过 90 个。 在单个子图中没有内置的跨链连接支持。
• 数据转换与聚合： 在 AssemblyScript（类似于 TypeScript）中定义转换。 可以在映射内部实现聚合，但是复杂的操作可能需要链下后处理。
• 查询和 API 层： GraphQL 接口。 模式驱动和强类型。 超出 GraphQL 模式的自定义端点支持有限。
• 托管、控制和成本： 三种选择：托管（通过 The Graph 的 Subgraph Studio）、去中心化（通过 The Graph Network）、自托管（通过开源工具）。 Subgraph Studio 从每月 10 万个免费查询开始，然后每 10 万个查询收费 2 美元。
• 开发者体验： 强大的文档、CLI 工具和子图浏览器。 需要学习 Graph 相关的模式定义和 AssemblyScript。 Subgraph Studio 和 Graph CLI 支持快速预览和部署。

“对我来说，我对来自 The Graph 的数据持乐观的信任态度。 我相信他们认为他们的社会价值是建立在提供准确结果的基础上的。 如果他们失去社会信任，那么他们的产品将不会被使用。 我相信他们报告的内容是真实的，直到有人受到激励来证明它是错误的。”

‍

– The Graph 的用户，Oracle 的 DevRel。

‍

Ponder

Ponder 是一个自托管的 TypeScript 索引框架，它使开发人员可以完全控制区块链数据的提取、转换和存储方式。 它使用事件驱动的逻辑与诸如 viem 之类的工具相结合，以执行链上读取并在索引期间触发自定义转换。 Ponder 特别适合那些希望将其索引逻辑与应用程序堆栈的其他部分紧密集成的开发人员。

与托管平台不同，Ponder 不施加任何基础架构约束，也没有供应商锁定。 团队可以定义自己的模式、管理自己的数据库并微调整个管道的性能。 它非常适合复杂的、对性能敏感的应用程序——尤其是需要自定义计算或使用非标准智能合约架构的 DeFi 协议。

Ponder 在构建实时仪表板和分析应用程序的团队中也很受欢迎，在这些应用程序中，延迟和迭代速度至关重要。 诸如热重载、清晰的错误显示和测试友好的结构之类的本地开发功能使你可以轻松快速地进行交付。

对比说明

• 数据来源： 读取事件日志，并且可以使用 viem 通过 RPC 调用链上函数。 完全控制提取哪些数据以及如何转换数据。 可以索引通过标准合约接口或公共方法访问的任何数据。
• 性能： 如果你有正确的 RPC 设置，则可以实现实时快速回填。 基准测试表明，对于某些任务，Ponder 的速度可能比 Graph 子图快 10-15 倍，但这取决于 RPC 延迟和调整。
• 链支持： 通过 RPC 支持所有 EVM 链。 多链设置需要手动配置。 没有对统一的跨链视图的内置支持。
• 数据转换与聚合： TypeScript 中的转换。 支持内联聚合、异步读取和条件逻辑。
• 查询和 API 层： 没有内置的查询层。 开发人员通过自己的应用程序服务器公开数据。 可以与像 Drizzle 这样的 ORM 或像 Kysely 这样的查询构建器集成。 适合构建紧密集成的后端的团队。
• 托管、控制和成本： 完全自托管，但通常部署在像 Railway 或 Render 这样的平台上。 可以免费使用，但是基础设施成本会随着使用量而扩展。
• 开发者体验： 强大的本地开发体验，具有热重载、CLI 和 TypeScript 支持。 使用现代工具和约定构建。 易于集成到完整的 TypeScript 应用程序中。

“如果你要跟踪一些特定的合约，需要在转换期间进行各种 API 调用，并且希望将这些数据存储在自己的数据库中； 那么，当与像 Quicknode 或 Alchemy 这样的 RPC 提供商结合使用时，Ponder 将是最简单且成本最低的选择。”

‍

– Herd 创始人 Andrew Hong 在 Crypto Data Engineering Guide 中提到。

‍

Envio

Envio 是一个针对 EVM 链优化的、高速索引平台。 它使用一个名为 HyperIndex 的专有框架，该框架在由 Envio 维护的预索引数据层上运行。 这种模型可以快速查找事件和快速回填，而无需你自己解析原始区块链数据。

Envio 不是直接从节点或 RPC 提取数据，而是预处理区块链事件并将其以允许极快访问的内部格式进行布局。 这样就可以实现诸如通配符索引之类的用例，你可以在所有合约中提取某种类型的所有事件，而无需预先定义特定的地址。 它对于监视新协议、Token标准或动态合约部署特别有用。

HyperIndex 支持本地开发和生产用途，但是数据源仍然是 Envio 的托管基础架构。 你可以自己托管索引器逻辑，但是底层数据层是中心化的，并且通过 Envio 的 API 进行访问。 这引入了一个权衡：你获得了速度和易用性，但是放弃了对原始提取层的某些控制。

对比说明

• 数据来源： 在来自 Envio 内部 API 的预索引链上数据上运行。 访问事件日志和回执；对状态或存储读取的可见性有限。 不适用于需要完整追踪或任意链上函数调用的用例。
• 性能： 回填可以超过 5,000 个事件/秒。 通过 HyperRPC 支持实时新鲜区块摄取。 性能优势来自读取预处理的磁盘布局，而不是 RPC。
• 链支持： 广泛的 EVM 链支持。 没有对非 EVM 或统一的跨链视图的内置支持。
• 数据转换与聚合： 支持索引框架中的内联转换。 开发人员可以使用 Envio 的 SDK 定义事件处理程序并发出结构化数据。 不支持有状态的链上读取或自定义合约连接。
• 查询和 API 层： 随附一个 GraphQL API 以公开索引的数据。 专为前端使用而设计，无需进行额外的配置。 可以通过 SDK 自定义端点和查询。
• 托管、控制和成本： 开发人员可以在本地或在生产中运行其索引器逻辑，但是必须查询 Envio 托管的预索引后端。 开发层包括 750 个免费索引编制小时。 付费计划的起价为 70 美元/月，具体取决于索引编制时间和支持要求。
• 开发者体验： 干净的 CLI 和 SDK，只需最少的设置。 简单的基于事件的用例的快速入门。 对于深度自定义或与非标准数据流集成来说，不够灵活。

‍

Subsquid

Subsquid (SQD) 提供了一个模块化的索引架构，该架构将数据提取与转换分离。 它的核心模型涉及通过分布式存档网络获取区块链数据，并通过 Squid SDK 转换数据，Squid SDK 将输出到像 PostgreSQL 或 BigQuery 这样的自定义数据接收器中。

与传统的逐个事件索引器不同，Subsquid 以大批量处理数据。 这种模型针对速度、规模和分析用例进行了优化。 它擅长于开发人员需要访问跨多个合约或区块的广泛数据集，并且延迟不如吞吐量重要的情况。 Subsquid 还因其对基于 Substrate 的和非 EVM 链的支持而脱颖而出，这使其非常适合多链分析和跨生态系统仪表板。

由于 Subsquid 允许直接输出到用户管理的数据库中，因此团队可以将区块链数据集成到熟悉的基础架构中，并使用标准工具对其进行查询。 这减少了构建复杂分析或将链上数据与链下数据集成在一起的团队的开发开销。

对比说明

• 数据来源： 支持日志、回执、追踪和状态差异。 允许深入访问交易内部结构。 通过存档节点提取原始链数据（不依赖于标准 RPC）。
• 性能： 基于批处理的处理实现了高速回填（每秒数万个区块）。 并非为亚秒级延迟或实时 UI 更新而设计。
• 链支持： 支持 200 多个网络，包括 EVM、Substrate 和其他非 EVM 链。 非常适合构建多链分析的开发人员。
• 数据转换与聚合： 在 Squid SDK 中处理转换； 输出可以定向到自定义数据库。 最适合那些习惯于定义自定义模式和处理面向分析的工作流程的团队。
• 查询和 API 层： 没有内置的 API 层； 开发人员通过连接的数据库定义自己的 API 层。 提供了最大的灵活性，但与即插即用的 GraphQL 端点相比，需要更多的工程工作。
• 托管、控制和成本： 需要运行自己的索引器 (squid)，但是依赖于托管的存档节点来进行数据摄取。 免费共享层支持大多数早期用例。 专用节点的起价约为 140 美元/月； 定价会随着计算/存储的扩展而扩展。
• 开发者体验： 快速设置大规模回填。 熟悉的输出目标（Postgres、BigQuery）减少了数据团队的入门摩擦。 对于没有现有数据基础设施的、以前端为中心的团队来说，不太符合人体工程学。

Goldsky

Goldsky 是一个在子图模型的基础上构建的托管索引平台，它为开发人员提供了一种快速、可靠的方式来交付区块链 API，而无需自己处理基础设施。 它与 The Graph 的子图模式和工具完全兼容，但是针对速度、支持和开发人员控制进行了优化。

Goldsky 无需团队运行自己的 graph 节点，而是处理部署、扩展和基础架构，并提供强大的 SLA 和响应迅速的支持。 开发人员可以使用熟悉的 Graph CLI 工具定义子图，而 Goldsky 会处理其余的任务——这使其成为希望获得可预测的性能和快速迭代而又无需 DevOps 开销的团队的有吸引力的替代方案。

对于希望在自己的基础设施中使用链上数据的团队，Goldsky 还提供“Mirror”，该功能将子图输出流式传输到用户管理的数据库中，如 Postgres 或 Kafka。 虽然这不是本指南的重点，但这对于分析或后端集成工作流程可能很有价值。

对比说明

• 数据来源： 支持来自子图映射的合约事件、日志和状态。 数据访问与通过 The Graph 的索引逻辑可获得的数据访问一致。
• 性能： 由于自定义基础设施优化，索引速度比普通的子图快得多。 性能改进在高容量合约和快速链上最为明显。
• 链支持： 支持 90 多个网络，主要是 EVM。 在添加部署改进的同时，保持与 The Graph 的链奇偶校验。
• 数据转换与聚合： 使用与子图相同的基于 TypeScript 的映射模型。 聚合和转换作为子图逻辑的一部分编写。
• 查询和 API 层： 通过 GraphQL 公开数据，与子图定义生成的模式兼容。
• 托管、控制和成本： 启动友好的 定价层，具体费用取决于子图计算和存储单元。 像 Aave 这样的团队每月支付约 300 美元，而 Uniswap 支付约 2800 美元。 有一个 定价计算器 可以估算成本。
• 开发者体验： 与 Graph CLI 和 Subgraph Studio 格式兼容。 简单的部署和监控 UI。

自研解决方案

有些团队选择在内部构建完全自定义的索引管道。 这涉及运行他们自己的区块链节点（通常包括存档节点）、提取原始链数据、设计自定义模式，以及编写用于转换、存储和服务的定制逻辑。 吸引力在于完全控制：每个设计决策都是根据项目的特定需求量身定制的。

这种模型在高频交易 (HFT) 公司、分析平台或协议开发人员（启动具有非标准执行环境的新链）中最常见。 当没有现有的索引器支持你的用例，或者当性能和正确性不能受到损害时，自研解决方案将提供无与伦比的灵活性。

权衡是复杂性。 这些系统的构建和维护成本很高，通常需要专业的工程团队和长期投资。 但是，如果做得好，它们可以有效地扩展并成为持久的战略优势。

对比说明

• 数据来源： 除了你自己的基础设施可以提取的内容外，没有其他限制
• 性能： 完全取决于实现。 通过足够的工程工作，能够实现低延迟的摄取和并行回填。
• 链支持： 可以支持多链，但是会增加大量的开销
• 数据转换与聚合： 能够实现专门的转换、新颖的聚合以及与应用程序逻辑的紧密集成。
• 查询和 API 层： 可以构建以匹配任何 API 形状或后端要求。 通常与内部数据平台紧密结合。
• 托管、控制和成本： 完全是自我管理的。 大量的工程和基础设施成本，随着时间的推移，通常会达到数百万美元。
• 开发者体验： 最大的灵活性，但是初始设置和维护负担很高。 工具、可观察性和迭代速度完全是你自己的责任。

“过去，我维护了自己的节点，但是由于数据量不断增长以及链的数量不断增加，这种方法变得不切实际。 在这种情况下，选择正确的索引解决方案对于我的工作至关重要，因为它使我可以专注于数据分析并回答在我的工作中最重要的研究问题。”

‍

– Johnnatan Messias，研究科学家 (MPI-SWS)

‍

Sim IDX

Sim IDX 是一个由 Dune 开发的高性能、完全托管的索引平台，专为希望快速、可靠地访问丰富的链上数据而无需管理基础设施的团队而设计。 与大多数在执行后提取数据的解决方案不同，Sim 将索引逻辑直接嵌入到 Solidity 监听器合约中。 这些合约在 Dune 的自定义检测 EVM (iEVM) 内部执行，该 iEVM 启用了实时过滤、并行回填和通常无法通过日志获得的深度状态访问。

由于索引逻辑在执行期间运行，因此 Sim 可以跳过不相关的区块，并行执行作业，并公开交易内部状态更改。 这种架构可以实现高吞吐量的回填和精细的索引编制，对于复杂的 DeFi 协议和实时应用程序尤其有价值。

IDX 还随附了基于 Git 的开发工作流程：开发人员使用 Solidity 编写监听器合约，将其提交给 GitHub，然后通过 pull request 进行部署。 除了索引层之外，Sim 还提供了一个使用 SQL 和/或 Drizzle 的 TypeScript API 堆栈来定义自动扩展 Hono 端点，从而在面向消费者的 API 的结构和灵活性之间取得平衡。

对比说明

• 数据来源： 完整的 EVM 状态访问，包括调用其他合约、访问合约存储和追踪。 索引逻辑是在执行时通过 Solidity 监听器定义的，从而启用了事务内可见性和选择性区块过滤。
• 性能： 启用了实时； 索引在区块执行时运行。 回填高度并行化和过滤，从而可以快速摄取历史数据。
• 链支持： 支持 10 多个 EVM 链，并且每月还会添加更多。 本机支持跨链索引和查询。
• 数据转换与聚合： 在索引和查询层中可用。
• 查询和 API 层： 基于 TypeScript + SQL 的 REST API 层。
• 托管、控制和成本： 完全托管的服务。 自定义基于使用情况的企业定价。 自托管数据流将在 7 月底推出，供需要数据托管的团队使用。
• 开发者体验： 具有 Solidity 定义的索引逻辑的独特模型。 监听器和 API 逻辑通过 GitHub 提交和部署。 紧密的反馈循环和熟悉的开发工具（VS Code / Cursor、GitHub、SQL、TypeScript）。
• 性能： 通过并行区块执行和基于合约活动的选择性过滤实现快速回填。 查询层是为高 RPS 构建的。
• 链支持： 支持 10 多个 EVM 链。 每月都会添加更多。
• 开发者体验： 独特的基于 Solidity 的索引逻辑提供了链上清晰度和可组合性。 基于 TypeScript + SQL 的 API 层支持快速迭代和灵活的输出格式。 无需管理 RPC、基础设施或存储。

IV. 为什么 Dune 构建 Sim IDX

Sim IDX 的创建是为了解决传统区块链索引中长期存在的局限性。如上所述，大多数现有系统在执行后从完整节点提取数据，并在外部对其进行转换。这种模型引入了权衡：开发人员通常必须在实时响应和重组安全性之间做出选择，接受对执行细节的有限可见性，或者承担管理基础设施的运营负担。

Dune 构建了 Sim IDX，通过将索引逻辑直接嵌入到自定义的检测 EVM (iEVM) 中来挑战这种模型。这种架构最初由 smlXL 团队开发，自 Dune 在 2024 年 11 月收购该公司 以来得到了 Dune 的进一步发展，它消除了开发人员管理节点基础设施或复杂 ETL 管道的需求。这颠倒了典型的流程——在执行时处理相关区块，而不是事后处理——从而实现了快速、并行化的回填和亚秒级的数据可用性。索引成为执行层面的操作，从而可以更细粒度地访问区块链状态。

这种架构的动机是需要更精确的数据，特别是对于像 DeFi 应用程序这样的复杂协议，在单个事务中发生的中间状态变化与最终状态同样重要。例如，捕获一个波动剧烈的互换中的每次价格更新，而不仅仅是最终结果，可以解锁新的分析类型和基于事件的系统可能错过的实时响应。

Sim 的设计还旨在简化协议范围内的可观察性。许多项目需要跟踪大量且动态的合约集合——例如每个 ERC-721 或每个 Uniswap V3 分叉。使用 Sim，开发人员可以定义一个针对实现给定接口的所有合约的单一索引作业，从而无需冗长、静态的地址列表或多个管道。

最后，Sim IDX 反映了一种信念，即开发人员应该同时拥有控制权和速度。它支持基于 Git 的工作流程和预览环境，无需节点或数据库维护。通过将索引更靠近执行并减少运营摩擦，Sim 的构建旨在为需要速度、准确性和灵活性的团队提供服务，以支持他们的扩展。

目前，Sim 仅通过完全托管的系统提供，这意味着团队可以零运维和零开销地管理管道并开始使用 Sim 构建。在接下来的几个月中，Sim 还将为那些需要更多数据控制权的用户推出自托管数据库的选项。

VII. 贡献者视角

Andrew Hong, Herd 创始人

“在区块链数据中，你在哪里进行表转换将严重影响你数据管道的延迟和成本。Sim IDX 允许你将这些转换移动到管道的起始位置，从而避免以后出现巨大的表和昂贵的连接操作。这是加密领域数据工程的一种新方法，我们在 Herd 正在利用它。”

Billy, Api3 的开发者关系

“除非你运行自己的基础设施，否则 RPC 服务的成本可能非常高，因此进入门槛可能很高。

套利和清算机会节奏非常快，每一秒都很重要。因此，索引器上的任何延迟都会让你失去机会，尤其是在市场波动时期。

各团队需要考虑将一些内部维护工作抽象出来所带来的业务成本，以及内部维护的技术债务成本。 有时，你只需要启动。

Sim 非常有趣。我实际上很高兴将其用于可以触发函数调用和智能合约级别的实时抵押品的实时更新。 这种级别的索引可以带来全新级别的服务，以及在时间上的优势。”

CryptoFede, Mode Network 的前 DevRel 负责人

“我只是喜欢当一个团队决定解决一个似乎已经解决的问题，然后分解问题的每个部分以提出解决方案。Sim IDX 具有创新性，我真的很高兴看到它的性能。”

Danning Sui, Flashbots 的数据科学家

“如今，加密领域的数据索引格局既成熟又具有竞争力。对于大多数刚开始组建数据团队的加密公司来说，订阅企业级流媒体服务通常比构建和维护内部实时索引管道和数据仓库更具成本效益和战略意义。除非你的核心业务涉及构建数据产品，否则使用供应商会将你雇用完整的内部团队的成本降低 10%。

运营你自己的管道也意味着要应对无数的技术挑战：确保 RPC/节点可靠性，管理实时新鲜度与链重组一致性等等。通过索引 onchain 数据，内部数据团队的主要角色通常会转变为编排：整合外部 onchain 和内部 offchain 来源，并通过选择的可视化和 BI 工具实现分析。”

加密风险投资或研究公司通常几乎完全依赖 Dune，但对于大多数拥有实际产品的公司（无论链或 dapp 如何），内部管道对于将用户上下文与 onchain 行为联系起来仍然至关重要，而且他们中的许多人今天都在运行混合数据设置。根据我组建和合作过的团队，常见的堆栈包括供应商流式传输的 ClickHouse，通过 Airflow 进行编排，并在 Hex.tech 等工具中进行分析。这使得团队可以将 offchain 敏感用户数据与 onchain 行为相结合 - 这对于增长和产品洞察至关重要。为了提高可见性，团队还需要解码合约，或将其协议数据推送到 Dune——通过 Spellbook 或公共上传——因为 Dune 已成为行业指标和仪表板的首选目的地。”

Johnnatan Messias, MPI-SWS 的研究科学家

“作为一名区块链数据研究员，我经常需要访问跨多个链的数据。这带来了相当大的复杂性，并消耗了原本可以用于更深入分析或探索新研究方向的时间。即使使用单条链也可能非常耗时，而处理多条链（尤其是像 rollup 这样的高吞吐量链）时，挑战会大大增加。

过去，我会维护自己的节点，但由于数据量不断增长以及链的数量不断增加，这种方法变得不切实际。在这种情况下，选择正确的索引解决方案对于我的工作至关重要，因为它让我能够专注于数据分析并回答对我工作中最重要的研究问题。

Sim IDX 提供了一个用于索引和转换区块链数据的强大框架。它对于分析静态 SQL 查询无法轻易捕获的复杂链上行为尤其有价值。它可用于投票跟踪、空投资格、DeFi 交易流和 DAO 治理模式。这种能力对我的日常研究非常有用。”

Pool, Berachain 的数据员

“Onchain 索引是应用程序的核心组成部分，但它常常被进入该领域的开发人员所忽视。首次构建者通常专注于智能合约和前端设计，但很快就会发现直接查询区块链数据的速度非常慢且成本高昂。索引平台充当关键基础设施，为从 DeFi 仪表板到 NFT 市场的各种后端提供支持。

新的 Sim IDX 使户更容易利用 onchain 数据，从而抽象化了索引基础设施的复杂性。我期待看到构建者如何使用它们。”

IX. 结论：前进的道路

EVM 索引领域不再是单一解决方案的领域；它是一个充满活力的专业工具生态系统，可满足各种需求。索引也是基本的必要基础设施，而不是可有可无的附加组件。正如本指南所示，选择正确的索引器取决于仔细评估你的应用程序的核心需求：实时延迟的关键性、数据转换的复杂性、所需状态访问的深度（事件、跟踪、联系人分类）、历史回填的规模、多链支持以及你的团队对基础设施管理的容忍度与对开发人员速度的渴望。

从 The Graph 的去中心化理念到 Ponder 的精细控制，Envio 的 HyperIndex 的速度，自研解决方案的定制能力，以及 Sim IDX 的新型执行层方法——每种工具都做出了独特的权衡。没有通用的“最佳”，只有“最适合”。

关键的要点是意图性。深入了解你的数据需求，确定你的不可妥协项，并利用此处共享的从业者的比较和见解。在这个由新的链架构、数据密集型应用程序（如基于意图的系统和链上 AI）以及对可验证索引的需求驱动的动态空间将继续快速发展。通过选择与你今天的基本面保持一致的解决方案，你可以构建一个能够适应明天的弹性基础。

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