Le plan quantique de TRON pourrait laisser certains portefeuilles capables de payer mais incapables de remplacer leurs clés

Le projet de conception de signature quantique de TRON pourrait laisser certains comptes migrés incapables de remplacer leurs clés après que la gouvernance du réseau désactive le schéma de signature dont ils dépendent. Certains de ces comptes pourraient encore effectuer des paiements par le biais d'une autorisation distincte.

La conception inclut une possible voie de récupération à travers un second schéma de signature résistant aux quantiques. Pour l'utiliser, les détenteurs auraient besoin des clés survivantes pour atteindre le seuil de propriétaire existant du compte, le niveau d'autorité requis pour changer les autorisations. Une clé de secours autorisée uniquement pour les paiements laisserait ce pouvoir de réparation hors de portée.

C'est la question pratique derrière l'initiative quantique de Justin Sun. Le 8 août 2026, @justinsuntron a déclaré que son objectif était que TRON devienne le premier réseau blockchain résistant aux quantiques et a fait référence à des tests sur le réseau de test Nile. Cette déclaration d'ambition datée fournit le contexte d'une conception de migration dont les commutateurs de gouvernance peuvent ultérieurement retirer l'approbation d'un schéma de signature.

À partir du 12 septembre, le TIP-899 reste étiqueté comme projet. La version logicielle de Nile du 30 juin a inclus des implémentations de Falcon-based FN-DSA-512 et ML-DSA-44, chacune soumise à son propre paramètre d'activation. Chaque implémentation a encore besoin de son approbation de gouvernance avant que le réseau n'accepte ses signatures.

Un contrôle du 12 septembre du point de terminaison des paramètres de Nile a renvoyé getAllowFnDsa512 avec une valeur de 1. Le paramètre ML-DSA est apparu sans valeur, ne fournissant aucune lecture d'activation affirmative. La réponse du mainnet ne contenait aucun paramètre. Les développeurs avaient déclaré lors de leur appel du 15 juillet que le calendrier du mainnet n'était pas décidé ; les contrôles actuels n'établissent pas l'activation du mainnet.

Un commutateur de réseau rencontre un seuil de compte

Le TIP-899 permet à la gouvernance d'activer ou de désactiver chaque schéma proposé séparément. Les 27 Super Représentants élus de TRON gouvernent par le biais de propositions sur la chaîne. Les commutateurs proposés appartiennent à ce processus.

Les paramètres d'activation ont également été renumérotés. Le TIP-899 et l'implémentation de Nile utilisent les codes 1000 et 1001, tandis que la discussion antérieure sur la migration contient encore 99 et 100. L'appel des développeurs du 1er juillet explique que les plus grands numéros ont été choisis pour éviter les conflits avec la numérotation future du mainnet. Ces numéros identifient les paramètres proposés ; l'activation nécessite une décision de gouvernance distincte.

Au niveau du compte, la question est de savoir quelles signatures restent acceptables. TRON attribue des poids aux clés et exige que les signataires valides d'une autorisation sélectionnée atteignent ou dépassent son seuil. Le chemin de signature quantique proposé utilise ce même calcul d'autorisation.

Il y a un détail conséquent dans le vérificateur de transaction de référence : une signature d'un schéma désactivé déclenche un rejet. Une transaction de secours fonctionnelle doit donc utiliser des signatures acceptées et omettre la signature du schéma désactivé, même si les clés restantes portent suffisamment de poids.

Désactiver un schéma peut donc supprimer une voie de signature sans changer le seuil configuré du compte. Rien dans ce commutateur n'accorde automatiquement à une autre clé l'autorité manquante.

La documentation des autorisations de TRON sépare l'autorité du propriétaire des autorisations actives. L'autorisation du propriétaire peut autoriser tout type de contrat et changer les autorisations du compte. Une autorisation active est limitée aux opérations qui lui sont assignées, telles que les transferts.

Une mise à jour des autorisations doit être signée sous l'autorisation du propriétaire existant. Cela rend la configuration du propriétaire centrale pour la récupération : une clé capable d'envoyer un paiement n'a pas nécessairement le pouvoir de remplacer les clés du compte.

Considérez une permission de propriétaire contenant uniquement une clé Falcon avec un poids de 1 et un seuil de 1. Lorsque Falcon est désactivé, cette permission de propriétaire ne peut pas autoriser un transfert ou une mise à jour de permission. Une permission active configurée séparément peut néanmoins permettre des transactions, donc cela ne rend pas nécessairement l'ensemble du compte incapable de dépenser.

