Solana a activé sa fonctionnalité txv1 sur le mainnet vers 01:00 UTC le 15 septembre, au début de l’époque 1035. La mise à niveau porte la taille maximale des transactions de 1 232 octets à 4 096 octets, soit une capacité plus de trois fois supérieure à la précédente.

Cet espace supplémentaire est accessible via le format de transaction V1. Les applications doivent ajouter explicitement sa prise en charge avant de l’utiliser, tandis que les transactions legacy et V0 restent entièrement prises en charge dans les limites qui leur sont propres.

Une transaction plus volumineuse ne signifie pas un transfert de SOL plus important

La nouvelle limite concerne la quantité d’informations transportées par une transaction, et non le montant de SOL qu’un utilisateur peut envoyer. Un transfert standard nécessite généralement peu de données, car il ne contient qu’un nombre limité de comptes, d’instructions et de signatures.

Les opérations plus avancées peuvent nécessiter plusieurs instructions, de nombreuses adresses de comptes, plusieurs approbations ou des preuves cryptographiques. Lorsque ces informations dépassaient l’ancienne limite, les développeurs devaient réduire la charge utile, répartir l’opération entre plusieurs transactions ou utiliser des solutions comme les tables de recherche d’adresses et les lots de transactions.

Solana peut traiter en parallèle des transactions sans lien entre elles, comme l’explique ce guide sur le fonctionnement de Solana. V1 ne modifie pas ce modèle d’exécution. Il offre plutôt davantage d’espace lorsqu’une même opération doit contenir plusieurs éléments liés.

Lorsque ces instructions sont soumises dans une seule transaction atomique, elles sont traitées comme un ensemble. L’opération complète réussit ou ses modifications sont annulées, ce qui évite qu’une partie seulement des instructions ne soit inscrite dans le registre.

Opérations susceptibles de bénéficier de cet espace supplémentaire

• Échanges groupés : une application de trading peut regrouper des instructions liées dans une seule transaction au lieu de coordonner plusieurs confirmations.
• Approbations multisig importantes : les portefeuilles de trésorerie et d’entreprise peuvent intégrer davantage de signatures et d’informations de comptes lorsque plusieurs personnes doivent autoriser une opération.
• Preuves à divulgation nulle de connaissance : les applications peuvent prouver qu’une condition est remplie sans révéler toutes les informations sous-jacentes, mais la preuve elle-même peut nécessiter un espace important dans la transaction.
• Schémas de signature on-chain : certains formats de signatures cryptographiques généraient auparavant davantage de données qu’une seule transaction Solana ne pouvait en contenir.

La Solana Foundation cite les transferts confidentiels, les multisigs imbriqués, les opérations groupées et certains schémas de signature on-chain parmi les utilisations potentielles du nouveau format.

La plupart des utilisateurs de portefeuilles n’ont aucune mesure à prendre

L’activation n’oblige pas les utilisateurs à déplacer leurs SOL, à créer une autre adresse ou à convertir un compte existant. Les applications qui continuent d’utiliser les transactions legacy ou V0 devraient fonctionner comme avant la mise à niveau.

Les utilisateurs auront besoin d’un portefeuille compatible lorsqu’une application choisira d’envoyer une transaction V1. La mise à jour des logiciels de portefeuille permettra d’accéder à cette prise en charge à mesure que les fournisseurs l’introduiront, mais les applications doivent toujours vérifier la compatibilité avant de demander à un portefeuille de signer.

Pour les utilisateurs, le changement pourrait à terme se traduire par un nombre réduit de demandes d’approbation lors d’opérations complexes. Un service qui nécessitait auparavant plusieurs transactions liées pourrait présenter une seule demande et attendre une seule confirmation.

Les développeurs et les indexeurs doivent mettre leurs logiciels à jour

L’envoi de transactions V1 est facultatif, mais leur lecture peut créer des problèmes de compatibilité pour les infrastructures qui n’ont pas été mises à jour.

