Abstraction de compte ou abstraction de compte native

En termes simples, Account Abstraction dans l'ERC-4337 est une infrastructure optionnelle de la blockchain. Vous pouvez choisir de l'adopter ou non. Une fois adopté, il fournit des fonctionnalités similaires à celles des comptes contractuels (CA), telles que le multisig, le paiement des frais de gaz avec des jetons ERC-20, la reprise sociale, etc. De nombreux fournisseurs de services, comme Stackup, travaillent sur cette infrastructure. Cependant, cette infrastructure n'a pas été largement adoptée pour les raisons suivantes :

• Problème de groupage : seuls les groupeurs participent à la vérification, ce qui entraîne une dépendance excessive à l'égard des groupeurs.
• Profits insuffisants pour les groupeurs : cela est principalement dû à leur petite taille, qui oblige un plus grand nombre de dApps à choisir l'infrastructure Account Abstraction afin de réduire les frais de gaz.
• Concentration de groupeurs : Les groupeurs sont concentrés chez quelques fournisseurs (Alchemy, Pimlico, Stackup), ce qui présente des risques de centralisation.
• Taux de rétention : Hormis les airdrops, le taux de rétention des utilisateurs pour les services Account Abstraction est très faible.

De nombreuses solutions de couche 2 déploient Account Abstraction directement sur la chaîne native pour réduire les frais de gaz. C'est ce que l'on appelle Native Account Abstraction. Cependant, cette approche présente également d'autres problèmes, tels que le fait que les utilisateurs qui ne souhaitent pas cette fonctionnalité ne puissent pas se désinscrire, des fonctionnalités inter-chaînes limitées et un manque général de flexibilité.

Cet article mentionne certains termes, tels que la distinction entre EOA et CA (en termes simples, Metamask c'est EOA, contracts c'est CA), ainsi que les bundleurs (dans l'écosystème de l'abstraction des comptes, les utilisateurs envoient des UserOperations aux bundlers pour le packaging et le traitement en chaîne, au lieu de les envoyer à Node Validators/Mempool). Pour des explications détaillées, vous pouvez cliquer sur les liens vers les deux articles mentionnés ci-dessus et vous référer aux articles publiés précédemment sur Gate Learn.

Qu'est-ce que le RIP-7560 ?

Le RIP-7560 est une proposition d'amélioration pour l'abstraction des comptes (EIP-2938/ERC-4337). L'introduction du nouveau type de transaction « AA_TX_TYPE » intègre des rôles autres que celui du vendeur de lots (créateur de blocs/validateur de nœuds) lors des étapes de vérification et d'exécution des transactions. Elle ne dépend plus uniquement du vendeur de lots pour l'emballage et la soumission en chaîne, résolvant ainsi les problèmes de centralisation mentionnés précédemment. De plus, le RIP-7560 propose un design standardisé afin de garantir une meilleure conformité aux futurs utilisateurs. Cet article expliquera plus en détail les normes améliorées par la proposition RIP-7560 et répondra aux préoccupations exprimées.

Le changement le plus fondamental

Il s'agit d'un changement de protocole de couche consensuelle \
La première proposition d'abstraction de comptes a en fait été faite en septembre 2020 EIP-2938. Il a finalement été accepté par la communauté et déployé sur Ethereum. La raison pour laquelle l'ERC-4337 a finalement été adopté au lieu de 2938 est que 4337 ne nécessite aucune modification au niveau du consensus, ce qui permet à la communauté de l'accepter relativement plus facilement.

Contrairement à l'ERC-4337, la proposition RIP-7560 impliquera des modifications plus importantes, notamment au niveau du protocole de la couche consensus (le préfixe RIP indique qu'il s'agit d'une proposition de niveau inférieur visant à améliorer la technologie Rollup). L'avantage correspondant est la possibilité d'éviter de dépendre directement de l'infrastructure de la chaîne native L2.

