Vérification de la compatibilité avant la transition vers le format de transaction v1 de Solana de 4096 octets

Le nouveau format de transaction v1 de Solana (SOL) est soumis à une vérification de compatibilité des infrastructures avant son activation sur le mainnet. Bien que la taille maximale d'une transaction unique passe de 1 232 octets à 4 096 octets, la question principale concerne la capacité des RPC, indexeurs, gRPC et sponsors de frais à lire correctement le nouveau format, plutôt que les problèmes de consensus de la chaîne.

La Fondation Solana a annoncé sur la page de mise à niveau du réseau que l'Agave 4.2 a été déployé sur le mainnet, mais que la fonctionnalité "Larger Transaction Sizes" est en attente d'activation au 4 septembre 2026. Cette fonctionnalité vise à augmenter la limite de transaction existante d'environ 3,3 fois via le format de transaction v1.

Ce changement n'est pas simplement une augmentation de taille. Les propositions SIMD-0296 et SIMD-0385 ont été présentées en lien avec des usages tels que les multi-signatures de grande taille, les preuves à connaissance nulle (ZK proof) et les envois groupés. Dans le v1, la dépendance à la table de recherche d'adresses utilisée dans les transactions existantes sera réduite, et les informations sur les frais et les limites de ressources seront déplacées vers une valeur de configuration distincte appelée transactionConfig.

La manière dont le système existant lit ces informations pourrait poser problème. Si l'indexeur et le sponsor de frais ne parcourent que l'instruction ComputeBudget, ils pourraient manquer le plafond de frais de la transaction v1 ou le lire comme étant 0. Le dépôt d'exemples de la Fondation Solana explique que le message v1 contient TransactionConfig au lieu de l'instruction ComputeBudget.

La documentation RPC de Solana indique qu'il est nécessaire d'inclure maxSupportedTransactionVersion: 1 dans les appels getTransaction, getBlock et blockSubscribe. Si cette valeur est omise ou laissée à 0, getTransaction pourrait renvoyer une erreur lors de la réception d'une transaction v1, et getBlock pourrait échouer à lire l'ensemble du bloc.

Les abonnements WebSocket ne sont pas exempts non plus. Si blockSubscribe n'est pas configuré correctement, il pourrait renvoyer block: null. La documentation de développement de Solana précise que cela doit être traité comme un échec plutôt que comme un bloc vide. Les transactions v1 sont identifiées par le premier octet 129, soit 0x81, de la transaction sérialisée.

Des erreurs plus discrètes peuvent survenir sur les chemins gRPC et Geyser. La documentation de développement de Solana avertit qu'il n'y a pas de valeur d'option comme maxSupportedTransactionVersion dans gRPC, et que les anciens stubs protobuf pourraient ignorer le champ Message.config. Dans ce cas, le système ne s'arrête pas, mais pourrait traiter les transactions v1 comme des v0, omettant ainsi les paramètres de frais.

Le dépôt d'exemples de la Fondation Solana a proposé des versions minimales telles que @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0 et yellowstone-grpc geyser 15.1.1. Des exemples de lecture, d'envoi, d'indexation de blocs et de gRPC sont également fournis séparément.

La validation du côté des outils principaux est également en cours. Le problème #831 du solana-sdk d'anza-xyz a soulevé la question de savoir si la taille maximale de 4 096 octets n'est pas correctement appliquée dans le désérialiseur et le sanitizeur. Cependant, la page d'état de Solana indique qu'au 4 septembre 2026, les nœuds RPC Mainnet Beta sont opérationnels et qu'aucun incident n'a été signalé ce jour-là.

Cette question est fortement liée à la vérification de la compatibilité des infrastructures concernant l'augmentation de la limite des transactions v1 de Solana. Si les questions précédentes concernaient la limite de 4 096 octets et l'activation des fonctionnalités par cluster, la clé ici est de savoir si le système backend peut lire la nouvelle structure lorsque de vraies transactions v1 arrivent.

La page de mise à niveau de Solana indique que la fonctionnalité "Larger Transaction Sizes" est en attente d'activation au 4 septembre 2026. Ce calendrier ressemble davantage à une feuille de route technique que les portefeuilles, RPC, indexeurs et outils de développement doivent préparer séquentiellement, plutôt qu'à un événement unique qui modifierait la structure de traitement de Solana d'un coup.

Techniquement, les transactions v1 ne remplacent pas les anciennes transactions v0 et legacy. Le format existant continuera à fonctionner, mais les applications utilisant des tailles de transaction plus grandes et transactionConfig nécessiteront un support pour le nouveau format. En général, lors des mises à niveau de l'infrastructure blockchain, la compatibilité des systèmes périphériques qui lisent et stockent les données influence réellement les risques d'exploitation.

Les sponsors de frais et les indexeurs pourraient être particulièrement affectés. S'ils lisent mal le plafond des frais ou la limite des unités de calcul, les services qui supportent les coûts à la place des utilisateurs pourraient être exposés à une structure de coûts différente de celle attendue, et les systèmes d'analyse des transactions pourraient mal enregistrer les paramètres de ressources des transactions v1. Bien que cela ne soit pas un incident qui arrête la chaîne, c'est un domaine qui nécessite une vérification distincte pour les opérateurs de services.

Les échanges nationaux ou les fournisseurs de portefeuilles qui gèrent les dépôts et retraits Solana ainsi que la surveillance on-chain ne sont pas exempts de ce problème. Ils doivent s'assurer que les chemins de recherche de blocs, de transactions, d'indexation, de surveillance des risques et de calcul des frais traitent la structure des messages v1. En particulier, dans le cas de l'utilisation de fournisseurs de nœuds externes ou de données basées sur Geyser, il est nécessaire de vérifier la reproductibilité des protobuf et la version des bibliothèques.

Avant que les transactions v1 de Solana n'arrivent réellement, les points de vérification clés sont : △ configuration de l'option d'appel RPC maxSupportedTransactionVersion: 1 △ réflexion du chemin de stockage transactionConfig △ régénération des stubs protobuf gRPC △ reconnaissance du préfixe de version 0x81. Selon la page de mise à niveau de Solana, "Larger Transaction Sizes" est en attente d'activation au 4 septembre 2026.