Analyse de l'abstraction de compte multi-chaînes : exploration de l'avenir de l'infrastructure de chiffrement
Du 8 au 11 juillet 2024, le plus grand événement annuel sur Ethereum en Europe — la conférence de la communauté Ethereum (EthCC) — se tiendra à Bruxelles, en Belgique, en mettant l'accent sur le développement technologique et communautaire.
La conférence communautaire Ethereum (EthCC 7) a invité plus de 350 leaders d'opinion de première ligne dans l'industrie de la blockchain à prendre la parole. Alfred, un développeur d'imToken Labs, a été invité à participer et a donné une conférence intitulée "Révéler l'avenir : analyse de l'abstraction de compte multi-chaînes".
Aperçu des points de discours
Les deux éléments clés de l'abstraction de compte (AA) : 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 offre diverses options de paiement pour les transactions, améliorant ainsi la sécurité et l'expérience utilisateur.
Les fonctions de point d'entrée à la phase de "validation" d'ERC-4337 et de AA natif sont toutes deux fixes, mais à la phase d'"exécution", seul AA natif maintient un point d'entrée fixe. Les différentes manières de mise en œuvre présentent chacune des caractéristiques en matière de restrictions sur les transactions de validation et d'étapes d'exécution des transactions.
Lors de la mise en œuvre d'ERC-4337 sur une chaîne compatible EVM, il existe principalement deux différences clés : les différences de protocole dans la conception du Rollup et les différences dans la méthode de calcul des adresses. Ces différences entraînent certains détails de développement facilement négligés lors de la mise en œuvre d'ERC-4337 entre L1 et L2.
abstraction de compte简介
1. Définition de l'abstraction de compte
L'abstraction de compte (AA) comprend principalement deux points clés :
Abstraction de signature : les utilisateurs peuvent librement choisir le mécanisme de vérification, sans être limités à des algorithmes de signature numérique spécifiques (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 être sponsorisés par des tiers pour la transaction.
Cette flexibilité améliore considérablement la sécurité et l'expérience utilisateur. L'abstraction de compte vise à atteindre ces deux objectifs principaux de différentes manières.
2. Analyse de 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 une gestion de compte et des méthodes 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 est similaire à un système d'exploitation, les principales fonctions de traitement des transactions 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.
Perception de frais.
Appeler la fonction execute dans le contrat de compte pour exécuter l'opération cible de userOp.
3. Introduction à AA natif
Dans Ethereum, les comptes sont divisés en EOA et comptes de contrat. 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 réseaux blockchain.
Abstraction de compte ERC-4337 : Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
Suivre l'abstraction de compte native ERC-4337 : StarkNet et zkSync Era
Abstraction de compte natif avec une conception de confidentialité : 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 :
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 du point 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 le 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.
La principale différence entre zkSync Era et d'autres réalisations AA réside dans le fait que l'Operator doit travailler 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 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 AA OS :
ERC-4337 : validation des opérations de l'utilisateur
zkSync : validation des transactions, paiement des transactions, exécution des transactions
Dans l'ERC-4337 et l'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 l'AA natif est fixe.
3. limitations des étapes de vérification
Étant donné qu'il n'y a pas de limite de coût pour la validation des transactions, un attaquant peut mener une attaque DoS sur la mémoire tampon, ce qui peut affecter le regroupement (EIP-4337) ou les opérateurs/triants (AA natif).
EIP-4337 définit les codes d'opération interdits ainsi que la manière de restreindre l'accès au stockage. zkSync Era assouplit l'utilisation de certains OpCode :
La logique de contrat ne peut accéder qu'à sa propre case 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
La case de stockage keccak256(A || X) appartenant à toute autre adresse : cela signifie utiliser directement l'adresse comme clé dans le mapping, ce qui équivaut à accéder à la case 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, comme le numéro de bloc. StarkNet n'autorise pas non plus 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, la seule façon 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 ERC-4337 et StarkNet, il n'y a pas de restrictions spéciales lors de la phase d'exécution.
5. nombre aléatoire
Dans l'ERC-4337, la conception du point d'entrée distingue les valeurs de clé de 192 bits et les valeurs aléatoires de 64 bits.
Dans zkSync, le contrat système NonceHolder gère le nonce, garantissant une stricte augmentation, 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 un contrat spécifique.
6. Utiliser la première transaction pour le déploiement
ERC-4337 inclut le 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/ordonnanceur pour déployer le contrat de compte.
7. conception spéciale dans zkSync
Si vous transférez directement des 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 contrôlé par la clé privée de l'Ethereum EOA correspondant.
Ce type de compte est de version None plutôt que 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 4337 de L1 et 4337 de L2
Il y a deux différences clés dans la mise en œuvre de l'ERC-4337 sur une chaîne compatible EVM : les différences de protocole et les différences d'adresse.
1. Différences de protocole
Dans la conception des Rollups, L2 doit uploader des données vers 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érence d'adresse
La méthode de codage des adresses dans la fonction create de zkSync ERA est différente de celle d'Ethereum et d'OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte d'ERC-4337 sur les chaînes compatibles 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 entraîner des différences dans les adresses des contrats de compte entre les implémentations d'ERC-4337 d'Ethereum et de L2.
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 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 reste le même.
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.
7 J'aime
Récompense
7
4
Partager
Commentaire
0/400
SigmaValidator
· Il y a 16h
L'abstraction de compte, c'est juste pour le plaisir.
Voir l'originalRépondre0
NeverPresent
· Il y a 16h
Le paiement abstrait est-il si bull ?
Voir l'originalRépondre0
GateUser-beba108d
· Il y a 16h
Ça ne sert à rien, juste des paroles en l'air.
Voir l'originalRépondre0
StableNomad
· Il y a 16h
meh, encore une autre discussion sur l'AA... ça me rappelle les revendications de "sécurité" de Celsius pour être honnête
Analyse de l'abstraction de compte multi-chaînes : différences et défis entre ERC-4337 et AA natif
Analyse de l'abstraction de compte multi-chaînes : exploration de l'avenir de l'infrastructure de chiffrement
Du 8 au 11 juillet 2024, le plus grand événement annuel sur Ethereum en Europe — la conférence de la communauté Ethereum (EthCC) — se tiendra à Bruxelles, en Belgique, en mettant l'accent sur le développement technologique et communautaire.
La conférence communautaire Ethereum (EthCC 7) a invité plus de 350 leaders d'opinion de première ligne dans l'industrie de la blockchain à prendre la parole. Alfred, un développeur d'imToken Labs, a été invité à participer et a donné une conférence intitulée "Révéler l'avenir : analyse de l'abstraction de compte multi-chaînes".
Aperçu des points de discours
Les deux éléments clés de l'abstraction de compte (AA) : 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 offre diverses options de paiement pour les transactions, améliorant ainsi la sécurité et l'expérience utilisateur.
Les fonctions de point d'entrée à la phase de "validation" d'ERC-4337 et de AA natif sont toutes deux fixes, mais à la phase d'"exécution", seul AA natif maintient un point d'entrée fixe. Les différentes manières de mise en œuvre présentent chacune des caractéristiques en matière de restrictions sur les transactions de validation et d'étapes d'exécution des transactions.
Lors de la mise en œuvre d'ERC-4337 sur une chaîne compatible EVM, il existe principalement deux différences clés : les différences de protocole dans la conception du Rollup et les différences dans la méthode de calcul des adresses. Ces différences entraînent certains détails de développement facilement négligés lors de la mise en œuvre d'ERC-4337 entre L1 et L2.
abstraction de compte简介
1. Définition de l'abstraction de compte
L'abstraction de compte (AA) comprend principalement deux points clés :
Cette flexibilité améliore considérablement la sécurité et l'expérience utilisateur. L'abstraction de compte vise à atteindre ces deux objectifs principaux de différentes manières.
2. Analyse de 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 une gestion de compte et des méthodes de traitement des transactions plus flexibles.
3. Introduction à AA natif
Dans Ethereum, les comptes sont divisés en EOA et comptes de contrat. 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 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 réalisés en collaboration par le Bundler et le contrat EntryPoint.
Dans le 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.
La principale différence entre zkSync Era et d'autres réalisations AA réside dans le fait que l'Operator doit travailler 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 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 AA OS :
Dans l'ERC-4337 et l'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 l'AA natif est fixe.
3. limitations des étapes de vérification
Étant donné qu'il n'y a pas de limite de coût pour la validation des transactions, un attaquant peut mener une attaque DoS sur la mémoire tampon, ce qui peut affecter le regroupement (EIP-4337) ou les opérateurs/triants (AA natif).
EIP-4337 définit les codes d'opération interdits ainsi que la manière de restreindre l'accès au stockage. zkSync Era assouplit l'utilisation de certains OpCode :
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, la seule façon 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 ERC-4337 et StarkNet, il n'y a pas de restrictions spéciales lors de la phase d'exécution.
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 des 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 contrôlé par la clé privée de l'Ethereum EOA correspondant.
Ce type de compte est de version None plutôt que 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 4337 de L1 et 4337 de L2
Il y a deux différences clés dans la mise en œuvre de l'ERC-4337 sur une chaîne compatible EVM : les différences de protocole et les différences d'adresse.
1. Différences de protocole
Dans la conception des Rollups, L2 doit uploader des données vers 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érence d'adresse
La méthode de codage des adresses dans la fonction create de zkSync ERA est différente de celle d'Ethereum et d'OP. De plus, StarkNet utilise une fonction de hachage unique pour le calcul des adresses. Dans le contexte d'ERC-4337 sur les chaînes compatibles 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 entraîner des différences dans les adresses des contrats de compte entre les implémentations d'ERC-4337 d'Ethereum et de L2.
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 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 reste le même.