---
title: "Nonce-Namensräume in Kryptowährungen"
description: "Praxisleitfaden zu Ethereum-Account-Nonces, anwendungsspezifischen Replay-Nonces, ERC-4337-Key-Sequence-Lanes und Such-Nonces in Proof-of-Work-Blockheadern."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Nonce-Namensräume in Kryptowährungen

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Verwandte Themen

- [Account-basiertes Modell](/de/crypto/account-based-model/)
- [Mempool-Ersetzung](/de/crypto/mempool-replacement/)
- [Account Abstraction](/de/crypto/account-abstraction/)

<a id="sources"></a>

## Quellen

- [Ethereum accounts](https://ethereum.org/developers/docs/accounts/) - Ethereum.org (abgerufen: 2026-08-13)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (abgerufen: 2026-08-13)
- [EIP-2681: Limit account nonce to 2^64-1](https://eips.ethereum.org/EIPS/eip-2681) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [Block Chain](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Developer Documentation (abgerufen: 2026-08-13)

Source: https://wiki.fcontext.com/de/crypto/nonce-crypto/index.mdx