Solanas 50.000-SOL-Sicherheitswettbewerb deckte einen Monate zuvor offengelegten Angriff auf die Uhr nicht ab

Auf der USENIX Security, einer der großen Peer-Review-Konferenzen des Fachgebiets, stellten Forscher am 12. August einen Angriff auf die Proof-of-History-Uhr von Solana vor, den sie Solana-Entwicklern bereits im Dezember 2025 privat gemeldet hatten. Anza — das Unternehmen, das den Validator-Client Agave entwickelt — beendete sieben Tage später seinen 50.000-$SOL-Alpenglow-Wettbewerb, und dessen Regeln scheinen den Angriff aus dem Geltungsbereich ausgeschlossen zu haben.

Das Papier beschreibt eine protokollkonforme Methode, mit der ein geplanter Leader sein effektives Blockfenster dehnen und in einer fork-gestützten Variante die Vorschläge ehrlicher Leader unterdrücken kann. Die Technik beruht auf Proof-of-History und TowerBFT — Solanas logischer Uhr und dem darauf aufbauenden Konsensmechanismus —, also den Komponenten, die Alpenglow ersetzen soll, die in Agave 4.2 auf dem Mainnet jedoch noch nicht verdrängt worden waren.

Das Ergebnis wirft zwei getrennte Fragen auf: ob der Angriff in den Geltungsbereich des Wettbewerbs fiel und ob der Protokollübergang selbst Raum für Risiko lässt.

Die Wettbewerbsregeln schlossen Verhalten aus, das nur erreichbar ist, wenn Alpenglow inaktiv war. Öffentliche Designdokumente deuten darauf hin, dass der exakte Legacy-Pfad des Papiers nach der Aktivierung unerreichbar werden sollte, doch Anza und die Solana Foundation haben keine auf das Papier bezogene Entscheidung oder Implementierungsanalyse veröffentlicht.

Wie ein Leader Solanas Uhr dehnen kann

Proof-of-History, kurz PoH, verwendet eine sequenzielle Hash-Kette, um Solana eine logische Uhr zu geben. Validatoren treiben ihre lokale Sicht dieser Uhr auch dann weiter voran, wenn ein geplanter Leader nicht sofort einen Block veröffentlicht.

Nach Angaben der Forscher kann ein bösartiger geplanter Leader einen protokollkonformen Block zurückhalten, während ehrliche Validatoren voranschreiten, und ihn später — auf einen früheren Punkt der logischen Zeit verankert — veröffentlichen. Übernehmen die Validatoren diesen Zweig, richten sie ihren PoH-Zustand an dem früheren Punkt des Blocks aus. Die Forscher nennen dieses Zurücksetzen „Re-Anchoring“.

Time Inflation (TI) wiederholt dieses Manöver, um dem Angreifer mehr physische Zeit für die Auswahl von Transaktionen zu verschaffen, während die logische Zeit langsamer fortschreitet. Fork-Assisted Time Inflation (FTI) kombiniert das Zurücksetzen mit der Fork-Wahl von TowerBFT.

Unter den modellierten Bedingungen kann der Zweig des Angreifers einen Block eines ehrlichen Leaders verwaisen lassen, und Solanas Regel eines Blocks pro Slot verhindert, dass dieser Leader für denselben Slot einfach einen weiteren Block erzeugt.

Das Bedrohungsmodell stattet den Angreifer mit weniger als 33 % des Stakings aus — unterhalb der Ein-Drittel-Fehlerschranke, für deren Toleranz byzantinisch fehlertolerante Protokolle konventionell ausgelegt sind — und gibt ihm keine Kontrolle über den Netzwerk-Scheduler. Es nimmt einen bekannten, staking-gewichteten Leader-Zeitplan, partielle Synchronität sowie die Zustellung eines ehrlichen Blocks an ehrliche Validatoren innerhalb eines nominellen Slots nach der Stabilisierung des Netzwerks an.

Für einen Angreifer, der ℓ aufeinanderfolgende Leader-Runden mit je vier Slots kontrolliert, verwenden die Experimente eine konservative, staking-unabhängige maximale Verzögerung von 4ℓ + 1 Slot-Einheiten. Eine Runde entspricht einem Verzögerungsparameter von fünf Slot-Einheiten.

Das Papier sagt, dass mehr Staking ein risikofreies Freigabefenster verbreitern könnte, führt diese experimentelle Konfiguration jedoch nicht als universelles Mainnet-Ergebnis an.

Die Forscher implementierten TI und FTI auf einem lokalen Solana-Testnet und nutzten Simulationen für Angreiferkonfigurationen über gesamte Epochen. Sie identifizierten keine bestimmte betroffene Agave-Version, weshalb das Papier nicht belegt, dass jede aktuelle Client-Version in gleicher Weise betroffen ist.

