Zum Inhalt springen
Financial Context Wiki

Nonce-Namensräume in Kryptowährungen

Praxisleitfaden zu Ethereum-Account-Nonces, anwendungsspezifischen Replay-Nonces, ERC-4337-Key-Sequence-Lanes und Such-Nonces in Proof-of-Work-Blockheadern.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Eine Nonce ist ein Wert, dessen Bedeutung aus einem bestimmten Protokoll-Namensraum stammt. Sie ist nicht immer eine Zufallszahl oder ein universell „einmal verwendeter“ Wert. Bei Ethereum ordnet und validiert die State-Nonce eines extern kontrollierten Kontos die Transaktionen dieses Absenders. Ein Contract kann getrennte Anwendungs-Nonces für Permits oder signierte Intents im Storage führen. ERC-4337-Smart-Accounts können eine strukturierte UserOperation-Nonce mit parallelen Key- und Sequence-Lanes verwenden. Bei Bitcoins Proof of Work ist die Blockheader-Nonce ein begrenztes Suchfeld für Hash-Kandidaten.

Diese Werte sind nicht austauschbar. Eine Ethereum-Account-Nonce schützt keine beliebige Typed-Data-Signatur, wenn die Anwendung nicht ihren eigenen Domain- und Replay-Wert prüft. Eine PoW-Header-Nonce ordnet keine Account-Transaktionen. Derselbe Zahlenwert bei anderen Absendern, Contracts, Chains oder Lanes beschreibt anderen Zustand.

Funktionsweise

  1. Bestimmen Sie vor dem Lesen den Namensraum: EOA-Transaktion, Contract-Account-State, Anwendungs-Storage, ERC-4337-UserOperation oder benannter PoW-Blockheader. Legen Sie Chain-ID, Fork, Version, Account oder Owner, verifizierenden Contract und Domain, EntryPoint beziehungsweise Headerformat fest.
  2. Lesen Sie autoritativen Zustand an einem ausdrücklichen Block-Tag. Trennen Sie kanonische EOA-Nonce, Pending-Zähler des Providers, nonces(owner) der Anwendung, ERC-4337-Key und -Sequence sowie den lokalen Header-Suchzähler. Übereinstimmende RPCs ersetzen nicht Receipt- und State-Prüfung.
  3. Erstellen Sie die signierte Linie aus Absender oder Owner, Chain und Domain, Nonce, Payload, Deadline, verifizierendem Contract, Transaktions- oder Nachrichten-Hash und Ersetzungen. EIP-155 ergänzt bei Ethereum-Transaktionen die Account-Nonce; diese allein ist kein vollständiger Cross-Chain-Replay-Schutz.
  4. Weisen Sie Werte in der richtigen Lane zu. Koordinieren Sie parallele EOA-Signer, erhalten Sie Lücken und Same-Nonce-Ersetzungslinien. Folgen Sie bei Anwendung oder Smart Account den atomaren Prüf-, Erhöhungs- und Lane-Regeln des Contracts statt einem angenommenen globalen Zähler.
  5. Senden Sie nach den passenden Zulassungsregeln. Pending- und Ersetzungsregeln von Execution Clients sind lokal; ERC-4337-Bundler validieren UserOperation-Objekte nach EntryPoint- und Account-Regeln; eine EIP-712- oder Permit-Signatur kann in der Transaktion eines Dritten übermittelt werden. Lokale Annahme beweist keine kanonische Aufnahme.
  6. Verfolgen Sie das vollständige Ergebnis: abgelehnt, pending, queued, ersetzt, erfolgreich aufgenommen, mit status = 0 aufgenommen, durch Reorganisation entfernt oder finalisiert. Eine aufgenommene Ethereum-Transaktion erhöht die Absender-Nonce auch bei EVM-Revert; eine innerhalb des Aufrufs geänderte Anwendungs-Nonce wird zurückgesetzt.
  7. Gleichen Sie vor einem erneuten Versuch kanonisches Receipt, Block-Hash, Absender-Nonce, Anwendungs-Storage, ERC-4337-Event oder -Receipt und Finalität ab. Prüfen Sie bei PoW vollständigen Header und Target; nach Erschöpfung des endlichen Felds ändern Miner andere headerwirksame Daten.

