Alerte : Solana envisage de supprimer le mécanisme Durable Nonce, six mois seulement pour que les dépositaires migrent

SOL
autorisations de mint USDC/USDTdurable nonceSIMD-0723SolanaAnzadépositairesmise à niveau du protocole
il y a 1 heureSource: blockweeks.com
Alerte : Solana envisage de supprimer le mécanisme Durable Nonce, six mois seulement pour que les dépositaires migrent

Cet article a été compilé et organisé par BlockWeeks

Gabe Rodriguez de Anza, l'équipe de développement principale du client de validateur Solana, a soumis le 5 novembre un document d'amélioration de Solana (SIMD), qui constitue le processus formel de modification du protocole du réseau. La proposition prévoit d'abolir formellement le mécanisme de durable nonce.

Le soi-disant durable nonce est une valeur stockée conservée dans un compte dédié, utilisée pour remplacer le « recent blockhash » — c'est-à-dire la référence de bloc à courte durée de vie que chaque transaction Solana porte généralement. Son objectif est de permettre à une transaction d'être signée maintenant et diffusée sur la chaîne bien plus tard.

Ce que SIMD-0723 change exactement

Selon SIMD-0723, une fois ce changement activé, « chaque transaction doit porter un recent blockhash ». Et cette référence expire après 150 blocs, moment auquel la transaction ne peut plus être mise sur la chaîne. Les instructions du System Program intégré de Solana utilisées pour initialiser, avancer et mettre à niveau les comptes nonce seront désactivées ; les deux instructions permettant aux propriétaires de comptes de retirer des fonds ou de réaffecter le contrôle resteront disponibles. Les comptes existants ne seront pas touchés.

Une soumission du 6 novembre a ajouté un calendrier : une fenêtre de migration d'au moins six mois, comptée à partir de la date de soumission du 5 novembre ; le projet indique explicitement que cette fonctionnalité « ne sera pas activée sur mainnet-beta (le réseau principal de Solana) avant le 2027-05-05 ». Le statut de la proposition est actuellement encore Draft, et la pull request correspondante n'a pas encore reçu d'approbations. Le bot du dépôt a listé les conditions requises pour la fusion : l'approbation d'un membre de l'équipe Anza et d'un membre de l'équipe Firedancer de Jump Crypto (qui est responsable d'un autre client de validateur indépendant).

Dépositaires et plateformes d'échange mis en cause

Le projet souligne que toute entité qui signe une transaction maintenant mais ne la diffuse qu'après l'expiration des 150 blocs doit refaire le processus ; et il met spécifiquement en cause les dépositaires et les plateformes d'échange — dont les processus d'approbation sur des machines air-gapped (non connectées au réseau) peuvent durer plus longtemps que cette fenêtre.

En janvier de cette année, lors de la discussion initiale, un participant a cité les clés contrôlant les droits d'émission de l'USDC et de l'USDT (c'est-à-dire l'autorité de mint) comme l'un des utilisateurs importants de cette fonctionnalité. Michael Gutkin de Fireblocks a écrit en mars que l'entreprise « gère des millions de portefeuilles Solana » et estimait que « l'abolition du durable nonce semble être la bonne direction ». Mais il a ajouté que s'il n'existe pas de pont compatible pour la migration des comptes (par exemple, une solution qui encapsule des transactions pré-signées), « nous pensons qu'à l'échelle institutionnelle, 12 mois constituent la période minimale viable ». SIMD-0723 a rejeté une telle solution d'encapsulation et n'offre qu'au moins six mois.

Deux alternatives officiellement proposées

La proposition renvoie à deux voies alternatives : le Programmatic Signer d'Anza et le Vector de Blueshift. Dans les deux solutions, le propriétaire du compte délègue l'autorité à une adresse dérivée d'un programme (PDA) — un compte contrôlé par un programme plutôt que par une clé privée — puis signe l'autorisation hors ligne et remet la signature à un tiers (un relayer), et le programme vérifie la signature sur la chaîne transaction par transaction avant d'exécuter l'instruction.

Au 9 novembre, l'auteur du projet, Rodriguez, avait soumis 136 commits au dépôt Programmatic Signer, ce qui, selon les données des contributeurs GitHub, est le plus élevé parmi plusieurs contributeurs. Le projet avertit également : « une soumission échouée n'est pas une révocation ».

Une histoire d'échecs et une concentration extrême des frais

Le SIMD cite une série de cas d'échec, dont un incident en 2022 : les validateurs ont traité une transaction échouée à la fois via le chemin blockhash standard et via le chemin nonce en même temps, provoquant un blocage du réseau principal pendant environ 4,5 heures.

Les données publiées par Max Resnick en juin montraient que, dans une certaine époque (intervalle de blocs fixe de Solana), les transactions nonce représentaient environ 3,1 % de toutes les transactions, mais contribuaient à environ 30 % des priority fees (c'est-à-dire le pourboire optionnel utilisé pour accélérer le traitement). Selon ses statistiques, parmi les 103 672 comptes ayant payé des frais pour des transactions nonce, 555 comptes en ont contribué 97,5 %.

L'ombre de l'incident Drift

Il convient de noter que le texte intégral du SIMD ne mentionne pas Drift. Cette bourse de contrats perpétuels a perdu environ 295,7 millions de dollars le 1er avril selon ses propres déclarations, et dans son plan de rétablissement, elle a qualifié la surface d'attaque liée au nonce durable de « élément central expliquant pourquoi l'exploit du 1er avril a pu être exécuté ». Des rapports antérieurs suggéraient que l'incident pourrait être lié à la Corée du Nord, et Drift a également publié des modalités de réclamation liées aux jetons de rétablissement.

Le compte à rebours de six mois et la pression des mises à niveau empilées

La question clé est la suivante : le compte à rebours de six mois commence à la date de publication du projet, et non à la date à laquelle les alternatives sont prêtes. Au 9 novembre, le dépôt Programmatic Signer est encore marqué comme « en construction ».

Cela signifie que les dépositaires doivent faire avancer cette migration tout en gérant d'autres changements fondamentaux récents, tels que le passage au consensus Alpenglow et la modification élargissant la limite de transaction à 4 096 octets.