Solana se rapproche des slots de 200 ms après sa dernière mise à niveau de vitesse

Selon les données de la blockchain, le nouveau paramètre est entré en vigueur le 18 septembre et porte Solana à quatre slots ciblés par seconde, contre environ 3,3 avec la configuration précédente de 300 ms. Ce changement constitue la troisième étape de la SIMD-0525, conçue pour réduire progressivement la durée des slots, du paramètre initial de 400 ms du réseau jusqu'à une cible finale de 200 ms.

Un slot est la période pendant laquelle un validateur désigné peut produire un bloc. Raccourcir cette période permet aux portefeuilles, aux plateformes d'échange et aux applications de trading de recevoir des mises à jour plus fréquentes sur l'état du réseau.

Les validateurs continuent d'agir en tant que leaders pendant quatre slots consécutifs. Chaque slot étant désormais ciblé à 250 ms, la fenêtre nominale de leadership d'un validateur est passée de 1,2 seconde avec le paramètre précédent à une seconde.

La durée des slots de Solana atteint 250 ms

Solana a entamé le déploiement actuel en août, en réduisant pour la première fois depuis le lancement du réseau la durée de ses slots de 400 ms à 350 ms, comme l'avait précédemment rapporté crypto.news.

La SIMD-0525 a divisé le processus en quatre étapes à 350 ms, 300 ms, 250 ms et 200 ms, au lieu de passer directement à la cible finale. Chaque réduction nécessite une activation de fonctionnalité distincte, ce qui permet aux développeurs et aux opérateurs de validateurs d'évaluer les performances du réseau avant de poursuivre.

À 250 ms, quatre opportunités de slots se présentent chaque seconde. Ces intervalles plus courts peuvent offrir aux applications une vision plus actuelle des transactions et de l'état du réseau, tout en transférant plus rapidement la production de blocs d'un validateur à l'autre.

Les marchés basés sur des oracles et les teneurs de marché automatisés figurent parmi les applications couvertes par la proposition, car leur fonctionnement peut dépendre de l'ancienneté des données on-chain. Un intervalle plus court réduit le temps entre les mises à jour du réseau, tandis que les utilisateurs peuvent voir plus tôt les changements d'état des transactions.

Pour les échanges (swaps), ce délai plus court peut réduire la période entre la soumission d'une transaction et son arrivée sur le réseau. La proposition sous-jacente identifie des confirmations plus rapides et des mises à jour plus fréquentes comme des avantages de la réduction de la durée des slots.

Ce changement n'augmente pas la capacité brute de transactions de Solana de près de 17 %.

Dans le cadre de la SIMD-0525, les limites de ressources sont réduites proportionnellement à la durée des slots. Davantage de slots sont produits sur une période donnée, mais chaque slot est autorisé à transporter moins de calcul et de données, ce qui maintient la quantité de travail que le réseau peut traiter en temps réel à peu près au même niveau.

Au niveau de référence de 60 millions d'unités de calcul utilisé par la proposition, la limite par slot diminue à mesure que l'horloge s'accélère. La configuration à 250 ms correspond à une limite de 37,5 millions d'unités de calcul, tandis que l'étape prévue à 200 ms la réduirait à 30 millions.

Des blocs plus rapides modifient les exigences d'infrastructure de Solana

Les fournisseurs d'infrastructure ont désormais davantage de blocs individuels à traiter et à stocker, même si le plafond de traitement en temps réel reste globalement inchangé.

Les applications qui calculent le temps écoulé en multipliant les numéros de slots par une durée fixe devront peut-être tenir compte de cette horloge plus rapide. Les blockhashes expirent plus tôt en temps réel à mesure que les slots avancent plus vite, laissant moins de temps pour les processus de transaction impliquant une signature hors ligne ou des approbations humaines différées.

Le calendrier des époques change pour la même raison. Solana maintient chaque époque fixée à 432 000 slots, ce qui signifie qu'une époque devient plus courte à mesure que la durée de chaque slot diminue.

