エンジンアーキテクチャ

​

Abstract

0x1はRustネイティブのミラートレードエンジンを運用しています。このエンジンは、ミラートレーダーの約定を多様なフォロワーアカウント群へサブセカンドのレイテンシ、スリッページ上限管理、アカウントごとのリスク分離を維持しながらレプリケートするよう設計されています。本ドキュメントでは当該エンジンのアーキテクチャを詳述し、従来のコピートレードスタックに見られるシリアル実行とスリッページ無制限のパターンとの比較を行います。以下の設計選択 — トレーダーごとの並行パイプライン、並列ファンアウト、オーダーブックを意識した事前チェック、ノンカストディアルなEIP-712署名 — が、0x1においてミラートレーダーからフォロワーへのレプリケーション遅延を最小化し、フォロワーが期待するPnL形状を維持するためのメカニズムです。

​

1. 問題の定義：レガシーなコピートレード

多くの既存コピートレード実装は、高頻度デリバティブ取引所向けには設計されていないアーキテクチャを継承しています。その結果として生じる実行上の問題は、以下の4つのカテゴリに繰り返し現れます。

​

1.1 シリアルな注文配置

レガシーシステムはシングルスレッドのループでフォロワーを逐次処理します。ミラートレーダーが約定すると、システムはN人のフォロワーを列挙し、次へ進む前に各HTTPラウンドトリップと取引所の応答をブロックしながら注文を順番に送信します。定常状態において、k番目のフォロワーの約定時刻はおよそ以下のようになります。 $$t_k \approx t_{\text{leader}} + k \cdot (t_{\text{rtt}} + t_{\text{match}})$$ N = 500のフォロワー、30msのラウンドトリップ、10msのマッチング遅延の場合、最後のフォロワーはミラートレーダーより20秒遅れて約定します — 無期限先物取引所においては致命的な遅延です。

​

1.2 スリッページの無制限拡大

注文はミラートレーダーのノーショナルに基づいてサイズが決定され、約定時に成行注文として送信されるため、後発のフォロワーは自身のオーダーブックを繰り返し掘り進めることになります。各約定は徐々に悪化した価格で流動性を消費し、実現スリッページがフォロワーのスリッページ許容値を超えた際にファンアウトを停止するフィードバックループが存在しません。同一のミラートレーダートレードが、フォロワー間で強い左裾分布を持つPnL分布を生み出します。

​

1.3 ポーリングベースのシグナル検出

多くのシステムは、ユーザーデータストリームを購読するのではなく、数秒ごとに取引所のREST APIをポーリングしてミラートレーダーのアクティビティを検出しています。そのため、ミラートレーダーの約定はすでに陳腐化したタイムスタンプでレプリケーションパイプラインに入り、上記のキューイング遅延をさらに悪化させます。

​

1.4 障害の連鎖

シリアルループ内で1つの不正な注文、レートリミットブロック、またはHTTPタイムアウトが発生すると、後続のすべてのフォロワーが停止します。あるミラートレーダーのパイプラインと別のパイプラインを分離するバルクヘッドが存在せず、1つのアカウントの問題が次のアカウントへ波及することを防ぐフォロワーごとのサーキットブレーカーもありません。

​

2. 0x1エンジン：設計目標

0x1エンジンは4つの不変条件を目標とします。

​

3. アーキテクチャ

​

3.1 ランタイム

ホットパスはRustで実装されており、Tokio非同期ランタイム上で動作します。各ミラートレーダーは独立したスーパーバイザータスクによって処理され、各フォロワーのサブスクリプションはTokioエグゼキュータ上で協調的にスケジュールされる軽量タスクです。エンジンはクリティカルパス上で同期ロックを一切保持しません — すべての状態受け渡しは有界MPSCチャネルを使用し、バックプレッシャーは明示的に管理されます。

​

3.2 トレーダーごとの並行パイプライン

フォローされているすべてのトレーダーは、アウトバウンドシグナルチャネルのみを共有する3つの並行ストリームで動作します。 オーダーブックストリームとユーザーアカウントストリームは独立したWebSocketサブスクリプションであるため、ミラートレーダーの約定はポーリングサイクルではなくプッシュパスで検知されます。シグナルジェネレーターは、次のREST tickを待つことなく、Asterが約定を公開した瞬間に型付きのMirrorIntentを生成します。

​

3.3 並列ファンアウト

ファンアウトステップは、対象となるすべてのフォロワーに対してFuturesUnorderedとして実装されています。各フォロワーは独自の署名者と、Asterへの独自のアウトバウンドHTTP接続を持つ独立したTokioタスクです。k番目のフォロワーが(k-1)番目を待つ必要はなく — すべての署名、リスクチェック、注文送信が並行して実行されます。 シリアルモデルでは最後のフォロワーのレイテンシがNに対して線形に増加しましたが、0x1モデルではNに対して対数的に増加し（スケジューラ＋コネクションプール上限による）、単一のRTTが支配的となります。 $$t_k \approx t_{\text{leader}} + t_{\text{rtt}} + t_{\text{match}} \quad \forall k \text{（並行性上限まで）}$$

​

3.4 オーダーブックを意識した事前チェック

フォロワータスクが注文を送信する前に、リスクガードがライブのオーダーブックスナップショットを再読し、フォロワーの設定済みスリッページ許容値に対する期待約定を計算します。許容値を超える注文は送信されずスキップされます — そのスキップは構造化された理由コードとともにフォロワーのアクティビティログに記録されます。500人のフォロワーが順番に自身のオーダーブックを掘り進めるというレガシーの障害モードは、期待マークが上限を超えた時点で注文が送信されないため、発生し得ません。

​

3.5 プロポーショナルサイジング

フォロワーのサイズは、フォロワーの設定済みアロケーションとミラートレーダーのマージンデルタの関数です。 $$\text{size}_{\text{follower}} = \text{size}_{\text{leader}} \cdot \frac{\text{alloc}_{\text{follower}}}{\text{margin}_{\text{leader}}}$$ フォロワーのレバレッジ上限とAsterの最小注文サイズによってクランプされます。エンジンは絶対ノーショナルを複製するのではなく、ミラートレーダーのリスクコミットメントの形状をフォロワーのバランスシートに反映させます。

​

3.6 ノンカストディアル署名

エンジンはホットパスでフォロワーの秘密鍵をそのまま参照することはありません。各フォロワーは、取引アカウントにスコープされたEIP-712 ECDSAペイロードに署名するエージェントキーをプロビジョニングします。エージェントキーは保存時に暗号化され、必要に応じてローテーションされます。フォロワーはAsterの残高とエージェントを承認するマスターキーの両方のカストディを保持します。

​

4. 比較分析

​

5. 運用上のエッジケース

​

6. 結論

レガシーなコピートレードスタックは、バッチ指向、RESTポーリング、シングルスレッドという前提の産物であり、現代の無期限先物取引所とは相容れません。0x1エンジンはそのスタックを、プッシュ駆動、トレーダーごとの並行、オーダーブックを意識した設計で置き換えます。追加フォロワー1人あたりのコストはRTTではなくタスクハンドルです。その結果、フォロワーの実現PnL分布がミラートレーダーのPnLを有界かつ明示的な乖離で追跡するレプリケーション基盤が実現され、1つのアカウントの悪い局面が次のアカウントの危機になることはありません。