一文详解dYdX Indexer

作者：dydx来源：dydx2023-05-29

当我们接近v4主网的启动时我们希望让您一窥 dYdX 团队正在构建的内容。这篇文章深入介绍了索引器。索引器是存在于链本身和最终用户之间的只读层。索引器的目的是以更易于使用的格式转换和提供数据。

考虑索引器的一个好方法类似于 Infura 或Alchemy's role 在以太坊生态系统中的作用。然而，与 Infura/Alchemy 不同，并且与 dYdX v4 中的其他所有内容一样，索引器是完全开源的，任何人都可以运行！

什么是索引器？

作为 dYdX 生态系统工具的一部分，我们希望确保客户在使用 dYdX v4 交易所时能够访问高性能数据查询。Cosmos SDK 全节点提供了许多可用于请求链上数据的 API。但是，这些全节点针对提交和执行块进行了优化，而不是针对来自网络/移动客户端的高频、低延迟请求进行服务。

这就是我们为索引服务编写软件的原因。Indexer是一种只读服务，通过 REST API 和 Websockets 向客户端提供链下数据。它的目的是以更易于使用的方式存储和提供存在于 dYdX 链上的数据。

换句话说，索引器的目的是以一种更高效、更高效和 web2 友好的方式为客户端索引和提供数据。例如，索引器将服务于 websockets，这些 websockets 提供订单簿和填充状态的更新。这些客户将包括前端应用程序（移动和网络）、做市商、机构以及任何其他希望通过传统 web2 API 查询 dYdX 链数据的各方。

链上&链下数据

索引器将使用来自 v4 全节点的数据运行两个独立的摄取/存储过程：一个用于链上数据，一个用于链下数据。目前，链上数据状态更改的吞吐量预计为每秒 10-50 个事件。另一方面，链下数据状态更改的预期吞吐量在 500-1,000 个事件/秒之间。这表示吞吐量要求存在 10-100 倍的差异。通过分别处理这些数据类型，v4 旨在允许不同的服务根据吞吐量需求更好地扩展。

链上数据

链上数据是所有可以通过读取 dYdX 链上提交的交易来复制的数据。所有链上数据均已通过共识验证。这些数据包括：

账户余额（USDC）
账户头寸（未平仓合约）
订单成交
行业
清算
去杠杆化
部分和完全成交的订单
资金费率支付
交易费用
历史预言机价格（用于计算资金和处理清算的现货价格）
长单下单及取消
有条件的下单和取消

链下数据

链下数据是保存在每个 v4 节点内存中的数据。它不会写入区块链或存储在应用程序状态中。此数据无法通过 v4 节点上的 gRPC API 查询，也无法从存储在块中的数据中派生。它实际上是 v4 节点上的临时数据，在重新启动/从内存数据存储中清除数据时会丢失。这包括：

短期订单下达和取消
每个永续交易对的订单簿
索引订单在到达链之前更新

索引器架构

dYdX 索引器由一系列服务组成，这些服务从 v4 全节点获取信息并将该信息提供给各种客户端。Kafka 主题用于将事件/数据传递给索引器中的服务。以下概述了构成 Indexer 的关键服务。

Ender（链上摄取）

Ender 是 Indexer 的链上数据摄取服务。它使用来自“to-ender”Kafka 主题（按块对所有链上事件进行排队）的数据，并且每个有效负载将包含整个块的所有事件数据。

Ender 从该块获取所有状态更改，并将它们应用到 Postgres 数据库，以便索引器存储所有链上数据。Ender 还将通过“to-websocket-?”创建和发送 websocket 事件。需要发出的任何 websocket 事件的 Kafka 主题。

Vulcan（链下摄取）

Vulcan 是 Indexer 的链下数据摄取服务。它将使用来自“to-vulcan”Kafka 主题（排队所有链下事件）的数据，该主题将携带有效负载，包括活动订单簿更新、下订单更新、取消订单更新和乐观填充。

此数据将存储在 Redis 缓存中。Vulcan 将使用任何新的未结订单更新 Redis，将已取消订单的状态设置为取消挂起，并根据收到的有效负载更新订单簿。

每当取消部分成交的订单时，Vulcan 也会更新 Postgres，以更新 Postgres 中的订单状态。Vulcan 还将通过“to-websocket-?”创建和发送 websocket 事件。需要发出的任何 websocket 事件的 Kafka 主题。

Comlink（API 服务器）

Comlink 是一个 API 服务器，它将公开 REST API 端点以读取链上和链下数据。例如，用户可以通过 Comlink 请求他们的 USDC 余额或特定头寸的大小，并将收到格式化的 JSON 响应。

作为 dYdX 团队设定的明确目标，我们正在设计 v4 API 以紧密匹配v3 交换 API[1]，因为 dYdX 用户已经熟悉这些 API。随着时间的推移，我们有时间收集反馈并使用 v3 迭代这些 API，并且相信它们在产品级别是合理的。

Roundtable

Roundtable 是一种周期性的作业服务，提供所需的交换聚合计算。这些计算的示例包括：每个市场的 24 小时交易量、未平仓合约、按账户分类的 PnL、蜡烛图等。

Socks（Websocket 服务）

Socks 是 Indexer 的 websockets 服务，允许客户端和 Indexer 之间的实时通信。它将使用来自 ender、vulcan 和 roundtable 的数据，并将 websocket 消息发送到连接的客户端。

托管和部署索引器

为了创建端到端的去中心化产品，Indexer 将是开源的。这将包括有关所有服务和系统的综合文档，以及用于在流行的云提供商上运行索引器的基础设施即代码。希望托管索引器的第三方运营商的具体职责通常包括初始部署和持续维护。初始部署将涉及：

设置 AWS 基础设施以利用开源存储库。
部署索引器代码以从全节点获取数据并通过 API 和 websockets 发布该信息

Datadog（为 Indexer 服务提供有用的指标和监控）和 Bugsnag（对错误或需要人工干预的问题进行实时警报。索引器的维护将涉及：

为新的开源版本迁移和/或升级索引器
监控 Bugsnag 和 Datadog 是否存在任何问题并提醒内部团队解决
使用 dYdX 提供的运行手册调试和修复任何问题

dYdX建议，至少需要一名 DevOps 工程师来执行部署和维护 Indexer 的必要职责。运营商需要使用以下服务：

AWS
ECS-Fargate
RDS——Postgres 数据库
EC2
Lambda
弹性缓存 Redis
EC2 ELB - 负载均衡器
Cloudwatch - 日志
加密数据管理器
Terraform Cloud - 用于部署到云
Bugsnag - 错误意识
Datadog - 指标和监控
Pagerduty - 警报运营商应该能够以高可用性（即高正常运行时间）的方式托管开源索引器以供公众访问。要求包括拥有上述服务的帐户并雇用适当的人员来执行部署和维护职责。