Solana développeurs envisagent un nouveau carnet de règles de protocole conçu pour rendre les logiciels de validateur développés indépendamment plus fiables et plus faciles à maintenir.
La proposition, publiée le 30 octobre, provient de Brennan Watt, PDG de Anza, l'entreprise d'ingénierie blockchain à l'origine d'Agave, l'un des principaux programmes logiciels utilisés pour faire fonctionner le réseau Solana.
Watt souhaite que Solana établisse une spécification unique et officielle définissant comment sa blockchain traite les transactions, valide les blocs et atteint le consensus, plutôt que de s'appuyer sur des règles dispersées dans les logiciels existants et les propositions techniques séparées.
Le changement pourrait répondre à un défi croissant alors que Solana s'étend au-delà de son logiciel de validateur original pour inclure des alternatives développées indépendamment, telles que Firedancer, construit par la société de trading Jump Crypto.
Les validateurs sont des ordinateurs qui vérifient les transactions et aident à sécuriser la blockchain. Bien que différents développeurs puissent créer le logiciel exécuté sur ces ordinateurs, chaque implémentation doit respecter les mêmes règles sous-jacentes pour maintenir l'accord au sein du réseau.
Les désaccords concernant ces règles pourraient amener les validateurs à traiter des transactions identiques de manière différente, créant potentiellement des vues conflictuelles de la blockchain et menaçant la fiabilité du réseau.
Watt affirme que le processus de développement actuel de Solana rend excessivement difficile pour les équipes indépendantes de déterminer exactement comment le réseau est censé fonctionner.
Dans le système actuel, les modifications du protocole sont proposées via Solana Improvement Documents, connus sous le nom de SIMDs. Ces documents décrivent des mises à jour individuelles, mais les règles complètes de fonctionnement du réseau ne sont pas regroupées dans une référence unique et officielle.
Par conséquent, les développeurs doivent parfois examiner le code des validateurs existants ou reconstituer les décisions de mise à niveau précédentes pour comprendre quelles règles sont actives.
Watt a déclaré que cette approche peut produire des descriptions répétées ou incohérentes du comportement existant tout en rendant plus difficile l'identification de chaque partie du protocole affectée par une mise à jour proposée.
Un nouveau règlement pourrait redéfinir le processus de mise à jour de Solana
Selon la proposition, les développeurs continueraient à discuter des améliorations potentielles via le processus SIMD existant, mais les modifications techniques formelles seraient soumises sous forme de modifications à une spécification de protocole partagée.
Chaque amendement décrirait précisément comment la mise à niveau affecte les transactions, les communications réseau, le consensus et autres fonctions pertinentes.
Les modifications seraient soumises à un examen technique et à toutes les approbations de gouvernance requises avant de faire partie de la spécification officielle lors de leur activation sur le mainnet de Solana.
Cela permettrait aux équipes développant Agave, Firedancer et les futurs logiciels de validateur de travailler à partir des mêmes exigences documentées plutôt que de s'appuyer sur le code d'une autre implémentation comme référence principale.
Où le client commence-t-il ?
La construction child-bank applique la transition de limite d'époque-E une fois avant ses transactions.
Un cahier des charges commun rend la cible explicite. La confiance d'état initial et le prochain époque restent des exigences distinctes.
Il s'agit d'une spécification provisoire, non une modification de protocole adoptée. Elle ne garantit pas la correction de l'état initial, la relecture historique ni le fonctionnement continu vers E+1. Aucun gain de fiabilité client n'est quantifié.
Cela pourrait également rendre les tests logiciels plus efficaces. Lorsque des validateurs indépendants produisent des résultats différents, les développeurs disposeraient d'une norme commune pour examiner le désaccord et identifier quelle implémentation nécessite une correction.
Watt a déjà publié une spécification provisoire couvrant 18 domaines des opérations de Solana, notamment le traitement des transactions, les communications réseau, le consensus, les frais et les récompenses des validateurs.
Cependant, le projet reste limité à une période définie de l'historique de la blockchain de Solana et suppose que les développeurs commencent à partir d'un état de réseau déjà fiable. Des travaux supplémentaires seraient nécessaires pour couvrir les mises à jour ultérieures et garantir que les implémentations restent compatibles dans le temps.