---
title: "Nakamoto-Konsens: Gültigkeit, Chainwork, Bestätigungen und Reorganisationen"
description: "Der Nakamoto-Konsens kombiniert unabhängig durchgesetzte Gültigkeitsregeln, erlaubnisfreie Proof-of-Work-Blockproduktion, Verbreitung und Auswahl der gültigen Kette mit der meisten kumulativen Arbeit. Lokale Sichten, Chainwork, Bestätigungen, Reorganisationen, Common-Prefix-Annahmen, Anreize und Netzwerkangriffe sind getrennt zu analysieren."
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.
# Nakamoto-Konsens: Gültigkeit, Chainwork, Bestätigungen und Reorganisationen
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Der Nakamoto-Konsens ist das Bitcoin-artige Verfahren, bei dem Knoten Konsens-Gültigkeitsregeln unabhängig durchsetzen, Proof-of-Work-Produzenten ohne zugelassene Mitgliederliste Blöcke erweitern, Blöcke sich über ein Peer-to-Peer-Netz verbreiten und jeder Knoten den gültigen Zweig mit der meisten kumulativen Proof-of-Work-Arbeit auswählt. Er ordnet protokollgültige Transaktionen in der beobachteten Knotensicht; er macht ungültige Transaktionen nicht gültig, bestimmt keine Tatsachen außerhalb des Ledgers und erzeugt keine sofortige deterministische Finalität.
Gültigkeit kommt vor Kettenauswahl. Ein Zweig mit ungültigem Header, Proof of Work, ungültiger Transaktion, ungültigem Skript, bereits ausgegebenem Output, unzulässigem Coinbase-Betrag oder überschrittenem Blocklimit wird unabhängig von behaupteter Höhe oder Arbeit verworfen. Unter Zweigen, die die Knotenregeln erfüllen und deren Daten verfügbar sind, bestimmt kumulative Chainwork die aktive Kette, nicht allein die Blockzahl. „Längste Kette“ ist daher eine informelle Abkürzung für die gültige Kette mit dem größten Proof-of-Work-Aufwand.
Die aktive Spitze ist vorläufig. Konkurrierende gültige Blöcke können gut verbundene ehrliche Knoten vorübergehend zu unterschiedlichen lokalen Sichten führen; zusätzliche Arbeit löst den Fork gewöhnlich auf, und ein Knoten kann bei einer Reorganisation einen Zweig trennen und einen anderen verbinden. Die Bestätigungszahl misst die Tiefe einer Transaktion in der aktuellen aktiven Kette des Beobachters. Mehr Tiefe kann unter einem festgelegten Hashrate- und Netzwerkmodell die Aufholwahrscheinlichkeit senken, aber keine Bestätigungszahl ist universell final.
Der Begriff beschreibt mehr als Hashing. Das Sicherheitsargument hängt auch von Block- und Transaktionsgültigkeit, Peer-to-Peer-Verbreitung, ehrlicher Übernahme der gültigen Kette mit der meisten Arbeit, genügend ehrlicher effektiver Mining-Leistung, wirtschaftlichem Verhalten und der unabhängigen Beobachtung des beabsichtigten Netzwerks und der Software ab. Common Prefix, Chain Growth und Chain Quality sind formale Eigenschaften, die nur in benannten Modellen bewiesen werden; sie sind keine bedingungslosen Tatsachen jeder eingesetzten Proof-of-Work-Kette.
## Nakamoto-Konsens analysieren
1. **Identität und Beobachtungsumfang fixieren.** Erfasse `chain`, `network`, `genesis hash`, `client version`, Konsensregeln, Checkpoints oder Assume-valid-Einstellungen, Beobachter, Peers und Zeitpunkt. Sichere `bestblockhash`, `height` und `chainwork`; während der Nachrichtenverbreitung können zwei Knoten ehrlich unterschiedliche Spitzen melden.
2. **Vor dem Arbeitsvergleich validieren.** Prüfe Header-Verknüpfung, Zeitregeln, decodiertes Ziel, Proof of Work, Merkle- und Witness-Commitments, Transaktionen, Skripte, UTXO-Ausgaben, Coinbase und Blockressourcen. Ein `invalid`-Zweig wird nicht allein durch behauptete Höhe oder Arbeit zulässig.
3. **Beobachteten Blockbaum rekonstruieren.** Verknüpfe jeden Kandidaten über den vorherigen Blockhash mit einem bekannten Vorfahren und unterscheide vollständige Blöcke von Headern. Gleiche `active`, `valid-fork`, `valid-headers`, `headers-only` und `invalid` über Schnittstellen wie `getchaintips` ab; nicht jede sichtbare Spitze ist eine gültige Konkurrenzkette.
4. **Kumulative Arbeit nachrechnen.** Decodiere das `nBits`-Ziel jedes Headers und berechne die repräsentierte Arbeit nach den Ganzzahlregeln der Implementierung, konzeptionell `work = floor(2^256 / (target + 1))`. Summiere entlang der Vorfahren und vergleiche gültige Zweige ab dem gemeinsamen Vorfahren; Höhe, geschätzte Hashrate und Pool-Bezeichnungen ersetzen Chainwork nicht.
5. **Auswahl und Reorganisation verfolgen.** Reproduziere die Auswahl des Kandidaten mit der meisten Arbeit, die lokale Reihenfolge bei gleicher Arbeit und den Ankunftsstatus. Erscheint ein besserer gültiger Zweig, bestimme den Forkpunkt, trenne das alte Suffix, verbinde das neue, aktualisiere das `UTXO set` und gleiche Transaktionen mit `mempool` und Anwendungsaufzeichnungen ab.
6. **Risikobasierte Bestätigungspolitik festlegen.** Berechne `confirmations = tip_height - block_height + 1` nur für einen Block der aktuellen aktiven Kette. Dokumentiere Risikowert, Reversibilität, Angreiferanteil, Verbreitung, Eclipse-Exposition, beobachtete Stale-Rate, Tiefe und Reaktionsplan; sechs ist eine Konvention, keine Protokoll-Finalitätsschwelle.
7. **Das gesamte Sicherheitsargument stressen.** Teste Partitionen, Latenz, Blockzurückhaltung, Selfish Mining, Eclipse-Angriffe, Pool- und Hardwarekonzentration, abrupte Hashrate-Änderungen, Gebühren- und Subventionsanreize, Client-Divergenz, tiefe Reorganisationen und Wiederherstellung. Ordne Aussagen Common Prefix, Chain Growth, Chain Quality, Persistenz und Liveness nur unter den Annahmen des zitierten Modells zu.
Das Ergebnis ist eine beobachterspezifische, reproduzierbare Erklärung, welche gültige Historie ein Knoten derzeit auswählt und warum. Konsensregeln definieren Zulässigkeit; Proof of Work verteuert alternative Historien; Verbreitung macht Arbeit anderen Knoten sichtbar; Fork Choice wählt eine aktuelle Historie; und Bestätigungspolitik bestimmt, wann eine Anwendung handelt. Diese Ebenen als „Netzwerkfreigabe“ zusammenzufassen, verdeckt ihre Ausfallbedingungen.
## Rechenbeispiele
### 1. Ungültige Arbeit gewinnt nicht
Angenommen, Zweig A meldet `valid_A = false` und `chainwork_A = 1,200 units`, während B `valid_B = true` und `chainwork_B = 1,000 units` hat. Der Knoten verwirft A und wählt B. Arbeit wird nur zwischen zulässigen Kandidaten verglichen; Proof of Work kann keine überhöhte Coinbase, ungültige Signatur oder Doppelausgabe erlauben.
Hat ein Beobachter nur As Header und ein anderer die vollständigen Blockdaten, können ihre Zustände bis zum Ende von Download und Validierung abweichen. Ein headergültiger Zweig beweist nicht, dass alle Transaktionen und Zustandsübergänge vollständig validiert sind.
### 2. Höhe ist nicht kumulative Arbeit
In einem vereinfachten Beispiel mit variablem Ziel fügt C sechs Blöcke zu je 100 Arbeitseinheiten hinzu, also `6 * 100 = 600 units`. D fügt fünf zu je 130 hinzu, also `5 * 130 = 650 units`. Sind beide gültig und starten mit gleicher Arbeit, ist D trotz eines Blocks weniger der Zweig mit der meisten Arbeit.
Haben zwei gültige Spitzen exakt `650 units`, zwingt gleiche Arbeit nicht alle Knoten sofort zur selben Spitze. Ankunftsreihenfolge und lokaler Implementierungszustand können abweichen, bis ein weiterer gültiger Block einen Zweig schwerer macht. Eine vorübergehende Gleichstandssicht ist keine deterministische globale Finalität.
### 3. Bestätigungen können entfernt werden
Eine Transaktion in Blockhöhe `100` hat bei aktiver Spitze `105` den Wert `tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations`. Angenommen, ein alternativer gültiger Zweig gabelt sich nach Höhe 99 ab und wird auf Höhe 106 ohne diese Transaktion zur Kette mit der meisten Arbeit. Die Reorganisation trennt alte Blöcke `100 through 105`; die Transaktion verliert sechs aktive Bestätigungen und kann in den Mempool zurückkehren, mit einer anderen Ausgabe kollidieren oder fehlen.
Anwendungen müssen Blockhash und Vorfahren abgleichen, nicht nur die Zahl sechs speichern. Börsengutschrift, gelieferte Ware, Bridge-Nachricht und Derivateabwicklung können wirtschaftlich irreversibel sein, obwohl die Quellkettenhistorie es nicht ist.
### 4. Aufholwahrscheinlichkeit ist modellabhängig
Im Beispielmodell des Bitcoin-Whitepapers sei der Angreiferanteil `q = 0.10`, der ehrliche Anteil `p = 0.90` und der ehrliche Vorsprung `z = 6`. Die Poisson-Näherung ergibt `lambda = z * (q / p) = 0.6666667` und `P(catch up) = 0.0002428027 = 0.02428027%`. Bei `q = 0.30` und gleicher Tiefe steigt der Wert auf `P(catch up) = 0.1321111687 = 13.21111687%`.
Diese Zahlen sind keine aktuellen Bitcoin-Garantien. Die Rechnung nimmt stabile unabhängige Hashversuche und die Rennbedingungen des Modells an; Eclipse-Isolation, Verbreitungsvorteil, egoistische Strategien, Preis- und Mietreaktion, Implementierungsfehler und Anwendungsreaktion fehlen. Eine Richtlinie muss ihr Modell offenlegen und schlechtere Bedingungen testen, statt nur sechs Bestätigungen zu nennen.
## Risiken und Prüfungsfehler
### Protokoll- und Messfehler
- Arbeit vergleichen, bevor Header, Blockkörper und Vorfahren unabhängig validiert sind.
- Den höchsten oder zuerst gesehenen Zweig ohne Berechnung kumulativer Chainwork zum Gewinner erklären.
- Blockzahl, Nenn-Hashrate, Poolanteil oder Explorer-Bezeichnung als Chainwork-Ersatz verwenden.
- Mainnet, Testnet, Signet, Forks, Client-Versionen, Checkpoints oder Genesis-Identitäten mischen.
- Nur-Header-, nicht verfügbare oder optimistische Daten als vollständig validierte Historie behandeln.
- Zieldecodierung, Ganzzahlarithmetik, Vorhash-Verknüpfung oder gemeinsamen Vorfahren ignorieren.
- Einen RPC oder Explorer ohne Hash-, Höhen-, Zeit- und Peer-Kontext als globale Sicht lesen.
### Netzwerk-, Anreiz- und Kontrollfehler
- Sofortige Verbreitung oder identische Transaktions- und Blockankunft bei allen Knoten annehmen.
- Einen Arbeitsgleichstand als einen global bestimmten Zustand statt als temporäre lokale Sichten behandeln.
- Stale-Blöcke, Latenz, Zurückhaltung, Selfish Mining und Verbreitungsvorteil ignorieren.
- Aus Poolnamen unabhängige Miner oder aus Poolanteilen physisches Hardwareeigentum ableiten.
- Pool-, Firmware-, Hersteller-, Hosting-, Energie-, geografische und Netzwerkkonzentration ignorieren.
- Belohnungen als Beweis ansehen, dass ehrliches Erweitern für jeden immer optimal ist.
- Eclipse-, Partitions-, Sybil-, Peer-Poisoning-, DoS- und Zeitmanipulationsrisiken auslassen.
### Abwicklungs- und Sicherheitsfehler
- Eine Bestätigung Protokollfinalität nennen oder versprechen, dass sechs nicht entfernt werden können.
- Eine Bestätigungszahl auf jeden Wert, jede Gegenpartei, Reversibilität und Bedrohung anwenden.
- Das Whitepaper-Wahrscheinlichkeitsbeispiel in eine aktuell gemessene Angriffswahrscheinlichkeit umdeuten.
- Behaupten, Mehrheits-Hashpower könne Signaturen fälschen, beliebige Coins nehmen oder Inflation validieren.
- Behaupten, Minderheits-Hashpower könne nie profitabel abweichen oder Reorganisation und Zensur bewirken.
- Die aktuelle Meistarbeits-Spitze mit externen Tatsachen, Rechtseigentum oder Anwendungsabwicklung gleichsetzen.
## Häufige Missverständnisse
- **Die längste Kette hat immer die meisten Blöcke.** Bitcoin-Knoten wählen die gültige Kette mit der meisten kumulativen Arbeit; bei verschiedenen Zielen kann Höhe ein ungeeigneter Ersatz sein.
- **Miner entscheiden, welche Protokollregeln gelten.** Miner schlagen Blöcke vor; jeder Full Node setzt seine konfigurierten Konsensregeln unabhängig durch.
- **Sechs Bestätigungen schaffen absolute Finalität.** Sechs ist Anwendungskonvention; Risiko hängt von Modell, Tiefe, Gegner, Verbreitung und Beobachtungsintegrität ab.
- **Ein 51-Prozent-Angreifer kann fremde Coins ausgeben.** Hashpower kann Reorganisation, Doppelausgabe und Zensur stützen, liefert aber keine fremde Private-Key-Signatur und lässt unveränderte Full Nodes keine ungültige Inflation akzeptieren.
- **Hohe Gesamt-Hashrate beweist Dezentralität und Sicherheit.** Effektive Kontrolle, Netzwerksicht, Hardwarezugang, Poolkoordination, Clientvielfalt, Anreize und Angriffsdauer zählen ebenfalls.
## Verwandte Themen
- [Proof of Work](/de/crypto/proof-of-work/)
- [Fork-Choice-Regeln](/de/crypto/fork-choice-rule/)
- [Blockbestätigungen](/de/crypto/block-confirmation/)
- [Chain-Reorganisationen](/de/crypto/chain-reorg/)
- [Selfish Mining](/de/crypto/selfish-mining/)
## Quellen
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (abgerufen: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (abgerufen: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (abgerufen: 2026-08-19)
- [Bitcoin Core RPC: getchaintips](https://developer.bitcoin.org/reference/rpc/getchaintips.html) - Bitcoin Project (abgerufen: 2026-08-19)
- [Bitcoin Core: validation.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp) - Bitcoin Core (abgerufen: 2026-08-19)
- [The Bitcoin Backbone Protocol: Analysis and Applications](https://eprint.iacr.org/2014/765) - IACR Cryptology ePrint Archive (abgerufen: 2026-08-19)
- [Majority Is Not Enough: Bitcoin Mining Is Vulnerable](https://www.cs.cornell.edu/~ie53/publications/btcProcArXiv.pdf) - Cornell University (abgerufen: 2026-08-19)
- [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (abgerufen: 2026-08-19)
Source: https://wiki.fcontext.com/de/crypto/nakamoto-consensus/index.mdx