Solana a réduit son temps de slot cible de 300 millisecondes à 250 millisecondes, augmentant le rythme auquel le réseau produit des slots de près de 17 % sans augmenter son plafond de traitement global du même montant.
Résumé
- Solana a réduit son temps de slot cible de 300 ms à 250 ms, portant le réseau à quatre slots ciblés par seconde.
- L'horloge plus rapide réduit la fenêtre de quatre slots de chaque validateur leader de 1,2 seconde à une seconde.
- La capacité de traitement globale reste à peu près inchangée car les limites de calcul et de données diminuent à mesure que la durée des slots diminue.
- Le réglage à 250 ms raccourcit une époque Solana attendue d'environ 36 heures à 30 heures.
- Une réduction finale à 200 ms porterait Solana à cinq slots par seconde, mais aucune date de mainnet n'a été fixée.
Selon les données de la blockchain, le nouveau réglage 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 à 300 ms. Ce changement est la troisième étape de SIMD-0525, qui est conçue pour réduire progressivement les temps de slot depuis le réglage original 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 donne aux portefeuilles, aux exchanges et aux applications de trading des mises à jour plus fréquentes sur l'état du réseau.
Les validateurs continuent de servir en tant que leaders pour quatre slots consécutifs. Avec chaque slot désormais ciblé à 250 ms, la fenêtre de leadership nominale d'un validateur est passée de 1,2 seconde au réglage précédent à une seconde.
Le temps de slot de Solana atteint 250 ms
Solana a commencé le déploiement actuel en août lorsqu'il a réduit son temps de slot de 400 ms à 350 ms pour la première fois depuis le lancement du réseau, comme l'a précédemment rapporté crypto.news.
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, permettant aux développeurs et aux opérateurs de validateurs d'évaluer les performances du réseau avant de continuer.
À 250 ms, quatre opportunités de slot arrivent chaque seconde. Les intervalles plus courts peuvent donner aux applications une vue plus actuelle des transactions et de l'état du réseau tout en transférant la production de blocs d'un validateur à un autre plus tôt.
Les marchés basés sur des oracles et les teneurs de marché automatisés font partie des applications couvertes par la proposition car leurs opérations peuvent dépendre de l'âge des données onchain. Un intervalle plus court réduit le temps entre les mises à jour du réseau, tandis que les utilisateurs peuvent voir les changements de statut des transactions plus tôt.
Pour les swaps, le timing plus court peut réduire la période entre la soumission d'une transaction et son atteinte du réseau. La proposition sous-jacente identifie des confirmations plus rapides et des mises à jour plus fréquentes comme avantages de la réduction de la durée des slots.
Le changement n'augmente pas la capacité brute de transactions de Solana de près de 17 %.
Sous SIMD-0525, les limites de ressources sont réduites proportionnellement à la durée des slots. Plus de slots sont produits sur une période donnée, mais chaque slot est autorisé à porter moins de calcul et de données, maintenant la quantité de travail que le réseau peut traiter en temps réel à peu près au même niveau.
À la base de 60 millions d'unités de calcul utilisée 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 plus 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 slot par une durée de slot fixe peuvent avoir besoin de tenir compte de l'horloge plus rapide. Les blockhashes expirent plus tôt en temps réel à mesure que les slots avancent plus rapidement, laissant moins de temps pour les processus de transaction impliquant une signature hors ligne ou des approbations humaines retardées.
Le timing 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.
À la cible précédente de 300 ms, une époque durait environ 36 heures. Le réglage à 250 ms réduit la durée attendue à environ 30 heures. Un passage à la cible finale de 200 ms la réduirait à environ 24 heures.
Les réductions de slots par étapes de Solana font partie du déploiement d'Agave 4.2. La version du client a commencé à activer plusieurs changements réseau en août, notamment la baisse du loyer de stockage onchain, des transactions plus volumineuses et le chemin vers des slots de 200 ms.
La conception par étapes inclut une sauvegarde liée aux taux de blocs sautés. La progression vers le prochain réglage de slot peut être interrompue si les taux de saut dépassent le niveau que les développeurs considèrent acceptable, ce qui donne aux validateurs le temps d'opérer sous chaque configuration avant qu'une autre réduction ne soit activée.
Aucune date pour le mainnet n'a été fixée pour l'étape des 200 ms.
Les mises à niveau de Solana vont au-delà de slots plus rapides
Le timing des slots ne représente qu'une partie des changements réseau déployés via Agave.
Solana a introduit séparément Transaction V1, qui augmente la taille maximale d'une transaction sérialisée de 1 232 octets à 4 096 octets. Le 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 multisignature complexes au sein d'une seule transaction.
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 SIMD-0525. Des transactions individuelles plus volumineuses ne déterminent donc pas l'horloge des slots, tandis que des slots plus courts n'augmentent pas automatiquement la taille maximale d'une transaction.
Solana a activé les changements indépendamment via des feature gates. La structure permet à une mise à niveau de progresser sans exiger que les autres fonctionnalités incluses dans Agave 4.2 soient activées en même temps.
Solana vise toujours des slots de 200 ms
L'étape finale sous SIMD-0525 réduirait le temps de slot cible de 250 ms à 200 ms, amenant le réseau à cinq slots ciblés par seconde.
Une fenêtre de leader de validateur de quatre slots tomberait par conséquent à environ 800 ms. La durée d'époque diminuerait d'environ 30 heures sous le réglage actuel de 250 ms à environ 24 heures.
Les développeurs de Solana n'ont pas fourni de date d'activation sur le mainnet pour la réduction finale. La progression dépend du comportement du réseau sous le réglage actuel, notamment si les validateurs peuvent maintenir des taux de blocs sautés acceptables.
Les réductions de slots sont distinctes d'Alpenglow, la refonte prévue du consensus de Solana. Alpenglow vise à remplacer TowerBFT par un système de vote appelé Votor et à retirer les transactions de vote onchain 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 mainnet a été lié à Agave 4.3 plutôt qu'aux feature gates de temps de slot utilisés pour SIMD-0525.
Alpenglow est entré en phase de test par les validateurs de la communauté plus tôt en 2026, permettant aux opérateurs d'exécuter la conception du consensus sur un cluster de test avant le déploiement sur le mainnet. Anza a décrit le système comme le plus grand changement de consensus de l'histoire de Solana.
Pour SIMD-0525, le réseau reste à l'étape des 250 ms jusqu'à ce que les développeurs activent le feature gate final. 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.
