Algorand a franchi le 15 août le seuil nécessaire à l’adoption de sa mise à niveau v5.0.0. Le changement introduit notamment des comptes capables d’autoriser nativement des transactions avec des signatures Falcon-1024, conçues pour résister aux attaques d’un futur ordinateur quantique suffisamment puissant.

Mais ces règles ne sont pas encore actives sur le réseau principal. Un délai obligatoire de 208 000 rounds sépare le vote de l’activation. Et le mot « post-quantique » doit rester précisément délimité : il concerne un nouveau type de compte optionnel, pas l’ensemble du protocole ni les comptes existants.

Ce que le réseau a réellement validé

La version stable du logiciel go-algorand v5.0.0 a été publiée le 12 août. Elle contient une proposition de changement de consensus : les opérateurs peuvent installer le logiciel, puis le réseau vote avant que les nouvelles règles deviennent obligatoires.

Selon l’analyse publiée par Algorand Foundation le 16 août, le seuil de 90 % a été atteint le 15 août. L’état public du réseau principal, consulté par GatherHub le 17 août vers 13 h 05 à Paris, affichait 9 198 votes favorables sur une fenêtre de 10 000 rounds, pour un minimum requis de 9 000.

Le même relevé indiquait que l’ancien protocole restait actif et que le suivant était programmé à la ronde 64 318 659. Ce point corrige une formulation fréquente dans les titres : v5.0.0 a passé le vote, mais ses nouvelles règles ne fonctionnent pas encore sur mainnet. La ronde d’activation devrait être atteinte environ une semaine après le vote, sans qu’une heure civile puisse être garantie à l’avance.

Cette mécanique concerne directement les opérateurs de nœuds, les services d’indexation et les infrastructures qui lisent la chaîne. La release précise que les exploitants d’Indexer et de Conduit doivent également installer des versions compatibles. Un acteur resté sur un logiciel incapable de comprendre le nouveau protocole risque de ne plus suivre correctement le réseau après l’activation.

Ce qu’un compte Falcon change

Une signature numérique prouve qu’une transaction a été autorisée par le détenteur de la clé privée. Les comptes Algorand ordinaires utilisent Ed25519, une cryptographie à courbe elliptique considérée comme sûre face aux ordinateurs disponibles aujourd’hui. Un ordinateur quantique suffisamment puissant pourrait toutefois, en théorie, résoudre beaucoup plus efficacement le problème mathématique dont dépend cette sécurité.

Le NIST recommande de commencer les migrations post-quantiques, car modifier des systèmes, des clés et des logiciels prend du temps. L’institut américain a sélectionné FALCON parmi les algorithmes de signature destinés à sa standardisation post-quantique.

Algorand savait déjà vérifier une signature Falcon dans un programme LogicSig. v5.0.0 fait de Falcon-1024 un mode d’autorisation natif, au même niveau fonctionnel qu’une signature Ed25519 ou un multisig. D’après la note technique de John Jannotti, l’adresse du compte est construite de manière à ne pas correspondre à un point Ed25519 valide. Même si Ed25519 devenait cassable, un attaquant ne pourrait donc pas simplement fabriquer une signature classique pour prendre le contrôle de cette adresse.

Cette protection reste volontaire. Un utilisateur doit créer ou adopter un compte Falcon ; v5.0.0 ne convertit pas automatiquement les adresses existantes. Les clés de consensus, les fonctions aléatoires vérifiables et d’autres composants doivent encore évoluer dans la feuille de route post-quantique d’Algorand. Dire que « la blockchain Algorand est désormais résistante au quantique » serait donc excessif.

Une protection qui occupe plus de place

Falcon-1024 apporte aussi un coût mesurable. Une clé publique atteint 1 793 octets et une signature peut aller jusqu’à 1 423 octets, contre 64 octets pour une signature Ed25519. La clé publique doit être incluse au moment de la dépense, car elle ne tient pas dans l’adresse de 32 octets.

