Nonces und API-Wallets

Grundlagen

Eine dezentrale L1 muss Replay-Angriffe verhindern. Wenn ein Nutzer eine USDC-Übertragungstransaktion signiert, kann der Empfänger sie nicht mehrfach senden, um die Wallet des Absenders zu leeren. Zur Lösung speichert Ethereum für jede Adresse eine "nonce", eine Zahl, die bei 0 beginnt. Jede Transaktion muss genau "nonce + 1" verwenden, um aufgenommen zu werden.

API-Wallets

Diese werden in der Dokumentation auch als agent wallets bezeichnet. Ein Master-Konto kann API-Wallets autorisieren, im Namen des Master-Kontos oder eines der Subkonten zu signieren.

Beachten Sie, dass API-Wallets ausschließlich zum Signieren dienen. Um die Kontodaten eines Master- oder Subkontos abzufragen, müssen Sie die tatsächliche Adresse dieses Kontos übergeben. Ein häufiger Fehler ist die Verwendung der Agent-Wallet, was zu einem leeren Ergebnis führt.

Bereinigung von API-Wallets

API-Wallets und ihr zugehöriger Nonce-Zustand können in den folgenden Fällen bereinigt werden:

1. Die Wallet wird abgemeldet. Dies geschieht bei einer bestehenden unbenannten API-Wallet, wenn eine ApproveAgent-Aktion gesendet wird, um eine neue unbenannte API-Wallet zu registrieren. Dies geschieht auch bei einer bestehenden benannten API-Wallet, wenn eine ApproveAgent-Aktion mit übereinstimmendem Namen gesendet wird.
2. Die Wallet läuft ab.
3. Das Konto, das den Agenten registriert hat, hat kein Guthaben mehr.

Wichtig: Wer API-Wallets programmatisch verwendet, sollte ihre Adressen dringend nicht wiederverwenden. Sobald ein Agent abgemeldet wird, kann sein verwendeter Nonce-Zustand bereinigt werden. Erzeugen Sie bei künftiger Verwendung eine neue Agent-Wallet, um unerwartetes Verhalten zu vermeiden. So können beispielsweise zuvor signierte Aktionen erneut abgespielt werden, sobald der Nonce-Satz bereinigt wurde.

Hyperliquid-Nonces

Das Design von Ethereum funktioniert nicht für ein On-Chain-Orderbuch. Eine Market-Making-Strategie kann innerhalb einer Sekunde Tausende von Orders und Stornierungen senden. Die Anforderung einer exakten Reihenfolge der Aufnahme in die Blockchain würde jede Strategie unmöglich machen.

Auf Hyperliquid werden die 100 höchsten Nonces pro Adresse gespeichert. Jede neue Transaktion muss eine Nonce aufweisen, die größer ist als die kleinste Nonce in dieser Menge, und darf zudem noch nie zuvor verwendet worden sein. Nonces werden pro Signer verfolgt, also der Nutzeradresse, wenn mit dem privaten Schlüssel der Adresse signiert wird, bzw. der Agent-Adresse, wenn mit einer API-Wallet signiert wird.

Nonces müssen innerhalb von (T - 2 days, T + 1 day) liegen, wobei T der Unix-Millisekunden-Zeitstempel auf dem Block der Transaktion ist.

Die folgenden Schritte können helfen, eine automatisierte Strategie von einer zentralisierten Börse zu übertragen:

1. Verwenden Sie eine API-Wallet pro Handelsprozess. Beachten Sie, dass Nonces pro Signer (d. h. privatem Schlüssel) gespeichert werden, sodass getrennte Subkonten, die von derselben API-Wallet signiert werden, denselben Nonce-Tracker der API-Wallet nutzen. Es wird empfohlen, für verschiedene Subkonten getrennte API-Wallets zu verwenden.
2. Richten Sie in jedem Handelsprozess eine Aufgabe ein, die Order- und Stornierungsanfragen alle 0.1 Sekunden periodisch bündelt. Es wird empfohlen, IOC- und GTC-Orders getrennt von ALO-Orders zu bündeln, da Batches mit ausschließlich ALO-Orders von den Validatoren bevorzugt behandelt werden.
3. Die Aufgaben der Handelslogik senden Orders und Stornierungen an die Bündelungsaufgabe.
4. Rufen Sie für jeden Batch von Orders oder Stornierungen einen atomaren Zähler ab und erhöhen Sie ihn, der eine eindeutige Nonce für die Adresse sicherstellt. Der atomare Zähler kann bei Bedarf auf die aktuellen Unix-Millisekunden vorgerückt werden.

Diese Struktur ist robust gegenüber Transaktionen, die innerhalb von 2 Sekunden in falscher Reihenfolge eintreffen, was für eine automatisierte Strategie in geografischer Nähe zu einem API-Server ausreichen sollte.

Empfehlungen für Nutzer von Subkonten und Vaults

Beachten Sie, dass Nonces pro Signer gespeichert werden, also der Adresse des privaten Schlüssels, mit dem die Transaktion signiert wird. Daher wird empfohlen, dass jeder Handelsprozess bzw. jede Frontend-Sitzung einen eigenen privaten Schlüssel zum Signieren verwendet. Insbesondere teilen sich eine einzelne API-Wallet, die für einen Nutzer, einen Vault oder ein Subkonto signiert, denselben Nonce-Satz.

Wenn Nutzer mehrere Subkonten parallel verwenden möchten, ist es einfacher, zwei getrennte API-Wallets unter dem Master-Konto zu erzeugen und für jedes Subkonto eine eigene API-Wallet zu verwenden. Dies vermeidet Kollisionen zwischen den von den einzelnen Subkonten verwendeten Nonce-Sätzen.