Warum kann eine öffentliche Blockchain stoppen? Verstehen Sie den Konsens der Blockchain anhand der 25-stündigen Aussetzung von Cosmos

Dezentralisierung bedeutet nicht, dass das Netzwerk immer online ist; der Betrieb der Kette hängt davon ab, ob genügend Teilnehmer einen Konsens erreichen.

Verfasst von: imToken

Am Abend des 22. September tätigte ein Benutzer eine ATOM-Überweisung.

Eine Nacht später blieb die Transaktion im Status „Warten auf Bestätigung“.

Der private Schlüssel war nicht verloren, und die Brieftasche wies keine Anomalien bei der Signatur auf. Am nächsten Tag, bei einer erneuten Überprüfung, zeigten mehrere öffentliche RPCs, dass der Cosmos Hub bei der Blockhöhe 33.086.740 stehen geblieben war.

Es wurden keine neuen Blöcke erzeugt, und folglich gab es auch keinen Ort, an dem diese Transaktion verpackt werden konnte.

Erst etwa einen Tag später, als der Cosmos Hub wieder Blöcke erzeugte, wurde die zuvor im Wartestatus befindliche ATOM-Überweisung schließlich erfolgreich.

Für den normalen Benutzer könnte dies die direkteste Lektion zum Verständnis des Konsenses in der Blockchain sein.

Wir sagen oft: „Es gibt keine zentrale Institution, die eine öffentliche Blockchain abschalten kann“, aber die Realität ist offensichtlich viel komplexer. Eine ausreichend dezentralisierte Blockchain hat zwar normalerweise keinen „Ausschaltknopf“ im Serverraum, aber sie kann dennoch stoppen.

Die Aussetzung des Cosmos Hub hat genau diese Mechanismen, die normalerweise im Hintergrund verborgen sind, vollständig vor den Augen der normalen Benutzer offengelegt.

1. Warum hat Cosmos plötzlich „aufgehört, Blöcke zu erzeugen“?

Zunächst muss ein leicht verwirrendes Problem klargestellt werden: Der Cosmos Hub wurde nicht direkt angegriffen.

Das Ereignis begann bei Neutron.

Am 22. September wurde ein Governance-Vorschlag mit dem Titel „AIATO: AI Agent Takeover“ bei Neutron genehmigt. Der Angreifer nutzte eine Schwachstelle in den chain-level Governance-Rechten und verwendete die privilegierten Befehle, die vom wasmd-Framework nativ bereitgestellt werden, um die Vertragsverwalter von Anwendungen wie Astroport und Drop auf Adressen zu ändern, die vom Angreifer kontrolliert werden.

Dies ist nicht das, was wir normalerweise als „Codefehler“ oder „Protokollfehler“ verstehen.

Man kann es sich einfach so vorstellen, dass die Anwendung selbst ein „Schloss“ hat, aber die chain-level Governance von Neutron noch einen „Generalschlüssel“ in der Hand hält. Wenn der Angreifer die Governance-Ergebnisse kontrolliert, hat er auch diesen Schlüssel und kann die Verwalter neu bestimmen, Verträge migrieren und Vermögenswerte weiter transferieren.

Was den Cosmos Hub wirklich involvierte, war die anschließende Übertragung von Geldern zwischen den Ketten.

Eine Rückschau von Cosmos Labs zeigt, dass der Angreifer vor der Stilllegung von Neutron einen Teil der Vermögenswerte auf mehrere Netzwerke übertragen hatte, darunter etwa 1,7 Millionen ATOM, die in den Cosmos Hub transferiert wurden und begannen, über die Cross-Chain-Liquidität umgetauscht zu werden.

Das bedeutet, dass der Cosmos Hub selbst nicht direkt angegriffen wurde und die Gelder der normalen Hub-Benutzer aufgrund der Neutron-Schwachstelle nicht direkt gestohlen wurden.

Aber die erbeuteten ATOM waren bereits im Hub angekommen. Um zu verhindern, dass die verbleibenden ATOM weiterhin abfließen, begannen einige Validatoren des Cosmos Hub, den Betrieb ihrer Knoten einzustellen.

Um 19:18 Uhr (SGT) am 22. September hatten die gestoppten Validatoren bereits mehr als ein Drittel der gesamten Voting-Power vertreten, weshalb der Cosmos Hub keine neuen Blöcke mehr bilden konnte und schließlich bei 33.086.740 stehen blieb.

Dieser Schritt ist entscheidend.

