Qu'est-ce que la transaction Solana V1 ? Mise à jour mainnet de 4 096 octets expliquée

Qu'est-ce que la transaction Solana V1 ? Mise à jour mainnet de 4 096 octets expliquée

Image personnalisée
Solana a activé Transaction V1 sur le mainnet, augmentant la taille maximale des transactions sérialisées de 1 232 octets à 4 096 octets. Ce changement offre aux développeurs environ 3,3 fois plus d'espace dans une seule transaction, facilitant la gestion de charges de travail intensives en données telles que les preuves à divulgation nulle de connaissance, les opérations multisig de grande taille, les transferts confidentiels et des interactions DeFi plus complexes. Transaction V1 est entrée en vigueur à l'Époque 1035 le 15 septembre 2026, tandis que les formats Legacy et V0 existants restent pris en charge.
 
Le chiffre principal, cependant, peut être trompeur. La transaction V1 ne rend pas Solana 3,3 fois plus rapide, ni ne triple automatiquement le nombre de transactions par seconde. Au lieu de cela, la mise à niveau augmente le montant de données sérialisées pouvant être intégrées dans une transaction atomique et redessine certaines parties du format de transaction. Cette distinction est importante car le principal avantage n’est pas simplement « plus de octets ». Il s’agit de la capacité à terminer des flux de travail en une seule transaction qui devaient auparavant être fragmentés en plusieurs étapes.

Qu'est-ce que la transaction Solana V1 ?

La transaction V1 est le nouveau format de transaction de Solana, introduit via le SIMD-0385 en parallèle avec la proposition plus large de taille de transaction dans le SIMD-0296. Sa fonctionnalité la plus visible est l'augmentation de la taille maximale de transaction sérialisée, passant de 1 232 octets à 4 096 octets. La V1 réorganise également le format de transmission, supprime les tables de recherche d'adresses et place les demandes de ressources, telles que les limites d'unités de calcul et les frais de priorité, directement dans la configuration de la transaction, au lieu de s'appuyer sur les instructions traditionnelles de budget de calcul.
 
Il est important de noter que V1 est un format opt-in et non un remplacement obligatoire. Les applications qui n'ont pas besoin d'un espace transactionnel supplémentaire peuvent continuer à utiliser les transactions Legacy ou V0. Les transferts SOL ordinaires, les transferts de jetons simples et de nombreuses interactions dapp existantes n'ont donc pas soudainement besoin de consommer 4 096 octets ou de migrer vers un nouveau type de transaction.
Fonctionnalité Legacy V0 Transaction V1
Taille maximale de la transaction 1 232 octets 1 232 octets 4 096 octets
Format versionné Non Oui Oui
Tables de recherche d'adresses Non Oui Non
Configuration des ressources Instructions de calcul du budget Instructions de calcul du budget Configuration de la transaction
Opérations atomiques plus volumineuses et gourmandes en données Limité Limité Oui
Migration requise Non Non Opt-in
La façon la plus simple de comprendre la mise à niveau est que V1 offre aux applications un enveloppe de transaction beaucoup plus grande tout en conservant les anciens formats de transaction.

Pourquoi Solana était-elle limitée à 1 232 octets ?

La limite d'origine de 1 232 octets remonte à l'architecture réseau de Solana, et non à une décision arbitraire concernant la complexité des applications. Le réseau utilisait historiquement un MTU minimum IPv6 de 1 280 octets comme point de référence. Après déduction des en-têtes réseau, 1 232 octets restaient disponibles pour les données de transaction. La documentation de Solana identifie toujours 1 232 octets comme PACKET_DATA_SIZE traditionnel, bien que les transactions V1 puissent désormais dépasser cette charge utile de paquet en étant transmises sur plusieurs trames QUIC.
 
Une transaction doit inclure bien plus que l'instruction que l'utilisateur souhaite réellement exécuter. Elle comprend des signatures, des adresses de compte, un blockhash récent, des métadonnées d'instruction et des données spécifiques à l'application. Chaque signature Ed25519 consomme 64 octets, tandis qu'une clé publique Solana standard fait 32 octets. Ces chiffres deviennent significatifs lorsqu'une transaction implique de nombreux signataires, comptes ou preuves cryptographiques.
 