Introduction d'un nouveau type de transaction \
Un nouveau type de transaction a été introduit : le quatrième type de transaction, également connu sous le nom de « AA_TX_TYPE » (qui était d'ailleurs proposé dans l'ancien EIP-2938). Non seulement il prend en charge toutes les fonctionnalités d'une autorité de certification classique (telles que le paiement des frais de gaz et les fonctions de paiement automatique récurrentes mentionnées dans l'article de Visa), mais contrairement à l'ERC-4337, il permet également aux EOA existants de soumettre des transactions. Cela signifie que cette proposition vise à promouvoir une adoption plus large.

Logique d'exécution des transactions

Cette proposition est compatible avec la norme ERC-4337 et adopte la logique transactionnelle qui consiste à séparer l'exécution de la vérification, ce qui nécessite plus de gaz. De plus, selon la documentation, l'exécution des transactions est la même que celle de l'ERC-4337, où toutes les étapes de la phase de vérification doivent être terminées sans retour en arrière. Après vérification, les données des appels seront envoyées au compte pour exécution. Après l'exécution, le Paymaster peut exécuter une logique post-transaction. Le processus d'exécution complet est illustré dans le schéma suivant.

Organigramme d'exécution (Source : document GitHub du RIP-7560)

Principales préoccupations concernant cette proposition

L'auteur a fait part des préoccupations suivantes lors de la discussion sur le forum Ethereum Magicians : RIP-7560 : Native Account Abstraction

Cela restreindra-t-il le développement de services d'abstraction de comptes basés sur l'intention ?

Les principaux acteurs des services basés sur l'intention devraient être Uniswap V4 et UniswapX, UniswapX prévoyant de développer des services d'abstraction de comptes. De plus, une direction similaire a été proposée par l'ERC-7521. En réponse aux discussions de la communauté, l'un des auteurs de cette proposition, Yoav Weiss, a indiqué qu'outre le RIP-7560, il existe également une règle de vérification des abstractions de compte appelée ERC-7562. La conception du système d'intention pourrait être rendue compatible uniquement avec le RIP-7560 et non avec la règle de vérification. Ensuite, un réseau de résolution d'intentions distinct pourrait être utilisé, afin de profiter des avantages du RIP-7560 sans entrer en conflit avec la conception des intentions.

Risque d'irréversibilité

Certains membres de la communauté se demandent si cette proposition revient à « essayer d'intégrer un système d'exploitation dans Bare Metal », car elle présente des risques importants. À cela, Yoav Weiss a répondu : Cette proposition concerne les chaînes qui choisissent d'intégrer un système d'exploitation (tel que l'ERC-4337) dans Bare Metal, à savoir les chaînes L2 qui choisissent de déployer une abstraction de compte native. L'écosystème Ethereum offre suffisamment de choix, et les utilisateurs peuvent opter pour d'autres chaînes L2 qui n'ont pas déployé d'abstraction de compte native.

Considérations relatives à la complexité et aux coûts

En ce qui concerne les préoccupations concernant la complexité de la proposition et les coûts élevés qui en résultent, Dror Tirosh, l'un des auteurs, a répondu que cela était inhérent à l'abstraction des comptes elle-même. L'abstraction du compte provient du fait que nous voulons valider des données externes à l'aide d'un code EVM générique. L'élimination de cette complexité exposerait les producteurs de blocs à des attaques DoS ou nécessiterait la suppression de l'utilisation générale du code EVM, ce qui va à l'encontre de l'objectif de développement d'une technologie d'abstraction des comptes.

Conclusion

Actuellement, au moins les fournisseurs d'infrastructures d'abstraction de comptes, tels que le fondateur de Stackup, accueillent favorablement ces changements au niveau du consensus, ce qui indique que les principaux problèmes liés aux services d'abstraction de comptes courants sont toujours d'actualité. Si les DApps n'adoptent pas cette solution pour réduire les frais de gaz et introduire des fonctionnalités conviviales similaires à celles de l'AC, les fournisseurs de forfaits n'en profiteront pas et les taux de fidélisation des utilisateurs n'augmenteront jamais. Cependant, si les services développés sur la base de cette proposition peuvent facilement prendre en charge les EOA en chaîne existants afin de prendre en charge l'abstraction des comptes de manière native, nous serons plus proches de l'objectif ultime (adoption massive, Metamask prenant en charge l'abstraction des comptes, etc.), et l'expérience utilisateur en matière d'interaction avec les dApps s'améliorera progressivement.