Er bedeutet, dass es keinen „Pause“-Knopf gibt, den ein Unternehmen direkt drücken kann, um den Cosmos Hub anzuhalten, und dass es auch keine vorherige On-Chain-Governance-Abstimmung gab. Was das Netzwerk tatsächlich zum Stillstand brachte, war, dass genügend Validatoren nicht mehr am Konsens teilnahmen.

Aber noch bemerkenswerter ist der anschließende Wiederherstellungsprozess.

Etwa 4 Stunden nach der Stilllegung erhielten die Validatoren einen vollständigen Wiederherstellungsplan: Eine einmalige Statusänderung wurde auf der Höhe des Stillstands durchgeführt, um die verbleibenden ATOM von der Adresse des Angreifers auf eine Multi-Signatur-Adresse zu übertragen, die von den Community-Validatoren gemeinsam verwaltet wird.

Anschließend stellte Cosmos Labs einen Patch für Gaia v28.3.0 basierend auf dem bereits von den Validatoren erzielten Plan her, testete ihn und verteilte ihn an die Validatoren.

Diese Version von Gaia würde bei der angegebenen Wiederherstellungshöhe eine einmalige Statusänderung durchführen und 1.227.121 ATOM von der Adresse des Angreifers auf eine 4-of-6 Multi-Signatur-Adresse übertragen, die aus Nansen, Keplr, Enigma, Silknodes, Kiln und Polkachu besteht.

In den frühen Morgenstunden des 23. September hatten mehr als 67 % der gesamten Voting-Power die Installation von v28.3.0 bestätigt, weshalb der Cosmos Hub am selben Tag um 12:00 UTC koordiniert neu gestartet wurde. Etwa 6 Minuten später wurde diese einmalige Statusänderung bei der Blockhöhe 33.086.741 ausgeführt, und das Netzwerk begann wieder normal Blöcke zu erzeugen.

Letztendlich war der gesamte Prozess von der Stilllegung des Cosmos bis zur Wiederherstellung, dass die Validatoren zuerst das Netzwerk ohne Liveness verloren und dann mehr als zwei Drittel der Voting-Power eine neue Regel für die Statusänderung akzeptierten, die schließlich zur kanonischen Statusänderung nach der Wiederherstellung wurde.

An dieser Stelle stellt sich eine scheinbar einfache Frage: Wenn es sich um eine dezentrale öffentliche Blockchain handelt, warum kann dann mehr als ein Drittel der Validierungsrechte sie zum Stillstand bringen, während die Wiederherstellung des Netzwerks die Zustimmung und Ausführung derselben Software durch genügend Validatoren erfordert?

Die Antwort liegt tatsächlich im Wort „Konsens“.

2. Konsens bedeutet nicht „niemals zu stoppen“

Eine der am häufigsten missverstandenen Dinge in der Blockchain ist, dass „Dezentralisierung“ gleichbedeutend mit „niemals auszufallen“ ist.

Tatsächlich ist das eigentliche Problem, das der Konsensmechanismus löst, wie viele Knoten ohne einen zentralen Buchhalter über die Reihenfolge von Transaktionen und den Status des Hauptbuchs übereinstimmen können.

Allerdings unterscheiden sich die Methoden, mit denen verschiedene öffentliche Blockchains dies umsetzen, erheblich.

Bitcoin verwendet klassischerweise PoW, also Proof of Work – Miner konkurrieren mit Rechenleistung um die Blockerzeugung. Wenn im Netzwerk kurzfristig zwei legale Zweige auftreten, wählen die Knoten einen davon aus, um weiter zu bauen, basierend auf der kumulierten Arbeitslast.

Daher gibt es keinen klaren Moment, an dem „nach 67 % der Stimmen dieser Block für immer finalisiert ist“; es ist eher eine Art probabilistische Finalität. Je mehr nachfolgende Blöcke es gibt, desto höher sind die Kosten, um frühere Transaktionen neu zu organisieren.

Das ist auch der Grund, warum man in der Vergangenheit oft gesagt hat, dass eine Bitcoin-Transaktion am besten auf 6 Bestätigungen wartet, denn selbst wenn die Rechenleistung hoch ist, kann man die Konsensregeln, die die Knoten ausführen, nicht einfach umgehen.

Das bedeutet jedoch nicht, dass der Status von Bitcoin unter keinen Umständen „absolut unveränderlich“ ist. Theoretisch könnte eine neue Client- und Konsensregelung, die von der gesamten Ökologie akzeptiert wird, durch einen Hard Fork auch frühere ungültige Statusänderungen gültig machen.

