> ## Documentation Index > Fetch the complete documentation index at: https://docs.0x.one/llms.txt > Use this file to discover all available pages before exploring further. # エンジンアーキテクチャ > 0x1のRustベースのミラートレードエンジンに関するテクニカルホワイトペーパー。レガシーなコピートレードシステムに見られるシリアル実行とスリッページの問題点と対比しながら解説します。 ## 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つの不変条件を目標とします。 | 不変条件 | 定義 | | ------------------ | ------------------------------------------------------------ | | **低レプリケーションレイテンシ** | フォロワーの約定中央値がミラートレーダーの約定から1秒以内に収まる。 | | **スリッページの上限管理** | フォロワーの約定が設定済みスリッページ許容値を超えない。 | | **プロポーショナルサイジング** | フォロワーのポジションデルタは、絶対サイズを複製するのではなく、ミラートレーダーのマージンデルタに対する固定割合とする。 | | **障害の分離** | あるミラートレーダーパイプラインまたはフォロワーアカウントの障害が、他のいかなる処理もブロックしない。 | ## 3. アーキテクチャ ### 3.1 ランタイム ホットパスはRustで実装されており、[Tokio](https://tokio.rs)非同期ランタイム上で動作します。各ミラートレーダーは独立したスーパーバイザータスクによって処理され、各フォロワーのサブスクリプションはTokioエグゼキュータ上で協調的にスケジュールされる軽量タスクです。エンジンはクリティカルパス上で同期ロックを一切保持しません — すべての状態受け渡しは有界MPSCチャネルを使用し、バックプレッシャーは明示的に管理されます。 ### 3.2 トレーダーごとの並行パイプライン フォローされているすべてのトレーダーは、アウトバウンドシグナルチャネルのみを共有する3つの並行ストリームで動作します。 ```mermaid theme={"system"} flowchart LR subgraph Leader pipeline OB["Orderbook stream
(WebSocket)"] UA["User-account stream
(WebSocket)"] EX["Executor task"] end UA -->|fill event| SG["Signal generator"] OB -->|top-of-book| SG SG --> RG["Risk guard"] RG -->|sized & validated| FA["Parallel fanout"] FA -. task .-> F1["Follower A
signer task"] FA -. task .-> F2["Follower B
signer task"] FA -. task .-> F3["Follower C
signer task"] ``` オーダーブックストリームとユーザーアカウントストリームは独立した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. 比較分析 | プロパティ | レガシーシリアル | 0x1エンジン | | ---------------- | ----------------------- | --------------- | | k番目のフォロワー約定 | $O(k \cdot \text{RTT})$ | $O(\text{RTT})$ | | 最後のフォロワー @ N=500 | ≈ 20秒 | ≈ 1秒 | | シグナル検出 | RESTポーリング | WebSocketプッシュ | | プロパティ | レガシーシリアル | 0x1エンジン | | ------------- | -------- | ----------- | | 送信前チェック | なし | オーダーブック再読 | | スリッページ上限 | 暗黙的・無制限 | フォロワーごとに明示的 | | 後発フォロワーのPnL歪み | 強い左裾 | 許容値による上限管理 | | プロパティ | レガシーシリアル | 0x1エンジン | | ------------ | --------- | -------------- | | フォロワー間ブロッキング | あり | なし（タスクごと） | | リーダー間ブロッキング | あり（共有ループ） | なし（スーパーバイザーごと） | | 不正注文の封じ込め | バッチ全体が停止 | 単一タスクのみ失敗 | | プロパティ | レガシーシリアル | 0x1エンジン | | ---------- | ----------- | ------------------ | | サーバー上のキー素材 | 平文 / KMSバック | 暗号化エージェントキーのみ | | 署名スコープ | スコープなし | EIP-712スコープ付きペイロード | | 失効権限 | プラットフォーム側 | フォロワー側 | ## 5. 運用上のエッジケース スーパーバイザーは自動的にポジションをクローズしません。フォロワーのオープンポジションは、ミラートレーダーがクローズするか、フォロワーがダッシュボードから手動でクローズするまでオープンのままです。エンジンは不在から意図を推測しません。 リスクガードは注文が署名される前に`MarginBreach`スキップを返します。フォロワーの代わりにレバレッジによる追加投入が行われることはありません。アクティビティログには、試みられたサイズと設定上限とともにブリーチが記録されます。 各フォロワー接続は独自のトークンバケットレートリミッターを持ちます。フォロワーがバケットに達した場合、そのフォロワーのタスクのみがバックプレッシャーを受けます。他のフォロワーや他のミラートレーダーには影響しません。 シグナルジェネレーターは各部分約定に対してインクリメンタルな`MirrorIntent`メッセージを発行します。フォロワーのサイジングは、各発行時に新しいミラートレーダーのマージンデルタに対して再計算されます。 ## 6. 結論 レガシーなコピートレードスタックは、バッチ指向、RESTポーリング、シングルスレッドという前提の産物であり、現代の無期限先物取引所とは相容れません。0x1エンジンはそのスタックを、プッシュ駆動、トレーダーごとの並行、オーダーブックを意識した設計で置き換えます。追加フォロワー1人あたりのコストはRTTではなくタスクハンドルです。その結果、フォロワーの実現PnL分布がミラートレーダーのPnLを有界かつ明示的な乖離で追跡するレプリケーション基盤が実現され、1つのアカウントの悪い局面が次のアカウントの危機になることはありません。 エンジンはノンカストディアルです。フォロワーの残高はすべてAster上に保持され、すべての署名にはフォロワーがいつでも失効させられるフォロワースコープのエージェントキーを使用します。