Révéler l'avenir : analyse de l'abstraction de compte multichaîne
Du 8 au 11 juillet, la conférence de la communauté Ethereum se tiendra à Bruxelles, c'est le plus grand événement annuel Ethereum en Europe, axé sur la technologie et la communauté.
Cette conférence a réuni plus de 350 leaders d'opinion de première ligne de l'industrie de la blockchain, dont une présentation intitulée "Révéler l'avenir : analyse de l'abstraction de compte multi-chaînes".
Points de discours :
L'abstraction de compte (AA) a 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, tandis que l'abstraction de paiement prend en charge diverses options de paiement des transactions. Cette flexibilité améliore la sécurité et l'expérience utilisateur.
Les fonctions de point d'entrée de la phase de "validation" pour l'ERC-4337 et l'AA natif sont fixes, tandis que dans la phase "d'exécution", seul le point d'entrée de l'AA natif est fixe. Les restrictions pour valider les transactions et les étapes pour exécuter les transactions varient selon les différentes implémentations.
Lors de la mise en œuvre de l'ERC-4337 sur une chaîne compatible EVM, les différences de protocole dans la conception du Rollup et la manière de calculer les adresses sont deux différences clés, ce qui entraîne quelques subtilités de développement lors de la mise en œuvre de l'ERC-4337 entre L1 et L2.
Voici le texte intégral du discours :
Bonjour à tous, aujourd'hui je vais introduire le concept d'ERC-4337 et d'AA natif, discuter des différences entre eux et analyser en détail les principales différences entre la norme 4337 de L1 et L2.
abstraction de compte introduction
1. Définition de l'abstraction de compte
abstraction de compte(AA) comprend principalement deux points clés : abstraction de signature et abstraction de paiement.
Abstraction de signature : l'utilisateur peut choisir n'importe quel mécanisme de validation de son choix, et pas seulement certains 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 au lieu d'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 d'atteindre ces deux points clés de plusieurs manières.
2. 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 une conception 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 incluent :
Appeler la fonction validate dans le contrat de compte, pour s'assurer que userOp a obtenu 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.
3. Introduction à l'AA natif
Dans Ethereum, les comptes sont divisés en EOA et en comptes de contrats. Cependant, dans le AA natif, chaque compte est un contrat, et le mécanisme de traitement des transactions est directement intégré dans le protocole de la blockchain.
Conception AA dans les différents réseaux blockchain :
abstraction de compte ERC-4337 : Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
L'abstraction de compte natif suit ERC-4337 : l'ère StarkNet et zkSync
Abstraction de compte native avec conception de la vie privée : Aztec
Différences entre ERC-4337 et AA natif
1. Rôle du système d'exploitation
AA OS doit résoudre les problèmes suivants :
Décideur du prix du gaz
Le décideur de l'ordre de transaction et la position de la mémoire tampon
Déclencheur de la fonction de point d'entrée
Facteurs déterminants du processus de traitement des transactions
Dans l'ERC-4337, ces rôles sont accomplis en collaboration par le Bundler et le contrat EntryPoint.
Dans l'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 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 bootloader (contrat système). Le bootloader ouvre de nouveaux blocs, définit ses paramètres (y compris les paramètres de bloc et d'autres paramètres de Gas), et reçoit les transactions de l'Operator pour vérification.
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 AA OS :
ERC-4337 : validation des opérations des utilisateurs
zkSync : vérification des transactions, paiement des transactions, exécution des transactions
Dans ERC-4337 et AA natif, la fonction de point d'entrée de la phase "validation" est fixe, tandis que dans la phase "exécution", seul le point d'entrée dans AA natif est fixe.
3. Limites des étapes de vérification
Étant donné qu'il n'y a pas de limite de coût pour la validation des transactions (en essence, la validation des transactions appelle une fonction de vue), un attaquant peut effectuer une attaque DoS sur le pool de mémoire, ce qui pourrait compromettre le regroupement (EIP-4337) ou l'opérateur/tri (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 des contrats ne peut accéder qu'à son propre espace 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
emplacement de stockage keccak256 (A || X) appartenant à toute autre adresse : cela signifie utiliser directement l'adresse comme clé dans la mappage (par exemple, mapping (address => value)), équivalant à accéder à l'emplacement keccak256 (A || X). Par exemple, le solde des 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 pas non plus les appels de contrats externes.
4. Restrictions des étapes d'exécution
Dans zkSync, l'exécution des appels système nécessite la confirmation de la présence 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 l'étape d'exécution d'ERC-4337 et de StarkNet, il n'y a pas de restrictions particulières.
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 aléatoire de 64 bits.
Dans zkSync, le contrat système NonceHolder gère les nonce, assurant une augmentation stricte, 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.
6. 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 leur première transaction à l'opérateur/trié 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 la version None et non la version 1. Vous ne pouvez pas appeler les fonctions de DefaultAccount car il n'a déployé aucun code dans l'espace noyau.
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 des raisons de sécurité et de 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érence d'adresse
L'encodage des adresses dans la fonction create de zkSync ERA diffère de celui d'Ethereum et des rollups OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte de l'ERC-4337 sur les chaînes compatibles EVM, nous supposons généralement que le calcul des adresses est cohérent sur toutes les chaînes. Cependant, un détail difficile à remarquer pourrait entraîner des différences dans les adresses des contrats de compte entre les implémentations ERC-4337 d'Ethereum et des L2.
La question clé est d'ajouter de nouveaux opcodes dans un hard fork. Par exemple, si la chaîne L2 ne prend pas en charge le hard fork de Shanghai et qu'aucune version EVM n'est 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
Ci-dessus se trouvent quelques informations sur l'abstraction de compte. Si vous avez des questions, n'hésitez pas à me contacter sur Twitter.
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.
22 J'aime
Récompense
22
7
Partager
Commentaire
0/400
EthMaximalist
· 07-24 00:42
La conférence n'a rien expliqué.
Voir l'originalRépondre0
RugDocScientist
· 07-23 14:29
Encore une vague de cours de marketing.
Voir l'originalRépondre0
AirdropSweaterFan
· 07-22 12:12
Le multi-chaînes AA est vraiment génial à jouer.
Voir l'originalRépondre0
RiddleMaster
· 07-22 12:11
La signature abstraite est vraiment géniale !
Voir l'originalRépondre0
liquidation_surfer
· 07-22 12:00
Encore couper les coupons ?
Voir l'originalRépondre0
RugPullProphet
· 07-22 11:51
On ne peut pas dire si le projet sera encore là l'année prochaine.
Voir l'originalRépondre0
SnapshotDayLaborer
· 07-22 11:46
Quand pourra-t-on faire un transfert en un seul clic ?
Analyse de la technologie d'abstraction de compte multi-chaînes : comparaison entre ERC-4337 et AA natif
Révéler l'avenir : analyse de l'abstraction de compte multichaîne
Du 8 au 11 juillet, la conférence de la communauté Ethereum se tiendra à Bruxelles, c'est le plus grand événement annuel Ethereum en Europe, axé sur la technologie et la communauté.
Cette conférence a réuni plus de 350 leaders d'opinion de première ligne de l'industrie de la blockchain, dont une présentation intitulée "Révéler l'avenir : analyse de l'abstraction de compte multi-chaînes".
Points de discours :
L'abstraction de compte (AA) a 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, tandis que l'abstraction de paiement prend en charge diverses options de paiement des transactions. Cette flexibilité améliore la sécurité et l'expérience utilisateur.
Les fonctions de point d'entrée de la phase de "validation" pour l'ERC-4337 et l'AA natif sont fixes, tandis que dans la phase "d'exécution", seul le point d'entrée de l'AA natif est fixe. Les restrictions pour valider les transactions et les étapes pour exécuter les transactions varient selon les différentes implémentations.
Lors de la mise en œuvre de l'ERC-4337 sur une chaîne compatible EVM, les différences de protocole dans la conception du Rollup et la manière de calculer les adresses sont deux différences clés, ce qui entraîne quelques subtilités de développement lors de la mise en œuvre de l'ERC-4337 entre L1 et L2.
Voici le texte intégral du discours :
Bonjour à tous, aujourd'hui je vais introduire le concept d'ERC-4337 et d'AA natif, discuter des différences entre eux et analyser en détail les principales différences entre la norme 4337 de L1 et L2.
abstraction de compte introduction
1. Définition de l'abstraction de compte
abstraction de compte(AA) comprend principalement deux points clés : abstraction de signature et abstraction de paiement.
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 plusieurs manières.
2. 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 une conception 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.
3. Introduction à l'AA natif
Dans Ethereum, les comptes sont divisés en EOA et en comptes de contrats. Cependant, dans le AA natif, chaque compte est un contrat, et le mécanisme de traitement des transactions est directement intégré dans le protocole de la blockchain.
Conception AA dans les différents réseaux blockchain :
Différences entre ERC-4337 et AA natif
1. Rôle du système d'exploitation
AA OS doit résoudre les problèmes suivants :
Dans l'ERC-4337, ces rôles sont accomplis en collaboration par le Bundler et le contrat EntryPoint.
Dans l'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 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 bootloader (contrat système). Le bootloader ouvre de nouveaux blocs, définit ses paramètres (y compris les paramètres de bloc et d'autres paramètres de Gas), et reçoit les transactions de l'Operator pour vérification.
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 AA OS :
Dans ERC-4337 et AA natif, la fonction de point d'entrée de la phase "validation" est fixe, tandis que dans la phase "exécution", seul le point d'entrée dans AA natif est fixe.
3. Limites des étapes de vérification
Étant donné qu'il n'y a pas de limite de coût pour la validation des transactions (en essence, la validation des transactions appelle une fonction de vue), un attaquant peut effectuer une attaque DoS sur le pool de mémoire, ce qui pourrait compromettre le regroupement (EIP-4337) ou l'opérateur/tri (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 des contrats ne peut accéder qu'à son propre espace de stockage. Si l'adresse du contrat de compte est l'adresse A, elle peut accéder à :
La logique des contrats 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.
4. Restrictions des étapes d'exécution
Dans zkSync, l'exécution des appels système nécessite la confirmation de la présence 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 l'étape d'exécution d'ERC-4337 et de StarkNet, il n'y a pas de restrictions particulières.
5. Nombre aléatoire
6. Utiliser la première transaction pour le déploiement
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 la version None et non la version 1. Vous ne pouvez pas appeler les fonctions de DefaultAccount car il n'a déployé aucun code dans l'espace noyau.
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 des raisons de sécurité et de 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érence d'adresse
L'encodage des adresses dans la fonction create de zkSync ERA diffère de celui d'Ethereum et des rollups OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte de l'ERC-4337 sur les chaînes compatibles EVM, nous supposons généralement que le calcul des adresses est cohérent sur toutes les chaînes. Cependant, un détail difficile à remarquer pourrait entraîner des différences dans les adresses des contrats de compte entre les implémentations ERC-4337 d'Ethereum et des L2.
La question clé est d'ajouter de nouveaux opcodes dans un hard fork. Par exemple, si la chaîne L2 ne prend pas en charge le hard fork de Shanghai et qu'aucune version EVM n'est 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
Ci-dessus se trouvent quelques informations sur l'abstraction de compte. Si vous avez des questions, n'hésitez pas à me contacter sur Twitter.