Solana vient de tripler sa capacité de transactions, quelle sera la prochaine étape ?

Solana a déployé la fonctionnalité Transaction V1 sur son réseau principal mardi, permettant ainsi d'ajouter davantage de données à chaque transaction. Les développeurs disposeront donc d'une plus grande latitude pour réaliser des actions complexes au sein d'un même processus atomique.

Cette évolution sera particulièrement pertinente pour les développeurs de la finance décentralisée DeFi , les fournisseurs de portefeuilles, les indexeurs et les opérateurs RPC. Cette nouvelle fonctionnalité pourrait également impacter d'autres projets liés aux actifs tokenisés et aux solutions de paiement.

La fonctionnalité txv1 a été déployée au début de l'époque 1035 vers 01h00 UTC le 15 septembre, comme indiqué sur la page de mise à niveau Solana , et la transaction V1 est maintenant en service sur le réseau principal, le réseau de test et le réseau de développement.

De 1 232 octets à 4 096

La première limitation concerne la taille des transactions. Solana a doublé la taille maximale des transactions sérialisées, la faisant passer de 1 232 octets à 4 096 octets, ce qui augmente l'espace disponible (environ 3,3 fois plus).

Le format de la nouvelle transaction a été defidans SIMD-0296, tandis que le format de message V1 est basé sur SIMD-0385.

Jusqu'à présent, la limite dans Solana était basée sur des limitations MTU réseau conservatrices. Désormais, en s'affranchissant de la limite stricte sur la taille des flux dans QUIC, des transactions plus importantes sont possibles.

Cet espace supplémentaire sera utile pour gérer les charges de travail impliquant un grand nombre de données transactionnelles, comme les preuves à divulgation nulle de connaissance, les opérations multisignatures de grande envergure et les signatures incluant BLS. Selon Cryptopolitan, la version 1 a été lancée sur le réseau de test à l'époque 1025, le 1er septembre, permettant ainsi aux fournisseurs d'infrastructure de se préparer au lancement sur le réseau principal.

Pourquoi une seule transaction atomique est importante

Les développeurs qui ont constaté que Solana imposait une limite à la taille des transactions pouvaient, dans certains cas, scinder leurs opérations en une série de transactions ou utiliser des bundles Jito.

Mais comme l'explique le document SIMD-0296, un bundle n'est pas équivalent à une transaction native lorsqu'on parle d'atomicité au niveau du protocole.

Avec la version 1 de la transaction, il est possible d'inclure davantage d'instructions et de données dans une même transaction. Ainsi, le routage, la vérification et le traitement par lots fonctionnent ou échouent simultanément, au lieu d'être effectués dans des transactions distinctes.

Dans certains cas, un nombre réduit de signatures et de confirmations serait nécessaire pour la réalisation d'une opération.

Le compromis de la table de consultation d'adresses

La version V1 modifie également la façon dont les transactions gèrent les ressources et les références de compte.

Les paramètres de limite de calcul et de frais prioritaires ont été déplacés des instructions ComputeBudget vers les paramètres de transaction, permettant ainsi aux fournisseurs d'infrastructure d'accéder facilement à ces paramètres.

Les transactions V1 sont également supprimées des tables de recherche d'adresses car les comptes référencés sont inclus dans la transaction.

Bien que cela contribue à simplifier la transaction, cela se fait au détriment de la taille de la transaction, car une table de recherche d'adresses v0 ne nécessite qu'un index d'un octet, tandis qu'une clé publique en ligne nécessite 32 octets.

L'analyse des tables de correspondance d'adresses de Solana a révélé que 62 % des transactions v0 utilisaient au moins une table de correspondance d'adresses ; par conséquent, les transactions denses utilisant plusieurs tables de correspondance d'adresses augmentent leur taille de plus de 1 500 octets. La limite de 64 comptes reste inchangée.

Où V1 s'inscrit dans la stratégie Solanaen matière de finance tokenisée

Cette mise à jour intervient alors que Solana renforce sa position dans la finance décentralisée. Selon DeFiLlama, la valeur totale bloquée dans Solanade DeFi le secteur 5.95$ milliards de dollars, et son volume d'échanges décentralisés sur 24 heures avoisine les 1.79$ .

Le rapport d'août de Solana indiquait également que la valeur des actifs réels sur le réseau avait dépassé 4$ et était répartie sur plus de 350 000 adresses. Par ailleurs, xStocks gérait plus de 500$ d'actifs.

Le fait qu'une plus grande capacité de transaction soit disponible ne signifie pas nécessairement qu'il en résultera une adoption accrue.

Galaxy Research a constaté qu'une grande partie de la valeur immobilisée dans les jetons de Solanan'est toujours pas utilisée, tandis que les plateformes concurrentes restent en tête dans certains secteurs à forte croissance.

La version V1 élargit ainsi la gamme d'applications que les développeurs peuvent créer sur Solana. La question plus complexe est cependant de savoir si les utilisateurs, la liquidité et l'activité transactionnelle 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 prioritaires V1 depuis `transactionConfig`. Les validateurs et les opérateurs RPC doivent utiliser Agave v4.2.2 ou une version ultérieure. Les expéditeurs V1 doivent également définir explicitement les limites de calcul et de compte chargé et utiliser le format Base64 pour les transactions supérieures à 1 232 octets. Les fournisseurs de portefeuilles, quant à eux, ne doivent annoncer la prise en charge de la version V1 qu’après avoir confirmé que leur logiciel peut analyser et signer correctement le nouveau format, conformément aux Solanarecommandations de.