Les développeurs de Solana proposent une refonte majeure pour traiter un risque caché pouvant perturber son réseau

Les développeurs de Solana envisagent un nouveau livre de règles de protocole conçu pour rendre les logiciels de validation développés indépendamment plus fiables et plus faciles à maintenir.

La proposition, publiée le 30 octobre, vient de Brennan Watt, PDG d'Anza, l'entreprise d'ingénierie blockchain derrière 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 autoritaire définissant comment sa blockchain traite les transactions, valide les blocs et atteint un consensus, plutôt que de s'appuyer sur des règles éparpillées dans les logiciels existants et des 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 validation d'origine 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écutant ces ordinateurs, chaque mise en œuvre doit suivre les mêmes règles sous-jacentes pour maintenir l'accord à travers le réseau.

Des désaccords sur 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 soutient que le processus de développement existant de Solana rend inutilement difficile pour les équipes indépendantes de déterminer exactement comment le réseau est censé se comporter.

Sous le système actuel, les changements de protocole sont proposés par le biais de documents d'amélioration de Solana, connus sous le nom de SIMDs. Ces documents décrivent des mises à niveau individuelles, mais les règles complètes de fonctionnement du réseau ne sont pas consolidées en une seule référence autoritaire.

En conséquence, les développeurs doivent parfois examiner le code des validateurs existants ou reconstruire des 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 à niveau proposée.

Un nouveau livre de règles pourrait remodeler le processus de mise à niveau de Solana

Selon la proposition, les développeurs continueraient à discuter des mises à niveau potentielles par le biais du processus SIMD existant, mais les changements techniques formels seraient soumis 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 d'autres fonctions pertinentes.

Les changements subiraient un examen technique et toute approbation de gouvernance requise avant de devenir partie intégrante de la spécification officielle lorsqu'ils seraient activés sur le Mainnet de Solana.

Cela permettrait aux équipes développant Agave, Firedancer et les futurs logiciels de validation de travailler à partir des mêmes exigences documentées plutôt que de s'appuyer sur le code d'une autre mise en œuvre comme référence principale.

Où commence et se termine le livre de règles provisoire de Solana

La conformité avancée commence à partir d'un état de confiance et reste dans l'époque de référence 1072.
ENTRÉE DE CONFIANCE ÉPOQUE DE RÉFÉRENCE 1072 État de confiance Instantané, ou état authentifié à la conformité avancée Appliquer les règles spécifiées dans E Première banque de E+1 En dehors de cette version Les règles précédemment retirées n'ont pas besoin d'être rejouées. Limite de portée schématique ; l'espacement ne représente pas le temps. racine de l'époque-E
ÉPOQUE DE RÉFÉRENCE PROVISOIRE 1072 Entrée de confiance État de confiance Instantané, ou état authentifié à la conformité avancée Appliquer les règles spécifiées Dans E seulement Première banque de E+1 En dehors de cette version Les règles précédemment retirées n'ont pas besoin d'être rejouées. Schématique ; l'espacement ne représente pas le temps. vers la racine de l'époque-E

Où le client commence-t-il ?

Où le client commence-t-il ? Dernière banque avant E Déjà dans E
La construction de la banque enfant applique la transition de frontière d'époque-E une fois avant ses transactions.
DERNIÈRE BANQUE AVANT E État de confiance Appliquer une fois Transition de frontière d'époque DANS E Transactions Avant les transactions de la banque enfant
Dernière banque avant E Appliquer une fois Transition de frontière d'époque Transactions dans E La transition précède ces transactions
L'état de confiance inclut déjà la transition de frontière d'époque, donc elle ne doit pas être appliquée à nouveau.
DANS E DANS E État de confiance Transactions La transition de frontière est déjà incluse dans l'état de départ
Déjà dans E État de confiance La transition de frontière est déjà incluse dans l'état de départ Transactions dans E Continuer sans répéter la transition.

Un livre de règles commun rend l'objectif explicite. La confiance de l'état de départ et la prochaine époque restent des exigences distinctes.

Ceci est une spécification préliminaire, pas un changement de protocole adopté. Elle n'établit pas la correction de l'état de départ, la relecture historique ou l'opération continue dans E+1. Aucun gain de fiabilité client n'est quantifié.
Sources et preuves

Sources

1. Portée et conformité
2. Époque de référence préliminaire

Faits soutenants

• La page d'atterrissage préliminaire identifie son époque de référence Mainnet comme E=1072 ; la portée commence une mise en œuvre à partir d'un instantané de confiance pour cette époque ou d'un autre état authentifié à une racine d'époque-1072. [2] [1]
• Le projet exige une conformité vers l'avant dans son époque de référence et ne nécessite pas de reproduire des encodages ou des branches de règles qui ont cessé d'être acceptées avant cette époque. [1]
• Le projet s'applique uniquement aux banques dans l'époque de référence E et ne définit explicitement pas la première banque de E+1, donc la conformité à cette version seule n'établit pas une opération continue à travers cette frontière. [1]
• Selon le projet, une mise en œuvre commençant à la dernière banque avant E applique la transition de frontière d'époque une fois ; un état de départ déjà à l'intérieur de E ne doit pas l'appliquer à nouveau. [1]
• La conformité vers l'avant laisse l'instantané de départ ou la racine authentifiée comme une entrée de confiance : le projet commence après que cette entrée a été acceptée plutôt que d'exiger qu'un nouveau client prouve toute la chaîne antérieure par relecture. [1]

Méthode

Schématique basée sur la page d'atterrissage préliminaire et le chapitre de portée capturé le 4 novembre 2026. Deux états d'initialisation sélectionnables reproduisent la règle de frontière du projet ; la géométrie est qualitative, sans échelle de durée ou de performance.

Portée

Ceci est une spécification préliminaire, pas un changement de protocole adopté. Elle n'établit pas la correction de l'état de départ, la relecture historique ou l'opération continue dans E+1. Aucun gain de fiabilité client n'est quantifié.
Infographie par CryptoSlate

Cela pourrait également rendre les tests logiciels plus efficaces. Lorsque des validateurs indépendants produisent des résultats différents, les développeurs auraient une norme commune contre laquelle examiner le désaccord et identifier quelle mise en œuvre nécessite une correction.

Watt a déjà publié une spécification préliminaire couvrant 18 domaines des opérations de Solana, y compris 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'histoire de la blockchain de Solana et suppose que les développeurs commencent à partir d'un état de réseau déjà de confiance. Des travaux supplémentaires seraient nécessaires pour couvrir les mises à jour ultérieures et établir que les mises en œuvre restent compatibles dans le temps.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.