Eine vollständige Chronik der Solana-Ausfälle: Ursachen, Lösungen und Erkenntnisse

Einführung

Wie alle verteilten Systeme muss Solana damit umgehen, dass ein einzelner Implementierungsfehler oder undurchsichtiger Grenzfall das gesamte Netzwerk lahmlegen kann. Ausfälle stören den Betrieb, sind aber unvermeidlich, wenn komplexe verteilte Infrastruktur betrieben wird – ob bei dezentralen Blockchains, zentralisierten Börsen oder selbst großen Cloud-Anbietern wie Amazon oder Microsoft.

Die Frage ist nicht, ob Fehler auftreten, sondern wann – und wie sich das Netzwerk weiterentwickelt, um sich anzupassen und gegen künftige Vorfälle zu wappnen. Trotz strenger Simulationstests, eines Testnets mit Anreizen und eines aktiven Bug-Bounty-Programms kann kein System – ganz gleich, wie gut es entwickelt wurde – jeden möglichen Fehlermodus vorhersehen. Die wertvollsten Erkenntnisse liefert der reale Betrieb.

In den vergangenen fünf Jahren kam es bei Solana zu sieben separaten Ausfällen. Fünf davon wurden durch Client-Fehler und zwei durch die Unfähigkeit des Netzwerks verursacht, eine Flut von Spam-Transaktionen zu bewältigen. Frühen Solana-Versionen fehlten wichtige Mechanismen zur Überlastungssteuerung wie Priority Fees und lokale Gebührenmärkte. Später erwiesen sich diese als entscheidend, um die Belastung des Netzwerks zu begrenzen. Da solche Mechanismen fehlten, kam es 2022 über längere Zeiträume zu Leistungseinbußen und Überlastungen, weil das Netzwerk Spam im Grunde belohnte.

Dieser Artikel analysiert jeden Solana-Ausfall im Detail und untersucht die Ursachen, Auslöser und ergriffenen Maßnahmen. Außerdem behandeln wir die wichtigsten Aspekte von Netzwerkneustarts und Fehlerberichten sowie die grundlegenden Konzepte von Liveness- und Safety-Fehlern. Die Abschnitte bauen zwar aufeinander auf, funktionieren aber auch eigenständig. So kannst du direkt zu den Themen oder Ausfällen springen, die dich am meisten interessieren.

Liveness und Safety

Nach dem CAP-Theorem, auch als Brewers Theorem bekannt, kann ein verteiltes System nur zwei von drei Eigenschaften erfüllen:

• Konsistenz - Jeder Lesevorgang berücksichtigt alle vorherigen Schreibvorgänge.
• Verfügbarkeit - Jede Anfrage erhält eine Antwort.
• Partitionstoleranz - Das System läuft trotz Netzwerkpartitionen weiter.

Für Blockchains ist Partitionstoleranz unverzichtbar – Netzwerkstörungen sind unvermeidlich. Deshalb muss zwischen AP (Verfügbarkeit + Partitionstoleranz) und CP (Konsistenz + Partitionstoleranz) gewählt werden. Wie die meisten PoS-Chains mit schneller Finalität priorisiert Solana Konsistenz vor Verfügbarkeit und ist damit ein CP-System. Bei kritischen Fehlern hält es an, statt veraltete Daten bereitzustellen oder unsichere Schreibvorgänge zuzulassen. Die Node-Software kann dadurch zwar in einen nicht wiederherstellbaren Zustand geraten, der manuelles Eingreifen erfordert. Dafür bleiben die Gelder der Nutzer geschützt.

Liveness-Fehler: Tritt auf, wenn die Blockchain keine Fortschritte mehr macht und deshalb keine Transaktionen bestätigt oder Blöcke produziert werden. Ursachen können ausgefallene Validatoren, Netzwerkpartitionen oder ein stillstehender Konsens sein. Im CAP-Theorem entspricht dies dem Verlust der Verfügbarkeit.

Safety-Fehler: Tritt auf, wenn der finalisierte Zustand der Blockchain unzulässig verändert oder geforkt wird. Das kann zu widersprüchlichen Historien oder Double Spending führen und wird häufig durch Konsensfehler oder böswillige Angriffe verursacht. Im CAP-Theorem entspricht dies dem Verlust der Konsistenz. 

Solana priorisiert Safety vor Liveness. Bei extremer Netzwerkbelastung oder einem Konsensfehler hält das Netzwerk daher an, statt eine Beschädigung des Zustands zu riskieren. Ausfälle stören den Betrieb und können Anwendungen, Nutzer und Validatoren beeinträchtigen. Sie sind jedoch den katastrophalen Folgen eines inkonsistenten oder beschädigten Ledgers vorzuziehen.

Netzwerkneustarts

Für einen Neustart des Solana-Netzwerks wird der letzte optimistisch bestätigte Block-Slot ermittelt. Anschließend werden die Nodes von einem vertrauenswürdigen lokalen Zustands-Snapshot dieses Slots neu gestartet. Da der Neustart-Slot nicht on-chain bestimmt wird, müssen sich die Validator-Betreiber off-chain auf einen sicheren Rollback-Punkt einigen. Diese Abstimmung findet öffentlich im Kanal #mb-validators auf dem Solana Tech Discord statt, wo professionelle Validator-Betreiber in Echtzeit kommunizieren. Die meisten Betreiber nutzen automatisierte Warnsysteme, die sie sofort benachrichtigen, wenn die Blockproduktion stoppt. Das ermöglicht eine schnelle Reaktion.

