ナンスとAPIウォレット

背景

非中央集権型L1はリプレイ攻撃を防止しなければなりません。ユーザーがUSDC送金トランザクションに署名した場合、受信者がそれを複数回ブロードキャストして送信者のウォレットを枯渇させることはできないようにする必要があります。これを解決するため、Ethereumは各アドレスごとに0から始まる数値である「nonce」を保存します。各トランザクションは、含まれるためにはちょうど「nonce + 1」を使用しなければなりません。

APIウォレット

ドキュメントでは agent wallets とも呼ばれます。マスターアカウントは、マスターアカウントまたはサブアカウントのいずれかに代わって署名するAPIウォレットを承認できます。

APIウォレットは署名のためだけに使用されることに注意してください。マスターアカウントまたはサブアカウントに関連付けられたアカウントデータを照会するには、そのアカウントの実際のアドレスを渡す必要があります。よくある落とし穴は、エージェントウォレットを使用してしまい、空の結果が返されることです。

APIウォレットのプルーニング

APIウォレットとそれに関連付けられたノンス状態は、以下の場合にプルーニングされることがあります：

ウォレットが登録解除された場合。これは、新しい無名のAPIウォレットを登録するApproveAgentアクションが送信されたときに、既存の無名のAPIウォレットに対して発生します。また、一致する名前を持つApproveAgentアクションが送信されたときに、既存の名前付きAPIウォレットに対しても発生します。
ウォレットが期限切れになった場合。
エージェントを登録したアカウントにもう資金がない場合。

重要： プログラム的にAPIウォレットを使用する方は、そのアドレスを再利用しないことを強く推奨します。エージェントが登録解除されると、その使用済みノンス状態はプルーニングされる可能性があります。予期しない動作を避けるため、今後の使用では新しいエージェントウォレットを生成してください。例えば、ノンスセットがプルーニングされると、以前に署名されたアクションがリプレイされる可能性があります。

Hyperliquidのナンス

Ethereumの設計は、オンチェーンのオーダーブックには機能しません。マーケットメイキング戦略は1秒間に何千もの注文とキャンセルを送信する可能性があります。ブロックチェーンへの包含の正確な順序付けを要求すると、どのような戦略でも破綻します。

Hyperliquidでは、アドレスごとに最高100個のノンスが保存されます。新しいトランザクションごとに、ノンスはこのセット内の最小のノンスより大きく、かつ一度も使用されたことのないものでなければなりません。ノンスはシグナーごとに追跡されます。シグナーとは、アドレスの秘密鍵で署名した場合はユーザーアドレス、APIウォレットで署名した場合はエージェントアドレスです。

ノンスは (T - 2 days, T + 1 day) の範囲内でなければなりません。ここで T はトランザクションのブロック上のunixミリ秒タイムスタンプです。

以下の手順は、中央集権型取引所から自動化戦略を移行する際に役立つ可能性があります：

トレーディングプロセスごとに1つのAPIウォレットを使用してください。ノンスはシグナー（すなわち秘密鍵）ごとに保存されるため、同じAPIウォレットで署名された別々のサブアカウントは、そのAPIウォレットのノンストラッカーを共有することに注意してください。異なるサブアカウントには別々のAPIウォレットを使用することをお勧めします。
各トレーディングプロセス内で、0.1秒ごとに注文とキャンセルのリクエストを定期的にバッチ処理するタスクを用意してください。ALOのみの注文バッチはバリデーターによって優先されるため、IOCおよびGTC注文はALO注文とは別々にバッチ処理することをお勧めします。
取引ロジックのタスクは、注文とキャンセルをバッチ処理タスクに送信します。
注文またはキャンセルの各バッチについて、アドレスに対して一意のノンスを保証するアトミックカウンターを取得してインクリメントしてください。アトミックカウンターは、必要に応じて現在のunixミリ秒に早送りできます。

この構造は2秒以内のトランザクションの順序入れ替わりに対してロバストであり、APIサーバーに地理的に近い自動化戦略には十分であるはずです。

サブアカウントとボールトユーザーへの提案

ノンスはシグナーごと、すなわちトランザクションへの署名に使用された秘密鍵のアドレスごとに保存されることに注意してください。したがって、各トレーディングプロセスまたはフロントエンドセッションが、署名用に別々の秘密鍵を使用することをお勧めします。特に、単一のAPIウォレットがユーザー、ボールト、またはサブアカウントのために署名する場合、すべて同じノンスセットを共有します。

複数のサブアカウントを並行して使用したい場合は、マスターアカウントの下に2つの別々のAPIウォレットを生成し、各サブアカウントに1つのAPIウォレットを使用する方が簡単です。これにより、各サブアカウントが使用するノンスセット間の衝突が回避されます。