Qu'est-ce que la Transaction Solana V1 ? La mise à niveau de 4 096 octets

Qu'est-ce que la Transaction Solana V1 ? C'est un nouveau format de transaction proposé conçu pour augmenter la capacité de transaction de Solana tout en simplifiant la manière dont les validateurs traitent les transactions.

Le actuel Solana les formats de transaction ont une taille maximale sérialisée de 1 232 octets. Cette limite peut devenir restrictive pour les applications qui doivent combiner de nombreuses instructions, comptes, signatures ou données en une seule transaction atomique.

Le format de transaction proposé Solana V1 augmente l'enveloppe à 4 096 octets. Cependant, la mise à jour n'est pas simplement une limite de taille plus grande. Elle modifie également la disposition de la transaction en supprimant les Tables de Recherche d'Adresse (ALTs), en déplaçant les informations de frais et de ressources vers les métadonnées de la transaction, et en séparant les en-têtes d'instructions de leurs charges utiles de longueur variable.

Le résultat est un format de transaction conçu pour fournir plus de capacité d'application tout en réduisant une partie du traitement dépendant de l'état requis lors de l'ingestion par le validateur.

Principaux Points à Retenir

• La Transaction Solana V1 augmente l'enveloppe de transaction de 1 232 octets à 4 096 octets.

• V1 supprime les Tables de Recherche d'Adresse (ALTs) et place toutes les adresses de comptes référencées directement à l'intérieur de la transaction.

• La mise à jour peut supporter des transactions atomiques plus complexes, mais la limite actuelle de 64 comptes peut encore restreindre les applications lourdes en comptes.

Qu'est-ce que la Transaction Solana V1 ?

La Transaction Solana V1 est un format de transaction proposé qui redessine comment les transactions sont sérialisées et traitées sur le réseau Solana.

La proposition est étroitement associée à deux Documents d'Amélioration Solana : SIMD-0296, qui propose des tailles de transaction plus grandes, et SIMD-0385, qui introduit le format de transaction V1.

Le changement le plus visible est l'augmentation de la taille maximale de transaction. Selon la proposition, une transaction Solana de 4 096 octets peut atteindre jusqu'à 4 096 octets au lieu de la limite actuelle de 1 232 octets.

Cela fournit de l'espace significativement plus grand pour les applications qui ont besoin de charges utiles de transaction plus importantes.

Cependant, V1 change également l'architecture sous-jacente des transactions. Au lieu de s'appuyer sur des Tables de Recherche d'Adresse pour comprimer les adresses de compte, V1 inclut les comptes référencés directement dans la transaction.

Cela crée un compromis : les applications obtiennent une enveloppe de transaction beaucoup plus grande, mais une partie de cet espace supplémentaire peut être consommée par des comptes qui étaient auparavant représentés par des index ALT compacts.

LIRE ÉGALEMENT : Airdrops Solana Septembre 2026 : Opportunités à Venir et Comment Se Qualifier

Pourquoi Solana a-t-il besoin de transactions plus grandes ?

La limite actuelle de 1 232 octets peut rendre difficiles certaines opérations complexes à intégrer dans une seule transaction atomique.

Une transaction peut avoir besoin d'inclure plusieurs instructions, adresses de compte, signatures et données spécifiques à l'application. Lorsque les données sérialisées combinées dépassent la limite, les développeurs peuvent devoir diviser l'opération en plusieurs transactions.

Cela peut compliquer certains flux de travail car des opérations qui pourraient théoriquement se produire de manière atomique doivent en fait être exécutées séparément.

La mise à niveau de la taille de transaction proposée par Solana donne aux développeurs beaucoup plus de place pour construire des transactions complexes au sein d'une enveloppe de transaction.

Cela pourrait être particulièrement utile pour les applications de finance décentralisée, les systèmes de routage, les transactions multisig, les applications de confidentialité et d'autres charges de travail qui nécessitent de traiter de nombreux éléments d'information ensemble.

Solana V1 contre V0 : Quels Changements ?