Avec la cible précédente de 300 ms, une époque durait environ 36 heures. Le paramètre de 250 ms ramène la durée prévue à environ 30 heures. Un passage à la cible finale de 200 ms la réduirait à environ 24 heures.

Les réductions progressives des slots de Solana font partie du déploiement d'Agave 4.2. La version du client a commencé à activer plusieurs changements de réseau en août, notamment une baisse du loyer de stockage on-chain, des transactions plus volumineuses et la voie vers des slots de 200 ms.

La conception par étapes comprend une protection liée aux taux de blocs sautés. La progression vers le paramètre de slot suivant peut être interrompue si les taux de saut dépassent le niveau jugé acceptable par les développeurs, ce qui laisse aux validateurs le temps de fonctionner sous chaque configuration avant qu'une autre réduction ne soit activée.

Aucune date de mise en service sur le réseau principal n'a été fixée pour l'étape à 200 ms.

Les mises à niveau de Solana vont au-delà des slots plus rapides

Le calendrier des slots n'est qu'une partie des changements de réseau déployés via Agave.

Solana a par ailleurs introduit la Transaction V1, qui fait passer la taille maximale des transactions sérialisées de 1 232 octets à 4 096 octets. Ce format de transaction plus volumineux peut accueillir des opérations gourmandes en données telles que les preuves à divulgation nulle de connaissance et les instructions multisignatures complexes au sein d'une seule transaction.

La Transaction V1 est facultative, tandis que les transactions héritées et de version zéro restent prises en charge. Les applications qui lisent les blocs doivent prendre en charge le nouveau format pour traiter correctement les transactions V1.

L'augmentation de la taille des transactions est distincte de la SIMD-0525. Des transactions individuelles plus volumineuses ne déterminent donc pas l'horloge des slots, et des slots plus courts n'augmentent pas automatiquement la taille maximale d'une transaction.

Solana a activé ces changements de manière indépendante via des portes de fonctionnalités (feature gates). Cette structure permet à une mise à niveau de se poursuivre sans exiger que les autres fonctionnalités incluses dans Agave 4.2 s'activent en même temps.

Solana vise toujours des slots de 200 ms

La dernière étape de la SIMD-0525 réduirait la durée cible des slots de 250 ms à 200 ms, portant le réseau à cinq slots ciblés par seconde.

Une fenêtre de leadership de quatre slots pour un validateur tomberait par conséquent à environ 800 ms. La durée des époques passerait d'environ 30 heures avec le paramètre actuel de 250 ms à environ 24 heures.

Les développeurs de Solana n'ont pas fourni de date d'activation sur le réseau principal pour la réduction finale. La progression dépend du comportement du réseau sous le paramètre actuel, notamment de la capacité des validateurs à maintenir des taux de blocs sautés acceptables.

Les réductions de slots sont distinctes d'Alpenglow, la refonte du consensus prévue par Solana. Alpenglow est destiné à remplacer TowerBFT par un système de vote appelé Votor et à supprimer les transactions de vote on-chain du processus de consensus central du réseau.

La mise à niveau du consensus Alpenglow vise une finalité d'environ 150 ms. Son code a été inclus pour les tests, tandis que le déploiement sur le réseau principal a été lié à Agave 4.3 plutôt qu'aux portes de fonctionnalités de slots utilisées pour la SIMD-0525.

Alpenglow est entré en phase de test communautaire par les validateurs plus tôt en 2026, permettant aux opérateurs d'exécuter la conception du consensus sur un cluster de test avant son déploiement sur le réseau principal. Anza a décrit ce système comme le plus grand changement de consensus de l'histoire de Solana.

Pour la SIMD-0525, le réseau reste à l'étape de 250 ms jusqu'à ce que les développeurs activent la dernière porte de fonctionnalité. La configuration à 200 ms achèverait un déploiement qui a commencé à 400 ms et est passé par 350 ms, 300 ms et 250 ms, tout en réduisant les limites de ressources à chaque étape.