Solana a activé Transaction V1 sur son mainnet au début de l’epoch 1035, le 15 septembre 2026 vers 01:00 UTC. Le plafond d’une transaction passe de 1 232 à 4 096 octets, soit environ 3,3 fois plus d’espace disponible.

Les formats legacy et V0 ne disparaissent pas. Une application qui n’a aucun besoin de transactions plus grandes peut continuer à les émettre. V1 est une nouvelle possibilité, pas une migration forcée de toutes les transactions du réseau.

1 232 octets commençaient à coûter cher en contournements

L’ancienne limite venait en partie de l’histoire technique de Solana et de son transport réseau. Avec 1 232 octets, certaines opérations complexes ne tenaient simplement pas dans une transaction unique. Les développeurs devaient réduire les données embarquées, exploiter les Address Lookup Tables de V0 ou découper une opération en plusieurs transactions.

Le nouveau plafond vise notamment les preuves zero-knowledge, les gros schémas multisignatures et certaines signatures vérifiées directement on-chain. Il permet aussi de regrouper davantage d’étapes dans une même opération atomique : si une étape échoue, l’ensemble de la transaction peut échouer avec elle.

C’est plus propre que de chaîner artificiellement plusieurs transactions lorsqu’une application a réellement besoin que toutes les étapes réussissent ensemble.

V1 change davantage que la taille du paquet

Transaction V1 n’est pas simplement V0 avec quelques kilo-octets supplémentaires. La documentation Solana décrit aussi une autre organisation des comptes et des limites de ressources.

V0 peut utiliser les Address Lookup Tables pour référencer jusqu’à 64 comptes via des index compacts. V1 conserve une limite de 64 adresses mais les place directement dans la transaction et ne prend pas en charge les Address Lookup Tables.

Les limites de calcul changent également d’emplacement. Avec les formats legacy et V0, elles étaient configurées à l’aide d’instructions ComputeBudget. Dans V1, les paramètres de ressources font partie de la configuration du message de transaction.

Pour le développeur qui émet une transaction V1, il y a d’ailleurs un piège plutôt efficace : les limites de compute units et de données ont une valeur par défaut de zéro. Elles doivent donc être renseignées explicitement.

Le vrai risque immédiat est du côté des logiciels qui lisent Solana

Une application peut très bien continuer à envoyer des transactions V0 tout en devenant incompatible avec le réseau si elle ne sait pas lire V1.

Les clients qui récupèrent des transactions ou des blocs doivent annoncer la version maximale qu’ils savent prendre en charge, notamment avec maxSupportedTransactionVersion=1. Sans cette adaptation, la lecture peut échouer lorsqu’une transaction V1 apparaît dans les données demandées.

Cela concerne particulièrement les indexeurs, explorateurs, fournisseurs RPC, outils analytiques, wallets et plateformes qui reconstruisent l’activité on-chain à partir de ces données. Une application qui sponsorise des frais ou cosigne des transactions doit également arrêter de chercher certaines limites uniquement dans les anciennes instructions ComputeBudget : V1 les déplace dans transactionConfig.

Plus gros ne veut pas dire plus de transactions par seconde

Le chiffre de 4 096 octets peut facilement être confondu avec une amélioration générale de capacité du réseau. Ce n’est pas ce que cette mise à jour mesure. Elle augmente la quantité de données qu’une transaction individuelle peut transporter, pas directement le nombre de transactions que Solana exécute chaque seconde.

Une transaction plus grande utilise aussi davantage de bande passante et de ressources. Pendant les périodes de forte concurrence, une opération volumineuse peut toujours avoir besoin de frais de priorité plus élevés pour obtenir de la place.

Il n’existe en revanche pas de nouveau tarif automatique par octet simplement parce que V1 permet d’en transporter davantage.

Un changement déjà utile pour le déploiement des programmes

Le changelog technique de Solana donne un exemple particulièrement concret : le déploiement d’un programme nécessite d’envoyer les données du binaire dans des transactions qui remplissent progressivement des comptes buffer.

Avec des transactions nettement plus grandes, davantage de données peuvent être écrites à chaque envoi. Les outils Solana travaillent ainsi à exploiter V1 dans solana program deploy, avec une réduction annoncée d’environ quatre fois du nombre de transactions et des frais associés à cette phase de déploiement.

Le plafond de 1 232 octets aura survécu longtemps après que le transport réseau qui l’avait rendu pratique a cessé d’être la seule option. Depuis le 15 septembre, les développeurs peuvent enfin choisir un paquet de 4 096 octets.