Le plafond de 1 232 octets est donc devenu de plus en plus restrictif à mesure que les applications Solana devenaient plus sophistiquées. Il était rarement un obstacle sérieux pour un simple transfert de jeton, mais il pouvait obliger les développeurs créant des applications financières ou cryptographiques avancées à repenser leurs flux de travail pour contourner une limite réseau établie bien plus tôt dans le développement de Solana.

Pourquoi Solana a-t-elle augmenté la limite à 4 096 octets ?

Solana peut désormais assouplir l'ancienne contrainte en partie parce que sa pile réseau utilise QUIC, permettant à une transaction plus grande que la charge utile originale du paquet d'être transmise sur plusieurs trames. Cela rend moins nécessaire l'exigence ancienne selon laquelle une transaction sérialisée entière doit tenir dans une seule charge utile de taille MTU. Dans le même temps, des transactions plus volumineuses consomment une bande passante supplémentaire chez les validateurs, donc supprimer complètement la limite créerait un autre ensemble de problèmes réseau et de ressources.
 
Le nouveau plafond de 4 096 octets, soit 4 Ko, est donc un compromis technique. Il offre aux développeurs un espace d'application considérablement plus important sans rendre la taille des transactions illimitée. Solana souligne que des transactions plus volumineuses peuvent consommer davantage de bande passante réseau et nécessiter des frais de priorité plus élevés que des transactions plus petites en concurrence à un niveau d'urgence similaire.
 
Cette nuance est importante. La transaction V1 n'est pas une abandonment des contraintes de taille des transactions par Solana ; elle remplace une limite fondée sur des hypothèses antérieures du réseau par un plafond considérablement plus élevé conçu pour les applications que le réseau doit désormais supporter.

Solana V1 contre V0 : Qu'est-ce qui a réellement changé ?

V1 supprime les tables de recherche d'adresses

V0 a introduit les tables de recherche d'adresses, ou ALT, comme une solution de contournement à l'ancienne limite de taille des transactions. Au lieu d'inclure directement chaque adresse de compte de 32 octets dans une transaction, une application pouvait référencer des adresses stockées dans des tables de recherche à l'aide d'indices beaucoup plus courts. Cette compression est devenue largement utilisée : l'analyse de Solana sur des activités échantillonnées a révélé qu'environ 62 % des transactions V0 observées référençaient au moins un ALT. V1 supprime le support des ALT et place directement les adresses de compte dans l'enveloppe de transaction plus grande.
 
La suppression des ALT simplifie une partie du processus d'ingestion des validateurs, car les validateurs n'ont plus besoin de récupérer et de résoudre l'état des tables de correspondance avant de connaître l'ensemble complet des comptes d'une transaction. Mais cela consomme également une partie de l'espace supplémentaire fourni par la V1. Solana a estimé que, lorsqu'on représente les transactions existantes sous la V1, la moitié affiche moins d'environ 420 octets de taille sérialisée supplémentaire, tandis que 90 % affichent moins d'environ 1 400 octets. Les transactions qui compressaient auparavant de nombreuses adresses grâce à un petit nombre d'ALT peuvent connaître une expansion beaucoup plus importante.

Plus de bytes ne signifient pas des comptes illimités

V1 n'augmente pas non plus le nombre de comptes qu'une transaction peut accéder par trois. Solana applique actuellement une limite de 64 comptes à l'exécution, même si la représentation sous-jacente de l'indice a un plafond théorique plus élevé. Une fonctionnalité distincte pourrait éventuellement augmenter la limite de verrouillage des comptes à 128, mais ce n'est pas automatiquement inclus dans la Transaction V1.
 
Cela signifie que certaines routes DeFi gourmandes en comptes peuvent encore atteindre la limite de comptes, même lorsqu'il reste des centaines de bytes de transaction inutilisés. V1 offre particulièrement une marge importante pour les charges de travail qui réutilisent un ensemble de comptes existant mais nécessitent davantage de données d'instruction, de signatures ou de preuves ; il est moins transformateur pour les stratégies dont la complexité provient principalement de l'interaction avec de nombreux marchés et comptes supplémentaires.

