Les transactions Solana V1 atteignent le testnet, visant à regrouper les opérations multi-étapes en une seule

Le 1er septembre, Anza a lancé la Transaction V1 sur le testnet de Solana, permettant la répétition finale de cette mise à jour avant son lancement le 9 septembre.

Le changement vise à permettre le traitement des charges de travail cryptographiques et DeFi, initialement fragmentées en plusieurs transactions, au sein d'une seule transaction atomique, comme indiqué par Solana Compass.

Les tâches qui étaient auparavant divisées tiennent désormais dans un seul appel

La modification la plus notable est l'augmentation de l'espace. La taille maximale d'une transaction Solana sérialisée est passée de 1 232 octets à 4 096 octets, soit une augmentation de 3,3 fois, effective à partir de l'époque 1025 du testnet.

Selon le site web dédié à la mise à jour des grandes transactions de la Fondation Solana, cette augmentation de la taille des transactions rendra possible l'implémentation de preuves à divulgation nulle de connaissance (zero-knowledge proofs), de transactions multisig complexes ainsi que divers schémas de signature qui étaient auparavant impossibles dans une seule transaction.

Par conséquent, moins de transactions doivent être traitées, moins d'argent est nécessaire pour payer les signatures, et il n'est plus besoin d'attendre une chaîne de confirmations. Les schémas de signature BLS, ainsi que les transactions confidentielles et les configurations multisig bénéficieront de cette mise à jour.

Deux propositions principales sont essentielles à cette amélioration. SIMD-0296 augmente la taille des transactions de 1 232 octets à 4 096 octets, tandis que SIMD-0385 définit le format de message V1 et intègre la configuration des transactions directement dans le message.

Moins d'un jour après l'activation de la mise à jour, Brennan Watt, PDG d'Anza a publié un post sur X mentionnant une grande transaction sur l'explorateur du testnet avec le message : « ATTENTION : les grandes transactions ont atteint le testnet ».

Pourquoi une seule transaction bat un bundle

L'importance de l'atomicité réside dans le fait qu'à certaines occasions, les développeurs contournaient l'ancienne limite de taille de Solana via des bundles Jito. En effet, SIMD-0296 explique ce contournement et précise également que les bundles manquent d'atomicité au niveau du protocole, contrairement à une transaction native.

Selon la documentation de Jito, les bundles peuvent inclure jusqu'à cinq transactions traitées séquentiellement sur une base tout ou rien. Cependant, les bundles fonctionnent au sein du block-engine de Jito et entrent en concurrence avec les pourboires aux validateurs. La transaction V1, quant à elle, désigne une transaction native unique Solana, qui bénéficie de la garantie d'atomicité au niveau de la transaction fournie par Solana.

Pour les développeurs DeFi, cela peut aider à simplifier l'établissement de routes d'échange, de preuves et d'autres types de transactions multi-étapes. Si l'opération est entièrement couverte par la transaction V1, elle réussit ou retourne la transaction comme une transaction native unique au lieu de s'appuyer sur un bundle de transactions.

Ce que le DeFi obtient au-delà des octets supplémentaires

V1 modifie également la structure de la transaction. Alors que Legacy et V0 gèrent les frais de priorité et les demandes de ressources via des instructions ComputeBudget, SIMD-0385 intègre ces configurations dans les paramètres de transaction de V1, simplifiant ainsi le travail des validateurs lors de l'identification des besoins en ressources sans avoir à rechercher activement dans la liste des instructions.

V1 élimine également les Tables de recherche d'adresses (ALT), utilisées par V0 pour raccourcir les adresses de comptes. Selon l'analyse de la Fondation concernant le compromis ALT de V1 , V1 effectue désormais le placement des adresses en ligne. Cela facilite l'entrée des validateurs par rapport à la méthode utilisée dans les applications lourdes de comptes sous V0, qui consomment davantage d'octets lors de la conversion.

L'avantage pratique pour les routeurs et les agrégateurs DEX est qu'il y a désormais plus de place pour des routes atomiques complexes. Cependant, cette amélioration n'est pas sans limites. En effet, la capacité maximale de Solana de 64 comptes différents reste inchangée, et ainsi les applications nécessitant une utilisation intensive de comptes peuvent toujours souffrir de cette limitation, même si la capacité en limite d'octets n'est plus un problème.

Cette mise à jour est introduite alors que Solana fait un bond vers la finance décentralisée (DeFi). Le rapport de Galaxy sur Solana pour le deuxième trimestre 2026 met en évidence une activité croissante des stablecoins, des actions tokenisées et des actifs du monde réel.

Selon Galaxy, à l'avenir, le potentiel de Solana dépendra largement de la capacité à utiliser les actifs dans le prêt, la garantie, le trading à effet de levier et la génération de rendement, plutôt que simplement dans l'émission ou le trading. Sur la base des données DeFiLlama sur Solana, la plateforme semble avoir une présence DeFi solide.

Par ailleurs, le calendrier de la mise à jour coïncide avec la phase de mise à niveau Agave 4.2. À titre informatif, Cryptopolitan a indiqué que le plan de mise en œuvre progressive de la réduction des coûts devrait entraîner des économies d'environ 90 %, ainsi qu'une diminution du temps de traitement de 500 à 200 millisecondes, ce qui bénéficiera aux émetteurs de stablecoins, aux fournisseurs de portefeuilles et aux systèmes de paiement.

Les opérateurs RPC ont une semaine pour mettre à jour

V1 est optionnel, donc les transactions Legacy et V0 continuent de fonctionner. Le problème réside dans le fait que l'infrastructure lisant le trafic V1 est-elle prête.

Anza a obligé les fournisseurs RPC à passer à Agave v4.2.2 ou v4.3.0-beta.3. La liste de vérification de migration Helius Agave 4.2 souligne également que les consommateurs RPC qui ne déclarent pas la conformité V1 peuvent subir des échecs d'appel tels que getBlock lorsqu'une transaction V1 est utilisée.

Le processus a commencé par des tests locaux de V1 le 24 août, peu après quoi la date du mainnet a été confirmée comme étant le 9 septembre le 29 août. V1 a activé le Testnet le 1er septembre à l'époque 1025, avec une activation prévue sur le mainnet le 9 septembre.

Cette dernière exécution du testnet constitue la dernière étape préparatoire pour les fournisseurs RPC, les indexeurs, les portefeuilles, les SDK et les plateformes analytiques avant le lancement du mainnet.