ActualitésCryptoSolana active Transaction V1 et porte la taille maximale des transactions à 4 096 octets

Solana active Transaction V1 et porte la taille maximale des transactions à 4 096 octets

Auteur: Cryptopolitan·

Points clés

  • Transaction V1 a été activée au début de l’époque 1035, vers 01:00 UTC le 15 septembre.
  • La taille maximale d’une transaction sérialisée est désormais de 4 096 octets, soit environ 3,3 fois l’ancienne limite de 1 232 octets.
  • La mise à niveau permet d’exécuter le routage, la vérification des preuves et le regroupement au sein d’une seule transaction atomique au niveau du protocole.
  • V1 inclut directement les références de comptes au lieu d’utiliser les Address Lookup Tables, ce qui peut ajouter plus de 1 500 octets aux transactions denses, tandis que la limite reste fixée à 64 comptes.
  • Les validateurs et les opérateurs RPC doivent utiliser Agave v4.2.2 ou une version ultérieure, tandis que les lecteurs RPC, les indexeurs, les émetteurs et les portefeuilles nécessitent une prise en charge et une configuration spécifiques à V1.
Solana active Transaction V1 et porte la taille maximale des transactions à 4 096 octets

Solana a activé la fonctionnalité Transaction V1 sur son réseau principal mardi, permettant d’inclure davantage de données dans chaque transaction. Cette mise à niveau offre aux développeurs une capacité supplémentaire pour exécuter des actions complexes au sein d’un seul processus atomique et concerne les développeurs de la DeFi, les fournisseurs de portefeuilles, les indexeurs et les opérateurs RPC. Elle pourrait également affecter les projets travaillant avec des actifs tokenisés et des solutions de paiement.

Selon la page de mise à niveau de Solana, le feature gate txv1 a été déployé au début de l’époque 1035, vers 01:00 UTC le 15 septembre. Transaction V1 est désormais disponible sur le réseau principal, le réseau de test et le réseau de développement de Solana.

La taille des transactions passe de 1 232 à 4 096 octets

Le changement le plus visible concerne l’augmentation de la taille maximale d’une transaction sérialisée. Solana a relevé la limite de 1 232 à 4 096 octets, offrant environ 3,3 fois plus d’espace pour les données de transaction.

Le format de la nouvelle transaction a été défini dans SIMD-0296, tandis que le format de message V1 repose sur SIMD-0385. Auparavant, la limite de taille des transactions de Solana était liée aux contraintes prudentes de l’unité de transmission maximale, ou MTU, du réseau. Transaction V1 s’affranchit de la limite stricte de taille des flux imposée par QUIC, permettant des transactions plus volumineuses.

Cette capacité supplémentaire doit prendre en charge les charges de travail nécessitant d’importants volumes de données de transaction, notamment les preuves à divulgation nulle de connaissance, les opérations multisig de grande ampleur et les signatures utilisant BLS. Comme l’a précédemment rapporté Cryptopolitan, V1 a été lancée sur le réseau de test à l’époque 1025, le 1er septembre, donnant aux fournisseurs d’infrastructure le temps de se préparer au déploiement sur le réseau principal.

Pourquoi une seule transaction atomique est importante

Avant la mise à niveau, les développeurs confrontés à la limite de taille des transactions de Solana pouvaient, dans certains cas, répartir leurs opérations sur plusieurs transactions ou utiliser des bundles Jito. Toutefois, l’explication fournie dans SIMD-0296 indique qu’un bundle n’est pas équivalent à une transaction native lorsque l’atomicité est considérée au niveau du protocole.

Transaction V1 permet d’intégrer davantage d’instructions et de données dans une seule transaction. Ainsi, le routage, la vérification des preuves et le regroupement peuvent soit réussir tous ensemble, soit échouer tous ensemble, au lieu d’être exécutés dans des transactions distinctes. Selon l’opération, cela pourrait également réduire le nombre de signatures et de confirmations nécessaires.

Le compromis des Address Lookup Tables

Transaction V1 modifie également la manière dont les transactions gèrent les ressources et les références de comptes. Les paramètres de limite de calcul et de frais prioritaires ont été déplacés des instructions ComputeBudget vers les paramètres de la transaction, ce qui rend ces paramètres plus facilement accessibles aux fournisseurs d’infrastructure.

Les transactions V1 n’utilisent pas les Address Lookup Tables, car les comptes référencés sont inclus directement dans la transaction. Cette approche simplifie la structure de la transaction, mais peut en augmenter la taille. Une Address Lookup Table v0 ne nécessite qu’un index d’un octet, tandis qu’une clé publique intégrée nécessite 32 octets.

Une analyse des Address Lookup Tables de Solana a révélé que 62 % des transactions v0 utilisaient au moins une Address Lookup Table. Par conséquent, les transactions denses utilisant plusieurs tables pourraient augmenter de plus de 1 500 octets lorsque les références de comptes sont incluses directement. La limite reste inchangée à 64 comptes.

Le rôle de V1 dans l’expansion de la finance tokenisée de Solana

La mise à niveau intervient alors que Solana renforce son rôle dans la finance on-chain. Selon DeFiLlama, la valeur totale verrouillée dans le secteur DeFi de Solana s’élève à près de 5,95 milliards de dollars, tandis que le volume de ses échanges décentralisés sur 24 heures atteint environ 1,79 milliard de dollars.

Le bilan d’août de Solana indiquait également que la valeur des actifs du monde réel sur le réseau avait dépassé 4 milliards de dollars et était répartie entre plus de 350 000 adresses. En outre, xStocks avait accumulé plus de 500 millions de dollars d’actifs sous gestion.

Une capacité de transaction accrue ne garantit pas à elle seule une adoption plus importante. Galaxy Research a constaté qu’une part importante de la valeur détenue dans les tokens de Solana reste inutilisée, tandis que les plateformes concurrentes continuent de dominer certains secteurs en forte expansion. Transaction V1 élargit l’éventail des applications que les développeurs peuvent créer sur Solana, mais la réaction des utilisateurs, de la liquidité et de l’activité transactionnelle reste une question ouverte.

Changements requis pour les opérateurs et les développeurs

Les lecteurs RPC doivent définir maxSupportedTransactionVersion: 1 pour getTransaction et getBlock. Les indexeurs doivent lire les limites de calcul et les frais prioritaires de V1 depuis transactionConfig.

Les validateurs et les opérateurs RPC doivent utiliser Agave v4.2.2 ou une version ultérieure. Les émetteurs de transactions V1 doivent définir explicitement les limites de calcul et de comptes chargés, et utiliser base64 pour les transactions de plus de 1 232 octets.

Les fournisseurs de portefeuilles ne doivent annoncer la prise en charge de V1 qu’après avoir confirmé que leurs logiciels peuvent analyser et signer correctement le nouveau format, conformément aux recommandations de mise à niveau de Solana. Le rapport original a été publié par Cryptopolitan.