Solana vise le 9 septembre pour la Transaction v1, un nouveau format qui augmente la taille maximale des transactions sérialisées de 1 232 octets à 4 096 octets.
Cette augmentation offre aux développeurs environ 3,3 fois plus d'espace de transaction. La feuille de route officielle de Solana indique que cette capacité supplémentaire peut accueillir des preuves à divulgation nulle de connaissance, des opérations multi-signatures importantes, des lots et certains schémas de signature onchain.
Auparavant, les opérations importantes devaient être divisées en plusieurs transactions lorsque leurs instructions, signatures et informations de compte dépassaient le plafond de 1 232 octets. Ce processus ajoutait de la complexité car une transaction pouvait réussir tandis qu'une autre étape échouait.
La Transaction v1 pourrait permettre aux développeurs de combiner davantage de ces instructions en une seule opération atomique. Soit chaque instruction réussit, soit la transaction entière échoue. Ce modèle pourrait bénéficier aux itinéraires de trading, aux transferts confidentiels, aux opérations inter-chaînes et aux applications traitant des preuves cryptographiques complexes.
La mise à niveau n'augmente pas la limite de Solana de 64 comptes référencés par transaction. Les applications peuvent inclure plus de données et d'instructions, mais elles ne peuvent pas interagir automatiquement avec plus de comptes.
La Transaction v1 est facultative. Les portefeuilles et les applications peuvent continuer à envoyer des transactions legacy et v0 sous la limite existante de 1 232 octets. Les utilisateurs n'ont pas besoin de migrer des tokens, d'échanger des SOL ou de compléter une réclamation avant l'activation.
Les développeurs doivent adopter délibérément le nouveau format pour accéder à sa plus grande capacité. La documentation de Solana identifie trois formats pris en charge : legacy, v0 et v1. Chaque format organise les adresses de compte et les limites de ressources différemment.
Le format v0 utilise des Tables de Recherche d'Adresses, ou ALTs, pour représenter les adresses de compte via des index compressés d'un octet. La V1 supprime les ALTs et place les adresses de compte complètes de 32 octets directement à l'intérieur de la transaction.
Cela crée un compromis. La V1 fournit une enveloppe globale plus grande, mais les applications qui dépendent fortement des tables de recherche pourraient dépenser plus d'octets pour représenter les mêmes comptes. L'analyse technique de Solana a révélé que 90 % des transactions échantillonnées ajouteraient moins de 1 400 octets lors de la conversion de v0 à v1.
Le principal risque de compatibilité s'applique aux services qui lisent les blocs et les transactions. Les fournisseurs d'appels de procédure à distance (RPC) doivent définir leur version de transaction maximale prise en charge à un. Sinon, les requêtes pourraient échouer lorsqu'elles rencontrent une transaction v1.
Les indexeurs, explorateurs et services d'analyse doivent également modifier la manière dont ils récupèrent les limites de ressources. Les transactions legacy et v0 placent les limites de calcul et les paramètres de frais de priorité à l'intérieur des instructions ComputeBudget. La V1 les stocke dans une configuration de transaction dédiée.
Les services obsolètes pourraient donc afficher des informations incorrectes. Par exemple, un explorateur pourrait afficher des frais de priorité nuls même si l'utilisateur en a payé. Les sponsors de frais et les applications qui vérifient les limites de transaction doivent lire la nouvelle configuration plutôt que de scanner les instructions de l'ancien style.
Les applications envoyant des transactions v1 doivent explicitement définir les limites d'unités de calcul et de données chargées, car les deux sont par défaut à zéro. Les développeurs devraient tester la construction, la signature et le décodage des transactions avant de basculer le trafic de production vers ce format.
Jacob Creech, vice-président de la technologie de la Fondation Solana, a identifié le 9 septembre comme la date prévue pour le mainnet. Comme crypto.news l'a précédemment rapporté, la mise à niveau est incluse dans le déploiement Agave 4.2 d'Anza.
Cependant, la feuille de route officielle indique toujours que la fonctionnalité du mainnet n'est "pas activée". Elle indique également que le calendrier de publication d'Anza est "tentatif et sujet à modification". Le testnet et le devnet ont déjà activé la fonctionnalité, selon la dernière page d'état de la Fondation.
L'augmentation de taille provient de SIMD-0296, tandis que SIMD-0385 définit le format v1. Jacob Creech et Andrew Fitzgerald ont co-écrit les deux propositions.
Le plafond de 4 096 octets a été choisi en partie parce que quatre kilooctets correspondent à une taille de page mémoire courante utilisée par le matériel des validateurs. Les transactions plus importantes consommeront également une bande passante supplémentaire, bien que la mise à niveau n'introduise pas de frais distincts facturés par octet.
La Transaction v1 reste distincte des réductions de loyer de Solana, des objectifs de slots plus courts et de la refonte du consensus Alpenglow. Dans une couverture connexe, crypto.news a rapporté qu'Alpenglow vise une finalité d'environ 150 millisecondes, octobre restant un objectif de développement plutôt qu'une date d'activation garantie.
SOL
