Les efforts de Solana pour moderniser la vérification des signatures de transactions ont rencontré un obstacle inattendu, et il provient d'une source inhabituelle : un agent de recherche en IA autonome opérant sous le pseudonyme @hackhackai sur la blockchain Solana. L'agent a identifié une vulnérabilité potentielle dans le SIMD-0376, la proposition conçue pour réformer la manière dont le réseau gère la vérification des signatures de transactions.

Selon les conclusions de l'agent, la faille—si elle n'est pas corrigée—pourrait permettre la signature à l'adresse zéro, un scénario qui devrait être impossible selon les règles actuelles, mettant 433 comptes de métadonnées en risque.

Ce que propose le SIMD-0376

Solana vérifie actuellement les signatures Ed25519 à l'aide de la bibliothèque ed25519-dalek. Le SIMD-0376 la remplacerait par le standard de vérification EdDSA cofactorisé ZIP-215, une implémentation différente de la même courbe cryptographique sous-jacente—un standard né à l'origine comme proposition d'amélioration de Zcash.

La vérification des signatures s'exécute sur chaque transaction traitée par le réseau, c'est pourquoi les gains d'efficacité à ce niveau se cumulent sur tout le débit de Solana. L'avantage pratique du changement est tangible : la proposition vise à permettre le traitement par lots des signatures, ce qui pourrait réduire les coûts de calcul des validateurs d'environ 40 % lors du traitement de grands volumes de signatures.

David Rubin de Syndica a introduit la proposition le 6 octobre 2025. Après des refinements ultérieurs, elle a été fusionnée dans le dépôt des Solana Improvement Documents le 28 janvier 2026.

Le problème de l'adresse zéro

La vulnérabilité porte sur un cas limite spécifique introduit par le standard ZIP-215 : la possibilité de signer avec, ou pour, l'adresse zéro. Selon les règles Ed25519 normales, une telle signature serait rejetée catégoriquement. Avec la logique de vérification plus permissive du ZIP-215, elle pourrait ne pas l'être.

L'adresse zéro n'est pas un cas limite ordinaire. Elle fonctionne comme une identité nulle—une adresse composée uniquement de zéros pour laquelle aucune clé privée n'existe en pratique—c'est pourquoi les règles actuelles considèrent toute signature la concernant comme invalide en soi, et pourquoi une signature vérifiable à l'adresse zéro remettrait en cause une hypothèse fondamentale des systèmes basés sur des comptes comme celui de Solana.

Cette permissivité est intentionnelle. Le ZIP-215 a été conçu pour accepter un éventail plus large de représentations de signatures valides, ce qui rend le traitement par lots plus simple. La contrepartie est qu'il assouplit également certaines vérifications aux limites qui servaient auparavant de garde-fous de sécurité implicites.

Le résultat, selon les conclusions de @hackhack, est que 433 comptes de métadonnées liés à l'écosystème Solana pourraient être exposés à des opérations de signature qui ne devraient jamais être possibles. Hackhackai se décrit comme un agent de recherche axé sur l'IA, conçu spécifiquement pour isoler les vulnérabilités dans les protocoles Solana.

Pourquoi le timing compte

La proposition a été introduite en octobre 2025 et fusionnée en janvier 2026, pourtant la vulnérabilité de l'adresse zéro a été révélée sans couverture significative par les médias crypto grand public dans les mois qui ont suivi. Ce décalage illustre aussi la manière dont la recherche sur les protocoles se déroule désormais : un agent autonome opérant on-chain peut mettre en évidence un problème au niveau d'une proposition bien avant la couverture médiatique ou les réponses officielles.

Les comptes de métadonnées signalés dans les conclusions ne sont pas des portefeuilles d'utilisateurs ordinaires. Dans l'architecture de Solana, les comptes de métadonnées stockent généralement des données au niveau des programmes, des configurations de tokens ou des attributs de NFT. Dans le pire des cas, une anomalie de signature affectant ces comptes pourrait permettre des modifications non autorisées de l'état des programmes ou des enregistrements de propriété d'actifs, selon la manière dont chaque programme gère les instructions signées entrantes.

Pour les développeurs construisant sur Solana—en particulier ceux dont les programmes interagissent avec les comptes de métadonnées—la question pratique est de savoir si leur logique de validation des instructions suppose le comportement de rejet actuel d'Ed25519 ou vérifie explicitement les entrées à l'adresse zéro. Les programmes écrits avant la proposition du SIMD-0376 n'auraient aucune raison d'inclure cette dernière vérification, puisqu'elle n'a jamais été nécessaire.

Au moment de la rédaction, les auteurs de la proposition et la Solana Foundation n'avaient pas commenté publiquement la faille. Toute révision du texte du SIMD, une réponse formelle de ses auteurs ou des ingénieurs principaux de Solana, ou de nouvelles recommandations pour les programmes interagissant avec les comptes de métadonnées constitueraient les prochains signes concrets de la résolution de cet arbitrage entre efficacité du traitement par lots et vérification stricte.