$NEAR prend en charge la signature des comptes résistante aux attaques quantiques, mais cela ne signifie pas que l’ensemble de la chaîne a achevé sa migration vers la résistance quantique. Le sujet actuellement à la sixième place sur la place mérite d’être examiné en détail, mais les étapes techniques auxquelles il se rapporte datent de juillet et de septembre : il ne faut pas les présenter comme une nouvelle fonctionnalité lancée aujourd’hui.
Le premier niveau concerne la manière dont un compte autorise les transactions. nearcore 2.13.0, publié le 9 juillet, indique que ML-DSA-65 devient le troisième type de signature de transaction et de clé d’accès, aux côtés des deux types existants. Ce changement offre aux comptes une nouvelle option de vérification des signatures. Il ne remplace toutefois pas automatiquement les clés de tous les comptes existants, et ne permet pas d’affirmer que tous les comptes ont adopté le nouvel algorithme.
Le deuxième niveau concerne la capacité d’un contrat à vérifier un message. La version candidate 2.14.0-rc.1 pour le testnet, datée du 16 septembre, ajoute l’interface ml_dsa_verify afin que les contrats puissent vérifier des messages. Il s’agit d’un point d’entrée différent de l’autorisation native des transactions par un compte : le fait qu’un contrat puisse vérifier une signature ne prouve pas directement que toutes les opérations qu’il contrôle, les actifs externes ou les messages inter-chaînes ont achevé leur migration sécurisée. Une version candidate de test ne doit pas non plus être présentée comme déjà déployée sur le mainnet.
Le troisième niveau concerne l’étendue de la migration de l’ensemble du système. La signature des comptes n’en est qu’un élément. La version du protocole utilisée par les nœuds, la mise à jour des clés existantes et le traitement des autres dépendances nécessitent chacun des preuves distinctes. On ne peut pas déduire de l’adoption d’un nouvel algorithme par un module que toutes les couches du système bénéficient des mêmes garanties.
Il faut également distinguer les dates. Le compte rendu de développement du 2 juillet présente une démonstration d’ajout de clé et de transfert dans un environnement sandbox ; le 9 juillet correspond à la publication d’une version destinée au mainnet ; cette version mentionne par ailleurs un projet de lancement du vote sur le protocole le 20 juillet. Une démonstration réussie, la publication d’une version, un projet de vote et l’activation effective sur le réseau ne correspondent pas au même état d’achèvement. Les résultats de la mise à niveau de l’ensemble du réseau n’ayant pas été vérifiés dans le cadre de cette analyse, la date prévue n’est pas présentée comme une confirmation de déploiement.
Pour les utilisateurs ordinaires, la question concrète est de savoir si leur compte est effectivement configuré avec ce type de clé d’accès, si leur portefeuille sait la générer, la stocker et l’utiliser pour signer correctement, et si l’application prend en charge le processus correspondant. Le simple fait de voir un titre d’actualité ne permet pas de conclure que le compte que l’on utilise est déjà protégé par le nouveau schéma de signature. Après l’ajout d’une nouvelle clé, il faut également vérifier les autorisations de l’ancienne clé en fonction de la configuration réelle du compte.
Pour les développeurs, il faut distinguer les transactions natives des comptes et la vérification des messages par les contrats. Les premières déterminent qui peut autoriser les opérations d’un compte ; la seconde détermine comment un programme vérifie la validité d’un message. Même si la vérification de la signature réussit, cela ne garantit pas que le contenu du message, l’étendue des autorisations ou la logique métier soient corrects par nature. Les limites de sécurité doivent être définies en fonction du processus d’autorisation réellement utilisé.
Les prochains points vérifiables qui m’intéressent sont les versions officielles et les traces d’activation du protocole, la prise en charge par les portefeuilles et les consignes de migration explicites. À ce stade, on peut confirmer que NEAR fait progresser différentes capacités au niveau de la vérification des signatures des comptes et des contrats ; on ne peut pas confirmer que tous les anciens comptes, toutes les applications et toutes les dépendances externes ont achevé leur migration en même temps. Il s’agit d’une observation sur le périmètre technique, et non d’une prévision du cours de la monnaie déduite du nom de l’algorithme.
Le premier niveau concerne la manière dont un compte autorise les transactions. nearcore 2.13.0, publié le 9 juillet, indique que ML-DSA-65 devient le troisième type de signature de transaction et de clé d’accès, aux côtés des deux types existants. Ce changement offre aux comptes une nouvelle option de vérification des signatures. Il ne remplace toutefois pas automatiquement les clés de tous les comptes existants, et ne permet pas d’affirmer que tous les comptes ont adopté le nouvel algorithme.
Le deuxième niveau concerne la capacité d’un contrat à vérifier un message. La version candidate 2.14.0-rc.1 pour le testnet, datée du 16 septembre, ajoute l’interface ml_dsa_verify afin que les contrats puissent vérifier des messages. Il s’agit d’un point d’entrée différent de l’autorisation native des transactions par un compte : le fait qu’un contrat puisse vérifier une signature ne prouve pas directement que toutes les opérations qu’il contrôle, les actifs externes ou les messages inter-chaînes ont achevé leur migration sécurisée. Une version candidate de test ne doit pas non plus être présentée comme déjà déployée sur le mainnet.
Le troisième niveau concerne l’étendue de la migration de l’ensemble du système. La signature des comptes n’en est qu’un élément. La version du protocole utilisée par les nœuds, la mise à jour des clés existantes et le traitement des autres dépendances nécessitent chacun des preuves distinctes. On ne peut pas déduire de l’adoption d’un nouvel algorithme par un module que toutes les couches du système bénéficient des mêmes garanties.
Il faut également distinguer les dates. Le compte rendu de développement du 2 juillet présente une démonstration d’ajout de clé et de transfert dans un environnement sandbox ; le 9 juillet correspond à la publication d’une version destinée au mainnet ; cette version mentionne par ailleurs un projet de lancement du vote sur le protocole le 20 juillet. Une démonstration réussie, la publication d’une version, un projet de vote et l’activation effective sur le réseau ne correspondent pas au même état d’achèvement. Les résultats de la mise à niveau de l’ensemble du réseau n’ayant pas été vérifiés dans le cadre de cette analyse, la date prévue n’est pas présentée comme une confirmation de déploiement.
Pour les utilisateurs ordinaires, la question concrète est de savoir si leur compte est effectivement configuré avec ce type de clé d’accès, si leur portefeuille sait la générer, la stocker et l’utiliser pour signer correctement, et si l’application prend en charge le processus correspondant. Le simple fait de voir un titre d’actualité ne permet pas de conclure que le compte que l’on utilise est déjà protégé par le nouveau schéma de signature. Après l’ajout d’une nouvelle clé, il faut également vérifier les autorisations de l’ancienne clé en fonction de la configuration réelle du compte.
Pour les développeurs, il faut distinguer les transactions natives des comptes et la vérification des messages par les contrats. Les premières déterminent qui peut autoriser les opérations d’un compte ; la seconde détermine comment un programme vérifie la validité d’un message. Même si la vérification de la signature réussit, cela ne garantit pas que le contenu du message, l’étendue des autorisations ou la logique métier soient corrects par nature. Les limites de sécurité doivent être définies en fonction du processus d’autorisation réellement utilisé.
Les prochains points vérifiables qui m’intéressent sont les versions officielles et les traces d’activation du protocole, la prise en charge par les portefeuilles et les consignes de migration explicites. À ce stade, on peut confirmer que NEAR fait progresser différentes capacités au niveau de la vérification des signatures des comptes et des contrats ; on ne peut pas confirmer que tous les anciens comptes, toutes les applications et toutes les dépendances externes ont achevé leur migration en même temps. Il s’agit d’une observation sur le périmètre technique, et non d’une prévision du cours de la monnaie déduite du nom de l’algorithme.