Date de lancement de la transaction Solana V1 : À quoi s'attendre le 9 septembre

2026-09-04
Date de lancement de la transaction Solana V1 : À quoi s'attendre le 9 septembre

Solana est sur le point de plus que tripler la quantité de données pouvant tenir dans une seule transaction. Le 9 septembre 2026, la Transaction V1 a été activée sur le mainnet, étendant la taille maximale de la transaction de 1 232 octets à 4 096 octets, le plus grand changement dans la structure des transactions Solana depuis l'arrivée des tables de recherche d'adresses en 2021.

Principaux enseignements

  • La Transaction V1 est mise en service sur le mainnet de Solana le 9 septembre 2026, augmentant la taille maximale de la transaction de 3,3x, de 1 232 octets à 4 096 octets, définie conjointement par deux documents d'amélioration Solana, SIMD-0296 et SIMD-0385.

  • La mise à niveau est opt-in pour quiconque envoie des transactions, ce qui signifie que les formats hérités et v0 continuent de fonctionner exactement comme avant, mais cela introduit des changements radicaux pour les fournisseurs RPC, les indexeurs et les plateformes d'analytique qui lisent les données de la blockchain.

  • L'espace supplémentaire débloque des cas d'utilisation auparavant impraticables dans une seule transaction, y compris les preuves à divulgation nulle de connaissance pour les transferts confidentiels, l'agrégation de signatures BLS, et des portefeuilles multisignatures beaucoup plus grands.

join bitrue to get 938 usdt

Qu'est-ce que la Transaction V1 de Solana ?

Transaction V1 est un nouveau format de transaction Solana qui élève la taille maximale d'une seule transaction de 1 232 octets à 4 096 octets, une augmentation de 3,3x. Il est défini par deux documents d'amélioration Solana, ou SIMD, tous deux rédigés par les ingénieurs d'Anza Jacob Creech et Andrew Fitzgerald : SIMD-0296 fixe le nouveau plafond de taille, et SIMD-0385 définit la structure réelle, ou le format, d'une transaction v1. Ensemble, ils résolvent un goulet d'étranglement qui a contraint ce que les développeurs pouvaient intégrer dans une seule transaction Solana depuis les premiers jours du réseau.

À première vue : Transaction V1

Détail

Ancien format (Héritage/v0)

Transaction V1

Taille maximale de la transaction

1 232 octets

4 096 octets

Propositions gouvernementales

N/A

SIMD-0296, SIMD-0385

Gestion des adresses

Tables de recherche d'adresses (ALTs)

Adresses en ligne, ALTs supprimées

Paramètres de frais/computing

Définis via les instructions du ComputeBudgetProgram

Définis via le TransactionConfigMask à décalage fixe

Activation du mainnet

Déjà en ligne

9 septembre 2026

Compatibilité avec les versions précédentes

N/A

Entièrement opt-in ; héritage et v0 non affectés

Pourquoi la limite de 1 232 octets existait-elle et pourquoi cela n'a plus de sens ?

La limite de taille de transaction originale de Solana était fixée de manière conservatrice autour de la taille d'un paquet réseau IPv6 de 1 280 octets, une contrainte au niveau réseau de l'époque avant que Solana n'adopte sa méthode actuelle de livraison des transactions.

En 2022, Solana est passé à QUIC comme protocole par défaut pour recevoir des transactions, et QUIC n'a pas de limite de taille maximale intégrée pour les flux de données qu'il transporte. Cela a rendu le plafond d'origine de 1 232 octets effectivement obsolète, un reste de limite plutôt qu'une véritable exigence technique.

SIMD-0296 formalise un nouveau plafond de 4 096 octets à la place, choisi délibérément pour correspondre à la taille standard de page mémoire de 4 kilooctets sur le matériel de validation. Cette alignement permet de garder le coût de gestion de chaque transaction en mémoire efficace, sans qu'une seule transaction ne déborde sur plusieurs pages mémoire.

Lire aussi : À propos du vote des validateurs Solana

