Community Trust ScoreVérifié
La tentative de Solana de réorganiser l’ordre de ses transactions a rencontré un obstacle. Une proposition de projet visant à permettre aux validateurs de rejeter des blocs mal ordonnés a été close le 25 septembre sans être fusionnée, et le débat qu’elle a déclenché est loin d’être résolu.
La proposition, officiellement appelée SIMD-0649, avait un objectif assez simple sur le papier : obliger les producteurs de blocs à organiser les transactions dans chaque lot par ordre de priorité des frais, du plus élevé au plus bas. Pas une idée radicale. L’ordre de priorité des frais est essentiellement la manière dont la plupart des gens supposent que les blockchains fonctionnent déjà. Mais l’architecture de Solana est suffisamment différente pour que cela nécessite une règle formelle — et apparemment, établir correctement cette règle est plus difficile qu’il n’y paraît.
Comment fonctionnait réellement SIMD-0649
Selon le projet, les producteurs de blocs de Solana — appelés leaders — conserveraient leur pouvoir existant de choisir quelles transactions entrent dans un bloc et comment ces transactions sont regroupées en lots. La règle ne toucherait pas à cela. Ce qu’elle ferait, c’est rendre l’ordre à l’intérieur de chaque lot inspectable et exécutoire. Les transactions devraient apparaître dans un ordre de priorité non croissant, bien que les transactions partageant le même score de priorité puissent se trouver n’importe où dans le lot.
Le score de priorité lui-même est calculé en divisant la récompense au leader par le coût de la transaction. Ce calcul intègre à la fois les frais de priorité et les frais de base non brûlés. Ce n’est donc pas seulement une question de qui a payé le plus en termes bruts — c’est un ratio, pondéré par rapport à ce que la transaction coûte réellement au réseau à traiter.
Et puis il y a la règle de taille de lot. Chaque lot devrait couvrir au moins deux ensembles de correction d’erreur avant — soit un minimum de 64 fragments de données — sauf pour le tout dernier lot d’un bloc. La logique : si vous permettez aux leaders de créer de petits lots, ils peuvent manipuler la vérification de l’ordre en isolant les transactions qu’ils veulent favoriser dans leur propre petit conteneur, où il n’y a rien d’autre pour comparer.
Pourquoi les examinateurs ont repoussé
Les préoccupations qui ont tué la fusion ne sont pas minces. Les examinateurs ont signalé que les leaders pourraient toujours exploiter le processus de clôture des lots pour contourner l’intention de la règle. Fermez un lot au bon moment, et vous avez effectivement séparé les transactions concurrentes sans techniquement enfreindre l’exigence d’ordre. La proposition ne résout pas cela.
Elle ne touche pas non plus aux paiements de frais internes. Un leader pourrait théoriquement favoriser ses propres transactions en se payant des frais à lui-même en interne, et SIMD-0649 ne le détecterait pas. C’est une lacune, et les critiques l’ont remarquée.
La latence a également été évoquée. Imposer une taille minimale de lot signifie que les leaders ne peuvent pas diffuser un bloc tant qu’ils n’ont pas accumulé suffisamment de transactions pour atteindre le seuil de 64 fragments. À faible débit — lorsque le réseau n’est pas occupé — cette attente pourrait retarder significativement la diffusion du bloc. Les validateurs traiteraient les transactions à leur arrivée, puis invalideraient le bloc si une vérification ultérieure de l’ordre échoue. Ce n’est pas un flux propre.
Aucun de ces cas n’est hypothétique. Ce sont des vulnérabilités structurelles dans le projet tel qu’il est écrit.
Ce qui manque aux données
Peut-être le plus gros problème : personne ne sait réellement à quelle fréquence les tailles de lot actuelles échoueraient au minimum proposé. Le projet ne le quantifie pas. Il n’y a pas de données empiriques sur la façon dont les leaders regroupent actuellement les transactions, sur la taille typique de ces lots, ou sur la fréquence à laquelle la vérification de l’ordre entraînerait un rejet dans des conditions réelles du réseau.
Sans cela, toute la proposition est un peu théorique. Vous ne pouvez pas évaluer si la règle change quoi que ce soit en pratique si vous ne savez pas à quoi ressemble actuellement la pratique. Les parties prenantes sont invitées à accepter une règle dont l’effet sur la prévisibilité de l’exécution est, selon l’aveu même du projet, spéculatif.
Cette incertitude est très importante pour les traders et les protocoles construisant sur Solana. Un ordre de transaction prévisible est essentiellement la base d’une exécution équitable — surtout pour tout ce qui implique des transactions sensibles au temps ou de l’arbitrage. Si la règle ne le fournit pas réellement, il n’est pas clair ce qu’elle apporte.
La communauté Solana a encore besoin de l’avis des développeurs de clients spécifiquement. Et elle a besoin de données réelles sur la taille des lots avant que toute version révisée de cette règle puisse être évaluée honnêtement. La clôture de SIMD-0649 n’était pas un rejet de l’idée — c’était un signal que l’idée a besoin de plus de travail, de plus de preuves, et probablement d’une approche différente du problème de la clôture des lots.
Il n’est pas clair si un projet révisé reviendra avec ces corrections. Aucun calendrier n’a été donné lorsque la proposition a été close le 25 septembre.
Hub : Prix, actualités et analyses de Solana
Hub: Solana : prix, actualités et analyse
Questions Fréquentes
Que cherchait à corriger SIMD-0649 sur Solana ?
SIMD-0649 visait à imposer un ordre de priorité des frais au sein des lots de transactions, permettant aux validateurs de rejeter les blocs où les transactions n’étaient pas organisées du score de priorité le plus élevé au plus bas.
Pourquoi SIMD-0649 a-t-il été clos sans fusion ?
La proposition a été close le 25 septembre après que les examinateurs ont soulevé des préoccupations concernant l’exploitation par les leaders des clôtures de lots, les paiements de frais internes non abordés, la latence potentielle à faible débit, et un manque de données empiriques sur les tailles de lots actuelles.
Pourquoi c'est important
L'échec de la proposition SIMD-0649 illustre les défis auxquels Solana est confronté dans sa quête d'amélioration de l'efficacité et de la transparence de son réseau. La capacité à gérer l'ordre des transactions est cruciale dans un environnement où la concurrence entre les blockchains est de plus en plus féroce, et ce rejet pourrait soulever des questions sur la gouvernance au sein de l'écosystème Solana. Ce débat sur la priorisation des frais reflète également les tensions entre l'innovation technique et les réalités opérationnelles des validateurs, mettant en lumière les dilemmes auxquels sont confrontées de nombreuses plateformes de blockchain.
