Solana’s beveiligingswedstrijd van 50.000 SOL dekte een eerder onthulde klokaanval niet af

Op USENIX Security, een van de belangrijkste peer-reviewed conferenties in het vakgebied, presenteerden onderzoekers op 12 augustus een Solana Proof-of-History-klokaanval die zij in december 2025 privé aan Solana-ontwikkelaars hadden gemeld. Anza — het bedrijf dat de Agave-validatorclient ontwikkelt — sloot zeven dagen later zijn Alpenglow-wedstrijd van 50.000 $SOL, en de regels lijken de aanval buiten de scope te hebben geplaatst.

Het paper beschrijft een protocolgeldige methode waarmee een geplande leider zijn effectieve blockvenster kan verlengen en voorstellen van eerlijke leiders kan onderdrukken in een fork-assisted variant. De techniek is afhankelijk van Proof-of-History en TowerBFT — Solana’s logische klok en het consensusmechanisme dat daarop is gebouwd — de onderdelen die Alpenglow moet vervangen maar die op mainnet in Agave 4.2 nog niet waren verdrongen.

De uitkomst roept twee afzonderlijke vragen op: of de aanval binnen de wedstrijdscope viel, en of de protocolovergang zelf ruimte laat voor risico.

De wedstrijdregels sloten gedrag uit dat alleen bereikbaar is wanneer Alpenglow inactief was. Openbare ontwerpdokumenten geven aan dat het exacte legacy-pad uit het paper na activatie onbereikbaar zou moeten worden, maar Anza en de Solana Foundation hebben geen paper-specifieke beoordeling of implementatieanalyse gepubliceerd.

Hoe een leider Solana’s klok kan oprekken

Proof-of-History, of PoH, gebruikt een sequentiële hash-keten om Solana een logische klok te geven. Validators blijven hun lokale beeld van die klok vooruitzetten wanneer een geplande leider niet onmiddellijk een block publiceert.

Volgens de onderzoekers kan een kwaadwillige geplande leider een protocolgeldige block achterhouden terwijl eerlijke validators doorgaan, en de block later vrijgeven, verankerd aan een eerder punt in de logische tijd. Als validators die tak accepteren, stemmen zij hun PoH-status af op het eerdere punt van de block. De onderzoekers noemen deze reset “re-anchoring”.

Time Inflation, of TI, herhaalt die manoeuvre om de aanvaller meer fysieke tijd te geven om transacties te kiezen terwijl de logische tijd langzamer vooruitgaat. Fork-Assisted Time Inflation, of FTI, combineert de reset met TowerBFT-forkkeuze.

Onder de gemodelleerde omstandigheden kan de tak van de aanvaller een block van een eerlijke leider verweesd achterlaten, en Solana’s regel van één block per slot verhindert dat die leider simpelweg nog een block voor hetzelfde slot produceert.

Het dreigingsmodel geeft de tegenstander minder dan 33% van de stake — onder de foutgrens van een derde waarvoor Byzantine-fault-tolerante protocollen doorgaans zijn ontworpen — en geen controle over de netwerkscheduler. Het veronderstelt een bekende, stake-gewogen leaderschedule, partiële synchronie en levering van een eerlijke block aan eerlijke validators binnen één nominaal slot nadat het netwerk is gestabiliseerd.

Voor een aanvaller die ℓ opeenvolgende vier-slot leader-rondes controleert, gebruiken de experimenten een conservatieve, stake-agnostische maximale vertraging van 4ℓ + 1 slot-eenheden. Eén ronde komt overeen met een vertragingparameter van vijf slot-eenheden.

Het paper zegt dat meer stake het venster voor risicovrije vrijgave zou kunnen vergroten, maar presenteert die experimentele instelling niet als een universeel mainnet-resultaat.

