Anza a activé la Transaction V1 sur le testnet de Solana le 1er septembre, offrant au réseau une dernière répétition de cette mise à niveau avant son lancement sur le mainnet prévu le 9 septembre. Selon Solana Compass, cette modification permet aux charges de travail cryptographiques et DeFi qui devaient auparavant être fragmentées sur plusieurs transactions d'être traitées en une seule transaction atomique.

Des tâches auparavant scindées tiennent désormais en un seul appel

Le changement le plus notable concerne l'espace disponible. La taille maximale d'une transaction Solana sérialisée est passée de 1 232 octets à 4 096 octets — une augmentation de 3,3 fois — avec effet au epoch 1025 du testnet. La limite de 1 232 octets remontait à la toute première conception du protocole Solana, et V1 marque la première fois que cette limite est relevée au niveau du format de message depuis que V0 a introduit les Address Lookup Tables comme solution partielle à la pression sur la taille.

Selon la page de la Solana Foundation consacrée à la mise à jour des grandes transactions, cette taille accrue permet de mettre en œuvre des preuves à divulgation nulle de connaissance, de grandes transactions multisignatures et divers schémas de signature qui ne pouvaient auparavant pas tenir dans une seule transaction. Il en résulte moins de transactions à traiter, des coûts de signature réduits et plus besoin d'attendre une chaîne de confirmations. Les schémas de signature BLS, les transactions confidentielles et les configurations multisignatures devraient bénéficier de cette mise à niveau.

Deux propositions sont au cœur de cette amélioration : SIMD-0296 relève la limite de taille de transaction de 1 232 à 4 096 octets, tandis que SIMD-0385 définit le format de message V1 et déplace la configuration des transactions dans le message lui-même.

Moins d'un jour après l'activation, le PDG d'Anza, Brennan Watt, a publié sur X en signalant une grande transaction sur l'explorateur du testnet avec le message : « ATTENTION : de grandes transactions sont arrivées sur le testnet. »

Pourquoi une transaction vaut mieux qu'un bundle

L'atomicité est importante car les développeurs ont parfois contourné l'ancienne limite de taille de Solana à l'aide de bundles Jito. SIMD-0296 documente explicitement cette solution de contournement et note que les bundles ne bénéficient pas de l'atomicité au niveau du protocole, contrairement à une transaction native unique.

Selon la documentation de Jito, les bundles peuvent contenir jusqu'à cinq transactions traitées séquentiellement selon un principe du tout ou rien. Cependant, les bundles fonctionnent au sein du moteur de blocs de Jito et sont en concurrence pour les pourboires des validateurs. Une transaction V1, en revanche, est une transaction Solana native unique portant la garantie d'atomicité au niveau transactionnel propre à Solana.

Pour les développeurs DeFi, cela simplifie la construction de routes de swap, de preuves et d'autres opérations multi-étapes : si l'ensemble de l'opération tient dans une transaction V1, elle réussit ou est annulée comme une seule transaction native, sans dépendre d'un bundle.

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

V1 modifie également la structure des transactions. Là où les transactions Legacy et V0 gèrent les frais de priorité et les demandes de ressources via des instructions ComputeBudget, SIMD-0385 déplace ces paramètres dans la configuration de la transaction V1, facilitant ainsi pour les validateurs l'identification des besoins en ressources sans avoir à parcourir la liste des instructions.

V1 supprime en outre les Address Lookup Tables (ALT), que V0 utilisait pour raccourcir les adresses de comptes. Selon l'analyse de la Fondation sur le compromis ALT de V1, V1 place plutôt les adresses en ligne, ce qui simplifie les entrées des validateurs par rapport à l'approche de V0, qui consommait davantage d'octets lors de la conversion des adresses dans les applications gourmandes en comptes.

Le bénéfice pratique pour les routeurs et les agrégateurs DEX est un espace accru pour des routes atomiques complexes. Cette amélioration n'est toutefois pas sans limites : le plafond de Solana de 64 comptes distincts par transaction reste inchangé, de sorte que les applications gourmandes en comptes peuvent toujours atteindre ce plafond même si la capacité en octets n'est plus la contrainte.

Cette mise à niveau intervient alors que Solana s'avance davantage dans la finance on-chain. Le rapport de Galaxy sur Solana pour le T2 2026 montre une activité croissante des stablecoins, des actions tokenisées et des actifs réels. Selon Galaxy, le potentiel futur de Solana dépendra largement de la capacité à utiliser ces actifs dans le prêt, la mise en garantie, le trading sur marge et le rendement — et pas seulement dans l'émission ou le négoce. Les données de DeFiLlama sur Solana indiquent une forte présence DeFi sur la plateforme.

Le calendrier coïncide également avec la phase de mise à niveau Agave 4.2. Comme Cryptopolitan l'a rapporté précédemment, le plan progressif de réduction des coûts devrait générer des économies d'environ 90 % et réduire le temps de traitement de 500 à 200 millisecondes, au bénéfice des émetteurs de stablecoins, des fournisseurs de portefeuilles et des systèmes de paiement.

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

V1 est optionnelle, de sorte que les transactions Legacy et V0 continuent de fonctionner. La question ouverte est de savoir si l'infrastructure lisant le trafic V1 est prête.

Anza a exigé que les fournisseurs RPC passent à Agave v4.2.2 ou v4.3.0-beta.3. La liste de contrôle de migration Helius pour Agave 4.2 avertit que les consommateurs RPC ne déclarant pas leur conformité V1 peuvent rencontrer des échecs d'appels, comme getBlock, lorsqu'une transaction V1 est impliquée.

Le déploiement a commencé par des tests locaux de V1 le 24 août, suivis de la confirmation de la date du mainnet au 9 septembre le 29 août. V1 a été activée sur le testnet le 1er septembre au epoch 1025, avec une activation sur le mainnet prévue le 9 septembre.

Cette dernière série sur le testnet constitue l'étape préparatoire finale pour les fournisseurs RPC, les indexeurs, les portefeuilles, les SDK et les plateformes d'analyse avant le lancement sur le mainnet.