Ein fehlkonfigurierter Netzwerkpfad brachte Solana am Mittwoch dicht an den Stillstand: 28,83% des gestakten SOL wurden gleichzeitig delinquent; bei 33,34% stoppt die Finalität. Der Solana Routingfehler Teraswitch konzentrierte sich auf ein Autonomous System und legte rund 90 Validatoren lahm; Belohnungen von 333 SOL gingen verloren. Solana stand an diesem Morgen nur 4,51 Prozentpunkte vor einem Finalitätsstopp. Auslöser war ein einzelner Routingfehler bei Teraswitch. Binnen Minuten gingen fast 29% der gestakten Coins offline. Die Kette finalisiert bei 33,34% Delinquenz nicht mehr. Damit war das Netzwerk zu rund 86% auf dem Weg zu einem Stopp. Teraswitch legte später detailliert dar, wie ein falsch propagierter Standardpfad (Default Route) diese Kettenreaktion auslöste. Besonders betroffen war ein einziges Autonomous System (AS20326), das mehr als ein Viertel der gestakten SOL trägt. 94% dieser Kapazität fielen gleichzeitig aus. Rund 90 Validatoren verloren zusammen 333 SOL an Belohnungen.

Was genau passierte: Solana Routingfehler Teraswitch

Ein falscher Standardpfad wanderte über Kontinente

Teraswitch nutzt intern eine Default Route, um anzuzeigen, dass ein Edge-Router das Internet erreichen kann. Normalerweise bevorzugt jeder Standort die Route, die seine eigenen Router erzeugen. In diesem Fall wurde eine Default Route aus dem Standort Miami mit entfernten Metriken und Communities weitergegeben. Ein Route Reflector in Amsterdam verteilte sie nach Europa und in den asiatisch-pazifischen Raum. Dort interpretierten Edge-Router die Route fälschlich als lokal erzeugt und bevorzugten sie gegenüber ihrer gültigen Route. Sie gaben sie ins Rechenzentrums-Core weiter, das sie wiederum als ungültig verwarf. Ergebnis: Zwölf Standorte in London, Amsterdam, Dublin, Frankfurt, Singapur und Tokio hatten vorübergehend keinen gültigen Pfad mehr. Nordamerika blieb verschont. Ingenieure lokalisierten den Fehler innerhalb von zehn Minuten; der Dienst war um 04:16:15 UTC wiederhergestellt.

Eine einzige Fehlinformation, viele gleichzeitige Ausfälle

Der Vorfall zeigt, wie eine scheinbar kleine Konfigurationsabweichung breitflächige Folgen haben kann. Ein Strippen der Attribute der Default Route reichte aus, um Prioritäten zu verschieben. Edge-Geräte bevorzugten die falsche Route, die Core-Instanzen verwarfen sie, und am Ende blieb kein valider Forwarding-Pfad. Die Ausfälle konzentrierten sich dadurch in einer engen Zeitspanne und betrafen viele Validatoren gleichzeitig.

Wie nah Solana an einem Finalitätsstopp war

Die Kette stoppt die Finalisierung bei 33,34% delinquentem Stake. An diesem Morgen gingen 28,83% offline. Damit fehlten nur 4,51 Prozentpunkte. In Relation entspricht das etwa 86% des Weges bis zum Stopp. Diese Nähe verdeutlicht, wie empfindlich die Finalität auf grobe Konzentrationen und gleichzeitige Ausfälle reagiert.

Die Schwelle ist bekannt – das Fenster war eng

– 28,83% delinquent gegenüber der 33,34%-Schwelle – „86% des Weges“ bis zum Finalitätsstopp – Rund 90 betroffene Validatoren – 333 SOL an verpassten Belohnungen

Konzentrationsrisiko: AS20326 überschreitet die Kappung

Staking-Protokoll Marinade Finance fasste die Zahlen zusammen. Die Ausfälle konzentrierten sich auf ein einziges Autonomous System. AS20326 trägt 118.890.767 SOL und damit mehr als ein Viertel des gesamten gestakten Kapitals im Netzwerk. 94% dieses Anteils gingen im selben Zeitfenster offline. Das liegt über der Kappung, die das Delegationsprogramm der Solana Foundation vorsieht: Pro Autonomous System sollen es maximal 25% sein. Tatsächlich lag AS20326 bei 27,34%.

Warum eine einzige AS-Konzentration so riskant ist

Wenn ein übergroßer Anteil des Stakes über eine identische Netzebene läuft, können Routingstörungen viele Validatoren zugleich treffen. Genau das geschah hier: Eine Fehlroute breitete sich in Europa und Asien schnell aus, sodass sich Ausfälle bündelten. Dadurch rückte die Kette sehr nahe an den Punkt, an dem keine Transaktion mehr finalisiert.

Mehr als ein Provider war betroffen

Die Abhängigkeit ging über einen Anbieter hinaus. Zusätzlich gingen 14,1 Millionen SOL in demselben Zeitfenster bei latitude.sh, Limestone, Butterfly Research und Allnodes offline. Marinade konnte das aus den vorliegenden Daten nicht erklären. Das deutet darauf hin, dass eine Zählung nach Hosting-Providern unterschätzt, was in der Praxis zusammen ausfällt. Korrelationen entlang Netzwerkgrenzen sind entscheidend – nicht nur entlang Marken- oder Anbieternamen.

