マッチング

マッチングはカーネル実行の内部にあるステージであって、チェーンが呼び出すサービスではありません。ブロックの注文をコミットされた順序で受け取り、板に突き合わせ、約定を生み出します。誰の残高も動かしません。それはクリアリングハウスの仕事で、マッチングが完了したあとに行われます。 この二つを分けておくことが、エンジンをテスト可能にしています。マッチングが答えるのは何が何と約定したかです。クリアリングハウスが答えるのはそれにいくらかかり、誰が誰にいくら支払うことになったのかです。

​

板の構造

銘柄ごとに専用の板があり、協調する三つの構造としてメモリ上に保持されます。 注文はslab arenaに置かれます。確保と解放が定数時間の、事前確保された領域です。そのため板の操作はホットパスでメモリを確保せず、解放されたスロットは、アロケータが置いた場所任せではなく決まった順序で再利用されます。この最後の点は性能上の選択ではありません。二つのバリデータがスロットを異なる順序で再利用したら、スロット配置を観測するものはすべて食い違うからです。 同じ規律が注文インデックスにも当てはまります。シードはランダムではなく固定です。プロセスごとにシードを変えるハッシュマップは衝突攻撃に対する標準的な防御ですが、コンセンサスの実行経路上では、それはフォークです。 価格は全面的に整数で、小数ではなくサブティック単位です。それが実際に送信する値とどう対応するかは精度を参照してください。

​

優先順位

優先順位はまず価格、次にその価格でのチェーン内の位置です。「時間」とは、ノードに到着した時刻ではなく、コミットされたブロック内での注文の正規の位置を指します。 これがブロック内のレイテンシ競争を取り除きます。同じブロック内の二つの注文には、どのバリデータも同一に計算する明確な優劣があり、特定のノードにどれだけ近くてもそれは変わりません。ブロックとブロックの間では到着順は依然として意味を持ちますが、競争の単位はマイクロ秒ではなくブロックです。 カーネルのステージ順序がこれを補強します。ブロック内では取り消しがテイカー注文の発注より先に実行されるため、取り消しと同じブロックに届いた注文が板の気配を奪うことはできません。

​

注文のマッチング

マッチャーは反対側の先頭を繰り返し消費し、取ったメイカーごとに約定を出力します。これを、到来した注文を使い切るか板が交差しなくなるまで続けます。残数量がどうなるかは有効期間が決めます。

• GTC — 残数量を板に置きます。
• IOC — 残数量を取り消します。
• FOK — 全数量を約定できない場合、何も執行されません。
• ALO — ポストオンリー。流動性を取りにいく注文は、交差させずに拒否されます。

約定は生成される時点で帰属情報を持ちます。各約定は、その銘柄の約定列の中で自分がどこに位置するかを記録し、銘柄ごとのその位置は、出力を組み立てる際にブロック全体でのひとつの順序へ解決されます。これによって、あとからイベントを、それを引き起こした正確なトランザクションと、ブロック内の正確な地点まで辿れます。

​

セルフトレード防止

到来した注文が、同一の保有者が板に置いている流動性と約定しそうになった場合、その約定は執行されずに抑止されます。どちらの側が譲るかは設定できます。 この方法で取り消されたメイカー注文はマッチング中に集められ、同じブロックの一部として除去されます。そのため板が、すでに抑止された注文を抱え続けることはありません。 このチェックにおける保有者の同一性は、板が追跡しているアカウントの単位で判定されます。取引側から見た説明はセルフトレード防止を参照してください。

​

マッチングがやらないこと

手数料の計算も、損益の実現も、ポジションの調整も、証拠金のチェックもしません。それらはマッチングのあと、マッチングが生んだ約定を起点としてクリアリングハウスで行われます。 そもそもその注文が許されるものだったのかも判断しません。証拠金の十分性、未約定注文数の上限、リデュースオンリーの制約、成行から指値への変換は、注文が板に到達する前に解決されます。マッチャーが注文を見る時点で残っている問いは、それが板のどこに属するかだけです。

​

次に読む