Préparation à l'extension de la limite de transaction de Solana v1 à 4096 octets

Solana (SOL) se prépare à une mise à niveau du format de transaction v1, augmentant la taille maximale d'une transaction de 1 232 octets à 4 096 octets. Ce changement technique permettra de traiter des transactions environ 3,3 fois plus grandes en une seule fois.

La Fondation Solana a classé cette mise à jour dans le document officiel comme "Taille de transaction plus grande" sous "Activation de fonctionnalité en attente". Ce changement repose sur SIMD-0296 et SIMD-0385, et bien que le tableau de bord de mise à niveau officiel indique qu'Agave 4.2 sera distribué en août 2026, la fonctionnalité d'augmentation de la taille des transactions reste en attente d'activation.

Le cœur de cette mise à niveau est la limite de transaction. La limite de taille de transaction actuelle de Solana est de 1 232 octets, et le document SIMD-0296 explique que cette limite provient de la conception de l'IPv6 MTU de 1 280 octets. En excluant les en-têtes, il restait 1 232 octets pour la charge utile de la transaction.

Solana a rapporté qu'avec l'introduction de QUIC, un environnement permettant d'envoyer des transactions plus grandes a été créé, et a proposé une nouvelle limite de 4 096 octets. Avec le changement de la structure de transmission du réseau, il y a un mouvement pour réajuster la limite de transaction qui était auparavant contrainte par la taille des paquets.

Le format v1 ne remplace pas le v0 existant ni les transactions héritées. Les applications, portefeuilles et indexeurs qui souhaitent utiliser des transactions plus grandes doivent s'adapter au nouveau format. Le document RPC de Solana indique que pour recevoir des messages v1, il faut définir maxSupportedTransactionVersion: 1 dans la demande.

Les messages v1 dans le document RPC incluent un objet transactionConfig contenant des limites de calcul et de taille de données, ainsi qu'une priorité de frais. transactionConfig comprend computeUnitLimit, loadedAccountsDataSizeLimit, et priorityFee. Cela se distingue de la méthode précédente où les demandes de ressources étaient soumises par des instructions séparées.

La structure technique changera également. SIMD-0385 explique que les transactions v1 utiliseront le byte de version 129 et que les demandes de ressources seront intégrées dans le masque de configuration de l'en-tête de transaction, au lieu de l'instruction ComputeBudgetProgram existante. La table de recherche d'adresses (ALT) ne sera pas prise en charge.

La table de recherche d'adresses réduit l'espace en référant à une table externe au lieu d'inclure toutes les adresses directement dans la transaction. La v1 est basée sur l'hypothèse qu'il y a souvent des cas où il est possible d'inclure directement une liste d'adresses dans la limite de 4 096 octets. Cependant, dans les charges de travail fortement dépendantes de l'ALT, l'effet d'augmentation de la limite peut être limité.

Ce changement élargit les possibilités pour les développeurs concernant les transactions atomiques. La Fondation Solana a expliqué que les preuves à connaissance nulle, les multi-signatures de grande taille, les travaux par lots et certaines structures de signature on-chain étaient difficiles à inclure dans une seule transaction avec la limite précédente de 1 232 octets. Une transaction atomique est une structure où plusieurs opérations réussissent ou échouent ensemble.

Dans des opérations DeFi complexes ou le traitement de multi-signatures institutionnelles, cela peut réduire le fardeau de diviser les transactions en plusieurs fois. Comme rapporté par notre publication, bien que le volume des transactions hebdomadaires augmente, les relations entre les revenus de frais, l'activité des développeurs et la demande de tokens doivent être examinées séparément des indicateurs de traitement du réseau, qui doivent être évalués en fonction des changements d'infrastructure.

Cependant, la v1 ne supprime pas tous les goulets d'étranglement. L'explication officielle de Solana indique que la v1 fournit une structure permettant aux validateurs et aux équipes clientes de lire plus tôt les demandes de frais et de ressources. En revanche, du point de vue des développeurs d'applications, la limite de 64 comptes peut continuer à poser des contraintes.

Les discussions entre développeurs ont également révélé des attentes et des préoccupations. Dans une discussion sur GitHub, des opinions ont été exprimées selon lesquelles une taille de transaction plus grande serait utile pour des échanges complexes, des DeFi en un clic et des liquidations atomiques. À l'inverse, des préoccupations ont été soulevées concernant les performances du réseau, la fragmentation des paquets, la bande passante des validateurs et la conception des frais.

Dans un environnement de validation local, des opportunités de test sont déjà ouvertes. Le dépôt d'exemples de Solana indique que la fonctionnalité enable_tx_v1 est déjà activée dans solana-test-validator. En revanche, si le code d'exécution a la fonctionnalité désactivée, les transactions v1 seront rejetées comme UnsupportedVersion, il est donc nécessaire de vérifier l'activation par cluster.

Crypto Briefing a rapporté que les transactions v1 pourraient entrer sur le testnet dans les semaines à venir. Cependant, l'état dans la documentation officielle de Solana est encore en attente d'activation. La mise en œuvre sur le mainnet et le calendrier doivent être confirmés en fonction de l'état d'activation des fonctionnalités officielles.

Cette mise à niveau est plus proche d'un changement d'infrastructure de développement que d'une prévision de prix. Les portefeuilles, RPC, indexeurs et outils de développement doivent vérifier leur capacité à analyser les transactions v1 et à répondre à transactionConfig. Les transactions v0 existantes et héritées continueront de fonctionner, mais les services souhaitant utiliser des transactions de 4 096 octets doivent être compatibles avec le nouveau format.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.