Analyse approfondie de l'histoire et de l'avenir de l'abstraction de compte sur Ethereum
Introduction
Cet article est divisé en deux grandes sections :
La partie supérieure commence avec la première proposition AA de 2015, le système a organisé le contenu principal des propositions EIP jusqu'à présent, espérant explorer le développement historique des propositions AA à travers une perspective historique et évaluer de manière complète les avantages et les inconvénients de chaque方案.
La deuxième partie se concentre sur la comparaison des réactions froides du marché face à la sortie de l'EIP4337, et analyse en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à jour d'Ethereum. Une fois cette proposition fusionnée, elle changera complètement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, explorons cela en détail 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, où les dispositions concernant l'abstraction de compte restent inchangées. Le modèle dominant évolue actuellement de l'EIP-4337 vers la prochaine étape "conversion volontaire de compte EOA".
Plus d'un an après le lancement de l'EIP4337, le 1er mars 2023 lors du WalletCon à Denver, il a été annoncé officiellement que le contrat de base ERC-4337, conçu et réalisé par les développeurs de la fondation Ethereum, a été audité par OpenZeppelin et est considéré comme un jalon historique de son lancement officiel (. Le marché présente un état contradictoire où les utilisateurs reconnaissent largement mais n'utilisent pas beaucoup. Dans ce contexte, le progrès de l'EIP-7702 a été considérablement avancé et il a été confirmé qu'il sera intégré dans la prochaine mise à niveau.
) 1.2 état du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total de comptes d'EIP4337 sur les chaînes principales n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal Ethereum, ce qui est considérablement inférieur au nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions. On peut dire qu'EIP4337 n'a presque pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur intrinsèque de l'abstraction de compte (AA). La conception de l'EIP4337 était dès le départ vouée à ne pas résoudre le problème grave de compatibilité ascendante du réseau principal. Avec l'intégration généralisée de différentes chaînes L2 dans l'AA native, le nombre d'adresses EIP4337 a explosé sur L2, avec respectivement 1 million et 3 millions d'utilisateurs actifs mensuels sur les chaînes Base et Polygon en juillet, ce qui est plutôt satisfaisant.
Par conséquent, ce n'est pas que la conception de l'EIP4337 soit erronée, elle a de nombreux avantages que nous résumerons systématiquement plus tard. La situation actuelle provient des différences entre la chaîne principale et le L2, elles nécessitent chacune des solutions adaptées.
2. Qu'est-ce que l'abstraction de compte?
L'abstraction de compte résout essentiellement le 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 ) Compte de contrat (. La propriété et le droit de signature du compte externe sont en réalité détenus par la même entité. La personne qui détient la clé privée possède 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. La structure des transactions montre que les transactions standard d'Ethereum n'ont pas de champ From. En réalité, l'adresse From est extraite par la signature de l'utilisateur avec les paramètres VRS ), en inversant la procédure de décodage.
Cela implique des concepts tels que la cryptographie asymétrique comme l'ECDSA et les fonctions de seuil unidirectionnelles, que nous n'explorerons pas ici. En résumé, la sécurité est assurée par la cryptographie, ce qui a également conduit à la difficulté actuelle de la fusion des droits de propriété des adresses EOA.
L'effet principal de l'EIP4337 est d'ajouter l'adresse de l'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 davantage de problèmes :
Difficulté de protection des clés privées : la perte de la clé privée (, les attaques de hackers et les décryptages cryptographiques ) signifient la perte de tous les actifs.
Algorithme de signature unique : la vérification des transactions du protocole natif ne peut utiliser que l'algorithme de signature et de vérification ECDSA.
Autorisation de signature trop élevée : aucune multi-signature native ( la multi-signature ne peut être réalisée que par un contrat intelligent ), 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 supportées.
Fuite de la vie privée des transactions : les transactions de pair à pair facilitent l'analyse des informations privées des détenteurs de comptes.
Ces restrictions rendent l'utilisation d'Ethereum difficile pour les utilisateurs ordinaires :
Tout d'abord, pour utiliser n'importe quelle application sur Ethereum, les utilisateurs doivent détenir de l'Éther ( et assumer le risque de fluctuation des prix ).
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, le prix du Gas, la limite de Gas, le blocage des transactions ( l'ordre du Nonce ) et d'autres concepts qui sont trop complexes pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications blockchain tentent d'améliorer l'expérience utilisateur par l'optimisation des produits, les résultats sont limités.
Ainsi, le point de rupture réside dans la mise en œuvre de l'abstraction de compte, déconnectant la propriété (Owner) et le droit de signature (Signer), afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Dans l'histoire, plusieurs solutions ont été proposées, qui se sont finalement regroupées en deux voies.
3. Contexte historique des propositions d'abstraction de compte
( 3.1 Première option : transformer une adresse EOA en adresse CA
Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte sous forme de contrat dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, changeant le support des frais de transaction pour être payé par ERC20, et grâce à des contrats précompilés, le jeton natif a été transformé en un solde de type ERC20 ) avec des fonctionnalités d'autorisation de prélèvement ###, et les champs de transaction ont été simplifiés en to, startgas, data et code.
Cette proposition peut être considérée comme une transformation de type Grand Bond en avant, modifiant 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 cherche à réaliser ).
Il peut également donner lieu à d'autres fonctionnalités, telles que :
Les transactions utilisent davantage d'algorithmes cryptographiques, qui peuvent être spécifiés par les méthodes de signature et d'authentification internes au Code de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est mis à jour.
Rendre l'Éther compatible avec les caractéristiques fonctionnelles des contrats ERC20, l'effet clé est de réaliser une autorisation de prélèvement, sans consommer de monnaie native.
Améliorer l'espace personnalisé du compte, compatible avec la récupération sociale, le support SBT, la récupération de clé, etc.
La raison pour laquelle nous n'avons pas pu continuer est simple : il est évident que le pas était trop grand, et que nous n'avons pas suffisamment pris en compte les problèmes de conflit de hachage de transaction actuels et les risques de sécurité, c'est pourquoi cela a été mis en attente. Mais chaque concept positif est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702.
Ensuite, 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 de Code, la fonction principale est que si le contrat de la partie transactionnelle n'est pas déployé, alors on utilise le paramètre code joint à la transaction pour exécuter le déploiement du portefeuille de contrat. De plus, un nouvel opcode PAYGAS a été proposé, qui sert non seulement à payer le gas, mais aussi de séparateur entre la partie de validation et la partie d'exécution dans les paramètres de la transaction.
Bien qu'il n'ait pas été mis en œuvre à 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 être accompagnée d'un certain code, permettant ainsi à l'adresse EOA de posséder des capacités de contrat dans cette transaction.
EIP-7702 : définir le code de compte EOA (2024-05-07)
C'est également le cœur du mécanisme de discussion ultérieur de cet article, proposé par Vitalik comme alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné, et l'EIP-7702 est déterminé pour être inclus dans le prochain fork dur ETH Prague/Electra(Pectra), dont nous développerons les détails plus tard.
( 3.2 Deuxième option : laisser l'adresse EOA piloter l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL )2020-10-15###
Ajouter deux nouveaux OpCodes AUTH et AUTHCALL dans l'EVM, 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 un message signé ( transaction ) à un contrat en lequel il a confiance ( appelé Invoker ), ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour remplacer l'EOA dans l'envoi de transactions.
EIP-4337 : mise en œuvre de l'abstraction de compte via le pool de mémoire des transactions (2021-09-29)
Conçu sous l'inspiration de MEV, sa valeur fondamentale est de pouvoir éviter complètement les modifications du protocole de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans la mémoire tampon, et que les bundlers regroupent et livrent en masse pour exécuter les transactions de contrat du point de vue des mineurs, ce qui revient essentiellement à faire exécuter les transactions sous-jacentes et les opérations de compte au niveau du contrat.
EIP-5189 : opération d'abstraction de compte par des endosseurs (2022-06-29)
C'est une optimisation de la logique EIP4337, qui fait face à des Bundlers malveillants en établissant un mécanisme d'entérinement par des amendes sur les fonds pour prévenir les attaques par blocage DoS.
( 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à Final, définissant un nouveau type de transaction, servant d'enveloppe pour les futurs types de transactions à ajouter.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il suffit de différencier les types de transactions par un codage spécifique, en étant uniquement compatible avec les versions antérieures, sans nécessiter de compatibilité avec les versions ultérieures. L'exemple le plus courant est l'EIP1559, qui différencie les frais de transaction, utilise un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : interdiction des adresses EOA de déployer des contrats (2021-06-10)
Ceci est un plan d'appoint sur le chemin AA, destiné à empêcher les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Il contrôlera la méthode de génération de contrat, interdisant au système de déployer du code à une adresse qui est déjà une adresse EOA. Ce risque est en réalité très faible, étant donné que l'adresse Ethereum mesure 160 bits de long. Bien qu'il existe une méthode pour générer une clé privée correspondant à une adresse de contrat spécifique par collision de clé privée, cela nécessiterait environ un an de calcul en utilisant la puissance de calcul totale du réseau Bitcoin.
( 3.4 Comment comprendre le développement de l'abstraction de compte?
Tout d'abord, il est nécessaire de comprendre la valeur après la conversion en CA.
基本ement, c'est aussi l'effet réel de l'EIP-4337, il peut réaliser :
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Cela semble mieux, mais il est pris dans un cercle vicieux de développement du marché, de nombreuses Dapps ne sont pas encore compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et même l'utilisation de CA peut entraîner des coûts de transaction plus élevés dans les scénarios de transfert ordinaires, les frais de transaction doublent, et cela dépend trop de la compatibilité des Dapps elles-mêmes.
Ainsi, l'Ethereum n'a pas encore été largement adopté sur le réseau principal.
Le coût est le critère de mesure le plus important pour les utilisateurs, il est donc nécessaire de réduire les coûts.
Mais pour vraiment réduire le GAS, il faut effectuer une mise à niveau par soft fork d'Ethereum lui-même, modifiant des modules tels que le calcul du GAS ou la consommation de GAS des codes d'opération. Puisque nous devons faire un soft fork, pourquoi ne pas envisager directement l'EIP-7702 ?
![Analyse approfondie de la voie d'abstraction de compte Ethereum : passé et futur])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp###
4. Analyse complète de l'EIP-7702
( 4.1 Qu'est-ce que l'EIP-7702
Il se distingue par un nouveau type de transaction, permettant aux EOA de disposer temporairement de fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des transactions en masse, des transactions sans Gas et une gestion des autorisations personnalisée, sans avoir besoin d'introduire un nouvel opCode EVM ) affectant la compatibilité ascendante (.
Il permet aux utilisateurs d'obtenir la plupart des capacités d'abstraction de compte sans déployer de contrat intelligent, et peut même fournir la capacité d'initier des transactions par des tiers au nom des utilisateurs, sans que ceux-ci aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure de données
Il définit un nouveau type de transaction 0x04, dont le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
Il est important de noter qu'un nouvel objet authorization_list a été ajouté, stockant le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe le code du contrat à exécuter en même temps qu'il signe la transaction, celui-ci existe sous forme de liste en deux dimensions, indiquant qu'il est possible de stocker plusieurs informations d'opération en masse et d'exécuter des opérations en lot.
Au début de l'exécution de la transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] de authorization_list :
Récupérer l'adresse du signataire ( à partir des signatures r et s en utilisant ecrecover. Notez que c'est un mécanisme propre à Ethereum, donc cet EIP n'a pas modifié l'algorithme de signature ).
authority = ecrecover###keccak###MAGIC || rlp([chain_id, address, nonce])(, y_parity, r, s]( est similaire à l'adresse from obtenue par la déchiffration de signature précédemment, ici il s'agit de l'adresse de signature partielle pour cette liste(
Vérifier l'ID de chaîne ) pour la protection contre la répétition de chaînes de fork ).
Vérifiez si le code du signataire authority est vide ou si ( a déjà été délégué.
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.
EIP-7702 : percée majeure dans l'abstraction de compte Ethereum
Analyse approfondie de l'histoire et de l'avenir de l'abstraction de compte sur Ethereum
Introduction
Cet article est divisé en deux grandes sections :
La partie supérieure commence avec la première proposition AA de 2015, le système a organisé le contenu principal des propositions EIP jusqu'à présent, espérant explorer le développement historique des propositions AA à travers une perspective historique et évaluer de manière complète les avantages et les inconvénients de chaque方案.
La deuxième partie se concentre sur la comparaison des réactions froides du marché face à la sortie de l'EIP4337, et analyse en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à jour d'Ethereum. Une fois cette proposition fusionnée, elle changera complètement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, explorons cela en détail 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, où les dispositions concernant l'abstraction de compte restent inchangées. Le modèle dominant évolue actuellement de l'EIP-4337 vers la prochaine étape "conversion volontaire de compte EOA".
Plus d'un an après le lancement de l'EIP4337, le 1er mars 2023 lors du WalletCon à Denver, il a été annoncé officiellement que le contrat de base ERC-4337, conçu et réalisé par les développeurs de la fondation Ethereum, a été audité par OpenZeppelin et est considéré comme un jalon historique de son lancement officiel (. Le marché présente un état contradictoire où les utilisateurs reconnaissent largement mais n'utilisent pas beaucoup. Dans ce contexte, le progrès de l'EIP-7702 a été considérablement avancé et il a été confirmé qu'il sera intégré dans la prochaine mise à niveau.
) 1.2 état du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total de comptes d'EIP4337 sur les chaînes principales n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal Ethereum, ce qui est considérablement inférieur au nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions. On peut dire qu'EIP4337 n'a presque pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur intrinsèque de l'abstraction de compte (AA). La conception de l'EIP4337 était dès le départ vouée à ne pas résoudre le problème grave de compatibilité ascendante du réseau principal. Avec l'intégration généralisée de différentes chaînes L2 dans l'AA native, le nombre d'adresses EIP4337 a explosé sur L2, avec respectivement 1 million et 3 millions d'utilisateurs actifs mensuels sur les chaînes Base et Polygon en juillet, ce qui est plutôt satisfaisant.
Par conséquent, ce n'est pas que la conception de l'EIP4337 soit erronée, elle a de nombreux avantages que nous résumerons systématiquement plus tard. La situation actuelle provient des différences entre la chaîne principale et le L2, elles nécessitent chacune des solutions adaptées.
2. Qu'est-ce que l'abstraction de compte?
L'abstraction de compte résout essentiellement le 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 ) Compte de contrat (. La propriété et le droit de signature du compte externe sont en réalité détenus par la même entité. La personne qui détient la clé privée possède 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. La structure des transactions montre que les transactions standard d'Ethereum n'ont pas de champ From. En réalité, l'adresse From est extraite par la signature de l'utilisateur avec les paramètres VRS ), en inversant la procédure de décodage.
Cela implique des concepts tels que la cryptographie asymétrique comme l'ECDSA et les fonctions de seuil unidirectionnelles, que nous n'explorerons pas ici. En résumé, la sécurité est assurée par la cryptographie, ce qui a également conduit à la difficulté actuelle de la fusion des droits de propriété des adresses EOA.
L'effet principal de l'EIP4337 est d'ajouter l'adresse de l'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 davantage de problèmes :
Difficulté de protection des clés privées : la perte de la clé privée (, les attaques de hackers et les décryptages cryptographiques ) signifient la perte de tous les actifs.
Algorithme de signature unique : la vérification des transactions du protocole natif ne peut utiliser que l'algorithme de signature et de vérification ECDSA.
Autorisation de signature trop élevée : aucune multi-signature native ( la multi-signature ne peut être réalisée que par un contrat intelligent ), 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 supportées.
Fuite de la vie privée des transactions : les transactions de pair à pair facilitent l'analyse des informations privées des détenteurs de comptes.
Ces restrictions rendent l'utilisation d'Ethereum difficile pour les utilisateurs ordinaires :
Tout d'abord, pour utiliser n'importe quelle application sur Ethereum, les utilisateurs doivent détenir de l'Éther ( et assumer le risque de fluctuation des prix ).
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, le prix du Gas, la limite de Gas, le blocage des transactions ( l'ordre du Nonce ) et d'autres concepts qui sont trop complexes pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications blockchain tentent d'améliorer l'expérience utilisateur par l'optimisation des produits, les résultats sont limités.
Ainsi, le point de rupture réside dans la mise en œuvre de l'abstraction de compte, déconnectant la propriété (Owner) et le droit de signature (Signer), afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Dans l'histoire, plusieurs solutions ont été proposées, qui se sont finalement regroupées en deux voies.
3. Contexte historique des propositions d'abstraction de compte
( 3.1 Première option : transformer une adresse EOA en adresse CA
Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte sous forme de contrat dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, changeant le support des frais de transaction pour être payé par ERC20, et grâce à des contrats précompilés, le jeton natif a été transformé en un solde de type ERC20 ) avec des fonctionnalités d'autorisation de prélèvement ###, et les champs de transaction ont été simplifiés en to, startgas, data et code.
Cette proposition peut être considérée comme une transformation de type Grand Bond en avant, modifiant 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 cherche à réaliser ).
Il peut également donner lieu à d'autres fonctionnalités, telles que :
Les transactions utilisent davantage d'algorithmes cryptographiques, qui peuvent être spécifiés par les méthodes de signature et d'authentification internes au Code de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est mis à jour.
Rendre l'Éther compatible avec les caractéristiques fonctionnelles des contrats ERC20, l'effet clé est de réaliser une autorisation de prélèvement, sans consommer de monnaie native.
Améliorer l'espace personnalisé du compte, compatible avec la récupération sociale, le support SBT, la récupération de clé, etc.
La raison pour laquelle nous n'avons pas pu continuer est simple : il est évident que le pas était trop grand, et que nous n'avons pas suffisamment pris en compte les problèmes de conflit de hachage de transaction actuels et les risques de sécurité, c'est pourquoi cela a été mis en attente. Mais chaque concept positif est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702.
Ensuite, 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 de Code, la fonction principale est que si le contrat de la partie transactionnelle n'est pas déployé, alors on utilise le paramètre code joint à la transaction pour exécuter le déploiement du portefeuille de contrat. De plus, un nouvel opcode PAYGAS a été proposé, qui sert non seulement à payer le gas, mais aussi de séparateur entre la partie de validation et la partie d'exécution dans les paramètres de la transaction.
Bien qu'il n'ait pas été mis en œuvre à 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 être accompagnée d'un certain code, permettant ainsi à l'adresse EOA de posséder des capacités de contrat dans cette transaction.
EIP-7702 : définir le code de compte EOA (2024-05-07)
C'est également le cœur du mécanisme de discussion ultérieur de cet article, proposé par Vitalik comme alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné, et l'EIP-7702 est déterminé pour être inclus dans le prochain fork dur ETH Prague/Electra(Pectra), dont nous développerons les détails plus tard.
( 3.2 Deuxième option : laisser l'adresse EOA piloter l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL )2020-10-15###
Ajouter deux nouveaux OpCodes AUTH et AUTHCALL dans l'EVM, 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 un message signé ( transaction ) à un contrat en lequel il a confiance ( appelé Invoker ), ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour remplacer l'EOA dans l'envoi de transactions.
EIP-4337 : mise en œuvre de l'abstraction de compte via le pool de mémoire des transactions (2021-09-29)
Conçu sous l'inspiration de MEV, sa valeur fondamentale est de pouvoir éviter complètement les modifications du protocole de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans la mémoire tampon, et que les bundlers regroupent et livrent en masse pour exécuter les transactions de contrat du point de vue des mineurs, ce qui revient essentiellement à faire exécuter les transactions sous-jacentes et les opérations de compte au niveau du contrat.
EIP-5189 : opération d'abstraction de compte par des endosseurs (2022-06-29)
C'est une optimisation de la logique EIP4337, qui fait face à des Bundlers malveillants en établissant un mécanisme d'entérinement par des amendes sur les fonds pour prévenir les attaques par blocage DoS.
( 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à Final, définissant un nouveau type de transaction, servant d'enveloppe pour les futurs types de transactions à ajouter.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il suffit de différencier les types de transactions par un codage spécifique, en étant uniquement compatible avec les versions antérieures, sans nécessiter de compatibilité avec les versions ultérieures. L'exemple le plus courant est l'EIP1559, qui différencie les frais de transaction, utilise un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : interdiction des adresses EOA de déployer des contrats (2021-06-10)
Ceci est un plan d'appoint sur le chemin AA, destiné à empêcher les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Il contrôlera la méthode de génération de contrat, interdisant au système de déployer du code à une adresse qui est déjà une adresse EOA. Ce risque est en réalité très faible, étant donné que l'adresse Ethereum mesure 160 bits de long. Bien qu'il existe une méthode pour générer une clé privée correspondant à une adresse de contrat spécifique par collision de clé privée, cela nécessiterait environ un an de calcul en utilisant la puissance de calcul totale du réseau Bitcoin.
( 3.4 Comment comprendre le développement de l'abstraction de compte?
Tout d'abord, il est nécessaire de comprendre la valeur après la conversion en CA.
基本ement, c'est aussi l'effet réel de l'EIP-4337, il peut réaliser :
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Cela semble mieux, mais il est pris dans un cercle vicieux de développement du marché, de nombreuses Dapps ne sont pas encore compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et même l'utilisation de CA peut entraîner des coûts de transaction plus élevés dans les scénarios de transfert ordinaires, les frais de transaction doublent, et cela dépend trop de la compatibilité des Dapps elles-mêmes.
Ainsi, l'Ethereum n'a pas encore été largement adopté sur le réseau principal.
Le coût est le critère de mesure le plus important pour les utilisateurs, il est donc nécessaire de réduire les coûts.
Mais pour vraiment réduire le GAS, il faut effectuer une mise à niveau par soft fork d'Ethereum lui-même, modifiant des modules tels que le calcul du GAS ou la consommation de GAS des codes d'opération. Puisque nous devons faire un soft fork, pourquoi ne pas envisager directement l'EIP-7702 ?
![Analyse approfondie de la voie d'abstraction de compte Ethereum : passé et futur])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp###
4. Analyse complète de l'EIP-7702
( 4.1 Qu'est-ce que l'EIP-7702
Il se distingue par un nouveau type de transaction, permettant aux EOA de disposer temporairement de fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des transactions en masse, des transactions sans Gas et une gestion des autorisations personnalisée, sans avoir besoin d'introduire un nouvel opCode EVM ) affectant la compatibilité ascendante (.
Il permet aux utilisateurs d'obtenir la plupart des capacités d'abstraction de compte sans déployer de contrat intelligent, et peut même fournir la capacité d'initier des transactions par des tiers au nom des utilisateurs, sans que ceux-ci aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure de données
Il définit un nouveau type de transaction 0x04, dont le 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 qu'un nouvel objet authorization_list a été ajouté, stockant le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe le code du contrat à exécuter en même temps qu'il signe la transaction, celui-ci existe sous forme de liste en deux dimensions, indiquant qu'il est possible de stocker plusieurs informations d'opération en masse et d'exécuter des opérations en lot.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
) 4.3 cycle de vie des transactions
4.3.1 Phase de vérification
Au début de l'exécution de la transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] de authorization_list :
Récupérer l'adresse du signataire ( à partir des signatures r et s en utilisant ecrecover. Notez que c'est un mécanisme propre à Ethereum, donc cet EIP n'a pas modifié l'algorithme de signature ). authority = ecrecover###keccak###MAGIC || rlp([chain_id, address, nonce])(, y_parity, r, s]( est similaire à l'adresse from obtenue par la déchiffration de signature précédemment, ici il s'agit de l'adresse de signature partielle pour cette liste(
Vérifier l'ID de chaîne ) pour la protection contre la répétition de chaînes de fork ).
Vérifiez si le code du signataire authority est vide ou si ( a déjà été délégué.