Un bug de Solana v1 peut bloquer les lecteurs et désactiver les plafonds de frais

Le format de transaction v1 de Solana porte la charge utile maximale de 1 232 à 4 096 octets. L’augmentation est d’environ 3,3 fois. Les transactions héritées et v0 conservent leurs limites et leur comportement actuels. Les utilisateurs et les applications qui continuent d’utiliser ces formats n’ont pas besoin de migrer. La page de mise à niveau en direct de Solana indiquait v1 comme inactif sur le réseau principal au 4 septembre. Le réseau de test était actif. Le réseau de développement était opérationnel à l’époque 1140. Un journal des modifications publié par Solana le 28 août décrivait les transactions v1 comme arrivant prochainement. Les consommateurs RPC doivent prendre en charge le format avant de lire des données v1. L’activation volontaire indique seulement au service RPC le format le plus élevé que le client peut décoder. Elle ne demande pas de données v1 et ne modifie pas la manière dont les transactions héritées et v0 sont renvoyées. Avec v1, les limites d’unités de calcul, de données de comptes chargées et les frais de priorité sont placés dans un objet plutôt que dans les instructions. Les indexeurs qui continuent de parcourir les instructions peuvent signaler un budget de calcul nul pour chaque transaction v1 sans générer d’erreur. Le drapeau protobuf est true pour v0 comme pour v1. Un consommateur Geyser ou gRPC obsolète peut donc étiqueter v1 comme v0 et conserver un budget vide. Les consommateurs doivent régénérer les stubs protobuf et vérifier le champ 7 avant de lire le drapeau. Les relais, les paymasters et les autres signataires de serveurs doivent mettre à jour leurs contrôles de politique. Un sponsor qui parcourt les instructions à la recherche d’un plafond de frais pourrait ne plus appliquer un plafond contraignant, car ces instructions peuvent apparaître dans v1 tout en étant exécutées comme des opérations sans effet. Les serveurs doivent identifier le préfixe v1 et appliquer les limites de frais et de ressources dans la configuration de la transaction. L’article décrit cela comme une défaillance du contrôle applicatif plutôt que comme un défaut de consensus. Il indique que le problème ne prouve pas que les fonds soient automatiquement exposés à un risque. Solana affirme qu’aucun sysvar ni syscall actuel n’expose la configuration du message v1. Les programmes qui conditionnent leur comportement à des instructions introspectées doivent cesser de s’appuyer sur cette vérification lorsque v1 sera activé. Les versions minimales capables de lire le format sont 8.0.0, 3.0.0-rc.3, Rust 4.2.x, Python 0.29.0 et 1.23.0. La branche 1.x de web3.js peut lire v1 à partir de 1.99.0-beta.0, mais ne peut pas le construire, le signer ni l’envoyer. Les utilisateurs de Yellowstone ont besoin d’au moins 12.6.0, du plugin Geyser 15.1.1, du client gRPC 12.0.0 ou 6.0.0, selon leur pile. La création de transactions v1 est facultative. Les équipes qui en créent doivent définir explicitement les limites d’unités de calcul et de données de comptes chargées, car les deux valeurs sont par défaut nulles. Elles doivent supprimer les instructions sans effet. Elles doivent cesser d’utiliser les tables de recherche d’adresses. Elles doivent utiliser base64 pour les charges utiles de plus de 1 232 octets. L’échéance immédiate est un test de compatibilité pour les services susceptibles de lire, d’indexer ou de sponsoriser la transaction v1 d’un autre utilisateur.