Le protocole ne sait pas non plus vérifier par lot de nombreuses signatures Falcon comme il peut le faire avec Ed25519. Chaque signature post-quantique doit être contrôlée séparément. La note technique chiffre donc son usage à deux frais minimum supplémentaires : une transaction Falcon coûte trois frais minimum au total, contre un pour une transaction ordinaire comparable.

Ce compromis explique le deuxième grand changement de v5.0.0 : la tarification selon les ressources. Une transaction plus volumineuse ou plus exigeante paie davantage. Les opérations déjà légales avant la mise à niveau conservent toutefois leurs allocations et leur coût minimum actuel. Il ne s’agit donc pas d’une hausse générale des frais pour les paiements simples.

Les frais supplémentaires rejoignent le réservoir qui finance les récompenses des opérateurs de nœuds. Algorand présente ce mécanisme comme une première étape vers un financement plus directement lié à l’usage de l’infrastructure. Cette intention ne démontre pas encore que les recettes suffiront à soutenir le réseau : il faudra observer les volumes réellement facturés après activation.

Des contrats plus grands et plus ouverts

La mise à niveau ne se limite pas à Falcon. La taille maximale combinée du programme d’approbation et du programme de sortie d’un contrat passe de 8 192 à 16 384 octets. Une application existante pourra aussi augmenter sa taille sans changer d’identifiant ni migrer tout son état, avec un mécanisme de sponsor pour le solde minimum associé.

AVM v13 ajoute des opérations cryptographiques comme Poseidon2 et permet à une application d’accéder aux « boxes » d’une autre application si celle-ci l’autorise explicitement. Cette condition est importante : les données on-chain étaient déjà observables publiquement, mais le droit de lecture ou d’écriture par un autre contrat n’est pas ouvert par défaut.

La release retire par ailleurs l’ancien endpoint `dryrun` et l’outil `tealdbg` au profit de `simulate`. Pour les développeurs, l’enjeu n’est donc pas seulement de bénéficier de nouvelles fonctions. Les outils de calcul des frais, de test et d’indexation doivent suivre le changement.

Le cours GatherHub Blockchain explique comment les règles communes d’un réseau sont appliquées par ses validateurs. Ici, la disponibilité d’un binaire ne suffit pas : le vote, le délai en rounds et l’adoption opérationnelle forment trois étapes distinctes.

Pourquoi cela compte maintenant

L’intérêt de v5.0.0 n’est pas qu’un ordinateur quantique menace actuellement les comptes Algorand. Aucune machine disponible n’est connue pour casser Ed25519. L’intérêt est de tester dès aujourd’hui la gestion des clés, les formats de transaction, les frais et les logiciels nécessaires à une migration qui serait risquée si elle devait être improvisée dans l’urgence.

Le choix natif permet aussi de mesurer le prix réel de cette précaution : davantage d’octets dans les blocs, une vérification séparée et des frais supérieurs. Il rend le débat plus concret qu’une promesse générale de « quantum safety ».

La limite principale est l’adoption. Sans support dans les portefeuilles, les kits de développement, les systèmes de conservation et les procédures de récupération, une primitive disponible dans le protocole peut rester peu utilisée. La sécurité dépendra aussi de la qualité de l’implémentation, de la protection des clés et des futurs audits, pas seulement du choix mathématique de Falcon.

À suivre

Le premier contrôle sera la ronde 64 318 659 : il faudra vérifier que le réseau active bien le nouveau protocole et que les services d’indexation restent synchronisés. Le deuxième sera l’usage, avec le nombre de comptes Falcon créés, les premières transactions et leurs frais observés.

Il faudra ensuite suivre le support des principaux portefeuilles et dépositaires, ainsi que les prochaines étapes de la feuille de route : multisignature post-quantique, autres variantes Falcon et migration des composants de consensus. Avant ces preuves, v5.0.0 constitue une option post-quantique native et un changement de tarification important — pas une immunité quantique complète du réseau.

Sources consultées