La différence entre Solana V1 et V0 ne se limite pas à la taille des transactions.

V0 utilise des Tables de Recherche d'Adresse

Les transactions de la version 0 peuvent utiliser des Tables de Recherche d'Adresse pour référencer des comptes en utilisant des index compacts au lieu d'inclure chaque clé publique de 32 octets directement dans la transaction.

Ceci est utile lorsqu'une transaction nécessite de nombreux comptes, car cela réduit considérablement la taille sérialisée de la section compte.

Cependant, l'utilisation d'ALTs introduit également des exigences de traitement supplémentaires pour les validateurs. Le validateur doit récupérer les tables de recherche pertinentes, les valider, résoudre les index et reconstruire l'ensemble complet des comptes avant le traitement ultérieur des transactions.

V1 supprime les dépendances ALT

Sous V1, les Tables de Recherche d'Adresse sont supprimées du format de transaction.

Au lieu de cela, tous les comptes référencés sont inclus directement dans un tableau d'adresses en ligne.

Cela rend l'ensemble complet des comptes disponible plus tôt dans le traitement des transactions et élimine le besoin de résolution ALT dépendante de l'état lors de l'ingestion.

Le compromis est que chaque compte en ligne nécessite sa clé publique complète de 32 octets.

Solana V1 et la Limite de Transaction de 4 096 Octets

Le changement de capacité le plus important est le passage de 1 232 octets à 4 096 octets.

Cela représente plus de trois fois l'enveloppe de transaction précédente.

La capacité plus grande ne signifie pas que chaque transaction sera automatiquement plus grande. Au lieu de cela, les applications qui ont besoin d'espace supplémentaire peuvent utiliser l'espace disponible pour des instructions plus complexes, des charges de données plus grandes, des comptes supplémentaires ou des informations cryptographiques.

L'analyse des charges de travail actuelles de Solana suggère que la population de transactions existante est largement compatible avec l'enveloppe de 4 096 octets après avoir été convertie du V0 au format V1 proposé.

Cependant, l'espace disponible n'est pas distribué uniformément dans chaque composant de la transaction.

La capacité d'instruction a généralement un espace de manœuvre substantiel, tandis que la capacité du compte est plus variable.

Le Compromis ALT dans la Transaction Solana V1

La suppression des Tables de Recherche d'Adresse est le compromis le plus important dans le nouveau format.

Dans V0, un compte chargé à partir d'un ALT peut souvent être représenté en utilisant environ un octet pour son index de recherche. Sous V1, ce même compte doit être représenté par son adresse complète de 32 octets.

En conséquence, la suppression de la compression ALT peut augmenter considérablement la taille sérialisée des transactions qui utilisent de nombreuses adresses de recherche.

L'impact dépend fortement de la manière dont l'ALT est utilisé.

Une transaction qui charge de nombreux comptes à partir de seulement quelques tables de recherche bénéficie considérablement de la compression ALT sous V0. Convertir cette transaction en V1 peut donc ajouter un nombre substantiel d'octets.

D'autre part, les transactions qui font référence à de nombreuses tables mais chargent relativement peu d'adresses de chaque table peuvent connaître une augmentation beaucoup plus petite. Dans certaines configurations éparses, la suppression des frais généraux d'ALT peut même compenser une partie du coût supplémentaire d'adresses.

C'est pourquoi la mise à niveau des transactions Solana V1 est mieux comprise comme un compromis de capacité plutôt qu'une simple augmentation de trois fois l'espace de transaction utilisable.

Quelle est la taille des transactions V1 ?

L'analyse d'un échantillon de 30 jours de transactions Solana fournit une estimation de la façon dont les transactions V0 actuelles se comporteraient sous le format proposé.

Parmi les transactions V0 actuelles utilisant des ALTs :

• Environ 50 % connaîtraient moins de 420 octets supplémentaires après conversion.

• Environ 90 % connaîtraient moins de 1 400 octets supplémentaires.