Ce qui change réellement sous le capot

Au-delà du plafond de taille plus grand, SIMD-0385 restructure la façon dont une transaction v1 est organisée :

  • Un marqueur de version se déplace vers l'avant de la transaction (une valeur octet spécifique l'identifiant comme v1), permettant à l'infrastructure d'identifier le format instantanément sans avoir besoin de déballer la transaction entière d'abord.

  • Les signatures se déplacent vers la fin de la transaction plutôt qu'au début.

  • Les paramètres de frais et de calcul se déplacent dans un emplacement fixe dans l'en-tête de la transaction. Auparavant, les frais prioritaires et les limites d'unités de calcul étaient définis par le biais d'instructions spéciales mélangées avec tout le reste dans la transaction, ce qui nécessitait que le logiciel parcoure toute la liste d'instructions pour les trouver. Dans v1, ces paramètres résident dans un endroit prévisible, ce qui les rend beaucoup plus rapides à lire.

  • Les tables de recherche d'adresses sont complètement supprimées dans v1. Les ALTs ont été introduites à l'origine pour qu'une transaction puisse faire référence à de nombreux comptes en utilisant des références courtes d'un octet au lieu des adresses complètes de 32 octets, une solution de contournement nécessaire sous l'ancienne limite de taille. Avec 4 096 octets d'espace, même 64 adresses de longueur complète s'intégrent confortablement sans avoir besoin de cette solution de contournement, donc v1 liste simplement les adresses directement.

Rien de cela n'affecte les transactions construites de l'ancienne manière. Les transactions héritées et v0 continuent de fonctionner exactement comme elles le font aujourd'hui, car V1 est une option supplémentaire, pas un remplacement.

Ce que cette mise à niveau débloque réellement

L'espace supplémentaire n'est pas juste une délicatesse technique, il rend des fonctionnalités spécifiques pratiques qui ne l'étaient pas auparavant :

  • Des preuves à divulgation nulle de connaissance, comme celles utilisées dans les Transferts Confidentiels. 
    Les Transferts Confidentiels, faisant partie du standard des Extensions de Token de Solana, permettent aux utilisateurs de déplacer des tokens tout en gardant le montant privé grâce à des preuves cryptographiques. Ces preuves sont souvent trop volumineuses pour tenir dans une transaction de 1 232 octets, obligeant les développeurs à diviser le processus en plusieurs transactions et à perdre la garantie que l'ensemble de l'opération réussit ou échoue ensemble. À 4 096 octets, une preuve complète tient dans une seule transaction.

  • Agrégation de signature BLS. 
    Il s'agit d'une technique cryptographique qui combine de nombreuses signatures individuelles en une seule preuve compacte, utile dans des situations telles que les ponts inter-chaînes ou la coordination des validateurs où plusieurs parties doivent autoriser conjointement une seule action. Il devient pratique de tenir dans une seule transaction Solana sous le nouveau format.

  • Des portefeuilles multisig plus grands. 
    Les portefeuilles multisig, couramment utilisés par les trésors institutionnels et les DAO via des plateformes comme Squads, nécessitent que plusieurs personnes approuvent une transaction avant son exécution. La limite de taille précédente limitait le nombre de signataires qui pouvaient raisonnablement être inclus ; le nouveau format permet des groupes de signataires significativement plus grands.

Pourquoi cela importe plus qu'une simple augmentation de taille : Atomicité

Le bénéfice pratique le plus important n'est pas seulement « plus de place », c'est l'atomicité, ce qui signifie qu'une transaction se complète entièrement ou échoue entièrement, sans rien laisser à moitié terminé.

Les développeurs qui avaient besoin de plus d'espace que la limite précédente autorisait ont souvent contourné le problème en utilisant des bundles Jito, un système qui peut chaîner jusqu'à cinq transactions séparées ensemble comme un groupe tout-ou-rien.

Cela fonctionne, mais la garantie ne tient que dans l'infrastructure propre de Jito et dépend de la concurrence pour le prioritaire via des pourboires aux validateurs.

