- Cardano hatte einen kurzfristigen Chain Split, ausgelöst durch eine fehlerhafte Delegationstransaktion, die unterschiedliche Node-Versionen verschieden behandelten.
- Ein Stake Pool Operator bekannte sich öffentlich zu dem Vorfall, nachdem der Fehler massive Störungen im Netzwerk ausgelöst hatte.
- Die Entwickler schlossen die Lücke schnell und brachten die Kette mit einem Hard Fork wieder zusammen, während ADA nur leicht nachgab.
Die Cardano-Blockchain musste nach einem Validierungsfehler kurzfristig in zwei Stränge getrennt werden. Die Entwickler griffen noch am selben Tag ein und stellten den regulären Betrieb wieder her.
Fehlvalidierung führt zu Kettenspaltung
Der Vorfall begann, als eine fehlerhaft aufgebaute Delegationstransaktion auf neueren Node-Versionen akzeptiert wurde. Ältere Installationen lehnten dieselben Daten ab. Dadurch entstanden zwei parallele Blockchains, die zunächst beide Blöcke produzierten. Die Governance-Organisation Intersect erklärte, dass ein Fehler in einer Bibliothek die Validierung umging und die Transaktion dadurch überhaupt erst in den Ledger gelangte.
Entwickler und Stake Pool Betreiber stellten klar, dass die Blockproduktion zu keinem Zeitpunkt vollständig zum Erliegen kam. Beide Stränge liefen weiter, bis ein koordinierter Eingriff der Betreiber den fehlerhaften Zweig stoppte. Die Korrektur erfolgte mit einem Hard Fork, der alle Nodes auf eine gemeinsame Version zurückführte.
Charles Hoskinson erklärte öffentlich, dass die Wallet hinter der fehlerhaften Transaktion innerhalb weniger Stunden identifiziert wurde. Die verantwortliche Person nutzte ein altes Testnet-Wallet und erzeugte die Transaktion in einem Experiment, das deutlich weiter ging als beabsichtigt. Ermittlungsbehörden wurden informiert. Die Entwickler betonten, dass der fehlerhafte Zweig zeitweise mehr Stake sammelte und sich dadurch schneller ausbreitete als die reguläre Kette.
Reaktionen aus Community und Markt
Ein Betreiber, der sich im Netz mit dem Namen Homer präsentierte, bekannte sich zu dem Versuch. Er schrieb, dass er eine fehlerhafte Transaktion bewusst testete, ohne die möglichen Folgen einzuschätzen. Er erklärte, dass er mit blockiertem Serververkehr und unzuverlässigen Anleitungen experimentierte. Das führte dazu, dass alte und neue Node-Versionen unterschiedlich reagierten. Seine öffentliche Entschuldigung betonte, dass keine Absicht zur Schädigung bestand.
Die Entwickler verwiesen darauf, dass alle Stake Pool Betreiber dringend auf Version 10.5.3 aktualisieren müssen. Erst dann lassen sich die beiden Stränge vollständig zusammenführen. In einer Community-Ansprache hob Hoskinson die Stabilität des Protokolls hervor, denn der Angriff führte weder zu einem Stillstand noch zu einem dauerhaften Datenverlust.
ADA reagierte nach der Meldung des Validierungsfehlers mit einem Rückgang von knapp sechs Prozent. Das liegt im üblichen Rahmen früherer technischer Zwischenfälle im Netzwerk. Historisch zeigt Cardano eine zügige Erholung nach technischen Korrekturen. Bereits nach dem „Epoch Boundary Issue“ im Jahr 2020 normalisierten sich Kurs und Netzwerkaktivität innerhalb weniger Tage.
Auch andere große Blockchains wie Ethereum haben vergleichbare kurzfristige Fork-Szenarien erlebt, etwa bei Client-Fehlern oder unvollständigen Updates. In allen Fällen wurden die Ketten durch Hard Forks wieder vereinigt.
Folgen rund um Technik und Betrieb
Die Korrekturmaßnahmen konzentrieren sich jetzt auf einheitliche Nodestände und eine gründliche Analyse der fehlerhaften Bibliothek. Entwickler arbeiten an neuen Prüfmechanismen, die ähnliche Validierungsfehler künftig direkt abfangen sollen. Der Vorfall zeigt, wie sensibel Proof-of-Stake-Netzwerke auf unterschiedliche Softwarestände reagieren, wenn Validierungslogik nicht vollständig synchronisiert ist.
Stake Pool Betreiber müssen ihre Systeme zeitnah aktualisieren, um weitere Divergenzen auszuschließen. Die Systeme werden außerdem auf weitere potenzielle Grenzfälle getestet, bei denen alte und neue Versionen unterschiedliche Entscheidungen treffen könnten. Die schnelle Reaktion der Betreiber und der zentrale Eingriff über einen koordinierten Hard Fork gelten als entscheidender Grund dafür, dass nur begrenzte Schäden entstanden sind.
