Analyse approfondie de l'histoire et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux grandes parties :
La première partie commence avec la première proposition AA de 2015, le système passe en revue le contenu principal des propositions EIP jusqu'à présent, examine l'évolution des propositions AA dans l'histoire et évalue de manière globale les avantages et les inconvénients de chaque solution.
La deuxième partie se concentre sur la comparaison des retours de marché négatifs rencontrés après le lancement de l'EIP4337, et analyse en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à niveau d'Ethereum. Une fois que cette proposition sera 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.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a mis à jour la feuille de route d'ETH à la fin de 2023, sans changer les paramètres de l'abstraction de compte. Le modèle dominant passe actuellement de l'EIP-4337 à la prochaine étape : conversion volontaire des comptes EOA.
Plus d'un an après le lancement de l'EIP4337, le 1er mars 2023 à Denver, WalletCon a officiellement annoncé (. Ce projet a reçu une large reconnaissance de la part des utilisateurs, mais n'a pas été largement utilisé. Dans cet environnement de marché contradictoire, les progrès de l'EIP-7702 ont été considérablement avancés et il a été confirmé qu'il sera intégré lors de la prochaine mise à niveau.
) 1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, l'EIP4337 compte 12 millions d'adresses sur les chaînes principales. Sur le réseau principal Ethereum, il n'y a que 6 764 adresses actives, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions, ce qui montre qu'il n'y a presque aucun développement substantiel de l'EIP4337 sur le réseau principal.
Cependant, cela n'affecte pas la valeur intrinsèque de l'AA. La conception de l'EIP4337 rend difficile la résolution des problèmes de compatibilité ascendante avec la chaîne principale. Avec l'intégration native de l'AA dans divers L2, 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 assez considérable.
Par conséquent, 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 les L2, qui nécessitent des solutions adaptées à chacune.
![Analyse approfondie de l'abstraction de compte Ethereum : passé et futur]###https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp(
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 ) Contract Account (. La propriété et le droit de signature du compte externe sont détenus par la même entité. La personne détenant 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 de compte Ethereum. On peut voir à partir de la structure de la transaction que les transactions standard d'Ethereum n'ont pas de champ From. Lors du transfert de fonds, l'adresse dont les fonds sont réellement dépensés est dérivée de l'adresse From par les paramètres VRS ) avec la signature de l'utilisateur (.
Cela implique des concepts tels que l'ECDSA et les fonctions de seuil unidirectionnelles, sans entrer dans les détails. En résumé, cela est garanti par la cryptographie, ce qui a également conduit à la situation délicate de la fusion des droits de propriété des adresses EOA.
L'effet central de l'EIP4337 est d'ajouter l'adresse de l'expéditeur dans le champ de transaction, séparant ainsi la clé privée 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é à protéger la clé privée : la perte de la clé privée par l'utilisateur signifie la perte de tous les actifs.
Algorithmes de signature limités : le protocole natif ne peut utiliser que les algorithmes de signature et de vérification ECDSA lors de la validation des transactions.
Autorité de signature élevée : aucune multi-signature native ) la multi-signature ne peut être mise en œuvre que par des contrats intelligents pour la collaboration (, une seule signature peut exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en lot ne sont pas prises en charge.
Fuite de la vie privée des transactions : les transactions en tête-à-tête facilitent l'analyse des informations privées des détenteurs de comptes.
Ces restrictions rendent difficile l'utilisation d'Ethereum 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 Gaz, la limite du Gaz, le blocage des transactions ) l'ordre de Nonce ( et d'autres concepts qui sont trop complexes pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications de blockchain essaient d'améliorer l'expérience utilisateur par l'optimisation des produits, les résultats sont très limités.
Ainsi, la solution 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.
Historiquement, il existe plusieurs solutions qui se sont finalement regroupées en deux voies.
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
3. Contexte historique des propositions AA
Les solutions aux problèmes semblent nombreuses avec de nombreuses propositions EIP, mais au fond, il n'y a que deux approches fondamentales. Les questions soulevées par chaque EIP non approuvé dans le passé se sont rassemblées pour devenir les points de rupture de la solution actuelle.
) 3.1 Première option : transformer l'adresse EOA en adresse CA
Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte basée sur des contrats autour de l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, le support des frais de transaction étant assuré par des paiements en ERC20, et grâce à des contrats précompilés, les jetons natifs ont été transformés en un type d'ERC20 pour conserver le solde ### et permettre des fonctions telles que l'autorisation de prélèvement (, tout en simplifiant les champs de transaction pour ne contenir que to, startgas, data et code.
Il semble maintenant que ce soit une transformation de type Grand Bond en Avant, qui modifie considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique "code" ), ce qui est exactement l'effet que l'EIP-7702 vise à réaliser (.
peut également dériver d'autres fonctionnalités, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par les méthodes de vérification et d'authentification du code interne de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est upgradable.
Rendre l'Ether compatible avec les caractéristiques fonctionnelles des contrats ERC20, l'effet principal étant de permettre l'autorisation de prélèvement sans consommer de la monnaie native.
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 le projet n'a pas pu avancer est simple : il est évident que le rythme était trop rapide, et qu'il y avait une attention insuffisante aux problèmes de conflit de hachage de transaction actuels et aux risques de sécurité, ce qui a conduit à un blocage. Cependant, chaque concept positif est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702.
Plus tard, une série d'EIP a également tenté 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 le déploiement du portefeuille de contrat est effectué en utilisant le paramètre code joint à la transaction. Ensuite, un nouveau code d'opération PAYGAS a également été proposé, qui, en plus de payer le gaz, devient également le séparateur entre la partie vérification et la partie exécution dans les paramètres de la transaction.
Bien que cela se soit terminé sans succès à 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 ainsi à l'adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code du compte EOA )2024-05-07(
C'est également le cœur du mécanisme discuté dans cet article, l'EIP. Vitalik a publié l'EIP-7702 comme alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné, et l'EIP-7702 sera intégré dans le prochain hard fork ETH Prague/Electra)Pectra(, dont nous développerons les détails ci-dessous.
) 3.2 Deuxième itinéraire : laisser l'adresse EOA piloter l'adresse CA
EIP-3074 : ajout des opcodes 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é ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour émettre des transactions en remplacement de cet 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 qu'il peut complètement éviter les modifications des protocoles de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans la mémoire tampon, qui est ensuite regroupé et livré pour exécuter des transactions de contrat par les bundlers du point de vue des mineurs. En essence, cela ramène les transactions de base et l'opération de compte au niveau des contrats.
EIP-5189 : Opération des comptes abstraits via des endosseurs (2022-06-29)
Ceci est une optimisation de la logique EIP4337, qui empêche les attaques de blocage DoS malveillantes des Bundlers en établissant un mécanisme de parrainage de pénalité financière.
( 3.3 Autres propositions pour soutenir 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 les nouveaux types de transactions à venir.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il est distingué par un codage spécifique pour savoir de quel type de transaction il s'agit, ce qui permet une compatibilité uniquement en arrière, sans nécessiter de compatibilité en avant. 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, 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 du contrat, empêchant le 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, après tout, une adresse Ethereum fait 160 bits de long, même s'il existe une méthode pour obtenir la clé privée d'une adresse de contrat spécifiée par collision de clés privées, cela nécessiterait environ un an avec une puissance de calcul totale de Bitcoin.
( 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.
En gros, c'est l'effet réel de l'EIP-4337, qui peut réaliser :
Récupération sociale
Agrégation de signature
Transaction en lot
protection contre les attaques DOS
Paiement des frais de Gas
Gas de paiement ERC20
Contrat précompilé de paiement
Transfert sans Gas
Gestion des droits
Limites de transaction
portefeuille évolutif
environnement d'exécution en bac à sable
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Cela a l'air mieux, mais cela est tombé dans un cercle vicieux de développement du marché : Beaucoup de Dapps ne sont pas encore compatibles, donc les utilisateurs ne veulent pas utiliser d'adresse CA, et même 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 peuvent également doubler ###, ce qui dépend trop de la compatibilité des Dapps eux-mêmes.
Donc, jusqu'à présent, cela n'a jamais été populaire sur le réseau principal Ethereum.
Le coût est le critère d'évaluation 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 que l'Ethereum lui-même effectue une mise à niveau par soft fork, modifiant le calcul du GAS ou la consommation de GAS des opcodes, etc. Puisqu'il s'agit d'un soft fork, pourquoi ne pas envisager directement l'EIP-7702 ?
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 temporairement posséder des fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des opérations telles que le trading en masse, les transactions sans Gas et la gestion des autorisations personnalisées, sans avoir besoin d'introduire de nouveaux opCode EVM ) affectant la compatibilité ascendante ###.
Il permet aux utilisateurs d'obtenir la plupart des capacités AA sans déployer de contrats intelligents, et peut même fournir la capacité à un tiers de lancer des transactions au nom de l'utilisateur, sans que l'utilisateur ait besoin de fournir sa 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 que la transaction, qui existe sous la forme d'une liste à deux dimensions, indiquant qu'il est possible de stocker plusieurs informations d'opération en masse et d'effectuer des opérations en lot.
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.
16 J'aime
Récompense
16
7
Partager
Commentaire
0/400
0xLuckbox
· Il y a 16h
4337 n'est même pas encore réchauffé qu'il faut déjà le changer pour 7702.
Voir l'originalRépondre0
DefiSecurityGuard
· 07-20 13:21
mmm... un modèle de déploiement suspect détecté dans eip4337. des signaux d'alarme sur celui-ci. ce n'est pas pour faire du fud, mais les vecteurs d'attaque sont *préoccupants*
Voir l'originalRépondre0
FastLeaver
· 07-18 23:22
Je file tout de suite, ce eip me donne mal à la tête.
Voir l'originalRépondre0
AirdropChaser
· 07-18 23:19
4337 est plein de pièges, 7702 n'est pas nécessairement meilleur.
Voir l'originalRépondre0
LightningAllInHero
· 07-18 23:18
Eh, j'ai entendu dire que 4337 allait être abandonné ? C'est une information positive !
Voir l'originalRépondre0
GameFiCritic
· 07-18 23:13
AA changer encore et encore, à quoi ça sert ? Les investisseurs détaillants perdent des jetons, ils perdent toujours des jetons.
Voir l'originalRépondre0
ser_we_are_early
· 07-18 23:08
Quand les investisseurs détaillants pourront-ils vraiment comprendre cette chose ?
Histoire du développement de l'abstraction de compte Ethereum : les changements majeurs de EIP4337 à EIP7702
Analyse approfondie de l'histoire et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux grandes parties :
La première partie commence avec la première proposition AA de 2015, le système passe en revue le contenu principal des propositions EIP jusqu'à présent, examine l'évolution des propositions AA dans l'histoire et évalue de manière globale les avantages et les inconvénients de chaque solution.
La deuxième partie se concentre sur la comparaison des retours de marché négatifs rencontrés après le lancement de l'EIP4337, et analyse en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à niveau d'Ethereum. Une fois que cette proposition sera 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.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a mis à jour la feuille de route d'ETH à la fin de 2023, sans changer les paramètres de l'abstraction de compte. Le modèle dominant passe actuellement de l'EIP-4337 à la prochaine étape : conversion volontaire des comptes EOA.
Plus d'un an après le lancement de l'EIP4337, le 1er mars 2023 à Denver, WalletCon a officiellement annoncé (. Ce projet a reçu une large reconnaissance de la part des utilisateurs, mais n'a pas été largement utilisé. Dans cet environnement de marché contradictoire, les progrès de l'EIP-7702 ont été considérablement avancés et il a été confirmé qu'il sera intégré lors de la prochaine mise à niveau.
) 1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, l'EIP4337 compte 12 millions d'adresses sur les chaînes principales. Sur le réseau principal Ethereum, il n'y a que 6 764 adresses actives, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions, ce qui montre qu'il n'y a presque aucun développement substantiel de l'EIP4337 sur le réseau principal.
Cependant, cela n'affecte pas la valeur intrinsèque de l'AA. La conception de l'EIP4337 rend difficile la résolution des problèmes de compatibilité ascendante avec la chaîne principale. Avec l'intégration native de l'AA dans divers L2, 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 assez considérable.
Par conséquent, 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 les L2, qui nécessitent des solutions adaptées à chacune.
![Analyse approfondie de l'abstraction de compte Ethereum : passé et futur]###https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp(
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 ) Contract Account (. La propriété et le droit de signature du compte externe sont détenus par la même entité. La personne détenant 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 de compte Ethereum. On peut voir à partir de la structure de la transaction que les transactions standard d'Ethereum n'ont pas de champ From. Lors du transfert de fonds, l'adresse dont les fonds sont réellement dépensés est dérivée de l'adresse From par les paramètres VRS ) avec la signature de l'utilisateur (.
Cela implique des concepts tels que l'ECDSA et les fonctions de seuil unidirectionnelles, sans entrer dans les détails. En résumé, cela est garanti par la cryptographie, ce qui a également conduit à la situation délicate de la fusion des droits de propriété des adresses EOA.
L'effet central de l'EIP4337 est d'ajouter l'adresse de l'expéditeur dans le champ de transaction, séparant ainsi la clé privée 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é à protéger la clé privée : la perte de la clé privée par l'utilisateur signifie la perte de tous les actifs.
Algorithmes de signature limités : le protocole natif ne peut utiliser que les algorithmes de signature et de vérification ECDSA lors de la validation des transactions.
Autorité de signature élevée : aucune multi-signature native ) la multi-signature ne peut être mise en œuvre que par des contrats intelligents pour la collaboration (, une seule signature peut exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en lot ne sont pas prises en charge.
Fuite de la vie privée des transactions : les transactions en tête-à-tête facilitent l'analyse des informations privées des détenteurs de comptes.
Ces restrictions rendent difficile l'utilisation d'Ethereum 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 Gaz, la limite du Gaz, le blocage des transactions ) l'ordre de Nonce ( et d'autres concepts qui sont trop complexes pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications de blockchain essaient d'améliorer l'expérience utilisateur par l'optimisation des produits, les résultats sont très limités.
Ainsi, la solution 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.
Historiquement, il existe plusieurs solutions qui se sont finalement regroupées en deux voies.
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
3. Contexte historique des propositions AA
Les solutions aux problèmes semblent nombreuses avec de nombreuses propositions EIP, mais au fond, il n'y a que deux approches fondamentales. Les questions soulevées par chaque EIP non approuvé dans le passé se sont rassemblées pour devenir les points de rupture de la solution actuelle.
) 3.1 Première option : transformer l'adresse EOA en adresse CA
Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte basée sur des contrats autour de l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, le support des frais de transaction étant assuré par des paiements en ERC20, et grâce à des contrats précompilés, les jetons natifs ont été transformés en un type d'ERC20 pour conserver le solde ### et permettre des fonctions telles que l'autorisation de prélèvement (, tout en simplifiant les champs de transaction pour ne contenir que to, startgas, data et code.
Il semble maintenant que ce soit une transformation de type Grand Bond en Avant, qui modifie considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique "code" ), ce qui est exactement l'effet que l'EIP-7702 vise à réaliser (.
peut également dériver d'autres fonctionnalités, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par les méthodes de vérification et d'authentification du code interne de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est upgradable.
Rendre l'Ether compatible avec les caractéristiques fonctionnelles des contrats ERC20, l'effet principal étant de permettre l'autorisation de prélèvement sans consommer de la monnaie native.
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 le projet n'a pas pu avancer est simple : il est évident que le rythme était trop rapide, et qu'il y avait une attention insuffisante aux problèmes de conflit de hachage de transaction actuels et aux risques de sécurité, ce qui a conduit à un blocage. Cependant, chaque concept positif est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702.
Plus tard, une série d'EIP a également tenté 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 le déploiement du portefeuille de contrat est effectué en utilisant le paramètre code joint à la transaction. Ensuite, un nouveau code d'opération PAYGAS a également été proposé, qui, en plus de payer le gaz, devient également le séparateur entre la partie vérification et la partie exécution dans les paramètres de la transaction.
Bien que cela se soit terminé sans succès à 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 ainsi à l'adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code du compte EOA )2024-05-07(
C'est également le cœur du mécanisme discuté dans cet article, l'EIP. Vitalik a publié l'EIP-7702 comme alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné, et l'EIP-7702 sera intégré dans le prochain hard fork ETH Prague/Electra)Pectra(, dont nous développerons les détails ci-dessous.
) 3.2 Deuxième itinéraire : laisser l'adresse EOA piloter l'adresse CA
EIP-3074 : ajout des opcodes 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é ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour émettre des transactions en remplacement de cet 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 qu'il peut complètement éviter les modifications des protocoles de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans la mémoire tampon, qui est ensuite regroupé et livré pour exécuter des transactions de contrat par les bundlers du point de vue des mineurs. En essence, cela ramène les transactions de base et l'opération de compte au niveau des contrats.
EIP-5189 : Opération des comptes abstraits via des endosseurs (2022-06-29)
Ceci est une optimisation de la logique EIP4337, qui empêche les attaques de blocage DoS malveillantes des Bundlers en établissant un mécanisme de parrainage de pénalité financière.
( 3.3 Autres propositions pour soutenir 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 les nouveaux types de transactions à venir.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il est distingué par un codage spécifique pour savoir de quel type de transaction il s'agit, ce qui permet une compatibilité uniquement en arrière, sans nécessiter de compatibilité en avant. 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, 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 du contrat, empêchant le 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, après tout, une adresse Ethereum fait 160 bits de long, même s'il existe une méthode pour obtenir la clé privée d'une adresse de contrat spécifiée par collision de clés privées, cela nécessiterait environ un an avec une puissance de calcul totale de Bitcoin.
( 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.
En gros, c'est l'effet réel 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.
Cela a l'air mieux, mais cela est tombé dans un cercle vicieux de développement du marché : Beaucoup de Dapps ne sont pas encore compatibles, donc les utilisateurs ne veulent pas utiliser d'adresse CA, et même 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 peuvent également doubler ###, ce qui dépend trop de la compatibilité des Dapps eux-mêmes.
Donc, jusqu'à présent, cela n'a jamais été populaire sur le réseau principal Ethereum.
Le coût est le critère d'évaluation 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 que l'Ethereum lui-même effectue une mise à niveau par soft fork, modifiant le calcul du GAS ou la consommation de GAS des opcodes, etc. Puisqu'il s'agit d'un soft fork, pourquoi ne pas envisager directement l'EIP-7702 ?
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 temporairement posséder des fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des opérations telles que le trading en masse, les transactions sans Gas et la gestion des autorisations personnalisées, sans avoir besoin d'introduire de nouveaux opCode EVM ) affectant la compatibilité ascendante ###.
Il permet aux utilisateurs d'obtenir la plupart des capacités AA sans déployer de contrats intelligents, et peut même fournir la capacité à un tiers de lancer des transactions au nom de l'utilisateur, sans que l'utilisateur ait besoin de fournir sa 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, valeur, données, liste_d'accès, liste_d'autorisation, 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 que la transaction, qui existe sous la forme d'une liste à deux dimensions, indiquant qu'il est possible de stocker plusieurs informations d'opération en masse et d'effectuer des opérations en lot.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
( 4.3 vie de transaction