Les développeurs d’Ethereum ont ouvert le tri de Hegotá, la mise à niveau qui doit succéder à Glamsterdam. Selon Toni Wahrstätter, chercheur à l’Ethereum Foundation et coauteur de plusieurs propositions, 66 changements étaient encore « sur la table » le 16 août. Ce nombre décrit un vivier de candidats, pas le contenu d’une version prête à être activée.

Parmi eux, un ensemble autour des « Frame Transactions » pourrait rendre les portefeuilles plus flexibles et réduire l’infrastructure externe dont certaines applications de paiement privé ont besoin. Mais ces textes restent des brouillons. Ils ne rendraient pas non plus les transferts ordinaires d’ether confidentiels.

Ce qui a réellement changé

Le fait nouveau n’est pas une activation sur Ethereum. C’est le passage d’une phase de collecte à une phase de sélection. Dans le dossier de la réunion All Core Devs Execution du 13 août, les développeurs indiquent que la liste des propositions candidates, ou PFI pour « proposed for inclusion », doit être finalisée environ deux semaines plus tard. Tout texte sans responsable clairement identifié doit être écarté automatiquement.

Les équipes qui maintiennent les principaux clients Ethereum doivent ensuite publier leurs préférences d’ici au 10 septembre. Cette étape compte : une idée peut être techniquement intéressante sans disposer de plusieurs implémentations, d’un calendrier de test réaliste ou d’un consensus suffisant pour entrer dans une mise à niveau.

Le chiffre de 66 vient d’un message public de Toni Wahrstätter daté du 16 août. Il rassemble des propositions de maturité et de portée très différentes. Certaines concernent le prix du calcul ou la mémoire, d’autres les validateurs, la résistance quantique, la construction des blocs ou le fonctionnement des comptes.

Le terme « Hegotá » ne désigne donc pas encore un paquet figé. CoinDesk a corroboré le début de ce tri et relevé que les prochaines réunions doivent réduire la liste avant les implémentations, les devnets et les testnets. Présenter les 66 propositions comme une feuille de route adoptée serait trompeur.

Frame Transactions : modifier la structure d’une transaction

L’EIP-8141, encore marquée « Draft », propose un nouveau type de transaction décomposé en « frames ». Certaines frames vérifient l’autorisation, d’autres approuvent le paiement des frais ou exécutent les actions demandées. Le protocole pourrait ainsi accepter des règles de validation différentes de la signature classique imposée aujourd’hui aux comptes ordinaires.

Pour un utilisateur, les effets possibles sont concrets : changer de clé sans déplacer le compte, regrouper plusieurs actions, faire payer les frais par un tiers ou adopter à terme un autre système cryptographique. Pour un portefeuille, cette souplesse rapproche des fonctions aujourd’hui construites par des contrats et des relais d’un format compris directement par le protocole.

L’ordre du jour du 13 août précise que les Frames sont « considered for inclusion », ou CFI, pour Hegotá. Ce statut est plus avancé qu’une simple candidature, mais ce n’est ni une spécification finale, ni une promesse de déploiement. Le même document signale d’ailleurs une objection sur la compatibilité avec l’EVM et mentionne une direction concurrente pour l’abstraction des comptes.

Le cours GatherHub Blockchain explique pourquoi une modification des règles communes exige l’accord et la mise à jour de plusieurs logiciels indépendants. Une EIP publiée n’est pas du code actif : elle doit encore être implémentée, testée et retenue dans les spécifications du fork.

Ce que le paquet peut apporter aux applications privées

Deux brouillons complémentaires expliquent l’intérêt actuel pour la confidentialité. L’EIP-8250 propose des compteurs de transactions indépendants, appelés « keyed nonces ». Une application privée peut faire passer plusieurs utilisateurs par une adresse partagée afin de ne pas relier automatiquement chaque activité à une adresse personnelle. Avec un compteur unique, une transaction retardée peut bloquer toutes celles qui suivent. Des domaines séparés réduiraient ce goulot d’étranglement.