Les demandes de ressources sont intégrées à la transaction

V1 modifie également la façon dont les transactions décrivent leurs besoins en ressources. Les limites d'unités de calcul, les limites de données de comptes chargés, la taille du tas et les frais de priorité peuvent être placées à des positions fixes dans la configuration de la transaction au lieu d'être exprimées via les instructions ComputeBudgetProgram. Cela permet à l'infrastructure réseau d'identifier plus tôt les informations de planification importantes sans avoir à analyser la liste des instructions.
 
Pour les développeurs, cela signifie que la mise à jour va au-delà d'une simple augmentation de la limite de octets. Les logiciels qui construisent, décodent, indexent, parrainent ou évaluent les transactions doivent comprendre la nouvelle structure V1 plutôt que d'assumer que chaque transaction se comporte comme une transaction Legacy ou V0.

Qu'est-ce que les transactions de 4 096 octets peuvent débloquer ?

Preuves à divulgation nulle de connaissance et transferts confidentiels

La technologie à preuve à connaissance nulle est l’un des plus clairs bénéficiaires, car les preuves peuvent nécessiter de importantes données de transaction. Sous l’ancienne limite, un développeur pouvait disposer de suffisamment de capacité de calcul pour vérifier une opération, mais pas assez d’espace de transaction sérialisée pour inclure la preuve et toutes les instructions environnantes dans une seule transaction. Le nouvel enveloppe V1 plus grande offre aux applications de confidentialité et cryptographiques beaucoup plus d’espace sans augmenter leurs limites de calcul ou de compte. Solana met spécifiquement en avant les preuves ZK et les charges de travail de transfert confidentiel parmi les applications bénéficiaires.
 
Les transferts confidentiels Token-2022 illustrent pourquoi cela est important. Ces flux de travail peuvent impliquer des preuves ainsi que les instructions nécessaires pour établir le contexte, effectuer le transfert et nettoyer l'état associé. Avec une transaction plus importante, les opérations qui devaient autrefois être assemblées peuvent potentiellement s'exécuter en une seule action atomique, réduisant ainsi le nombre d'états intermédiaires que l'utilisateur ou le développeur doit gérer.

Opérations multisig et cryptographiques plus importantes

Les transactions multisig bénéficient également car les signatures consomment un espace sérialisé significatif. Une signature Ed25519 de 64 octets peut sembler négligeable isolément, mais une transaction nécessitant de nombreuses approbations indépendantes peut rapidement perdre une part importante de l'ancien enveloppe de 1 232 octets avant même de prendre en compte les instructions du programme et les adresses. V1 libère davantage d'espace pour des structures de gestion de trésorerie sophistiquées, de custody institutionnelle et d'autorisation.
 
Solana a également mentionné d'autres conceptions cryptographiques gourmandes en données, notamment les workflows liés à BLS et les schémas de signature avancés sur chaîne. Cela est important pour les applications institutionnelles, car les exigences complexes en matière d'autorisation, de garde et de confidentialité sont souvent bien plus exigeantes qu'un utilisateur particulier qui envoie des jetons entre deux wallets.

Workflow atomiques plus complexes

Peut-être que le plus grand avantage est l'atomicité. Une transaction atomique réussit dans son ensemble ou échoue dans son ensemble. Si une opération complexe doit être divisée en plusieurs transactions car la transaction d'origine est trop volumineuse, les développeurs peuvent avoir besoin d'un état temporaire, de confirmations supplémentaires ou de systèmes de regroupement pour coordonner les étapes.
 
Avec V1, certains flux de travail peuvent inclure davantage d'instructions et de données dans une seule transaction. La valeur réside donc non seulement dans le fait qu'une transaction contient plus d'informations, mais aussi dans le fait qu'une plus grande partie de la logique d'une application peut potentiellement partager le même cadre d'exécution tout-ou-rien.

Que signifie la transaction V1 pour la DeFi ?