Auswirkungen auf Validatoren und Belohnungen

Marinade erfasste, dass 59 Validatoren mit zusammen 80,2 Millionen SOL in Amsterdam, Frankfurt und Tokio innerhalb desselben schmalen Fensters wieder online kamen. Sie warteten offenbar auf die erneute Konvergenz des Routings, statt aktiv zu wechseln. Helius, der zweitgrößte Validator auf Solana, war volle 33 Minuten down. Von 74 messbaren Operatoren kamen drei „sauber“ zurück: Laine und Cogent Crypto (beide betrieben von Sol Strategies) sowie Lion3d.

Belohnungen und Bonds

Die Summe der verpassten Rewards betrug 333 SOL. Sie wird am Ende der Epoche aus Validator-Bonds gedeckt. Hätte die Delinquenz die Ein-Drittel-Marke überschritten, wäre die Finalisierung für niemanden mehr möglich gewesen. Ein Bond deckt einen solchen Systemstillstand nicht. Zum Vergleich: Beim letzten vollständigen Halt im Februar 2024 dauerte der Neustart fast fünf Stunden.

Was Marinade für sich selbst feststellte

Marinade wandte dieselbe Analyse auf die eigene Allokation an. Vier autonome Systeme halten zwei Drittel des Stakes, den das Modell verteilt. Eines davon, AS395201, kommt auf 36,94%. „Niemand sollte damit zufrieden sein – wir eingeschlossen“, schrieb das Team sinngemäß. Marinade will die eigenen Konzentrationsgrenzen pro Netzwerk und pro Rechenzentrum prüfen. Zudem will der Pool künftig veröffentlichen, ob ein Validator Hot-Swap und automatische Failover nutzt. Von außen lässt sich das derzeit nicht erkennen.

Transparenz über Setups wird wichtiger

Wenn Betreiber offenlegen, ob Hot-Swap und automatische Umschaltung aktiv sind, lässt sich das reale Ausfallrisiko besser einschätzen. Die Analyse von Marinade zeigt, dass reine Providerlisten wenig über gemeinsame Ausfallpfade verraten. Sichtbar werden muss, wie Validatoren netzwerkseitig angebunden sind – und ob alternative Pfade im Notfall automatisch greifen.

Zeitlinie und Geografie des Vorfalls

– Fehlerentdeckung: innerhalb von zehn Minuten – Service-Wiederherstellung: 04:16:15 UTC – Betroffene Regionen: Europa (u. a. London, Amsterdam, Dublin, Frankfurt) und Asien-Pazifik (Singapur, Tokio) – Unbetroffen: Nordamerika Die Kombination aus einem global verbreiteten falschen Standardpfad und der Knotenstruktur in Europa und Asien führte zu gleichzeitigen Ausfällen. Die schnelle Suche und Behebung durch Teraswitch begrenzte die Dauer.

Lehren aus dem Solana Routingfehler Teraswitch

Diese Störung macht drei Punkte deutlich: – Ein einzelner Routingfehler kann große Teile eines hochkonzentrierten Stakes gleichzeitig treffen. – Kappungen auf AS-Ebene sind sinnvoll, müssen aber eingehalten werden, sonst steigt das Systemrisiko. – Sichtbarkeit über Netz-Setups, Hot-Swap und Failover-Mechanismen ist entscheidend, um Korrelationen zu verstehen. Die Zahlen sprechen für sich: 28,83% delinquent und nur 4,51 Prozentpunkte bis zur Finalitätsschwelle. 94% Ausfall in einem einzigen Autonomous System. 333 SOL entgangene Belohnungen. Und doch blieb Nordamerika unbeeinträchtigt – ein Hinweis darauf, wie stark regionale Routingentscheidungen wirken. Am Ende zeigt dieses Ereignis, wie wichtig dezentrale Verteilung jenseits einzelner AS-Grenzen ist. Die Untersuchung von Marinade unterstreicht, dass auch Staking-Pools ihre Allokationen breit über mehrere Netze und Rechenzentren streuen sollten. Wo Konzentration wächst, wächst auch das Risiko eines gleichzeitigen Ausfalls. Dieser Vorfall war kurz, aber lehrreich. Er brachte Solana nah an einen systemweiten Stillstand, ohne ihn zu überschreiten. Die Reaktionszeit war schnell, die Wiederherstellung klar dokumentiert. Entscheidend bleibt nun, dass die offengelegten Konzentrationen adressiert werden. Je konsequenter Stake- und Netzverteilung an realen Abhängigkeiten ausgerichtet wird, desto stabiler bleibt die Finalität – auch wenn der nächste Solana Routingfehler Teraswitch-ähnlicher Art wieder unerwartet auftritt.

(Source: https://decrypt.co/375404/a-routing-bug-took-solana-86-of-the-way-to-losing-finality)

For more news: Click Here

FAQ