MultiversX hat den Betrieb seines Mainnets ausgesetzt, nachdem ein Angreifer versuchte, ein Problem mit der Transaktions-Atomizität in der Virtual-Machine-Schicht des Netzwerks auszunutzen, wodurch ungültige Änderungen onchain aufgezeichnet wurden. Das Team hat die Blockproduktion offline genommen, einen Patch in das Shadow-Fork-Testing überführt und erklärt, eine gezielte Wiederherstellung zu prüfen. Eine bestätigte Verlustsumme wurde bislang nicht genannt.

Was MultiversX bestätigt hat

• Das Problem betraf die Transaktions-Atomizität.
• Ungültige Änderungen wurden onchain aufgezeichnet.
• Der Mainnet-Betrieb wurde ausgesetzt.
• Ein Patch ging in das Shadow-Fork-Testing.
• Eine gezielte Wiederherstellung wurde geprüft.

Was weiterhin unbekannt ist

• Ob Nutzer dauerhaft Mittel verloren haben.
• Welche Konten oder Verträge betroffen sind.
• Wie der Angreifer den Fehler ausgelöst hat.
• Welche Wiederherstellungsmethode gewählt wird.
• Wann alle Dienste wieder geöffnet werden.

Die Unterbrechung hat das Problem eingefroren – nicht rückgängig gemacht

In seinem Incident-Update erklärte MultiversX, ein Angreifer habe versucht, ein Atomizitätsproblem in der Virtual-Machine-Schicht des Mainnets auszunutzen. Die Entwickler setzten den Netzwerkbetrieb aus, während sie die entstandenen Zustandsänderungen nachverfolgten und einen Patch vorbereiteten. Eine bestätigte Verlustsumme wurde nicht genannt.

Das Stoppen der Blockproduktion verhindert, dass neue Transaktionen auf Datensätzen aufbauen die bereits fehlerhaft sein könnten. Es blockiert auch einen weiteren Versuch mit derselben Methode, während die Ingenieure ermitteln, welche Guthaben oder Vertragseinträge betroffen sind.

Die Pause macht die bereits akzeptierten Änderungen des Netzwerks nicht rückgängig. Diese Datensätze bleiben der Ausgangspunkt, den Wallets, Anwendungen und Bridges verwenden, bis MultiversX einen Wiederherstellungsplan beschließt.

Bei einer Prüfung am 20. September stufte die MultiversX-Statusseite das System als teilweise eingeschränkt ein. Die öffentliche API, xPortal, Explorer, Wallet, Bridge, xExchange und xLaunchpad zeigten eine eingeschränkte Leistung, während Gateway und Index als betriebsbereit aufgeführt waren.

Diese Bezeichnungen beschreiben einzelne Dienste und bestätigen nicht, dass die normale Transaktionsverarbeitung wieder aufgenommen wurde. Die Wiederherstellung der Schnittstellen würde zudem das zugrunde liegende Buchhaltungsproblem nicht lösen. Um zu verstehen, warum, lohnt ein Blick auf die Transaktions-Atomizität.

Atomizität ist die Blockchain-Version von „alles oder nichts“

Eine Smart-Contract-Transaktion kann mehrere verbundene Operationen enthalten. Ein Guthaben könnte reduziert, ein anderes erhöht und ein Liquiditätspool aktualisiert werden. Die atomare Ausführung erfordert, dass die vollständige Sequenz erfolgreich ist, bevor eine dieser Änderungen dauerhaft wird.

Erwartetes Ergebnis: Jeder erforderliche Schritt ist erfolgreich, und alle Änderungen werden gemeinsam übernommen. Schlägt ein Schritt fehl, sollte keine der Änderungen der Transaktion übernommen werden.

Atomizitätsfehler: Eine Operation schlägt fehl, aber eine frühere Zustandsänderung bleibt bestehen. Das Netzwerk kann dann ein Teilergebnis aufzeichnen, das für sich allein nicht hätte existieren dürfen.

