Solana propose de réduire les limites de calcul par bloc afin que son passage à des slots de 350 ms ne surcharge pas les validateurs ni ne compromette la stabilité du réseau.
Faites de nous votre source préférée sur
gsoitsoitgjeet
La vitesse plus élevée de Solana a une contrepartie technique : pour que son saut à des blocs de 350 millisecondes ne surcharge pas le réseau, les développeurs proposent de réduire les limites de calcul par bloc. Un projet de proposition vise à ajuster ces plafonds à mesure que les intervalles entre les blocs se raccourcissent, sans relever le plafond théorique des unités de calcul par seconde.
Ce changement fait partie des efforts continus du réseau pour réduire ses délais de confirmation. Chaque bloc – ou fentedans la terminologie de Solana, traite les transactions dans le cadre d'un budget d'« unités de calcul » (UC), la mesure qui mesure la quantité de travail que la chaîne peut exécuter dans chaque intervalle. Si les créneaux deviennent plus courts mais conservent le même budget, le système risque de se resserrer aux moments critiques de coordination entre validateurs.
Pourquoi la vitesse de Solana oblige à réduire le nombre de blocs
La logique du projet est simple : en raccourcissant la durée de chaque créneau, vous réduisez proportionnellement la quantité de calcul qui y est contenue. La proposition, identifiée sous le nom SIMD-0525, vise à réduire les limites par emplacement à mesure qu'elles deviennent plus courtes. L’essentiel est que le plafond théorique de CU par seconde n’augmente pas : ce qui change, c’est la façon dont ce budget est réparti dans le temps.
La raison est liée à deux goulots d’étranglement pratiques. Les premiers sont les transferts de dirigeantsle moment où un validateur donne le tour à un autre de proposer des blocs. Avec des créneaux plus courts, ce transfert se produit plus fréquemment et laisse moins de marge de manœuvre. La seconde est la synchronisation hors chaîne (timing hors chaîne) : Les nœuds ont besoin de temps pour propager les données, les vérifier et les accepter, et ce processus n'est pas accéléré simplement parce que le bloc dure moins longtemps.
En d'autres termes, augmenter la vitesse de Solana sans recalibrer le nombre de blocs pourrait déplacer la pression sur l'infrastructure des validateurs, juste au moment où le réseau est le plus vulnérable au blocage.
Le contexte : la course de Solana aux blocs plus rapides
Solana ajuste les paramètres depuis des mois pour réduire ses temps de blocage, un objectif qui apparaît de manière récurrente dans ses mises à jour de développement. Le réseau a construit une grande partie de sa proposition de valeur sur la rapidité et le faible coût des transactions, ce qui en fait un terrain fertile pour les applications de trading, de paiement et de memecoin qui reposent sur un règlement quasi instantané.
Réduire la durée du créneau à 350 ms est un autre pas dans cette direction, mais cela expose également les tensions liées à la mise à l'échelle d'une blockchain sans compromettre sa stabilité. L'histoire récente de Solana comprend des épisodes de congestion et de pannes de réseau, de sorte que toute augmentation de vitesse s'accompagne d'un examen minutieux de ses performances sous charge réelle.
La réforme est liée à d'autres éléments de la refonte de son consensus, notamment les travaux regroupés sous l'initiative Alpenglow, qui cherche à repenser la manière dont les validateurs parviennent à un accord. Dans l’ensemble, le message des développeurs est que la vitesse ne peut être recherchée de manière isolée : chaque milliseconde coupée oblige à revoir les budgets de calcul, la propagation des données et les transferts entre nœuds.
Ce que cela signifie pour les utilisateurs et les validateurs
Pour l'utilisateur final, le résultat souhaité est un réseau qui confirme les transactions plus rapidement et sans échecs visibles. Un intervalle de 350 ms signifie des confirmations nettement plus rapides, particulièrement utiles dans les applications sensibles au facteur temps. Le compromis est que chaque bloc individuel prendra en charge moins de calcul, ce qui obligera les applications à optimiser la consommation des ressources.
Pour les validateurs, l’ajustement a des implications opérationnelles. Des emplacements plus courts et des relais plus fréquents augmentent les exigences en matière de matériel et de connectivité. En maintenant fixe le plafond de CU par seconde, la proposition tente d'empêcher la charge totale de monter en flèche, mais concentre la pression sur la coordination entre les nœuds, où les marges d'erreur sont étroites.
La discussion est encore en phase de projet et devra passer par les tests habituels sur les réseaux de test avant tout déploiement en production. Les changements de ce type sont d'abord validés dans des environnements tels que testnet et devnet, où les équipes observent la réaction du réseau avant de le valider dans la chaîne principale.
Cette décision résume le dilemme sous-jacent de toute blockchain haute performance : la vitesse n’est pas gratuite. Chaque amélioration des délais de confirmation soulève des questions sur l’allocation des ressources, la stabilité et le coût pour ceux qui assurent le fonctionnement du réseau. Solana parie qu'il peut gagner en vitesse sans sacrifier la fiabilité, et réduire les limites de calcul par bloc est l'élément qui vise à maintenir cet équilibre.
Voir l’article original en espagnol
