La transaction v1 de Solana se prépare à augmenter la taille maximale des transactions de 1 232 octets à 4 096 octets, offrant aux développeurs plus d'espace pour les preuves à connaissance nulle, les opérations multisignatures de grande taille et les lots complexes.
La mise à niveau est active sur le testnet et le devnet de Solana, mais n'avait pas été activée sur le mainnet lors de la vérification du 7 septembre. Le 9 septembre a été rapporté comme date cible, bien que la page officielle de mise à niveau de Solana indique que le calendrier d'activation reste sujet à changement.
Pour les utilisateurs réguliers, la transition devrait être largement invisible. Les transactions existantes héritées et v0 continueront de fonctionner. La question plus importante est de savoir si les portefeuilles, les explorateurs, les fournisseurs de données et les applications mettent à jour leurs systèmes avant l'apparition des premières transactions v1 sur le mainnet.
La transaction v1 augmente la capacité, pas le TPS de Solana
Le changement le plus visible est la limite de taille de transaction plus élevée. Passer de 1 232 à 4 096 octets offre environ 3,3 fois plus d'espace dans une seule transaction.
Cela ne signifie pas que Solana traitera soudainement 3,3 fois plus de transactions par seconde. La transaction v1 modifie la quantité d'informations qu'une transaction peut contenir, pas le nombre de transactions que le réseau peut intégrer dans chaque bloc.
L'espace supplémentaire est utile pour les opérations transportant de grandes quantités de données d'instructions. Sous la limite précédente, les développeurs devaient parfois diviser une action complexe en plusieurs transactions. Chaque étape nécessitait un traitement séparé et créait un autre point où le processus pouvait échouer.
Avec la transaction v1, certaines de ces opérations peuvent être effectuées en une seule transaction atomique. Soit l'action entière réussit, soit elle échoue sans laisser l'utilisateur à mi-chemin d'un processus en plusieurs étapes.
La mise à niveau est donc mieux comprise comme une amélioration de la conception et de la fiabilité des applications plutôt qu'une simple augmentation de vitesse.
Les preuves ZK et les opérations multisignatures de grande taille gagnent plus d'espace
Les preuves à connaissance nulle peuvent nécessiter plus de données que la limite de transaction existante de Solana ne le permet. Cela a rendu certaines fonctions de confidentialité et de jetons confidentiels difficiles à réaliser en une seule transaction.
La nouvelle limite de 4 096 octets donne aux développeurs suffisamment d'espace pour inclure certaines preuves ZK directement. Les utilisations potentielles incluent les transferts confidentiels, les soldes chiffrés et les applications qui doivent prouver des informations sans révéler publiquement les données sous-jacentes.
Les transactions multisignatures de grande taille peuvent également en bénéficier. La gestion de trésorerie, la garde institutionnelle et la gouvernance en chaîne peuvent nécessiter plusieurs signatures ou des instructions détaillées. Plus d'espace de transaction permet à certaines de ces actions d'être approuvées et exécutées ensemble.
Le même principe s'applique aux opérations par lots. Un portefeuille ou une application peut être en mesure de combiner plusieurs étapes liées, réduisant le nombre d'approbations qu'un utilisateur doit signer.
Ces capacités n'apparaîtront pas automatiquement lors de l'activation de la transaction v1. Les développeurs doivent toujours mettre à jour leurs applications et construire délibérément des transactions en utilisant le nouveau format.
Pourquoi la transaction v1 supprime les tables de recherche d'adresses
Les transactions v0 de Solana utilisent des tables de recherche d'adresses, communément appelées ALT, pour référencer les adresses de comptes à l'aide d'identifiants plus courts. Cela aide les transactions avec beaucoup de comptes à rester petites, mais cela rend également le traitement des transactions plus compliqué.
La transaction v1 supprime les ALT et inclut les adresses de comptes directement dans la transaction.
Cela donne aux validateurs une vue plus claire de la liste complète des comptes sans avoir à récupérer d'abord des tables de recherche séparées. Les frais, les limites de ressources et les limites d'instructions deviennent également plus faciles à identifier avant l'exécution.
Il y a un compromis. Chaque adresse de compte placée directement dans une transaction v1 utilise 32 octets. Une application qui interagit avec de nombreux comptes peut toujours trouver les transactions v0 plus efficaces en termes d'espace car les ALT compressent ces adresses.
La transaction v1 n'est donc pas un remplacement complet de la v0. Les deux formats répondent à des besoins différents. La v1 est la plus utile pour les transactions transportant des preuves, des signatures ou des charges utiles d'instructions plus importantes, tandis que la v0 peut rester adaptée aux itinéraires impliquant de nombreux comptes.
Les portefeuilles existants continuent de fonctionner, mais les services de données doivent être mis à niveau
L'envoi de transactions v1 est facultatif. Un portefeuille qui continue d'utiliser des transactions héritées ou v0 devrait fonctionner normalement après l'activation de la fonctionnalité.
Le problème le plus urgent se situe du côté de la lecture.
Les services RPC, les explorateurs et les applications qui demandent des données de transaction doivent déclarer leur prise en charge de la version 1. S'ils ne le font pas, les tentatives de récupération d'un bloc contenant une transaction v1 peuvent échouer au lieu de renvoyer uniquement les transactions qu'ils comprennent.
Les indexeurs sont confrontés à un risque plus silencieux. La transaction v1 déplace les limites de calcul et les paramètres de frais prioritaires hors des instructions Compute Budget séparées et dans un nouveau champ de configuration de transaction.
Un service d'analyse obsolète peut ne pas produire d'erreur évidente. Il pourrait continuer à fonctionner tout en rapportant incorrectement qu'une transaction v1 n'a utilisé aucun frais prioritaire ni budget de calcul.
Cela signifie que le premier signe d'une mise à niveau incomplète peut être des blocs manquants, des flux de données bloqués ou des statistiques de frais inexactes plutôt que des paiements utilisateur échoués.
Les transactions plus volumineuses ne signifient pas automatiquement des frais moins élevés
Effectuer une opération en une seule transaction peut réduire les signatures et confirmations répétées. Cela peut réduire les coûts pour certaines applications par rapport à la division de la même action en plusieurs transactions.
Cela ne garantit pas que chaque transaction v1 sera moins chère.
Les transactions plus volumineuses consomment toujours des ressources réseau, et les développeurs doivent définir explicitement leurs limites d'unités de calcul et de données de compte. Les frais prioritaires restent également pertinents lorsque l'espace de bloc est demandé.
Sous v1, les frais prioritaires sont exprimés comme un montant total en lamports plutôt qu'un prix par unité de calcul. Les applications qui copient leurs anciens calculs de frais sans convertir le format pourraient soumettre des frais incorrects.
L'avantage pratique est la flexibilité. Les développeurs peuvent utiliser le format plus grand lorsque cela rend une application plus simple ou plus sûre, tout en continuant à utiliser les anciens formats lorsqu'ils restent plus efficaces.
Le marché du SOL peut avoir besoin de preuves d'adoption
La mise à niveau élargit ce que les développeurs peuvent construire sur Solana, mais elle ne crée pas immédiatement une demande pour SOL en soi.
Lors de la vérification du 7 septembre, le prix du SOL sur MEXC était d'environ 104,39 $, en baisse de 1,21 % sur 24 heures. L'absence de rallye immédiat après la mise à niveau suggère que les traders ne traitent pas la transaction v1 comme un événement de prix à court terme.
Le point de vue de MEXC est que le signal le plus important sera l'adoption par les applications après l'activation du réseau principal, et non la date d'activation elle-même.
Si la transaction v1 conduit à une utilisation plus large des transferts confidentiels, des systèmes de multisig institutionnels et des applications financières plus complexes, elle pourrait augmenter l'activité utile et la demande pour l'espace de blocs de Solana au fil du temps. Cela donnerait à la mise à niveau un lien plus clair avec la valeur économique de SOL.
Si seulement un petit nombre de développeurs utilisent le format, la réalisation technique pourrait avoir un impact limité sur le marché à court terme. Des erreurs d'infrastructure pendant le déploiement pourraient également temporairement l'emporter sur le récit positif.
Ce qu'il faut surveiller lors du déploiement du réseau principal
Le premier point de contrôle est le statut officiel de la fonctionnalité. Une date prévue n'est pas la même chose qu'une activation confirmée.
Après l'activation, les traders et les développeurs devraient surveiller si les principaux portefeuilles, fournisseurs RPC, explorateurs et indexeurs traitent correctement les transactions v1. Des données de bloc manquantes ou des rapports de frais incorrects indiqueraient que certaines parties de l'écosystème n'étaient pas préparées.
Le prochain test est l'utilisation réelle. La transaction v1 devient significative lorsque les applications utilisent l'espace ajouté pour des produits qui étaient auparavant difficiles à construire, et non simplement lorsque le réseau accepte le nouveau format.
L'adoption par les outils de confidentialité, les portefeuilles institutionnels et les applications DeFi complexes fournirait une preuve plus solide que la mise à niveau crée une nouvelle demande plutôt que de simplement modifier l'encodage des transactions.
FAQ
La transaction v1 de Solana est-elle déjà en ligne ?
La transaction v1 était active sur le testnet et le devnet mais pas encore activée sur le réseau principal lors de la vérification du 7 septembre 2026. Le 9 septembre a été rapporté comme objectif, mais les utilisateurs devraient vérifier le statut officiel de la fonctionnalité.
Les utilisateurs devront-ils mettre à jour leurs portefeuilles ?
La plupart des utilisateurs ne devraient pas avoir besoin de prendre des mesures immédiates. Les transactions héritées et v0 continueront de fonctionner. Les développeurs de portefeuilles et d'applications ont besoin de mises à jour s'ils veulent envoyer ou lire correctement les transactions v1.
La transaction v1 rendra-t-elle Solana plus rapide ?
Pas directement. Elle augmente la quantité de données pouvant tenir dans une transaction. Elle n'augmente pas automatiquement la capacité des blocs ou le débit des transactions.
La v1 remplace-t-elle les transactions v0 ?
Non. La v1 est facultative, et la v0 reste disponible. Les opérations lourdes en comptes peuvent continuer à utiliser la v0 car ses tables de recherche d'adresses peuvent représenter de nombreuses adresses plus efficacement.
La mise à niveau de la transaction v1 de Solana est-elle haussière pour SOL ?
Elle peut soutenir l'utilité à long terme de SOL si les transactions plus volumineuses produisent des applications utiles et une activité réseau supplémentaire. L'activation seule ne garantit pas une demande plus élevée ou un prix du SOL plus élevé.
Avertissement de risque
La transaction v1 est un changement majeur d'infrastructure même si elle est facultative pour les expéditeurs. Les services RPC obsolètes, les indexeurs et les systèmes d'analyse peuvent échouer ou rapporter des données incorrectes après l'activation du réseau principal. SOL reste également exposé à la volatilité plus large des crypto-monnaies, et une mise à niveau technique ne garantit pas une adoption accrue ou une appréciation du prix.