Aber das Problem liegt hier: Wer hat die Fähigkeit, genügend Miner, Full Nodes, Handelsplattformen, Wallets und Benutzer dazu zu bringen, eine solche neue Regel zu akzeptieren?

Fast niemand.

Das Entwicklungsteam kann nicht die Konsensregeln für das gesamte Bitcoin-Netzwerk festlegen, und Miner und Handelsplattformen können dies ebenfalls nur schwer tun, da die Konsensschwelle, die überschritten werden muss, sehr hoch ist. Als Binance 7000 BTC gestohlen wurden, gab es Vorschläge, dass CZ große Miner kontaktieren sollte, aber letztendlich kam nichts dabei heraus.

Ethereum bietet ein weiteres klassisches Beispiel.

Nach dem Übergang zu PoS verwendet das heutige Ethereum den Gasper-Konsens, der aus Casper FFG und LMD-GHOST besteht. Einfach gesagt, ein Teil des Mechanismus entscheidet, „welcher Kette wir derzeit folgen sollten“, während ein anderer Teil dafür sorgt, dass Blöcke tatsächlich Finalität erlangen.

Wenn Validatoren, die mindestens zwei Drittel der gestakten ETH repräsentieren, sich auf den entsprechenden Checkpoint einigen, kann der Block weiter zur endgültigen Bestätigung gelangen; umgekehrt, wenn mehr als ein Drittel der Stake über längere Zeit nicht an der richtigen Abstimmung teilnehmen, kann das Netzwerk vorübergehend keine Finalität erreichen. Ethereum hat jedoch auch einen Inaktivitätsverlust entworfen, der bei längerer Unfähigkeit zur Finalisierung das Gewicht der inaktiven Validatoren schrittweise verringert, sodass das Netzwerk schließlich die Möglichkeit hat, die Finalität wiederherzustellen.

Um dieses Ergebnis wirklich zu ändern, müssen ebenfalls die Protokollregeln und Clients geändert werden.

Wie im Jahr 2016 beim DAO-Ereignis, als die Ethereum-Community schließlich durch einen Hard Fork eine spezielle Statusänderung, die damals von der Ethereum Foundation als unregelmäßige Statusänderung bezeichnet wurde, bei Block 1.920.000 durchführte, um die entsprechenden ETH in einen Wiederherstellungsvertrag zu übertragen.

Allerdings bildeten einige Miner und Community-Mitglieder, die sich weigerten, das Upgrade durchzuführen und den ursprünglichen Status aufrechtzuerhalten, schließlich Ethereum Classic (ETC), was zur bekannten Gabelung von ETH und ETC führte und zeigte, dass nicht jeder diese Regeln akzeptiert.

Der Cosmos Hub unterscheidet sich jedoch, da er CometBFT verwendet, das näher an einem typischen BFT-Konsens liegt.

Man kann es als einen typischen BFT-Konsens verstehen, bei dem ein Block tatsächlich eingereicht werden muss, um mehr als zwei Drittel der Voting-Power zu erhalten.

Der Vorteil ist, dass die Finalität sehr klar ist; sobald ein Block durch genügend Abstimmungsrechte eingereicht wird, muss man nicht wie bei PoW weiterhin auf immer mehr Blöcke warten, um Sicherheit zu gewinnen.

Aber die andere Seite ist auch sehr direkt: Wenn ein Drittel oder mehr der Voting-Power nicht mehr die für die Commit-Bildung erforderlichen Stimmen abgibt, können die verbleibenden Validatoren, egal wie sehr sie sich anstrengen, nicht mehr als zwei Drittel erreichen.

In diesem Fall ist die sicherste Wahl für das Netzwerk, wie in diesem Fall die „Pause der Blockerzeugung“. Daher ist die kurzfristige Aussetzung des Cosmos Hub aus der Perspektive eines verteilten Systems nicht mysteriös.

Zusammengefasst: Wenn eine Gruppe von Validatoren mit ausreichender Voting-Power die Teilnahme einstellt, entscheidet das Konsensprotokoll, dass es lieber die Verfügbarkeit opfert, als neue Blöcke unter Bedingungen ohne ausreichenden Konsens zu bestätigen.

Dies entspricht tatsächlich zwei Konzepten in verteilten Systemen, die von normalen Benutzern oft verwechselt werden:

