Solana Pourrait Recevoir Un Boost Turbo Alors Que Firedancer Cible Les Restrictions De Bloc

L'élan de performance de Solana a gagné un nouvel élan cette semaine alors que les ingénieurs derrière Firedancer, le client validateur alternatif haute performance dirigé par Jump, ont déposé un nouveau document d'amélioration Solana (SIMD-0370) pour supprimer la limite d'unité de calcul (CU) au niveau des blocs du réseau - un changement qu'ils considèrent comme redondant après Alpenglow et qui se traduirait immédiatement par un débit plus élevé et une latence plus faible lors des pics de demande.

Prochain Turbo Boost Pour Solana

La pull request, rédigée par l'équipe "Firedancer" et ouverte le 24 septembre 2025, est explicitement présentée comme une proposition "post-Alpenglow". Dans Alpenglow, les nœuds votants diffusent un SkipVote s'ils ne peuvent pas exécuter un bloc proposé dans le temps imparti. Comme les blocs lents sont automatiquement ignorés, les auteurs soutiennent qu'un plafond CU distinct imposé par protocole par bloc est inutile.

"Dans Alpenglow, les nœuds votants diffusent un SkipVote s'ils ne parviennent pas à exécuter un bloc à temps... Ce SIMD supprime donc l'application de la limite d'unité de calcul des blocs", indique le document, décrivant la limite comme superflue selon les règles de planification améliorées.

Au-delà de la propreté technique, les auteurs proposent un alignement économique plus précis. Le plafond CU actuel au niveau des blocs, selon eux, brise les incitations en plafonnant la capacité via le protocole plutôt que par des améliorations matérielles et logicielles. Sa suppression permettrait aux producteurs de remplir les blocs jusqu'à ce que leurs machines puissent traiter et propager en toute sécurité, poussant la concurrence des clients et du matériel au premier plan.

"La capacité du réseau est déterminée non pas par les capacités du matériel mais par la limite arbitraire d'unité de calcul des blocs", écrivent-ils, avant d'expliquer pourquoi lever ce couvercle réalignerait les incitations tant pour les clients validateurs que pour les développeurs de programmes.

Les premiers commentaires de révision de code des contributeurs principaux et des équipes clientes soulignent à la fois l'impact utilisateur à court terme et les limites du changement. Un réviseur a résumé l'avantage pratique : "Supprimer la limite aujourd'hui présente des avantages tangibles pour l'écosystème et les utilisateurs finaux... sans attendre que l'architecture future du réseau soit élaborée." Un autre a souligné que certaines contraintes de bloc resteraient, citant une "limite maximale de fragments", tandis que d'autres ont suggéré que le réseau devrait probablement conserver les limites CU par transaction pour l'instant et traiter tout changement à ce niveau comme une discussion distincte et plus étendue.

Les considérations de sécurité et de vivacité sont mises en avant. Les réviseurs ont demandé que la proposition explique explicitement pourquoi la sécurité est préservée même si un bloc est trop lourd pour se propager à temps ; la réponse d'Alpenglow est que ces blocs ne sont simplement pas votés, c'est-à-dire qu'ils sont ignorés - maintenant la progression sans pénaliser le réseau. Les auteurs de Firedancer conviennent que le garde-fou décisif est l'horloge et le budget de propagation, et non un plafond CU statique.

La proposition aborde également une préoccupation fréquente dans les débats sur le débit : la coordination. Si un producteur de blocs améliore son matériel de manière agressive tandis que d'autres sont à la traîne, le réseau risque-t-il de souffrir de blocs ignorés ? Un réviseur note que les producteurs trop ambitieux s'auto-calibrent déjà car les blocs manqués signifient des récompenses manquées, limitant naturellement la taille des blocs à ce que les pairs peuvent accepter à temps. Le document soutient en outre que, sans la limite CU, les forces du marché régissent la capacité : les producteurs et les équipes clientes qui optimisent l'exécution, le réseau et la planification gagneront plus de blocs et de frais, repoussant la frontière vers l'extérieur selon la demande.

Crucialement, SIMD-0370 est compatible avec le futur. Les conceptions en cours pour plusieurs proposants concurrents - un élément de feuille de route à long terme pour Solana - supposent parfois une limite de bloc et parfois non. Les réviseurs soulignent que la suppression de la limite actuelle n'empêche pas les architectures de proposants concurrents ultérieurement ; cela débloque simplement des améliorations qui "peuvent être réalisées aujourd'hui".

Alors que la discussion GitHub fournit la substance technique, Anza - l'équipe cliente Solana derrière Agave - a également amplifié la proposition sur les canaux sociaux, signalant une large attention des équipes clientes au changement et à ses implications pour les utilisateurs.

Qu'est-ce qui changerait pour les utilisateurs et les développeurs si SIMD-0370 était déployé ? En périodes de pointe - airdrops, mints, volatilité du marché - les blocs pourraient supporter plus de calcul tant qu'ils peuvent être exécutés et propagés dans le temps imparti, augmentant potentiellement le débit soutenu et lissant les pics de frais.

Pour les développeurs Solana, une marge de manœuvre plus élevée et des incitations plus fortes pour l'optimisation client/matériel pourraient réduire la latence pour les charges de travail exigeantes, bien qu'avec la nécessité continue d'optimiser les programmes pour le parallélisme et la localité. Pour les validateurs, l'avantage concurrentiel pencherait encore plus vers l'efficacité d'exécution, la performance réseau et les politiques intelligentes de construction de blocs qui équilibrent les revenus de frais contre le risque de produire un bloc si lourd qu'il est ignoré.

Comme pour tous les SIMD, le changement est soumis à l'examen de la communauté, à la mise en œuvre et à la coordination du déploiement entre les clients validateurs. Mais la direction est claire. Post-Alpenglow, les concepteurs de Solana croient que le budget de temps de slot est le véritable limiteur.

Au moment de la publication, Solana se négociait à 205,38 $.