Glossar
Reorg (Chain Reorganization)
Aktualisiert 12. Juni 2026
Reorg (Chain Reorganization) ist der Vorgang, bei dem ein Blockchain-Knoten seine bisherige Sicht auf die längste Kette aufgibt und stattdessen einen konkurrierenden Kettenzweig als kanonische Version der Transaktionshistorie übernimmt.
Wie eine Reorg entsteht
In Proof-of-Work-Netzwerken kann es vorkommen, dass zwei Miner nahezu gleichzeitig einen gültigen Block auf derselben Höhe finden. Beide Blöcke werden ins Netzwerk propagiert; je nach geografischer Nähe und Verbindungsgeschwindigkeit sieht ein Teil der Knoten zunächst Block A als Spitze, ein anderer Teil Block B. Es entstehen zwei konkurrierende Kettenzweige. Das Netzwerk löst diesen Konflikt über die Nakamoto-Konsensregel: Die Kette mit der größten akkumulierten Proof-of-Work gilt als gültig. Sobald auf einem Zweig der nächste Block gefunden wird, hat dieser Zweig mehr Arbeit als der andere – alle Knoten, die bislang dem unterlegenen Zweig folgten, reorganisieren sich auf den längeren Zweig.
Die dabei verworfenen Blöcke werden als Stale Blocks bezeichnet. Das ist terminologisch wichtig: Stale Blocks sind Blöcke, die einmal gültig waren und kurzzeitig Teil eines aktiven Zweigs, aber durch die Reorg abgehängt wurden. Davon zu unterscheiden sind sogenannte Orphan Blocks im engeren Sinne – Blöcke, deren Elternblock einem Knoten noch nicht bekannt ist und die deshalb vorübergehend im Orphan-Block-Cache zwischengespeichert werden. Die Gleichsetzung beider Begriffe ist in der Praxis verbreitet, aber technisch ungenau.
Bedeutung und Risiken
Ein-Block-Reorgs sind in Proof-of-Work-Netzwerken ein normales, gelegentlich auftretendes Ereignis ohne ernsthafte Folgen. Problematisch werden Reorgs, wenn sie mehrere Blöcke tief gehen. Miner, deren Blöcke durch eine Reorg zu Stale Blocks werden, verlieren die Blockbelohnung für diese Arbeit. Für Nutzer können Transaktionen, die in einem verworfenen Block lagen, vorübergehend aus der Kette verschwinden – sie kehren in den Mempool zurück und müssen erneut bestätigt werden.
Tiefe Reorgs entstehen durch Netzwerklatenz, Software-Bugs oder absichtliche 51-%-Angriffe, bei denen ein Angreifer mit ausreichend Hashrate heimlich eine längere Kette aufbaut und diese dann veröffentlicht, um bereits bestätigte Transaktionen rückgängig zu machen (Double Spend). Die Kostspieligkeit tiefer Reorgs schützt etablierte Netzwerke in der Praxis erheblich: Je mehr Blöcke eine Transaktion bereits hinter sich hat, desto mehr Proof-of-Work müsste ein Angreifer neu berechnen. Deshalb gilt bei hochwertigen Transaktionen die Faustregel, auf mehrere Bestätigungen zu warten.