Am Abend des 22. September sendete ein Nutzer eine ATOM-Überweisung.
Nach einer vergangenen Nacht blieb die Transaktion weiterhin „wartend auf Bestätigung“.
Der private Schlüssel ging nicht verloren, und die Wallet zeigte keine Anomalien bei der Signierung. Bei einer erneuten Überprüfung am nächsten Tag zeigten mehrere öffentliche RPCs, dass Cosmos Hub bei Blockhöhe 33.086.740 stehen geblieben war.
Da keine neuen Blöcke produziert wurden, gab es natürlich auch keinen Ort, der diese Transaktion hätte paketieren können.
Erst etwa einen Tag später, nachdem Cosmos Hub die Blockproduktion wieder aufgenommen hatte, war diese ATOM-Überweisung, die sich die ganze Zeit im Wartezustand befunden hatte, schließlich erfolgreich.
Für normale Nutzer ist dies möglicherweise die intuitivste Lektion, um Blockchain-Konsens zu verstehen.
Wir sind es gewohnt zu sagen, dass „keine zentrale Institution eine öffentliche Chain abschalten kann“, aber die Realität ist offensichtlich viel komplexer. Eine ausreichend dezentralisierte Blockchain hat in der Regel zwar nicht diesen „Abschaltknopf“ in einem Serverraum, aber sie kann trotzdem stoppen.
Diese Pause von Cosmos Hub hat zufällig genau diesen Satz von Mechanismen, der normalerweise auf der darunterliegenden Ebene verborgen ist, für normale Nutzer vollständig offengelegt.
1. Warum hat Cosmos plötzlich „aufgehört, Blöcke zu produzieren“?
Zunächst ist es notwendig, eine Frage zu klären, die leicht zu Verwechslungen führt: Was diesmal direkt angegriffen wurde, war nicht Cosmos Hub.
Der Vorfall ereignete sich zuerst auf Neutron.
Am 22. September wurde ein Neutron-Governance-Vorschlag namens „AIATO: AI Agent Takeover“ verabschiedet. Der Angreifer nutzte eine Lücke in den Governance-Berechtigungen auf Chain-Ebene aus und verwendete privilegierte Anweisungen, die nativ vom wasmd-Framework bereitgestellt werden, um die Vertragsadministratoren von Anwendungen wie Astroport und Drop auf vom Angreifer kontrollierte Adressen zu ändern.
Dies ist nicht das, was wir üblicherweise als „Code-Schwachstelle“ oder „Protokollfehler“ verstehen.
Es kann einfach so verstanden werden: Die Anwendungen selbst haben ihre eigenen „Türschlösser“, aber die Chain-Ebene-Governance von Neutron besitzt auch einen „Hauptschlüssel“ mit höheren Privilegien, und wenn der Angreifer das Governance-Ergebnis kontrolliert, ist das gleichbedeutend damit, diesen Schlüssel zu erhalten, was es ihm ermöglicht, Administratoren neu zuzuweisen, Verträge zu migrieren und weiter die darin befindlichen Vermögenswerte zu übertragen.
Was Cosmos Hub tatsächlich mit hineingezogen hat, war der darauffolgende Cross-Chain-Fondstransfer.
Der Postmortem von Cosmos Labs zeigt, dass der Angreifer, bevor Neutron den Betrieb einstellte, bereits einige Vermögenswerte in mehrere Netzwerke verschoben hatte, unter denen etwa 1,7 Millionen ATOM in Cosmos Hub transferiert wurden und begannen, durch Cross-Chain-Liquidität getauscht zu werden.
Mit anderen Worten: Cosmos Hub selbst wurde nicht direkt angegriffen, und die Gelder gewöhnlicher Hub-Nutzer wurden nicht direkt wegen der Neutron-Schwachstelle gestohlen.
Aber die durch den Angriff erlangten ATOM waren bereits in den Hub gelangt, und um zu verhindern, dass die verbleibenden ATOM weiter abfließen, begannen einige Cosmos Hub-Validatoren, ihre Nodes nicht weiter zu betreiben.
Gegen etwa 19:18 Uhr am 22. September (SGT) repräsentierten die Validatoren, die den Betrieb eingestellt hatten, bereits mehr als ein Drittel der gesamten Stimmrechte, sodass Cosmos Hub keine neuen Blöcke mehr bilden konnte und schließlich bei 33.086.740 stehen blieb.
Dieser Schritt ist sehr entscheidend.
Es bedeutet, dass Cosmos Hub keinen „Pause“-Knopf hat, den irgendein Unternehmen direkt drücken kann, und es auch nicht zuerst eine On-Chain-Governance-Abstimmung durchlaufen hat. Was das Netzwerk tatsächlich zum Stillstand brachte, war, dass genügend Validatoren nicht mehr an der Konsensbildung teilnahmen.
Doch bemerkenswerter ist eigentlich der anschließende Wiederherstellungsprozess.
Etwa 4 Stunden nachdem die Chain gestoppt wurde, erhielten die Validatoren einen vollständigen Wiederherstellungsplan: eine einmalige Zustandsänderung auf der Höhe des Chain-Stopps ausführen und die verbleibenden ATOM auf der Adresse des Angreifers an eine Multisig-Adresse übertragen, die gemeinsam von Community-Validatoren verwaltet wird.
Cosmos Labs erstellte dann den Gaia v28.3.0-Patch basierend auf dem bereits von den Validatoren vereinbarten Plan, testete ihn und verteilte ihn an die Validatoren.
Diese Version von Gaia würde eine einmalige Zustandsänderung auf der angegebenen Wiederherstellungshöhe ausführen und 1.227.121 ATOM von der Adresse des Angreifers an eine 4-von-6-Multisig-Adresse übertragen, die aus sechs Parteien besteht: Nansen, Keplr, Enigma, Silknodes, Kiln und Polkachu.
Bis zum frühen Morgen des 23. September hatten Validatoren, die nachweislich v28.3.0 installiert hatten, bereits mehr als 67 % der gesamten Stimmrechte erreicht, sodass Cosmos Hub an diesem Tag um 12:00 UTC einen Neustart koordinierte. Etwa 6 Minuten später wurde diese einmalige Zustandsänderung auf Blockhöhe 33.086.741 ausgeführt und das Netzwerk nahm die normale Blockproduktion wieder auf.
Letztendlich, während des gesamten Prozesses vom Stopp der Blockproduktion durch Cosmos bis zur Wiederaufnahme des Betriebs, verursachten die Validatoren zunächst, dass das Netzwerk seine Liveness verlor, und dann akzeptierten mehr als zwei Drittel der Stimmrechte einen neuen Satz von Zustandsübergangsregeln, wodurch dieser Regelsatz schließlich zum kanonischen Zustand nach der Wiederherstellung wurde.
An diesem Punkt stellt sich eine scheinbar einfache Frage: Warum kann, obwohl es sich um eine dezentrale öffentliche Chain handelt, mehr als ein Drittel der Validierungsmacht sie stoppen, während die Wiederherstellung des Netzwerks erfordert, dass genügend Validatoren gemeinsam dieselbe Software akzeptieren und ausführen?
Die Antwort ist tatsächlich im Wort "Konsens" verborgen.
2. Sogenannter Konsens war nie "stoppt niemals"
Eines der am leichtesten missverstandenen Dinge über Blockchain ist, "Dezentralisierung" mit "geht niemals down" gleichzusetzen.
Tatsächlich löst der Konsensmechanismus wirklich wie, ohne einen zentralen Buchhalter, viele Knoten eine Einigung über Transaktionsreihenfolge und Ledger-Zustand erzielen können.
Allerdings implementieren verschiedene öffentliche Chains dies nicht auf die gleiche Weise.
Zum Beispiel ist Bitcoins klassischster Mechanismus PoW, Proof of Work – Miner konkurrieren mit Rechenleistung um die Produktion von Blöcken. Wenn kurzzeitig zwei gültige Zweige im Netzwerk erscheinen, wählen Knoten einen davon aus, um gemäß der kumulierten Arbeit weiter darauf aufzubauen.
Bitcoin hat also keinen klaren Moment, in dem "nach 67 % Abstimmung dieser Block für immer Finalisiert ist". Es ist eher eine Art probabilistische Finalität: Je mehr nachfolgende Blöcke es gibt, desto mehr Rechenleistungskosten sind erforderlich, um frühere Transaktionen zu reorganisieren und zu entfernen.
Das ist auch der Grund, warum früher gesagt wurde, dass man bei einer Bitcoin-Transaktion am besten 6 Blockbestätigungen abwartet. Schließlich kann man selbst mit höherer Rechenleistung nicht einfach die Konsensregeln umgehen, die die Knoten ausführen.
Natürlich bedeutet das nicht, dass Bitcoins Zustand unter keinen Umständen "absolut unmöglich zu ändern" ist. Theoretisch, wenn das gesamte Ökosystem einen neuen Client und neue Konsensregeln akzeptiert, ist es durch einen Hard Fork ebenfalls möglich, Zustandsänderungen, die unter den alten Regeln ungültig waren, gültig zu machen.
Aber hier liegt das Problem: Wer hat die Fähigkeit, genügend Miner, Full Nodes, Handelsplattformen, Wallets und Benutzer dazu zu bringen, gemeinsam einen solchen neuen Regelsatz zu akzeptieren?
Fast niemand.
Das Entwicklungsteam kann die Konsensregeln für das gesamte Bitcoin-Netzwerk nicht allein bestimmen, und auch Miner und Handelsplattformen können das nur schwer, weil die zu überschreitende Konsensschwelle sehr hoch ist. Als Binance für 7.000 BTC gehackt wurde, schlugen einige vor, dass CZ große Miner kontaktieren sollte, um zu operieren, aber am Ende wurde nichts daraus.
Ethereum liefert ein weiteres sehr klassisches Beispiel.
Nach dem Wechsel zu PoS verwendet Ethereum jetzt den Gasper-Konsens, der aus Casper FFG und LMD-GHOST zusammen besteht. Einfach gesagt, ein Teil des Mechanismus ist dafür verantwortlich zu bestimmen, "welcher Chain derzeit gefolgt werden soll", während der andere Teil dafür verantwortlich ist, Blöcken echte Finalität zu verleihen.
Nur wenn Validatoren, die mindestens zwei Drittel des gestakten ETH repräsentieren, dem entsprechenden Checkpoint zustimmen, kann ein Block weiter in Richtung Finalisierung fortschreiten; umgekehrt, wenn mehr als ein Drittel des Stakes über lange Zeit nicht an korrekten Abstimmungen teilnimmt, kann das Netzwerk vorübergehend keine Finalität bilden. Ethereum hat jedoch auch einen Inaktivitätsleck entworfen, der das effektive Gewicht offline befindlicher Validatoren allmählich reduziert, wenn Finalisierung über lange Zeit nicht erreicht werden kann, und dem Netzwerk so eine Chance gibt, schließlich die Finalität wiederherzustellen.
Um dieses Ergebnis wirklich zu ändern, ist es ebenso notwendig, die Protokollregeln und Clients zu ändern.
Genau wie beim The DAO-Vorfall von 2016 führte die Ethereum-Community letztendlich einen Hard Fork durch und führte bei Block 1.920.000 eine spezielle Zustandsänderung aus, die die Ethereum Foundation damals direkt als irreguläre Zustandsänderung bezeichnete und die relevanten ETH in einen Wiederherstellungsvertrag überführte.
Einige Miner und Community-Mitglieder, die sich weigerten, ein Upgrade durchzuführen, und den ursprünglichen Zustand weiter aufrechterhielten, bildeten jedoch schließlich Ethereum Classic (ETC), was zu dem bekannten ETH- und ETC-Fork führte und zeigte, dass nicht alle diese Regeln akzeptierten.
Cosmos Hub ist wieder anders. Es verwendet CometBFT, das näher an einem typischen BFT-Konsens liegt.
Es kann als ein typischerer BFT-Konsens verstanden werden, was bedeutet, dass ein Block, um wirklich committet zu werden, ein Commit von mehr als zwei Dritteln der Stimmrechte erhalten muss.
Sein Vorteil ist, dass die Finalität sehr klar ist. Sobald ein Block nach Abstimmung durch ausreichende Verifizierungsleistung committet wurde, muss nicht wie bei PoW weiter auf immer mehr Blöcke gewartet werden, um Wahrscheinlichkeit gegen ein Sicherheitsgefühl einzutauschen.
Aber seine andere Seite ist ebenso direkt: Wenn ein Drittel oder mehr der Stimmrechte die für die Bildung eines Commits erforderlichen Stimmen nicht mehr bereitstellt, können die verbleibenden Validatoren, egal wie sehr sie sich bemühen, nicht mehr als zwei Drittel zusammenbringen.
Zu diesem Zeitpunkt ist die sicherste Wahl für das Netzwerk genau die diesmal beobachtete „Pause der Blockproduktion“, sodass aus der Perspektive verteilter Systeme dieser kurze Halt des Cosmos Hub tatsächlich nicht mysteriös ist.
Mit einem Wort: Nachdem eine Gruppe von Validatoren mit ausreichendem Stimmrecht nicht mehr teilnimmt, zieht es das Konsensprotokoll gemäß seinen eigenen Regeln vor, die Verfügbarkeit zu verlieren, anstatt ohne ausreichenden Konsens weiter neue Blöcke zu bestätigen.
Dahinter entsprechen tatsächlich zwei Konzepte in verteilten Systemen, die von gewöhnlichen Nutzern oft verwechselt werden:
- Sicherheit: Verschiedene Knoten dürfen nicht gleichzeitig zwei widersprüchliche Endzustände bestätigen;
- Lebendigkeit: Ob das Netzwerk weiter voranschreiten und neue Transaktionen verarbeiten kann;
Für BFT-Systeme ist eine Pause bei unzureichender Beteiligung von Knoten am Konsens manchmal genau der Preis, der gezahlt wird, um die Sicherheit aufrechtzuerhalten. Um es deutlich zu sagen: Dieses dezentrale Ledger würde lieber zuerst dort anhalten, als dass die Verbleibenden jeweils ihre eigenen Aufzeichnungen weiterführen.
Von diesem Blickwinkel aus betrachtet wird man feststellen, dass viele scheinbar völlig unterschiedliche Vorfälle in der Geschichte öffentlicher Blockchains tatsächlich um dieselbe Sache kreisen:
Was soll das Netzwerk tun, wenn verteilte Knoten keinen Konsens mehr über den „korrekten Zustand“ bilden können?
III. Von Bitcoin bis Solana: Wo liegt die wahre Risikogrenze öffentlicher Blockchains?
Dies ist nicht das erste Mal, dass Cosmos diese Frage auf den Tisch bringt.
Bereits 2013 erlebte Bitcoin einen sehr klassischen Chain-Fork-Vorfall.
Damals wechselte Bitcoin 0.8 seine zugrunde liegende Datenbank von Berkeley DB zu LevelDB. In der Folge erschien ein Block mit einer großen Anzahl von Transaktionseingaben. Knoten der neuen Version konnten ihn normal verarbeiten, aber einige Knoten der alten Version beurteilten diesen Block aufgrund des Lock-Anzahl-Limits von Berkeley DB als ungültig.
So entstand eine sehr unangenehme Szene: Alle betrieben Bitcoin, aber die alten und neuen Clients begannen, unterschiedliche Antworten auf die Frage zu geben, „ob dieser Block legal ist oder nicht“.
Das Netzwerk spaltete sich daher in zwei Chains, und die Seite der neuen Version 0.8 hatte zeitweise etwa 60 % der Hashrate und konnte sich nicht auf normale Hashratenkonkurrenz verlassen, um schnell von selbst zu konvergieren.
Schließlich koordinierten sich große Mining-Pools, um zur alten Version zurückzukehren, gewannen auf der Seite der alten Regeln mehr Hashrate zurück, und erst dann konvergierte das Netzwerk wieder. Bitcoin überprüfte diesen Vorfall später speziell mit BIP 50.
Bis 2016 trieb der The DAO-Vorfall von Ethereum das Problem einen Schritt weiter.
Wie oben bezüglich des DAO-Vorfalls erwähnt, führte die Ethereum-Community letztendlich einen Hard Fork durch und vollzog bei Block 1.920.000 eine spezielle Zustandsänderung, die von der Ethereum Foundation ausdrücklich als irreguläre Zustandsänderung bezeichnet wird, wodurch die betreffenden ETH in einen Wiederherstellungsvertrag übertragen wurden.
Doch nicht alle waren mit dieser Vorgehensweise einverstanden. Einige Miner und Community-Mitglieder, die die Zustandsänderung nicht akzeptieren wollten, führten die ursprünglichen Regeln weiter und so entstand das bis heute bestehende Ethereum Classic (ETC).
Dieser DAO-Fork war ebenfalls ein klassisches Ereignis und kommt der Aussage gleich, dass bei extremen Ereignissen neben dem Code-Konsens auch ein sozialer Konsens existiert. Wenn keine ausreichend einheitliche Meinung gebildet werden kann, kann eine Chain tatsächlich in zwei Teile gespalten werden.
Solana im Jahr 2021 zeigte einen anderen, völlig andersartigen Fehlerpfad.
Im September jenes Jahres überschwemmte eine große Anzahl von Bot-Transaktionen das Netzwerk, wodurch den Validator-Knoten der Speicher ausging und viele Knoten abstürzten. Schließlich konnte das gesamte Netzwerk keinen Konsens über den aktuellen Zustand mehr bilden und bestätigte etwa 17 Stunden lang keine neuen Blöcke, wonach die Validatoren gemeinsam koordinierten, um das Netzwerk wiederherzustellen.
Betrachtet man diese Vorfälle zusammen, stellt man fest, dass sie nicht dasselbe sind:
- Das Problem von Bitcoin im Jahr 2013 war, dass verschiedene Clients begannen, unterschiedliche Gültigkeitsregeln durchzusetzen;
- Das Problem von Solana im Jahr 2021 war, dass eine große Anzahl von Validator-Knoten nicht mehr normal am Konsens teilnehmen konnte und das Netzwerk die Liveness verlor;
- Womit Ethereum DAO konfrontiert war, kam eher der Frage nahe, ob eine Community den Zustand aktiv durch neue Protokollregeln ändern sollte;
- Und diesmal hat der Cosmos Hub eine weitere Besonderheit: Das Netzwerk verlor zunächst aktiv durch Validator-Koordination die Liveness, um zu verhindern, dass angegriffene Vermögenswerte weiter bewegt werden; anschließend akzeptierte eine ausreichend hohe Proportion der Stimmrechte gemeinsam die neue Software und den Wiederherstellungszustand, wodurch das Netzwerk wieder einen Konsens bilden konnte;
Anstatt diese Ereignisse einfach darauf zu reduzieren, dass „Blockchains also tatsächlich abgeschaltet werden können“ oder „Dezentralisierung alles fake ist“, sollte man daher eine realere Tatsache anerkennen:
Der Konsensmechanismus war nie eine Maschine, die nicht brechen kann. Was er tatsächlich bietet, ist eigentlich eine Reihe dezentraler Regeln, etwa wer bei Meinungsverschiedenheiten über die richtige Chain entscheidet; wie viele Teilnehmer nötig sind, damit ein Zustand Finalität erlangt; ob das Netzwerk bei Fehlern beschließt, weiterzulaufen oder anzuhalten; und unter extremen Umständen, welche Art kollektiven Handelns die Betriebsregeln für die Zukunft ändern kann.
Dies hinterlässt bei diesem Cosmos-Vorfall auch eine Frage, die für normale Nutzer nachdenkenswerter ist als „ob die Chain gestoppt werden sollte“.
Abschließende Gedanken
Wir sagen oft: Not your keys, not your coins.
Diese Aussage gilt natürlich weiterhin, sie betont jedoch die Kontrolle über Vermögenswerte – solange der private Schlüssel in den eigenen Händen ist, können Wallets, Handelsplattformen oder andere Dritte keine Übertragung in Ihrem Namen signieren.
Die Voraussetzung ist, dass die Blockchain, auf der Sie sich befinden, jederzeit in der Lage sein muss, diese Signatur zu verarbeiten.
An dem Tag, an dem der Cosmos Hub aufhörte, Blöcke zu produzieren, hielten die Nutzer immer noch ihre eigenen privaten Schlüssel, und die Vermögenswerte verschwanden dadurch nicht in Luft auf, es war nur so, dass selbst wenn Sie eine Transaktion korrekt signierten, es keinen neuen Block gab, der sie akzeptierte.
Der Wiederherstellungsprozess zeigt zudem, dass sich der On-Chain-Zustand bestimmter Konten ebenfalls ändern kann, ohne dass er mit dem privaten Schlüssel der ursprünglichen Adresse signiert wurde, wenn genügend Konsens-Teilnehmer eine neue Reihe von Zustandsregeln akzeptieren.
Dies entkräftet „Not your keys, not your coins“ nicht, aber es erinnert uns daran, dass private Schlüsselsouveränität und zugrunde liegende Konsensmacht niemals dasselbe waren.
Und für Wallets gilt dasselbe.
Wallets können sicherstellen, dass private Schlüssel und Signierrechte in den Händen der Nutzer liegen, können Anomalien auf Chain-Ebene so schnell wie möglich erkennen, den Transaktionsstatus präzise anzeigen, RPC- und Node-Redundanz aufbauen und das endgültige Ergebnis von Transaktionen nach der Wiederherstellung des Netzwerks erneut bestätigen.
Aber Wallets können keinen Konsens für eine öffentliche Chain wiederherstellen, noch können sie garantieren, dass das zugrunde liegende Netzwerk niemals unterbrochen wird, geschweige denn garantieren, dass die Regeln und der Zustand auf der Chain niemals Änderungen auf Konsensebene erfahren werden.
Was ein ausgereiftes dezentrales System wirklich anstreben muss, war also möglicherweise nie „nichts kann jemals geändert werden“; im Gegenteil, es sollte diese unvollkommenen Grenzen so weit wie möglich klären: Wer kann den Konsens pausieren? Wie viel Gewicht ist erforderlich? Unter welchen Umständen ist eine Notfallintervention erlaubt?
Denn wahre Dezentralisierung kann nicht dafür sorgen, dass das System niemals auf Unfälle stößt; der Schlüssel liegt darin, dass wir selbst dann, wenn wirklich ein Unfall passiert, immer noch wissen können, wer, basierend auf welchen Regeln und mit wie viel Konsens, entschieden hat, wie dieses Ledger als Nächstes aufgezeichnet werden soll.
