Antworten>Erfahren Sie mehr über die Grundlagen der Blockchain-Sicherheit>Was ist eine Blockchain-Reorganisation?
Was ist eine Blockchain-Reorganisation?
// Tags
Blockchain-ReorganisationKettenreorganisation
TL;DR: Eine Blockchain-Reorg (kurz für „Reorganisation“) tritt auf, wenn sich die kanonische Kette des Netzwerks ändert und Blöcke, die zuvor als Teil der Hauptkette galten, durch eine andere Gruppe von Blöcken ersetzt werden. Dies kann dazu führen, dass bestätigte Transaktionen verschwinden, sich die Reihenfolge der Transaktionen ändert und der Zustand der Anwendung inkonsistent wird. Reorgs treten aufgrund von Netzwerklatenz und der gleichzeitigen Blockproduktion bei den meisten Blockchains ganz natürlich auf, doch tiefgreifende Reorgs können auch durch Angriffe oder Softwarefehler verursacht werden. Das Verständnis von Reorgs ist für jeden Entwickler, der Anwendungen erstellt, die auf bestätigten Blockchain-Daten basieren, von entscheidender Bedeutung, da die Nichtberücksichtigung von Reorgs zu Schwachstellen durch Doppelausgaben, Phantomtransaktionen und beschädigten Datenbanken führen kann.
Die einfache Erklärung
Stellen Sie sich eine Blockchain als einen einzelnen Pfad durch einen Wald vor, auf dem jeder Schritt einen Block darstellt. Unter normalen Umständen folgen alle demselben Pfad. Gelegentlich finden jedoch zwei Wegbereiter gleichzeitig unterschiedliche Routen, sodass für kurze Zeit zwei gültige Pfade nebeneinander bestehen. Das Netzwerk entscheidet schließlich, welcher Pfad der richtige ist (in der Regel derjenige, der sich zuerst weiter erstreckt), und alle wechseln auf diesen Pfad. Wer dem anderen Pfad gefolgt ist, muss umkehren und wechseln.
Wenn dieser Wechsel stattfindet, spricht man von einer Reorganisation. Die Blöcke auf dem verworfenen Pfad werden verworfen, und die Blöcke auf dem siegreichen Pfad bilden die kanonische Kette. Transaktionen, die sich in den verworfenen Blöcken befanden, tauchen möglicherweise in den Blöcken der siegreichen Kette auf – oder auch nicht. Einige Transaktionen könnten an derselben Position in beiden Pfaden landen. Andere tauchen vielleicht in einem Pfad auf, im anderen jedoch nicht. Einige wenige könnten vollständig verworfen werden, wenn sie mit Transaktionen in der siegreichen Kette in Konflikt stehen.
Für die meisten Endnutzer finden flache Reorgs (ein oder zwei Blöcke tief) häufig und unbemerkt statt. Ihre Wallet zeigt eine Transaktion möglicherweise kurzzeitig als bestätigt an, dann für einige Sekunden wieder als ausstehend, bevor sie im neuen kanonischen Block erneut bestätigt wird. Das würden Sie wahrscheinlich gar nicht bemerken. Für Anwendungen, die Blockchain-Daten in großem Umfang verarbeiten, bedeutet jedoch bereits eine Reorganisation um einen Block, dass Datensätze, die auf der Grundlage der alten Blöcke bereits in Ihre Datenbank geschrieben wurden, nun fehlerhaft sind und korrigiert werden müssen.
Wie Umstrukturierungen ablaufen
Die häufigste Ursache für Reorgs ist die natürliche Netzwerklatenz. Wenn zwei Validatoren ungefähr zur gleichen Zeit (innerhalb desselben Slots oder bei derselben Blockhöhe) gültige Blöcke erzeugen, kann es vorkommen, dass verschiedene Teile des Netzwerks vorübergehend unterschiedliche Blöcke übernehmen. Knoten A sieht möglicherweise Block X zuerst und betrachtet ihn als kanonisch, während Knoten B Block Y zuerst sieht. Beide Blöcke sind gemäß den Konsensregeln gültig, aber letztendlich kann nur einer Teil der Hauptkette sein.
Das Netzwerk löst diese Mehrdeutigkeit durch seine Regel zur Fork-Auswahl. Auf Ethereum wählt die Fork-Auswahlregel (LMD-GHOST) die Kette aus, die von den meisten Validatoren bestätigt wird. Auf Bitcoin gewinnt die längste Kette (mit dem größten kumulierten Proof-of-Work). Unabhängig von der jeweiligen Regel ist das Ergebnis dasselbe: Ein Fork wird als kanonisch übernommen, der andere verworfen. Knoten, die dem verworfenen Fork gefolgt sind, erkennen den Wechsel, rollen die verwaisten Blöcke zurück und übernehmen die siegreiche Kette.
Bei Proof-of-Work-Blockchains wie Bitcoin kommen Reorgs relativ häufig vor, da der Mining-Prozess von Natur aus probabilistisch ist. Es kann vorkommen, dass zwei Miner fast zeitgleich gültige Blöcke finden, wodurch eine vorübergehende Verzweigung entsteht, die sich innerhalb von ein oder zwei Blöcken auflöst. Reorganisationsvorgänge über einen Block auf Bitcoin treten regelmäßig auf und gelten als normaler Bestandteil des Netzwerkbetriebs. Tiefgreifendere Reorganisationsvorgänge sind unter ehrlichen Bedingungen selten, werden jedoch möglich, wenn ein Angreifer einen erheblichen Teil der Hash-Leistung des Netzwerks kontrolliert (die Grundlage für einen 51-Prozent-Angriff).
Im Proof-of-Stake-System von „ Ethereum “ verringert das slotbasierte Modell zur Blockerstellung die Häufigkeit natürlicher Reorgs, da für jeden Slot ein bestimmter Proposer vorgesehen ist. Reorgs können jedoch weiterhin auftreten, wenn der Block eines Proposers verspätet eintrifft (aufgrund von Netzwerklatenz) und der nächste Proposer stattdessen auf dem vorherigen kanonischen Block aufbaut. Verpasste Slots, bei denen der festgelegte Proposer keinen Block erzeugt, können ebenfalls die Voraussetzungen für kurze Reorgs schaffen, wenn mehrere Validatoren auf unterschiedlichen Ansichten der Blockchain aufbauen.
Arten von Umstrukturierungen
Flache Reorgs sind ein bis drei Blöcke tief und treten in den meisten Blockchains ganz natürlich auf. Sie sind eine normale Folge des verteilten Konsenses und lösen sich innerhalb von Sekunden von selbst auf. Die meisten Anwendungen können mit flachen Reorgs umgehen, indem sie einige zusätzliche Blockbestätigungen abwarten, bevor sie Daten als endgültig betrachten.
Tiefe Reorgs sind mehr als drei Blöcke tief und deuten in der Regel auf eine Anomalie hin: einen gezielten Angriff, einen Konsensfehler oder eine erhebliche Netzwerkpartitionierung. Ein tiefer Reorg auf einer Hauptkette ist ein schwerwiegendes Ereignis, da er Transaktionen rückgängig machen kann, die Nutzer und Anwendungen bereits als bestätigt angesehen hatten. Tiefe Reorgs auf kleineren Ketten mit geringerer Sicherheit (geringere Hash-Leistung oder geringerer gestaketer Wert) kommen häufiger vor und wurden bereits zur Durchführung von Doppelausgaben-Angriffen genutzt.
Ein 51-Prozent-Angriff (oder bei einigen PoS-Blockchains ein 34-Prozent-Angriff) ist die absichtliche Erzeugung einer tiefgreifenden Reorganisation. Ein Angreifer mit mehrheitlicher Konsensmacht minet oder validiert eine private Blockchain, die sich von der öffentlichen unterscheidet, und legt diese anschließend dem Netzwerk offen. Da die Kette des Angreifers länger ist (oder mehr Bestätigungen aufweist), übernimmt das Netzwerk diese als kanonisch, wodurch die jüngsten Blöcke der öffentlichen Kette zu Waisenblöcken werden. Dies ermöglicht es dem Angreifer, Transaktionen auf der verworfenen Kette rückgängig zu machen und möglicherweise Gelder, die zuvor gesendet und bestätigt wurden, doppelt auszugeben.
Auswirkungen auf Anwendungen
Bei Anwendungen, die Blockchain-Daten verarbeiten, stellen Reorgs eine Herausforderung hinsichtlich der Datenkonsistenz dar. Wenn Ihre Anwendung Transaktionsdatensätze in eine Datenbank schreibt, sobald diese in einem Block erscheinen, bedeutet eine Reorg, dass einige dieser Datensätze nun auf Blöcken basieren, die nicht mehr existieren. Die Transaktionen können zwar weiterhin in den neuen kanonischen Blöcken erscheinen (nur an einer anderen Position oder unter einer anderen Blocknummer), oder sie fehlen möglicherweise gänzlich.
DeFi-Anwendungen sind besonders anfällig. Wenn ein DEX-Aggregator einen Swap als bestätigt anzeigt und das Portfolio des Nutzers aktualisiert, dieser Swap jedoch durch eine Reorganisation aus der kanonischen Blockchain entfernt wird, ist das Portfolio nun fehlerhaft. Wenn eine Bridge eine Einzahlung in der Quell-Blockchain erkennt und Gelder in der Ziel-Blockchain freigibt, die Einzahlung jedoch durch eine Reorganisation entfernt wird, hat die Bridge Gelder auf der Grundlage einer Transaktion freigegeben, die nicht mehr existiert. Dies ist einer der wichtigsten Angriffsvektoren gegen kettenübergreifende Brücken.
Indexer und Datenpipelines müssen Reorganisationen erkennen, feststellen, welche Blöcke verworfen wurden, alle aus diesen Blöcken abgeleiteten Datensätze zurückrollen und die korrekten kanonischen Blöcke erneut verarbeiten. Ohne diese Logik sammeln sich in der indizierten Datenbank Phantomdatensätze aus verwaisten Blöcken an, was zu Inkonsistenzen führt, die mit der Zeit zunehmen und nachgelagerte Analysen, Salden und Transaktionsverläufe verfälschen.
Umgang mit Umstrukturierungen
Die einfachste Abwehrmaßnahme gegen Reorgs besteht darin, die Finalität abzuwarten, bevor Daten als bestätigt behandelt werden. Bei „ Ethereum “ tritt die Finalität nach zwei Epochen (etwa 12–13 Minuten) ein; danach können Blöcke nicht mehr rückgängig gemacht werden, ohne mindestens ein Drittel aller gestakten ETH zu vernichten. Bei „ Bitcoin “ gelten sechs Bestätigungen (etwa 60 Minuten) als allgemein anerkannter Standard für die wirtschaftliche Finalität. Bei „ Solana “ bedeutet „Single-Slot-Finalität“, dass bestätigte Transaktionen innerhalb von etwa 400 Millisekunden effektiv endgültig sind.
Bei Anwendungen, bei denen eine Wartezeit bis zur vollständigen Endgültigkeit nicht in Frage kommt (da die Nutzer schnelleres Feedback erwarten), empfiehlt es sich, Daten so lange als „unbestätigt“ oder „ausstehend“ anzuzeigen, bis eine ausreichende Anzahl an Bestätigungen vorliegt, und eine Rollback-Logik zu implementieren, die den Fall, dass eine kürzlich bestätigte Transaktion durch eine Reorganisation rückgängig gemacht wird, reibungslos abwickelt.
Datenpipelines sollten Blöcke nach Möglichkeit in der Reihenfolge ihrer endgültigen Bestätigung verarbeiten. Anstatt Blöcke sofort zu erfassen, sobald sie an der Spitze der Blockchain erscheinen (was das Risiko birgt, Blöcke zu verarbeiten, die später möglicherweise verwaist sind), sollten Pipelines die neuesten Blöcke zwischenspeichern und erst dann verarbeiten, wenn sie eine sichere Bestätigungs-Tiefe erreicht haben. Für Echtzeit-Anwendungsfälle, bei denen eine Zwischenspeicherung nicht akzeptabel ist, muss die Pipeline über explizite Mechanismen zur Erkennung von Reorganisationen und zum Rollback verfügen.
Was ist der Unterschied zwischen einer Reorg und einem Fork?
Reorgs und Forks hängen zusammen, sind aber nicht dasselbe. Ein Fork ist jeder Punkt, an dem sich die Kette in zwei konkurrierende Zweige aufspaltet; dies kann vorübergehend sein (zwei gültige Blöcke auf derselben Höhe) oder dauerhaft (ein Protokoll-Upgrade, das eine neue Kette erzeugt). Eine Reorganisation ist konkret das, was geschieht, wenn Knoten einen Zweig aufgeben und zu einem anderen wechseln, nachdem sich eine vorübergehende Abspaltung aufgelöst hat. Mit anderen Worten: Eine vorübergehende Abspaltung ist die Ursache, und eine Reorganisation ist die Folge für die Knoten, die den unterlegenen Zweig unterstützt haben.
Aspekt
Reorganisation
Gabel
Definition
Knoten ersetzen kanonische Blöcke durch einen konkurrierenden Zweig
Die Kette teilt sich in zwei oder mehr Zweige auf
Auslöser
Eine temporäre Abzweigung wird zugunsten eines anderen Zweigs aufgelöst
Parallele Blöcke, ein Fehler oder ein Protokoll-Upgrade
Beständigkeit
Immer nur vorübergehend; ein Zweig wird verworfen
Kann vorübergehend oder dauerhaft sein
Auswirkungen auf die Daten
Bestätigte Transaktionen können sich verschieben oder verschwinden
Kann eine separate, dauerhafte Kette bilden
Um einen tieferen Einblick in die verschiedenen Arten von Splits zu erhalten, lesen Sie, was eine „Chain Fork“ ist. Reorgs stehen zudem in engem Zusammenhang mit der Reihenfolge der Transaktionen, da sich die Reihenfolge der Transaktionen ändern kann, wenn der kanonische Zweig wechselt.
Wie viele Bestätigungen schützen vor einer Reorganisation?
Die Anzahl der Bestätigungen, die als sicher gilt, hängt vom Konsensmodell der Blockchain und vom Wert der betroffenen Transaktion ab. Je mehr Bestätigungen vorliegen, desto umfangreicher müsste eine Reorganisation sein, um Ihre Transaktion rückgängig zu machen, was für einen Angreifer exponentiell teurer wird. Die folgende Tabelle fasst gängige Richtlinien für die Behandlung von Daten als endgültig zusammen.
Kette
Gemeinsamer Schwellenwert für die Endgültigkeit
Ungefähre Dauer (in Uhrzeit)
Bitcoin
6 Bestätigungen
ca. 60 Minuten
Ethereum
2 Epochen (abgeschlossen)
~12 bis 13 Minuten
Solana
Finalität mit einem einzigen Slot
~400 Millisekunden
Kleinere PoW-Blockchains
Noch viel mehr Bestätigungen
Unterschiedlich, höheres Risiko einer Umstrukturierung
Das Abwarten der Blockchain-Finalität ist der beste Schutz, während kleinere oder weniger sichere Netzwerke eine größere Anzahl an Bestätigungen erfordern, da ihr Risiko einer Reorganisation höher ist. Auch eine zuverlässige Infrastruktur spielt hier eine Rolle: Erfahren Sie, warum die Zuverlässigkeit der Knoten für konsistente, Reorganisation-berücksichtigende Daten wichtig ist.
Kann eine Blockchain-Reorganisation einen Angriff darstellen?
Die meisten Reorgs sind harmlos und lösen sich innerhalb von ein oder zwei Blöcken auf, doch eine absichtlich herbeigeführte tiefgreifende Reorg stellt einen Angriff dar. Indem ein Angreifer mit ausreichender Konsensmacht im Verborgenen eine konkurrierende Blockchain aufbaut und diese anschließend veröffentlicht, kann er kürzlich erstellte Blöcke verwaisten lassen und Transaktionen rückgängig machen, die bereits als bestätigt galten – dies ist der Mechanismus, der hinter Doppelausgaben und 51-Prozent-Angriffen steht. Reorgs überschneiden sich zudem mit Strategien zur Gewinnabschöpfung. Daher hilft das Verständnis dessen, was MEV ist, sowie die Betrachtung gängiger Ausfallmodi von Blockchains Teams dabei, Systeme zu entwerfen, die sicher ausfallen, wenn eine Reorg böswillig und nicht natürlich ist.
Häufig gestellte Fragen
Sind Blockchain-Reorgs normal?
Flache Reorgs von einem bis drei Blöcken sind ein normaler Bestandteil des verteilten Konsensverfahrens und treten regelmäßig auf, insbesondere bei Proof-of-Work-Blockchains. Sie sind in der Regel innerhalb von Sekunden behoben, und die meisten Nutzer bemerken sie gar nicht. Tiefe Reorgs hingegen sind ungewöhnlich und deuten oft auf einen Angriff oder einen Fehler hin.
Verschwinden bestätigte Transaktionen während einer Reorganisation?
Das ist möglich. Eine Transaktion in einem verwaisten Block kann in der neuen kanonischen Kette an einer anderen Position wieder auftauchen oder ganz verworfen werden, wenn sie mit dem siegreichen Zweig in Konflikt steht. Aus diesem Grund sollten Anwendungen auf eine ausreichende Anzahl von Bestätigungen warten, bevor sie eine Transaktion als endgültig betrachten.
Welche Blockchains weisen die meisten Reorgs auf?
Proof-of-Work-Blockchains und kleinere Netzwerke mit geringerer Hash-Leistung oder geringerem Staking-Wert sind häufiger von Reorgs betroffen. Bei „ Bitcoin “ kommt es gelegentlich zu Reorgs, die nur einen Block betreffen, während Blockchains mit geringerer Sicherheit stärker von tiefgreifenderen, potenziell böswilligen Reorgs bedroht sind.
Wie gehen Indexer mit Reorgs um?
Ein „reorg-aware“-Indexer erkennt die Verzweigung, ermittelt, welche Blöcke verworfen wurden, macht alle daraus abgeleiteten Datensätze rückgängig und verarbeitet die neuen kanonischen Blöcke erneut. Ohne diese Logik sammeln sich in der Datenbank Phantomdatensätze an, die im Laufe der Zeit die Salden und Auswertungen verfälschen.
Verhindert das Warten auf die Endgültigkeit Probleme bei der Reorganisation?
Ja. Sobald ein Block endgültig bestätigt ist, kann er nicht mehr rückgängig gemacht werden, ohne dass dabei extrem hohe wirtschaftliche Kosten entstehen. Daher sind Daten, die mit endgültig bestätigten Blöcken verknüpft sind, vor Reorganisationen geschützt. Der Nachteil dabei ist die Latenz, weshalb manche Anwendungen unbestätigte Daten anzeigen und irreversible Aktionen den endgültig bestätigten Daten vorbehalten.
Wie „ Quicknode “ Umstrukturierungen handhabt
Quicknode Streams ist so konzipiert, dass die Behandlung von Reorganisationsvorgängen in die Kernarchitektur integriert ist. „ Streams “ liefert Blockchain-Daten in der Reihenfolge ihrer Endgültigkeit, was bedeutet, dass Blöcke erst dann verarbeitet und übermittelt werden, wenn sie eine sichere Bestätigungs-Tiefe im Netzwerk erreicht haben. Wenn es doch zu einer Reorganisation kommt, erkennt „ Streams “ die Abzweigung automatisch, ermittelt, welche bereits übermittelten Blöcke nicht mehr kanonisch sind, und sendet Korrekturdaten an Ihren Empfänger, damit Ihre Daten mit dem tatsächlichen Zustand der Blockchain übereinstimmen.
Diese integrierte Reorg-Verarbeitung beseitigt eine der komplexesten technischen Herausforderungen bei der Verarbeitung von Blockchain-Daten. Anstatt eine benutzerdefinierte Reorg-Erkennung, Rollback-Logik und Blockabgleich in Ihre Pipeline zu integrieren, konfigurieren Sie einfach einen Stream – und „ Quicknode “ kümmert sich um den Rest. Ganz gleich, ob Sie einen Indexer, eine Analyseplattform oder ein Echtzeit-Überwachungssystem entwickeln: „ Streams “ garantiert, dass die Daten in Ihrem Zielsystem auch während Netzwerk-Reorganisationen mit der kanonischen Kette übereinstimmen.
QuicknodeDie Core-API unterstützt zudem die Abfrage sowohl der aktuellsten als auch der endgültigen Blockdaten in allen unterstützten Netzwerken, sodass Ihre Anwendung für jeden Anwendungsfall die passende Bestätigungsstufe wählen kann. Zeigen Sie Nutzern, die sofortiges Feedback wünschen, den aktuellsten Block an, stützen Sie sich jedoch bei allen Logikabläufen, die finanzielle Entscheidungen oder unwiderrufliche Aktionen beinhalten, auf die endgültigen Blockdaten.
