Analyse de l'abstraction de compte multi-chaînes : explorer l'avenir de l'infrastructure de chiffrement

Du 8 au 11 juillet 2024, la conférence communautaire Ethereum (EthCC) se tiendra à Bruxelles, en Belgique. Il s'agit de l'événement annuel Ethereum le plus important en Europe, axé sur la technologie et la communauté.

La conférence communautaire Ethereum ( EthCC 7) a vu plus de 350 leaders d'opinion actifs dans l'industrie de la blockchain prendre la parole. Parmi eux, un développeur blockchain a été invité à participer et a donné une conférence intitulée "Révéler l'avenir : analyse de l'abstraction de compte multichaîne".

Aperçu du discours :

• abstraction de compte(AA) comprend principalement deux points clés : l'abstraction de signature et l'abstraction de paiement. L'abstraction de signature permet aux utilisateurs de choisir n'importe quel mécanisme de vérification de leur choix, tandis que l'abstraction de paiement permet d'utiliser plusieurs options de paiement pour les transactions. Cette flexibilité offre une expérience utilisateur plus sûre et améliorée.
• 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 dans AA natif est fixe. Les restrictions sur la vérification des transactions et les étapes d'exécution des transactions ont chacune leurs propres caractéristiques et limitations dans les différentes implémentations.
• La mise en œuvre d'ERC-4337 sur une chaîne compatible EVM présente deux différences clés : les différences de protocole dans la conception des Rollups et les différences dans la méthode de calcul des adresses, entraînant des détails de développement difficiles à remarquer lors de la mise en œuvre d'ERC-4337 entre L1 et L2.

Voici le texte intégral du discours :

Bonjour à tous, aujourd'hui je vais vous présenter le concept d'ERC-4337 et de Native AA, discuter des différences entre eux et analyser en détail les principales différences entre les standards 4337 de L1 et L2.

introduction à l'abstraction de compte

1. Qu'est-ce que l'abstraction de compte

abstraction de compte(AA) comprend principalement deux points clés : abstraction de signature et abstraction de paiement.

• Abstraction de signature : les utilisateurs peuvent choisir n'importe quel mécanisme de validation préféré, et pas seulement certaines algorithmes de signature numérique ( comme ECDSA ).
• Abstraction de paiement : les utilisateurs peuvent utiliser plusieurs options de paiement pour les transactions, telles que le paiement avec des actifs ERC-20 au lieu des actifs natifs, ou permettre à un tiers de sponsoriser la transaction.

Cette flexibilité offre une expérience utilisateur plus sécurisée et optimale. L'objectif de l'abstraction de compte est de réaliser ces deux points clés de plusieurs manières.

2. Qu'est-ce que l'ERC-4337

Actuellement, dans le protocole Ethereum, il existe certaines limitations concernant les comptes externes possédés par (EOA), telles qu'une méthode de signature fixe 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.

• Structure userOp : dans l'ERC-4337, l'utilisateur envoie la structure userOp au Bundler. Le Bundler collecte plusieurs userOp et les envoie au contrat EntryPoint en appelant la fonction handleOps.
• Contrat EntryPoint : Ce contrat gère les transactions comme un système d'exploitation, ses principales fonctions comprennent :

• Appeler la fonction validate dans le contrat de compte, s'assurer que userOp a obtenu l'autorisation du propriétaire du compte.
• Frais de collecte.
• Appeler la fonction execute dans le contrat de compte pour exécuter l'opération cible de userOp.

3. Qu'est-ce que le AA natif

Dans Ethereum, les comptes sont divisés en EOA et en comptes de contrat. Cependant, dans l'AA natif, chaque compte est un contrat, et le mécanisme de traitement des transactions est directement intégré au protocole de la blockchain.

Conception de l'AA dans les différents réseaux de blockchain:

• Abstraction de compte ERC-4337 : Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• L'abstraction de compte native suit ERC-4337 : l'ère StarkNet & zkSync
• Abstraction de compte native avec conception axée sur la confidentialité : Aztec

Si vous êtes intéressé par Aztec Native AA ou EIP-3074, EIP-7702, aujourd'hui nous allons nous concentrer sur le AA natif après l'ERC-4337.

La différence entre ERC-4337 et l'abstraction de compte natif

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

AA OS doit répondre aux questions suivantes :

• Qui décide du prix du Gas ?
• Qui décide de l'ordre des transactions ? Où se trouve la mémoire tampon ?
• Qui déclenche la fonction d'entrée?
• Qu'est-ce qui détermine le processus de traitement des transactions ?

Dans l'ERC-4337, ces rôles sont réalisés en collaboration par le Bundler et le contrat EntryPoint.

Dans l'AA natif, les utilisateurs envoient leurs userOps à l'opérateur/ordonnanceur du serveur officiel, plutôt qu'au Bundler et au contrat EntryPoint.

Dans StarkNet, le séquenceur est responsable de l'exécution de toutes ces tâches.

Dans zkSync, la principale différence entre Era et d'autres implémentations AA est que l'Operator doit travailler en collaboration avec le contrat de système bootloader(. Le Bootloader ouvre un nouveau bloc, définit ses paramètres), y compris les paramètres du bloc et d'autres paramètres de Gas(, et reçoit les transactions de l'Operator pour validation.

2. Interface de contrat

