Le format de transaction v1 de Solana relève le plafond de payload par transaction de 1 232 octets à 4 096 octets, soit un bond d'environ 3,3x, et tourne déjà sur testnet et devnet (epoch 1140). L'activation sur le mainnet reste en attente sur la page officielle de mise à niveau de Solana, avec un changelog du 28 août qui indique que les transactions v1 arrivent « bientôt ». Cette fenêtre est la montée vers deux pièges de compatibilité très différents pour l'infrastructure environnante : les clients RPC qui ne sont pas mis à niveau peuvent geler net dès qu'ils rencontrent une transaction v1, tandis que les indexeurs, les relayers et les sponsors de frais peuvent continuer à tourner et signaler silencieusement les mauvaises limites de ressources.
Pourquoi c'est important
La hausse du payload mise en avant est l'argument commercial de la mise à niveau, mais les modes de défaillance se nichent dans la tuyauterie que la plupart des utilisateurs ne voient jamais. Les clients RPC qui ne parviennent pas à passer maxSupportedTransactionVersion: 1 recevront l'erreur -32015 sur les requêtes v1 getTransaction, verront getBlock échouer entièrement quand une transaction v1 atterrit dans un bloc, et regarderont blockSubscribe émettre block: null et cesser d'avancer au premier slot affecté. Le risque le plus discret vit dans la gestion de ComputeBudget. V1 déplace les limites d'unités de calcul, les limites de données des comptes chargés et les frais de priorité dans un objet transactionConfig, donc tout indexeur qui analyse encore les instructions ComputeBudget signalera un budget à zéro sans erreur levée, et tout relayer qui applique un plafond de frais en lisant ces instructions les verra s'exécuter comme des no-ops, supprimant le plafond contraignant qu'il pensait imposer. Les consommateurs Geyser et gRPC font face à un piège d'étiquette de version apparenté, car le drapeau versioned du protobuf est vrai pour v0 comme pour v1, laissant des stubs obsolètes persister un budget vide.
Impact sur le marché
Solana présente cela comme une défaillance de contrôle applicatif plutôt qu'un défaut de consensus, donc les fonds ne sont pas automatiquement en risque. Le rayon de l'explosion, en revanche, couvre chaque paymaster, explorateur, stack de garde et programme on-chain qui introspecte ComputeBudget, puisqu'aucun sysvar ou syscall actuel n'expose la configuration de message v1.
Questions fréquemment posées
-
Qu'est-ce que le format de transaction v1 de Solana ?
C'est un format de transaction amélioré qui relève la limite de payload par transaction de Solana de 1 232 octets à 4 096 octets, soit une augmentation d'environ 3,3x. Les transactions legacy et v0 conservent leurs limites et comportements existants, donc les applications qui restent sur ces formats n'ont pas besoin…
-
Comment le bug de gel v1 affecte-t-il les clients RPC ?
Les clients RPC qui ne passent pas maxSupportedTransactionVersion: 1 reçoivent l'erreur -32015 sur les requêtes v1 getTransaction, font échouer getBlock entièrement quand une transaction v1 atterrit dans un bloc, et voient blockSubscribe émettre block: null puis geler au premier slot affecté.
-
Pourquoi les vérifications de plafonds de frais en v1 cassent-elles silencieusement ?
V1 déplace les limites d'unités de calcul, les limites de données des comptes chargés et les frais de priorité dans un objet transactionConfig. Les relayers et les paymasters qui appliquent des plafonds de frais en scannant les instructions ComputeBudget voient ces instructions s'exécuter comme des no-ops en v1, donc…
-
Les fonds des utilisateurs sont-ils en risque avec la mise à niveau v1 de Solana ?
Non. Le diagnostic présente cela comme une défaillance de contrôle applicatif plutôt qu'un défaut de consensus, et les fonds des utilisateurs ne sont pas automatiquement en risque. Le risque se niche dans les relayers, explorateurs, stacks de garde et programmes on-chain qui introspectent ComputeBudget et nécessitent…
-
Quelles versions logicielles gèrent correctement Solana v1 ?
Les versions compatibles lecteur incluent @solana/kit 8.0.0, @solana/web3.js 3.0.0-rc.3, Rust solana-* 4.2.x, Python solders 0.29.0, solana-go 1.23.0, yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1 et gRPC client 12.0.0, selon la stack.
CoinTelegraph
CoinDesk
Crypto News
WatcherGuru
TheBlock