Les applications DeFi interagissent fréquemment avec plusieurs programmes au sein d'une seule action utilisateur. Un échange sophistiqué peut impliquer un routeur de swap, un protocole de prêt, un ajustement de collatéral et une étape de règlement, tandis qu'une stratégie d'arbitrage ou de liquidation peut nécessiter de coordonner plusieurs actions avant que son économie ne fonctionne. Sous l'ancienne limite de octets, la sérialisation des transactions pouvait devenir un goulot d'étranglement, même lorsque le réseau disposait d'une capacité de calcul suffisante pour exécuter les instructions prévues.
 
V1 crée plus de place pour les itinéraires en plusieurs étapes, des logiques de validation supplémentaires et des instructions riches en données. Cela peut réduire la dépendance aux flux de travail fragmentés et diminuer le risque d'exécution partielle. Les routeurs et les systèmes de trading capables d'intégrer davantage de logique dans une seule transaction peuvent également offrir une expérience utilisateur plus fluide, car les utilisateurs ont besoin de moins de signatures et de confirmations pour certaines actions complexes. CoinDesk a souligné les trades en plusieurs étapes comme l'une des catégories d'applications immédiates bénéficiant de cette mise à niveau.
 
Cependant, l'amélioration a ses limites. Les octets de transaction, les unités de calcul et les verrous de compte sont des ressources différentes. Augmenter le plafond des octets ne confère pas à une application une puissance de calcul illimitée ni des comptes supplémentaires. L'analyse Solana V1 note spécifiquement que la limite inchangée de 64 comptes peut rester la contrainte déterminante pour les stratégies multi-pools ou multi-places.

La transaction V1 rendra-t-elle Solana plus rapide ou moins chère ?

V1 augmente-t-il le TPS de Solana ?

Pas 3,3 fois plus. La mise à niveau augmente la taille maximale d'une transaction individuelle, pas le nombre de transactions que Solana peut exécuter par seconde. Le débit de transactions dépend également des limites de calcul par bloc, de la contention sur les comptes, du réseau, de la composition des transactions et d'autres contraintes du protocole. Décrire V1 comme une « mise à niveau de 3,3x TPS » confond donc la capacité de transaction avec la taille de la transaction.
 
Solana a augmenté séparément sa limite de calcul par bloc de 60 millions à 100 millions d'unités de calcul, une expansion de 66 % activée sur le mainnet en juillet 2026. Cette mise à jour ajoute directement plus de marge de calcul par bloc et est distincte de la V1.
 
V1 peut encore améliorer l'efficacité au niveau de l'application. Si un flux de travail qui nécessitait autrefois trois transactions coordonnées peut désormais s'exécuter en une seule, l'utilisateur peut connaître moins d'étapes et moins de latence, même si le TPS annoncé du réseau n'a pas été multiplié par trois. Cette distinction est le meilleur moyen de décrire le bénéfice en performance.

La transaction V1 peut-elle réduire les frais ?

Pour certaines opérations complexes, éventuellement. Combiner plusieurs étapes en une seule transaction atomique peut réduire les signatures dupliquées, les confirmations répétées et autres surcoûts liés à la division d’un processus. Cela pourrait diminuer le coût total de l’accomplissement de l’ensemble de l’action.
 
Mais la mise à niveau ne réduit pas les frais de transaction de base de Solana de 3,3 fois. En fait, la documentation de Solana elle-même indique que les transactions plus importantes consomment plus de bande passante des validateurs et peuvent nécessiter des frais de priorité plus élevés pour être traitées que les transactions plus petites en concurrence avec une priorité similaire.
 
L'avantage en frais doit donc être évalué au niveau du flux de travail : une seule transaction plus importante pourrait coûter plus cher qu'un simple transfert, mais rester moins chère ou mieux adaptée opérationnellement que plusieurs petites transactions nécessaires pour accomplir la même tâche complexe.

Ce que les développeurs et les wallets doivent modifier

