Solana vise l'activation de Transaction v1 mercredi

Solana vise mercredi pour activer la Transaction v1, augmentant la taille maximale des transactions de 1 232 octets à 4 096 octets. Le changement élargit ce qui peut être intégré de manière atomique sur la chaîne, mais il oblige également l'infrastructure de lecture des données à se mettre à jour ou à risquer des demandes échouées et des affichages de frais de priorité trompeurs.

Points clés

Solanavise une activation du mainnet mercredi qui augmente la taille maximale des transactions de 1 232 octets à 4 096 octets via la Transaction v1.
Les anciens formats de transaction restent pris en charge, donc la plupart des portefeuilles et des applications peuvent continuer à fonctionner sans changer, à moins qu'ils n'aient besoin de l'espace supplémentaire.
Les lecteurs de blocs et de transactions qui alimentent les explorateurs, les portefeuilles et les applications de trading ont besoin du support de la Transaction v1 ou les demandes de récupération peuvent échouer lorsque le nouveau format apparaît.
Les métadonnées de frais de priorité se déplacent dans v1, ce qui signifie que les outils obsolètes peuvent afficher un frais de priorité de zéro même lorsqu'un utilisateur en a payé un.

La Transaction v1 est en ligne : de 1 232 octets à 4 096 octets

Solana vise mercredi à augmenter sa taille maximale de transaction de 1 232 octets à 4 096 octets grâce à un nouveau format de Transaction v1. Cela représente plus de 3 fois l'augmentation de la quantité d'instructions et de données pouvant tenir dans une seule transaction.

Le gain pratique est l'atomicité. Les flux de travail qui devaient auparavant être répartis sur plusieurs transactions peuvent de plus en plus être exécutés en une seule, réduisant le nombre de signatures séparées, de diffusions et de points de défaillance nécessaires pour compléter une action complexe.

Le nouveau format est déjà en cours d'exécution sur les réseaux de test et de développement de Solana. Le paquet ne précise pas de moment d'activation exact pour mercredi, et il ne confirme pas l'activation finale du mainnet au-delà de l'objectif.

Le changement est défini dans deux documents d'amélioration de Solana, SIMD-0296 et SIMD-0385, coécrits par Jacob Creech et Andrew Fitzgerald.

Exécution et optique des frais : transactions plus importantes, métadonnées de frais de priorité différentes

Des transactions plus importantes élargissent l'espace de conception pour les applications Solana qui sont lourdes en instructions. Les exemples cités de ce qui peut désormais s'intégrer plus confortablement dans une seule transaction incluent de grandes preuves cryptographiques, des paiements nécessitant de nombreuses approbations (grandesmultisigopérations), et certains transferts confidentiels.

Pour les traders, l'implication immédiate est qu'il y a moins de séquences de transactions multiples pour des actions complexes. Cela est particulièrement important lorsque la chaîne est occupée et que l'exécution partielle est coûteuse. Une transaction réussit ou elle échoue. Diviser la même intention en plusieurs transactions augmente les chances qu'un volet échoue, arrive en retard ou soit traité avec un régime de frais différent.

Le tableau des frais est plus nuancé. La mise à niveau n'introduit pas de nouveau frais par octet, mais les transactions plus importantes consomment plus de bande passante réseau. Les développeurs s'attendent à ce que les utilisateurs doivent proposer des frais de priorité plus élevés lorsque des transactions plus importantes sont en concurrence pour de l'espace.

Les frais de priorité sont des paiements supplémentaires optionnels que les utilisateurs peuvent effectuer pour faire traiter une transaction plus rapidement. Le problème est que la version 1 des transactions stocke les informations sur les frais de priorité ailleurs, ce qui crée un nouveau mode de défaillance pour tout outil qui suppose l'ancienne structure.

Risque d'indexeur et d'explorateur : lectures échouées et erreurs de rapport sur les 'frais nuls'

La pression de mise à niveau la plus immédiate ne concerne pas les portefeuilles. Les formats de transaction existants resteront pris en charge, et les portefeuilles et applications n'ont pas besoin de passer à la v1 à moins qu'ils n'aient besoin de l'espace supplémentaire.

La pression est sur la plomberie qui lit Solana. Les services qui récupèrent des blocs et des transactions doivent être mis à jour pour reconnaître la Transaction v1. S'ils ne le sont pas, les demandes peuvent échouer lorsqu'elles rencontrent le nouveau format.

Cet échec n'est pas seulement un casse-tête opérationnel. Les portefeuilles, les explorateurs et les applications de trading s'appuient souvent sur ces services pour afficher ce qui s'est passé sur la chaîne.

Si le backend ne peut pas analyser la v1, le symptôme visible pour l'utilisateur peut être des transactions manquantes, des vues d'historique cassées ou des rapports d'exécution incohérents à travers des applications qui tirent des données de différents indexeurs.

Les aspects des frais sont le côté le plus tranchant. Parce que la v1 stocke les données de frais de priorité à un endroit différent, un logiciel obsolète peut afficher un frais de priorité de zéro même lorsqu'un frais a été payé.

En période de congestion, ce type de rapport erroné peut déformer l'expérience utilisateur des traders en rendant l'exécution moins chère qu'elle ne l'était, ou en créant des "vérités" conflictuelles à travers les explorateurs et les terminaux.

Liste de vérification post-activation pour les traders et les constructeurs

Le premier point de contrôle est la confirmation de l'heure d'activation exacte du mercredi et si des problèmes de déploiement apparaissent immédiatement après le changement. Le paquet n'inclut pas de timestamp finalisé.

Le deuxième point de contrôle est l'état de l'infrastructure. Les principaux indexeurs, explorateurs et backends de portefeuilles doivent confirmer le support de la Transaction v1, y compris l'analyse correcte des frais de priorité. Une préparation mixte est le cas de base lorsque un changement de format se produit, et c'est là que les traders voient des affichages de frais incohérents à travers les outils.

Le troisième point de contrôle est la télémétrie d'erreur dans la nature. Des rapports de demandes de récupération de blocs ou de transactions échouées, d'historique manquant ou de divergences soudaines dans les frais de priorité affichés à travers les explorateurs et les applications de trading seraient le signal le plus clair que certains backends lisent encore la chaîne avec de vieilles hypothèses.

Le dernier point de contrôle est comportemental, pas mécanique. Une fois que des transactions plus importantes commencent à rivaliser pour de l'espace, le marché découvrira ce que "peut nécessiter des frais de priorité plus élevés" signifie en pratique pendant la congestion. Le paquet ne fournit aucune estimation numérique, seulement l'attente directionnelle.

Mon avis : C'est une mise à niveau de l'expérience utilisateur et de la fiabilité autant qu'une mise à niveau du débit.

Le seuil qui compte n'est pas de savoir si les portefeuilles « supportent v1 ». Les formats hérités restent valides, donc la plupart des interfaces fonctionneront correctement.

Le véritable test est de savoir si les indexeurs et les explorateurs en qui les traders ont implicitement confiance peuvent analyser v1 de manière cohérente, car des lectures échouées et des rapports erronés sans frais sont la manière dont les mises à niveau de format se transforment en confusion d'exécution.

Si les affichages de frais prioritaires restent cohérents à travers les principaux outils après l'activation, la configuration commence à sembler structurelle plutôt que narrative : des actions plus complexes peuvent être effectuées de manière atomique sans perturber la vision du coût et de la confirmation du trader.

Si l'optique des frais se fragmente, la mise à niveau semblera moins comme une capacité supplémentaire et plus comme une taxe de fiabilité temporaire payée en mauvaises données.

Solana active Transaction v1 mercredi, taille max à 4 096…