Solana lancera Transaction v1 cette semaine : la taille maximale d’une transaction passera à 4 096 octets

Solana lancera officiellement la fonctionnalité Transaction v1 sur le mainnet le mercredi 9 septembre 2026, faisant passer la taille maximale des transactions de 1 232 octets à 4 096 octets, soit une capacité multipliée par plus de trois. Cette mise à niveau est définie par deux propositions d’amélioration de Solana : SIMD-0296 (transactions plus grandes) et SIMD-0385 (format Transaction v1).

Spécifications techniques de Transaction v1

Transaction v1 est définie conjointement par deux propositions d’amélioration de Solana : SIMD-0296 fixe une limite de taille plus élevée pour les transactions, tandis que SIMD-0385 définit le format Transaction v1. Les deux propositions ont été rédigées conjointement par Jacob Creech et Andrew Fitzgerald. La nouvelle fonctionnalité fonctionne de manière stable sur le testnet et le devnet depuis un certain temps et sera officiellement déployée sur le mainnet le 9 septembre 2026.

Transaction v1 est conçue pour être rétrocompatible : le format v0 existant reste valide, et les portefeuilles ainsi que les applications n’adopteront le format v1 que lorsqu’ils auront besoin de davantage d’espace pour leurs transactions, sans obligation de migrer.

Les trois types de transactions qui bénéficieront le plus directement de Transaction v1

Après l’augmentation de la capacité de 1 232 octets à 4 096 octets, les trois types de transactions suivants bénéficieront le plus directement de cette évolution :

Preuves cryptographiques volumineuses : les données de vérification, telles que les preuves ZK, dépassaient souvent la limite de 1 232 octets et devaient donc être réparties sur plusieurs transactions. Transaction v1 permet d’envoyer l’intégralité des données de vérification ZK dans une seule transaction.

Processus d’approbation multisignature : les transferts de fonds nécessitant l’approbation de plusieurs signataires, comme ceux d’une trésorerie d’entreprise ou d’une proposition de DAO, utilisent de l’espace pour chaque signature. Le format v1 permet de finaliser le processus d’approbation multisignature au sein d’une seule transaction.

Transferts confidentiels : certains mécanismes de transaction privée nécessitent une couche de chiffrement supplémentaire. La capacité initiale insuffisante entraînait l’échec des transactions ou réduisait leur efficacité, tandis que les 4 096 octets offrent un espace suffisant pour ce type d’opérations.

Pourquoi la limite a été fixée à 4 096 octets

La limite de 4 096 octets (4 Ko) repose sur des considérations matérielles : il s’agit de la taille standard des pages mémoire utilisées par les nœuds validateurs. Lorsqu’une transaction s’étend sur plusieurs pages mémoire, le coût de traitement augmente considérablement, ce qui nuit au maintien du nombre élevé de TPS (transactions par seconde) de Solana. Les 4 Ko constituent donc un compromis entre l’augmentation de la capacité et le maintien des performances du réseau.

L’ancienne limite de 1 232 octets provenait de la conception réseau initiale de Solana : chaque transaction devait tenir dans un paquet IP d’environ 1 280 octets. En 2022, Solana a modifié le mode de transmission du trafic des transactions, rendant ce plafond rigide inutile. Le lancement de Transaction v1 constitue la suppression officielle de cette limitation historique.

Mises à jour nécessaires des nœuds RPC et des services de lecture

Transaction v1 a davantage d’impact sur les services qui lisent les données on-chain que sur ceux qui soumettent des transactions. Tous les services récupérant les données des blocs et des transactions — nœuds RPC, fournisseurs de données on-chain et backends de portefeuilles — doivent mettre à jour leur code. Dans le cas contraire, ils renverront directement une erreur lorsqu’ils rencontreront une transaction au format v1.

Un autre impact concret concerne l’emplacement du champ des frais prioritaires (priority fee) : v1 stocke les informations relatives aux frais prioritaires dans un champ différent de celui utilisé par v0. Les logiciels obsolètes afficheront donc des « frais nuls » lors de la lecture d’une transaction v1, même si l’utilisateur a effectivement payé des frais d’accélération. Si les interfaces de portefeuille, les explorateurs blockchain et les applications de trading ne sont pas mis à jour, les utilisateurs verront des informations de frais inexactes.

Comparaison de la capacité avec Ethereum

Du point de vue de la conception du protocole, Ethereum n’impose aucune limite de taille des transactions au niveau du protocole : les développeurs peuvent exécuter des opérations nécessitant beaucoup de données au sein d’une seule transaction, à condition de payer des frais de gas plus élevés. Par le passé, Solana était fortement limité en ce qui concerne le nombre d’instructions pouvant tenir dans une seule transaction. Après le relèvement de la limite à 4 096 octets avec Transaction v1, l’écart entre les deux chaînes se réduit, mais 4 096 octets restent peu élevés par rapport à Ethereum L1 : une transaction DeFi complexe sur Ethereum, comme un arbitrage entre plusieurs pools ou des emprunts et remboursements portant sur plusieurs actifs, dépasse souvent cette taille.

La portée technique concrète pour l’écosystème Solana réside dans la suppression des solutions de contournement nécessaires aux développeurs : lorsqu’une opération devait auparavant être répartie sur plusieurs transactions, il fallait gérer les dépendances d’état entre les transactions ainsi que les problèmes d’annulation en cas d’échec. Transaction v1 permet de réaliser une logique complexe au sein d’une seule opération atomique, ce qui la rapproche davantage des modèles traditionnels de programmation.

Questions fréquentes

Quelle est la date de lancement de Solana Transaction v1, quelle sera l’évolution de la capacité maximale et quelles sont les propositions qui la définissent ?

Solana Transaction v1 sera lancée sur le mainnet le mercredi 9 septembre 2026, et la capacité maximale des transactions passera de 1 232 octets à 4 096 octets, soit une capacité multipliée par plus de trois. La mise à niveau est définie par les deux propositions SIMD-0296 et SIMD-0385, rédigées conjointement par Jacob Creech et Andrew Fitzgerald, après avoir fonctionné de manière stable sur le testnet et le devnet.

Pourquoi la limite a-t-elle été fixée à 4 096 octets plutôt qu’à une valeur plus élevée ?

Les 4 096 octets correspondent à la taille standard des pages mémoire utilisées par les nœuds validateurs. Lorsqu’une transaction s’étend sur plusieurs pages mémoire, le coût de traitement augmente considérablement, ce qui nuit au maintien du nombre élevé de TPS de Solana. Les 4 Ko constituent donc un compromis entre l’augmentation de la capacité et le maintien des performances du réseau.

Comment les nœuds RPC et les services de lecture doivent-ils être mis à jour, et quel est l’impact concret du changement d’emplacement du champ des frais prioritaires ?

Tous les services récupérant les données des blocs et des transactions doivent mettre à jour leur code, sans quoi ils renverront directement une erreur lorsqu’ils rencontreront une transaction v1. L’emplacement du champ des frais prioritaires de v1 diffère de celui de v0. Les logiciels obsolètes afficheront des « frais nuls » lors de la lecture, même si l’utilisateur a payé des frais d’accélération, et les portefeuilles ainsi que les explorateurs blockchain qui ne seront pas mis à jour afficheront des informations de frais inexactes.