Pour les utilisateurs ordinaires, la transaction V1 devrait rester principalement invisible à moins que l'application qu'ils utilisent ne commence à en tirer parti. Pour les fournisseurs d'infrastructure, la transition nécessite une attention bien plus importante. Les wallets et les SDK doivent comprendre le nouveau format de sérialisation s'ils veulent créer ou signer des transactions V1, tandis que les services RPC, les Explorateurs et les indexeurs doivent être capables de décoder correctement cette nouvelle version.
 
Même les applications qui n’ont pas l’intention d’envoyer des transactions V1 peuvent les rencontrer en lisant des blocs ou des historiques de transactions. Les conseils de migration de Solana avertissent les systèmes qui lisent les transactions de prendre explicitement en charge la version 1 des transactions. Les systèmes qui font des hypothèses basées sur les structures V0 ou qui recherchent des instructions de budget de calcul traditionnelles risquent sinon d’échouer ou de signaler des informations ressources incorrectes.
 
Ce problème de compatibilité explique pourquoi l'activation a été déplacée à l'Époque 1035 après que les équipes de l'écosystème aient demandé plus de temps pour les tests et l'intégration. La question immédiate après le lancement n'est donc pas simplement de savoir combien de développeurs commenceront à créer de grandes transactions. Il s'agit de savoir si les wallets, les fournisseurs RPC, les indexeurs, les sponsors de frais et les plateformes d'analyse comprennent correctement V1 dès qu'il commence à apparaître en production.

Que signifie cette mise à jour pour SOL ?

La transaction V1 est fondamentalement positive pour les capacités techniques de Solana, car elle élargit les types d'applications que les développeurs peuvent raisonnablement construire. Plus de place pour les preuves, les structures multisig institutionnelles, les protocoles DeFi sophistiqués et les flux de travail axés sur la confidentialité peut renforcer le cas de Solana en tant qu'infrastructure pour des applications allant au-delà des simples transferts de jetons. C'est un développement fondamental significatif, mais il ne crée pas de relation mécanique entre la taille de la transaction et le prix du jeton SOL.
 
La réponse immédiate du marché a été relativement modeste par rapport à l'ampleur du titre technique. SOL était négocié autour de 102 $ le 15 septembre, les données de prix indiquant qu'il était environ 35 % au-dessus de son niveau un mois plus tôt, mais toujours soumis à la volatilité plus large du marché des cryptomonnaies.
 
Les investisseurs peuvent donc obtenir des informations plus utiles en observant l'adoption plutôt que la bougie des prix du premier jour. Les questions pertinentes sont de savoir si les transactions V1 deviennent courantes, si les développeurs lancent des applications auparavant impraticables, et si l'utilisation de DeFi, de la confidentialité, des paiements ou institutionnelle s'étend en conséquence. La valeur économique des 2 864 octets supplémentaires dépend en fin de compte de ce que les développeurs construisent avec eux.

Comment V1 s'intègre dans la feuille de route de mise à niveau plus large de Solana

La transaction V1 n'est qu'une partie d'un effort plus large visant à éliminer les goulots d'étranglement sur Solana. Le réseau a déjà augmenté la capacité de calcul des blocs à 100 millions de CUs, introduit progressivement des paramètres de loyer nettement plus bas, et travaille à des durées de slot plus courtes. Agave 4.3 devrait apporter un autre changement majeur avec Alpenglow, l'architecture de consensus de prochaine génération de Solana, visant une finalité considérablement plus rapide.
Mettre à niveau Objectif principal Direction actuelle
100M blocs CU Augmenter la limite de calcul de bloc de 60M à 100M CU En direct sur le mainnet
Transaction V1 Augmenter la taille maximale de transaction de 1 232 à 4 096 octets En direct sur le mainnet
Loyer réduit Réduction de jusqu'à 90 % des paramètres de location de stockage sur chaîne Déploiement progressif
Temps de créneau réduits Passez des créneaux de 400 ms à ceux de 200 ms Déploiement des fonctionnalités
Alpenglow Nouveau système de consensus visant une finalité d'environ 150 ms Planifié avec Agave 4.3
Ces améliorations répondent à différentes contraintes. Des blocs plus grands créent une capacité de calcul supplémentaire, V1 augmente la flexibilité des transactions, une location plus faible réduit les coûts de stockage sur chaîne, des créneaux plus courts améliorent la latence, et Alpenglow cible le consensus et la finalité. Considérer V1 comme une partie de cette architecture plus large est plus précis que de la présenter comme une seule amélioration qui rendrait soudainement tous les aspects de Solana trois fois meilleurs.
 
