Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux grandes parties :
La première partie part de la première proposition AA de 2015, fait un état des lieux des principales propositions EIP jusqu'à présent, explore l'évolution historique des propositions AA et fournit une évaluation globale des différents schémas.
La deuxième partie se concentre sur la comparaison des réactions du marché face au lancement de l'EIP4337, ainsi qu'une analyse approfondie de l'EIP7702 qui sera intégré dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition fusionnée, elle changera radicalement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, explorons-le ensemble.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a de nouveau mis à jour la feuille de route du développement d'ETH à la fin de 2023, mais la position sur l'abstraction de compte n'a pas changé. Le modèle dominant actuel passe de l'EIP-4337 à la prochaine étape de "conversion volontaire des comptes EOA".
1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total d'adresses d'EIP4337 sur les chaînes majeures n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal Ethereum, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses distinctes sur le réseau principal Ethereum a atteint 270 millions, on peut dire que le développement d'EIP4337 sur le réseau principal est lent.
Cependant, cela n'affecte pas la valeur intrinsèque de l'AA. La conception de l'EIP4337 rend difficile sa compatibilité ascendante sur la chaîne principale. Avec l'intégration généralisée des chaînes L2 dans l'AA natif, le nombre d'adresses EIP4337 a connu une explosion sur L2, avec des utilisateurs actifs mensuels de 1 million et 3 millions respectivement sur les chaînes Base et Polygon en juillet, ce qui est impressionnant.
Ainsi, la conception de l'EIP4337 n'est pas erronée, elle présente de nombreux avantages. La situation actuelle découle des différences entre la chaîne principale et le L2, qui nécessitent des solutions adaptées à chacune.
2. Qu'est-ce que l'abstraction de compte ?
L'abstraction de compte est essentiellement une solution au problème de la séparation des droits de propriété.
Il existe deux types de comptes dans l'architecture EVM : le compte externe ( EOA ) et le compte de contrat ( CA ). Dans le compte externe, la propriété et le droit de signature sont détenus par la même entité. La personne qui possède la clé privée détient non seulement la "propriété" du compte, mais a également le droit de "signer le transfert de tous les actifs".
Ceci est déterminé par la structure des transactions des comptes Ethereum. À partir de la structure des transactions, on peut voir que la transaction standard n'a en réalité pas de champ From. Lors du transfert de fonds, l'adresse de consommation spécifique est déduite à l'aide du paramètre VRS (, c'est-à-dire que la signature de l'utilisateur ) est utilisée pour la rétro-analyse.
Le principal effet de l'EIP4337 est d'ajouter une adresse d'expéditeur dans le champ de transaction, permettant ainsi la séparation de la clé privée et de l'adresse manipulée.
La raison pour laquelle la séparation des droits de propriété est si importante est que la conception des comptes externes (EOA) engendrera de nombreux problèmes :
La clé privée est difficile à protéger : perdre la clé privée signifie perdre tous ses actifs.
Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme ECDSA.
Autorisation de signature trop élevée : pas de fonction multi-signature native, une seule signature suffit pour exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en masse ne sont pas prises en charge.
La confidentialité des transactions est facilement compromise : les transactions en tête-à-tête permettent d'analyser les informations des détenteurs de compte.
Ces restrictions rendent l'utilisation d'Ethereum difficile pour les utilisateurs ordinaires :
Tout d'abord, l'utilisateur doit détenir des Éthers et assumer le risque de fluctuation des prix.
Ensuite, les utilisateurs doivent gérer des logiques de frais complexes, telles que le prix du Gas, la limite de Gas, les concepts de blocage des transactions, etc.
Enfin, les portefeuilles ou applications de blockchain essaient d'améliorer l'expérience utilisateur grâce à l'optimisation des produits, mais les résultats sont limités.
Ainsi, la solution réside dans la mise en œuvre de l'abstraction de compte, qui découple la propriété (Owner) et le droit de signature (Signer), résolvant progressivement les problèmes mentionnés ci-dessus.
Il y a eu plusieurs solutions dans l'histoire, qui se résument finalement à deux voies.
3. Contexte historique des propositions d'abstraction de compte
Il semble y avoir de nombreuses propositions EIP pour résoudre le problème, mais au fond, il s'agit de deux idées principales. Chaque problème soulevé par une EIP non approuvée a contribué aux points de rupture des solutions existantes.
3.1 Première voie : transformer l'adresse EOA en adresse CA
Dès novembre 2015, Vitalik a proposé une nouvelle structure de compte basée sur des contrats dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, supportant le paiement des frais de transaction en ERC20, et grâce à des contrats précompilés, les tokens natifs ont été transformés en équivalents de stockage de type ERC20, simplifiant les champs de transaction à to, startgas, data et code.
Cette solution peut être qualifiée de transformation de type grand bond en avant, elle modifiera considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" (, qui est précisément l'effet que l'EIP-7702 souhaite réaliser ).
Il peut également engendrer d'autres fonctionnalités, telles que :
Permettre aux transactions d'utiliser plus d'algorithmes de cryptographie, avec des méthodes de vérification et d'authentification spécifiées par le Code interne de chaque adresse.
Doté de caractéristiques de résistance aux attaques quantiques, car le code peut être mis à jour.
Permettre à l'Éther d'avoir des fonctions similaires à celles des contrats ERC20, telles que l'autorisation de prélèvement.
Améliorer l'espace de personnalisation du compte, compatible avec la récupération sociale, le support SBT, la récupération de clés, etc.
La raison pour laquelle nous n'avons pas continué à avancer est principalement que nous avons fait un trop grand pas, en ne tenant pas suffisamment compte des problèmes de collision de hachage de transaction actuels et des risques de sécurité. Cependant, chaque concept positif est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702.
Il y a une série d'EIP qui tentent d'améliorer cette logique :
EIP-859: abstraction de compte de la chaîne principale (2018-01-30)
Essayer de résoudre le problème de déploiement du Code. Son rôle principal est que si le contrat de la partie transactionnelle n'est pas déployé, alors le déploiement du portefeuille de contrat est effectué en utilisant le paramètre code joint à la transaction. Un nouvel opcode PAYGAS a également été proposé, servant non seulement à payer le gas, mais aussi comme séparateur entre la partie de vérification et la partie d'exécution dans les paramètres de la transaction.
Bien que cela n'ait pas réussi à l'époque, cela est devenu l'une des logiques centrales de l'EIP7702. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut inclure un certain code, permettant à l'adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code de compte EOA (2024-05-07)
C'est le cœur de la discussion ultérieure de cet article, proposé par Vitalik comme une alternative à l'EIP-3074. L'EIP-3074 a été abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra(Pectra).
3.2 Deuxième approche : faire en sorte que l'adresse EOA pilote l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL (2020-10-15)
Ajouter deux nouveaux OpCode dans l'EVM : AUTH et AUTHCALL, permettant aux EOA d'autoriser des contrats à appeler d'autres contrats en remplaçant l'identité de l'EOA par ces deux opcodes.
En résumé, un EOA peut envoyer des messages signés ( et des transactions ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les opcodes AUTH et AUTHCALL pour émettre des transactions à la place de l'EOA.
EIP-4337 : mise en œuvre de l'abstraction de compte dans le pool de mémoire des transactions (2021-09-29)
Conçu sous l'inspiration de MEV, sa valeur fondamentale est d'éviter complètement les modifications du protocole de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient à la mémoire pool, les bundlers le regroupent et le livrent pour exécuter des transactions de contrat du point de vue des mineurs, ce qui revient essentiellement à faire exécuter des transactions sous-jacentes et des opérations de compte au niveau des contrats.
EIP-5189 : Opération d'abstraction de compte via des endosseurs (2022-06-29)
C'est une optimisation de la logique d'EIP4337, visant à prévenir les attaques de blocage DoS des Bundlers malveillants en établissant un mécanisme de parrainage d'amende sur les fonds.
3.3 autres propositions supportant l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)
Ceci est une proposition déjà finalisée, définissant un nouveau type de transaction comme une enveloppe pour les futurs types de transactions supplémentaires.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il est possible de distinguer les types de transaction par un codage spécifique, nécessitant uniquement une compatibilité ascendante, sans nécessité de compatibilité descendante. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilise un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : rendre les adresses EOA incapables de déployer des contrats (2021-06-10)
Ceci est un plan complémentaire sur le chemin AA, destiné à éviter les conflits entre l'adresse de déploiement des contrats et les adresses EOA. Il contrôlera la méthode de génération des contrats, interdisant le déploiement de code à des adresses qui sont déjà des adresses EOA. Ce risque est en réalité très faible, car une adresse Ethereum a une longueur de 160 bits. Bien qu'il existe une méthode pour générer une clé privée correspondant à une adresse de contrat spécifiée par collision, cela nécessiterait environ un an de calcul avec la puissance totale de Bitcoin.
3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il faut comprendre la valeur après la conversion en CA, qui est essentiellement l'effet réel de l'EIP-4337 :
Prise en charge des transactions en bloc
Prise en charge de la récupération sociale
Support de la vérification de signature personnalisée
Pas besoin de payer des frais avec le jeton natif.
Gestion des permissions à un niveau plus granulaire
Scalabilité
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Il semble mieux, mais il est piégé dans un cercle vicieux du développement du marché : de nombreuses Dapp ne sont pas encore compatibles, les utilisateurs ne souhaitent pas utiliser d'adresses CA, et l'utilisation de CA entraîne des coûts de transaction plus élevés ( dans les scénarios de transfert ordinaires, les frais de transaction doublent ), une dépendance excessive à la compatibilité des Dapp elles-mêmes.
Donc, cela n'a pas encore été largement adopté sur le réseau principal d'Ethereum.
Le coût est le critère de mesure le plus important pour les utilisateurs, il faut réduire les coûts.
Mais pour vraiment réduire le GAS, il faut que l'Ethereum lui-même effectue une mise à niveau par soft fork, modifiant le calcul du GAS ou les modules de consommation de GAS des opcode, etc. Puisqu'il s'agit d'un soft fork, autant envisager directement l'EIP-7702.
4. Analyse complète de l'EIP-7702
4.1 Qu'est-ce que l'EIP-7702
Il permet aux EOA de disposer temporairement de fonctionnalités de contrat intelligent dans une seule transaction grâce à un nouveau type de transaction, supportant les transactions en lot, les transactions sans Gas et la gestion des autorisations personnalisées, tout en n'ayant pas besoin d'introduire un nouveau opCode EVM ( qui pourrait affecter la compatibilité ascendante ).
Les utilisateurs n'ont pas besoin de déployer des contrats intelligents pour bénéficier de la plupart des capacités AA, et ils peuvent même offrir la possibilité à des tiers de lancer des transactions au nom des utilisateurs, sans que ces derniers aient à fournir de clé privée, il leur suffit de signer des informations d'autorisation.
4.2 structure de données
Définir un nouveau type de transaction 0x04, TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
Il est important de noter que l'objet authorization_list a été ajouté, stockant le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe le code de contrat à exécuter en même temps que la transaction, sous forme de liste à deux dimensions, permettant de stocker plusieurs informations d'opération en lot et d'exécuter des opérations en masse.
Lors de l'exécution de la transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] dans authorization_list :
Récupérer l'adresse du signataire à partir des signatures r, s en utilisant ecrecover.
Vérifiez l'ID de chaîne ( pour éviter la relecture de chaînes de forks ).
Vérifiez si le code du signataire authority est vide ou délégué.
Vérifiez le signataire d’autorité nonce( la relecture de la signature anti-autorité ).
Réglez le code du signataire d'autorité sur 0xef0100 || address( pour contourner la stratégie de prévention des collisions EIP3607).
Augmenter le nonce du signataire authority ( pour prévenir la répétition de signature partielle ).
Ajouter le compte signataire d'authority à la liste des adresses visitées ( et transférer l'adresse chaude, réduisant les frais de gaz de stockage de requête ).
4.3.2 Phase d'exécution des opérations
La "nouvelle" version n'a modifié que le comportement de déploiement du code.
Ne pas définir account_code comme contract_code, mais plutôt récupérer le code spécifié par address dans authorization_list et le définir comme account_code.
Lors de l'exécution du code autorisé, le code est chargé depuis le champ adresse de authorization_list à l'adresse spécifiée, puis exécuté dans le contexte du compte du signataire.
Cela signifie que le code du contrat utilisateur est effectivement stocké à une adresse spécifique sur la chaîne, et non directement inclus dans la transaction.
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.
11 J'aime
Récompense
11
7
Partager
Commentaire
0/400
LiquidationWizard
· 07-25 01:53
Qu'est-ce que ce putain de 7702 fait encore ?
Voir l'originalRépondre0
GasWaster
· 07-24 18:03
oh mon dieu, encore un eip... j'ai dépensé 2eth en tx échouées l'année dernière et maintenant ils me disent ça ?
Voir l'originalRépondre0
EntryPositionAnalyst
· 07-24 15:19
AA a de nouveau pris de l'ampleur après quelques jours.
Voir l'originalRépondre0
MetaMuskRat
· 07-22 06:03
On recommence à parler d'AA, c'est du vieux vin dans de nouvelles bouteilles pour le Blockchain.
Voir l'originalRépondre0
WenAirdrop
· 07-22 05:57
Blockchain veille élans chien
Voir l'originalRépondre0
CryptoAdventurer
· 07-22 05:56
La théorie de l'évolution des pigeons Épisode 7702 est diffusé.
EIP-7702 va redéfinir l'écosystème Ethereum, l'abstraction de compte entre dans une nouvelle ère.
Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux grandes parties :
La première partie part de la première proposition AA de 2015, fait un état des lieux des principales propositions EIP jusqu'à présent, explore l'évolution historique des propositions AA et fournit une évaluation globale des différents schémas.
La deuxième partie se concentre sur la comparaison des réactions du marché face au lancement de l'EIP4337, ainsi qu'une analyse approfondie de l'EIP7702 qui sera intégré dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition fusionnée, elle changera radicalement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, explorons-le ensemble.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a de nouveau mis à jour la feuille de route du développement d'ETH à la fin de 2023, mais la position sur l'abstraction de compte n'a pas changé. Le modèle dominant actuel passe de l'EIP-4337 à la prochaine étape de "conversion volontaire des comptes EOA".
1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total d'adresses d'EIP4337 sur les chaînes majeures n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal Ethereum, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses distinctes sur le réseau principal Ethereum a atteint 270 millions, on peut dire que le développement d'EIP4337 sur le réseau principal est lent.
Cependant, cela n'affecte pas la valeur intrinsèque de l'AA. La conception de l'EIP4337 rend difficile sa compatibilité ascendante sur la chaîne principale. Avec l'intégration généralisée des chaînes L2 dans l'AA natif, le nombre d'adresses EIP4337 a connu une explosion sur L2, avec des utilisateurs actifs mensuels de 1 million et 3 millions respectivement sur les chaînes Base et Polygon en juillet, ce qui est impressionnant.
Ainsi, la conception de l'EIP4337 n'est pas erronée, elle présente de nombreux avantages. La situation actuelle découle des différences entre la chaîne principale et le L2, qui nécessitent des solutions adaptées à chacune.
2. Qu'est-ce que l'abstraction de compte ?
L'abstraction de compte est essentiellement une solution au problème de la séparation des droits de propriété.
Il existe deux types de comptes dans l'architecture EVM : le compte externe ( EOA ) et le compte de contrat ( CA ). Dans le compte externe, la propriété et le droit de signature sont détenus par la même entité. La personne qui possède la clé privée détient non seulement la "propriété" du compte, mais a également le droit de "signer le transfert de tous les actifs".
Ceci est déterminé par la structure des transactions des comptes Ethereum. À partir de la structure des transactions, on peut voir que la transaction standard n'a en réalité pas de champ From. Lors du transfert de fonds, l'adresse de consommation spécifique est déduite à l'aide du paramètre VRS (, c'est-à-dire que la signature de l'utilisateur ) est utilisée pour la rétro-analyse.
Le principal effet de l'EIP4337 est d'ajouter une adresse d'expéditeur dans le champ de transaction, permettant ainsi la séparation de la clé privée et de l'adresse manipulée.
La raison pour laquelle la séparation des droits de propriété est si importante est que la conception des comptes externes (EOA) engendrera de nombreux problèmes :
La clé privée est difficile à protéger : perdre la clé privée signifie perdre tous ses actifs.
Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme ECDSA.
Autorisation de signature trop élevée : pas de fonction multi-signature native, une seule signature suffit pour exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en masse ne sont pas prises en charge.
La confidentialité des transactions est facilement compromise : les transactions en tête-à-tête permettent d'analyser les informations des détenteurs de compte.
Ces restrictions rendent l'utilisation d'Ethereum difficile pour les utilisateurs ordinaires :
Tout d'abord, l'utilisateur doit détenir des Éthers et assumer le risque de fluctuation des prix.
Ensuite, les utilisateurs doivent gérer des logiques de frais complexes, telles que le prix du Gas, la limite de Gas, les concepts de blocage des transactions, etc.
Enfin, les portefeuilles ou applications de blockchain essaient d'améliorer l'expérience utilisateur grâce à l'optimisation des produits, mais les résultats sont limités.
Ainsi, la solution réside dans la mise en œuvre de l'abstraction de compte, qui découple la propriété (Owner) et le droit de signature (Signer), résolvant progressivement les problèmes mentionnés ci-dessus.
Il y a eu plusieurs solutions dans l'histoire, qui se résument finalement à deux voies.
3. Contexte historique des propositions d'abstraction de compte
Il semble y avoir de nombreuses propositions EIP pour résoudre le problème, mais au fond, il s'agit de deux idées principales. Chaque problème soulevé par une EIP non approuvée a contribué aux points de rupture des solutions existantes.
3.1 Première voie : transformer l'adresse EOA en adresse CA
Dès novembre 2015, Vitalik a proposé une nouvelle structure de compte basée sur des contrats dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, supportant le paiement des frais de transaction en ERC20, et grâce à des contrats précompilés, les tokens natifs ont été transformés en équivalents de stockage de type ERC20, simplifiant les champs de transaction à to, startgas, data et code.
Cette solution peut être qualifiée de transformation de type grand bond en avant, elle modifiera considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" (, qui est précisément l'effet que l'EIP-7702 souhaite réaliser ).
Il peut également engendrer d'autres fonctionnalités, telles que :
Permettre aux transactions d'utiliser plus d'algorithmes de cryptographie, avec des méthodes de vérification et d'authentification spécifiées par le Code interne de chaque adresse.
Doté de caractéristiques de résistance aux attaques quantiques, car le code peut être mis à jour.
Permettre à l'Éther d'avoir des fonctions similaires à celles des contrats ERC20, telles que l'autorisation de prélèvement.
Améliorer l'espace de personnalisation du compte, compatible avec la récupération sociale, le support SBT, la récupération de clés, etc.
La raison pour laquelle nous n'avons pas continué à avancer est principalement que nous avons fait un trop grand pas, en ne tenant pas suffisamment compte des problèmes de collision de hachage de transaction actuels et des risques de sécurité. Cependant, chaque concept positif est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702.
Il y a une série d'EIP qui tentent d'améliorer cette logique :
EIP-859: abstraction de compte de la chaîne principale (2018-01-30)
Essayer de résoudre le problème de déploiement du Code. Son rôle principal est que si le contrat de la partie transactionnelle n'est pas déployé, alors le déploiement du portefeuille de contrat est effectué en utilisant le paramètre code joint à la transaction. Un nouvel opcode PAYGAS a également été proposé, servant non seulement à payer le gas, mais aussi comme séparateur entre la partie de vérification et la partie d'exécution dans les paramètres de la transaction.
Bien que cela n'ait pas réussi à l'époque, cela est devenu l'une des logiques centrales de l'EIP7702. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut inclure un certain code, permettant à l'adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code de compte EOA (2024-05-07)
C'est le cœur de la discussion ultérieure de cet article, proposé par Vitalik comme une alternative à l'EIP-3074. L'EIP-3074 a été abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra(Pectra).
3.2 Deuxième approche : faire en sorte que l'adresse EOA pilote l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL (2020-10-15)
Ajouter deux nouveaux OpCode dans l'EVM : AUTH et AUTHCALL, permettant aux EOA d'autoriser des contrats à appeler d'autres contrats en remplaçant l'identité de l'EOA par ces deux opcodes.
En résumé, un EOA peut envoyer des messages signés ( et des transactions ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les opcodes AUTH et AUTHCALL pour émettre des transactions à la place de l'EOA.
EIP-4337 : mise en œuvre de l'abstraction de compte dans le pool de mémoire des transactions (2021-09-29)
Conçu sous l'inspiration de MEV, sa valeur fondamentale est d'éviter complètement les modifications du protocole de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient à la mémoire pool, les bundlers le regroupent et le livrent pour exécuter des transactions de contrat du point de vue des mineurs, ce qui revient essentiellement à faire exécuter des transactions sous-jacentes et des opérations de compte au niveau des contrats.
EIP-5189 : Opération d'abstraction de compte via des endosseurs (2022-06-29)
C'est une optimisation de la logique d'EIP4337, visant à prévenir les attaques de blocage DoS des Bundlers malveillants en établissant un mécanisme de parrainage d'amende sur les fonds.
3.3 autres propositions supportant l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)
Ceci est une proposition déjà finalisée, définissant un nouveau type de transaction comme une enveloppe pour les futurs types de transactions supplémentaires.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il est possible de distinguer les types de transaction par un codage spécifique, nécessitant uniquement une compatibilité ascendante, sans nécessité de compatibilité descendante. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilise un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : rendre les adresses EOA incapables de déployer des contrats (2021-06-10)
Ceci est un plan complémentaire sur le chemin AA, destiné à éviter les conflits entre l'adresse de déploiement des contrats et les adresses EOA. Il contrôlera la méthode de génération des contrats, interdisant le déploiement de code à des adresses qui sont déjà des adresses EOA. Ce risque est en réalité très faible, car une adresse Ethereum a une longueur de 160 bits. Bien qu'il existe une méthode pour générer une clé privée correspondant à une adresse de contrat spécifiée par collision, cela nécessiterait environ un an de calcul avec la puissance totale de Bitcoin.
3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il faut comprendre la valeur après la conversion en CA, qui est essentiellement l'effet réel de l'EIP-4337 :
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Il semble mieux, mais il est piégé dans un cercle vicieux du développement du marché : de nombreuses Dapp ne sont pas encore compatibles, les utilisateurs ne souhaitent pas utiliser d'adresses CA, et l'utilisation de CA entraîne des coûts de transaction plus élevés ( dans les scénarios de transfert ordinaires, les frais de transaction doublent ), une dépendance excessive à la compatibilité des Dapp elles-mêmes.
Donc, cela n'a pas encore été largement adopté sur le réseau principal d'Ethereum.
Le coût est le critère de mesure le plus important pour les utilisateurs, il faut réduire les coûts.
Mais pour vraiment réduire le GAS, il faut que l'Ethereum lui-même effectue une mise à niveau par soft fork, modifiant le calcul du GAS ou les modules de consommation de GAS des opcode, etc. Puisqu'il s'agit d'un soft fork, autant envisager directement l'EIP-7702.
4. Analyse complète de l'EIP-7702
4.1 Qu'est-ce que l'EIP-7702
Il permet aux EOA de disposer temporairement de fonctionnalités de contrat intelligent dans une seule transaction grâce à un nouveau type de transaction, supportant les transactions en lot, les transactions sans Gas et la gestion des autorisations personnalisées, tout en n'ayant pas besoin d'introduire un nouveau opCode EVM ( qui pourrait affecter la compatibilité ascendante ).
Les utilisateurs n'ont pas besoin de déployer des contrats intelligents pour bénéficier de la plupart des capacités AA, et ils peuvent même offrir la possibilité à des tiers de lancer des transactions au nom des utilisateurs, sans que ces derniers aient à fournir de clé privée, il leur suffit de signer des informations d'autorisation.
4.2 structure de données
Définir un nouveau type de transaction 0x04, TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
Il est important de noter que l'objet authorization_list a été ajouté, stockant le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe le code de contrat à exécuter en même temps que la transaction, sous forme de liste à deux dimensions, permettant de stocker plusieurs informations d'opération en lot et d'exécuter des opérations en masse.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
4.3 cycle de vie de la transaction
4.3.1 Phase de validation
Lors de l'exécution de la transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] dans authorization_list :
4.3.2 Phase d'exécution des opérations
La "nouvelle" version n'a modifié que le comportement de déploiement du code.
Ne pas définir account_code comme contract_code, mais plutôt récupérer le code spécifié par address dans authorization_list et le définir comme account_code.
Lors de l'exécution du code autorisé, le code est chargé depuis le champ adresse de authorization_list à l'adresse spécifiée, puis exécuté dans le contexte du compte du signataire.
Cela signifie que le code du contrat utilisateur est effectivement stocké à une adresse spécifique sur la chaîne, et non directement inclus dans la transaction.