• Sicherheit: Es darf nicht zulässig sein, dass verschiedene Knoten gleichzeitig zwei widersprüchliche endgültige Zustände bestätigen;
• Liveness: Kann das Netzwerk weiterhin neue Transaktionen verarbeiten und vorankommen;

Für BFT-Systeme ist es manchmal der Preis, den man für die Aufrechterhaltung der Sicherheit zahlt, wenn nicht genügend Knoten am Konsens teilnehmen. Um es klar zu sagen, dieses dezentrale Hauptbuch bleibt lieber stehen, als dass die verbleibenden Teilnehmer unterschiedliche Aufzeichnungen führen.

Wenn man aus dieser Perspektive zurückblickt, wird man feststellen, dass viele scheinbar völlig unterschiedliche Vorfälle in der Geschichte der öffentlichen Blockchains tatsächlich um dasselbe Thema kreisen:

Was sollte das Netzwerk tun, wenn verteilte Knoten keine Einigkeit über den "richtigen Zustand" erzielen können?

III. Wo liegen die echten Risikogrenzen öffentlicher Blockchains von Bitcoin bis Solana?

Dies ist nicht das erste Mal, dass Cosmos dieses Problem aufwirft.

Bereits 2013 gab es einen sehr klassischen Fork-Vorfall bei Bitcoin.

Damals wechselte Bitcoin 0.8 die zugrunde liegende Datenbank von Berkeley DB zu LevelDB. Daraufhin erschien ein Block mit einer Vielzahl von Transaktionsinputs, den die neuen Knoten normal verarbeiten konnten, während einige alte Knoten aufgrund der Begrenzung der Anzahl der Berkeley DB-Sperren diesen Block als ungültig einstuften.

So kam es zu einer sehr peinlichen Situation: Alle betrieben Bitcoin, aber die neuen und alten Clients begannen, unterschiedliche Antworten auf die Frage zu geben, ob "dieser Block gültig ist oder nicht".

Das Netzwerk spaltete sich daher in zwei Ketten, und die neue Version 0.8 hatte zeitweise etwa 60 % der Rechenleistung, konnte sich jedoch nicht auf die normale Rechenleistung verlassen, um schnell zu einer Einigung zu gelangen.

Schließlich koordinierte ein großes Mining-Pool die Rückkehr zur alten Version, um auf der Seite der alten Regeln mehr Rechenleistung zu gewinnen, und das Netzwerk konnte sich wieder konsolidieren. Bitcoin hat später diesen Vorfall speziell mit BIP 50 analysiert.

Im Jahr 2016 brachte der DAO-Vorfall von Ethereum das Problem einen Schritt weiter.

Wie bereits erwähnt, führte die Ethereum-Community schließlich einen Hard Fork durch, um bei Block 1.920.000 eine spezielle Statusänderung durchzuführen, die von der Ethereum Foundation als unregelmäßige Statusänderung bezeichnet wurde, um die entsprechenden ETH in einen Wiederherstellungsvertrag zu übertragen.

Aber nicht alle waren mit dieser Vorgehensweise einverstanden. Ein Teil der Miner und der Community, die sich weigerten, die Statusänderung zu akzeptieren, hielten an den ursprünglichen Regeln fest, was zur langfristigen Existenz von Ethereum Classic (ETC) führte.

Dieser DAO-Fork ist ebenfalls ein klassisches Ereignis, das allen zeigt, dass es, wenn extreme Ereignisse eintreten, neben dem Konsens des Codes auch einen sozialen Konsens gibt. Wenn keine ausreichende Einigkeit erzielt werden kann, kann eine Kette tatsächlich in zwei Ketten aufgeteilt werden.

Solana im Jahr 2021 zeigte einen völlig anderen Fehlerpfad.

Im September des Jahres strömten zahlreiche Bot-Transaktionen ins Netzwerk, was zu einem Speicherausfall der Validierungsknoten führte. Viele Knoten stürzten ab, und schließlich konnte das gesamte Netzwerk keine Einigkeit über den aktuellen Zustand erzielen und hörte etwa 17 Stunden lang auf, neue Blöcke zu bestätigen. Danach koordinierten die Validatoren gemeinsam die Wiederherstellung des Netzwerks.

Wenn man diese Vorfälle zusammen betrachtet, wird deutlich, dass sie nicht dasselbe sind:

