Analyse approfondie de l'évolution historique et des perspectives futures de l'abstraction de compte Ethereum
Introduction
Cet article explorera l'évolution de l'abstraction de compte Ethereum (AA) sous deux principaux aspects :
Tout d'abord, nous allons retracer le fil historique depuis la première proposition AA en 2015, organiser systématiquement le contenu principal des différentes propositions EIP jusqu'à présent, explorer en profondeur le processus d'évolution de la proposition AA, et évaluer de manière complète les avantages et les inconvénients de chaque solution.
Ensuite, nous analyserons les raisons pour lesquelles la réaction du marché a été timide après le lancement de l'EIP4337 et nous explorerons en profondeur l'EIP7702 qui sera intégré dans les futures mises à jour d'Ethereum. Une fois cette proposition fusionnée, elle changera fondamentalement la nature des applications sur la chaîne.
EIP-7702 est une révolution sans précédent, explorons ensemble ses mystères.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum a récemment mis à jour la feuille de route du développement de l'ETH, mais les paramètres concernant l'abstraction de compte n'ont pas changé. Le modèle principal actuel passe de l'EIP-4337 à la prochaine étape de "conversion volontaire des comptes EOA".
Bien que le lancement de l'EIP4337 ait eu lieu il y a plus d'un an, la réaction du marché est plutôt contradictoire - les utilisateurs reconnaissent généralement sa valeur, mais le taux d'utilisation réel reste faible. Dans ce contexte, l'avancement de l'EIP-7702 a été considérablement accéléré 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 d'adresses d'EIP4337 sur les chaînes de blocs publiques majeures n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal d'Ethereum, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal d'Ethereum a atteint 270 millions, ce qui montre qu'EIP4337 n'a pratiquement fait aucun progrès substantiel sur le réseau principal.
Cependant, cela ne signifie pas que la valeur fondamentale d'AA est affectée. La conception de l'EIP4337 fait qu'il est difficile de résoudre correctement le problème de compatibilité ascendante du réseau principal. Avec l'intégration généralisée des chaînes L2 dans l'AA natif, le nombre d'adresses de l'EIP4337 a connu une croissance explosive sur L2, avec 1 million et 3 millions d'utilisateurs actifs mensuels respectivement sur les chaînes Base et Polygon en juillet, ce qui est assez considérable.
Ainsi, le problème ne vient pas de la conception de l'EIP4337, mais des différences entre le réseau principal et le L2, qui ont besoin de 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é.
Dans l'architecture de la machine virtuelle Ethereum ( EVM ), il existe deux types de comptes : le compte externe ( EOA ) et le compte de contrat ( Contract Account ). Dans un EOA, la propriété et le droit de signature du compte 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".
Cette caractéristique est déterminée par la structure des transactions de compte Ethereum. Dans la structure de transaction standard d'Ethereum, il n'y a en fait pas de champ From. L'adresse de l'initiateur de la transaction est obtenue par la rétro-analyse des paramètres VRS (, c'est-à-dire la signature de l'utilisateur ).
Bien que ce design garantisse la sécurité grâce à la cryptographie, il a également conduit à la situation actuelle de fusion des droits de propriété des adresses EOA.
L'effet central de l'EIP4337 est d'ajouter une adresse d'expéditeur dans le champ de transaction, permettant ainsi la séparation entre la clé privée et l'adresse manipulée.
La raison pour laquelle la séparation des droits de propriété est si importante réside dans le fait que la conception de l'EOA engendre de nombreux problèmes :
La clé privée est difficile à protéger : perdre la clé privée signifie perdre tous les actifs.
Algorithme de signature unique : le protocole natif ne prend en charge que l'algorithme de signature et de vérification ECDSA.
Autorisation de signature trop élevée : pas de support natif pour les multisignatures, une seule signature peut exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en Éther, les transactions groupées ne sont pas prises en charge.
La confidentialité des transactions est facilement compromise : les transactions en one-to-one facilitent l'analyse des informations des détenteurs de compte.
Ces restrictions rendent difficile l'utilisation d'Ethereum pour les utilisateurs ordinaires :
Tout d'abord, l'utilisateur doit détenir de l'Éther ( et assumer le risque de fluctuation des prix ) pour pouvoir utiliser les applications sur Ethereum.
Ensuite, les utilisateurs doivent gérer une logique de frais complexe, comme le prix du gaz, la limite de gaz, le blocage des transactions (, l'ordre des Nonces ), qui est trop complexe pour eux.
Enfin, bien que de nombreux portefeuilles ou applications blockchain essaient d'améliorer l'expérience utilisateur grâce à une optimisation des produits, les résultats sont limités.
Ainsi, la clé pour surmonter les difficultés réside dans la réalisation de l'abstraction de compte, en découplant la propriété (Owner) et le droit de signature (Signer), afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Au cours de l'histoire, diverses propositions ont été faites, qui se sont finalement regroupées en deux principales voies.
3. Contexte historique des propositions AA
La solution au problème semble avoir plusieurs propositions d'EIP, mais au fond, il n'y a que deux idées centrales. Chaque problème envisagé par un EIP non adopté a finalement convergé vers les points de rupture de la solution actuelle.
3.1 Première ligne: transformer une adresse EOA en adresse CA
Dès novembre 2015, Vitalik a proposé une nouvelle structure de compte en tant que contrat dans l'EIP-101. Cette proposition suggérait de modifier l'adresse pour ne contenir que du code et de l'espace de stockage, prenant en charge le paiement des frais de transaction avec des jetons ERC20, en transformant le jeton natif en un jeton de type ERC20 via un contrat précompilé (, et en simplifiant les champs de transaction pour ne contenir que to, startgas, data et code.
Cette solution peut être qualifiée de révolutionnaire, car elle modifie en grande partie la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" ), ce qui est précisément l'effet que l'EIP-7702 cherche à réaliser (.
Il peut également dériver d'autres fonctionnalités, telles que :
Support des transactions utilisant davantage d'algorithmes cryptographiques, avec des méthodes de vérification et d'authentification spécifiées par le Code interne de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est upgradable.
Donner aux pièces d'Éther et aux contrats ERC20 des caractéristiques fonctionnelles identiques, permettant l'autorisation de prélèvement automatique sans consommer de monnaie native.
Améliorer l'espace personnalisé du compte, prendre en charge la récupération sociale, SBT, récupération de clé, et d'autres fonctionnalités.
La raison pour laquelle ce plan n'a pas pu avancer est simple : les étapes étaient trop grandes, et les problèmes de conflit de hachage des transactions et les risques de sécurité n'ont pas été suffisamment pris en compte, ce qui a conduit à son gel. Cependant, chacun des avantages de ce concept est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702.
Par la suite, une série d'EIP a tenté d'améliorer cette logique :
EIP-859: abstraction de compte de la chaîne principale )2018-01-30(
Cette proposition tente de résoudre le problème du déploiement de code. Son rôle principal est que, lorsque le contrat de la partie transactionnelle n'est pas déployé, le code fourni avec la transaction est utilisé pour exécuter le déploiement du portefeuille de contrat. De plus, un nouveau code d'opération PAYGAS a été proposé, qui, en plus de payer le gaz, sert également de séparateur entre la partie de validation et la partie d'exécution dans les paramètres de la transaction.
Bien que cela n'ait pas pu être réalisé à l'époque, cette idée est devenue l'une des logiques centrales de l'EIP7702 aujourd'hui. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut inclure un certain code, permettant ainsi à une adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702: définition du code de compte EOA )2024-05-07(
C'est le cœur de la discussion ultérieure de cet article, proposé par Vitalik, en tant qu'alternative à l'EIP-3074. Ainsi, l'EIP-3074 est abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra)Pectra(, dont nous détaillerons le contenu dans la suite de l'article.
) 3.2 Deuxième itinéraire : laisser l'adresse EOA conduire l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL ###2020-10-15(
Cette proposition suggère d'ajouter deux nouveaux codes d'opération 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 codes d'opération.
En résumé, un EOA peut envoyer un message signé ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour envoyer des transactions à la place de cet EOA.
EIP-4337 : mise en œuvre de l'abstraction de compte dans le pool de mémoire des transactions (2021-09-29)
Cette proposition est inspirée par le MEV et sa valeur fondamentale réside dans le fait qu'elle évite complètement les modifications du protocole de couche de consensus.
EIP-4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans le pool de mémoire, et que les bundlers regroupent et livrent pour exécuter des transactions de contrat du point de vue des mineurs. Essentiellement, cela élève les transactions sous-jacentes et le fonctionnement des comptes au niveau du contrat.
EIP-5189 : opération d'abstraction de compte par l'entremise d'un parrain (2022-06-29)
Cela peut être considéré comme une optimisation de la logique EIP4337, en établissant un mécanisme d'endossement de pénalités financières pour empêcher les attaques de blocage DoS malveillantes des Bundlers.
( 3.3 Autres propositions soutenant l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction )2020-06-13(
Il s'agit d'une proposition qui a déjà été finalisée, définissant un nouveau type de transaction, servant d'enveloppe pour de futurs types de transactions à ajouter.
L'effet final est que, lors de l'introduction de nouveaux types de transactions, il est possible de distinguer les différents types de transactions par un codage spécifique, ce qui ne nécessite de prendre en compte que la compatibilité arrière, sans avoir besoin de compatibilité avant. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilise un nouveau codage de type de transaction, tout en n'impactant pas le type de transaction legacy initial.
EIP-3607: interdiction de déployer des contrats par des adresses EOA)2021-06-10###
Ceci est un plan complémentaire sur le chemin AA, utilisé pour éviter 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 contrats, 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, compte tenu que l'adresse Ethereum peut atteindre 160 bits. Bien qu'il existe des méthodes utilisant des collisions de clés privées pour générer la clé privée d'une adresse de contrat spécifiée, même en mobilisant toute la puissance de calcul du réseau Bitcoin, cela nécessiterait environ un an.
( 3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il est nécessaire de comprendre la valeur après la conversion en CA.
C'est essentiellement l'effet pratique de l'EIP-4337, qui peut réaliser :
Support de la multi-signature et de la récupération sociale
Prise en charge des transactions en masse
Prise en charge des paiements de frais de gas en utilisant des jetons ERC20
Support des limites de transaction
Support des transactions sans gas ) paiement du gas (
Support de la verrouillage de compte ) basculement entre le portefeuille chaud et froid ###
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 de développement du marché : de nombreuses Dapp 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 le cas de transferts ordinaires, les frais de transaction peuvent doubler ), dépendance excessive à la compatibilité des Dapp elles-mêmes.
C'est pourquoi il n'a pas encore réussi à se généraliser sur le réseau principal d'Ethereum.
Le coût est le critère 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 est nécessaire de passer par une mise à niveau de fork doux d'Ethereum lui-même, en modifiant le calcul du GAS ou la consommation de GAS des opcodes et autres modules. Puisqu'il faut procéder à un fork doux, pourquoi ne pas envisager directement l'EIP-7702?
4. Analyse complète de l'EIP-7702
( 4.1 Introduction à l'EIP-7702
Cette proposition permet, en introduisant un nouveau type de transaction, aux EOA de posséder temporairement les fonctionnalités des contrats intelligents dans une seule transaction, soutenant ainsi des opérations commerciales telles que les transactions en lot, les transactions sans Gas et la gestion des autorisations personnalisées, sans avoir à introduire de nouveaux opCode EVM) affectant la compatibilité ascendante(.
Cela permet aux utilisateurs d'obtenir la plupart des capacités AA sans déployer de contrats intelligents, et même de soutenir des tiers pour initier des transactions au nom de l'utilisateur, sans que celui-ci ait besoin de fournir sa clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure de données
EIP-7702 définit un nouveau type de transaction 0x04, dont le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
L'objet authorization_list nouvellement ajouté stocke le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe la transaction tout en signant également l'exécution.
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.
9 J'aime
Récompense
9
4
Partager
Commentaire
0/400
RektRecovery
· 08-01 17:29
meh... une autre proposition AA qui va probablement se faire détruire comme l'a fait 4337. je le prédis maintenant
Voir l'originalRépondre0
BearMarketNoodler
· 08-01 17:26
La nouvelle proposition est enfin arrivée, le 4337 n'est pas encore bien chaud.
Voir l'originalRépondre0
Degentleman
· 08-01 17:25
Tu as encore fait quelque chose de nouveau ? Laisse-moi voir.
Voir l'originalRépondre0
DancingCandles
· 08-01 17:11
En gros, il a parlé pendant longtemps sans rien dire.
EIP-7702 : Nouvelle percée et développement futur de l'abstraction de compte Ethereum
Analyse approfondie de l'évolution historique et des perspectives futures de l'abstraction de compte Ethereum
Introduction
Cet article explorera l'évolution de l'abstraction de compte Ethereum (AA) sous deux principaux aspects :
Tout d'abord, nous allons retracer le fil historique depuis la première proposition AA en 2015, organiser systématiquement le contenu principal des différentes propositions EIP jusqu'à présent, explorer en profondeur le processus d'évolution de la proposition AA, et évaluer de manière complète les avantages et les inconvénients de chaque solution.
Ensuite, nous analyserons les raisons pour lesquelles la réaction du marché a été timide après le lancement de l'EIP4337 et nous explorerons en profondeur l'EIP7702 qui sera intégré dans les futures mises à jour d'Ethereum. Une fois cette proposition fusionnée, elle changera fondamentalement la nature des applications sur la chaîne.
EIP-7702 est une révolution sans précédent, explorons ensemble ses mystères.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum a récemment mis à jour la feuille de route du développement de l'ETH, mais les paramètres concernant l'abstraction de compte n'ont pas changé. Le modèle principal actuel passe de l'EIP-4337 à la prochaine étape de "conversion volontaire des comptes EOA".
Bien que le lancement de l'EIP4337 ait eu lieu il y a plus d'un an, la réaction du marché est plutôt contradictoire - les utilisateurs reconnaissent généralement sa valeur, mais le taux d'utilisation réel reste faible. Dans ce contexte, l'avancement de l'EIP-7702 a été considérablement accéléré 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 d'adresses d'EIP4337 sur les chaînes de blocs publiques majeures n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal d'Ethereum, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal d'Ethereum a atteint 270 millions, ce qui montre qu'EIP4337 n'a pratiquement fait aucun progrès substantiel sur le réseau principal.
Cependant, cela ne signifie pas que la valeur fondamentale d'AA est affectée. La conception de l'EIP4337 fait qu'il est difficile de résoudre correctement le problème de compatibilité ascendante du réseau principal. Avec l'intégration généralisée des chaînes L2 dans l'AA natif, le nombre d'adresses de l'EIP4337 a connu une croissance explosive sur L2, avec 1 million et 3 millions d'utilisateurs actifs mensuels respectivement sur les chaînes Base et Polygon en juillet, ce qui est assez considérable.
Ainsi, le problème ne vient pas de la conception de l'EIP4337, mais des différences entre le réseau principal et le L2, qui ont besoin de 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é.
Dans l'architecture de la machine virtuelle Ethereum ( EVM ), il existe deux types de comptes : le compte externe ( EOA ) et le compte de contrat ( Contract Account ). Dans un EOA, la propriété et le droit de signature du compte 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".
Cette caractéristique est déterminée par la structure des transactions de compte Ethereum. Dans la structure de transaction standard d'Ethereum, il n'y a en fait pas de champ From. L'adresse de l'initiateur de la transaction est obtenue par la rétro-analyse des paramètres VRS (, c'est-à-dire la signature de l'utilisateur ).
Bien que ce design garantisse la sécurité grâce à la cryptographie, il a également conduit à la situation actuelle de fusion des droits de propriété des adresses EOA.
L'effet central de l'EIP4337 est d'ajouter une adresse d'expéditeur dans le champ de transaction, permettant ainsi la séparation entre la clé privée et l'adresse manipulée.
La raison pour laquelle la séparation des droits de propriété est si importante réside dans le fait que la conception de l'EOA engendre de nombreux problèmes :
La clé privée est difficile à protéger : perdre la clé privée signifie perdre tous les actifs.
Algorithme de signature unique : le protocole natif ne prend en charge que l'algorithme de signature et de vérification ECDSA.
Autorisation de signature trop élevée : pas de support natif pour les multisignatures, une seule signature peut exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en Éther, les transactions groupées ne sont pas prises en charge.
La confidentialité des transactions est facilement compromise : les transactions en one-to-one facilitent l'analyse des informations des détenteurs de compte.
Ces restrictions rendent difficile l'utilisation d'Ethereum pour les utilisateurs ordinaires :
Tout d'abord, l'utilisateur doit détenir de l'Éther ( et assumer le risque de fluctuation des prix ) pour pouvoir utiliser les applications sur Ethereum.
Ensuite, les utilisateurs doivent gérer une logique de frais complexe, comme le prix du gaz, la limite de gaz, le blocage des transactions (, l'ordre des Nonces ), qui est trop complexe pour eux.
Enfin, bien que de nombreux portefeuilles ou applications blockchain essaient d'améliorer l'expérience utilisateur grâce à une optimisation des produits, les résultats sont limités.
Ainsi, la clé pour surmonter les difficultés réside dans la réalisation de l'abstraction de compte, en découplant la propriété (Owner) et le droit de signature (Signer), afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Au cours de l'histoire, diverses propositions ont été faites, qui se sont finalement regroupées en deux principales voies.
3. Contexte historique des propositions AA
La solution au problème semble avoir plusieurs propositions d'EIP, mais au fond, il n'y a que deux idées centrales. Chaque problème envisagé par un EIP non adopté a finalement convergé vers les points de rupture de la solution actuelle.
3.1 Première ligne: transformer une adresse EOA en adresse CA
Dès novembre 2015, Vitalik a proposé une nouvelle structure de compte en tant que contrat dans l'EIP-101. Cette proposition suggérait de modifier l'adresse pour ne contenir que du code et de l'espace de stockage, prenant en charge le paiement des frais de transaction avec des jetons ERC20, en transformant le jeton natif en un jeton de type ERC20 via un contrat précompilé (, et en simplifiant les champs de transaction pour ne contenir que to, startgas, data et code.
Cette solution peut être qualifiée de révolutionnaire, car elle modifie en grande partie la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" ), ce qui est précisément l'effet que l'EIP-7702 cherche à réaliser (.
Il peut également dériver d'autres fonctionnalités, telles que :
Support des transactions utilisant davantage d'algorithmes cryptographiques, avec des méthodes de vérification et d'authentification spécifiées par le Code interne de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est upgradable.
Donner aux pièces d'Éther et aux contrats ERC20 des caractéristiques fonctionnelles identiques, permettant l'autorisation de prélèvement automatique sans consommer de monnaie native.
Améliorer l'espace personnalisé du compte, prendre en charge la récupération sociale, SBT, récupération de clé, et d'autres fonctionnalités.
La raison pour laquelle ce plan n'a pas pu avancer est simple : les étapes étaient trop grandes, et les problèmes de conflit de hachage des transactions et les risques de sécurité n'ont pas été suffisamment pris en compte, ce qui a conduit à son gel. Cependant, chacun des avantages de ce concept est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702.
Par la suite, une série d'EIP a tenté d'améliorer cette logique :
EIP-859: abstraction de compte de la chaîne principale )2018-01-30(
Cette proposition tente de résoudre le problème du déploiement de code. Son rôle principal est que, lorsque le contrat de la partie transactionnelle n'est pas déployé, le code fourni avec la transaction est utilisé pour exécuter le déploiement du portefeuille de contrat. De plus, un nouveau code d'opération PAYGAS a été proposé, qui, en plus de payer le gaz, sert également de séparateur entre la partie de validation et la partie d'exécution dans les paramètres de la transaction.
Bien que cela n'ait pas pu être réalisé à l'époque, cette idée est devenue l'une des logiques centrales de l'EIP7702 aujourd'hui. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut inclure un certain code, permettant ainsi à une adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702: définition du code de compte EOA )2024-05-07(
C'est le cœur de la discussion ultérieure de cet article, proposé par Vitalik, en tant qu'alternative à l'EIP-3074. Ainsi, l'EIP-3074 est abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra)Pectra(, dont nous détaillerons le contenu dans la suite de l'article.
) 3.2 Deuxième itinéraire : laisser l'adresse EOA conduire l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL ###2020-10-15(
Cette proposition suggère d'ajouter deux nouveaux codes d'opération 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 codes d'opération.
En résumé, un EOA peut envoyer un message signé ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour envoyer des transactions à la place de cet EOA.
EIP-4337 : mise en œuvre de l'abstraction de compte dans le pool de mémoire des transactions (2021-09-29)
Cette proposition est inspirée par le MEV et sa valeur fondamentale réside dans le fait qu'elle évite complètement les modifications du protocole de couche de consensus.
EIP-4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans le pool de mémoire, et que les bundlers regroupent et livrent pour exécuter des transactions de contrat du point de vue des mineurs. Essentiellement, cela élève les transactions sous-jacentes et le fonctionnement des comptes au niveau du contrat.
EIP-5189 : opération d'abstraction de compte par l'entremise d'un parrain (2022-06-29)
Cela peut être considéré comme une optimisation de la logique EIP4337, en établissant un mécanisme d'endossement de pénalités financières pour empêcher les attaques de blocage DoS malveillantes des Bundlers.
( 3.3 Autres propositions soutenant l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction )2020-06-13(
Il s'agit d'une proposition qui a déjà été finalisée, définissant un nouveau type de transaction, servant d'enveloppe pour de futurs types de transactions à ajouter.
L'effet final est que, lors de l'introduction de nouveaux types de transactions, il est possible de distinguer les différents types de transactions par un codage spécifique, ce qui ne nécessite de prendre en compte que la compatibilité arrière, sans avoir besoin de compatibilité avant. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilise un nouveau codage de type de transaction, tout en n'impactant pas le type de transaction legacy initial.
EIP-3607: interdiction de déployer des contrats par des adresses EOA)2021-06-10###
Ceci est un plan complémentaire sur le chemin AA, utilisé pour éviter 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 contrats, 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, compte tenu que l'adresse Ethereum peut atteindre 160 bits. Bien qu'il existe des méthodes utilisant des collisions de clés privées pour générer la clé privée d'une adresse de contrat spécifiée, même en mobilisant toute la puissance de calcul du réseau Bitcoin, cela nécessiterait environ un an.
( 3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il est nécessaire de comprendre la valeur après la conversion en CA.
C'est essentiellement l'effet pratique de l'EIP-4337, qui peut réaliser :
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 de développement du marché : de nombreuses Dapp 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 le cas de transferts ordinaires, les frais de transaction peuvent doubler ), dépendance excessive à la compatibilité des Dapp elles-mêmes.
C'est pourquoi il n'a pas encore réussi à se généraliser sur le réseau principal d'Ethereum.
Le coût est le critère 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 est nécessaire de passer par une mise à niveau de fork doux d'Ethereum lui-même, en modifiant le calcul du GAS ou la consommation de GAS des opcodes et autres modules. Puisqu'il faut procéder à un fork doux, pourquoi ne pas envisager directement l'EIP-7702?
4. Analyse complète de l'EIP-7702
( 4.1 Introduction à l'EIP-7702
Cette proposition permet, en introduisant un nouveau type de transaction, aux EOA de posséder temporairement les fonctionnalités des contrats intelligents dans une seule transaction, soutenant ainsi des opérations commerciales telles que les transactions en lot, les transactions sans Gas et la gestion des autorisations personnalisées, sans avoir à introduire de nouveaux opCode EVM) affectant la compatibilité ascendante(.
Cela permet aux utilisateurs d'obtenir la plupart des capacités AA sans déployer de contrats intelligents, et même de soutenir des tiers pour initier des transactions au nom de l'utilisateur, sans que celui-ci ait besoin de fournir sa clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure de données
EIP-7702 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, valeur, données, access_list, liste_d'autorisation, signature_y_parity, signature_r, signature_s ](
L'objet authorization_list nouvellement ajouté stocke le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe la transaction tout en signant également l'exécution.