Transactions Solana de 4 096 octets : les changements de v1

Mis à jour le 8 septembre 2026. Les transactions v1 sont actives sur testnet et devnet, pas encore sur le mainnet Solana.

Les transactions Solana pourront passer de 1 232 à 4 096 octets avec le nouveau format v1. Cet espace permet d’intégrer dans une seule opération des preuves zero-knowledge, de grands multisigs et des lots auparavant divisés. Cela ne signifie pas que le débit ou la vitesse du réseau triple automatiquement.

La mise à niveau impose des adaptations aux wallets, indexeurs, clients RPC et services qui sponsorisent les frais. Les applications legacy et v0 continuent de fonctionner, mais un lecteur de blocs sans support v1 peut échouer lorsque le format atteindra le mainnet.

Transactions Solana : de 1 232 à 4 096 octets

La page officielle de la mise à niveau Solana annonce une limite multipliée par 3,3. L’ancien plafond provenait d’une taille prudente de paquet réseau. Le transport QUIC permet désormais de répartir une transaction sur plusieurs frames.

Le maximum reste fixé à 4 Kio pour limiter pression mémoire et retransmissions. Une transaction plus grande consomme davantage de bande passante et peut coûter plus cher à propager. La capacité supplémentaire sert aux charges complexes ; elle n’offre pas des ressources gratuites.

V1 place la configuration des ressources directement dans le message et déplace les signatures. Le premier octet permet d’identifier la version avant de tout décoder. Legacy et v0 gardent leur plafond de 1 232 octets.

Ce qui peut tenir dans une seule transaction

Une preuve ZK ou un multisig institutionnel peut dépasser la place disponible dans l’ancien format. Les développeurs devaient répartir le flux entre plusieurs transactions, utiliser des tables d’adresses ou des bundles. Chaque étape ajoute confirmations, signatures et risque d’échec partiel.

V1 peut rendre certains ensembles atomiques : soit toutes les actions s’exécutent, soit aucune ne modifie l’état. Confidential Transfers, signatures avancées et opérations coordonnées entre programmes sont des cas importants.

Plus d’espace ne supprime pas les limites logiques. V1 conserve au maximum 64 adresses de comptes et 64 instructions, avec des budgets explicites. La complexité doit rester conçue, pas seulement entassée dans un conteneur plus grand.

Pourquoi indexeurs et explorateurs doivent évoluer

Les appels getTransaction ou getBlock doivent définir maxSupportedTransactionVersion à 1. Sans cette valeur, une transaction v1 peut produire une erreur de version. Avec getBlock, une seule opération inconnue peut empêcher la lecture de tout le bloc.

Le changelog Solana du 27 août demande aux équipes de se préparer. Un indexeur peut sembler fonctionner jusqu’au premier bloc v1, puis cesser d’avancer ou afficher des informations incomplètes.

Les flux Geyser et gRPC ont besoin de stubs compatibles, tandis que décodeurs et archives doivent reconnaître le préfixe v1. Notre analyse des validateurs Solana et des changements Agave rappelle que l’infrastructure doit évoluer avec le protocole.

Compute budget et priority fee changent d’emplacement

Dans v1, limite de calcul, taille des données chargées, heap et priority fee sont stockés dans transactionConfig. Scanner seulement les anciennes instructions ComputeBudget peut retourner silencieusement des zéros et produire des statistiques fausses.

L’unité de la priority fee change également. V1 conserve un total en lamports, alors que les formats précédents utilisent des micro-lamports par unité de calcul. Réutiliser l’ancienne multiplication peut appliquer un montant incorrect.

Les applications qui envoient v1 doivent définir explicitement les limites de calcul et de données. Les valeurs par défaut sont nulles ; une transaction sans configuration peut échouer avant l’exécution. La simulation sert à estimer les ressources avec une marge adaptée.

Address Lookup Tables et comptes

V1 n’utilise pas les Address Lookup Tables. Son espace permet d’inclure directement jusqu’à 64 adresses, supprimant une dépendance employée par v0 pour tenir dans un paquet plus petit. Les adresses dupliquées sont rejetées.

Certains flux deviennent plus autonomes, mais les systèmes v0 ne deviennent pas compatibles automatiquement. SDK, wallets et programmes doivent choisir le format approprié et gérer les deux pendant la transition.

Le support arrive dans les bibliothèques, notamment Anza Kit. Une version capable de lire v1 ne sait pas nécessairement la construire et l’envoyer. Il faut contrôler la matrice exacte pour chaque langage et client.

État de l’activation mainnet

La page officielle indique une feature gate active sur testnet et devnet, mais inactive sur mainnet. Le planning vise Agave 4.2 ; il reste explicitement provisoire et peut changer.

Les utilisateurs ordinaires n’ont rien à faire puisque legacy et v0 fonctionnent encore. L’action immédiate concerne développeurs, fournisseurs RPC, explorateurs, indexeurs, relayers, sponsors de frais et services de co-signature.

Dire que Solana a déjà triplé chaque transaction serait faux. V1 élève le plafond lorsque ce format est choisi et supporté. Les formats précédents conservent dimensions et comportement.

Coûts et risques des grandes transactions

Une opération atomique peut réduire signatures et confirmations par rapport à plusieurs transactions liées. Les grands paquets utilisent aussi plus de bande passante et pourraient nécessiter une priority fee supérieure pour concurrencer de petites transactions de priorité comparable.

La surface d’erreur augmente : mauvaises limites, anciens parseurs et analyses de frais fondées sur le format précédent peuvent interrompre un service. Les tests doivent couvrir lecture, simulation, envoi, stockage et reproduction des données.

L’intégration des NFT Solana par OpenSea montre pourquoi la compatibilité de l’infrastructure compte autant que la capacité du protocole. La fonction ne devient réelle pour l’utilisateur que lorsque wallets, API et explorateurs la traitent correctement.

Les transactions Solana de 4 096 octets répondent à une contrainte réelle pour ZK, multisig et lots atomiques. La valeur de la mise à niveau ne dépendra pas seulement du nombre d’octets, mais de la préparation de l’écosystème, du coût de propagation et de la fiabilité des données pendant la transition v1.