Les développeurs d'Ethereum ont soumis une proposition qui donnerait au code on-chain la capacité de vérifier ce qu'une transaction a réellement modifié — et d'annuler l'intégralité de la transaction si le résultat enfreint des règles définies à l'avance par l'utilisateur. Ce concept, connu sous le nom d'assertions de transaction natives, a été mis en avant par la Ethereum Foundation dans un article de blog publié le 5 octobre 2026.

La proposition cible l'une des faiblesses les plus anciennes et les plus persistantes de la sécurité des crypto-monnaies : la signature à l'aveugle.

Le problème de la signature à l'aveugle

La signature à l'aveugle est l'équivalent crypto du fait d'accepter des conditions générales sans les lire. Un portefeuille présente une requête, les détails sont illisibles ou peu clairs, et l'utilisateur approuve quand même. La plupart du temps, rien ne se passe mal, mais quand cela arrive, les conséquences sont souvent coûteuses. Cette faiblesse est liée à la manière dont les transactions Ethereum sont construites : la charge utile signée est une donnée au format machine plutôt qu'un texte en langage clair, donc ce qui s'affiche sur l'écran d'un portefeuille n'est que l'interprération de ces données par une interface.

La Ethereum Foundation a présenté ces nouveaux travaux comme une réponse directe à ces risques, signalés dans le cadre de son initiative Trillion Dollar Security. Ce programme comprend déjà des mesures comme Clear Signing, qui vise à rendre les requêtes de transaction lisibles avant leur approbation par l'utilisateur.

Les assertions de transaction natives interviennent à une autre étape du processus. Clear Signing cherche à aider l'utilisateur à comprendre une transaction avant son exécution. Les assertions vérifient si le résultat correspond aux attentes après son exécution.

À l'intérieur de l'EIP-7906

Le cœur technique de la proposition est l'EIP-7906, qui introduit trois nouveaux opcodes dans la machine virtuelle Ethereum : TXTRACE, TXDIFF et EVENTDATACOPY. Les opcodes sont les instructions de bas niveau que l'EVM comprend ; en ajouter élargit donc ce que le code des smart contracts peut voir et faire.

En l'occurrence, ces nouvelles instructions donnent au code on-chain un moyen d'inspecter les changements d'état réels produits par une transaction. vérification passe ainsi de ce qu'une transaction prétend faire à ce qu'elle a démontré avoir fait.

Son articulation avec l'EIP-8141

L'EIP-7906 ne se suffit pas à lui-même. Il repose sur le cadre posé par l'EIP-8141, connu sous le nom de format de transaction à frames. Les formats de transaction sont une infrastructure fondamentale : chaque nœud, portefeuille et outil de développement doit pouvoir les traiter, donc à ce niveau l'impact concerne l'ensemble de la pile.

Les frame transactions divisent une transaction unique en segments distincts, ou frames. L'EIP-7906 ajoute un nouvel élément à cette structure : une frame POST_TX.

La frame POST_TX fonctionne comme un static call pendant l'exécution. Un static call est une opération en lecture seule, ce qui signifie qu'elle peut examiner l'état mais pas le modifier. Si les conditions définies dans cette frame ne sont pas remplies, les effets de la transaction peuvent être annulés.

État d'avancement et calendrier

Rien de tout cela n'est encore actif. L'EIP-7906 reste au stade de draft. Selon le processus de développement d'Ethereum, un draft doit passer la revue et obtenir l'acceptation des développeurs coordonnant une mise à niveau avant que ses changements n'atteignent le réseau. L'objectif est de l'inclure dans la mise à niveau Hegotá, dont le déploiement est attendu en 2027.

Des démonstrations préliminaires ont déjà été menées sur un réseau de développement, ce qui suggère que la mécanique fonctionne au-delà du livre blanc. L'EIP-7906 dépend également de l'EIP-8141, si bien que son sort est lié à l'adoption du format de transaction à frames.

Pourquoi c'est important au-delà du code

Les assertions natives déplaceraient une partie du fardeau du risque de signature vers la couche de base. Si le protocole peut imposer directement des contrôles de résultat, les utilisateurs deviennent moins dépendants de la perfection de la logique d'affichage d'un portefeuille quelconque.

Pour les institutions et les entreprises, l'intérêt est évident. Les organisations qui déplacent des sommes importantes veulent généralement des garanties, pas de simples bons efforts. Un mécanisme capable d'annuler automatiquement une transaction dont les résultats sortent des paramètres définis s'intègre naturellement aux contrôles de risque que ces acteurs utilisent déjà ailleurs.

Des questions ouvertes subsistent. Les développeurs devront également déterminer comment les utilisateurs ordinaires définissent les règles que leurs transactions doivent respecter, car un filet de sécurité nécessitant une configuration experte pourrait finir par ne protéger que les experts. La couche d'utilisabilité construite sur l'EIP-7906 pourrait compter autant que les opcodes eux-mêmes.

Un compromis est aussi à peser. Chaque nouvel opcode élargit la surface à implémenter et à auditer sur les multiples clients Ethereum. Les améliorations de sécurité qui introduisent de nouveaux cas limites doivent justifier ce coût.

Les indicate à surveiller incluent la sortie de l'EIP-7906 du stade de draft, l'obtention d'une place pour l'EIP-8141 dans Hegotá, et la poursuite des tests devnet après les premières démonstrations.