Sobald Konsens über den richtigen Neustart-Slot besteht, erzeugen die Betreiber mit dem Ledger-Tool einen neuen lokalen Snapshot, starten ihre Validatoren neu und warten, bis mindestens 80 % des gesamten Stakes wieder online sind. Erst dann nimmt das Netzwerk die Blockproduktion und Validierung wieder auf. Beim Neustart des Clusters darf höchstens 20 % des Stakes offline sein. So bleibt genügend Sicherheitspuffer, falls Nodes forken oder direkt nach dem Neustart erneut offline gehen.

Fehler melden

Bug-Bounty-Programme belohnen Sicherheitsforscher dafür, Software-Schwachstellen zu identifizieren und zu melden. Sie bilden eine wichtige Verteidigungslinie, weil sie proaktiv Anreize schaffen, Fehler zu finden, bevor sie ausgenutzt werden können. Sicherheitsforscher und Entwickler, die mögliche Schwachstellen im Agave-Client entdecken, sollten sie über die vorgesehenen Sicherheitskanäle melden. Ausführliche Richtlinien zur Offenlegung findest du im Agave-Repository auf GitHub. 

Für gültige Meldungen kritischer Schwachstellen werden je nach Schweregrad folgende Prämien angeboten:

• Verlust von Geldern: Bis zu 25.000 SOL
• Konsens- oder Safety-Verstöße: Bis zu 12.500 SOL
• Liveness oder Verlust der Verfügbarkeit: Bis zu 5.000 SOL

Außerdem gibt es für den Firedancer-Client ein separates Bug-Bounty-Programm, das über Immunefi läuft und für kritische Funde eine maximale Prämie von 500.000 USDC bietet.

Die Ausfälle

Die folgenden Abschnitte analysieren die Ausfälle und Zeiträume mit Leistungseinbußen bei Solana detailliert und chronologisch, beginnend mit dem Start von Mainnet Beta am 16. März 2020. Die Analyse beleuchtet wichtige Vorfälle, ihre Ursachen und die anschließenden Verbesserungen am Netzwerk. Sie zeigt, wie Solana im Laufe der Zeit stabiler und widerstandsfähiger wurde.

Turbine-Fehler: Dezember 2020

Ausfallzeit: Etwa sechs Stunden

Ursache: Fehler bei der Blockweitergabe

Lösungen: 

• Blöcke anhand ihres Hashes statt ihrer Slot-Nummer verfolgen
• Stellen in Turbine korrigieren, an denen Fehler früher erkannt werden können
• Den zuerst erkannten Fehler über Gossip an alle Validatoren weitergeben

Dieser Ausfall wurde durch ein bereits bekanntes Problem bei Blockreparatur und Codeverarbeitung verursacht, das ein unbekannter Fehler in Turbine, Solanas Mechanismus zur Blockweitergabe, ausgelöst hatte. Der Fehler trat auf, als ein Validator für denselben Slot zwei unterschiedliche Blöcke übermittelte und sie an zwei separate Partitionen (A und B) weitergab, während eine dritte Partition die Inkonsistenz unabhängig erkannte.

Da jede Partition nur einen Minderheits-Stake hielt, konnte keine den für die Fortsetzung der Chain nötigen Supermajority-Konsens erreichen. Das zugrunde liegende Problem lag darin, wie Solanas interne Datenstrukturen Blöcke und ihren berechneten Zustand verfolgen. Das System verwendete die Slot-Nummer des Proof of History (PoH), eine u64-Kennung, um auf den Zustand und den Block dieses Slots zu verweisen. Nachdem sich das Netzwerk in Partitionen aufgeteilt hatte, interpretierten Nodes die Blöcke A und B fälschlich als identisch. Das verhinderte eine ordnungsgemäße Reparatur und Blocksynchronisierung.

Jede Partition nahm an, die andere besitze denselben Block. Dadurch entstand ein grundlegender Konflikt:

• Nodes mit Block A lehnten Forks ab, die von Block B abgeleitet waren
• Nodes mit Block B lehnten Forks ab, die von Block A abgeleitet waren

Da sich die Zustandsübergänge zwischen den Partitionen unterschieden, konnten die Validatoren die Forks weder reparieren noch zusammenführen. Finalität war damit unmöglich.

Zur Behebung des Problems wurde Diensten ermöglicht, Blöcke anhand ihres Hashes statt ihrer Slot-Nummer zu verfolgen. Wenn mehrere Blöcke desselben Slots Partitionen erzeugen, werden diese nicht anders behandelt als Partitionen mit Blöcken in unterschiedlichen Slots. Nodes können alle möglichen Forks reparieren und der Konsens kann die Partitionen auflösen.