La stratégie plus large consiste à offrir aux applications plus de flexibilité à plusieurs niveaux simultanément. Si elle réussit, Solana ne se contentera pas de traiter davantage d'activités ; les développeurs devraient rencontrer moins de contraintes au niveau du protocole lors de la conception d'applications complexes.

Que devons-nous surveiller après le lancement du mainnet ?

La première métrique à surveiller est simplement l'adoption de V1. Étant donné que le format est facultatif, l'activation sur mainnet ne nous indique pas à quelle vitesse les wallets, les protocoles DeFi, les projets de confidentialité ou les applications institutionnelles l'utiliseront réellement. Les développeurs ont de solides raisons de rester sur les formats existants lorsque les transactions sont déjà petites et simples ; l'adoption de V1 devrait donc initialement se concentrer sur les applications où sa capacité supplémentaire résout un problème réel.
 
La fiabilité de l’infrastructure sera tout aussi importante. Le décodage des transactions, la signature du wallet, la compatibilité RPC, l’estimation des frais et l’indexation doivent tous fonctionner correctement à mesure que l’activité V1 augmente. Il sera également utile de surveiller si les transactions de plus grande taille exercent une pression mesurable sur la bande passante des validateurs ou attirent des frais de priorité plus élevés, comme le prévoit la documentation de conception de Solana.
 
À plus long terme, les indicateurs les plus intéressants seront spécifiques aux applications : la croissance des transferts confidentiels et des charges de travail ZK, des conceptions multisig plus sophistiquées, des itinéraires DeFi nécessitant moins de transactions fragmentées, et des flux de travail institutionnels qui auraient été impraticables avec 1 232 octets. La question après le lancement n’est plus de savoir si Solana peut prendre en charge des transactions de 4 096 octets, mais si les développeurs trouvent suffisamment de raisons pertinentes pour les utiliser.

🔥 Au-delà des titres : ce que KuCoin 5.0 signifie pour vous

Les actualités du marché évoluent rapidement — mais où vous agissez dessus compte tout autant. Ce octobre, KuCoin lance KuCoin 5.0, transformant KuCoin en une plateforme entièrement重构. Voici ce qui change réellement pour vous :
  • Un seul compte pour tout. Les anciennes plateformes répartissaient votre argent entre des comptes séparés « spot », « marge » et « futures » et s’attendaient à ce que vous compreniez pourquoi. Le compte unifié de KuCoin 5.0 élimine cela complètement — déposez une fois, et tout est simplement disponible.
  • Actions, indices et matières premières. KuCoin 5.0 s'étend au-delà du crypto vers les marchés mondiaux. Lorsque le crypto stagne et que les actions progressent (ou l'inverse), vous effectuez une rotation en quelques minutes au lieu d'ouvrir un compte de courtage et d'attendre des jours pour les voies monétaires.
  • Actifs du monde réel (RWA). Une exposition tokenisée à des actifs traditionnels comme les matières premières, directement dans votre compte crypto. L’un des segments à la croissance la plus rapide de la finance mondiale n’est plus réservé aux institutions — vous y accédez depuis le même solde que celui que vous utilisez pour trader.
  • Gagnez tout en apprenant. Pas prêt à trader ? KCUSD permet à vos stablecoins de générer des intérêts quotidiens, avec un auto-compound. La méthode la moins stressante pour faire travailler vos dépôts inactifs avec un rendement de 4 %.
  • Un assistant IA en langage simple. Posez des questions, obtenez du contexte sur le marché, comprenez ce que vous voyez — intégré à la plateforme, aucun jargon requis.
  • Une application qui ne submerge pas. Plus rapide, plus propre et cohérente — intuitive dès le premier toucher, sans besoin de tutoriel.
  • Sécurité que vous pouvez vérifier, et non seulement confier. Une entité européenne autorisée MiCAR, Proof of Reserves que vous pouvez vérifier vous-même, et une sécurité certifiée au niveau international (SOC 2 Type II, ISO 27001:2022).
 
