Analyse de l'abstraction de compte multi-chaînes : explorer l'avenir de l'infrastructure de chiffrement
Récemment, la conférence de la communauté Ethereum (EthCC 7) s'est tenue à Bruxelles, en Belgique, cet événement étant le plus grand rassemblement annuel d'Ethereum en Europe, axé sur la technologie et la communauté. Plus de 350 leaders d'opinion de premier plan dans le secteur de la blockchain ont pris la parole lors de cette conférence, dont un développeur qui a présenté un discours intitulé "Dévoiler l'avenir : analyse de l'abstraction de compte multi-chaînes".
Points clés du discours
L'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 validation qu'ils préfèrent, 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 meilleure.
Dans ERC-4337 et AA natif, la fonction de point d'entrée de la phase de "validation" est fixe, tandis que dans la phase "d'exécution", seul le point d'entrée de l'AA natif est fixe. Les restrictions de validation des transactions et les étapes d'exécution des transactions ont chacune leurs propres caractéristiques et limitations dans les différentes implementations.
L'implémentation de l'ERC-4337 sur les chaînes compatibles EVM présente deux différences clés : les différences de protocoles dans la conception des Rollups et les différences dans la méthode de calcul des adresses, qui entraînent des détails de développement subtils lors de la mise en œuvre de l'ERC-4337 entre le L1 et le L2.
abstraction de compte introduction
Qu'est-ce que l'abstraction de compte
L'abstraction de compte (AA) comprend principalement deux points clés :
Abstraction de signature : l'utilisateur peut choisir n'importe quel mécanisme de validation qu'il préfère, 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, comme utiliser des actifs ERC-20 à la place des actifs natifs pour le paiement, 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 d'atteindre ces deux points clés de différentes manières.
Introduction à l'ERC-4337
Actuellement, les comptes externes détenus (EOA) dans le protocole Ethereum présentent 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.
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 traite les transactions comme un système d'exploitation, ses principales fonctionnalités incluent :
Appeler la fonction validate dans le contrat de compte pour s'assurer que userOp a reçu l'autorisation du propriétaire du compte.
Percevoir des frais.
Appeler la fonction execute dans le contrat de compte pour exécuter l'opération cible de userOp.
Introduction à AA natif
Dans Ethereum, les comptes sont divisés en EOA et en comptes de contrat. Cependant, dans le 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 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 l'ERC-4337 : l'ère de StarkNet et zkSync
Abstraction de compte native avec conception de la vie privée : Aztec
Différences entre l'ERC-4337 et l'AA natif
rôle du système d'exploitation
AA OS doit résoudre les problèmes suivants :
Qui décide du prix du Gas ?
Qui décide de l'ordre des transactions ? Où se trouve le pool de mémoire ?
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 AA natif, les utilisateurs envoient leurs userOps à l'opérateur/ordonneur du serveur officiel, plutôt qu'au Bundler et au contrat EntryPoint.
Dans StarkNet, le Séquenceur est responsable 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 avec le bootloader (contrat système). 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.
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 utilisateur
zkSync : validation des transactions, paiement des transactions, exécution des transactions
Dans l'ERC-4337 et l'AA natif, la fonction du point d'entrée de la phase "vérification" est fixe, tandis que dans la phase "exécution", seul le point d'entrée de l'AA natif est fixe.
étapes de vérification des limites
En raison de l'absence de limitation des coûts pour la validation des transactions (en essence, la validation des transactions consiste à appeler des fonctions de vue), un attaquant peut mener une attaque DoS sur le pool de mémoire, ce qui pourrait compromettre le packager (EIP-4337) ou l'opérateur/tri (AA natif).
EIP-4337 définit les opcodes 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
Une case de stockage appartenant à toute autre adresse keccak256(A || X) : cela signifie utiliser directement l'adresse comme clé dans la carte (par exemple, mapping (address => value)), équivalant à accéder à la case keccak256(A || X). Par exemple, le solde des actifs dans un contrat ERC-20.
La logique de contrat ne peut pas accéder aux variables globales, telles que le numéro de bloc. StarkNet n'autorise pas non plus les appels de contrats externes.
restriction des é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, la seule façon d'augmenter le nonce est d'interagir avec le NonceHolder, tandis que le déploiement de contrats nécessite une interaction avec le ContractDeployer. Les indicateurs système garantissent que les développeurs de comptes interagissent consciemment avec les contrats système.
Dans ERC-4337 et StarkNet, il n'y a pas de restrictions particulières lors de la phase d'exécution.
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 aléatoire de 64 bits.
Dans zkSync, le contrat système NonceHolder gère le nonce, garantissant un strict incrément, c'est-à-dire en ajoutant 1 au nombre aléatoire.
Dans StarkNet, le nonce est également strictement croissant, mais il n'y a pas de nonce abstrait géré par des contrats spécifiques.
utiliser la première transaction pour le déploiement
ERC-4337 contient un champ initcode dans la structure userOp pour déployer l'expéditeur (contrat de compte) dans son premier userOp.
Dans StarkNet et zkSync, les utilisateurs doivent envoyer la première transaction à l'opérateur/triant pour déployer le contrat de compte.
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 version 1. Vous ne pouvez pas appeler la fonction DefaultAccount car elle n'a pas déployé de code dans l'espace noyau.
Différence entre L1 4337 et L2 4337
Il y a deux différences clés dans la mise en œuvre d'ERC-4337 sur une chaîne compatible EVM : les différences de protocole et les différences d'adresse.
différences de protocole
Dans la conception des Rollups, L2 doit télécharger des données sur 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.
différence d'adresse
La méthode d'encodage des adresses dans la fonction create de zkSync ERA est différente de celle d'Ethereum et des solutions de couche 2 OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte d'ERC-4337 sur des chaînes compatibles EVM, nous supposons généralement que le calcul des adresses est cohérent entre les différentes chaînes. Cependant, il existe un détail difficile à remarquer qui peut entraîner des différences dans les adresses des contrats de compte entre les implémentations d'ERC-4337 sur Ethereum et sur les solutions de couche 2.
La question clé est d'ajouter de nouveaux codes d'opération dans un 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 du bytecode, même si le code Solidity est identique.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
17 J'aime
Récompense
17
2
Partager
Commentaire
0/400
OnChainArchaeologist
· 07-09 19:30
J'aime vraiment m'amuser avec ça.
Voir l'originalRépondre0
PriceOracleFairy
· 07-09 19:30
meh, aa n'est que des maths eth sophistiquées... mais cette abstraction de signature a l'air plutôt juteuse, pas mentir
Analyse de l'abstraction de compte multi-chaînes : principales différences entre l'ERC-4337 et l'AA natif
Analyse de l'abstraction de compte multi-chaînes : explorer l'avenir de l'infrastructure de chiffrement
Récemment, la conférence de la communauté Ethereum (EthCC 7) s'est tenue à Bruxelles, en Belgique, cet événement étant le plus grand rassemblement annuel d'Ethereum en Europe, axé sur la technologie et la communauté. Plus de 350 leaders d'opinion de premier plan dans le secteur de la blockchain ont pris la parole lors de cette conférence, dont un développeur qui a présenté un discours intitulé "Dévoiler l'avenir : analyse de l'abstraction de compte multi-chaînes".
Points clés du discours
L'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 validation qu'ils préfèrent, 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 meilleure.
Dans ERC-4337 et AA natif, la fonction de point d'entrée de la phase de "validation" est fixe, tandis que dans la phase "d'exécution", seul le point d'entrée de l'AA natif est fixe. Les restrictions de validation des transactions et les étapes d'exécution des transactions ont chacune leurs propres caractéristiques et limitations dans les différentes implementations.
L'implémentation de l'ERC-4337 sur les chaînes compatibles EVM présente deux différences clés : les différences de protocoles dans la conception des Rollups et les différences dans la méthode de calcul des adresses, qui entraînent des détails de développement subtils lors de la mise en œuvre de l'ERC-4337 entre le L1 et le L2.
abstraction de compte introduction
Qu'est-ce que l'abstraction de compte
L'abstraction de compte (AA) comprend principalement deux points clés :
Abstraction de signature : l'utilisateur peut choisir n'importe quel mécanisme de validation qu'il préfère, 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, comme utiliser des actifs ERC-20 à la place des actifs natifs pour le paiement, 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 d'atteindre ces deux points clés de différentes manières.
Introduction à l'ERC-4337
Actuellement, les comptes externes détenus (EOA) dans le protocole Ethereum présentent 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.
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 traite les transactions comme un système d'exploitation, ses principales fonctionnalités incluent :
Introduction à AA natif
Dans Ethereum, les comptes sont divisés en EOA et en comptes de contrat. Cependant, dans le 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 AA dans les différents réseaux de blockchain :
Différences entre l'ERC-4337 et l'AA natif
rôle du système d'exploitation
AA OS doit résoudre les problèmes suivants :
Dans l'ERC-4337, ces rôles sont réalisés en collaboration par le Bundler et le contrat EntryPoint.
Dans AA natif, les utilisateurs envoient leurs userOps à l'opérateur/ordonneur du serveur officiel, plutôt qu'au Bundler et au contrat EntryPoint.
Dans StarkNet, le Séquenceur est responsable 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 avec le bootloader (contrat système). 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.
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 :
Dans l'ERC-4337 et l'AA natif, la fonction du point d'entrée de la phase "vérification" est fixe, tandis que dans la phase "exécution", seul le point d'entrée de l'AA natif est fixe.
étapes de vérification des limites
En raison de l'absence de limitation des coûts pour la validation des transactions (en essence, la validation des transactions consiste à appeler des fonctions de vue), un attaquant peut mener une attaque DoS sur le pool de mémoire, ce qui pourrait compromettre le packager (EIP-4337) ou l'opérateur/tri (AA natif).
EIP-4337 définit les opcodes 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 à :
La logique de contrat ne peut pas accéder aux variables globales, telles que le numéro de bloc. StarkNet n'autorise pas non plus les appels de contrats externes.
restriction des é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, la seule façon d'augmenter le nonce est d'interagir avec le NonceHolder, tandis que le déploiement de contrats nécessite une interaction avec le ContractDeployer. Les indicateurs système garantissent que les développeurs de comptes interagissent consciemment avec les contrats système.
Dans ERC-4337 et StarkNet, il n'y a pas de restrictions particulières lors de la phase d'exécution.
nombre aléatoire
utiliser la première transaction pour le déploiement
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 version 1. Vous ne pouvez pas appeler la fonction DefaultAccount car elle n'a pas déployé de code dans l'espace noyau.
Différence entre L1 4337 et L2 4337
Il y a deux différences clés dans la mise en œuvre d'ERC-4337 sur une chaîne compatible EVM : les différences de protocole et les différences d'adresse.
différences de protocole
Dans la conception des Rollups, L2 doit télécharger des données sur 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.
différence d'adresse
La méthode d'encodage des adresses dans la fonction create de zkSync ERA est différente de celle d'Ethereum et des solutions de couche 2 OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte d'ERC-4337 sur des chaînes compatibles EVM, nous supposons généralement que le calcul des adresses est cohérent entre les différentes chaînes. Cependant, il existe un détail difficile à remarquer qui peut entraîner des différences dans les adresses des contrats de compte entre les implémentations d'ERC-4337 sur Ethereum et sur les solutions de couche 2.
La question clé est d'ajouter de nouveaux codes d'opération dans un 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 du bytecode, même si le code Solidity est identique.