L’ordre du jour des développeurs principaux du 6 août a décrit la date comme une date limite pour soumettre des propositions, et non comme une décision sur l’ensemble final des fonctionnalités de Hegota.

Frame Transactions fait partie des propositions actuellement examinées. Deux projets dépendants, Keyed Nonces et Recent Roots, montrent comment ce modèle de transaction pourrait prendre en charge les portefeuilles et les applications de confidentialité s’il est adopté.

Frame Transactions découpe une transaction en étapes programmables

EIP-8141, connu sous le nom de Frame Transactions, propose un nouveau type de transaction Ethereum composé de frames programmables.

Différents frames pourraient valider une action, approuver le paiement du gas ou exécuter l’appel prévu par l’utilisateur. Certains frames pourraient également être regroupés en un lot atomique : si l’un échoue, les modifications d’état effectuées par les autres frames de ce lot seraient annulées.

Cette structure pourrait offrir aux portefeuilles des options natives supplémentaires pour le regroupement, la rotation des clés et l’autorisation de transactions complexes. Elle pourrait aussi permettre à un compte ou à un service de payer le gas tandis qu’un autre compte autorise l’action. Cela rend la proposition pertinente au-delà des outils de confidentialité, car elle touche à la manière dont les comptes délèguent et coordonnent les actions on-chain.

Keyed Nonces crée des domaines distincts de protection contre le rejeu

Ethereum utilise normalement un nonce séquentiel unique pour chaque compte. Ce nombre détermine l’ordre des transactions et empêche l’exécution deux fois de la même transaction.

EIP-8250 remplacerait ce nonce unique pour les Frame Transactions par un ensemble de clés de nonce et un numéro de séquence. Les transactions utilisant des ensembles de clés non chevauchants et non nuls seraient indépendantes vis-à-vis du rejeu.

Cela compte pour les protocoles de confidentialité qui utilisent un expéditeur partagé, afin que chaque utilisateur n’expose pas une adresse d’expéditeur publique distincte. Avec une seule séquence de nonce, une action retardée peut interférer avec des actions sans rapport soumises via cet expéditeur.

Keyed Nonces répond à cette contrainte de protection contre le rejeu, mais n’apporte pas la confidentialité à lui seul. Les clés de nonce restent visibles dans les données de transaction.

La proposition conserve également la règle d’EIP-8141 n’autorisant qu’une seule Frame Transaction en attente par expéditeur dans le mempool public. Des domaines de nonce séparés ne permettraient donc pas, à eux seuls, de laisser plusieurs Frame Transactions du même expéditeur en attente publique simultanément.

Recent Roots évite les lectures de stockage mutable pendant la validation

Les applications de confidentialité utilisent souvent un arbre d’engagements, une racine récente représentant les engagements contre lesquels un utilisateur peut prouver une dépense.

La validation d’une Frame Transaction ne peut pas lire un stockage externe arbitraire contrôlé par une autre application. Ce stockage pourrait changer pendant qu’une transaction est en attente.

EIP-8272, connu sous le nom de Recent Roots, propose une alternative limitée. Une source de racine écrirait des racines dans un contrat système, tandis qu’une Frame Transaction pourrait nommer une source, un emplacement et une racine précis dans ses données signées.

Les clients Ethereum vérifieraient cette référence avant l’exécution du frame. L’application pourrait alors valider une preuve par rapport à une racine d’engagement récente sans dépendre d’un stockage externe changeant pendant la validation.

La proposition autorise jusqu’à 16 références de racine dans une seule transaction et limite la durée de validité de chacune.

Elle ne rendrait pas les transferts ETH ordinaires privés. Elle fournirait une couche d’infrastructure que les applications de confidentialité pourraient utiliser aux côtés de Frame Transactions, ce qui explique pourquoi la conception est présentée comme un élément de base plutôt que comme un système de confidentialité complet.

La date limite n’a pas finalisé Hegota

Les trois EIP sont encore des brouillons. EIP-8250 et EIP-8272 requièrent également EIP-8141, de sorte qu’aucune des deux ne pourrait être activée indépendamment.

La date limite du 6 août a seulement fermé la fenêtre pour les nouvelles propositions non principales. Les développeurs doivent encore décider si Frame Transactions doit faire partie de Hegota et, si oui, si les conceptions dépendantes sont prêtes à suivre. En pratique, cela signifie que l’examen porte toujours sur l’adéquation et la maturité, et pas seulement sur l’intérêt technique des idées.

Cette combinaison de flexibilité des comptes, de confidentialité et de résilience cryptographique apparaît également dans l’évolution de la feuille de route d’Ethereum. Mais pour l’instant, il s’agit de propositions à l’étude, et non de fonctionnalités disponibles pour les utilisateurs d’Ethereum.

Avertissement : cet article est fourni à titre informatif uniquement. EIP-8141, EIP-8250 et EIP-8272 sont des propositions de brouillon susceptibles d’évoluer, d’être exclues de Hegota ou de ne jamais être activées.

Méthodologie : cet article s’appuie sur l’ordre du jour officiel des développeurs de Hegota et sur les spécifications de brouillon pour EIP-8141, EIP-8250 et EIP-8272.