Le concours de sécurité de 50 000 SOL de Solana n'a pas couvert l'attaque d'horloge divulguée plus tôt
Points clés
- •Des chercheurs ont divulgué en privé une attaque contre l'horloge Proof-of-History de Solana aux développeurs de Solana en décembre 2025 et l'ont présentée publiquement à USENIX Security le 12 août.
- •Cette attaque, baptisée Time Inflation, permet à un leader programmé disposant de moins d'un tiers de la mise de retenir un bloc valide au sens du protocole et de réancrer les validateurs à un point antérieur du temps logique, gagnant ainsi du temps physique supplémentaire pour la sélection des transactions et pouvant potentiellement rendre orphelins les blocs des leaders honnêtes en vertu de la règle de Solana d'un seul bloc par slot.
- •Les règles du concours Alpenglow de 50 000 SOL d'Anza semblent avoir exclu l'attaque car elle repose sur des comportements hérités de Proof-of-History et de TowerBFT atteignables uniquement lorsqu'Alpenglow est inactif.
- •La recherche a démontré un problème d'équité et de latence valide au sens du protocole grâce à des implémentations sur testnet et des simulations, mais elle n'a montré ni exploit en conditions réelles, ni vol, ni manipulation démontrée du mainnet, ni rupture de la sécurité du consensus.
- •Alpenglow remplace PoH et TowerBFT par Votor et devrait être activé dans Agave 4.3, supprimant ainsi les prérequis énoncés de l'attaque, même si ni Anza ni la Solana Foundation n'a publié d'analyse d'implémentation spécifique à l'article.