Les services RPC qui récupèrent des transactions ou des blocs doivent définir maxSupportedTransactionVersion: 1. Sans ce paramètre, une demande portant sur une transaction V1 peut renvoyer une erreur. Une seule transaction non prise en charge peut également faire échouer la demande d’un bloc entier.

Les indexeurs font face à un risque différent. V1 stocke sa limite de calcul, sa limite de données des comptes chargés et ses frais prioritaires dans transactionConfig, plutôt que dans les instructions Compute Budget. Les logiciels qui continuent à analyser l’ancien emplacement peuvent classer incorrectement la transaction ou afficher à zéro ses limites de ressources et ses frais prioritaires.

Les applications qui créent des transactions V1 doivent définir explicitement leurs limites d’unités de calcul et de données des comptes chargés. Ces deux valeurs sont par défaut égales à zéro dans le nouveau format ; les omettre peut donc entraîner l’échec de la transaction avant son exécution.

Les transactions de plus de 1 232 octets doivent également être soumises avec un encodage base64. Le chemin de soumission base58 conserve l’ancienne limite de taille.

V1 ajoute de l’espace, mais modifie d’autres limites

V1 n’est pas simplement V0 avec une charge utile plus importante. Il peut inclure directement jusqu’à 64 adresses de comptes dans la transaction, mais il ne prend pas en charge les tables de recherche d’adresses. Les adresses de comptes en double sont également rejetées.

Ces règles offrent aux équipes chargées des applications un choix de conception différent. V0 reste utile lorsque les tables de recherche constituent un moyen efficace de référencer les comptes, tandis que V1 est destiné aux opérations qui bénéficient davantage d’un espace accru pour les instructions, les signatures ou les preuves.

Un paiement simple a peu de chances de tirer profit du nouveau format. V1 est davantage adapté aux applications capables de remplacer une séquence complexe ou d’intégrer des données qui ne pouvaient auparavant pas tenir dans une seule transaction.

Les transactions plus volumineuses peuvent entraîner des frais plus élevés

L’augmentation de la limite en octets ne rend pas automatiquement toutes les transactions V1 plus coûteuses. Le coût dépend des ressources demandées, du nombre de signatures et des frais prioritaires sélectionnés par l’application.

Les messages plus volumineux consomment effectivement davantage de bande passante des validateurs. La documentation de Solana indique que l’ordonnanceur devrait exiger des frais prioritaires plus élevés pour une transaction volumineuse que pour une transaction plus petite recherchant un niveau de priorité équivalent, notamment lorsque l’espace disponible dans les blocs est très demandé.

V1 exprime également les frais prioritaires sous la forme d’un montant total en lamports. V0 utilise un prix par unité de calcul, ce qui signifie que les plateformes d’analyse doivent normaliser les deux formats avant de les comparer.

La demande en frais prioritaires peut évoluer fortement avec l’activité du réseau, comme le montrent les données récentes sur les frais de Solana. Les développeurs devront donc mettre en balance la commodité d’une opération plus importante et le coût de son inclusion pendant les périodes de congestion.

L’activation lance le test d’adoption

La mise à niveau supprime une contrainte qui influençait auparavant la conception des applications Solana, mais l’activation sur le mainnet ne garantit pas une utilisation généralisée. Les portefeuilles, les fournisseurs RPC, les indexeurs et les bibliothèques applicatives doivent gérer correctement le nouveau format avant que les développeurs puissent s’y fier dans des produits destinés aux utilisateurs.

Les premiers avantages pourraient apparaître dans les charges de travail qui rencontrent déjà des difficultés avec l’ancienne limite, notamment les transferts confidentiels, les dispositifs multisig institutionnels et les applications comportant de nombreuses instructions. Pour les transferts ordinaires, les formats établis restent l’option la plus simple.

L’importance de V1 dépendra de la capacité à regrouper ces charges de travail dans une transaction atomique et à générer suffisamment d’économies en matière de coordination, de signatures et de tentatives échouées pour justifier les mises à jour nécessaires de l’infrastructure.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou en investissement. La compatibilité des portefeuilles, la prise en charge par les applications et les frais de transaction peuvent évoluer.

Source : Coindoo