Drei Blockchains in vier Tagen gestoppt: Wer darf die Pause-Taste drücken?

Autor: Liam 'Akiba' Wright, cryptoslate

Übersetzung: Saoirse, Foresight News

Innerhalb von vier Tagen haben nacheinander drei Blockchain-Netzwerke die Blockproduktion eingestellt. Bei jedem Netzwerkstopp kamen unterschiedliche Notfallbefugnisse zum Einsatz, und nur bei Cronos wurde ein Teil der offiziellen Chain-Historie umgeschrieben.

Cronos gab an, dass die Validatoren nach einem Exploit-Angriff auf das Tectonic-Protokoll das Netzwerk per Konsensmechanismus heruntergefahren, die Chain auf den Zustand vor dem Angriff zurückgesetzt und die Blockproduktion ab Blockhöhe 90.896.189 wieder aufgenommen hätten. Diese Maßnahme stoppte nicht nur die Blockproduktion, sondern schrieb auch direkt den Chain-Zustand um. Transaktionen und Zustandsänderungen, die nach dem Wiederherstellungspunkt entstanden waren, gehören nicht mehr zur offiziellen Mainchain nach dem Neustart.

Ontology und ICON griffen dagegen auf andere Notfallmaßnahmen zurück. Ontology pausierte die Blockproduktion, bevor der böswillige Angriff bestätigt war; laut Update vom 1. September verursachte die böswillige Aktivität keine Verluste bei Nutzervermögen. ICON pausierte zunächst den angegriffenen Vertrag und fuhr erst danach das gesamte Netzwerk herunter; die Stiftung erklärte, das Netzwerk habe sich während der Migrationsphase unter ihrer Kontrolle befunden, und zu diesem Zeitpunkt sei der Großteil der gestohlenen ICX bereits auf Verwahrkonten von Börsen transferiert worden.

Ein Blockchain-Stopp ist nur die erste Kontrollebene. Die tiefergehende Frage lautet: Wer ist befugt, ein Netzwerk herunterzufahren? Können sie den bestätigten Chain-Zustand umschreiben? Welche Verluste sind nicht mehr rückgängig zu machen, wenn Gelder kettenübergreifend transferiert werden oder in zentralisierte Verwahrstellen gelangen?

Vergleich der Notfallmaßnahmen der drei öffentlichen Chains Cronos, Ontology und ICON

Cronos: Vom Stopp zum Umschreiben des Chain-Zustands

Cronos bezeichnete die Maßnahme als „Notfallaktion im Validator-Konsens". Die Neustart-Ankündigung vom 31. August zeigt, dass das Netzwerk am 30. August um 23:49:01 UTC die Blockproduktion ab Blockhöhe 90.896.189 wieder aufnahm und der Chain-Zustand auf den Zeitpunkt vor dem Tectonic-Exploit zurückgesetzt wurde.

Der Stopp von Cronos bedeutet eine Verteilungsentscheidung über den Wiederherstellungspunkt. Nach dem Checkpoint wurden sowohl die mit der Schwachstelle verbundenen On-Chain-Zustände als auch alle unabhängigen Transaktionen in diesem Zeitraum aus der offiziellen Chain entfernt. Die Neustart-Ankündigung enthielt keine Transaktionsliste, keine Validator-Statistiken, keine Abstimmungsschwellen und keine Liste der beteiligten Knoten. Cronos versprach einen nachträglichen Bericht, der den Ablauf und die technischen Auswirkungen vollständig erklären soll.

Selbst der Umfang der durch diesen Eingriff tatsächlich geschützten Vermögenswerte ist noch unklar. TRM Labs schätzt, dass nach der Manipulation des TONIC-Token-Preises Vermögenswerte im Wert von etwa 75 Millionen US-Dollar ausgeliehen wurden; davon flossen etwa 6 Millionen US-Dollar nach Ethereum, und etwa 68,7 Millionen US-Dollar wurden innerhalb der Cronos-Chain zurückgerollt. Bitquery kommt auf einen höheren Gesamtabfluss: etwa 8,3 Millionen US-Dollar flossen nach Ethereum, insgesamt wurden 10.961 Blöcke verworfen.

Die beiden Statistiken erfassen unterschiedliche Objekte; die endgültigen Verlustzahlen von Tectonic stehen noch aus. Eines ist jedoch bereits klar: Der Rollback von Cronos kann nur Zustände wiederherstellen, die noch auf der eigenen Chain liegen; Vermögenswerte auf der Ethereum-Chain unterliegen vollständig außerhalb seiner Kontrolle.

Der Vermögensplan von Tectonic hinterlässt weiterhin offene Fragen bei den Nutzerkonten. Das Protokoll kündigte an, zuerst Auszahlungen und Kreditrückzahlungen freizuschalten und gleichzeitig Einzahlungen und neue Kredite zu pausieren. Dieser Plan bietet Nutzern einen Ausstiegs- und Deleveraging-Pfad, aber ob Kapitalgeber vollständig zurückgezahlt werden können, ist noch nicht bestätigt. Der noch zu veröffentlichende Bericht von Tectonic muss außerdem die Ursache der Schwachstelle, den gesamten Mittelabfluss, den Umfang der notleidenden Kredite, die bereits zurückerlangten Vermögenswerte und die verbleibenden Verbindlichkeiten klären.