• Das Problem von Bitcoin im Jahr 2013 war, dass verschiedene Clients begannen, unterschiedliche Gültigkeitsregeln auszuführen;
• Das Problem von Solana im Jahr 2021 war, dass viele Validierungsknoten nicht mehr normal am Konsens teilnehmen konnten, wodurch das Netzwerk seine Liveness verlor;
• Ethereum DAO stand vor der Frage, ob die Community aktiv den Status durch neue Protokollregeln ändern sollte;
• Und diesmal hat Cosmos Hub eine weitere Besonderheit, da das Netzwerk zunächst durch die Koordination der Validatoren aktiv seine Liveness verlor, um zu verhindern, dass Angriffsvermögen weiterhin bewegt wird; danach akzeptierte ein ausreichend hoher Anteil der Validierungsrechte gemeinsam neue Software und stellte den Status wieder her, sodass das Netzwerk erneut eine Einigkeit bildete;

Daher ist es besser, diese Ereignisse nicht einfach als "Blockchain kann auch abgeschaltet werden" oder "Dezentralisierung ist alles falsch" zu betrachten, sondern eine realistischere Tatsache anzuerkennen:

Das Konsensmechanismus ist niemals eine Maschine, die nicht kaputt gehen kann. Was er tatsächlich bietet, ist ein Set von dezentralen Regeln, wie zum Beispiel, wer entscheidet, welche Kette korrekt ist, wie viele Teilnehmer erforderlich sind, damit ein Zustand endgültig wird, ob das Netzwerk im Falle eines Fehlers weiter betrieben oder gestoppt wird und welche kollektiven Maßnahmen unter extremen Umständen die zukünftigen Betriebsregeln ändern können.

Dies lässt uns bei diesem Cosmos-Ereignis eine Frage hinterlassen, die für normale Benutzer nachdenklicher ist als "Sollte die Kette gestoppt werden?"

Schlusswort

Wir sagen oft: not your keys, not your coins.

Dieser Satz bleibt natürlich gültig, da er das Kontrollrecht über Vermögenswerte betont - solange der private Schlüssel in den eigenen Händen liegt, können Wallets, Handelsplattformen oder andere Dritte keine Transaktion normal für dich unterzeichnen.

Die Voraussetzung ist, dass die Blockchain, auf der du dich befindest, jederzeit in der Lage sein muss, diese Signatur zu verarbeiten.

Am Tag, an dem Cosmos Hub das Blocken einstellte, besitzen die Benutzer weiterhin ihre privaten Schlüssel, und die Vermögenswerte verschwinden nicht einfach, nur dass selbst wenn du eine Transaktion korrekt signierst, es keinen neuen Block gibt, der sie akzeptieren kann.

Der Wiederherstellungsprozess zeigt weiter, dass, wenn genügend Konsens-Teilnehmer eine neue Statusregel akzeptieren, der On-Chain-Status bestimmter Konten auch ohne die Signatur des ursprünglichen Adressenschlüssels geändert werden kann.

Das wird "Not your keys, not your coins" nicht ungültig machen, sondern erinnert uns daran, dass die Selbstbestimmung des privaten Schlüssels und das Recht auf den zugrunde liegenden Konsens niemals dasselbe sind.

Und das gilt auch für Wallets.

Wallets können sicherstellen, dass private Schlüssel und Signaturrechte in den Händen der Benutzer bleiben, können Kettenanomalien schnell erkennen, den Transaktionsstatus genau anzeigen, RPC und Knotenredundanz aufbauen und nach der Wiederherstellung des Netzwerks die endgültigen Ergebnisse der Transaktionen erneut bestätigen.

Aber Wallets können nicht das Konsens einer öffentlichen Blockchain wiederherstellen und können nicht garantieren, dass das zugrunde liegende Netzwerk niemals unterbrochen wird, noch können sie garantieren, dass die Regeln und der Status auf der Kette niemals Änderungen auf der Konsensebene erfahren.

Daher sollte das, was ein reifes dezentrales System wirklich anstreben sollte, vielleicht niemals sein, dass "nichts absolut geändert werden kann"; im Gegenteil, es sollte so klar wie möglich gemacht werden, welche nicht perfekten Grenzen bestehen: Wer kann den Konsens pausieren? Wie viel Gewicht ist erforderlich? Unter welchen Umständen sind Notfallinterventionen erlaubt?

Denn echte Dezentralisierung kann nicht verhindern, dass das System jemals auf Vorfälle stößt. Der Schlüssel ist, dass wir, selbst wenn ein Vorfall tatsächlich eintritt, immer noch wissen, wer, auf welcher Grundlage und mit welchem Konsens entschieden hat, wie dieses Buch in Zukunft geführt werden soll.