Le vice-président de la technologie de la Fondation Solana, Jacob Creech, a présenté plusieurs prochaines mises à niveau de Solana le 30 août. La transaction V1 est prévue pour le 9 septembre, tandis que la première étape d'une réduction du loyer du réseau est attendue au cours de la semaine commençant le 31 août.
Résumé
- Solana prévoit d'activer la transaction V1 le 9 septembre, augmentant la taille des transactions à 4 096 octets.
- La première étape de réduction du loyer commence la semaine prochaine, amorçant un processus en cinq étapes vers des économies de 90 %.
- Solana a déjà réduit les créneaux cibles à 350 millisecondes, avec 300, 250 et 200 prévus plus tard.
- Alpenglow reste ciblé pour octobre, Solana visant une finalité d'environ 150 millisecondes après l'activation du réseau principal.
- Les transactions héritées et de version zéro restent compatibles car les développeurs doivent choisir le format V1 plus grand.
Creech a également déclaré que les développeurs prévoient de raccourcir davantage les temps de créneau et de cibler octobre pour Alpenglow. Cependant, ces changements suivent des processus d'activation distincts. La transaction V1 ne réduira pas automatiquement les temps de créneau ni n'activera Alpenglow.
La transaction V1 porte la limite de Solana à 4 096 octets
La transaction V1 portera la taille maximale des transactions sérialisées de Solana de 1 232 octets à 4 096 octets. Cette augmentation représente environ 3,3 fois la limite existante, selon la feuille de route officielle des mises à niveau de Solana.
Le format plus grand pourrait prendre en charge des transactions contenant des preuves à divulgation nulle de connaissance, des instructions de multisignature complexes et d'autres opérations gourmandes en données. La proposition SIMD-0296 associée identifie également les signatures BLS et les opérations inter-chaînes comme des utilisations possibles.
Les développeurs doivent choisir le format V1. Les transactions héritées et de version zéro existantes resteront valides. La transaction V1 ne prendra pas en charge les tables de recherche d'adresses, ce qui signifie que les applications doivent décider quel format convient à chaque transaction.
Le changement nécessite également que les portefeuilles, les interfaces de programmation d'applications et autres infrastructures gèrent des charges utiles de données plus importantes. La proposition reconnaît les risques possibles de bande passante et de fragmentation du réseau, ce qui rend les tests coordonnés importants avant une adoption plus large.
La réduction du loyer de Solana commence avec l'une des cinq étapes
La première réduction du loyer n'atteint pas immédiatement l'objectif complet de 90 %. Solana prévoit cinq étapes qui abaisseraient finalement le calcul du loyer de 6 960 lamports par octet à 696 lamports par octet.
Solana utilise des soldes exonérés de loyer pour limiter la croissance incontrôlée de l'état. Les applications verrouillent des SOL lors de la création de comptes qui stockent des données. Ce SOL est généralement récupérable lorsque le compte est fermé, ce qui signifie que le loyer fonctionne davantage comme un dépôt remboursable que comme des frais de réseau récurrents.
Des exigences plus faibles réduiraient le montant de SOL que les développeurs doivent verrouiller lors de la création de comptes de jetons, de comptes de programmes et d'autres états en chaîne. Cela pourrait réduire les coûts d'entrée pour les applications qui gèrent de nombreux comptes d'utilisateurs.
Agave 4.2 incluait le code nécessaire, mais Solana a placé les changements derrière des portes de fonctionnalités indépendantes. Comme crypto.news l'a précédemment rapporté, les validateurs peuvent activer séparément les mises à niveau du loyer, de la taille des transactions et du temps de créneau après les tests.
Des créneaux Solana plus rapides suivent un calendrier distinct
Solana a déjà réduit son temps de créneau cible à 350 millisecondes, contre 400 millisecondes auparavant. Le réseau prévoit des étapes supplémentaires à 300, 250 et éventuellement 200 millisecondes.
Creech n'a pas fourni de dates pour ces étapes restantes. Chaque réduction nécessite une activation de fonctionnalité distincte. Les développeurs du réseau peuvent donc surveiller les performances des validateurs avant de passer à l'étape suivante.
Des slots plus courts peuvent améliorer la vitesse de confirmation des transactions et augmenter la fréquence à laquelle les validateurs produisent des blocs. Ils imposent également des exigences de synchronisation et de réseau plus élevées aux validateurs. Solana prévoit d'ajuster les limites de ressources proportionnellement lors du déploiement.
Transaction V1 et la réduction des temps de slot sont liées à la feuille de route plus large de Solana en matière de performance, mais elles restent techniquement distinctes. Les rapports décrivant le 9 septembre comme date pour les deux changements exagéreraient l'annonce de Creech.
Alpenglow reste un objectif d'octobre
Alpenglow est la refonte proposée du consensus de Solana. Solana affirme qu'elle vise à réduire la finalité des transactions à environ 150 millisecondes, par rapport au processus de confirmation plus long utilisé par le système de consensus actuel.
La feuille de route officielle liste Alpenglow comme « en développement », tandis qu'Agave 4.3 est attendu en octobre. Le post de Creech soutient octobre comme objectif actuel, mais aucune déclaration ne confirme une date d'activation garantie sur le réseau principal.
Avant cela, Solana devrait commencer la première étape de réduction des loyers et activer Transaction V1 le 9 septembre. D'autres réductions de slots dépendront d'activations distinctes des validateurs. Alpenglow doit également terminer les tests et obtenir le support réseau requis.
Aucun mouvement de marché vérifié n'a été directement attribué à l'annonce de Creech au moment de la publication.
