dYdXのv4 取引注文はどのように処理されるのか？バリデーター、フロントエンド、インデクサーの役割を解説
v4 (dYdXチェーン）は、今秋ローンチ予定のdYdXProtocolの新たなバージョンであり、オープンソースのソフトウェアで構成されることになります。現在のバージョン（v3）とそれ以前のバージョンは、イーサリアムなど既存のチェーン上でスマートコントラクトを展開し、クラウドを通して中央集権的なサービスを提供していました。対照的にv4は、単独で存在するレイヤー1（L1）のブロックチェーンです。完全に分散化したオフチェーンの取引板とマッチングエンジンを実現します。dYdXチェーンは、Cosmos SDKとCometBFT PoSコンセンサスプロトコルを基盤に構築されます。
v4のメインネットローンチが近づく中、dYdXトレーディングチームが作っているプロダクトについて少しずつお伝えしていきたいと考えています。今回は、v4のアーキテクチャについてです。v4は開発中であるため今回の内容に変更が加えられる可能性がある点は留意ください。
v4のアーキテクチャ
dYdX v4は完全な分散化を実現するように設計されています。主な要素は、プロトコル、インデクサー、フロントエンドです。それぞれの要素は、オープンソースのソフトウェアとして公開されます。どの要素もdYdXトレーディング社によって管理されることはありません。
プロトコル（もしくはアプリケーション）
プロトコルはCosmos SDKとCometBFT PoSを使って構築されるL1のブロックチェーンです。ノードのソフトウェアはGoで書かれ、シングルバイナリにまとめられます。全てのCosmos SDK基盤のブロックチェーンと同様に、v4はPoSのコンセンサスメカニズムを採用します。
プロトコルは、ノードのネットワークによってサポートされます。ノードには2つのタイプがあります。
バリデーター
取引注文をインメモリ（コンピューターで扱うデータを主にメモリー上に格納し、処理の高速化を図るデータベース）で保管し、他のバリデーターに対して取引を"ささやき"（Gossipping）、コンセンサスを通じてdYdXチェーンに新たなブロックを作る役割を担います。インメモリは、オフチェーンでコンセンサスにコミットしない状態を指します（マッチした注文のみがオンチェーンにアップロードされます）。
コンセンサスプロセスにおいてバリデーターは、ノードにステークするトークン量に応じて（加重ラウンドロビン・スケジューリングで）新しいブロックの提案を順番で行います。提案者は次のブロックのコンテンツ生成の責任を持ちます。取引注文がマッチングしたら、提案者はその取引記録をブロックに追加し、コンセンサスにかけます。もし2/3以上のバリデーター（ステーキング量で測って）がブロックを承認したら、そのブロックはブロックチェーンに追加されます。
フルノード
フルノードは、v4プロトコルの一部を形成していますが、コンセンサス形成プロセスには参加しません。ステーキング量がゼロのノードであり、提案や投票に参加することもありません。しかし、フルノードは、バリデーターのネットワークと繋がっており、取引のささやきに参加したり承認済みのブロックを処理したりします。フルノードは、dYdXチェーンの全ての取引記録を持つことになり、後述するインデクサーのサポート役も担います。
インデクサー
インデクサーは、ユーザーに対してブロックチェーンデータを効率的な方法で届ける目的を持つ読み取り専用のサービスです。フルノードからリアルタイムでデータを獲得・保存し、ウェブソケットとRESTのリクエストを通じて上記のサービスを実行します。
v4プロトコルも上記サービスを実行する能力を保持していますが、バリデーターとフルノードは効率的にそれを処理するように設計されていません。インデクサーとフルノードを分けて構築・維持することは重要です。
インデクサーは、Postgresデータベースを使ってオンチェーンデータ、Redisを使ってオフチェーンデータを保管し、Kafkaを使って双方のデータを多くのインデクサーのサービス向けにストリーミングします。
Front-ends
dYdXは3つのオープンソースのフロントエンドを開発しています。それらは、ウェブのアプリ、iOSアプリ、そしてアンドロイドのアプリです。
ウェブアプリ
JavascriptとReactを使ってウェブサイトは構築されます。APIを通してインデクサーと連携し、オフチェーンの取引板情報を入手し、取引を直接dYdXチェーンに送ります。dYdXはフロントエンドのコードと関連スクリプトをオープソース化します。これにより、誰もが、IPFS/Cloudflareゲートウェイを通じて自身のドメインからdYdXのフロントエンドにアクセスでき、またこれを実装できるようになります。
モバイル
iOSアプリとアンドロイドのアプリは、それぞれSwiftとKotlinで構築されます。モバイルアプリはウェブアプリと同様にインデクサーと連携し、チェーンに対して取引を直接送ります。モバイルアプリもオープンソースであり、誰もがモバイルアプリをApp StoreやPlay Storeに展開できます。とりわけApp Storeに関しては、モバイルアプリを展開する者は、開発者アカウントとBitriseアカウントを保有し、アプリ提出プロセスを通過しなければなりません。
注文はどのように処理されるのか？
上記はdYdX v4の主な要素について解説しました。以下では、一つの取引注文がそれぞれの要素を通して、どのようなプロセスで処理されるのか見てみましょう。
ユーザーは分散化されたフロントエンド（例えばウェブサイト）もしくはAPIを通じて注文を出す（トレードする）。
注文はバリデーターに送られる。該当するバリデーターは該当する取引を取引板に反映するように、他のバリデーターとフルノードに「ささやく」。
コンセンサスプロセスによって一つのバリデーターが提案者として選ばれる。選ばれたバリデーターは注文のマッチングを行い、次のブロックとして追加し提案する。
提案されたブロックは以下のコンセンサスプロセスを通過する。
もし3分の2以上のバリデーターノードがブロック承認すれば、ブロックは全てのバリデーターとフルノードが持つオンチェーンデータベースに保管される。
もし3分の2以上のバリデーターノードが承認しなければ、ブロックは拒否される。
ブロックが承認された後、アップデートされたオンチェーン（とオフチェーン）データはフルノードからインデクサーにストリームされる。インデクサーは、このデータをAPIやウェブソケットを通して、データのクエリを行なったフロントエンドや他の外部サービスに対して提供する。
上記のフローは、v4において取引データがどのように処理されるかを概念レベルで説明したものです。プロトコル、インデクサー、フロントエンドに関しては今後さらに詳細をブログで解説する予定です。
*上記はdYdX Trading社のブログ「v4 Technical Architecture Overview」を翻訳・編集したものです。
この記事が気に入ったらサポートをしてみませんか？