Conserver une clé pour la méthode de signature ECDSA existante de TRON aux côtés de Falcon ne restaure pas toujours l'accès. Avec un poids ECDSA de 1, un poids Falcon de 1 et un seuil de 2, les deux signatures sont requises. Après la désactivation de Falcon, le poids ECDSA restant ne peut pas atteindre le seuil.

Les exemples suivants appliquent les règles proposées à des configurations hypothétiques. Ils montrent des déductions des règles de permission et de vérification documentées ; aucune observation de verrouillage ou test de retour en arrière exécuté ne sous-tend ces exemples. Supposons que Falcon ait été désactivé, que toutes les clés ML-DSA aient été configurées au préalable, que ML-DSA reste activé et sécurisé, et que le titulaire puisse toujours utiliser ces clés.

Ces résultats concernent l'autorité de signature ; d'autres exigences de transaction s'appliquent toujours. La distinction fonctionne également dans l'autre sens. Une permission de propriétaire ML-DSA survivante pourrait autoriser des transactions directement et remplacer une permission active Falcon désactivée.

Une seconde clé quantique n'aide que si elle peut agir

L'exemple de propriétaire à deux schémas préserve une voie résistante aux quantiques pour la réparation de permission si l'une ou l'autre clé peut indépendamment atteindre le seuil du propriétaire. Exiger les deux clés crée une dépendance à ce que les deux schémas restent disponibles. Le seuil détermine quelles propriétés un compte possède.

Une voie de récupération classique ne préserve donc pas le même objectif de sécurité. La proposition de migration dit explicitement qu'ajouter une clé résistante aux quantiques ne fournit aucune protection quantique si un ensemble de signature uniquement ECDSA peut encore atteindre le seuil. Une route de propriétaire uniquement ECDSA peut également remplacer une permission active protégée par des quantiques.

La configuration pertinente est donc plus large que la clé utilisée pour les paiements de routine. L'autorité du propriétaire et chaque route active capable de déplacer les actifs protégés doivent être considérées ensemble.

Une configuration de type soit-schéma a également une limite : elle préserve une alternative après qu'un schéma soit désactivé, mais elle ne protège pas contre un schéma compromis tant que ce schéma reste activé et autorisé indépendamment. La disponibilité après désactivation et la résistance à une clé compromise encore acceptée sont des propriétés distinctes.

Le statut des normes de ML-DSA aide à expliquer sa place dans la conception. Le NIST a finalisé le FIPS 204, qui spécifie ML-DSA, le 13 août 2024. Le NIST décrit toujours la normalisation de Falcon comme en cours. Le TIP-899 présente ML-DSA comme une alternative mise en œuvre à la normalisation de Falcon et au risque d'audit. Cela fournit un algorithme alternatif, plutôt qu'une autorisation de récupération automatique.

Le travail restant va au-delà de l'ajout d'un bouton de signature. Le TIP-899 appelle à un audit cryptographique externe et à un audit de mise en œuvre, à du matériel d'audit public et à une couverture de bug-bounty avant l'activation du mainnet. Les matériaux de proposition examinés ne fournissent pas de rapport d'audit indépendant complet.

La proposition et la discussion des développeurs du 15 juillet identifient également le travail de dérivation de portefeuille, de keystore, d'adaptation de SDK et de portefeuille matériel. La mise en œuvre du testnet et les outils de génération de clés ne prouvent pas que les portefeuilles consommateurs ou les dépositaires peuvent déjà effectuer toutes les opérations de migration et de récupération.

Une démonstration utile du testnet suivrait les autorisations à travers l'échec : désactiver le schéma, construire une transaction en utilisant uniquement les signatures survivantes, montrer quels transferts restent autorisés et montrer si le propriétaire existant peut remplacer les clés affectées. Le résultat devrait correspondre à la configuration que les utilisateurs détiennent réellement.

Si les deux schémas quantiques proposés étaient désactivés et qu'aucun ensemble de signatures valide ne pouvait atteindre le propriétaire ou le seuil actif pertinent, les règles décrites ne fourniraient aucun chemin ordinaire immédiat pour dépenser ou faire tourner les clés. Cela n'établit pas de perte permanente. La réactivation de la gouvernance ou un changement de protocole ultérieur seraient une autre voie de récupération ; le canal d'urgence plus rapide et les idées de récupération à connaissance nulle restent en dehors du champ actuel de cette proposition.

Pour les portefeuilles et les dépositaires, la continuité des paiements laisserait seule la question centrale de la récupération sans réponse. Une configuration de migration a besoin d'un chemin autorisé par le propriétaire survivant pour remplacer les clés ainsi que d'un moyen de déplacer des fonds, les deux chemins préservant son objectif de résistance quantique.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.