Le concours de sécurité de 50 000 SOL de Solana n'a pas couvert une attaque d'horloge divulguée des mois plus tôt
À USENIX Security, l'une des grandes conférences à comité de lecture du domaine, des chercheurs ont présenté le 12 août une attaque contre l'horloge Proof-of-History de Solana qu'ils avaient divulguée en privé aux développeurs de Solana en décembre 2025. Anza — la société qui développe le client de validateur Agave — a clôturé sept jours plus tard son concours Alpenglow doté de 50 000 $SOL, et ses règles semblent avoir placé l'attaque hors du périmètre.
L'article décrit une méthode valide au sens du protocole par laquelle un leader programmé peut étendre sa fenêtre effective de bloc et supprimer les propositions des leaders honnêtes dans une variante assistée par fork. La technique repose sur Proof-of-History et TowerBFT — l'horloge logique de Solana et le mécanisme de consensus construit au-dessus d'elle — les composants qu'Alpenglow est destiné à remplacer mais qu'il n'avait pas encore évincés du mainnet dans Agave 4.2.
Ce résultat soulève deux questions distinctes : d'une part, savoir si l'attaque relevait du périmètre du concours ; d'autre part, si la transition du protocole elle-même laisse place à un risque.
Les règles du concours excluaient les comportements atteignables uniquement lorsqu'Alpenglow était inactif. Les documents de conception publics indiquent que le chemin hérité exact décrit dans l'article devrait devenir inatteignable après l'activation, mais Anza et la Solana Foundation n'ont publié ni adjudication ni analyse d'implémentation spécifiques à l'article.
Comment un leader peut étirer l'horloge de Solana
Proof-of-History, ou PoH, utilise une chaîne de hachage séquentielle pour fournir à Solana une horloge logique. Les validateurs continuent de faire avancer leur vue locale de cette horloge lorsqu'un leader programmé ne publie pas immédiatement un bloc.
Selon les chercheurs, un leader programmé malveillant peut retenir un bloc valide au sens du protocole pendant que les validateurs honnêtes avancent, puis publier ultérieurement le bloc ancré à un point antérieur du temps logique. Si les validateurs acceptent cette branche, ils alignent leur état PoH sur le point antérieur du bloc. Les chercheurs appellent cette réinitialisation le « re-anchoring » (réancrage).
Time Inflation, ou TI, répète cette manœuvre pour donner à l'attaquant davantage de temps physique pour choisir des transactions pendant que le temps logique avance plus lentement. Fork-Assisted Time Inflation, ou FTI, combine cette réinitialisation avec le choix de fork de TowerBFT.
Dans les conditions modélisées, la branche de l'attaquant peut rendre orphelin le bloc d'un leader honnête, et la règle de Solana d'un seul bloc par slot empêche ce leader de simplement produire un autre bloc pour le même slot.
Le modèle de menace donne à l'adversaire moins de 33 % de la mise — en deçà de la borne de défaillance d'un tiers que les protocoles tolérants aux fautes byzantines sont conventionnellement conçus pour tolérer — et aucun contrôle sur l'ordonnanceur du réseau. Il suppose un calendrier de leaders connu et pondéré par la mise, une synchronie partielle, et la livraison d'un bloc honnête aux validateurs honnêtes dans un délai d'un slot nominal après la stabilisation du réseau.
Pour un attaquant contrôlant ℓ tours de leader consécutifs de quatre slots chacun, les expériences utilisent un délai maximal conservateur et indépendant de la mise de 4ℓ + 1 unités de slot. Un tour correspond à un paramètre de délai de cinq unités de slot.
L'article indique qu'une mise plus importante pourrait élargir une fenêtre de publication sans risque, mais il ne présente pas ce cadre expérimental comme un résultat universel du mainnet.
Les chercheurs ont implémenté TI et FTI sur un testnet Solana local et ont utilisé des simulations pour des configurations d'attaquant sur des époques complètes. Ils n'ont pas identifié de version d'Agave spécifiquement concernée ; l'article n'établit donc pas que chaque version actuelle du client est exposée de la même manière.
Ce que montrent les données publiques
Les chercheurs ont également étudié des données publiques du mainnet et sélectionné deux validateurs qui se situaient de façon répétée dans la queue de la distribution des intervalles d'horodatage. Ces validateurs associaient des intervalles plus longs à une inclusion de transactions plus élevée et à de faibles taux de saut.
Ce schéma est cohérent avec le canal incitatif de TI, car une fenêtre physique plus longue crée davantage d'occasions de sélectionner des transactions génératrices de frais — un avantage d'ordonnancement des transactions du type que l'industrie au sens large désigne sous le terme de valeur extractible maximale, ou MEV.
L'article indique que des différences matérielles, le traitement par lots local ou d'autres choix de configuration, les conditions réseau et des perturbations opérationnelles pourraient également créer des schémas temporels similaires. Il n'a pas non plus constaté de taux de saut en aval significativement élevé et a jugé le schéma observé incompatible avec une attribution à FTI.
La recherche établit un problème d'équité et de latence valide au sens du protocole au moyen de tests contrôlés et de mesures indicatives. Elle ne montre ni exploit en conditions réelles, ni vol, ni manipulation démontrée du mainnet, ni rupture de la sécurité du consensus.
Pourquoi le concours Alpenglow de Solana l'a probablement exclu
Les soumissions au concours Alpenglow ont été clôturées le 19 août à 16 h 00 UTC. Les règles couvraient la surface de consensus avec la fonctionnalité Alpenglow active, le code d'intégration dont le comportement changeait du fait de l'activation d'Alpenglow, et le chemin de migration de TowerBFT vers Alpenglow.
Les comportements atteignables uniquement lorsqu'Alpenglow était inactif relevaient du domaine de TowerBFT et étaient hors concours. Les problèmes déjà rendus publics étaient également inéligibles.
Cet écart est un classique des concours de sécurité à durée limitée : ce sont les règles de périmètre, et non la gravité, qui déterminent ce qui est récompensé. Le concours couvrait les défaillances causées par Alpenglow ou sa migration, tandis que l'article cible le modèle hérité de temps et de choix de fork qu'Alpenglow est conçu pour remplacer.
Ce qu'Alpenglow change
La présentation d'Alpenglow d'Anza indique que la mise à niveau remplace TowerBFT et PoH, en tant que composants centraux du consensus, par Votor. La proposition officielle SIMD-0326 — un Solana Improvement Document relevant du processus formel de changement du réseau — décrit des délais d'attente locaux qui jouent un rôle temporel sans temps synchronisé et qualifie ce changement de non rétrocompatible.
Ces conceptions suppriment les prérequis de réancrage PoH et de choix de fork TowerBFT utilisés par TI et FTI. Les archives publiques ne contiennent aucune analyse d'Anza ou de la Solana Foundation reliant chaque étape de l'attaque au code Alpenglow livré, ni excluant un problème analogue dans la logique de migration.
Selon les chercheurs, l'équipe de développement de Solana a répondu en moins d'un jour après la divulgation de décembre 2025. L'article indique que l'équipe considérait ce comportement comme connu en interne, s'attendait à ce qu'une future mise à niveau du protocole telle qu'Alpenglow y réponde, le surveillait et jugeait les scénarios les plus graves improbables dans les conditions actuelles.
Les auteurs ont également déclaré n'avoir pas déployé de mesures d'atténuation complètes au moment de la publication.
Une présentation de la Solana Foundation sur Agave 4.2 indiquait que le client incluait du code Alpenglow destiné aux clusters de test communautaires mais n'activait pas le nouveau consensus sur le mainnet, l'activation étant attendue dans Agave 4.3.
L'attaque PoH héritée décrite dans l'article semble être tombée en dehors du concours de 50 000 $SOL, et Alpenglow est conçu pour supprimer ses prérequis exacts. En attendant l'activation — attendue dans Agave 4.3 — et une réponse publique au niveau de l'implémentation, la transition demeure le point non résolu de cette histoire.