Der Wiederherstellungsfortschritt der verschiedenen Infrastrukturen verläuft nicht synchron mit dem Neustart des Chain-Konsenses. Cronos wies darauf hin, dass Protokolle, Cross-Chain-Brücken, Block-Explorer und RPC-Dienste mehr Zeit zur Wiederherstellung benötigen. Auch die Statusseite von Alchemy dokumentierte den Stopp und die anschließende Wiederherstellung separat. Ein Chain-Netzwerk kann offiziell neu starten, aber die davon abhängigen Dienste sind möglicherweise noch nicht bereit.

Ontology: Stopp nur zur Zeitgewinnung, keine Transaktionsrücknahme

Die Maßnahmen von Ontology erfolgten, bevor die böswillige Aktivität bestätigt war. Das Netzwerk gab an, dass das Kernentwicklungsteam bei einer Routineinspektion ein potenzielles Sicherheitsrisiko entdeckt und die Blockproduktion sofort pausiert habe; anschließend hätten das technische Team und die Validatoren eine Systemprüfung durchgeführt.

Das Update vom 1. September besagt, dass die Prüfung einen böswilligen Angriff bestätigt habe, das Mainnet weiterhin gestoppt bleibe und Schwachstellenbehebung sowie Netzwerk-Upgrade durchgeführt würden; der Angriff habe keine Nutzervermögen geschädigt. Ontology strebt eine Wiederaufnahme des normalen Betriebs innerhalb von 24 Stunden an, sofern Sicherheitsprüfung, Schwachstellenbehebung, Upgrade und Tests vollständig erfolgreich abgeschlossen werden.

Der Stopp von Ontology behält alle bestätigten On-Chain-Zustände bei und stoppt lediglich die Bestätigung und Abwicklung neuer Transaktionen. Die Ankündigung nennt keinen Wiederherstellungspunkt und veröffentlicht auch keine Menge zu verwerfender Transaktionen.

Die öffentlich zugänglichen Befugnisinformationen sind unvollständig. Die Ankündigung erwähnt die Beteiligung des Kernentwicklungsteams, des technischen Teams und der Netzwerk-Validatoren, nennt jedoch nicht, wer letztlich entscheidungsbefugt ist, und gibt auch keine numerische Schwelle für Notfallmaßnahmen an. Die VBFT-Dokumentation von Ontology beschreibt den regulären Konsensmechanismus, einschließlich der Erzeugung bestätigter Blöcke durch Knoten und der Aktualisierung der Konsensknotenmenge über Verwaltungsverträge, aber die Dokumentation deckt nur den Normalbetrieb ab; die am 31. August verwendeten Notfall-Pausierungsregeln wurden nicht öffentlich gemacht.

Selbst ohne Vermögensverluste verursacht ein Stopp reale Kosten. Ontology teilte den Nutzern mit, dass On-Chain-Transaktionen nicht verarbeitet werden können, und riet davon ab, zeitkritische Operationen durchzuführen; später hieß es, der Netzwerkneustart hänge von Schwachstellenbehebung, Upgrade und Tests ab. Nutzer können ihre Positionen nicht on-chain anpassen oder Überweisungen abwickeln, und alle mit der Chain verbundenen externen Dienste müssen auf das Netzwerksignal warten.

Die Kriterien für die Wiederaufnahme des Betriebs sind sicherheitsorientiert, aber die Details sind begrenzt. Ontology erklärte, man strebe eine Wiederaufnahme des Dienstes innerhalb von 24 Stunden an, sobald Behebung, Upgrade, Tests und Verifizierung abgeschlossen seien; wer jedoch die Erfüllung der Bedingungen feststellt und wie hoch die Auslöseschwelle ist, wurde nicht offengelegt.

Daraus ergibt sich eine Governance-Unsicherheit: Die Ankündigung nennt die an der Prüfung beteiligten Parteien, aber das Subjekt mit der endgültigen Entscheidungsbefugnis über den Neustart bleibt unklar. Für Nutzer besteht das aktuelle Risiko in der Dienstunterbrechung, nicht in einem bestätigten Vermögensverlust oder Chain-Rollback.

ICON: Warum ein Blockchain-Stopp zu spät kam

Der Vorfall bei ICON zeigt den gesamten Ablauf von Alarmierung, Maßnahmen und dem Entgleiten der Vermögenswerte aus der Chain-Kontrolle.

Laut dem nachträglichen Bericht der Stiftung spielte der Angreifer zwischen 02:01:02 und 02:21:12 UTC am 27. August zwei historisch gültige signierte Auszahlungsnachrichten 1.492 Mal erneut ab. Ein Präzisionsfehler führte dazu, dass 1.490 dieser Aufrufe erfolgreich waren und 119,866 Millionen ICX sowie 531.600 bnUSD aus dem Vermögenspool der Stiftung transferiert wurden.

