Que change le format v1 activé le 15 septembre ?
La taille maximale d'une transaction Solana est passée de 1 232 à 4 096 octets. Le feature gate txv1 s'est activé sur le réseau principal au début de l'epoch 1035, le 15 septembre 2026 vers 01h00 UTC. Il est également actif sur le devnet et le testnet, ces réseaux parallèles où les développeurs testent leur code avant le réseau réel, comme l'explique notre fiche sur la différence entre testnet et mainnet. Deux documents portent la modification. SIMD-0296 relève le plafond de taille, SIMD-0385 définit le format v1 qui le transporte. Les formats v0 et legacy continuent de fonctionner, donc les applications et les portefeuilles qui n'ont pas besoin de place supplémentaire ne changent rien à leur manière d'émettre des transactions sur la chaîne Solana.
Quelles opérations ne tenaient pas dans 1 232 octets ?
La Solana Foundation cite les preuves à divulgation nulle de connaissance utilisées par les Confidential Transfers, les multisignatures de grande taille et les opérations groupées. Ces traitements devaient jusqu'ici être découpés en plusieurs transactions enchaînées. Ils peuvent désormais tenir dans une seule transaction atomique, avec une confirmation au lieu de plusieurs et moins de signatures à payer. Unchained ajoute à cette liste des schémas de signature récents comme les signatures à usage unique de Winternitz et BLS. Le chiffre de 4 096 octets n'est pas arbitraire, relève Unchained : il correspond à la page mémoire standard de 4 KiB des machines qui font tourner les validateurs, et il borne le coût de relais d'une transaction, puisque tout ce qui dépasse la taille de paquet du réseau doit être fractionné.
Qui doit modifier son code ?
Lire des transactions constitue une rupture, envoyer du v1 reste optionnel. La documentation officielle détaille quatre situations :
- Les consommateurs de RPC, indexeurs et explorateurs doivent passer `maxSupportedTransactionVersion` à la valeur entière 1 sur `getTransaction`, `getBlock` et `blockSubscribe`.
- Les décodeurs de transactions brutes doivent reconnaître le préfixe de version 129 (0x81) et son nouvel agencement.
- Les indexeurs et les relais lisent désormais les limites dans `transactionConfig`, et non plus dans les instructions ComputeBudget.
- Ceux qui parrainent des frais perdent leurs garde-fous : les plafonds qui reposaient sur l'inspection des instructions ComputeBudget cessent de s'appliquer.
Qui veut émettre du v1 doit fixer explicitement la limite d'unités de calcul et la taille des données chargées. Les deux valent zéro par défaut, et la transaction échoue sans ces valeurs. Les Address Lookup Tables disparaissent du format, les comptes étant placés directement dans l'instruction, jusqu'à 64. Les frais de priorité changent d'unité au passage, exprimés en lamports au total et non plus en micro-lamports par unité de calcul. Les éditeurs de portefeuilles ne doivent annoncer la prise en charge de v1 qu'une fois capables de parser et signer ce format. L'annoncer trop tôt conduit les applications à envoyer des transactions que le portefeuille rejettera.
Quelles versions de bibliothèques sont nécessaires ?
| Bibliothèque | Version minimale | Capacité |
|---|---|---|
| @solana/kit | 8.0.0 | lecture et envoi |
| @solana/web3.js 1.x | 1.99.0 | lecture seule |
| solders (Python) | 0.29.0 | lecture et envoi |
| solana-go | 1.23.0 | lecture et envoi |
| Yellowstone geyser | 15.1.1 | lecture |
Côté infrastructure, les validateurs Jito-Solana et les nœuds RPC sous Agave doivent tourner en v4.2.2 ou ultérieure. Les versions antérieures rétrogradent une transaction v1 en v0, et un leader sur une ancienne compilation Jito n'inscrira pas de transactions v1 dans ses blocs.
Où en est la réduction des temps de slot ?
En parallèle, Solana descend son temps de slot de 400 vers 200 millisecondes par paliers de 50, chacun doté de son propre feature gate. Deux sont actifs sur le réseau principal : 350 millisecondes depuis le 19 août 2026, epoch 1019, puis 300 millisecondes depuis le 25 août, epoch 1023. Les paliers 250 et 200 millisecondes tournent sur devnet et testnet, sans date arrêtée pour le mainnet. Le taux de blocs sautés sert de critère de passage, ces gains reposant sur les optimisations apportées aux clients validateurs. Cette réduction a un effet direct sur les intégrations. La fenêtre d'expiration d'un blockhash reste de 150 blocs, mais elle s'écoule plus vite : environ 60 secondes à 300 millisecondes, contre 80 secondes à l'origine, et près de 40 secondes une fois le palier 200 activé. Les signatures hors ligne qui attendent une validation humaine disposent donc de moins de marge. Une epoch de 432 000 slots dure aujourd'hui environ 36 heures, contre 48 heures auparavant.