De onderzoekers implementeerden TI en FTI op een lokale Solana-testnet en gebruikten simulaties voor aanvallersconfiguraties over een volledige epoch. Zij identificeerden geen specifieke getroffen Agave-release, dus het paper toont niet aan dat elke huidige clientversie op dezelfde manier blootstaat.

Wat openbare data laat zien

De onderzoekers bestudeerden ook openbare mainnet-data en selecteerden twee validators die herhaaldelijk in de staart van de distributie van timestamp-intervals zaten. Die validators combineerden langere intervallen met een hogere opname van transacties en lage skip-rates.

Dit patroon is consistent met TI’s prikkelmechanisme, omdat een langer fysiek venster meer mogelijkheden creëert om transacties met fees te selecteren.

Het paper zegt dat hardwareverschillen, lokale batching of andere configuratiekeuzes, netwerkcondities en operationele verstoringen vergelijkbare timingpatronen kunnen veroorzaken. Het vond ook geen significant verhoogde downstream skip-rate en zei dat het waargenomen patroon niet consistent was met toeschrijving aan FTI.

Het onderzoek toont via gecontroleerde tests en indicatieve metingen een protocolgeldige fairness- en latencykwestie aan. Het laat geen live exploit, diefstal, gedemonstreerde mainnet-manipulatie of een consensusveiligheidsbreuk zien.

Waarom de Solana Alpenglow-wedstrijd het waarschijnlijk uitsloot

Inzendingen voor de Alpenglow-wedstrijd sloten op 19 aug. om 16:00 UTC. De regels bestreken het Alpenglow-feature-actieve consensusoppervlak, integratiecode waarvan het gedrag veranderde doordat Alpenglow actief was, en het migratiepad van TowerBFT naar Alpenglow.

Gedrag dat alleen bereikbaar was wanneer Alpenglow inactief was, viel onder het TowerBFT-domein en lag buiten de wedstrijd. Eerder publiek bekende issues kwamen ook niet in aanmerking.

De wedstrijd dekte fouten veroorzaakt door Alpenglow of de migratie ervan, terwijl het paper zich richt op het legacy-model van tijd en forkkeuze dat Alpenglow moet vervangen.

Wat Alpenglow verandert

Volgens Anza’s Alpenglow-overzicht vervangt de upgrade TowerBFT en PoH als kerncomponenten van het consensusmechanisme door Votor. Het officiële SIMD-0326-voorstel beschrijft lokale time-outs die een timingrol vervullen zonder gesynchroniseerde tijd en noemt de verandering backward-incompatible.

Die ontwerpen verwijderen de PoH-re-anchoring- en TowerBFT-forkkeuzevoorwaarden die TI en FTI gebruiken. In de publieke stukken ontbreekt een analyse van Anza of de Solana Foundation waarin elke stap van de aanval wordt gemapt op uitgeleverde Alpenglow-code of waarin een vergelijkbaar probleem in migratielogica wordt uitgesloten.

Volgens de onderzoekers reageerde het Solana-developmentteam binnen één dag na de onthulling in december 2025. Het paper zegt dat het team het gedrag intern als bekend beschouwde, verwachtte dat een toekomstige protocolupgrade zoals Alpenglow het zou adresseren, erop monitorde en de meest ernstige scenario’s onder de huidige omstandigheden onwaarschijnlijk achtte.

De auteurs zeiden ook dat mitigatie bij publicatie nog niet volledig was uitgerold.

Een overzicht van de Solana Foundation over Agave 4.2 zei dat de client Alpenglow-code bevatte voor community-testclusters, maar het nieuwe consensusmechanisme op mainnet niet activeerde; activatie werd verwacht in Agave 4.3.

De legacy PoH-aanval uit het paper lijkt buiten de wedstrijd van 50.000 $SOL te zijn gevallen, en Alpenglow is ontworpen om de exacte voorwaarden ervoor te verwijderen. Tot activatie en een openbare implementatiegerichte reactie blijft de overgang het onopgeloste deel van het verhaal.