見た目以上に効いてくる理由
送信がタイムアウトした場合を考えます。チェーンに届いたのかどうかは分かりません。クライアント注文IDがなければ、直近の注文を照会してマーケット・売買方向・価格・数量から推測するか、何もせずに祈るかの二択です。 識別子があれば、この曖昧さは消えます。自分で生成した識別子で取り消しを出すだけです。注文が存在していれば取り消され、届いていなければ取り消しは何も見つけません。どちらの場合も既知の状態で終わります。人が張り付いていない状態で動くシステムに本当に必要なのは、これです。 突合が現実的になるのも同じ理由です。自分側の記録は自分が付けた識別子をキーにしているため、自分の状態とチェーン側の状態を突き合わせる作業は、推測ではなく単純な参照になります。フォーマット
識別子は16バイトの値で、0xから始まる32文字の小文字16進文字列として送信します。
- 小文字のみ。大文字の16進数は正規化されず、拒否されます。
- 長さは厳密。これより短くても長くても拒否されます。
- オールゼロは予約済み。
0x00000000...0000は「未指定」を表すセンチネル値であり、識別子としては使えません。
一意性
一意性のスコープはサブアカウントです。署名アドレスと、その配下のサブアカウントの組み合わせが単位になります。 ここから二つの帰結が出ます。同一アドレス配下の異なるサブアカウントは、同じ識別子を衝突なく使えます。それぞれが独自にIDを生成する独立した戦略を走らせる場合に便利です。一方、同じサブアカウントの中で、有効な注文が使っている識別子を再利用すると、置き換えではなくエラーになります。識別子は連番ではなくランダムに生成してください。カウンターは順序が見える点で魅力的ですが、再起動でカウンターを失うと、まだ有効な注文と衝突します。16バイトのランダム値なら、実用上まず衝突しません。
識別子でできること
識別子が残る期間
識別子はセッションではなく注文に属します。注文が約定または取り消された後も照会でき、これが事後の突合に役立ちます。 その注文が有効でなくなった時点で、識別子は再利用可能になります。ただし実務上、再利用する理由はほとんどありません。新しいランダム値の生成にコストはかからず、履歴上のレコードがどの注文を指すのかという疑問も残りません。次に読む
注文の変更
有効な注文を変更したとき、識別子がどうなるのかです。
注文タイプ
識別子を付けられる注文の種類です。
開発者向け
注文の送信と、曖昧なレスポンスをコードで扱う方法です。
トランザクションの順序付け
同じブロックで送った取り消しが、テイカー注文より先に実行される理由です。