Une seule transaction V1, en revanche, porte automatiquement la garantie d'atomicité au niveau du protocole de base de Solana, sans infrastructure de regroupement ni pourboires supplémentaires nécessaires. Pour les développeurs construisant des routes d'échange DeFi complexes ou des opérations cryptographiques en plusieurs étapes, c'est une base plus fiable sur laquelle bâtir.

Lire aussi : Le gain de Solana stagne à 1 %—Perd-il du terrain face à Robinhood ?

Ce qui se casse le 9 septembre (et qui cela affecte)

C'est la partie qui compte le plus pour les développeurs et les fournisseurs d'infrastructure, pas pour les utilisateurs de portefeuilles quotidiens. Parce que la transaction V1 change la structure de données sous-jacente, tout logiciel lisant des blocs Solana doit être mis à jour pour le comprendre correctement :

  • Les appels RPC qui ne demandent pas explicitement le support v1 provoqueront une erreur lorsqu'ils rencontrent une transaction v1, au lieu de fonctionner silencieusement.

  • Certains flux de données en temps réel peuvent complètement se bloquer s'ils rencontrent une transaction v1 pour laquelle ils ne sont pas préparés, sans nécessairement lancer une erreur évidente.

  • Les indexeurs et les plateformes d'analytique qui lisent les données de frais et de calcul de l'ancienne manière peuvent silencieusement rapporter des chiffres incorrects pour les transactions v1, puisque cette information vit maintenant dans une partie différente de la transaction qu'auparavant.

  • Les fournisseurs d'infrastructure doivent exécuter un logiciel client de validateurs mis à jour, spécifiquement Agave v4.2.2 ou plus récent, pour traiter correctement le trafic v1.

Pour les utilisateurs quotidiens de Solana envoyant et recevant simplement des transactions via un portefeuille standard, cette mise à jour n'est pas quelque chose que vous devez configurer personnellement. Le fardeau incombe aux fournisseurs de portefeuilles, aux services RPC et aux plateformes de données blockchain de mettre à jour leurs systèmes, ce que la plupart des grands fournisseurs d'infrastructure préparent déjà depuis l'activation du testnet début septembre.

Chronologie de déploiement

Jalon

Date

Tests de développement locaux disponibles

24 août 2026

Activation du testnet

1er septembre 2026 (époque 1025)

Activation du mainnet

9 septembre 2026

La transaction V1 arrive également avec la première phase d'une mise à niveau distincte, SIMD-0437, qui commence une réduction en cinq étapes visant une réduction de 90 % du coût de stockage des comptes de tokens sur Solana. Les deux changements sont expédiés sous le même plus large logiciel de validateurs Agave 4.2.

Ce que cela signifie pour les détenteurs et les commerçants de SOL

La transaction V1 est fondamentalement une mise à niveau de l'infrastructure et de l'expérience développeur plutôt qu'un changement qui affecte directement l'expérience quotidienne des détenteurs de tokens. Son importance réside dans ce qu'elle permet à l'avenir : des opérations DeFi plus complexes, des transferts préservant la confidentialité et des configurations multisig de niveau institutionnel deviennent toutes plus pratiques à construire sur Solana.

Que cela se traduise par de nouvelles applications et une activité réseau accrue au fil du temps vaut la peine d'être observé, mais ce n'est pas le genre de mise à niveau qui change les soldes des portefeuilles ou les frais de transaction par elle-même. Vous pouvez suivre le prix en direct de SOL sur la page de marché SOL de Bitrue au fur et à mesure que ce déploiement progresse.

Si vous êtes nouveau sur Solana en général, le guide de Bitrue sur Solana pour les débutants est un bon point de départ pour comprendre l'écosystème plus large dans lequel cette mise à niveau s'inscrit. Pour ceux qui souhaitent s'impliquer davantage, le guide de Bitrue sur comment acheter SOLcouvre les bases, et le staking SOL sur Bitrue est une option pour les détenteurs cherchant à gagner un rendement pendant que le réseau continue de se développer.

