Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux grands modules :
La partie supérieure commence avec la première proposition AA de 2015, le système a récapitulé le contenu principal des propositions EIP jusqu'à présent, a passé en revue l'historique des propositions AA et a effectué une évaluation globale des avantages et des inconvénients de chaque solution.
La partie inférieure se concentre sur la comparaison des retours du marché peu satisfaisants rencontrés après le lancement de l'EIP4337, en analysant en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition fusionnée, elle transformera complètement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, examinons cela de plus près.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a de nouveau mis à jour la feuille de route du développement d'ETH à la fin de 2023, mais les paramètres concernant l'abstraction de compte n'ont pas changé. Le modèle principal évolue actuellement d'EIP-4337 vers la conversion VoluntaryEOA( des comptes EOA).
1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total 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 représente un écart énorme avec le nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions, il est donc évident qu'EIP4337 n'a pratiquement pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur essentielle de l'AA. La conception de l'EIP4337 était dès le départ destinée à ne pas résoudre les problèmes de compatibilité avec le réseau principal, mais a été largement adoptée sur diverses chaînes de niveau 2. Parmi elles, les chaînes Base et Polygon ont respectivement atteint 1 million et 3 millions d'utilisateurs actifs en juillet, ce qui est remarquable.
Ainsi, le design de l'EIP4337 n'a pas de problème en soi, la situation actuelle provient des différences entre la chaîne principale et les L2, qui nécessitent d'adopter des solutions appropriées différentes.
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 de l'EOA sont en réalité détenus par le même acteur. La personne qui détient la clé privée possède non seulement la "propriété du compte", mais peut également "signer le transfert de tous les actifs".
Ceci est déterminé par la structure des transactions des comptes Ethereum. Dans la structure de transaction standard, il n'y a en fait pas de champ From, le transfert de fonds est réalisé par la signature de l'utilisateur avec les paramètres VRS (, qui permettent de déduire l'adresse From.
L'effet principal de l'EIP4337 est d'ajouter l'adresse de l'expéditeur dans le champ de la transaction, permettant ainsi la séparation de la clé privée et de l'adresse opérée.
La raison pour laquelle la séparation des droits de propriété est si importante est que la conception de l'EOA entraîne 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 peut utiliser que l'algorithme ECDSA pour vérifier les transactions.
Autorisation de signature trop élevée : pas de multi-signature native, une seule signature suffit pour exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en lot ne sont pas prises en charge.
Fuite de la vie privée des transactions : le trading en tête-à-tête facilite l'analyse des informations des titulaires de compte.
Ces limitations rendent difficile l'utilisation d'Ethereum par les utilisateurs ordinaires :
Tout d'abord, l'utilisation des applications Ethereum nécessite de détenir de l'ETH et d'assumer le risque de fluctuation des prix.
Deuxièmement, l'utilisateur doit traiter des logiques de frais complexes, telles que le prix du Gas, la limite de Gas, et des concepts comme le blocage des transactions.
Enfin, bien que de nombreux portefeuilles de blockchain essaient d'améliorer l'expérience utilisateur par l'optimisation des produits, les résultats sont limités.
Ainsi, la clé réside dans la mise en œuvre de l'abstraction de compte, permettant de découpler la propriété )Owner( et le droit de signature )Signer(, afin de résoudre progressivement les problèmes susmentionnés.
Dans l'histoire, il y a eu plusieurs plans, qui se résument finalement à deux pistes.
![Analyse approfondie de l'abstraction de compte Ethereum : passé et avenir])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
3. Récapitulation des propositions historiques sur l'abstraction de compte
Les solutions aux problèmes semblent nombreuses avec de nombreuses propositions d'EIP, mais au fond, il n'y a que deux idées fondamentales. Chaque question soulevée par une EIP non adoptée a contribué aux points de rupture de la solution actuelle.
) 3.1 Première voie : convertir une adresse EOA en adresse CA
Dès le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte en utilisant des contrats dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, prenant en charge le paiement des frais de transaction en ERC20, et par le biais de contrats précompilés, les jetons natifs ont été convertis en un solde de type ERC20, simplifiant les champs de transaction en to, startgas, data et code.
Ce plan peut donner lieu à plusieurs fonctionnalités :
Les transactions peuvent utiliser davantage d'algorithmes cryptographiques, la méthode de vérification étant spécifiée par le code interne de l'adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est évolutif.
Permettre à l'ETH de disposer des mêmes fonctionnalités que les contrats ERC20, comme l'autorisation de prélèvement.
Amélioration de l'espace de personnalisation du compte, compatible avec la récupération sociale, le support SBT, la récupération de clés, etc.
Les raisons pour lesquelles il n'a pas été possible de poursuivre sont simples : les étapes ont été trop grandes, et les problèmes de collision de hachage des transactions actuelles et les préoccupations concernant la sécurité n'ont pas été suffisamment prises en compte. Cependant, chaque concept avantageux est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702.
Par la suite, une série d'EIP 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, l'essentiel étant que si le contrat de la partie transactionnelle n'est pas déployé, le code fourni avec la transaction sera utilisé pour effectuer le déploiement. Un nouveau code d'opération PAYGAS a également été proposé, servant de séparateur entre la partie de vérification et la partie d'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 peut être accompagnée d'un code intégré à une structure de transaction spéciale, permettant à l'adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code de compte EOA )2024-05-07(
C'est le cœur de la discussion ultérieure de cet article, proposé par Vitalik comme alternative à l'EIP-3074. L'EIP-3074 a été abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra.
) 3.2 Deuxième voie : laisser l'adresse EOA conduire 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 à remplacer l'identité EOA pour appeler d'autres contrats via ces deux opcodes.
Un EOA peut envoyer une transaction de message signé ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour remplacer l'envoi de transactions par l'EOA.
EIP-4337 : implémentation de l'abstraction de compte dans le pool de mémoire des transactions (2021-09-29)
Inspiré par le MEV, la valeur fondamentale est d'éviter complètement les modifications du protocole de couche de consensus.
Proposer un nouvel objet de transaction UserOperation, que les utilisateurs envoient à la mémoire tampon, qui est ensuite regroupé en masse par les bundlers pour exécuter des transactions de contrat du point de vue des mineurs. Essentiellement, cela déplace l'exécution des transactions sous-jacentes et le fonctionnement du compte au niveau du contrat.
EIP-5189 : opération d'abstraction de compte par le biais de l'endosseur (2022-06-29)
Optimiser la logique de l'EIP4337, en établissant un mécanisme d'endossement de pénalités financières pour prévenir les attaques de blocage DoS.
( 3.3 Autres propositions supportant l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction )2020-06-13###
La proposition finalisée définit un nouveau type de transaction comme une enveloppe pour de futurs types de transactions ajoutés.
Lors de l'introduction de nouveaux types de transactions, ils sont différenciés par un codage spécifique, nécessitant une compatibilité rétroactive sans nécessiter une compatibilité proactive. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilisant un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : limiter le déploiement de contrats par des adresses EOA (2021-06-10)
Solutions complémentaires sur le chemin AA pour éviter les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Contrôle des méthodes de génération de contrat, il n'est pas permis de déployer du code à une adresse qui est déjà celle d'un EOA. Ce risque est très faible, l'adresse Ethereum fait 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 même avec toute la puissance de calcul de Bitcoin.
( 3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il est nécessaire de comprendre la valeur de la conversion en CA, qui est essentiellement l'effet réel de l'EIP-4337:
Mais le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Il semble mieux, mais cela entraîne un cercle vicieux dans le développement du marché. De nombreuses Dapp ne sont pas compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et utiliser CA entraîne même des coûts de transaction plus élevés. Une trop grande dépendance à la compatibilité des Dapp elles-mêmes.
Ainsi, cela n'est pas encore répandu sur le réseau principal d'Ethereum.
Le coût est le critère le plus important pour les utilisateurs, il faut réduire les coûts.
Pour vraiment réduire le Gas, il est nécessaire que l'Ethereum lui-même effectue une mise à niveau par soft fork, en modifiant le calcul du Gas ou les modules de consommation de Gas des codes d'opération. Puisqu'il s'agit d'un soft fork, pourquoi ne pas envisager directement l'EIP-7702 ?
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp###
4. Analyse complète de l'EIP-7702
( 4.1 Qu'est-ce que l'EIP-7702
Par la distinction des nouveaux types de transactions, il permet aux EOA de posséder temporairement des fonctionnalités de contrat intelligent dans une seule transaction, soutenant les transactions en masse, les transactions sans Gas et la gestion des permissions personnalisées, sans avoir besoin d'introduire de nouveaux opCode EVM.
Les utilisateurs peuvent obtenir la plupart des capacités AA sans déployer de contrats intelligents, et peuvent même fournir à des tiers la capacité de lancer des transactions au nom des utilisateurs, il leur suffit de signer des informations d'autorisation plutôt que de fournir leur clé privée.
) 4.2 structure de données
Définir un nouveau type de transaction 0x04, TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
Ajout d'un objet authorization_list, stockant le code que le signataire souhaite exécuter dans l'EOA. L'utilisateur signe la transaction tout en signant le code du contrat à exécuter, sous forme de liste à deux dimensions, pouvant contenir plusieurs informations d'opération en vrac.
Au début de la transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] dans l'authorization_list :
Récupérer l'adresse du signataire à partir des signatures r, s en utilisant ecrecover.
Vérifiez l'ID de chaîne ### pour éviter la relecture de chaînes fork ###.
Vérifiez si le code du signataire authority est vide ou déjà délégué.
Vérifier le nonce de l'autorité signataire ( pour prévenir la répétition de la signature de l'autorité ).
Définir le code du signataire authority à 0xef0100 || adresse.
Augmenter le nonce des signataires d'autorité ( pour éviter la répétition de signatures partielles ).
Ajouter le compte signataire d'autorité à la liste des adresses visitées.
(# 4.3.2 Phase d'exécution
La "nouvelle" version ne modifie que le comportement de déploiement du code.
Ne plus définir le code de compte comme contract_code, mais récupérer le code à partir du champ address de authorization_list et le définir comme code de compte.
Lors de l'exécution du code autorisé, chargez le code à partir de l'adresse spécifiée dans authorization_list et exécutez-le dans le contexte du compte signataire.
Le code du contrat utilisateur est réellement stocké à une adresse spécifique sur la chaîne, et n'est pas directement inclus dans la transaction.
Les instructions d'opération et les paramètres associés sont stockés dans le champ de données de la charge utile de la transaction.
) 4.4 La valeur de l'EIP-7702
Des changements ont eu lieu dans le portefeuille Web3 sur toute la chaîne, offrant une transformation majeure de l'expérience utilisateur. Un EOA peut initier des transactions ordinaires avec une logique similaire à celle d'un contrat, comme le transfert en masse. Cela affecte l'identification des transactions dans les scénarios CeFi et les frais de regroupement pour les dépôts et retraits.
Briser plusieurs préjugés établis :
Le solde du compte peut diminuer en raison de transactions qui ne proviennent pas de ce compte.
Après le début de l'exécution de la transaction, le nonce EOA peut augmenter de plusieurs unités.
Briser la logique de protection de la comparaison entre tx.origin et msg.sender, de nombreux contrats existants présentent des risques.
Un EOA peut lui-même émettre des événements, affectant la reconnaissance et l'écoute de certains événements on-chain.
L'adresse EOA peut échouer à recevoir des actifs ERC20, 721, 1155, etc. en raison du mécanisme de rappel ###.
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
) 4.5 Comparaison entre EIP-7702 et EIP-4337
Avantages de l'EIP-7702
Gaz plus bas, pas besoin de passer par le module entrypoint, réduction des opérations sur la chaîne.
Le coût de migration des utilisateurs est plus bas, il n'est pas nécessaire de déployer des contrats sur la chaîne à l'avance.
Par rapport à EIP4337, il y a également une exécution déléguée par code, avec deux méthodes :
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.
13 J'aime
Récompense
13
8
Reposter
Partager
Commentaire
0/400
0xSunnyDay
· 07-24 16:28
C'est juste comme ça, la réaction du marché est plutôt moyenne.
Voir l'originalRépondre0
ContractHunter
· 07-24 08:01
Le vieux V est vraiment têtu, il est encore en train de s'agiter avec AA.
Voir l'originalRépondre0
TommyTeacher1
· 07-21 17:46
C'est encore le vieux problème de ne pas pouvoir trouver l'entrée de l'écosystème.
Voir l'originalRépondre0
SadMoneyMeow
· 07-21 17:46
Wouhou, c'est encore un sujet à fric.
Voir l'originalRépondre0
LazyDevMiner
· 07-21 17:46
AA est encore en train de préparer le terrain, je n'ai jamais eu confiance.
Voir l'originalRépondre0
ForeverBuyingDips
· 07-21 17:43
Encore une nouvelle astuce pour le BTC. Faites-moi savoir si ça fonctionne lors des tests.
Voir l'originalRépondre0
GasFeeWhisperer
· 07-21 17:34
La piste AA est trop longue, que peut vraiment résoudre le 7702 ?
EIP-7702 : la solution ultime pour l'abstraction de compte Ethereum et le développement futur
Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux grands modules :
La partie supérieure commence avec la première proposition AA de 2015, le système a récapitulé le contenu principal des propositions EIP jusqu'à présent, a passé en revue l'historique des propositions AA et a effectué une évaluation globale des avantages et des inconvénients de chaque solution.
La partie inférieure se concentre sur la comparaison des retours du marché peu satisfaisants rencontrés après le lancement de l'EIP4337, en analysant en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition fusionnée, elle transformera complètement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, examinons cela de plus près.
1. Contexte de l'abstraction de compte
1.1 Signification de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a de nouveau mis à jour la feuille de route du développement d'ETH à la fin de 2023, mais les paramètres concernant l'abstraction de compte n'ont pas changé. Le modèle principal évolue actuellement d'EIP-4337 vers la conversion VoluntaryEOA( des comptes EOA).
1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total 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 représente un écart énorme avec le nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions, il est donc évident qu'EIP4337 n'a pratiquement pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur essentielle de l'AA. La conception de l'EIP4337 était dès le départ destinée à ne pas résoudre les problèmes de compatibilité avec le réseau principal, mais a été largement adoptée sur diverses chaînes de niveau 2. Parmi elles, les chaînes Base et Polygon ont respectivement atteint 1 million et 3 millions d'utilisateurs actifs en juillet, ce qui est remarquable.
Ainsi, le design de l'EIP4337 n'a pas de problème en soi, la situation actuelle provient des différences entre la chaîne principale et les L2, qui nécessitent d'adopter des solutions appropriées différentes.
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 de l'EOA sont en réalité détenus par le même acteur. La personne qui détient la clé privée possède non seulement la "propriété du compte", mais peut également "signer le transfert de tous les actifs".
Ceci est déterminé par la structure des transactions des comptes Ethereum. Dans la structure de transaction standard, il n'y a en fait pas de champ From, le transfert de fonds est réalisé par la signature de l'utilisateur avec les paramètres VRS (, qui permettent de déduire l'adresse From.
L'effet principal de l'EIP4337 est d'ajouter l'adresse de l'expéditeur dans le champ de la transaction, permettant ainsi la séparation de la clé privée et de l'adresse opérée.
La raison pour laquelle la séparation des droits de propriété est si importante est que la conception de l'EOA entraîne 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 peut utiliser que l'algorithme ECDSA pour vérifier les transactions.
Autorisation de signature trop élevée : pas de multi-signature native, une seule signature suffit pour exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en lot ne sont pas prises en charge.
Fuite de la vie privée des transactions : le trading en tête-à-tête facilite l'analyse des informations des titulaires de compte.
Ces limitations rendent difficile l'utilisation d'Ethereum par les utilisateurs ordinaires :
Tout d'abord, l'utilisation des applications Ethereum nécessite de détenir de l'ETH et d'assumer le risque de fluctuation des prix.
Deuxièmement, l'utilisateur doit traiter des logiques de frais complexes, telles que le prix du Gas, la limite de Gas, et des concepts comme le blocage des transactions.
Enfin, bien que de nombreux portefeuilles de blockchain essaient d'améliorer l'expérience utilisateur par l'optimisation des produits, les résultats sont limités.
Ainsi, la clé réside dans la mise en œuvre de l'abstraction de compte, permettant de découpler la propriété )Owner( et le droit de signature )Signer(, afin de résoudre progressivement les problèmes susmentionnés.
Dans l'histoire, il y a eu plusieurs plans, qui se résument finalement à deux pistes.
![Analyse approfondie de l'abstraction de compte Ethereum : passé et avenir])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
3. Récapitulation des propositions historiques sur l'abstraction de compte
Les solutions aux problèmes semblent nombreuses avec de nombreuses propositions d'EIP, mais au fond, il n'y a que deux idées fondamentales. Chaque question soulevée par une EIP non adoptée a contribué aux points de rupture de la solution actuelle.
) 3.1 Première voie : convertir une adresse EOA en adresse CA
Dès le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte en utilisant des contrats dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, prenant en charge le paiement des frais de transaction en ERC20, et par le biais de contrats précompilés, les jetons natifs ont été convertis en un solde de type ERC20, simplifiant les champs de transaction en to, startgas, data et code.
Ce plan peut donner lieu à plusieurs fonctionnalités :
Les transactions peuvent utiliser davantage d'algorithmes cryptographiques, la méthode de vérification étant spécifiée par le code interne de l'adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est évolutif.
Permettre à l'ETH de disposer des mêmes fonctionnalités que les contrats ERC20, comme l'autorisation de prélèvement.
Amélioration de l'espace de personnalisation du compte, compatible avec la récupération sociale, le support SBT, la récupération de clés, etc.
Les raisons pour lesquelles il n'a pas été possible de poursuivre sont simples : les étapes ont été trop grandes, et les problèmes de collision de hachage des transactions actuelles et les préoccupations concernant la sécurité n'ont pas été suffisamment prises en compte. Cependant, chaque concept avantageux est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702.
Par la suite, une série d'EIP 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, l'essentiel étant que si le contrat de la partie transactionnelle n'est pas déployé, le code fourni avec la transaction sera utilisé pour effectuer le déploiement. Un nouveau code d'opération PAYGAS a également été proposé, servant de séparateur entre la partie de vérification et la partie d'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 peut être accompagnée d'un code intégré à une structure de transaction spéciale, permettant à l'adresse EOA d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code de compte EOA )2024-05-07(
C'est le cœur de la discussion ultérieure de cet article, proposé par Vitalik comme alternative à l'EIP-3074. L'EIP-3074 a été abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra.
) 3.2 Deuxième voie : laisser l'adresse EOA conduire 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 à remplacer l'identité EOA pour appeler d'autres contrats via ces deux opcodes.
Un EOA peut envoyer une transaction de message signé ) à un contrat de confiance ( appelé Invoker ). Ce contrat Invoker peut utiliser les codes d'opération AUTH et AUTHCALL pour remplacer l'envoi de transactions par l'EOA.
EIP-4337 : implémentation de l'abstraction de compte dans le pool de mémoire des transactions (2021-09-29)
Inspiré par le MEV, la valeur fondamentale est d'éviter complètement les modifications du protocole de couche de consensus.
Proposer un nouvel objet de transaction UserOperation, que les utilisateurs envoient à la mémoire tampon, qui est ensuite regroupé en masse par les bundlers pour exécuter des transactions de contrat du point de vue des mineurs. Essentiellement, cela déplace l'exécution des transactions sous-jacentes et le fonctionnement du compte au niveau du contrat.
EIP-5189 : opération d'abstraction de compte par le biais de l'endosseur (2022-06-29)
Optimiser la logique de l'EIP4337, en établissant un mécanisme d'endossement de pénalités financières pour prévenir les attaques de blocage DoS.
( 3.3 Autres propositions supportant l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction )2020-06-13###
La proposition finalisée définit un nouveau type de transaction comme une enveloppe pour de futurs types de transactions ajoutés.
Lors de l'introduction de nouveaux types de transactions, ils sont différenciés par un codage spécifique, nécessitant une compatibilité rétroactive sans nécessiter une compatibilité proactive. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilisant un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : limiter le déploiement de contrats par des adresses EOA (2021-06-10)
Solutions complémentaires sur le chemin AA pour éviter les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Contrôle des méthodes de génération de contrat, il n'est pas permis de déployer du code à une adresse qui est déjà celle d'un EOA. Ce risque est très faible, l'adresse Ethereum fait 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 même avec toute la puissance de calcul de Bitcoin.
( 3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il est nécessaire de comprendre la valeur de la conversion en CA, qui est essentiellement l'effet réel de l'EIP-4337:
Mais le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Il semble mieux, mais cela entraîne un cercle vicieux dans le développement du marché. De nombreuses Dapp ne sont pas compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et utiliser CA entraîne même des coûts de transaction plus élevés. Une trop grande dépendance à la compatibilité des Dapp elles-mêmes.
Ainsi, cela n'est pas encore répandu sur le réseau principal d'Ethereum.
Le coût est le critère le plus important pour les utilisateurs, il faut réduire les coûts.
Pour vraiment réduire le Gas, il est nécessaire que l'Ethereum lui-même effectue une mise à niveau par soft fork, en modifiant le calcul du Gas ou les modules de consommation de Gas des codes d'opération. Puisqu'il s'agit d'un soft fork, pourquoi ne pas envisager directement l'EIP-7702 ?
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp###
4. Analyse complète de l'EIP-7702
( 4.1 Qu'est-ce que l'EIP-7702
Par la distinction des nouveaux types de transactions, il permet aux EOA de posséder temporairement des fonctionnalités de contrat intelligent dans une seule transaction, soutenant les transactions en masse, les transactions sans Gas et la gestion des permissions personnalisées, sans avoir besoin d'introduire de nouveaux opCode EVM.
Les utilisateurs peuvent obtenir la plupart des capacités AA sans déployer de contrats intelligents, et peuvent même fournir à des tiers la capacité de lancer des transactions au nom des utilisateurs, il leur suffit de signer des informations d'autorisation plutôt que de fournir leur clé privée.
) 4.2 structure de données
Définir un nouveau type de transaction 0x04, TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
rlp###[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s]###
Ajout d'un objet authorization_list, stockant le code que le signataire souhaite exécuter dans l'EOA. L'utilisateur signe la transaction tout en signant le code du contrat à exécuter, sous forme de liste à deux dimensions, pouvant contenir plusieurs informations d'opération en vrac.
authorization_list = [[chain_id, adresse, nonce, y_parity, r, s], ...]
( 4.3 cycle de vie des transactions
)# 4.3.1 phase de validation
Au début de la transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] dans l'authorization_list :
Récupérer l'adresse du signataire à partir des signatures r, s en utilisant ecrecover.
Vérifiez l'ID de chaîne ### pour éviter la relecture de chaînes fork ###.
Vérifiez si le code du signataire authority est vide ou déjà délégué.
Vérifier le nonce de l'autorité signataire ( pour prévenir la répétition de la signature de l'autorité ).
Définir le code du signataire authority à 0xef0100 || adresse.
Augmenter le nonce des signataires d'autorité ( pour éviter la répétition de signatures partielles ).
Ajouter le compte signataire d'autorité à la liste des adresses visitées.
(# 4.3.2 Phase d'exécution
La "nouvelle" version ne modifie que le comportement de déploiement du code.
Ne plus définir le code de compte comme contract_code, mais récupérer le code à partir du champ address de authorization_list et le définir comme code de compte.
Lors de l'exécution du code autorisé, chargez le code à partir de l'adresse spécifiée dans authorization_list et exécutez-le dans le contexte du compte signataire.
Le code du contrat utilisateur est réellement stocké à une adresse spécifique sur la chaîne, et n'est pas directement inclus dans la transaction.
Les instructions d'opération et les paramètres associés sont stockés dans le champ de données de la charge utile de la transaction.
) 4.4 La valeur de l'EIP-7702
Des changements ont eu lieu dans le portefeuille Web3 sur toute la chaîne, offrant une transformation majeure de l'expérience utilisateur. Un EOA peut initier des transactions ordinaires avec une logique similaire à celle d'un contrat, comme le transfert en masse. Cela affecte l'identification des transactions dans les scénarios CeFi et les frais de regroupement pour les dépôts et retraits.
Briser plusieurs préjugés établis :
Le solde du compte peut diminuer en raison de transactions qui ne proviennent pas de ce compte.
Après le début de l'exécution de la transaction, le nonce EOA peut augmenter de plusieurs unités.
Briser la logique de protection de la comparaison entre tx.origin et msg.sender, de nombreux contrats existants présentent des risques.
Un EOA peut lui-même émettre des événements, affectant la reconnaissance et l'écoute de certains événements on-chain.
L'adresse EOA peut échouer à recevoir des actifs ERC20, 721, 1155, etc. en raison du mécanisme de rappel ###.
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
) 4.5 Comparaison entre EIP-7702 et EIP-4337
完全委托(Délégation complète)