45 / 736REORG

Reorg

Neuordnung der Blockchain

Auch eine bestätigte Zahlung kann ihre Bestätigung vorübergehend verlieren. Bei einem Reorg übernimmt ein Knoten einen anderen gültigen Zweig der Bitcoin-Historie und ersetzt damit die zuletzt verfolgten Blöcke.

Ein Bitcoin-Knoten ist ein Programm, das Blöcke und Transaktionen prüft. Ein Reorg ist der Wechsel eines Bitcoin-Knotens zu einem anderen gültigen Zweig mit mehr angesammeltem Proof of Work, also durch Mining nachgewiesener Arbeit. Der Knoten bewertet die jüngsten Blöcke und ihre Zahlungen neu. Das ändert weder die Regeln von Bitcoin noch gibt es jemandem einen Knopf zum Stornieren fremder Zahlungen.

Anna erhält 20.000 Satoshi, die kleinen Einheiten von Bitcoin. Ihre Wallet zeigt eine Bestätigung: Die Zahlung steht in einem Block, den ihr Knoten angenommen hat. Dann erfährt der Knoten von einem konkurrierenden gültigen Zweig, der die Zahlung noch nicht enthält. Sobald dieser Zweig mehr angesammelte Mining-Arbeit nachweist, wechselt der Knoten zu ihm. Dieser Austausch eines Teils der Historie heißt Reorg. Annas Zahlung kann wieder auf Bestätigung warten, ohne dass jemand ihre Schlüssel gestohlen oder die Signatur verändert hat. Entscheidend ist weder eine Abstimmung noch allein die Zahl der Blöcke, sondern Chainwork: die Summe der Arbeit, die jeder Block entsprechend seiner Schwierigkeit nachweist. Einen ungültigen Zweig lehnt der Knoten auch bei mehr Arbeit ab. [1] [4]

Was Anna danach sieht, hängt vom neuen Zweig ab. Enthält auch er ihre Zahlung, bleibt diese bestätigt; die Anzahl der Bestätigungen kann sich jedoch ändern. Andernfalls kann Bitcoin Core versuchen, sie in den Mempool zurückzunehmen: die vorläufige Liste unbestätigter Transaktionen, die auf einen Block warten. Das ist nicht garantiert. Ein Ausgang einer früheren Transaktion hält einen Betrag und die Bedingungen fest, unter denen er ausgegeben werden darf. Der neue Zweig könnte dieselben Mittel bereits anders ausgegeben haben. Vielleicht fehlt auch ein zuvor erzeugter Ausgang, der ausgegeben werden soll, oder zeitliche und andere Aufnahmebedingungen sind nicht erfüllt. Eine erneut wartende Zahlung ist daher etwas anderes als eine Zahlung, die die neue Historie nicht mehr zulässt. [1]

Eine Bestätigung steht für den Block mit der Zahlung. Jeder folgende Block fügt eine weitere Bestätigung hinzu und auch Arbeit, die ein konkurrierender Zweig übertreffen müsste. Eine Zahlung im jüngsten Block hat somit eine Bestätigung. Je tiefer sie in der akzeptierten Historie liegt, desto schwieriger wird deren Austausch gewöhnlich. Doch keine endliche Zahl von Bestätigungen garantiert mathematisch, dass ein Austausch unmöglich ist. Händler und Börsen richten ihre Wartezeiten deshalb am Zahlungswert und am akzeptierten Risiko aus. [3] [5]

Ein Reorg allein beweist keinen Angriff. Zwei Miner können fast gleichzeitig Blöcke mit demselben Vorgänger finden. Nachrichten verbreiten sich nicht augenblicklich, daher folgen Knoten kurzzeitig verschiedenen Kettenenden. Sobald ein gültiger Zweig mehr Arbeit aufweist, wechseln die Knoten zu ihm; der aufgegebene Block ist ein Stale Block. Bei einem Double Spend kann ein Angreifer denselben Mechanismus ausnutzen und eine Historie durchsetzen wollen, in der dieselben Mittel anders ausgegeben wurden. Entscheidend ist deshalb, warum der Wechsel stattfand und welche Zahlungen er veränderte. [4] [5]

Bei einem Reorg behält der Knoten dieselben Regeln und wählt zwischen Historien, die ihnen entsprechen. Ein Hard Fork ändert dagegen die Gültigkeitsregeln: Alte und neue Software können denselben Block unterschiedlich beurteilen. Eine Reorganisation schafft somit nicht von selbst eine neue Währung und schreibt auch nicht die Bitcoin-Regeln um. Die folgenden Kapitel erklären die technische Umsetzung dieses Historienwechsels. [4]

Tip bezeichnet den jüngsten Block des derzeit akzeptierten Zweigs. Der Verzweigungspunkt ist der letzte gemeinsame Block der derzeit aktiven Kette und des alternativen Zweigs. Die Tiefe eines Reorgs wird gewöhnlich durch die Anzahl der Blöcke am aktiven Kettenende beschrieben, die getrennt werden müssen, um zu diesem gemeinsamen Vorfahren zurückzukehren. Ein Reorg mit einer Tiefe von einem Block ersetzt die Kettenspitze; ein tieferer Reorg macht mehrere bestätigte Blöcke rückgängig. Die Tiefe hängt von der Sicht des jeweiligen Knotens ab. [1]

