La Fondation Ethereum examine les assertions EIP-7906 pour vérifier l’état final des transactions

Les chercheurs de la Fondation Ethereum examinent des assertions de transaction natives qui pourraient faire dépendre la sécurité des transactions de l’état final ainsi que des instructions signées. Cette recherche, détaillée dans un document publié le 5 octobre 2026, vise à atténuer les risques spécifiques liés à la manière dont les utilisateurs approuvent actuellement les actions sur le réseau.

Définir l’écart de signature

La fondation distingue deux manières principales dont les utilisateurs peuvent approuver des actions avec des résultats indésirables : la signature aveugle et les résultats d’exécution incertains. Une signature de transaction prouve l’autorisation de certains octets spécifiques, mais ne garantit pas qu’une interaction complexe avec un contrat intelligent atteindra l’objectif économique prévu par le signataire. La recherche proposée explore des vérifications qui inspectent les changements nets de solde, de stockage ou de code après l’exécution. Si une règle requise échoue, le mécanisme révoquerait la transaction.

Les vérifications indépendantes des soldes finaux ou des approbations visent à réduire l’écart entre la signature et l’objectif économique. Cependant, la fondation note que des assertions provenant d’une interface compromise pourraient toujours encoder un résultat nocif, ce qui signifie que la solution n’est pas une garantie universelle de sécurité pour tous les scénarios.

EIP-7906 et limites d’implémentation

L’EIP-7906 est identifié comme une voie possible pour cette implémentation. La proposition utilise un cadre post-transaction en lecture seule pour évaluer les changements et les événements avant d’accepter le résultat. La fondation indique que l’EIP-7906 est à l’étude mais n’est pas encore confirmé pour une mise à niveau future. Même s’il est adopté, le mécanisme exigerait toujours que les portefeuilles ou les protocoles appliquent une règle spécifique.

Le travail reste au stade de la recherche et de la proposition, et non une nouvelle fonctionnalité de sécurité disponible pour les transactions Ethereum ordinaires aujourd’hui. Les ingénieurs doivent prendre en compte les applications existantes, les opérateurs de nœuds, la compatibilité des clients et le comportement des erreurs dans des conditions de stress. Les choix de conception incluent la détermination de qui définit la règle, le coût en gaz, et si un logiciel tiers peut l’omettre silencieusement.

Les métriques de performance telles que le débit, la finalité, la réactivité, le coût et la tolérance aux pannes sont des mesures distinctes. Améliorer une métrique n’améliore pas automatiquement toutes les autres, en particulier lorsqu’un portefeuille, un échange ou une application ajoute ses propres confirmations. Le développement s’inscrit dans un changement plus large vers la sécurité des portefeuilles, où les utilisateurs recherchent la clarté et un accès prévisible, les opérateurs veulent des contrôles fiables et des coûts maîtrisables, et les institutions exigent une responsabilisation en cas d’échec.

Les mises à jour futures doivent être distinguées entre les fonctionnalités publiées, les fonctionnalités planifiées et l’utilisation mesurée. Les domaines clés à surveiller incluent la gouvernance des EIP, les implémentations des portefeuilles, le support des protocoles et les tests des opcodes de différence d’état proposés. Le test opérationnel consiste à savoir si différentes équipes de clients peuvent implémenter la fonctionnalité, si les développeurs peuvent mettre à niveau en toute sécurité et si les utilisateurs peuvent s’y fier lors des pics d’activité. L’article a été édité par Samuel Rae.