Der Fehler löste den Ausfall zwar aus, doch der größte Teil der Ausfallzeit entstand beim Warten darauf, dass genügend Stake wieder online kam. Solana benötigt mindestens 80 % Stake-Beteiligung, um die Blockproduktion fortzusetzen.

Die Grape Protocol IDO: September 2021

Ausfallzeit: 17 Stunden 

Ursache: Speicherüberlauf durch Bot-Transaktionen

Lösungen: 

• Schreibsperren für Programme ignorieren
• Ratenbegrenzung für die Weiterleitung von Transaktionen
• Konfigurierbares RPC-Wiederholungsverhalten
• Priorisierung von TPU-Abstimmungstransaktionen

Am 14. September 2021 kam es bei Solana nach dem Start des on-chain Initial DEX Offering (IDO) von Grape Protocol auf der Crowdfunding-Plattform Raydium AcceleRaytor zu einem massiven Netzwerkausfall. Innerhalb von zwölf Minuten nach Beginn der IDO wurde das Netzwerk von einer beispiellosen Flut Bot-gesteuerter Transaktionen überlastet und produzierte keine verwurzelten Slots mehr. Die Bots führten faktisch einen verteilten Denial-of-Service-Angriff (DDoS) aus und trieben die Transaktionslast über die Kapazität des Netzwerks hinaus.

Auf dem Höhepunkt der Überlastung:

• Einige Validatoren empfingen mehr als 300.000 Transaktionen pro Sekunde.
• Die Rohdaten der Transaktionen überschritten 1 Gbit/s bei 120.000 Paketen pro Sekunde.
• Der Datenverkehr überschritt teilweise die physischen Grenzen der Netzwerkschnittstellen. Dadurch gingen Pakete bereits am Switch-Port verloren, bevor sie die Validatoren erreichten.

Einer der Bots strukturierte seine Transaktionen so, dass sie Schreibsperren auf 18 wichtigen Accounts setzten, darunter das globale SPL-Token-Programm und das inzwischen eingestellte Serum-DEX-Programm. Dadurch wurden alle Transaktionen blockiert, die mit diesen Accounts interagierten. Solanas Fähigkeit zur parallelen Verarbeitung sank drastisch. Statt Transaktionen unabhängig voneinander auszuführen, verarbeitete das Netzwerk sie nacheinander. Dieser Engpass verschärfte die Überlastung.

Eine Lösung, die Schreibsperren für Programme ignoriert, war bereits entwickelt und zur Veröffentlichung vorgesehen. Der spätere Netzwerkneustart aktivierte dieses Upgrade und beseitigte den Angriffsvektor dauerhaft.

Während der IDO erhielten die Validatoren eine Flut Bot-gesteuerter Transaktionen und leiteten überschüssige Transaktionen wiederum an den nächsten Leader weiter. Das verstärkte die Überlastung. Mit dem Netzwerkneustart wurden Ratenbegrenzungen für die Transaktionsweiterleitung eingeführt, damit künftige Transaktionsstürme die Leader nicht überfordern.

Solanas RPC-Nodes wiederholen fehlgeschlagene Transaktionen automatisch, um die Zuverlässigkeit zu erhöhen. Bei extremer Überlastung verschärfte dieser Mechanismus jedoch die Transaktionsflut. Alte Transaktionen blieben im Umlauf, statt dem Netzwerk die Erholung zu ermöglichen. Solana 1.8 führte ein konfigurierbares RPC-Wiederholungsverhalten ein. Anwendungen konnten Wiederholungen dadurch mit kürzeren Ablaufzeiten und exponentiellen Backoff-Strategien optimieren.

Bei hoher Überlastung nahmen Solana-Leader keine Abstimmungstransaktionen auf, obwohl diese für den Konsens entscheidend sind. Ohne bestätigte Stimmen kam der Konsens zum Stillstand und es wurden keine neuen Root-Blöcke mehr produziert. Spätere Versionen des Solana-Clients führten einen Mechanismus zur Priorisierung von Abstimmungstransaktionen ein, damit reguläre Transaktionen sie bei künftigen Vorfällen nicht verdrängen.

Ein zweiter Fehler: Ganzzahlüberlauf

Während des Netzwerkneustarts trat ein zweites Problem auf. Validatoren meldeten stark schwankende Mengen aktiven Stakes. Ursache war ein Fehler, durch den der Stake-Prozentsatz fälschlich mit 100 multipliziert wurde und den maximal möglichen Wert überschritt. Der Inflationsmechanismus hatte so viele neue SOL-Token erzeugt, dass eine vorzeichenlose 64-Bit-Ganzzahl überlief. Der Fehler wurde schnell erkannt und vor einem zweiten Neustart behoben.

Starke Überlastung: Januar 2022

Ausfallzeit: Keine

Ursache: Übermäßig viele doppelte Transaktionen Teillösung:

• Veröffentlichungen von Solana 1.8.12 und 1.8.14
• Optimierung der SigVerify-Deduplizierung
• Verbesserte Leistung des Executor-Caches