Was öffentliche Daten zeigen

Die Forscher untersuchten zudem öffentliche Mainnet-Daten und wählten zwei Validatoren aus, die wiederholt im Tail der Verteilung der Zeitstempel-Intervalle lagen. Diese Validatoren verbanden längere Intervalle mit höherer Transaktions-Inklusion und niedrigen Skip-Raten.

Das Muster ist mit dem Anreizkanal von TI vereinbar, weil ein längeres physisches Fenster mehr Gelegenheiten bietet, gebührentragende Transaktionen auszuwählen — ein Vorteil bei der Transaktionsreihenfolge, wie ihn die breitere Branche unter dem Label Maximal Extractable Value, kurz MEV, diskutiert.

Das Papier sagt, dass Hardware-Unterschiede, lokales Batching oder andere Konfigurationsentscheidungen, Netzwerkbedingungen und betriebliche Störungen ähnliche Zeitmuster erzeugen könnten. Es fand zudem keine signifikant erhöhte nachgelagerte Skip-Rate und erklärte, dass das beobachtete Muster mit einer Zuschreibung zu FTI unvereinbar sei.

Die Forschung belegt durch kontrollierte Tests und indikative Messungen ein protokollkonformes Fairness- und Latenzproblem. Sie zeigt keinen Live-Exploit, keinen Diebstahl, keine demonstrierte Mainnet-Manipulation und keinen Bruch der Konsenssicherheit.

Warum der Solana-Alpenglow-Wettbewerb ihn vermutlich ausschloss

Die Einreichungen für den Alpenglow-Wettbewerb schlossen am 19. August um 16:00 UTC. Die Regeln umfassten die Konsensfläche bei aktiviertem Alpenglow-Feature, Integrationscode, dessen Verhalten sich änderte, weil Alpenglow aktiv war, sowie den Migrationspfad von TowerBFT zu Alpenglow.

Verhalten, das nur erreichbar war, wenn Alpenglow inaktiv war, gehörte zur Domäne von TowerBFT und lag außerhalb des Wettbewerbs. Bereits zuvor öffentlich bekannte Issues waren ebenfalls nicht zugelassen.

Die Lücke ist in zeitlich begrenzten Sicherheitswettbewerben vertraut: Über die Belohnung entscheiden die Regeln zum Geltungsbereich, nicht der Schweregrad. Der Wettbewerb deckte Fehler ab, die von Alpenglow oder dessen Migration verursacht wurden, während das Papier auf das Legacy-Modell von Zeit und Fork-Wahl abzielt, das Alpenglow ersetzen soll.

Was Alpenglow verändert

Anzas Alpenglow-Übersicht besagt, dass das Upgrade TowerBFT und PoH als Kernkomponenten des Konsenses durch Votor ersetzt. Der offizielle SIMD-0326-Vorschlag — ein Solana Improvement Document im formellen Änderungsprozess des Netzwerks — beschreibt lokale Timeouts, die eine Zeitgeberfunktion ohne synchronisierte Zeit übernehmen, und stuft die Änderung als nicht abwärtskompatibel ein.

Diese Designs beseitigen die Voraussetzungen — PoH-Re-Anchoring und TowerBFT-Fork-Wahl —, auf die TI und FTI setzen. Die öffentliche Dokumentlage enthält keine Analyse von Anza oder der Solana Foundation, die jeden Angriffsschritt auf den ausgelieferten Alpenglow-Code abbildet oder ein analoges Problem in der Migrationslogik ausschließt.

Nach Angaben der Forscher reagierte das Solana-Entwicklungsteam innerhalb eines Tages auf die Meldung vom Dezember 2025. Das Papier sagt, dass das Team das Verhalten intern als bekannt betrachtete, erwartete, dass ein künftiges Protokoll-Upgrade wie Alpenglow es beheben würde, es überwachte und die schwerwiegendsten Szenarien unter den aktuellen Bedingungen als unwahrscheinlich einstufte.

Die Autoren sagten außerdem, dass bis zur Veröffentlichung keine vollständigen Gegenmaßnahmen umgesetzt worden waren.

Einer Übersicht der Solana Foundation zu Agave 4.2 zufolge enthielt der Client Alpenglow-Code für Community-Testcluster, aktivierte den neuen Konsens auf dem Mainnet jedoch nicht; die Aktivierung wird für Agave 4.3 erwartet.

Der Legacy-PoH-Angriff des Papiers scheint außerhalb des 50.000-$SOL-Wettbewerbs gefallen zu sein, und Alpenglow ist darauf ausgelegt, seine genauen Voraussetzungen zu beseitigen. Bis zur Aktivierung — erwartet in Agave 4.3 — und einer öffentlichen Antwort auf Implementierungsebene bleibt der Übergang der ungelöste Teil der Geschichte.