L’EIP-8272 permettrait à une transaction de référencer une racine cryptographique récente déjà vérifiée par le protocole. Une application pourrait prouver qu’une dépense se rattache à un ensemble d’engagements récent sans lire, pendant la validation, un état externe susceptible de changer. Le texte vise explicitement les arbres d’engagement utilisés par les systèmes de confidentialité.

Ces deux mécanismes dépendent de l’EIP-8141 et restent eux aussi au stade de brouillon. Ils améliorent la plomberie dont une application privée peut se servir ; ils ne masquent aucune donnée par eux-mêmes. La preuve cryptographique, la gestion des engagements et les règles de révélation restent à la charge de l’application.

Un virement classique d’ETH entre deux adresses continuerait donc d’être public. Les montants, les adresses et l’historique resteraient lisibles. Même dans une application spécialisée, les métadonnées réseau, les entrées et sorties vers des plateformes régulées ou une mauvaise réutilisation d’adresse peuvent rétablir des liens entre l’utilisateur et ses opérations.

Confidentialité et résistance à la censure ne sont pas la même chose

Hegotá doit aussi intégrer des changements qui ne cherchent pas à cacher les transactions. L’EIP-7805, appelée FOCIL, propose qu’un comité de validateurs produise des listes de transactions à inclure. Les attestateurs refuseraient de soutenir un bloc qui omet une transaction encore valide figurant dans ces listes.

L’objectif est la résistance à la censure : réduire le pouvoir d’un constructeur de bloc dominant d’écarter une transaction. Cela ne chiffre ni l’adresse, ni le montant, ni le contenu de l’opération. Une transaction peut être difficile à censurer tout en restant entièrement publique ; elle peut aussi être cryptographiquement privée tout en dépendant d’un petit nombre de relais susceptibles de la bloquer.

Cette distinction évite une conclusion trop large. Hegotá réunit plusieurs chantiers qui touchent à la manière d’envoyer et d’inclure des transactions, mais ils ne résolvent pas le même problème et n’avancent pas au même rythme.

Les risques d’une transaction plus programmable

Déplacer davantage de logique dans le protocole peut supprimer des intermédiaires, mais augmente aussi la surface que tous les clients doivent implémenter exactement de la même manière. Une divergence sur la validation, le calcul des frais ou l’ordre d’exécution pourrait provoquer des transactions rejetées différemment, voire un désaccord entre nœuds.

Les Frame Transactions introduisent plusieurs modes, des signatures multiples, un payeur distinct et jusqu’à 64 frames dans le brouillon actuel. Les keyed nonces et les racines récentes ajoutent encore de l’état et des règles de validité. Ces choix doivent être évalués contre les risques de déni de service, les coûts en gaz, la complexité des mempools et la capacité des portefeuilles à présenter clairement ce que l’utilisateur autorise.

La confidentialité crée aussi un arbitrage réglementaire et opérationnel. Une entreprise peut vouloir protéger sa paie ou sa trésorerie sans faciliter des flux impossibles à auditer. La technique ne décide pas seule quelles informations doivent être visibles, par qui et dans quelles circonstances.

À suivre

La prochaine réunion All Core Devs Consensus du 20 août doit de nouveau traiter Hegotá. La liste PFI est attendue vers la fin août, puis les préférences des clients le 10 septembre. Ce sont des jalons de sélection, pas des dates d’activation.

Il faudra ensuite surveiller les implémentations dans plusieurs clients, les devnets, les résultats de tests et le maintien ou non du paquet EIP-8141/8250/8272. Tant que ces étapes ne sont pas franchies, la conclusion GatherHub reste limitée : Ethereum étudie une base plus native pour des transactions programmables et certaines applications privées ; il ne lance pas encore un réseau confidentiel.

Sources consultées