Une règle commune pour plusieurs logiciels validateurs
Solana ne repose plus sur une seule implémentation logicielle. Agave, développé par Anza, et Firedancer, porté par Jump Crypto, doivent interpréter exactement les mêmes règles pour parvenir au même résultat sur chaque transaction et chaque bloc. Une divergence pourrait fragmenter temporairement la vision de la chaîne.
Brennan Watt propose donc de créer une spécification normative unique du protocole. Elle couvrirait les transactions, le runtime, le consensus, le réseau, les frais, le format du registre et les récompenses des validateurs.
Les limites du système actuel
Les changements de Solana sont aujourd’hui décrits dans des SIMDs séparés. Ces documents expliquent chaque évolution, mais ne forment pas toujours une description complète et consolidée du protocole actif. Les développeurs doivent parfois consulter le code des clients, l’historique des feature gates et plusieurs propositions pour reconstruire le comportement attendu.
Cette dispersion peut produire des définitions répétées ou légèrement différentes. Elle complique aussi l’examen des évolutions touchant plusieurs domaines en même temps, par exemple la validation des transactions, les frais et l’exécution des programmes.
Comment le nouveau processus fonctionnerait
L’idée et la motivation continueraient à être discutées dans une conversation SIMD. Une fois le changement suffisamment défini, son contenu technique prendrait la forme d’une modification du référentiel commun. La proposition ne serait fusionnée dans la spécification principale qu’au moment de son activation sur le réseau principal.
Le numéro SIMD resterait disponible pour suivre l’historique, les alternatives et les décisions. Les validations des contributeurs, les examens techniques et les votes de gouvernance éventuellement nécessaires ne disparaîtraient pas.
| Élément | Situation | Lecture |
|---|---|---|
| Proposition | Spécification normative unique | En discussion |
| Clients concernés | Agave, Firedancer et futurs clients | Même comportement attendu |
| SIMDs | Maintenus pour la discussion et l’identifiant | Le détail normatif passerait dans le référentiel |
| Activation réseau | Aucune à ce stade | Changement de processus, pas de consensus immédiat |
Pourquoi la diversité des clients reste importante
Plusieurs implémentations indépendantes peuvent réduire le risque qu’un bug unique arrête l’ensemble du réseau. Cette résilience n’existe toutefois que si les clients suivent les mêmes règles. Une spécification claire aide à tester chaque logiciel et à déterminer lequel se trompe lorsque les résultats divergent.
Les limites encore ouvertes
Le premier brouillon couvre un état déterminé du réseau et part d’un snapshot de confiance. Il ne prouve pas encore qu’une implémentation peut rejouer toute l’histoire ni rester conforme à travers chaque changement d’époque. Le bénéfice dépendra aussi de la qualité des tests, de la précision du référentiel et de sa mise à jour au même rythme que le réseau.
