简述 dYdX V4 技术架构

dYdX V4 将是一个独立的 L1 区块链，具有完全去中心化的链下订单簿和匹配引擎。

**撰文：**dYdX

编译：IBCL

dYdX 链 V4 是 dYdX 协议的最新的一个迭代，它将由开源软件组成。当前投入生产的版本称为 v3, dYdX 的 v3 和过去版本的核心是部署到现有链上的智能合约，并结合托管在云中的中心化服务。

v4 将是一个独立的 L1 区块链，具有完全去中心化的链下订单簿和匹配引擎。dYdX 链将基于 Cosmos SDK 和 CometBFT PoS 共识协议。

当我们接近 v4 主网的启动时，我们希望让您一窥 dYdX 团队正在构建的内容。这篇文章提供了 v4 架构的高级概述。鉴于 v4 仍在开发中可能会存在变化。

v4 系统架构

dYdX v4 被设计成完全去中心化的端到端。主要组件大致包括协议、索引器和前端。这些组件中的每一个都将作为开源软件提供。dYdX Trading Inc. 将不会运行任何组件。

协议

该协议是建立在 CometBFT 之上并使用 CosmosSDK 的 L1 区块链。节点软件是用 Go 编写的，并编译为单个二进制文件。与所有 CosmosSDK 区块链一样，v4 使用权益证明共识机制。

该协议将由节点网络支持。有两种类型的节点：

• 验证者：验证者负责将订单存储在内存中的订单簿中（即链下且不承诺达成共识），将交易闲聊给其他验证者，并通过共识过程为 dYdX 链生成新区块。共识过程将让验证者以加权循环方式轮流作为新区块的提议者（由抵押到其节点的代币数量加权）。提议者负责提议下一个区块的内容。当订单匹配时，提议者将其添加到他们提议的区块中并启动共识回合。如果 ⅔ 或更多的验证者（按股权权重）批准一个区块，则该区块被视为已提交并添加到区块链中。用户将直接向验证器提交交易。
• 全节点：全节点代表运行不参与共识的 v4 应用程序的进程。它是一个 stake 权重为 0 的节点，它不提交提案或对其进行投票。然而，全节点连接到验证器网络，参与交易的八卦，并处理每个新提交的块。全节点具有 dYdX 链及其历史的完整视图，旨在支持索引器。某些方可能决定（出于性能或成本原因）运行他们自己的完整节点和 / 或索引器。

索引器

Indexer 是一个只读服务集合，其目的是以更高效和 web2 友好的方式为用户索引和服务区块链数据。这是通过使用来自 v4 全节点的实时数据，将其存储在数据库中，并通过 websocket 和 REST 请求向最终用户提供该数据来完成的。

虽然 v4 协议本身能够将端点暴露给有关一些基本链上数据的服务查询，但这些查询往往很慢，因为验证器和完整节点没有经过优化以有效地处理它们。此外，对验证者的过多查询会削弱其参与共识的能力。出于这个原因，许多 Cosmos 验证器倾向于在生产中禁用这些 API。这就是为什么构建和维护与验证器分开的索引器和完整节点很重要。

索引器将使用 Postgres 数据库存储链上数据，使用 Redis 存储链下数据，使用 Kafka 将链上 / 链下数据消费和流式传输到各种索引器服务。

前端

为了构建端到端的去中心化体验，dYdX 正在构建三个开源前端：Web 应用程序、iOS 应用程序和 Android 应用程序。

• Web 应用程序：该网站将使用 Java 和 React 构建。该网站将通过 API 与 Indexer 交互以获取链下订单簿信息，并将交易直接发送到链上。dYdX 将开源前端代码库和相关部署脚本。这将允许任何人通过 IPFS/Cloudflare 网关轻松部署和访问 dYdX 前端到 / 从他们自己的域 / 托管解决方案。
• 移动：iOS 和 Android 应用程序分别使用原生 Swift 和 Kotlin 构建。移动应用程序将以与 Web 应用程序相同的方式与索引器交互，并将交易直接发送到链。移动应用程序也将是开源的，允许任何人将移动应用程序部署到 App Store 或 Play 商店。特别是对于应用程序商店，部署者需要有一个开发者帐户和一个 Bitrise 帐户才能完成应用程序提交过程。

订单的生命周期

现在我们对 dYdX v4 的每个组件有了更好的了解，让我们来看看在下订单时它们是如何组合在一起的。当在 v4 上下订单时，它将遵循以下流程：

1. 用户在分散的前端（例如网站）或通过 API 进行交易
2. 订单被路由到验证器。该验证者将该交易八卦给其他验证者和完整节点，以使用新订单更新他们的订单簿。
3. 共识过程选择一个验证者作为提议者。选定的验证器匹配订单并将其添加到下一个提议的块中。
4. 提议的区块继续通过共识过程。a. 如果 ⅔ 的验证节点投票确认该块，则该块将被提交并保存到所有验证节点和全节点的链上数据库中。b. 如果提议的区块没有成功达到 ⅔ 阈值，则该区块将被拒绝。
5. 提交块后，更新的链上（和链下）数据从全节点流式传输到索引器。然后，索引器通过 API 和 Websockets 将此数据提供给前端和 / 或查询此数据的任何其他外部服务。

上面的流程是订单 / 数据如何通过 v4 移动的高级概述。随着 v4 主网发布的临近，我们将在后续博文中进一步深入探讨协议、索引器和各种前端的基础设施。