Durchgerechnete Beispiele

  • Aufgenommener Revert verbraucht die EOA-Nonce. Die kanonische Absender-Nonce ist 12. Eine Transaktion mit Nonce 12 wird mit status = 0 aufgenommen, verbraucht 50,000 Gas zu 30 gwei und kostet 50,000 * 30 gwei = 0.0015 ETH. Contract-Änderungen werden zurückgesetzt, die Nonce steigt dennoch auf 13. Entfernt eine Reorganisation den Block, kann sie auf 12 zurückgehen; die Wallet muss die gesamte Linie prüfen.
  • Anwendungs- und Relayer-Nonces sind getrennt. Ein Owner hat EOA-Nonce 18, ein ERC-2612-Token meldet nonces(owner) = 7, der Relayer hat EOA-Nonce 42. Ein erfolgreiches Permit verbraucht Anwendungs-Nonce 7, die zu 8 wird; die Aufnahme erhöht die Relayer-Nonce auf 43, die Owner-Nonce bleibt 18. Beim Revert steigt die Relayer-Nonce trotzdem auf 43, der Token-Storage fällt auf 7 zurück.
  • ERC-4337-Lanes. Nach dem Lehrbeispiel nonce = (key << 64) | sequence ergeben Key 5 und Sequence 9 den Wert 5 * 2^64 + 9 = 92,233,720,368,547,758,089; Sequence 10 ergibt 92,233,720,368,547,758,090. Der unabhängige Key 6 mit Sequence 0 ergibt 110,680,464,442,257,309,696. Parallelität hängt von der Smart-Account-Validierung ab und ist von der EOA-Nonce des Bundlers getrennt.
  • PoW-Such-Nonce. Bitcoins Header-Nonce hat 32 bits und damit 2^32 = 4,294,967,296 Zahlenkandidaten. Bei hypothetischen 100 TH/s dauert ein Durchlauf 4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds. Miner ändern Coinbase-extraNonce, Zeit oder Transaktionsmenge und damit die Merkle Root, um neue Header zu erzeugen; das Feld ist kein Account-Replay-State.

Risiken

  • Verwechslung von EOA-, Contract-, Anwendungs-, ERC-4337- und PoW-Namensräumen.
  • Lesen aus falscher Chain, falschem Fork, Contract oder EntryPoint.
  • Veraltete, inkonsistente oder bösartige RPC-Antwort.
  • Doppelte EOA-Nonce durch parallele Signer.
  • Blockierung späterer Kandidaten durch eine Nonce-Lücke.
  • Behandlung einer Provider-Pending-Nonce als kanonischer Zustand.
  • Übersehen, dass ein aufgenommener Revert Nonce und Gas verbraucht.
  • Fehlende Wiederherstellung von Nonce und Linie nach Reorganisation.
  • Same-Nonce-Ersetzung verfehlt Gebührenregel des Ziel-Nodes.
  • Annahme, Ersetzung habe die alte Transaktion global gelöscht.
  • Verknüpfung gleicher Zahlen verschiedener Absender oder Domains.
  • Fehlende Chain-ID oder anderer Domain Separator.
  • Nicht atomare Prüfung und Erhöhung einer Anwendungs-Nonce.
  • Falscher ERC-2612-Owner, Deadline, Domain Separator oder Token.
  • Replay einer Signatur über Chain, Contract oder Version hinweg.
  • Contract-Account-Nonce als allgemeiner Aufrufzähler missverstanden.
  • Falsches Packen von ERC-4337-Key oder Sequence-Breite.
  • Vermischung von Bundler-EOA-Nonce und Smart-Account-UserOperation-Nonce.
  • Proxy-Upgrade oder Storage-Kollision verändert das Verhalten.
  • Endliche PoW-Nonce als Autorisierung, Replay-State oder Beweis behandelt.

Häufige Missverständnisse

  • Jedes Nonce-Feld bedeutet dasselbe und wird global einmal verwendet.
  • Eine höhere Nonce macht eine Transaktion sicherer, schneller oder finaler.
  • Eine revertierte Ethereum-Transaktion verbraucht keine Absender-Nonce.
  • Eine Nonce allein verhindert jeden Cross-Chain-, Cross-Contract- und Typed-Message-Replay.
  • Jeder ERC-4337-Smart-Account hat denselben linearen Zähler wie eine EOA.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...