L'Account Abstraction c'est facile (si on ignore la censure) - Censorship.wtf

Le problème de l'accès au Smart Account (0:20)

Les wallets détenus en externe (EOA) peuvent fonctionner directement sur la blockchain sans intermédiaires, tandis que les smart contract wallets nécessitent l'aide d'un EOA pour fonctionner sur la blockchain. Cela crée une mauvaise expérience utilisateur car les utilisateurs doivent gérer deux comptes et signer deux fois les transactions.

L'approche habituelle jusqu'à ERC-4337 était d'utiliser des relais centralisés qui envoient des meta-transactions au nom des utilisateurs. Mais cela a des inconvénients :

• Mauvaise expérience utilisateur car il faut deux comptes
• Points de défaillance centralisés
• Frontrunning
• Censure
• Problèmes de confidentialité

L'ERC-4337 résout ces problèmes en permettant aux Smart Wallets de payer leurs propres frais de gaz sur la blockchain sans intermédiaire.

La solution naïve (3:50)

Une solution naïve consiste à avoir de nombreux relais exploités par la même entité, mais c'est centralisé car ils peuvent toujours se concerter pour censurer les utilisateurs.

Le Gas Station Network (GSN) fournit un réseau décentralisé de relais, mais présente un problème : les relais peuvent perdre de l'argent si les smart wallets se comportent de manière inconsistante et ne remboursent pas le gaz.

Il y a eu des tentatives pour atténuer ce risque comme des listes blanches ou des systèmes de réputation, mais ces systèmes réintroduisent un risque de censure.

Les attaquants peuvent exploiter le non-déterminisme pour forcer les relais à simuler des transactions qui ne paieront jamais, gaspillant ainsi de la puissance de calcul. La protection des relais par Flashbots peut aider mais les attaquants peuvent encore la submerger.

En résumé, les problèmes clés sont:

1. Manque de véritable décentralisation
2. Non-déterminisme des smart contracts
3. Risques de censure des solutions tentées
4. Attaques d'épuisement des ressources

Par conséquent, une approche résistante à la censure est nécessaire pour gérer les smart wallets et empêcher le drainage malveillant des fonds des relais

La voie de l'ERC-4337 (7:20)

L'ERC-4337 vise à permettre une abstraction complète des smart wallets sans compromettre la résistance à la censure. Il n'a pas de composants centralisés ou permissionnés.

La validation implique l'exécution du bytecode EVM, ce qui ouvre des vecteurs d'attaque à traiter. Voici les mesures à prendre pour s'en prémunir :

1. Le protocole doit être permissionless pour les bundlers (entités qui regroupent les transactions), n'importe qui devrait pouvoir fournir des services de regroupement.
2. Il doit aussi être permissionless pour les utilisateurs, car personne ne devrait pouvoir censurer les transactions.
3. Les Bundlers doivent être récompensés pour un travail valide.
4. Les Bundlers ne doivent pas faire d'attaques d’épuisement drainant leurs fonds.
5. L'ensemble du réseau a besoin d'être protégé contre les attaques par déni de service (DoS).

La to-do list (9:00)

Les transactions sont divisées en phases de validation et d'exécution avec des limites de gaz distinctes, ce qui réduit le coût de la simulation.

La validation doit être déterministe, l'accès à l'environnement comme le numéro de bloc est interdit pour empêcher les annulations sur la blockchain.

Les attaques d'invalidation massives sont atténuées par des règles de stockage : les comptes ne peuvent accéder qu'à leur propre stockage lors de la validation. Pour invalider de nombreuses transactions, un attaquant devrait apporter des modifications d'état sur la blockchain, ce qui lui coûterait cher

Cela permet de réduire le coût de la simulation, le déterminisme et la prévention des attaques par déni de service.

Les transactions dans un lot doivent rester valides ensemble, sinon les attaquants pourraient invalider d'autres transactions.

Les validations sont effectuées avant les exécutions, de sorte que les exécutions ne peuvent pas invalider les validations une fois le gaz payé, ce qui empêche l'invalidation croisée.

Des entités globales comme les paymasters peuvent encore invalider des lots en détectant des appels multiples. Donc les paymasters qui se comportent mal doivent être limités, et doivent engager plus de fonds pour continuer à attaquer.

Divers vecteurs d'attaque ont dû être traités avec des restrictions de validation minimales pour conserver la nature sans autorisation.

Dans l'ensemble, l'objectif était de trouver le bon équilibre entre la participation ouverte, la dissuasion des attaques et les incitations économiques.

Pourquoi tous les Bundlers doivent-ils mettre en œuvre des restrictions ? (15:15)

Tous les Bundlers doivent appliquer les mêmes règles de validation pour prévenir les attaques par déni de service. Les attaquants pourraient spammer des nœuds avec des transactions non valides en utilisant le gaz de validation maximal. Les nœuds peuvent détecter cela en vérifiant le hachage du bloc de validation.

Si les Bundlers ont des règles de validation différentes, une transaction pourrait être valide pour certains mais invalide pour d'autres. Cela permettrait aux attaquants de spammer certains Bundlers en envoyant des transactions adaptées à leurs règles spécifiques.

Avec des règles standardisées, les transactions non valides marquent les nœuds comme spammeurs pour les bloquer à l'échelle du réseau.

Avoir un ensemble de règles standardisé de validation empêche la fragmentation en petits mempools isolés.

Pourquoi la fragmentation du mempool est mauvaise ? (17:00)

Les mempools fragmentés sont plus vulnérables à la centralisation et la censure

La fragmentation perd également la robustesse d'avoir de multiples implémentations client, car les bugs pourraient faire tomber tout un mempool isolé.

Économiquement, les petits mempools ne peuvent pas construire des lots optimaux, ce qui réduit les incitations financières

La solution consiste à avoir de multiples implémentations de Bundler mais avec un ensemble unique de règles de validation compatibles. Ethereum a fait face à des problèmes similaires et les a résolus grâce à :

• Des spécifications claires
• Une implémentation de référence
• Des tests de compatibilité
• Des tests de fuzzing pour les bugs de consensus

Conclusion (18:55)

Concevoir un protocole d'Account Abstraction véritablement résistant à la censure est très difficile car il nécessite d'examiner de nombreux cas extrêmes et attaques.

C'est pourquoi il a fallu beaucoup de temps et d'efforts pour développer ERC-4337 tout en conservant la décentralisation.

Les développeurs de smart contracts/wallets ne se soucient pas souvent de la résistance à la censure, seulement des fonctionnalités utilisateur.

Ils peuvent obtenir la résistance à la censure "gratuitement" en utilisant un SDK compatible ERC-4337. Cependant, cela repose sur les Bundlers mettant en œuvre des règles de validation compatibles.

Les bundlers doivent utiliser une implémentation qui passe les tests de compatibilité ERC-4337. Une fois que le réseau P2P sera lancé, les bundlers compatibles obtiendront tous les avantages d'une résistance complète à la censure.