• Les transactions ALT denses peuvent ajouter plus de 1 500 octets lorsque leurs adresses sont converties en adresses V1 en ligne.

Même après avoir pris en compte cette expansion, la distribution de transactions V1 contrefactuelles reste largement en dessous de l'enveloppe proposée de 4 096 octets.

Cela suggère que l'enveloppe plus grande peut fournir une capacité supplémentaire significative pour de nombreuses charges de travail existantes.

Qu'est-ce que des transactions plus grandes sur Solana peuvent permettre ?

Les transactions plus grandes sur Solana peuvent bénéficier aux applications qui peinent actuellement à intégrer toutes les opérations requises dans une seule transaction.

Les cas d'utilisation potentiels incluent :

Des routes DeFi plus complexes

Les routeurs de trading peuvent combiner plus d'opérations et d'interactions de compte au sein d'une seule transaction, rendant potentiellement les routes complexes plus faciles à construire de manière atomique.

Des charges utiles multisig et cryptographiques plus grandes

Les applications impliquant des opérations multisig, des preuves, des signatures ou d'autres constructions cryptographiques lourdes en données peuvent bénéficier d'espace sérialisé supplémentaire.

Une logique d'application plus sophistiquée

Les développeurs peuvent avoir plus de place pour les données d'instruction et plusieurs instructions de premier niveau sans atteindre immédiatement le plafond précédent de 1 232 octets.

Cependant, la taille de la transaction n'est qu'une limitation.

La limite de 64 comptes compte toujours

Un détail important est que la limite de 4 096 octets ne supprime pas automatiquement toutes les contraintes de transaction existantes.

L'analyse actuelle indique que la capacité d'instruction a généralement une marge considérable après conversion, tandis que la marge de compte est plus hétérogène.

Cela signifie qu'une application peut avoir des centaines d'octets inutilisés mais être toujours incapable d'ajouter une autre interaction de protocole si elle atteint la limite de compte.

C'est particulièrement pertinent pour les applications lourdes en comptes DeFi.Ajouter un autre pool de liquidités, un marché, un oracle, un coffre-fort ou un autre composant de protocole peut nécessiter plusieurs nouveaux comptes.

Par conséquent, V1 fournit une capacité d'octets considérablement plus grande, mais cela ne signifie pas que les applications ont une capacité de compte illimitée.

Comment la transaction Solana V1 change le traitement des validateurs

Un autre objectif majeur de V1 est de simplifier l'ingestion des transactions pour les validateurs.

Dans les formats de transaction existants, les validateurs doivent extraire les frais et les exigences en ressources des instructions de transaction. Les transactions V0 nécessitent également une résolution d'ALT avant que l'ensemble complet de comptes ne soit connu.

V1 change ce processus en faisant des frais et des demandes de ressources des métadonnées de transaction de premier ordre.

Il fournit également un tableau de comptes en ligne complet, supprimant le besoin de résoudre les tables de recherche d'adresses pendant l'ingestion.

Les en-têtes d'instruction sont séparés de leurs charges utiles de longueur variable également. Cela permet aux validateurs de déterminer les limites d'instruction sans analyser séquentiellement chaque instruction de longueur variable précédente.

Ensemble, ces changements peuvent permettre aux validateurs d'identifier plus tôt des informations importantes sur les transactions et de réduire le traitement dépendant de l'état dans le chemin d'ingestion.

Qui bénéficie de la transaction Solana V1 ?

La mise à niveau peut affecter plusieurs parties de l'écosystème Solana.

• Les développeurs bénéficient d'une enveloppe de transaction plus grande pour des opérations atomiques plus complexes.

• Les validateurs et les équipes clients bénéficient d'une structure de transaction qui expose les informations sur les frais et les ressources plus tôt et supprime la résolution d'ALT de l'ingestion.

• Les traders et les systèmes de routage peuvent potentiellement construire des routes de transactions atomiques plus complexes.

• Les portefeuilles, SDK et fournisseurs RPC devront prendre en charge la nouvelle sérialisation et le modèle de construction de transactions.