En raison de l'existence de trois étapes, l'interface de contrat de compte est similaire dans différentes implémentations, ces fonctions de point d'entrée ne peuvent être appelées que par le système d'exploitation AA :

• ERC-4337 : validation des opérations des utilisateurs
• zkSync : vérification des transactions, paiement des transactions, exécution des transactions
• StarkNet:exécuter, valider, valider_déclaration, valider_déploiement

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 dans AA natif est fixe.

3. Limitations des étapes de vérification

En raison de l'absence de limites de coût pour la vérification des transactions), la vérification des transactions consiste essentiellement à appeler une fonction de vue(. Un attaquant peut mener une attaque DoS sur le pool de mémoire, ce qui pourrait compromettre l'assembleur)EIP-4337( ou l'opérateur/trieur)AA natif(.

EIP-4337 définit quels codes d'opération sont interdits et comment limiter l'accès au stockage. zkSync Era assouplit l'utilisation de certains OpCode :

• La logique de contrat ne peut accéder qu'à son propre emplacement de stockage. Si l'adresse du contrat de compte est l'adresse A, elle peut accéder à :

• Emplacement de stockage appartenant à l'adresse A
• emplacement de stockage appartenant à toute autre adresse A
• Un emplacement de stockage keccak256)A || X( appartenant à n'importe quelle autre adresse : cela signifie utiliser directement l'adresse comme clé dans la carte ) par exemple, la carte (address => value(), équivalent à accéder à l'emplacement keccak256)A || X(. Par exemple, le solde d'actifs dans un contrat ERC-20.

• La logique des contrats ne peut pas accéder aux variables globales, telles que le numéro de bloc. StarkNet n'autorise également pas les appels de contrats externes.

4. Restrictions sur les étapes d'exécution

Dans zkSync, l'exécution des appels système nécessite la confirmation de l'existence des indicateurs système. Par exemple, le seul moyen d'augmenter le nonce est d'interagir avec le NonceHolder, tandis que le déploiement de contrats nécessite d'interagir avec le ContractDeployer. Les indicateurs système garantissent que les développeurs de comptes interagissent consciemment avec les contrats système.

Dans l'ERC-4337 et StarkNet, il n'y a pas de restrictions particulières à l'étape d'exécution.

5. Nombre aléatoire

• Dans l'ERC-4337, la conception du nombre aléatoire du point d'entrée distingue la valeur de clé de 192 bits et la valeur de nombre aléatoire de 64 bits.
• Dans zkSync, le contrat système NonceHolder gère le nonce, garantissant une augmentation stricte, c'est-à-dire que le nombre aléatoire est augmenté de 1.
• Dans StarkNet, le nonce est également strictement croissant, mais il n'y a pas de nonce abstrait géré par des contrats spécifiques.

6. Utiliser la première transaction pour le déploiement

• ERC-4337 inclut un champ initcode dans la structure userOp pour déployer le contrat de compte de l'expéditeur ) dans son premier userOp (.
• Dans StarkNet et zkSync, les utilisateurs doivent envoyer la première transaction à l'opérateur / le ordonneur pour déployer le contrat de compte.

7. Conception spéciale dans zkSync

Si vous transférez directement de l'ETH d'un EOA Ethereum vers zkSync, sans déployer de contrat de compte personnalisé, vous recevrez un compte par défaut avec la même adresse. Ce compte peut fonctionner comme un EOA Ethereum et est également contrôlé par la clé privée de l'EOA Ethereum correspondant.

Ce type de compte est de version None et non de version 1. Vous ne pouvez pas appeler les fonctions de DefaultAccount, car il n'a déployé aucun code dans l'espace noyau.

![L'avenir des infrastructures de chiffrement ? Analyse de l'abstraction de compte multichaîne])https://img-cdn.gateio.im/webp-social/moments-52ccc7ebff94f6c548dd55bc61aad309.webp(

) La différence entre le 4337 de L1 et le 4337 de L2

Il y a deux différences clés dans la mise en œuvre d'ERC-4337 sur les chaînes compatibles EVM : les différences de protocole et les différences d'adresse.

1. Différences de protocole

Dans la conception des Rollups, le L2 doit télécharger des données sur le L1 pour la sécurité et le règlement. Dans le contexte de l'ERC-4337, les frais associés à ce processus de téléchargement, tels que les frais de sécurité L1 et les frais de blob, devraient être inclus dans le Gas de pré-validation. Déterminer les frais de téléchargement appropriés dans le Gas de pré-validation est un défi majeur.

2. Différences d'adresse

Le mode d'encodage des adresses dans la fonction create de zkSync ERA est différent de celui d'Ethereum et des résumés OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte du ERC-4337 sur des chaînes compatibles avec l'EVM, nous supposons généralement que le calcul des adresses est cohérent entre les différentes chaînes. Cependant, un détail difficile à remarquer pourrait conduire à des adresses de contrat de compte différentes entre les implémentations ERC-4337 d'Ethereum et des L2.

La question clé est d'ajouter de nouveaux codes d'opération dans le hard fork. 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 entraînera un changement de bytecode, même si le code Solidity est le même.

conclusion

Voici quelques informations sur l'abstraction de compte. Si vous avez des questions, vous pouvez me trouver sur Twitter.

![L'avenir des infrastructures de chiffrement ? Analyse de l'abstraction de compte multi-chaînes]###https://img-cdn.gateio.im/webp-social/moments-180475deec41c605ac65be9b2b494048.webp(