Vom 6. bis 12. Januar 2022 war das Solana-Mainnet stark überlastet. Das führte zu Leistungseinbußen und Teilausfällen. Bots versendeten übermäßig viele doppelte Transaktionen und verringerten die Netzwerkkapazität erheblich. Die Verarbeitung der Blöcke dauerte länger als erwartet, sodass der nächste Leader einen Fork erstellte und der Durchsatz weiter sank. Auf dem Höhepunkt fiel die Erfolgsquote von Transaktionen um bis zu 70 %. Der Client hatte Schwierigkeiten, die zunehmend komplexen und rechenintensiven Transaktionen des Netzwerks zu bewältigen. Das machte seine begrenzte Fähigkeit sichtbar, die Nachfrage zu bedienen.

Vom 21. bis 23. Januar kam es erneut zu Instabilität und anhaltender Überlastung. Am 22. Januar ging der öffentliche RPC-Endpunkt (https://api.mainnet-beta.solana.com) aufgrund von Missbrauch offline, weil gebündelte Spam-RPC-Aufrufe das System überforderten.

Zur Behebung dieser Probleme zielte Solana 1.8.12 gezielt auf die Erschöpfung des Programm-Caches, während Version 1.8.14 den Sysvar-Cache, das Verwerfen durch SigVerify und die SigVerify-Deduplizierung verbesserte.

Candy-Machine-Spam: April/Mai 2022 

Ausfallzeit: Acht Stunden

Ursache: Transaktions-Spam von Bot-Accounts

Lösungen:

• Bot-Steuer im Candy-Machine-Programm
• Speicherverbesserungen in Solana v1.10

Am 30. April 2022 erlebte Solana einen beispiellosen Anstieg der Transaktionsanfragen. Einige Nodes meldeten sechs Millionen Anfragen pro Sekunde, die pro Node mehr als 100 Gbit/s Datenverkehr erzeugten. Bots versuchten, über das Metaplex-Candy-Machine-Programm neu erzeugte NFTs zu erhalten. Dieser Minting-Mechanismus funktionierte nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“. Dadurch entstand ein starker wirtschaftlicher Anreiz, das Netzwerk mit Transaktionen zu fluten und den Mint zu gewinnen.

Als das Transaktionsvolumen sprunghaft anstieg, ging den Validatoren der Speicher aus und sie stürzten ab. Schließlich kam der Konsens zum Stillstand. Der unzureichende Abstimmungsdurchsatz verhinderte die Finalisierung früherer Blöcke. Deshalb konnten aufgegebene Forks nicht bereinigt werden. Die enorme Zahl auszuwertender Forks überforderte die Validatoren selbst nach Neustarts. Um das Netzwerk wiederherzustellen, war manuelles Eingreifen erforderlich.

Dieser Ausfall ähnelte zwar dem Vorfall vom September 2021, doch Solana zeigte eine höhere Widerstandsfähigkeit. Obwohl das Netzwerk 10.000 % mehr Transaktionsanfragen als beim vorherigen Ausfall verarbeiten musste, blieb es deutlich länger betriebsfähig. Darin spiegelten sich die Verbesserungen wider, die die Validator-Community als Reaktion auf frühere Skalierungsprobleme umgesetzt hatte.

Nachdem man sich auf den kanonischen Snapshot geeinigt hatte, dauerte der Netzwerkneustart weniger als 1,5 Stunden. Solana v1.10 verbesserte die Speichernutzung, damit Nodes langsamen oder stillstehenden Konsens länger überstehen können. 

Grundlegende Probleme blieben jedoch ungelöst. Der Leader verarbeitete Transaktionen, die um dieselben Account-Daten konkurrierten, weiterhin nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ und ohne wirksamen Spam-Schutz. Nutzer konnten die Dringlichkeit ihrer Transaktionen nicht priorisieren. Als praktische langfristige Lösungen wurden drei Mechanismen vorgeschlagen.

Einführung von QUIC: Zuvor nutzte Solana das Netzwerkprotokoll UDP (User Datagram Protocol), um Transaktionen über Gulf Stream von RPC-Nodes an den aktuellen Leader zu senden. UDP ist schnell und effizient, aber verbindungslos und bietet weder Flusskontrolle noch Empfangsbestätigungen. Missbräuchliches Verhalten lässt sich daher nicht sinnvoll verhindern oder eindämmen. Um den Netzwerkverkehr kontrollieren zu können, wurde das Protokoll des Validators zur Transaktionsaufnahme, also die Fetch Stage der TPU, mit QUIC neu implementiert.

QUIC versucht, die Vorteile von TCP und UDP zu vereinen. Es ermöglicht ähnlich wie UDP eine schnelle, asynchrone Kommunikation, bietet aber zugleich sichere Sitzungen und fortschrittliche Flusskontrolle wie TCP. Damit lassen sich einzelne Datenverkehrsquellen begrenzen, sodass sich das Netzwerk auf die Verarbeitung legitimer Transaktionen konzentrieren kann. QUIC unterstützt außerdem separate Streams. Wird eine Transaktion verworfen, blockiert sie daher nicht die übrigen. QUIC wurde schließlich mit Version 1.13.4 in den Solana-Labs-Client integriert.

Stake-Weighted Quality of Service (SWQoS): Ein neues System priorisiert Netzwerkverkehr anhand des Stakes der Validatoren. Validatoren mit mehr Stake können dadurch Transaktionen effizienter senden. Ein Validator mit 3 % des gesamten Stakes darf über diesen Mechanismus bis zu 3 % aller Pakete an den Leader senden. SWQoS dient als Sybil-Resistenz und erschwert es böswilligen Akteuren, das Netzwerk mit minderwertigen Transaktionen zu fluten. Dieser Ansatz ersetzt das bisherige Prinzip „Wer zuerst kommt, mahlt zuerst“, bei dem Transaktionen unabhängig von ihrer Quelle angenommen wurden.

Einführung von Priority Fees: Nach der Aufnahme konkurrieren Transaktionen weiterhin um den Zugriff auf gemeinsame Account-Daten. Zuvor wurde dieser Konflikt nach dem einfachen Prinzip „Wer zuerst kommt, mahlt zuerst“ gelöst. Nutzer konnten die Dringlichkeit ihrer Transaktionen nicht signalisieren. Da jeder Transaktionen einreichen kann, eignet sich eine Stake-Gewichtung in dieser Phase nicht zur Priorisierung. Deshalb erhielt das Compute-Budget-Programm eine neue Anweisung. Nutzer können damit eine zusätzliche Gebühr festlegen, die bei Ausführung und Aufnahme in einen Block erhoben wird. Das Verhältnis von Gebühr zu Recheneinheit bestimmt die Ausführungspriorität einer Transaktion und ermöglicht eine dynamischere, marktgesteuerte Reihenfolge.

Bot-Steuer für Candy Machine

Metaplex führte schnell eine fest codierte Bot-Steuer von 0,01 SOL für Mint-Transaktionen ein, die mit dem Candy-Machine-Programm interagierten, um Bot-gesteuerten Spam zu bekämpfen. Dieser Anti-Spam-Mechanismus erhob eine geringe Gebühr, um böswillige Aktivitäten abzuschrecken, ohne legitime Nutzer für versehentliche Fehler zu bestrafen. Die Steuer fiel in bestimmten Fällen an, darunter:

• Minting-Versuch, obwohl die Candy Machine nicht aktiv war
• Minting-Versuch, obwohl keine Elemente mehr verfügbar waren
• Transaktionen, bei denen Mint oder Set Collection nicht die letzte Anweisung war
• Verwendung einer falschen Collection-ID
• Nicht übereinstimmende Set-Collection-Anweisungen
• Abweichung zwischen Signierer und Zahler in den Anweisungen für Collection Set und Mint
• Verdächtige Transaktionen mit unzulässigen Programmen
• Minting-Versuch über eine durch AllowList geschützte Candy Machine ohne das erforderliche Allowlist-Token

Diese wirtschaftliche Abschreckung erwies sich als äußerst wirksam. Das Guthaben der Mint-Sniper war schnell aufgebraucht und die Spam-Aktivitäten endeten. In den ersten Tagen verloren die Bot-Betreiber zusammen mehr als 426 SOL.

Durable-Nonce-Fehler: Juni 2022 

Ausfallzeit: Viereinhalb Stunden

Ursache: Durable-Nonce-Fehler führte zum Konsensausfall 

Lösungen: 

• Durable-Nonce-Transaktionen vorübergehend deaktiviert
• Update auf Solana 1.10.23

Ein Laufzeitfehler ermöglichte es, bestimmte Durable-Nonce-Transaktionen zweimal zu verarbeiten: einmal als reguläre Transaktion und erneut als Nonce-Transaktion. Voraussetzung war, dass sie im Feld recent_blockhash einen aktuellen Blockhash statt einer Durable Nonce verwendeten. Das führte zu nicht deterministischem Verhalten bei Validatoren, da einige Nodes die zweite Ausführung ablehnten und andere sie akzeptierten. Da mehr als ein Drittel der Validatoren den Block akzeptierte, konnte die erforderliche Zweidrittelmehrheit keinen Konsens erreichen.

Anders als Standardtransaktionen laufen Durable-Nonce-Transaktionen nicht ab und benötigen einen speziellen Mechanismus, der eine doppelte Ausführung verhindert. Sie werden sequenziell anhand eines on-chain Nonce-Werts verarbeitet, der mit jedem Account verknüpft ist und bei jeder Verarbeitung einer Durable-Nonce-Transaktion rotiert. Nach dieser Rotation sollte dieselbe Nonce-Transaktion nicht erneut gültig sein.

Um das Problem einzudämmen, wurden Durable-Nonce-Transaktionen vorübergehend deaktiviert. Später wurde in Solana 1.10.23 eine Lösung implementiert, die eine doppelte Ausführung verhinderte, indem sie die Nonce- und Blockhash-Domänen trennte. Beim Fortschreiben von Nonce-Accounts wird der Blockhash seit dem Update mit einer festen Zeichenfolge gehasht. Dadurch ist ein Blockhash als Nonce-Wert ungültig. Eine als reguläre Transaktion ausgeführte Transaktion kann deshalb nicht erneut als Durable-Transaktion ausgeführt werden und umgekehrt. Außerdem ersetzte ein neuer Typ namens DurableNonce die bisherigen Blockhash-Werte im Zustand des Nonce-Accounts. Das erhöht die Typsicherheit und verhindert ähnliche Probleme.

In unserem früheren Helius-Blogartikel erfährst du mehr über Durable Nonces und ihre Einsatzbereiche.

Fehler durch doppelte Blöcke: September 2022

Ausfallzeit: Achteinhalb Stunden

Ursache: Ein Fehler in den Regeln zur Fork-Auswahl führte zum Konsensausfall

Lösung: 

• Client-Patch

Auslöser dieses Ausfalls war ein Validator, der fälschlich doppelte Blöcke auf derselben Blockhöhe erzeugte. Sowohl der primäre Node des Validators als auch sein als Reserve vorgesehener Ersatz-Node waren gleichzeitig aktiv. Beide verwendeten dieselbe Node-Identität, schlugen aber unterschiedliche Blöcke vor. Dieser Zustand bestand vor dem Ausfall mindestens 24 Stunden lang. In dieser Zeit verarbeitete das Netzwerk die doppelten Leader-Slots des Validators korrekt.

Der Cluster hielt schließlich an, als das Netzwerk wegen eines Fehlers in der Fork-Auswahllogik auf einen nicht wiederherstellbaren Fork stieß. Der Fehler hinderte Blockproduzenten daran, auf dem vorherigen Block aufzubauen, wodurch der Konsens scheiterte.

Forks treten bei Solana regelmäßig auf. Validatoren lösen sie normalerweise auf, indem sie sich am Fork mit den meisten Stimmen orientieren, dem schwersten Fork. Wählt ein Validator den falschen Fork, muss er zum schwersten Fork wechseln, um mit dem Netzwerk synchron zu bleiben. In diesem Fall konnten Validatoren jedoch nicht zur schwersten Bank zurückkehren, wenn deren Slot ihrem zuletzt gewählten Slot entsprach. Deshalb blieben die Validatoren stecken, der Konsens kam nicht voran und das Netzwerk hielt schließlich an.

Im obigen Beispiel produziert der fehlerhafte Validator C doppelte Blöcke für seine Leader-Slots 5 bis 8. Als Validator G die Rolle des nächsten Leaders übernimmt, sieht er nur eines der Duplikate und erweitert seinen Fork entsprechend. Der darauffolgende Leader, Validator D, erkennt hingegen beide doppelten Blöcke von Validator C und verwirft sie. Stattdessen baut er seinen Fork auf Slot 4 auf.

Im weiteren Verlauf erhält der von Validator G erstellte Fork Stimmen von der Mehrheit des Stakes und etabliert sich als kanonische Chain. Validator D erkennt, dass sein Fork verliert, und versucht, zu Validator Gs Fork zu wechseln. Der Wechsel scheitert jedoch an einem Fehler in der Fork-Auswahllogik. Der gemeinsame Vorgänger beider Forks – ein doppelter Block in Slot 5 – wurde nicht korrekt verarbeitet. Deshalb erkennt Validator D den Mehrheits-Fork nicht. Er bleibt auf seinem eigenen Fork stecken und kann sich der Haupt-Chain nicht wieder anschließen.

Das Core-Team löste das Problem nach einer Überprüfung. Ein Patch wurde in den Master-Branch übernommen und auf alle Release-Branches zurückportiert.

Großer Block überlastet Turbine: Februar 2023

Ausfallzeit: Fast 19 Stunden

Ursache: Fehler der Deduplizierungslogik in Diensten zur Shred-Weiterleitung

Lösungen:

• Mehrere Verbesserungen an Deduplizierungslogik und Filterung von Turbine
• Client-Patch, der Blockproduzenten bei der Erzeugung großer Blöcke zum Abbruch zwingt

Der benutzerdefinierte Dienst eines Validators zur Shred-Weiterleitung versagte und übertrug während seines Leader-Slots einen außergewöhnlich großen Block mit fast 150.000 Shreds. Er war um mehrere Größenordnungen größer als ein Standardblock. Das überforderte die Deduplizierungsfilter der Validatoren, sodass die Daten kontinuierlich weitergeleitet wurden. Als neue Blöcke entstanden, verschärfte sich das Problem und sättigte schließlich das Protokoll.

Der starke Anstieg ungewöhnlichen Netzwerkverkehrs überforderte Turbine. Blockdaten mussten über das deutlich langsamere Ersatzprotokoll Block Repair übertragen werden. Turbine ist zwar dafür ausgelegt, große Blöcke herauszufiltern, doch die Dienste zur Shred-Weiterleitung arbeiten vor dieser Filterlogik und verringerten deren Wirksamkeit. Während der Leistungseinbußen wechselten Block-Leader automatisch in einen Modus, der ausschließlich Abstimmungen zuließ. Bei diesem Sicherheitsmechanismus schließen Leader wirtschaftliche Nicht-Abstimmungstransaktionen aus.

Die Ursache war ein Fehler in der Deduplizierungslogik der Dienste zur Shred-Weiterleitung. Dadurch konnten redundante Shred-Übertragungen nicht verhindert werden. Außerdem war der Deduplizierungsfilter in der Weiterleitungspipeline ursprünglich nicht darauf ausgelegt, Schleifen innerhalb des Turbine-Baums zu verhindern. Das verschärfte das Problem.

Das Netzwerk wurde manuell neu gestartet und auf die letzte bekannte stabile Version der Validator-Software zurückgesetzt. Um diese Probleme einzudämmen, verbesserten Solana v1.13.7 und v1.14.17 die Deduplizierungslogik. Dadurch konnte sie eine Filtersättigung besser verhindern und eine robustere Netzwerkleistung gewährleisten.

Endlosschleife bei der Neukompilierung: Februar 2024

Ausfallzeit: Fast fünf Stunden

Ursache: Fehler verursachte eine Endlosschleife bei der Neukompilierung im JIT-Cache

Lösungen: 

• Legacy Loader in v1.17.20 deaktiviert

Der Agave-Validator kompiliert alle Programme just-in-time (JIT), bevor er Transaktionen ausführt, die auf sie verweisen. Zur Leistungsoptimierung wird die JIT-Ausgabe häufig genutzter Programme zwischengespeichert. Das reduziert unnötige Neukompilierungen. Mit Agave v1.16 wurde der bestehende Cache-Mechanismus LoadedPrograms durch die effizientere neue Implementierung ExecutorsCache ersetzt.

LoadedPrograms bot eine globale, Fork-kompatible Ansicht zwischengespeicherter Programme. Das reduzierte die Duplizierung von Abrechnungsdaten und ermöglichte Threads zur Transaktionsausführung, neue Programme gemeinsam zu laden, um Kompilierungskonflikte zu verhindern. Eine wichtige Funktion des Systems bestand darin, den Slot zu verfolgen, in dem ein Programm aktiv wird, die sogenannte effektive Slot-Höhe. So konnten Cache-Invalidierungen erkannt werden, wenn on-chain Programmdaten aktualisiert wurden.

Die effektive Slot-Höhe der meisten Programme wurde aus ihrem Deployment-Slot abgeleitet, der in ihrem on-chain Account gespeichert war. Programme, die mit Legacy Loadern bereitgestellt wurden, speicherten diesen Deployment-Slot jedoch nicht in ihren Accounts. Als Behelfslösung wies LoadedPrograms diesen Programmen eine effektive Slot-Höhe von null zu.

Eine Ausnahme trat auf, wenn eine Deploy-Anweisung erkannt wurde. Sie signalisierte, dass der Bytecode eines Programms ersetzt worden war. In diesem Fall fügte LoadedPrograms vorübergehend einen Eintrag mit der richtigen effektiven Slot-Höhe ein. Da keine Transaktion auf diesen Eintrag verwies, konnte er jedoch leicht verdrängt werden. In diesem Fall wurde die JIT-Ausgabe verworfen und das Programm als nicht geladen markiert, während die effektive Slot-Höhe erhalten blieb.

Wenn eine Transaktion später auf dieses nicht geladene Programm verwies, kompilierte LoadedPrograms es neu und fügte an seiner effektiven Slot-Höhe einen neuen Eintrag ein. Normalerweise wäre das Programm damit bei der nächsten Iteration zur Ausführung verfügbar. Bei Legacy-Loader-Programmen wurde der neuen JIT-Ausgabe jedoch die Sentinel-Slot-Höhe null zugewiesen. Damit lag sie hinter dem vorherigen nicht geladenen Eintrag. LoadedPrograms erkannte das Programm deshalb nie als geladen und löste bei jeder Iteration eine erneute Kompilierung aus.

In Agave v1.16 unterstützte LoadedPrograms kein kooperatives Laden. Dadurch konnte die auslösende Transaktion in einen Block gepackt werden. Dieser Block wurde anschließend im gesamten Netzwerk weitergegeben. Jeder Validator spielte ihn ab und geriet in dieselbe Endlosschleife bei der Neukompilierung. Da während des Ausfalls mehr als 95 % des Cluster-Stakes Agave v1.17 nutzten, blieben die meisten Validatoren an diesem Block hängen und das Netzwerk kam zum Stillstand.

Dieser Fehler war in der Vorwoche bei der Untersuchung eines Ausfalls des Devnet-Clusters entdeckt worden und ein Patch war bereits zur Bereitstellung vorgesehen. Als Gegenmaßnahme wurden Änderungen auf Agave v1.17 zurückportiert und beim Netzwerkneustart sofort ein Feature-Gate entfernt. Dadurch wurde der Legacy Loader deaktiviert, der den Fehler ausgelöst hatte, und weitere Vorfälle wurden verhindert.

Koordinierter Schwachstellen-Patch: August 2024

Ausfallzeit: Keine

Ursache: Falsche Annahme zur Ausrichtung von ELF-Adressen

Lösungen: 

• Patch-Update 

Am 5. August wurden Anzas Core-Entwickler über eine von einem externen Forscher gemeldete Schwachstelle im Agave-Client informiert. Ein Angreifer hätte den Fehler ausnutzen können, um Leader-Validatoren zum Absturz zu bringen und das gesamte Netzwerk anzuhalten. Anzas Entwickler erstellten schnell einen Patch, den anschließend mehrere externe Sicherheitsfirmen prüften.

Solana-Programme werden mit LLVM in das Executable and Linkable Format (ELF) kompiliert. Die Schwachstelle entstand durch eine falsche Annahme zur Adressausrichtung in diesen erzeugten ELF-Dateien. Die ELF-Bereinigung erzwingt normalerweise verschiedene Integritätsprüfungen, validierte jedoch nicht die Ausrichtung des Abschnitts .text. Eine böswillig erstellte ELF-Datei hätte deshalb einen falsch ausgerichteten .text-Abschnitt definieren können. Die virtuelle Maschine wäre dadurch zu einer ungültigen Adresse gesprungen. Das hätte einen Segmentierungsfehler auf dem Host ausgelöst und den Validator zum Absturz gebracht.

Ein Angreifer hätte die Schwachstelle wie folgt ausnutzen können:

• Ein bösartiges Solana-Programm erstellen, das den Opcode CALL_REG verwendet.
• Die ELF-Datei manipulieren, um den Abschnitt .text falsch auszurichten.
• Das Programm im Netzwerk bereitstellen und aufrufen, um Validatoren zum Absturz zu bringen.

Ablauf des Patch-Updates

Ein öffentlich veröffentlichtes Patch-Update hätte die Schwachstelle sofort offengelegt. Ein Angreifer hätte dadurch womöglich genug Zeit gehabt, sie zurückzuentwickeln und das Netzwerk anzuhalten, bevor ausreichend Stake aktualisiert worden wäre. Um dieses Szenario zu vermeiden, musste eine kritische Masse von Validatoren jeden Patch so schnell wie möglich installieren.

Bis zum 7. August hatten mehrere Mitglieder der Solana Foundation Validatoren über private Nachrichten auf verschiedenen Kommunikationsplattformen kontaktiert. Sie informierten sie über einen bevorstehenden kritischen Patch und teilten eine gehashte Nachricht, die Datum und eindeutige Kennung des Vorfalls bestätigte. Mehrere bekannte Mitglieder von Anza, Jito und der Solana Foundation teilten diesen Hash auf X, GitHub und LinkedIn, um die Richtigkeit der Nachricht zu bestätigen. Geteilter Beispiel-Hash: 

trent.sol

@trentdotsol

07ff4f17c96a632726e209b4afbbcf4e6ba089989cb485b8abbe85da3f558cd9

7. Aug. 2024, 2:35 PM

Am nächsten Tag kontaktierten Core-Mitglieder weitere Validatoren und betonten die Dringlichkeit und Vertraulichkeit. Zum vorher festgelegten Zeitpunkt am 8. August um 14:00 Uhr UTC erhielten die Validator-Betreiber eine weitere Nachricht mit Anweisungen zum Herunterladen, Prüfen und Anwenden des Patches. Der Patch lag im GitHub-Repository eines bekannten Anza-Entwicklers und nicht im Agave-Hauptrepository. Die Anweisungen sahen vor, die heruntergeladenen Patch-Dateien anhand bereitgestellter Prüfsummen zu verifizieren.

Bis 20:00 Uhr UTC am 8. August war der Stake einer Supermajority gepatcht und die Netzwerksicherheit gewährleistet. Anschließend wurden die Schwachstelle und der zugehörige Patch öffentlich bekannt gegeben. Alle übrigen Validatoren wurden zum Upgrade aufgefordert.

Die stille Verteilung des Patches und die Abstimmung der Validatoren hinter den Kulissen weckten Bedenken hinsichtlich Solanas Dezentralisierung. Kurz nach dem Vorfall äußerte sich Dan Albert, Executive Director der Solana Foundation, in einem Medieninterview zu dieser Kritik.

„Ich halte es für wichtig, Zentralisierung nicht mit der Fähigkeit zur Koordination zu verwechseln. Weltweit gibt es 1.500 blockproduzierende Nodes, die von fast ebenso vielen Personen betrieben werden. … Die Fähigkeit, freiwillig mit ihnen oder einigen von ihnen zu kommunizieren, darf nicht mit Zentralisierung verwechselt werden.“

Fazit

Zum Zeitpunkt der Veröffentlichung ist Solana seit mehr als einem Jahr ohne Ausfall. Damit wurde ein wichtiger Meilenstein für das Entfernen des „Beta“-Zusatzes aus Mainnet Beta erreicht. Mit zunehmender Reife des Netzwerks scheinen Ausfälle seltener zu werden. Firedancer soll zudem die Client-Vielfalt erhöhen und so das Risiko senken, dass unentdeckte Fehler oder Grenzfälle den gesamten Cluster lahmlegen. Einige führende Community-Mitglieder, darunter Helius-Gründer Mert Mumtaz, sagen jedoch weitere Ausfälle voraus. Die Zeit wird es zeigen.

Vielen Dank an Zantetsu (Shinobi Systems) und OxIchigo für die Prüfung früherer Fassungen dieses Artikels.

Weitere Ressourcen

• Verfügbarkeit und Status von Solana