Abstraction de compte multi-chaînes : explorer l'avenir des infrastructures de chiffrement
Du 8 au 11 juillet 2024, la conférence de la communauté Ethereum (EthCC) se tiendra à Bruxelles, en Belgique. En tant que plus grand événement annuel Ethereum en Europe, cette conférence mettra l'accent sur le développement technologique et communautaire.
Lors de la conférence communautaire Ethereum (EthCC 7), plus de 350 leaders d'opinion de premier plan dans l'industrie de la blockchain ont pris la parole. Parmi eux, un développeur blockchain a été invité à participer et a prononcé un discours sur le thème "Révéler l'avenir : analyse de l'abstraction de compte multichaîne".
Résumé des points clés du discours
L'abstraction de compte (AA) comprend le noyau de l'abstraction de signature et de l'abstraction de paiement. La première permet aux utilisateurs de choisir n'importe quel mécanisme de vérification, tandis que la seconde offre diverses options de paiement pour les transactions. Cette flexibilité améliore considérablement la sécurité et l'expérience utilisateur.
Les fonctions de point d'entrée à la phase de validation d'ERC-4337 et d'AA natif sont fixes, mais à la phase d'exécution, seul l'AA natif conserve le point d'entrée fixe. Différentes méthodes de mise en œuvre présentent des caractéristiques distinctes en ce qui concerne les restrictions de validation des transactions et les étapes d'exécution des transactions.
Lors de la mise en œuvre de l'ERC-4337 sur une chaîne compatible avec EVM, deux défis majeurs se présentent : les différences de protocole dans la conception des Rollups et les différences dans la méthode de calcul des adresses. Ces différences entraînent des détails de développement difficiles à percevoir lors de la mise en œuvre de l'ERC-4337 entre L1 et L2.
Abstraction de compte : Introduction
définition de l'abstraction de compte
L'abstraction de compte (AA) comprend principalement deux concepts clés :
Abstraction de signature : les utilisateurs peuvent choisir librement n'importe quel mécanisme de validation qu'ils préfèrent, sans être limités à des algorithmes de signature numérique spécifiques (comme ECDSA).
Abstraction de paiement : les utilisateurs peuvent utiliser plusieurs moyens pour payer les frais de transaction, par exemple en utilisant des jetons ERC-20 à la place des jetons natifs, ou en faisant sponsoriser la transaction par un tiers.
Cette flexibilité améliore non seulement la sécurité, mais optimise également l'expérience utilisateur. L'objectif de l'abstraction de compte est d'atteindre ces deux concepts fondamentaux de plusieurs manières.
analyse 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 gère 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 obtenu l'autorisation du propriétaire du compte.
Perception 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 l'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 différents réseaux blockchain :
Abstraction de compte ERC-4337 : Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
Suivre l'abstraction de compte native d'ERC-4337 : StarkNet et l'ère zkSync
Abstraction de compte native avec un design de confidentialité : Aztec
Différences entre ERC-4337 et AA natif
rôle du système d'exploitation
Le système d'exploitation AA doit résoudre les problèmes suivants :
Décideur des prix du gaz
Décideur de l'ordre des transactions et position dans la mémoire tampon
Déclencheur de la fonction de point d'entrée
facteurs décisifs du 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/trieur 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.
Les principales caractéristiques de zkSync Era sont que l'Operator doit travailler en coopération avec le bootloader (contrat système). Le bootloader est responsable de l'ouverture de nouveaux blocs, de la définition des paramètres de bloc et des paramètres de Gas, et de la réception des 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 AA OS :
ERC-4337 : validation des opérations des utilisateurs
zkSync : vérification des transactions, paiement des transactions, exécution des transactions
Dans l'ERC-4337 et l'AA natif, la fonction d'entrée de la phase "vérification" est fixe, tandis que dans la phase "exécution", seule l'entrée de l'AA natif est fixe.
étapes de vérification des restrictions
É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, affectant ainsi les regroupements (EIP-4337) ou les opérateurs/triants (AA natif).
EIP-4337 définit les codes d'opération interdits ainsi que les restrictions d'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.
La logique de contrat ne peut pas accéder aux variables globales, comme le numéro de bloc.
StarkNet n'autorise pas les appels de contrats externes.
limitation des étapes d'exécution
Dans zkSync, l'exécution d'appels système nécessite de confirmer la présence des drapeaux système. Par exemple, l'augmentation du nonce nécessite une interaction avec le NonceHolder, tandis que le déploiement de contrats nécessite une interaction avec le ContractDeployer.
ERC-4337 et StarkNet n'ont pas de restrictions particulières au stade d'exécution.
traitement de nombre aléatoire
ERC-4337 : la conception du point d'entrée distingue la clé de 192 bits et la valeur aléatoire de 64 bits.
zkSync : le contrat du système NonceHolder gère le nonce, assurant une stricte augmentation.
StarkNet : le nonce est également strictement croissant, mais il n'y a pas de contrat spécifique qui gère cela.
déploiement de la première transaction
ERC-4337 : la structure userOp contient un champ initcode, utilisé pour déployer l'expéditeur (contrat de compte) dans le premier userOp.
StarkNet et zkSync : les utilisateurs doivent envoyer leur première transaction à l'opérateur/ordonneur pour déployer le contrat de compte.
conception spéciale zkSync
Dans zkSync, si vous transférez directement de l'ETH depuis un EOA Ethereum sans déployer de contrat de compte personnalisé, l'utilisateur recevra 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'EOA Ethereum correspondant.
Ce type de compte est de version None et non de version 1. Les utilisateurs ne peuvent pas appeler les fonctions de DefaultAccount car aucun code n'est déployé dans l'espace noyau.
Différences entre L1 et L2 en 4337
Il existe deux différences clés dans la mise en œuvre de l'ERC-4337 sur les chaînes compatibles avec l'EVM : la différence de protocole et la différence d'adresse.
différences de protocole
Dans la conception des Rollups, le L2 doit télécharger des données sur le L1 pour garantir la sécurité et le règlement. Dans l'ERC-4337, les frais liés à ce processus de téléchargement (tels que les frais de sécurité L1 et les frais de blob) doivent ê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 de codage des adresses dans la fonction create de zkSync ERA est différente de celle 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 de l'ERC-4337 sur les chaînes compatibles avec l'EVM, nous supposons généralement que le calcul des adresses est cohérent sur chaque chaîne. Cependant, un détail facilement négligé peut entraîner des différences dans les adresses des contrats de compte entre les implémentations de l'ERC-4337 sur Ethereum et 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 dans le bytecode, même si le code Solidity est identique.
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
8 J'aime
Récompense
8
5
Partager
Commentaire
0/400
StableGenius
· Il y a 11h
*bâille* encore une conversation aa... j'ai déjà vu ce film, empiriquement parlant c'est juste des maxies eth qui se consolent.
Voir l'originalRépondre0
OfflineNewbie
· Il y a 11h
Regarde qui est encore en train de sauter.
Voir l'originalRépondre0
TokenVelocity
· Il y a 11h
Parlons des projets une fois que toutes les chaînes seront en place...
Voir l'originalRépondre0
PessimisticLayer
· Il y a 11h
Je pense que cela ne règle que les symptômes, pas la cause.
La conférence EthCC discute de l'abstraction de compte multichaînes : comparaison technique entre l'ERC-4337 et l'AA natif.
Abstraction de compte multi-chaînes : explorer l'avenir des infrastructures de chiffrement
Du 8 au 11 juillet 2024, la conférence de la communauté Ethereum (EthCC) se tiendra à Bruxelles, en Belgique. En tant que plus grand événement annuel Ethereum en Europe, cette conférence mettra l'accent sur le développement technologique et communautaire.
Lors de la conférence communautaire Ethereum (EthCC 7), plus de 350 leaders d'opinion de premier plan dans l'industrie de la blockchain ont pris la parole. Parmi eux, un développeur blockchain a été invité à participer et a prononcé un discours sur le thème "Révéler l'avenir : analyse de l'abstraction de compte multichaîne".
Résumé des points clés du discours
L'abstraction de compte (AA) comprend le noyau de l'abstraction de signature et de l'abstraction de paiement. La première permet aux utilisateurs de choisir n'importe quel mécanisme de vérification, tandis que la seconde offre diverses options de paiement pour les transactions. Cette flexibilité améliore considérablement la sécurité et l'expérience utilisateur.
Les fonctions de point d'entrée à la phase de validation d'ERC-4337 et d'AA natif sont fixes, mais à la phase d'exécution, seul l'AA natif conserve le point d'entrée fixe. Différentes méthodes de mise en œuvre présentent des caractéristiques distinctes en ce qui concerne les restrictions de validation des transactions et les étapes d'exécution des transactions.
Lors de la mise en œuvre de l'ERC-4337 sur une chaîne compatible avec EVM, deux défis majeurs se présentent : les différences de protocole dans la conception des Rollups et les différences dans la méthode de calcul des adresses. Ces différences entraînent des détails de développement difficiles à percevoir lors de la mise en œuvre de l'ERC-4337 entre L1 et L2.
Abstraction de compte : Introduction
définition de l'abstraction de compte
L'abstraction de compte (AA) comprend principalement deux concepts clés :
Abstraction de signature : les utilisateurs peuvent choisir librement n'importe quel mécanisme de validation qu'ils préfèrent, sans être limités à des algorithmes de signature numérique spécifiques (comme ECDSA).
Abstraction de paiement : les utilisateurs peuvent utiliser plusieurs moyens pour payer les frais de transaction, par exemple en utilisant des jetons ERC-20 à la place des jetons natifs, ou en faisant sponsoriser la transaction par un tiers.
Cette flexibilité améliore non seulement la sécurité, mais optimise également l'expérience utilisateur. L'objectif de l'abstraction de compte est d'atteindre ces deux concepts fondamentaux de plusieurs manières.
analyse 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 gère 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 l'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 différents réseaux blockchain :
Différences entre ERC-4337 et AA natif
rôle du système d'exploitation
Le système d'exploitation AA 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/trieur 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.
Les principales caractéristiques de zkSync Era sont que l'Operator doit travailler en coopération avec le bootloader (contrat système). Le bootloader est responsable de l'ouverture de nouveaux blocs, de la définition des paramètres de bloc et des paramètres de Gas, et de la réception des 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 AA OS :
Dans l'ERC-4337 et l'AA natif, la fonction d'entrée de la phase "vérification" est fixe, tandis que dans la phase "exécution", seule l'entrée de l'AA natif est fixe.
étapes de vérification des restrictions
É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, affectant ainsi les regroupements (EIP-4337) ou les opérateurs/triants (AA natif).
EIP-4337 définit les codes d'opération interdits ainsi que les restrictions d'accès au stockage. zkSync Era assouplit l'utilisation de certains OpCode :
limitation des étapes d'exécution
Dans zkSync, l'exécution d'appels système nécessite de confirmer la présence des drapeaux système. Par exemple, l'augmentation du nonce nécessite une interaction avec le NonceHolder, tandis que le déploiement de contrats nécessite une interaction avec le ContractDeployer.
ERC-4337 et StarkNet n'ont pas de restrictions particulières au stade d'exécution.
traitement de nombre aléatoire
déploiement de la première transaction
conception spéciale zkSync
Dans zkSync, si vous transférez directement de l'ETH depuis un EOA Ethereum sans déployer de contrat de compte personnalisé, l'utilisateur recevra 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'EOA Ethereum correspondant.
Ce type de compte est de version None et non de version 1. Les utilisateurs ne peuvent pas appeler les fonctions de DefaultAccount car aucun code n'est déployé dans l'espace noyau.
Différences entre L1 et L2 en 4337
Il existe deux différences clés dans la mise en œuvre de l'ERC-4337 sur les chaînes compatibles avec l'EVM : la différence de protocole et la différence d'adresse.
différences de protocole
Dans la conception des Rollups, le L2 doit télécharger des données sur le L1 pour garantir la sécurité et le règlement. Dans l'ERC-4337, les frais liés à ce processus de téléchargement (tels que les frais de sécurité L1 et les frais de blob) doivent ê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 de codage des adresses dans la fonction create de zkSync ERA est différente de celle 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 de l'ERC-4337 sur les chaînes compatibles avec l'EVM, nous supposons généralement que le calcul des adresses est cohérent sur chaque chaîne. Cependant, un détail facilement négligé peut entraîner des différences dans les adresses des contrats de compte entre les implémentations de l'ERC-4337 sur Ethereum et 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 dans le bytecode, même si le code Solidity est identique.