Dies ist ein vereinfachtes Beispiel für Atomizität, keine Rekonstruktion des MultiversX-Vorfalls. Eine fehlerhafte Transaktion könnte ein Kontoguthaben, eine Token-Versorgung oder einen Vertragseintrag inkonsistent mit dem beabsichtigten Ergebnis hinterlassen. MultiversX hat nicht offengelegt, welche Art von Daten verändert wurde, daher gibt es nicht genügend Beweise, um zu sagen, dass der Angreifer Token erstellt, einen bestimmten Vertrag geleert oder einen bekannten Betrag gestohlen hat.

Finalität beweist Einigkeit, nicht fehlerfreie Ausführung

Blockchain-Finalität bedeutet, dass Validatoren sich darauf geeinigt haben, welcher Block und welcher resultierende Zustand zur kanonischen Kette gehören. Sie beweist nicht, dass die zur Berechnung dieses Zustands verwendete Software frei von Defekten war.

Validatoren führen dieselben Protokollregeln aus und vergleichen ihre Ergebnisse. Enthalten diese Regeln denselben Fehler auf jedem Knoten, können Validatoren übereinstimmend ein Ergebnis billigen, das das Protokoll nie zulassen sollte. Der Konsens kann feststellen, welchen Zustand das Netzwerk akzeptiert hat; er kann nicht garantieren, dass kein Softwarefe zu diesem Zustand beigetragen hat.

Die Installation korrigierter Software verhindert, dass derselbe Ausführungspfad erneut funktioniert, entscheidet aber nicht, was mit den bereits aufgezeichneten Änderungen geschehen soll. MultiversX muss die betroffenen Einträge identifizieren und den Validatoren eine reproduzierbare Möglichkeit geben, zu überprüfen, dass nicht betroffene Aktivitäten unverändert bleiben.

Der Shadow Fork bietet eine Generalprobe vor dem Mainnet-Neustart

MultiversX hat einen Patch für Tests in einer Shadow-Fork-Umgebung vorbereitet. Ein Shadow Fork kopiert den relevanten Mainnet-Verlauf und Zustand in eine isolierte Umgebung, sodass Ingenieure echte Netzwerkbedingungen reproduzieren können, ohne mit Live-Guthaben zu experimentieren.

Das Team kann den Patch anwenden, die betroffene Sequenz wiedergeben und eine vorgeschlagene Wiederherstellung testen, bevor Validatoren ihn im Mainnet installieren. Dieser Prozess sollte klären:

• Ob Knoten denselben reparierten Zustand berechnen.
• Ob nicht betroffene Guthaben unverändert bleiben.
• Ob Anwendungen die korrigierten Datensätze korrekt lesen.
• Ob Bridges und Börsen ihre Daten abgleichen können.
• Ob Validatoren neu starten können, ohne konkurrierende Ketten zu erzeugen.

Das Bestehen dieser Tests würde nicht alle Dienste automatisch wieder öffnen. Der Einsatz erfordert weiterhin Koordination zwischen Validatoren, Börsen, Bridges und den Infrastrukturanbietern, die Nutzer und Anwendungen mit MultiversX verbinden.

Eine gezielte Reparatur würde das Zurückwickeln der gesamten Kette vermeiden

MultiversX erklärte, es prüfe eine gezielte Wiederherstellung, die den finalisierten Transaktionsverlauf und legitime Nutzerdatensätze bewahren soll, während nur die mit dem Vorfall verbundenen Änderungen behandelt werden. Das Projekt hat nicht erklärt, wie diese Korrektur umgesetzt würde.

Gezielte Zustandskorrektur. Nur Guthaben, Vertragsspeicher oder andere mit dem Vorfall verbundene Datensätze würden repariert, und nicht betroffene Transaktionen könnten im finalisierten Verlauf bleiben. Die Hauptschwierigkeit besteht darin zu beweisen, dass die Korrektur jede ungültige Änderung umfasst – und nichts anderes.

