一文了解dYdX V4技术架构

dydx热度: 17148

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

原文作者:dydx

原文标题:v4 technical architecture overview

原文来源:dydx

编译:Will,IBCL

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

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

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

v4 系统架构

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

dYdX协议

该协议是建立在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 应用程序:该网站将使用 Javascript 和 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 主网发布的临近,我们将在后续博文中进一步深入探讨协议、索引器和各种前端的基础设施。

声明:本文为入驻“MarsBit 专栏”作者作品,不代表MarsBit官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
免责声明:本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况,及遵守所在国家和地区的相关法律法规。
关键字:dYdX