Qu'est-ce qui vient d'être activé sur le mainnet ?

Le changelog publié par Solana recense trois feature gates notables côté mainnet : le format Transaction V1, la réduction du loyer de stockage à 5080 lamports par octet, et la réduction du temps de slot à 250 ms. Le slot est l'intervalle pendant lequel un validateur désigné produit un bloc, et sa durée conditionne le rythme auquel le réseau confirme les transactions. Le document accompagne une longue liste de versions publiées, dont Agave v4.4.0-alpha.4 et v4.3.0-rc.1, les versions Firedancer v26.09.3 pour le testnet et v26.08.5 pour le mainnet, ainsi que le SDK JS du programme Token-2022 en v0.18.0 et Anchor v0.32.2. Pour comprendre la distinction entre réseau de test et réseau principal, voir notre explication de la différence entre testnet et mainnet.

Pourquoi discuter de la suppression des limites de calcul ?

Les blocs de Solana sont aujourd'hui plafonnés à 100 millions d'unités de calcul, les compute units. Une discussion ouverte dans les SIMDs, les documents de proposition d'amélioration du réseau, envisage de retirer entièrement cette limite par un processus en deux étapes. Les validateurs choisiraient alors eux-mêmes la quantité de calcul et de transactions qu'ils estiment que le réseau peut absorber. Ces textes restent des discussions et des propositions. Aucun calendrier d'adoption n'est donné par le changelog, et rien n'indique qu'ils seront retenus en l'état.

Quelles autres propositions sont sur la table ?

Quatre sujets sont ouverts côté protocole :

  • désactiver les formats de transaction Legacy et V0, maintenant que Transaction V1 est déployé sur le mainnet, ce qui allégerait le travail des validateurs, sur le modèle de SIMD-0500 qui interdisait déjà les déploiements de versions sBPF antérieures à la v3
  • simplifier la destruction des frais de transaction, aujourd'hui additionnés sur l'ensemble du bloc avant que la moitié ne soit brûlée en fin de slot, au profit d'un calcul transaction par transaction
  • introduire la multiplication d'entiers sur 128 bits dans le runtime, là où il fallait jusqu'ici manipuler deux entiers de 64 bits
  • permettre de consulter la configuration d'une transaction pendant son exécution, une question posée notamment parce que les demandes et la consommation de calcul ont migré des instructions ComputeBudgetProgram vers l'en-tête de la transaction avec Transaction V1

Que préparent les clients validateurs ?

Côté Agave, plusieurs chantiers touchent aux déploiements de programmes en fin d'epoch, afin qu'ils partent dans le bon environnement et ne soient pas rechargés après la bascule. Le client consolide aussi ses deux environnements d'exécution pour simplifier la validation au moment du déploiement. Autre changement annoncé : avec Transaction V1 activé, la commande de déploiement devient quatre fois moins coûteuse en frais, les transactions étant quatre fois plus grandes. Agave prévoit par ailleurs d'estimer à l'avance le temps restant pour envoyer une transaction au leader, et de viser le leader suivant en cas de doute, pour limiter les transactions perdues à mesure que les slots raccourcissent. Son service Votor, qui gère les votes et le consensus, passera à XDP pour ses échanges réseau, une technique qui contourne la pile réseau habituelle. La gestion mémoire des lots de votes vérifiés et non vérifiés d'Alpenglow sera rendue explicite dans le service de vérification BLS. Ces mécanismes de vote sont au cœur de la preuve d'enjeu. Firedancer, le client validateur développé pour la performance, abandonne OpenSSL au profit de sa propre implémentation TLS, jugée mieux adaptée aux besoins d'un validateur qu'à ceux d'un serveur web. Il a également implémenté la signature de messages ed25519 par lots de huit.

Et du côté de la sécurité ?

Le compte @r0bre a publié les résultats obtenus par un agent de recherche autonome sur SIMD-0376, la proposition qui remplacerait l'implémentation ed25519 utilisée par le réseau. Ces travaux ont identifié plusieurs vulnérabilités critiques, depuis corrigées par Anza selon le changelog. Enfin, le programme Token-2022 passera au point d'entrée pinocchio plutôt qu'au point d'entrée natif, un changement présenté comme comparable aux gains obtenus sur le programme Token avec p-token.