La Fondation Ethereum étudie des assertions de transaction qui permettraient aux utilisateurs d’associer à une transaction des conditions exécutoires portant sur son résultat final, au lieu de se fier uniquement à l’approbation de l’action demandée. Cette recherche, menée dans le cadre de son initiative Trillion Dollar Security, vise à combler une lacune en matière de sécurité des transactions : une signature valide ne garantit pas que les soldes, les autorisations ou les contrôles du compte qui en résultent correspondent à ce que le signataire souhaitait.
Points clés
- Les vérifications proposées évalueraient les résultats des transactions pendant leur exécution et annuleraient les actions qui enfreignent une règle signée.
- La protection dépend de règles approuvées indépendamment d’un constructeur de transactions potentiellement compromis.
- La recherche pourrait contribuer à des politiques de sécurité des portefeuilles, des agents délégués et des processus de solveurs, mais aucun déploiement n’a été annoncé.
Table des matières
- Pourquoi approuver une transaction peut tout de même entraîner une perte
- Comment les assertions de transaction vérifieraient le résultat
- Ce que l’implémentation proposée permettrait d’examiner
- Quels changements seraient nécessaires pour les portefeuilles et les protocoles
- Ce que les agents et les processus de solveurs pourraient y gagner
- Conclusion
Pourquoi approuver une transaction peut tout de même entraîner une perte
Ethereum exécute la requête autorisée par un utilisateur en fonction du code et de l’état disponibles au moment de son exécution. Ces conditions peuvent différer de celles que l’utilisateur a examinées. Par exemple, l’implémentation d’un proxy peut changer avant l’exécution, tandis que l’ordre des transactions peut modifier le prix auquel un swap est effectué.
La fondation distingue les requêtes trompeuses des résultats indésirables. Lors des attaques contre Bybit et BadgerDAO, des interfaces compromises ont présenté des demandes de signature différentes de ce que les utilisateurs pensaient approuver. En revanche, une requête affichée fidèlement peut tout de même permettre un résultat préjudiciable sur le plan économique.
L’exemple qu’elle donne est un swap de collatéral Aave et CoW portant sur environ 50,4 millions d’aEthUSDT. La faible liquidité d’AAVE et le plafond de gaz de CoW ont limité le cours vérifié à environ 329 aEthAAVE. Malgré un avertissement affiché indiquant un impact sur le prix de 99,9 % et la confirmation que la totalité de la valeur pouvait être perdue, l’utilisateur a signé et reçu des jetons d’une valeur d’environ 36 000 $.
Cette distinction explique pourquoi de meilleures descriptions des transactions ne suffisent pas. Clear Signing aide les utilisateurs à comprendre l’action demandée. La simulation estime les effets à partir d’un état de chaîne donné. Aucune de ces méthodes, à elle seule, n’impose de condition indépendante au résultat qui se produit réellement.
| Élément | Détails |
|---|---|
| TXTRACE | Recense les changements nets d’état de la transaction et les événements émis. |
| TXDIFF | Récupère les valeurs initiales et finales pour les adresses et les emplacements de stockage spécifiés. |
| EVENTDATACOPY | Copie les données d’un événement en mémoire à des fins d’inspection. |
| Informations de déploiement | Les données proposées sur les changements d’état comprennent les nouveaux contrats déployés et leurs empreintes de code. |
Comment les assertions de transaction vérifieraient le résultat
Une assertion comparerait l’état initial et l’état final d’une transaction à l’aide d’une logique en lecture seule, une fois les actions exécutées. La condition serait intégrée à la transaction et signée avec les actions. En cas d’échec, ces actions seraient annulées.
Les règles possibles pourraient inclure un montant minimum à recevoir, un plafond de dépenses, des restrictions sur les nouvelles autorisations de jetons ou la préservation de la logique de contrôle d’un compte. La capacité d’inspection proposée va au-delà des soldes et couvre également le stockage, le code, les contrats nouvellement déployés et les événements émis.
Les vérifications contractuelles existantes protègent déjà certains résultats. Uniswap peut rejeter les swaps dont le montant de sortie est inférieur à un minimum spécifié, et un guard Safe peut examiner l’état du compte après l’exécution. La limite tient à la visibilité : ces vérifications doivent anticiper ce qu’elles doivent examiner et dépendent généralement des interfaces exposées par les autres contrats. Un proxy, par exemple, n’est pas tenu de fournir une fonction révélant l’adresse de son implémentation.
Les assertions natives rendraient disponibles à la vérification tous les effets nets de la transaction, y compris les changements qu’un guard classique ne saurait pas nécessairement rechercher. Mais une visibilité plus large n’est utile que si la règle est fiable. Une interface malveillante pourrait fournir une condition qui autorise sa propre attaque ; la politique doit donc découler d’une intention approuvée indépendamment, de la politique du compte ou de la logique protégée du protocole.
Ce que l’implémentation proposée permettrait d’examiner
L’annonce de la fondation sur les assertions de transaction natives présente l’EIP-7906 comme une implémentation possible, et non comme une conception définitive. Elle s’appuie sur les transactions par trames définies dans l’EIP-8141, qui organisent les étapes de validation et d’action selon une séquence ordonnée. L’EIP-8141 est prévu pour Hegotá ; l’EIP-7906 a atteint le statut « Considered for Inclusion », mais son inclusion dans cette mise à niveau n’est pas confirmée.
Dans cette approche, une trame POST_TX en lecture seule examinerait les résultats à la fin de l’exécution. Les instructions proposées pour accéder aux données ne fonctionneraient que dans cette trame, et non dans l’ensemble de l’EVM.
Les informations décriraient les effets nets, et non l’historique de chaque écriture intermédiaire. Un emplacement de stockage modifié à plusieurs reprises apparaîtrait avec ses valeurs initiale et finale ; un emplacement rétabli à sa valeur d’origine n’apparaîtrait pas. Il est donc important de distinguer l’application de règles à l’état final de la surveillance de chaque étape de l’exécution.
Si une vérification échouait, le corps de l’exécution serait annulé, mais la transaction resterait dans le bloc en tant que transaction échouée. Le payeur du gaz devrait tout de même payer le gaz consommé, afin d’empêcher que des transactions volontairement vouées à l’échec imposent gratuitement du travail d’exécution aux constructeurs de blocs.
Quels changements seraient nécessaires pour les portefeuilles et les protocoles
La proposition fournit un mécanisme de vérification, sans imposer automatiquement son utilisation. Pour les transactions d’un utilisateur, le portefeuille devrait intégrer sa politique de sécurité à la construction de la transaction, au lieu de laisser le constructeur libre de l’omettre. Cette politique pourrait découler de la propre simulation du portefeuille ou s’appliquer comme règle permanente du compte.
Pour les protocoles, la protection devrait être intégrée aux conditions d’accès à une fonction protégée. Il ne suffirait pas de fournir une transaction capable de prendre en charge des assertions : l’appel devrait inclure la vérification particulière exigée par le protocole. Cela modifierait les exigences d’intégration pour les appelants, tandis que les contrats immuables déjà déployés ne pourraient pas intégrer rétroactivement cette vérification d’admission.
Ces dépendances distinguent une capacité potentiellement puissante de l’EVM d’une garantie destinée aux utilisateurs. Une protection efficace nécessiterait à la fois une condition solide et des logiciels qui la rendent systématiquement incontournable.
Ce que les agents et les processus de solveurs pourraient y gagner
Les agents délégués pourraient être encadrés en fonction des résultats, en plus de leurs autorisations. Les restrictions portant sur les contrats qu’un agent peut utiliser ou sur ses dépenses pourraient être complétées par des exigences concernant l’état laissé par chaque transaction.
Pour l’exécution par solveur, un protocole pourrait définir un résultat acceptable tout en laissant au solveur le choix de l’itinéraire. La garantie se limiterait à une transaction sur un seul réseau et ne couvrirait pas un itinéraire passant par plusieurs chaînes.
Les assertions pourraient également vérifier le nettoyage des processus, par exemple le retour des jetons inutilisés et la révocation des autorisations restantes. La fondation sollicite les avis des équipes des portefeuilles et des protocoles à mesure que la conception progresse ; ces applications potentielles relèvent donc de pistes de recherche et non de fonctionnalités annoncées pour un produit.
Conclusion
Les assertions de transaction natives déplaceraient une partie de la sécurité des transactions Ethereum, de l’interprétation d’une requête vers l’application de son résultat. Leur utilité pratique dépendrait de politiques fiables et de leur adoption par les portefeuilles et les protocoles chargés de les appliquer.
Lire d’autres actualités
Plus d’actualités FinanceVelix
Avertissement
Cet article de FinanceVelix fournit des informations générales et ne constitue pas un conseil financier, en investissement, juridique ou fiscal personnalisé. Les cours des cryptomonnaies peuvent évoluer rapidement et vous pourriez perdre la totalité des fonds investis. Les faits reflètent les informations disponibles au moment de la publication et peuvent changer. Vérifiez les informations importantes de manière indépendante et consultez un professionnel qualifié si nécessaire. La mention d’un actif, d’une entreprise ou d’un service ne constitue pas une recommandation.
