Abstraction de compte multichaîne : une nouvelle direction pour l'infrastructure de chiffrement

Du 8 au 11 juillet 2024, le plus grand événement annuel sur Ethereum en Europe - la conférence communautaire Ethereum (EthCC) se tiendra à Bruxelles, en Belgique. Cette conférence (EthCC 7) rassemblera plus de 350 leaders d'opinion de premier plan dans l'industrie de la blockchain. Un développeur de blockchain a donné une présentation intitulée "Révéler l'avenir : analyse de l'abstraction de compte multi-chaînes".

Les points clés de la présentation incluent :

• Les deux éléments clés de l'abstraction de compte (AA) : l'abstraction de signature et l'abstraction de paiement. La première permet à l'utilisateur de choisir n'importe quel mécanisme de validation, tandis que la seconde autorise plusieurs options de paiement pour offrir une expérience utilisateur plus sécurisée et pratique.

• La conception de la fonction d'entrée pour la validation et l'exécution de ERC-4337 et de l'AA natif diffère. Chaque solution d'implémentation a ses propres caractéristiques en ce qui concerne les restrictions de validation des transactions et les étapes d'exécution.

• Lors de la mise en œuvre de l'ERC-4337 sur une chaîne compatible EVM, il est nécessaire de prêter attention aux différences de protocole résultant de la conception de Rollup, ainsi qu'aux différences dans la manière de calculer les adresses, ces détails pouvant affecter la mise en œuvre entre L1 et L2.

abstraction de compte aperçu

L'abstraction de compte (AA) comprend principalement deux points clés :

1. Abstraction de signature : l'utilisateur peut choisir n'importe quel mécanisme de validation, sans se limiter à un algorithme de signature numérique spécifique.

2. Abstraction de paiement : les utilisateurs peuvent utiliser plusieurs options de paiement pour les transactions, comme payer avec des jetons ERC-20 ou faire sponsoriser la transaction par un tiers.

Cette flexibilité peut offrir une expérience utilisateur plus sécurisée et optimisée. AA vise à atteindre ces deux objectifs principaux de plusieurs manières.

Introduction à l'ERC-4337

Actuellement, le compte externe dans le protocole Ethereum (EOA) présente certaines limitations, telles que des méthodes de signature fixes et un design de paiement. L'ERC-4337 résout ces problèmes en introduisant des méthodes de gestion de compte et de traitement des transactions plus flexibles.

Principales caractéristiques:

• structure userOp : l'utilisateur envoie la structure userOp au Bundler, qui collecte plusieurs userOp et appelle la fonction handleOps du contrat EntryPoint.

• Contrat EntryPoint : similaire à un système d'exploitation traitant des transactions, ses principales fonctionnalités incluent :

  1. Appeler la fonction validate du contrat de compte pour s'assurer que userOp est autorisé
  2. Perception de frais
  3. Appeler la fonction execute du contrat de compte pour exécuter l'opération cible de userOp

Introduction à AA natif

Dans l'AA natif, chaque compte est un contrat, et le mécanisme de traitement des transactions est directement intégré dans le protocole de blockchain.

Conception AA de différents réseaux de blockchain :

• Abstraction de compte ERC-4337 : Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• Suivre l'abstraction de compte natif ERC-4337 : StarkNet et zkSync Era
• Abstraction de compte natif avec conception de confidentialité : Aztec

Différences entre ERC-4337 et AA natif

1. Rôle du système d'exploitation

Le système d'exploitation AA doit résoudre les problèmes suivants : tarification du gaz, tri des transactions, déclenchement de la fonction d'entrée, processus de traitement des transactions, etc.

ERC-4337 accomplit ces tâches grâce à la collaboration entre Bundler et EntryPoint Contract. Dans l'AA natif, les utilisateurs envoient des userOps aux opérateurs/ordonneurs du serveur officiel.

2. Interface de contrat

Les interfaces de contrat de compte de différentes implémentations sont similaires, elles contiennent toutes trois étapes : vérification, paiement, exécution. Dans ERC-4337 et AA natif, la fonction de point d'entrée de la phase de "vérification" est fixe, tandis que dans la phase "d'exécution", seul le point d'entrée de AA natif est fixe.

3. Limitation des étapes de vérification

Pour prévenir les attaques DoS, chaque implémentation a mis en place différentes restrictions sur la validation des transactions. Par exemple, l'EIP-4337 définit des restrictions sur les codes d'opération et l'accès au stockage, tandis que zkSync Era assouplit l'utilisation de certains OpCode.

4. Limites des étapes d'exécution

zkSync nécessite la confirmation du drapeau système pour exécuter un appel système. La phase d'exécution d'ERC-4337 et de StarkNet n'a pas de restrictions spéciales.

5. Nombre aléatoire

ERC-4337 distingue une clé de 192 bits et une valeur aléatoire de 64 bits. zkSync et StarkNet adoptent un nonce strictement croissant.

6. Déploiement de la première transaction

ERC-4337 contient un champ initcode dans la structure userOp, utilisé pour déployer le contrat de compte lors de la première userOp. StarkNet et zkSync exigent que la première transaction de l'utilisateur soit envoyée à l'opérateur/ordonneur pour déployer le contrat de compte.

Différences entre ERC-4337 sur L1 et L2

Il existe deux différences clés dans la mise en œuvre de l'ERC-4337 sur une chaîne compatible avec l'EVM :

1. Différences de protocole

Dans la conception de Rollup, le L2 doit télécharger des données vers le L1 pour garantir la sécurité et le règlement. Les frais associés ( tels que les frais de sécurité du L1, les frais de blob ) doivent être inclus dans le Gas de pré-validation, mais déterminer les frais de téléchargement appropriés est un grand défi.

2. Différences d'adresse

Il existe des différences dans les méthodes de calcul des adresses entre différentes chaînes. Par exemple, la méthode d'encodage des adresses dans la fonction create de zkSync ERA est différente de celle d'Ethereum et d'OP, tandis que StarkNet utilise une fonction de hachage unique pour calculer les adresses.

Il est important de noter que les nouveaux codes d'opération introduits dans un hard fork peuvent entraîner des modifications du bytecode, ce qui peut affecter la cohérence des adresses des contrats de compte. Par exemple, si la chaîne L2 ne prend pas en charge le hard fork de Shanghai et que la version EVM n'est pas spécifiée lors de la compilation, l'introduction de push0 modifiera le bytecode, même si le code Solidity est identique.