Ethereum impose déjà certaines limites financières
Uniswap v3 dispose aujourd’hui d’une sauvegarde concrète. Son routeur de swap rejette un swap à saisie exacte lorsque le montant reçu est inférieur au reçu minimum, amountOutMinimum. Pour un échange de sortie exacte, il rejette les dépenses supérieures à l’entrée maximale, amountInMaximum. Ce sont des conditions de temps d’exécution fournies dans les paramètres d’appel.
La distinction entre avoir une condition et choisir une valeur solide apparaît dans le propre guide d’échange unique d’Uniswap. Son exemple simplifié fixe le rendement minimum à zéro, avertit explicitement que cela est risqué en production et oriente les développeurs vers un kit de développement logiciel, un oracle de prix ou une autre source de données pour une valeur plus sûre.
Un reçu minimum est une quantité symbolique et non un jugement quant à savoir si l’échange est une bonne affaire. Si un constructeur fixe un plancher qui permet une très petite réception, un résultat juste au-dessus de ce plancher est adopté. Déduire le plancher d’un devis déjà médiocre permettrait de préserver cette mauvaise affaire tout en appliquant correctement la limite.
D’autres protections abordent différentes parties du problème. Plus tôt cette année, le groupe de travail Ethereum a annoncé la norme Clear Signing le 12 mai 2026. Elle fournit des descriptions structurées que les portefeuilles peuvent présenter aux utilisateurs, avec des examens et attestations indépendants et des sources fiables sélectionnées par portefeuille. Cela aide un signataire à comprendre l’action demandée. Cette description n’impose pas elle-même un résultat financier minimum.
La simulation prédit les effets sur un état de chaîne sélectionné. L’état peut changer avant que la transaction n’atteigne un bloc. Pendant ce temps, les gardes des comptes intelligents Safe peuvent vérifier les paramètres avant l’exécution et l’état final du Safe par la suite, bloquant les transactions selon les règles configurées.
Ce que les assertions de transaction Ethereum ajouteraient
EIP-7906 propose une vision plus large des effets de la transaction. Il s’appuie sur les cadres ordonnés d’EIP-8141, qui séparent les étapes de validation et d’action, et ajoute des éléments en lecture seule. POST_TX cadres à la fin. Le code d’assertion inspecterait l’état résultant et rejetterait l’exécution qui viole sa règle.
Les instructions proposées divisent ce travail en trois opérations : TXTRACE énumère les changements et événements nets spécifiés, TXDIFF récupère les valeurs par clé, et EVENTDATACOPY rend les données d’événement disponibles pour l’assertion. Leur portée définie inclut les soldes ETH natifs, les modifications de stockage, les contrats nouvellement déployés et les hachages de code. Les contrôles du solde des jetons devraient interpréter le stockage contractuel concerné et appliquer la limite sélectionnée.
Cela pourrait rendre possibles des politiques allant au-delà du résultat minimum d’un échange. Un compte peut exiger que sa configuration de contrôle reste intacte, ou une politique peut restreindre les approbations et vérifier les effets sur les contrats impliqués dans un itinéraire.
La vue est toujours un résultat net. Les écritures multiples sur un emplacement de stockage se réduisent à ses valeurs de départ et de fin ; un emplacement restauré à sa valeur d’origine disparaît de l’énumération des changements nets.
Qui doit exiger et protéger le chèque
La proposition n’exige pas que chaque transaction contienne une assertion. Un compte qui en dépend doit configurer sa logique de validation pour exiger le POST_TX cadre sans bypass.
Un protocole a une obligation connexe. Sa fonction protégée devrait appliquer l’assertion exacte requise, en rejetant les transactions ordinaires et en encadrant les transactions avec des contrôles manquants ou incorrects. Dans les flux de règlement dans lesquels un solveur choisit la voie d’exécution de la transaction, la protection du résultat d’un utilisateur nécessite que l’ordre signé ou le protocole de règlement lie le solveur à la politique. La garantie du solveur proposée s’applique à une transaction sur un réseau.
La politique doit aussi survivre aux actions qu’elle est censée juger. Les directives de sécurité de l’EIP-7906 appellent à des cibles d’assertion immuables et non évolutives. Dans le cas contraire, une transaction pourrait modifier le contrat d’exécution après validation et avant le contrôle final. Les orientations indiquent également clairement que la validation de l’objectif visé dépend de la validation effectuée avant les changements d’état.
Même un code d’assertion inchangé peut lire une référence compromise. La spécification met en garde contre les prix, les registres, les proxys et autres états que l’organisme d’exécution peut modifier avant l’exécution de l’assertion. Si une transaction modifie le prix utilisé pour décider si son propre résultat est acceptable, la lecture de l’état final réel ne sauve pas la comparaison.
EIP-7906 recommande des valeurs de référence fixées à la signature ou tirées de l’état au début de la transaction. Les deux approches empêchent l’organisme d’exécution de réécrire la référence. Les risques oracle habituels demeurent car des transactions antérieures dans le même bloc peuvent déplacer cet état de départ.
Un résultat rejeté coûterait quand même du gaz
Selon la proposition, un échec POST_TX le chèque annulerait le corps d’exécution. La transaction resterait dans le bloc. Le payeur de gaz resterait facturé pour le gaz consommé, et les modifications apportées aux étapes de validation initiales, connues sous le nom de préfixe de validation, resteraient engagées. Ceux-ci peuvent inclure l’approbation du paiement ou la création d’un compte.
Les actions destinées à être protégées doivent se situer dans la partie où l’assertion peut être annulée. Mettre une exécution non fiable dans le préfixe de validation validé la laisserait en dehors de cette protection.
Le contrôle nécessite également suffisamment d’essence pour être terminé. EIP-7906 prévient que l’énumération des changements et des événements peut épuiser son budget et nécessite qu’une vérification incomplète de panne de gaz soit traitée comme un échec d’assertion.
La Fondation décrit les applications potentielles dans le domaine des agents délégués et du règlement par les solveurs. La couverture de CryptoSlate en septembre sur les autorisations du portefeuille AI discutait déjà des limites déterministes et des assertions requises.
Une mise en œuvre significative indiquerait clairement la limite requise et sa référence avant l’autorisation, puis empêcherait le constructeur de s’affaiblir non plus. Ethereum pourrait parfaitement appliquer une condition de sécurité tout en appliquant une mauvaise négociation financière.