Si vous suivez également les opportunités de tokens autour de l'écosystème croissant de Solana, le résumé de Bitrue sur les airdrops de Solana de septembre couvre ce qui est actuellement actif.

Lire aussi : Prédiction de prix de Solana 2026 et 2030 : Jusqu'où SOL peut-il aller ?

Conclusion

L'activation du mainnet de la Transaction V1 de Solana le 9 septembre est une véritable mise à niveau technique significative, tripliant plus de trois fois la quantité de données pouvant tenir dans une seule transaction Solana et débloquant des cas d'utilisation auparavant impraticables comme les transferts confidentiels et les configurations multisig plus grandes. 

C'est aussi un déploiement délibérément sans drame pour les utilisateurs réguliers : rien ne se casse pour les portefeuilles existants ou les types de transactions, et le véritable travail repose sur les fournisseurs d'infrastructure qui ont eu des semaines d'accès au testnet pour se préparer. L'impact réel de la mise à niveau se montrera progressivement, dans ce que les développeurs construiront une fois que l'espace supplémentaire sera disponible.

FAQ

Quand la Transaction V1 de Solana sera-t-elle lancée sur le mainnet ?

La Transaction V1 s'active sur le mainnet de Solana le 9 septembre 2026, après l'activation du testnet le 1er septembre.

La Transaction V1 affectera-t-elle mon portefeuille Solana ou des transactions existantes ?

Non. La Transaction V1 est entièrement opt-in, et les formats de transactions hérités et v0 continuent de fonctionner exactement comme auparavant. La mise à niveau affecte principalement les développeurs et les fournisseurs d'infrastructure qui doivent mettre à jour leurs systèmes pour lire le nouveau format correctement.

Que débloque réellement la Transaction V1 ?

Elle fait en sorte que des opérations auparavant impraticables tiennent dans une seule transaction, y compris les preuves à connaissance nulle utilisées dans les transferts confidentiels, l'agrégation de signatures BLS pour la coordination entre chaînes et validateurs, et des configurations de portefeuille multisig significativement plus grandes.

Pourquoi les Tables de Consultation d'Adresse ont-elles été supprimées dans la Transaction V1 ?

Les Tables de Consultation d'Adresse étaient une solution de contournement pour l'ancienne limite de taille de 1 232 octets de Solana, permettant aux transactions de référencer des comptes avec des codes courts au lieu d'adresses complètes. Avec la nouvelle limite de 4 096 octets, même un grand nombre d'adresses complètes s'intègre confortablement sans avoir besoin de cette solution de contournement.

La Transaction V1 rend-elle les transactions Solana moins chères ?

Pas directement. La Transaction V1 change la structure et les limites de taille des transactions plutôt que la mécanique des frais. Une mise à niveau séparée, SIMD-0437, vise une réduction de 90 % des coûts de stockage des comptes de jetons et sera déployée presque en même temps sous le même logiciel.

Avertissement : Les opinions exprimées appartiennent exclusivement à l'auteur et ne reflètent pas les opinions de cette plateforme. Cette plateforme et ses affiliés déclinent toute responsabilité quant à l'exactitude ou la pertinence des informations fournies. Cela est uniquement à des fins d'information et n'est pas destiné à des conseils financiers ou d'investissement.

Feragatname: Bu makalenin içeriği finansal veya yatırım tavsiyesi niteliğinde değildir.

Inscrivez-vous maintenant pour réclamer un package cadeau de 6752 USDT pour les nouveaux arrivants

Rejoignez Bitrue pour des récompenses exclusives

Inscrivez-vous maintenant
register

Recommandé

Réponses WOTD de Binance 6-7 septembre 2026
Réponses WOTD de Binance 6-7 septembre 2026

Le WOTD de Binance du 6 au 7 septembre 2026 propose un puzzle crypto amusant où vous devinez le mot, apprenez des termes clés, gagnez des récompenses et construisez votre série quotidienne.

2026-09-06Lire