Breites Ketten-Rollback. Das Netzwerk würde zu einem früheren Block zurückkehren und von dort neu aufbauen. Transaktionen, die nach diesem Punkt abgeschlossen wurden, könnten verschwinden, selbst wenn sie keinen Bezug zum Vorfall hatten. Die Hauptschwierigkeit: Legitime Überweisungen und Anwendungsaktivitäten müssten möglicherweise wiederholt oder abgeglichen werden.

Die Kosten eines breiteren Rollbacks zeigten sich nach dem Tectonic-Exploit, als Cronos-Validatoren fast 11.000 Blöcke entfernten, die knapp zwei Stunden abdeckten. Das Rollback machte den Großteil der auf Cronos noch aufgezeichneten, vorfallsbezogenen Kredite rgängig, aber auch nicht betroffene Transaktionen aus diesem Zeitraum. Die beiden Vorfälle haben unterschiedliche Ursachen; das Cronos-Beispiel ist hier relevant, weil es die Nebenkosten des Zurückwickelns eines gemeinsamen Ledgers zeigt.

MultiversX erklärt, eine engere Reparatur zu erwägen, hat aber noch nicht gezeigt, wie die betroffenen Datensätze isoliert würden. Eine gezielte Reparatur würde die ursprünglichen Blöcke nicht unbedingt löschen: Der Transaktionsverlauf könnte sichtbar bleiben, während eine koordinierte Protokolländerung den Zustand festlegt, den Anwendungen und Validatoren nach dem Neustart erkennen werden. Die Methode lässt sich erst richtig bewerten, wenn MultiversX seinen Wiederherstellungsentwurf veröffentlicht.

Was MultiversX-Nutzer während der Pause tun sollten

Für gewöhnliche Halter lautet die einfachste Anweisung: warten. MultiversX hat Nutzer nicht gebeten, Token zu migrieren, Wallets mit einer Wiederherstellungs-Website zu verbinden oder eine Korrekturtransaktion zu genehmigen.

• Keine Transaktionen einreichen oder erneut übertragen.
• Kein EGLD oder ESDT über Börsen einzahlen oder abheben.
• Diese Assets nicht über Cross-Chain-Bridges bewegen.
• Den Transaktionshash für alles aufbewahren, was in der Nähe der Unterbrechung eingereicht wurde.
• Wiederherstellungslinks, Migrationen und unaufgeforderte Support-Nachrichten ignorieren.
• Auf die Bestätigung der Wiedereröffnung durch MultiversX und die jeweilige Plattform warten.

Eine Netzwerkreparatur würde von Validatoren und Infrastrukturbetreibern übernommen. Sie würde nicht verlangen, dass Nutzer Seed-Phrasen preisgeben oder Assets an eine neue Adresse senden.

Wallets und Explorer benötigen nach Wiederaufnahme der Blockproduktion möglicherweise Zeit zur Resynchronisierung. Ein veraltetes Guthaben oder eine fehlende aktuelle Transaktion in einer Schnittstelle zeigt nicht für sich genommen, dass sich die zugrunde liegenden Assets geändert haben.

Ein Neustart muss überprüfbar sein

Der Neustart der Blockproduktion stellt die Verfügbarkeit wieder her, beantwortet aber allein nicht die Frage der Finalität. MultiversX muss weiterhin offenlegen, welche Konten oder Verträge betroffen waren, wie der reparierte Zustand berechnet wurde und wie Validatoren unabhängig voneinander dasselbe Ergebnis erreicht haben.

Wenn dieser Nachweis zeigt, dass nur vorfallsbezogene Änderungen korrigiert wurden, kann eine gezielte Wiederherstellung mehr legitime Aktivität bewahren als ein breites Rollback. Ohne ihn könnte das Netzwerk den Betrieb aufnehmen, während Nutzer nicht überprüfen können, warum einige finalisierte Änderungen verändert und andere beibehalten wurden.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Netzwerkbedingungen und Wiederherstellungsanweisungen können sich ändern, während MultiversX weitere Updates veröffentlicht.