Um 02:08 Uhr löste das Überwachungssystem einen Alarm aus; die technische Untersuchung begann erst später. Der betroffene Vertrag wurde um 03:53 Uhr pausiert. Die großen Börsen stellten ab 05:54 Uhr schrittweise Ein- und Auszahlungen von ICX ein; der vollständige Netzwerkstopp trat um 06:18:54 Uhr in Kraft. ICON schloss den Neustart am 28. August gegen 07:51 Uhr ab, nach etwa 25 Stunden, und behob gleichzeitig die zugrunde liegende Schwachstelle.

Der Bericht sieht die Ursache des Problems im Incident-Response-Prozess und nicht in mangelnder Erkennungsfähigkeit. Der Alarm wurde innerhalb von sieben Minuten ausgelöst, aber solche Alarme werden häufig mit unzusammenhängenden RPC-Anomalien verwechselt, und das System benachrichtigte das Bereitschaftspersonal nicht. Die technische Untersuchung begann erst gegen 03:40 Uhr, und kurz darauf wurde der Vertrag pausiert.

Als die Chain offiziell gestoppt wurde, hatte der Großteil der betroffenen ICX bereits das Verwahrungssystem der Börsen erreicht. Die Kontrollmechanismen auf der ICON-Chain konnten die Börsen nicht daran hindern, die in ihrem Besitz befindlichen Vermögenswerte zu transferieren oder umzuwandeln. Die Stiftung ist auf das Einfrieren von Vermögenswerten durch die Börsen, Sicherungsanordnungen, Anwälte und Strafverfolgungsbehörden angewiesen.

Die Verwahrungsgrenze bestimmt unmittelbar die Verlustzuordnung. ICON erklärte, alle betroffenen Vermögenswerte gehörten der Stiftung; Einlagen, Guthaben und Positionen normaler Nutzer seien nicht berührt worden. Der Bericht zeigt, dass 531.600 bnUSD und 1,366 Millionen SODA vollständig zurückerlangt wurden; von den ausgeliehenen 113.634 USDC wurden 82.430 zurückgewonnen. Der bestätigte Nettoverlust beträgt etwa 150,2 ETH zuzüglich 31.204 USDC. Die überwiegende Mehrheit der betroffenen ICX wurde bei den Börsen lediglich eingefroren oder verfolgt, aber nicht tatsächlich zurückerlangt.

Die Kontrollarchitektur von ICON unterscheidet sich auch von den beiden anderen Fällen. Der nachträgliche Bericht stellt fest, dass das Netzwerk während der Token-Migration unter der Kontrolle der Stiftung stand; das Migrationsdokument erwähnt, dass der Konsens im Wartungsmodus mit nur sieben Kernknoten lief. Dieser Stopp stützte sich daher auf eine besondere Betriebsarchitektur, die eindeutig von der Stiftung kontrolliert wurde.

Notfallbefugnisse sind im Kern auch Macht auf Bilanzebene

Jeder Blockchain-Stopp ist im Wesentlichen eine Verlagerung von Risiken an einen anderen Ort.

• Cronos schrieb die offizielle Chain-Historie um: Dies kann Vermögenswerte schützen, die noch unter der Kontrolle der Chain stehen, verwirft aber zugleich normale On-Chain-Aktivitäten außerhalb der Schwachstelle und kann gegen Vermögenswerte auf Ethereum nichts ausrichten.
• Ontology wandelte das Risiko in Zeitkosten und Verlust der Dienstverfügbarkeit um; während der Untersuchung konnten Transaktionen nicht abgewickelt werden, und es wurden keine buchhalterischen Vermögensverluste bestätigt.
• ICON isolierte Vertrag und Netzwerk erst, nachdem die Vermögenswerte bereits aus dem Verwahrungsbereich der Chain transferiert worden waren; die bestätigten Verluste trägt die Stiftung, und die Rückholung der eingefrorenen ICX hängt von Börsen und Justizbehörden ab.

Ein einfacher Dezentralisierungs-Score würde diese völlig unterschiedlichen Ergebnisse verschleiern. Praktischere Bewertungskriterien sind: Sind die Notfallregeln öffentlich? Welche Schwelle löst die Maßnahme aus? Werden nur neue Blöcke gestoppt oder wird der bereits bestätigte Chain-Zustand umgeschrieben? Wer kontrolliert die Vermögenswerte, die zum Zeitpunkt des Eingriffs bereits außerhalb der eigenen Chain liegen? Wer verpflichtet sich, die verbleibenden Verluste zu tragen?

Cronos und Tectonic müssen noch vollständige nachträgliche Berichte veröffentlichen. Ontology muss Angriffsdetails und Notfallbefugnisregeln offenlegen und später bestätigen, ob die Bedingungen für Upgrade und Neustart erfüllt sind. Wirklich vergleichbar ist die von jedem Netzwerk gezogene Risikogrenze – welche Historie, welche Zeiträume und welche Gelder einem Risiko ausgesetzt werden.

Originalartikel