Solana a implémenté la fonctionnalité Transaction V1 sur son mainnet mardi, rendant possible l’ajout de davantage de données à chaque transaction. Cela offrira aux développeurs plus d’espace pour mener à bien des actions complexes dans un seul processus atomique.
Le développement sera très pertinent pour les développeurs du secteur DeFi, les fournisseurs de portefeuilles, les indexeurs et les opérateurs RPC. La nouvelle fonctionnalité peut affecter d’autres projets qui traitent des actifs tokenisés et des solutions de paiement.
Le déploiement de l’option (feature gate) txv1 a été effectué au début de l’époque 1035, vers 01:00 UTC le 15 septembre, comme indiqué sur la page de mise à niveau de Solana, et Transaction V1 est désormais en ligne sur le mainnet, le testnet et le devnet.
De 1 232 octets à 4 096
La première est une limitation de taille de transaction. Désormais, Solana a doublé la taille maximale des transactions sérialisées, passant de 1 232 octets à 4 096 octets, ce qui offre davantage d’espace pour les transactions : environ trois fois et demie plus d’espace.
Le format de la nouvelle transaction a été défini dans SIMD-0296, tandis que le format de message V1 s’appuie sur SIMD-0385.
Jusqu’à présent, la limite de Solana reposait sur des contraintes MTU réseau conservatrices. Désormais, se détacher de la limite stricte de taille des flux dans QUIC permet des transactions plus volumineuses.
L’espace supplémentaire sera utile pour traiter des types de charges de travail impliquant beaucoup de données de transaction, comme des preuves à connaissance zéro, de très grosses opérations multisig et des signatures, y compris BLS. Comme l’a rapporté Cryptopolitan, V1 a été lancée sur le testnet à l’époque 1025, le 1er septembre, donnant ainsi aux fournisseurs d’infrastructure le temps de se préparer au lancement sur le mainnet.
Solana Transaction V1 vs Legacy : explication de la mise à niveau de 4 096 octets
Pourquoi une transaction atomique compte
Les développeurs qui ont découvert que Solana imposait un plafond à la taille des transactions ont, dans certains cas, pu scinder leurs opérations en une série de transactions ou utiliser des bundles Jito.
Comme l’explique la note SIMD-0296, un bundle n’est pas équivalent à une transaction native lorsqu’on discute de l’atomicité au niveau du protocole.
Avec la transaction V1, davantage d’instructions et de données peuvent être placées dans une transaction. Ainsi, l’acheminement, la vérification des preuves et le regroupement fonctionneront tous ou échoueront tous, au lieu d’être effectués dans des transactions distinctes.
Dans certains cas, un nombre moins élevé de signatures et de confirmations serait nécessaire pour les performances d’une opération.
L’arbitrage Address Lookup Table
V1 modifie également la manière dont les transactions gèrent les ressources et les références de comptes.
À l’intérieur de la transaction Solana V1 : nouvelle mise en page expliquée
Les paramètres de limite de calcul et de frais de priorité ont été déplacés des instructions ComputeBudget vers les paramètres de la transaction, permettant ainsi aux fournisseurs d’infrastructure d’accéder facilement à ces réglages.
Les transactions V1 sont aussi débarrassées des Address Lookup Tables, car les comptes référencés sont inclus dans la transaction.
Même si cela aide à simplifier la transaction, cela se fait au détriment de sa taille, car une Address Lookup Table v0 ne nécessitera qu’un index d’un octet, tandis qu’une clé publique incluse nécessite 32 octets.
Il a été constaté, grâce à l’analyse des Address Lookup Tables de Solana, que 62 % des transactions v0 utilisaient au moins une Address Lookup Table ; ainsi, des transactions denses utilisant plus d’une Address Lookup Table augmenteront la taille de la transaction de plus de 1 500 octets. La limite de 64 comptes reste la même.
Où V1 s’insère dans l’orientation « finance tokenisée » de Solana
La mise à niveau a lieu à un moment où Solana renforce sa position dans la finance on-chain. D’après DeFiLlama, la valeur totale immobilisée dans le secteur DeFi de Solana atteint près de 5,95 milliards de dollars, et son volume sur les échanges décentralisés (sur 24 heures) est d’environ 1,79 milliard de dollars.
Le récapitulatif d’août pour Solana indiquait aussi que la valeur des actifs du monde réel sur le réseau avait dépassé 4 milliards de dollars et était détenue sur plus de 350 000 adresses. De plus, xStocks avait réuni plus de 500 millions de dollars d’actifs sous gestion.
Le fait que davantage de capacité de transaction soit disponible ne signifie pas pour autant qu’une adoption plus large s’ensuivra.
Galaxy Research a observé qu’une large part de la valeur liée aux tokens de Solana n’est toujours pas utilisée, tandis que des plateformes concurrentes continuent d’être en tête dans certains domaines connaissant une croissance rapide.
Ainsi, V1 élargit la gamme d’applications que les développeurs peuvent créer sur Solana. La question, toutefois, est de savoir si les utilisateurs, la liquidité et l’activité de transaction suivront.
Que doivent faire les opérateurs maintenant ?
Les lecteurs RPC doivent définir maxSupportedTransactionVersion : 1 pour getTransaction et getBlock, tandis que les indexeurs doivent lire les limites de calcul et les frais de priorité V1 depuis transactionConfig. Les validateurs et opérateurs RPC doivent exécuter Agave v4.2.2 ou une version ultérieure. Les expéditeurs V1 doivent aussi définir explicitement les limites de calcul et de compte chargé et utiliser base64 pour les transactions de plus de 1 232 octets. Les fournisseurs de portefeuilles, quant à eux, doivent annoncer la prise en charge de V1 uniquement après avoir confirmé que leur logiciel peut analyser correctement et signer le nouveau format, conformément aux recommandations de mise à niveau de Solana.
Si vous lisez ceci, vous êtes déjà en avance. Restez avec nous grâce à notre newsletter.