Ein Full Node prüft die Regeln selbst. Die folgenden Funktionsnamen beschreiben die Umsetzung in Bitcoin Core. Bitcoin Core wählt nicht einfach den höchsten oder beliebtesten Zweig. Die Kandidatenkette muss bei der Aktivierung die Konsensregeln des Knotens erfüllen; mehr chainwork macht einen ungültigen Block nicht gültig. FindMostWorkChain wählt den Kandidaten mit der größten Arbeit aus, von dem nicht bekannt ist, dass er ungültig ist. Das bedeutet noch keine vollständige Validierung: Weitere Prüfungen erfolgen beim Anschließen der Blöcke in ActivateBestChain. Bekannt ungültige Zweige werden ausgeschlossen. [1]

Ein UTXO ist ein noch nicht ausgegebener Transaktionsausgang; das UTXO-Set umfasst diese verfügbaren Ausgänge. Undo-Daten speichern, was zum Rückgängigmachen der Auswirkungen eines Blocks benötigt wird. DisconnectTip und die nachfolgende Validierungslogik machen die Auswirkungen der getrennten Blöcke in umgekehrter Reihenfolge rückgängig. Ausgegebene UTXO werden wiederhergestellt, und die vom entfernten Block erzeugten Outputs sind nicht mehr bestätigt. Deshalb speichert Bitcoin Core Undo-Daten: Das UTXO-Set muss exakt am Verzweigungspunkt rekonstruiert werden können. [1]

Rollback meint hier die Rückkehr zum Zustand vor den getrennten Blöcken; Chainstate ist der Arbeitszustand des Knotens zur akzeptierten Historie. Nach dem Rollback schließt ConnectTip die Blöcke des Zweigs mit höherem chainwork in Vorwärtsreihenfolge an. Jede Transaktion wird erneut anhand des rekonstruierten UTXO-Sets und der auf der jeweiligen Höhe geltenden Regeln validiert. Das Ergebnis ist ein chainstate, der einer einzigen konkreten Historie entspricht, und keine Mischung aus Transaktionen beider Zweige. [1]

Die Coinbase Transaction ist die erste Transaktion im Block und weist dem Miner seine Belohnung zu. Höhe h bezeichnet die Position eines Blocks in der Kette. Die Coinbase-Transaktion ist eine Ausnahme: Nach dem Trennen des Blocks kehrt sie nicht in den Mempool zurück. Ein auf Höhe h erzeugter Coinbase-Output darf gemäß den Konsensregeln frühestens in Block h + 100 ausgegeben werden. Bei einer Kettenspitze auf Höhe h + 99 hat der Ursprungsblock 100 Bestätigungen, und die Reifebedingung erlaubt die Aufnahme der Ausgabe in den nächsten Block. Entfernt ein Reorg den Block mit der Coinbase-Transaktion, verschwindet dessen Belohnung aus dem aktiven chainstate. Auch nachfolgende Transaktionen, die auf der entfernten Historie aufbauten, können ungültig sein. [1] [2] [3]

Es folgen Funktionsnamen einer bestimmten Programmversion, keine zusätzlichen Handlungen für Wallet-Nutzer. In Bitcoin Core v29.0 sind die Schritte ausdrücklich umgesetzt: FindMostWorkChain findet den Kandidaten mit dem höchsten chainwork, für den keine Ungültigkeit bekannt ist; ActivateBestChainStep kann die aktuelle Kettenspitze trennen; ConnectTip prüft alternative Blöcke und schließt sie an; und MaybeUpdateMempoolForReorg prüft die Transaktionen aus getrennten Blöcken erneut. Die Aktivierung kann die Ungültigkeit eines Kandidaten aufdecken und die Suche nach einem anderen Zweig fortsetzen. Ein umfangreicher Reorg erfordert die Verarbeitung weiterer getrennter und angeschlossener Blöcke und kann deshalb die Verarbeitung durch ActivateBestChain verlängern. [1]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bestätigung, Proof of Work, Stale Block, Double Spend, Full Node, UTXO. Auf diesen Eintrag verweisen außerdem Bestätigung, Double Spend, Coinbase-Transaktion, Soft Fork.

DOC · 001Bitcoin Core v29.0 — chain activation and mempool reconciliationPrimärquelle DOC · 002Bitcoin Core v29.0 — coinbase maturity validationPrimärquelle DOC · 003Bitcoin Core v29.0 — confirmation depthPrimärquelle DOC · 004Bitcoin Developer Guide — Block ChainDokumentation DOC · 005Bitcoin whitepaper — Sections 5 and 11Primärquelle
Überarbeitet: Quellenbasiert · Keine Anlageberatung