Am Abend des 22. September schickte ein Benutzer eine ATOM-Überweisung.
Eine Nacht verging und die Transaktion wartete immer noch „auf Bestätigung“.
Der private Schlüssel ging nicht verloren und es gab keine Signaturausnahme im Wallet. Bei einer erneuten Überprüfung am nächsten Tag zeigten mehrere öffentliche RPCs, dass der Cosmos Hub bei Blockhöhe 33.086.740 anhielt.
Wenn kein neuer Block generiert wird, gibt es natürlich keinen Ort, an dem diese Transaktion verpackt werden kann.
Erst als Cosmos Hub etwa einen Tag später die Blockproduktion wieder aufnahm, war der wartende ATOM-Transfer endlich erfolgreich.
Für normale Benutzer ist dies möglicherweise die intuitivste Lektion zum Verständnis des Blockchain-Konsenses.
Wir sind es gewohnt zu sagen, dass „keine zentrale Organisation eine öffentliche Kette schließen kann“, aber die Realität ist offensichtlich viel komplizierter. Eine ausreichend dezentrale Blockchain verfügt in der Regel nicht über den „Shutdown-Knopf“ im Serverraum, es kann aber trotzdem passieren, dass sie stoppt.
Die Aussetzung von Cosmos Hub hat dieses Mal diesen Mechanismus, der normalerweise unten verborgen ist, für normale Benutzer vollständig offengelegt.
1. Warum hat Cosmos plötzlich „aufgehört, Blöcke zu produzieren“?
Zunächst müssen wir ein leicht verwirrendes Problem klären. Diesmal wurde nicht der Cosmos Hub direkt angegriffen.
Der Vorfall ereignete sich erstmals in Neutron.
Am 22. September wurde ein Neutron-Governance-Vorschlag mit dem Titel „AIATO: AI Agent Takeover“ verabschiedet. Der Angreifer nutzte die Lücken in den Governance-Berechtigungen auf Kettenebene und nutzte die vom wasmd-Framework nativ bereitgestellten privilegierten Anweisungen, um die Vertragsadministratoren von Anwendungen wie Astroport und Drop auf vom Angreifer kontrollierte Adressen umzustellen.
Dies ist nicht die Art von „Code-Schwachstelle“ oder „Protokollfehler“, die wir normalerweise verstehen.
Es kann einfach verstanden werden, dass die Anwendung selbst über ein eigenes „Türschloss“ verfügt, aber die Governance auf Kettenebene von Neutron verfügt auch über einen „Hauptschlüssel“ mit höherer Autorität. Wenn der Angreifer die Governance-Ergebnisse kontrolliert, ist dies gleichbedeutend mit dem Erhalten dieses Schlüssels und kann den Administrator neu benennen, den Vertrag migrieren und die Vermögenswerte weiter übertragen.
Was Cosmos Hub wirklich involvierte, war der anschließende kettenübergreifende Geldtransfer.
Die Überprüfung durch Cosmos Labs zeigt, dass der Angreifer einige Vermögenswerte auf mehrere Netzwerke übertragen hatte, bevor Neutron nicht mehr ausgeführt wurde. Etwa 1,7 Millionen ATOMs wurden an Cosmos Hub übertragen und begannen mit dem Austausch über kettenübergreifende Liquidität.
Mit anderen Worten: Der Cosmos Hub selbst wurde nicht direkt angegriffen und die Gelder gewöhnlicher Hub-Benutzer wurden aufgrund der Neutron-Sicherheitslücke nicht direkt gestohlen.
Das durch den Angriff erhaltene ATOM hat jedoch bereits den Hub betreten. Um zu verhindern, dass das verbleibende ATOM herausfließt, begannen einige Cosmos Hub-Validatoren, den Knotenbetrieb zu stoppen.
Am 22. September (SGT) gegen 19:18 Uhr stellten die gestoppten Validatoren mehr als ein Drittel der gesamten Stimmrechte dar, und Cosmos Hub war daher nicht in der Lage, mit der Bildung neuer Blöcke fortzufahren, und blieb schließlich bei 33.086.740 stehen.
Dieser Schritt ist sehr kritisch.
Das bedeutet, dass es keine „Pause“-Schaltfläche gibt, auf die ein Unternehmen direkt im Cosmos Hub klicken kann, und dass es auch nicht zuerst eine On-Chain-Governance-Abstimmung durchläuft. Was das Netzwerk wirklich stoppt, ist, wenn nicht mehr genügend Validatoren an der Konsensbildung beteiligt sind.
Bemerkenswerter ist jedoch der anschließende Genesungsprozess.
Ungefähr vier Stunden nach der Unterbrechung der Kette erhielt der Verifizierer einen vollständigen Wiederherstellungsplan: Führen Sie eine einmalige Statusänderung für die Höhe der Kettenunterbrechung durch und übertragen Sie das verbleibende ATOM in der Adresse des Angreifers an eine Adresse mit mehreren Signaturen, die gemeinsam von Community-Validatoren verwaltet wird.
Cosmos Labs erstellte dann den Gaia v28.3.0-Patch basierend auf der von den Prüfern erzielten Lösung, testete ihn und verteilte ihn an die Prüfer.
Diese Version von Gaia führt eine einmalige Statusänderung bei der angegebenen Wiederherstellungshöhe durch und überträgt 1.227.121 ATOM in der Adresse des Angreifers an eine 4-von-6-Multisignaturadresse bestehend aus Nansen, Keplr, Enigma, Silknodes, Kiln und Polkachu.
Am frühen Morgen des 23. September hatte die Anzahl der Validatoren, denen bestätigt wurde, dass sie v28.3.0 installiert hatten, 67 % der gesamten Stimmrechte überschritten. Daher koordinierte der Cosmos Hub an diesem Tag um 12:00 UTC einen Neustart. Etwa 6 Minuten später wurde diese einmalige Statusänderung bei Blockhöhe 33.086.741 ausgeführt und das Netzwerk kehrte zur normalen Blockproduktion zurück.
Letztendlich waren es während des gesamten Prozesses von der Einstellung der Blockproduktion durch Cosmos bis zur Wiederaufnahme des Betriebs zunächst die Validatoren, die dafür sorgten, dass das Netzwerk an Lebendigkeit verlor, und dann akzeptierten mehr als zwei Drittel der Stimmberechtigten ein neues Regelwerk für den Zustandsübergang, wodurch dieses Regelwerk letztlich zum wiederhergestellten kanonischen Zustand wurde.
An diesem Punkt stellt sich eine scheinbar einfache Frage: Da es sich um eine dezentrale öffentliche Kette handelt, warum können mehr als ein Drittel der Verifizierungsrechte sie stoppen, und um das Netzwerk wiederherzustellen, müssen genügend Validatoren denselben Softwaresatz akzeptieren und ausführen?
Die Antwort liegt tatsächlich im Wort „Konsens“.
2. Der sogenannte Konsens heißt nicht „niemals aufhören“.
Eines der am meisten missverstandenen Dinge im Zusammenhang mit Blockchain ist, dass „Dezentralisierung“ mit „niemals Ausfallzeiten“ gleichgesetzt wird.
Tatsächlich besteht das Problem, das der Konsensmechanismus wirklich löst, darin, wie viele Knoten ohne einen zentralen Buchhalter eine Einigung über die Transaktionssequenz und den Ledgerstatus erzielen können.
Allerdings setzen verschiedene öffentliche Ketten dies auf unterschiedliche Weise um.
Das klassischste Beispiel für Bitcoin ist PoW, ein Arbeitsnachweis – Miner konkurrieren um die Produktion von Blöcken basierend auf der Rechenleistung. Wenn in kurzer Zeit zwei Rechtszweige im Netzwerk erscheinen, wählt der Knoten einen von ihnen aus, um entsprechend der akkumulierten Arbeitslast mit dem Aufbau fortzufahren.
Daher gibt es bei Bitcoin keinen klaren „Dieser Block wird nach 67 % der Stimmen für immer endgültig sein“-Moment. Es liegt näher an einer probabilistischen Endgültigkeit. Je mehr Folgeblöcke es gibt, desto höher und höher wird der Rechenleistungsaufwand für die Neuorganisation der vorherigen Transaktionen sein.
Aus diesem Grund sagte jeder, dass es für eine Bitcoin-Transaktion am besten sei, 6 Blöcke auf die Bestätigung zu warten. Denn egal wie hoch die Rechenleistung ist, sie kann die von den Knoten ausgeführten Konsensregeln nicht einfach umgehen.
Dies bedeutet natürlich nicht, dass der Zustand von Bitcoin unter keinen Umständen „absolut unveränderbar“ ist. Wenn das gesamte Ökosystem durch Hard Fork einen neuen Satz von Kunden und neue Konsensregeln akzeptiert, können theoretisch auch Statusänderungen gültig gemacht werden, die nach früheren Regeln ungültig waren.
Aber hier ist die Frage: Wer hat die Fähigkeit, genügend Miner, Full Nodes, Handelsplattformen, Wallets und Benutzer dazu zu bringen, solch ein neues Regelwerk zu akzeptieren?
Kaum.
Das Entwicklungsteam kann nicht über die Konsensregeln für das gesamte Bitcoin-Netzwerk entscheiden. Auch für Miner und Handelsplattformen ist es schwierig, da die Konsensschwelle, die überschritten werden muss, sehr hoch ist. Als 7.000 BTC von Binance gestohlen wurden, schlugen einige Leute vor, dass CZ mit großen Bergleuten Kontakt aufnehmen sollte, um den Betrieb aufzunehmen, aber am Ende passierte nichts.
Ethereum ist ein weiteres klassisches Beispiel.
Nach der Umstellung auf PoS nutzt Ethereum nun den Gasper-Konsens bestehend aus Casper FFG und LMD-GHOST. Um es einfach zu verstehen: Ein Teil des Mechanismus ist dafür verantwortlich, zu bestimmen, „welche Kette derzeit befolgt werden soll“, während der andere Teil dafür verantwortlich ist, dass der Block im wahrsten Sinne des Wortes Endgültigkeit erlangt.
Wenn die Validatoren, die mindestens zwei Drittel der eingesetzten ETH repräsentieren, eine Einigung über den entsprechenden Kontrollpunkt erzielen, kann der Block weiter in Richtung Finalisierung voranschreiten; Umgekehrt kann es sein, dass das Netzwerk vorübergehend nicht in der Lage ist, eine endgültige Entscheidung zu treffen, wenn mehr als ein Drittel der Einsätze längere Zeit nicht an der korrekten Abstimmung teilnehmen. Allerdings hat Ethereum auch ein Inaktivitätsleck entwickelt, um das effektive Gewicht von Offline-Validatoren schrittweise zu reduzieren, wenn die Finalisierung über einen längeren Zeitraum nicht abgeschlossen werden kann, was dem Netzwerk eine Chance gibt, die Finalität endlich wiederherzustellen.
Um dieses Ergebnis wirklich zu ändern, müssen Sie auch die Protokollregeln und den Client ändern.
Genau wie beim DAO-Vorfall im Jahr 2016 implementierte die Ethereum-Community schließlich eine spezielle Zustandsänderung namens „Unregelmäßige Zustandsänderung“ durch die Ethereum Foundation bei Block 1.920.000 über Hard Fork und übertrug die entsprechende ETH in den Wiederherstellungsvertrag.
Allerdings gründeten einige Miner und Gemeinden, die sich weigerten, ein Upgrade durchzuführen und den ursprünglichen Zustand weiterhin beizubehalten, schließlich Ethereum Classic (ETC), was zur bekannten Abspaltung von ETH und ETC führte, was darauf hindeutet, dass nicht jeder dieses Regelwerk akzeptiert.
Cosmos Hub ist wieder anders. Es verwendet CometBFT, was einem typischen BFT-Konsens näher kommt.
Es kann als typischerer BFT-Konsens verstanden werden, d. h. damit ein Block wirklich eingereicht werden kann, muss er einen Commit von mehr als zwei Dritteln der Stimmrechte erhalten.
Sein Vorteil ist, dass die Endgültigkeit sehr klar ist. Sobald ein Block durch Abstimmung mit ausreichenden Verifizierungsrechten eingereicht wurde, besteht keine Notwendigkeit, weiter auf immer mehr Blöcke wie PoW zu warten und Wahrscheinlichkeit gegen ein Gefühl der Sicherheit einzutauschen.
Aber auch die andere Seite ist ganz einfach: Wenn ein Drittel oder mehr der Stimmrechte nicht mehr die für die Bildung eines Commits erforderlichen Stimmen liefern, werden die verbleibenden Validatoren nicht in der Lage sein, mehr als zwei Drittel zu bekommen, egal wie hart sie arbeiten.
Die sicherste Wahl für das Netzwerk besteht derzeit darin, die Blockproduktion dieses Mal anzuhalten. Aus der Sicht eines verteilten Systems ist diese kurze Aussetzung von Cosmos Hub also eigentlich nicht rätselhaft.
Mit einem Wort: Nachdem eine Gruppe von Validatoren mit ausreichender Stimmmacht ihre Teilnahme eingestellt hat, würde das Konsensprotokoll gemäß seinen eigenen Regeln lieber die Verfügbarkeit verlieren, als weiterhin neue Blöcke ohne ausreichenden Konsens zu bestätigen.
Dahinter verbergen sich tatsächlich zwei Konzepte in verteilten Systemen, die von normalen Benutzern häufig verwechselt werden:
Sicherheit: Verschiedene Knoten können nicht gleichzeitig zwei widersprüchliche Endzustände bestätigen;
Lebendigkeit: Kann das Netzwerk weiter voranschreiten und neue Transaktionen verarbeiten?
Wenn beim BFT-System nicht genügend Knoten am Konsens teilnehmen, ist die Aussetzung manchmal der Preis, der für die Aufrechterhaltung der Sicherheit gezahlt wird. Um es ganz klar auszudrücken: Dieses dezentrale Hauptbuch würde hier lieber aufhören, als den verbleibenden Leuten ihre eigenen Konten zu überlassen.
Wenn Sie aus dieser Perspektive zurückblicken, werden Sie feststellen, dass sich viele scheinbar völlig unterschiedliche Unfälle in der Geschichte öffentlicher Ketten tatsächlich um dasselbe drehen:
Was macht das Netzwerk, wenn sich verteilte Knoten nicht mehr auf den „richtigen Zustand“ einigen können?
3. Wo liegt von Bitcoin bis Solana die tatsächliche Risikogrenze öffentlicher Ketten?
Dies ist nicht das erste Mal, dass Cosmos dieses Problem auf den Tisch bringt.
Bereits 2013 kam es bei Bitcoin zu einem ganz klassischen Chain-Fork-Unfall.
Zu diesem Zeitpunkt stellte Bitcoin 0.8 die zugrunde liegende Datenbank von Berkeley DB auf LevelDB um, und dann erschien ein Block mit einer großen Anzahl von Transaktionseingaben. Die neue Version des Knotens konnte ihn normal verarbeiten, aber einige Knoten der alten Version beurteilten den Block aufgrund der Begrenzung der Anzahl der Berkeley DB-Sperren als ungültig.
Es entstand also eine sehr peinliche Szene. Jeder nutzte Bitcoin, aber die alten und neuen Kunden begannen unterschiedliche Antworten auf die Frage zu haben, „ob dieser Block legal ist.“
Infolgedessen teilte sich das Netzwerk in zwei Ketten auf, und die Seite der neuen Version 0.8 verfügte einst über etwa 60 % der Rechenleistung und konnte sich nicht auf den normalen Wettbewerb um die Rechenleistung verlassen, um schnell von selbst zu konvergieren.
Am Ende koordinierten sich große Mining-Pools, um wieder auf die alte Version umzusteigen, wodurch mehr Rechenleistung auf der Seite der alten Regeln zurückgewonnen wurde, und das Netzwerk konvergierte erneut. Später untersuchte Bitcoin den Vorfall mit BIP 50 konkret.
Im Jahr 2016 verschärfte der DAO-Vorfall in Ethereum das Problem noch einen Schritt weiter.
Wie oben im Abschnitt „Der DAO-Vorfall“ erwähnt, hat die Ethereum-Gemeinschaft schließlich durch Hard Fork bei Block 1.920.000 eine spezielle Zustandsänderung implementiert, die ausdrücklich als irreguläre Zustandsänderung bezeichnet wird, und die entsprechende ETH in den Wiederherstellungsvertrag übertragen.
Doch nicht alle waren mit dieser Entscheidung einverstanden. Einige Bergleute und Gemeinden, die sich weigerten, die Statusänderung zu akzeptieren, behielten weiterhin die ursprünglichen Regeln bei, und später entstand das langjährige Ethereum Classic (ETC).
Dieser DAO-Fork ist auch ein klassisches Ereignis, was bedeutet, allen zu sagen, dass es bei extremen Ereignissen neben dem Code-Konsens auch einen sozialen Konsens gibt. Wenn keine hinreichend konsistente Meinung gebildet werden kann, kann eine Kette tatsächlich in zwei Teile geteilt werden.
Der Solana 2021 zeigt einen völlig anderen Ausfallpfad.
Im September dieses Jahres strömten zahlreiche Robotertransaktionen in das Netzwerk, was dazu führte, dass der Speicher des Verifizierungsknotens erschöpft war und eine große Anzahl von Knoten abstürzte. Letztendlich konnte das gesamte Netzwerk keinen Konsens über den aktuellen Status erzielen und bestätigte etwa 17 Stunden lang keine neuen Blöcke mehr. Dann arbeiteten die Validatoren zusammen, um das Netzwerk wiederherzustellen.
Wenn Sie diese Unfälle zusammenfassen, werden Sie feststellen, dass sie nicht dasselbe sind:
Das Problem mit Bitcoin im Jahr 2013 besteht darin, dass verschiedene Clients beginnen, unterschiedliche Gültigkeitsregeln zu implementieren;
Das Problem von Solana im Jahr 2021 besteht darin, dass eine große Anzahl von Verifizierungsknoten nicht weiterhin normal am Konsens teilnehmen kann und das Netzwerk an Lebendigkeit verliert;
Womit Ethereum DAO konfrontiert ist, ist eher die Frage, ob eine Community den Status durch neue Protokollregeln aktiv ändern sollte;
Dieses Mal bietet Cosmos Hub eine weitere Ebene der Besonderheit. Das Netzwerk verliert zunächst aktiv seine Lebendigkeit durch Validatorkoordination, um zu verhindern, dass sich die Angriffsressourcen weiter bewegen. dann akzeptiert ein ausreichend hoher Anteil an Verifizierungsrechten gemeinsam neue Software und stellt den Zustand wieder her, wodurch das Netzwerk wieder konsistent wird;
Anstatt diese Vorfälle einfach auf „Blockchains können heruntergefahren werden“ und „Dezentralisierung ist eine Fälschung“ zurückzuführen, ist es daher besser, eine realere Tatsache zuzugeben:
Der Konsensmechanismus ist niemals eine unzerstörbare Maschine. Was es wirklich bietet, ist eine Reihe dezentraler Regeln, z. B. wer im Falle einer Meinungsverschiedenheit über die richtige Kette entscheidet; Wie viele Teilnehmer können ein Staatsfinale erreichen? Wenn ein Fehler auftritt, entscheidet sich das Netzwerk dafür, den Betrieb fortzusetzen oder anzuhalten. und im Extremfall, welche Art von kollektiver Aktion die nächsten Betriebsregeln ändern kann.
Dies führt auch dazu, dass dieser Cosmos-Vorfall eine Frage hinterlässt, die für normale Benutzer eine größere Überlegung wert ist als „Sollte die Kette gestoppt werden?“
schreibe am Ende
Wir sagen oft: Nicht Ihre Schlüssel, nicht Ihre Münzen.
Natürlich gilt dieser Satz immer noch, aber er betont die Vermögenskontrolle – solange der private Schlüssel in Ihren eigenen Händen ist, können Wallets, Handelsplattformen oder andere Dritte normalerweise keine Überweisung für Sie signieren.
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 Cosmos Hub die Produktion von Blöcken einstellt, behalten die Benutzer weiterhin ihre privaten Schlüssel und die Vermögenswerte verschwinden nicht aus dem Nichts. Doch selbst wenn Sie eine Transaktion korrekt signieren, gibt es keinen neuen Block, um sie zu akzeptieren.
Der Wiederherstellungsprozess erklärt weiter, dass sich der On-Chain-Status eines bestimmten Kontos auch ohne die Signatur des privaten Schlüssels der ursprünglichen Adresse ändern kann, wenn genügend Konsensteilnehmer einen neuen Satz von Statusregeln akzeptieren.
Dies entkräftet nicht „Nicht Ihre Schlüssel, nicht Ihre Münzen“, aber es erinnert uns daran, dass die Autonomie privater Schlüssel und die zugrunde liegenden Konsensrechte niemals dasselbe sind.
Das Gleiche gilt für Geldbörsen.
Das Wallet kann sicherstellen, dass der private Schlüssel und die Signaturrechte in den Händen des Benutzers liegen, Anomalien auf Kettenebene so schnell wie möglich identifizieren, den Transaktionsstatus genau anzeigen, RPC- und Knotenredundanz herstellen und das Endergebnis der Transaktion nach der Wiederherstellung des Netzwerks erneut bestätigen.
Das Wallet kann jedoch weder den Konsens für eine öffentliche Kette wiederherstellen, noch kann es garantieren, dass das zugrunde liegende Netzwerk niemals unterbrochen wird, noch kann es garantieren, dass sich die Regeln und der Status der Kette niemals auf Konsensebene ändern.
Daher muss ein ausgereiftes dezentrales System möglicherweise niemals „nichts kann geändert werden“ verfolgen; im Gegenteil, diese unvollkommenen Grenzen sollten so deutlich wie möglich gemacht werden: Wer kann den Konsens aufheben? Wie viel Gewicht wird benötigt? Unter welchen Umständen ist ein Notfalleingriff zulässig?
Aufgrund der echten Dezentralisierung ist es für das System unmöglich, niemals Unfälle zu erleiden. Der Schlüssel liegt darin, dass wir, selbst wenn es zu einem Unfall kommt, immer noch wissen können, wer nach welchen Regeln und mit welchem Maß an Konsens darüber entscheidet, wie dieses Konto als Nächstes erfasst werden soll.