Solana blieb trotz eines Infrastrukturausfalls, der am 12. August einen Teil seines Validator-Netzwerks vorübergehend störte, betriebsfähig, so Jacob Creech, Technologieverantwortlicher der Solana Foundation.
Zusammenfassung
- 597 von 699 eingesetzten Solana-Validatoren stimmten weiterhin ab, während das Netzwerk normal Blöcke produzierte.
- 102 Validatoren stoppten vorübergehend die Abstimmung, während betroffene Betreiber innerhalb von vierzig Minuten nach der Störung wiederhergestellt wurden.
- 28,83 % des eingesetzten SOL wurden delinquent und näherten sich der Schwelle von 33,34 %, bei der die Transaktionsfinalität vollständig stoppt.
- Teraswitch gab an, dass eine fehlerhafte Route zwölf europäische und asiatische Standorte störte, bevor Ingenieure die Konnektivität wiederherstellten.
- Die Statusseite von Solana verzeichnete keinen Mainnet-Vorfall und zeigt eine 100-prozentige Cluster-Verfügbarkeit über neunzig Tage.
Von 699 eingesetzten Solana-Validatoren stimmten 597 weiterhin ab, während Blöcke und Transaktionen weiterhin verarbeitet wurden. Betroffene Validatoren erholten sich innerhalb von 40 Minuten.
Creech sagte, dass Validatoren im Solana Foundation Delegation Program nicht betroffen waren. Die offizielle Status-Seite von Solana verzeichnete am 12. oder 13. August keinen Mainnet-Vorfall und zeigte eine 100-prozentige Mainnet-Beta-Cluster-Verfügbarkeit in den letzten 90 Tagen.
Solana-Validatoren behielten die Finalität trotz eines starken Rückgangs
Während das Mainnet online blieb, zeigte eine separate Analyse, dass der Vorfall näher daran war, die Finalität zu stören, als die rohe Validatoranzahl vermuten lässt. Marinade Finance stellte fest, dass 28,83 % des gesamten eingesetzten SOL für etwa 33 Minuten delinquent wurden. Solana benötigt mehr als zwei Drittel des Einsatzes, damit Transaktionen Finalität erreichen, was die relevante Offline-Schwelle auf 33,34 % setzt.
Marinade identifizierte etwa 90 Validatoren, die von dem Routing-Fehler betroffen waren, während Creechs Zahl von 597 von 699 bedeutet, dass 102 Validatoren zu einem Zeitpunkt nicht abstimmten. Der Unterschied spiegelt getrennte Messungen wider und nicht den Beweis, dass alle 102 Validatoren denselben Infrastrukturausfall teilten.
Creech beschrieb den Vorfall als "Beweis für die Widerstandsfähigkeit von Solana." Das Netzwerk hielt der Störung stand, aber Marinades Daten zeigten auch, dass der delinquente Einsatz etwa 86 % des Niveaus erreichte, bei dem die Finalität gestoppt worden wäre.
Teraswitch-Routingfehler breitete sich von Miami nach Asien aus
Teraswitchs Status-Bericht führte das Infrastrukturproblem auf eine fehlerhafte Standardroute zurück, die von seiner MIA1-Einrichtung in Miami stammte. Ein Route-Reflektor in Amsterdam verbreitete die geänderte Route in europäische und asiatisch-pazifische Märkte, wo lokale Router sie gegenüber gültigen Routen bevorzugten. Zwölf Standorte in London, Amsterdam, Dublin, Frankfurt, Singapur und Tokio verloren die Erreichbarkeit. Nordamerikanische Standorte waren nicht betroffen.
Ingenieure identifizierten die fehlerhafte Route innerhalb von 10 Minuten und entfernten Miami aus dem privaten Backbone. Der Dienst kehrte um 04:16:15 UTC zurück. Teraswitch setzte später eine globale Änderung auf seinen Computestandorten ein, sodass eine ähnlich fehlerhafte Route den Verkehrsweiterleitung nicht blockieren sollte. Der Anbieter sagte, dass der zugrunde liegende Defekt weiterhin untersucht wird und ein vollständiger Root-Cause-Bericht folgen wird.
Das Ereignis legte auch die Infrastrukturkonzentration unter Validatoren offen. Marinade berechnete, dass ein autonomes System etwa 118,9 Millionen SOL hielt, mehr als ein Viertel des gesamten eingesetzten SOL, und etwa 94 % dieses Einsatzes ging gleichzeitig offline.
Solana vermeidet eine Wiederholung seines Netzwerkausfalls von 2024
Das Ergebnis steht im Gegensatz zu dem Neustart des Netzwerks im Februar 2024, nachdem die Blockproduktion gestoppt worden war. Bei diesem Vorfall war ein koordinierter Neustart der Validatoren erforderlich, und Solana blieb fast fünf Stunden lang offline. Der Infrastrukturausfall am 12. August erforderte keinen Mainnet-Neustart.
Solana hat seitdem durch unabhängige Validator-Software zusätzliche Widerstandsfähigkeit angestrebt. In verwandter Berichterstattung begann Firedancer, Solana-Mainnet-Blöcke zu produzieren im Jahr 2026, was einen weiteren Validator-Client-Pfad neben dem dominierenden Agave-Ökosystem hinzufügte.
Die jüngste Störung testete eine andere Art der Dezentralisierung: physisches Hosting und Netzwerkkonnektivität statt Validator-Software. Solana verarbeitete weiterhin Transaktionen, aber die Konzentration des Stakes hinter gemeinsamer Infrastruktur ermöglichte es, dass ein einziger Provider-Ausfall einen großen Teil des Abstimmungs-Stakes auf einmal entfernte.
Was als Nächstes passiert
Teraswitchs sofortige Konfigurationskorrektur ist bereits bereitgestellt, aber die Untersuchung ist noch nicht abgeschlossen. Der Provider untersucht weiterhin, warum die Miami-Standardroute mit falschen Attributen angekündigt wurde, und hat seinen Hardware-Anbieter eingeschaltet. Ein vollständiger Bericht wird erwartet, sobald diese Arbeit abgeschlossen ist.
Validator-Betreiber werden wahrscheinlich auch einer genaueren Prüfung der Infrastruktur-Redundanz ausgesetzt sein. Marinade gab an, dass es plant, Konzentrationsgrenzen nach autonomen Systemen und Rechenzentren zu überprüfen und mehr Transparenz bei automatischen Failover-Vereinbarungen zu schaffen. Für Solana ist der nächste Test, ob diese Infrastrukturänderungen den Anteil des Stakes verringern, der einem einzelnen Routing-Ausfall ausgesetzt ist.