Créez votre compte en quelques minutes — et commencez sur la plateforme conçue pour où va la crypto, pas où elle en est venue.

Conclusion

La transaction Solana V1 semble simple lorsqu'elle est réduite à un seul chiffre : le réseau a augmenté sa taille maximale de transaction de 1 232 octets à 4 096 octets. Mais le changement le plus important est ce que ces octets supplémentaires permettent. Des preuves, des signatures, des données de configuration et plusieurs instructions d'application peuvent désormais être intégrées dans une limite d'exécution atomique plus grande, remplaçant potentiellement certaines des contournements que les développeurs utilisaient auparavant pour contourner l'ancienne limite.
 
V1 ne rend pas Solana 3,3 fois plus rapide, ne supprime pas les contraintes de calcul ni ne garantit des frais plus bas. Il élimine plutôt un goulot d’étranglement de conception d’applications de plus en plus important, tout en introduisant de nouveaux compromis autour de la représentation des adresses, de la compatibilité avec l’infrastructure et de la bande passante du réseau. Si le nouveau format aide les développeurs à simplifier les applications ZK, les flux de travail institutionnels et les transactions DeFi complexes, son importance à long terme pourrait ne pas provenir du chiffre emblématique de 4 096 octets, mais des applications qui étaient difficiles à construire avant son apparition.

FAQ

Les utilisateurs peuvent-ils encore envoyer des transactions Solana héritées ?

Oui. Les transactions héritées et V0 restent prises en charge après le déploiement de V1. La transaction V1 est facultative, donc les applications qui n'ont pas besoin de l'enveloppe de transaction plus grande peuvent continuer à utiliser les formats existants.

Ai-je besoin d’un nouveau wallet pour la transaction V1 ?

Pas nécessairement. Les utilisateurs ordinaires peuvent continuer à utiliser des wallets qui reposent sur des transactions Legacy ou V0. Toutefois, les wallets qui souhaitent construire, décoder ou signer des transactions V1 doivent ajouter un support explicite pour le nouveau format.

V1 augmente-t-il le nombre de comptes par transaction ?

Pas automatiquement. Solana applique actuellement une limite de 64 comptes à l'exécution, qui reste séparée de la nouvelle limite de taille de transaction de 4 096 octets. Une fonctionnalité future pourrait augmenter la limite de verrouillage des comptes, mais cela ne fait pas partie de l'augmentation de taille de la V1 elle-même.

Toutes les transactions V1 font-elles 4 096 octets ?

Non. Le chiffre représente un maximum, pas une taille requise. Une transaction V1 peut être beaucoup plus petite que 4 096 octets, et les développeurs n'ont aucune raison de remplir l'espace inutilisé simplement parce qu'il est disponible.

Qu'est-ce que SIMD-0296 et SIMD-0385 ?

SIMD-0296 est la proposition d'amélioration Solana associée à l'augmentation de la taille maximale des transactions, tandis que SIMD-0385 spécifie le format Transaction V1 qui prend en charge l'enveloppe plus grande et la structure de transaction révisée.

Les transactions V1 peuvent-elles utiliser des tables d'adresses ?

Non. Contrairement à V0, V1 ne prend pas en charge les tables de recherche d'adresses. Il inclut directement les adresses de compte dans la transaction, simplifiant l'ingestion des transactions mais consommant plus d'espace sérialisé pour les charges de travail intensives en comptes.
 
Clause de non-responsabilité : Cet article a uniquement une finalité informative et ne constitue pas un conseil en investissement. Les crypto-actifs peuvent être très volatils, et les conditions du marché, la liquidité des jetons et l'évolution des projets peuvent changer rapidement. Les lecteurs doivent effectuer leurs propres recherches et évaluer leur tolérance au risque avant de prendre des décisions financières.

Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.