• Les applications de confidentialité et cryptographiques peuvent bénéficier d'une marge supplémentaire pour des charges utiles lourdes en données.

Le principal avantage, cependant, n'est pas simplement que les transactions deviennent plus grandes. V1 tente de rendre les transactions plus grandes plus faciles à traiter structurellement pour le réseau.

Transaction Solana V1 expliquée en termes simples

Le moyen le plus simple de comprendre la transaction Solana V1 est de la considérer comme une refonte du conteneur de transaction.

V0 utilise un conteneur plus petit et peut compresser les adresses de compte via des ALTs. V1 utilise un conteneur beaucoup plus grand mais place toutes les adresses de compte directement à l'intérieur.

Dans le même temps, V1 réorganise les métadonnées des transactions afin que les validateurs puissent identifier les frais, les exigences en ressources, les comptes et les frontières d'instruction plus efficacement.

Ainsi, le compromis est simple :

V0 : transactions plus petites + adresses ALT compressées + résolution de recherche supplémentaire.

V1 : transactions plus grandes + adresses en ligne + découverte de compte simplifiée lors de l'ingestion.

L'enveloppe plus grande de 4 096 octets donne aux applications plus de marge, tandis que la nouvelle structure vise à simplifier le traitement des validateurs.

LIRE ÉGALEMENT : Solana pour les débutants - Tout sur Solana (SOL)

Conclusion

Qu'est-ce que la Transaction Solana V1 ? C'est un format de transaction proposé conçu pour élargir la capacité de transaction de Solana de 1 232 octets à 4 096 octets tout en changeant la façon dont les données de transaction sont organisées.

La mise à niveau est étroitement liée aux SIMD-0296 et SIMD-0385. V1 supprime les Tables de Recherche d'Adresse du format de transaction, déplace les demandes de frais et de ressources dans les métadonnées de la transaction, et sépare les en-têtes d'instruction de leurs charges utiles de longueur variable.

Le plus grand compromis est la suppression des ALT. Les comptes qui étaient auparavant représentés par des index de recherche compacts doivent être inclus comme des adresses complètes de 32 octets, ce qui signifie que certaines transactions peuvent devenir significativement plus grandes.

Néanmoins, la charge de travail analysée semble largement compatible avec l'enveloppe de 4 096 octets. La mise à niveau pourrait donc fournir une capacité supplémentaire significative pour des applications complexes, bien que la limite existante de 64 comptes puisse rester une contrainte pour les transactions lourdes en comptes.

Pour les traders suivant les développements de l'écosystème Solana et cherchant à échanger SOL ou d'autres actifs cryptographiques, vous pouvez explorer le marché sur Bitrue et vous inscrire pour un compte Bitrue ici.

FAQ

Qu'est-ce que la Transaction Solana V1 ?

La Transaction Solana V1 est un format de transaction proposé qui augmente la taille maximale de transaction à 4 096 octets et refond le sérialisation des transactions.

Quelle est la taille d'une transaction Solana V1 ?

La taille maximale proposée est 4 096 octets, comparée à la limite actuelle de 1 232 octets.

Qu'est-ce que SIMD-0385 ?

SIMD-0385 est le Document d'Amélioration de Solana proposant le format de Transaction V1 et ses changements structurels.

Qu'est-ce que SIMD-0296 ?

SIMD-0296 propose d'augmenter la taille maximale des transactions de Solana de 1 232 octets à 4 096 octets.

La Solana V1 supprime-t-elle les Tables de Recherche d'Adresse ?

Oui. V1 supprime les dépendances ALT du format de transaction et inclut les comptes référencés directement dans la transaction.

Avertissement : Les opinions exprimées appartiennent exclusivement à l'auteur et ne reflètent pas les opinions de cette plateforme. Cette plateforme et ses affiliés déclinent toute responsabilité quant à l'exactitude ou à la pertinence des informations fournies. C'est à des fins d'information uniquement et n'est pas destiné à des conseils financiers ou d'investissement.