dYdX V4 の技術アーキテクチャを簡単に説明します

dYdX V4 は、完全に分散化されたオフチェーンのオーダーブックとマッチング エンジンを備えた独立した L1 ブロックチェーンになります。

**作者:**dYdX

コンパイル: IBCL

dYdX Chain V4 は dYdX プロトコルの最新版であり、オープンソース ソフトウェアで構成されます。現在運用されているバージョンは v3 と呼ばれ、v3 と dYdX の過去のバージョンの中核には、クラウドでホストされる集中サービスと組み合わせて既存のチェーンにデプロイされたスマート コントラクトがあります。

v4 は、完全に分散化されたオフチェーンのオーダーブックとマッチング エンジンを備えた独立した L1 ブロックチェーンになります。 dYdX チェーンは、Cosmos SDK と CometBFT PoS コンセンサス プロトコルに基づいています。

v4 メインネットの立ち上げが近づくにつれて、dYdX チームが構築しているものを垣間見ていただきたいと思いました。この記事では、v4 アーキテクチャの概要を説明します。 v4 はまだ開発中であるため、変更される可能性があります。

v4 システム アーキテクチャ

dYdX v4 は、エンドツーエンドで完全に分散化されるように設計されています。主なコンポーネントには、プロトコル、インデクサー、フロントエンドが広く含まれます。これらの各コンポーネントはオープンソース ソフトウェアとして提供されます。 dYdX Trading Inc. はコンポーネントを実行しません。

＃＃＃ 合意

このプロトコルは、CometBFT 上に構築され、CosmosSDK を使用する L1 ブロックチェーンです。ノード ソフトウェアは Go で書かれ、単一のバイナリにコンパイルされます。すべての CosmosSDK ブロックチェーンと同様に、v4 はプルーフ オブ ステーク コンセンサス メカニズムを使用します。

このプロトコルはノードのネットワークによってサポートされます。ノードには次の 2 種類があります。

• バリデーター: バリデーターは、注文をメモリー内のオーダーブックに保存し (つまり、オフチェーンでコンセンサスにコミットせずに)、他のバリデーターにトランザクションを噂し、コンセンサスプロセスを通じて dYdX チェーンの新しいブロックを生成する責任があります。コンセンサスプロセスでは、バリデーターが順番に重み付きラウンドロビン方式で新しいブロックの提案者になります（ノードにステークされたトークンの量によって重み付けされます）。提案者は、次のブロックのコンテンツを提案する責任があります。注文が一致すると、提案者はそれを提案されたブロックに追加し、コンセンサスラウンドを開始します。 2/3 以上のバリデーター (ステーク ウェイトに基づく) が承認した場合、ブロックはコミットされたとみなされ、ブロックチェーンに追加されます。ユーザーはトランザクションをバリデーターに直接送信します。
• フル ノード: フル ノードは、コンセンサスに参加しない v4 アプリケーションを実行するプロセスを表します。これはステーク ウェイトが 0 のノードであり、提案の提出も投票も行いません。ただし、フルノードはバリデーターのネットワークに接続し、トランザクションのゴシップに参加し、新しく送信された各ブロックを処理します。フルノードには、dYdX チェーンとその履歴の完全なビューがあり、インデクサーをサポートするように設計されています。関係者によっては、(パフォーマンスまたはコスト上の理由から) 独自のフル ノードやインデクサーを実行することを決定する場合があります。

インデクサー

インデクサーは読み取り専用サービスのコレクションであり、その目的は、より効率的かつ Web2 に適した方法でブロックチェーン データのインデックスを作成し、ユーザーに提供することです。これは、v4 フル ノードからのリアルタイム データを使用してデータベースに保存し、WebSocket および REST リクエストを介してエンド ユーザーがそのデータを利用できるようにすることで実現されます。

v4 プロトコル自体は、一部の基本的なオンチェーン データに関するサービス クエリにエンドポイントを公開できますが、バリデータとフル ノードが効率的に処理するように最適化されていないため、これらのクエリは遅くなる傾向があります。さらに、バリデーターへの過剰なクエリは、コンセンサスに参加する能力を損なう可能性があります。このため、多くの Cosmos バリデーターは、運用環境ではこれらの API を無効にすることを好みます。このため、インデクサーとフル ノードをバリデーターとは別に構築して維持することが重要です。

インデクサーは、オンチェーン データ ストレージに Postgres データベースを、オフチェーン データ ストレージに Redis を、オンチェーン/オフチェーン データの消費とさまざまなインデクサー サービスへのストリーミングに Kafka を使用します。

＃＃＃ フロントエンド

エンドツーエンドの分散エクスペリエンスを構築するために、dYdX は、Web アプリケーション、iOS アプリケーション、Android アプリケーションという 3 つのオープンソース フロントエンドを構築しています。

• Web アプリケーション: Web サイトは Java と React を使用して構築されます。 Web サイトは API を介して Indexer と対話し、オフチェーンのオーダーブック情報を取得し、取引をオンチェーンに直接送信します。 dYdX は、フロントエンド コード ベースと関連する展開スクリプトをオープンソース化します。これにより、IPFS/Cloudflare ゲートウェイを介して、誰でも簡単に dYdX フロントエンドを自分のドメイン/ホスト型ソリューションに/からデプロイしてアクセスできるようになります。
• モバイル: iOS アプリと Android アプリは、それぞれネイティブの Swift と Kotlin を使用して構築されます。モバイル アプリは、Web アプリと同じ方法でインデクサーと対話し、トランザクションをチェーンに直接送信します。モバイル アプリケーションもオープン ソースとなるため、誰でもモバイル アプリケーションを App Store または Play ストアにデプロイできるようになります。特にアプリ ストアの場合、デプロイヤはアプリの送信プロセスを完了するために開発者アカウントと Bitrise アカウントを持っている必要があります。

注文のライフサイクル

dYdX v4 の各コンポーネントについて理解が深まったので、注文時にすべてがどのように組み合わされるかを見てみましょう。 v4 で注文を行う場合、次のプロセスに従います。

1. ユーザーは分散フロントエンド (Web サイトなど) または API 経由で取引します。
2. 注文はバリデーターにルーティングされます。そのバリデーターは、他のバリデーターやフルノードにトランザクションについて噂話をし、注文帳を新しい注文で更新します。
3. コンセンサスプロセスにより、バリデーターが提案者として選択されます。選択されたバリデーターは順序と一致し、次に提案されたブロックに追加されます。
4. 提案されたブロックは合意プロセスを経て続行されます。 a. バリデーターの 2/3 がブロックの確認に投票した場合、ブロックはコミットされ、すべてのバリデーターとフルノードのオンチェーン データベースに保存されます。 b. 提案されたブロックが 2/3 しきい値に達しない場合、ブロックは拒否されます。
5. ブロックがコミットされた後、更新されたオンチェーン (およびオフチェーン) データがフル ノードからインデクサーにストリーミングされます。次に、インデクサーは、API および Websocket を介して、このデータをフロントエンドやこのデータをクエリする他の外部サービスに提供します。

上記のフローは、注文/データが v4 を介してどのように移動するかの概要です。 v4 メインネットの立ち上げが近づくにつれて、今後のブログ投稿でプロトコル、インデクサー、およびさまざまなフロントエンド インフラストラクチャについてさらに詳しく掘り下げていきます。