Analyse approfondie de l'évolution et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux parties principales :
La première partie commence par la première proposition d'abstraction de compte en 2015, le système passe en revue le contenu principal des propositions EIP jusqu'à présent, examine l'évolution historique des solutions d'abstraction de compte et évalue les avantages et les inconvénients de chaque solution.
La deuxième partie met en évidence le contraste entre la réaction tiède du marché après le lancement de l'EIP4337 et analyse en profondeur l'EIP7702 qui sera inclus dans la prochaine mise à niveau d'Ethereum. Une fois que cette proposition sera fusionnée, elle changera fondamentalement la forme des applications sur la chaîne.
EIP-7702 en tant que révolution historique, examinons en détail son contenu.
1. Contexte de l'abstraction de compte
1.1 localisation de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a de nouveau mis à jour la feuille de route de développement d'ETH à la fin de 2023, mais les paramètres de l'abstraction de compte n'ont pas changé. Le chemin de développement principal actuel est de passer de l'EIP-4337 à la prochaine phase de conversion volontaire d'EOA (Voluntary EOA Conversion).
1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total d'adresses d'EIP4337 sur les chaînes majeures n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal d'Ethereum, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses uniques sur le réseau principal d'Ethereum a atteint 270 millions, il est donc juste de dire qu'EIP4337 n'a presque pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur intrinsèque de l'abstraction de compte. Le but initial du EIP4337 est de résoudre le problème de compatibilité ascendante de la chaîne principale, c'est pourquoi il a connu une croissance explosive sur diverses chaînes L2 qui prennent en charge nativement l'abstraction de compte. Par exemple, le nombre d'utilisateurs actifs mensuels sur les chaînes Base et Polygon a atteint respectivement 1 million et 3 millions en juillet, ce qui est impressionnant.
Ainsi, la conception de l'EIP4337 n'est pas erronée, elle présente de nombreux avantages. La situation actuelle est principalement causée par la différence entre la chaîne principale et le L2, qui nécessitent d'adopter des solutions adaptées.
2. Qu'est-ce que l'abstraction de compte ?
L'abstraction de compte est essentiellement une solution au problème de la séparation des droits de propriété.
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 compte externe, la propriété et le droit de signature sont en réalité détenus par la même entité. La personne possédant la clé privée détient non seulement la "propriété" du compte, mais a également le droit de "signer le transfert de tous les actifs".
Ceci est déterminé par la structure des transactions de compte Ethereum. D'après la structure des transactions, il est en fait évident que la transaction standard d'Ethereum n'a pas de champ From. Alors, comment une transaction de fonds détermine-t-elle l'adresse de dépense ? En réalité, c'est dérivé à l'envers de l'adresse From à travers le paramètre VRS (, c'est-à-dire la signature de l'utilisateur ).
Cela implique des concepts tels que l'ECDSA et les fonctions de seuil unidirectionnelles, qui ne seront pas développés ici. En résumé, ce mécanisme garantit la sécurité par la cryptographie, mais a également conduit à la difficulté actuelle de la fusion des droits de propriété des adresses EOA.
Le rôle central de l'EIP4337 est d'ajouter une adresse d'expéditeur dans le champ de transaction, permettant ainsi la séparation de la clé privée et de l'adresse manipulée.
La raison pour laquelle la séparation des droits de propriété est si importante réside dans le fait que la conception des comptes externes (EOA) engendrera davantage de problèmes :
Difficulté à protéger la clé privée : si l'utilisateur perd la clé privée (, est victime d'une attaque de hacker ou subit une décryptage cryptographique ), cela signifie la perte de tous les actifs.
Algorithme de signature unique : le protocole natif ne peut utiliser que l'algorithme de signature et de vérification ECDSA lors de la validation des transactions.
Autorisation de signature trop élevée : la multi-signature native n'est pas prise en charge ( la multi-signature ne peut être réalisée que par contrat intelligent ), une seule signature suffit pour exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en masse ne sont pas prises en charge.
Fuite de la vie privée des transactions : les transactions de pair à pair peuvent facilement exposer les informations privées des détenteurs de compte.
Ces restrictions rendent l'utilisation d'Ethereum très difficile pour les utilisateurs ordinaires :
Tout d'abord, pour utiliser n'importe quelle application sur Ethereum, les utilisateurs doivent détenir de l'Éther ( et assumer le risque de fluctuation de son prix ).
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, les concepts de prix du gaz, de limite de gaz, de blocage des transactions ( et de séquence de nonce ) sont trop complexes pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications de blockchain tentent d'améliorer l'expérience utilisateur grâce à l'optimisation des produits, les résultats sont limités.
Ainsi, la solution réside dans la mise en œuvre de l'abstraction de compte, déconnectant la propriété (Owner) et le droit de signature (Signer), afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Dans l'histoire, plusieurs solutions ont été proposées, qui se résument finalement à deux grandes voies.
3. Analyse du contexte des propositions d'AA
La solution au problème semble avoir plusieurs propositions d'EIP, mais au fond, il n'y a que deux idées principales. Chaque problème considéré par un EIP non adopté a convergé vers le point de rupture des solutions existantes.
( 3.1 Première option : transformer l'adresse EOA en adresse CA
Dès le 15 novembre 2015, autour de l'EIP-101, Vitalik a proposé une nouvelle structure de compte basée sur des contrats. Les principaux changements comprennent :
Changer l'adresse pour qu'elle ne contienne que du code et de l'espace de stockage
Changement du support des frais, permettant le paiement avec des jetons ERC20
Transformer les jetons natifs en jetons de type ERC20 via des contrats précompilés, avec des fonctionnalités telles que l'autorisation de prélèvement.
Réduire les champs de transaction à to, startgas, data et code
Cette solution peut être considérée comme une réforme révolutionnaire, qui modifiera considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" ) c'est précisément l'effet que le EIP-7702 cherche à réaliser ###.
Il peut également dériver d'autres fonctions, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par le Code interne de chaque adresse pour la méthode de vérification et d'authentification.
Possède des caractéristiques de résistance aux attaques quantiques, car le code peut être mis à jour.
Permettre à l'Éther d'avoir des caractéristiques fonctionnelles identiques à celles des contrats ERC20, l'effet principal étant de réaliser une 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é, etc.
La raison pour laquelle ce plan n'a pas été poursuivi est très simple : les étapes étaient trop ambitieuses. Les problèmes de collision de hash des transactions et les risques de sécurité n'ont pas été suffisamment pris en compte à l'époque, ce qui a conduit à son abandon. Cependant, chaque principe de ses avantages est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702 qui ont suivi.
Ensuite, une série d'EIP a tenté de perfectionner cette logique :
EIP-859 : abstraction de compte de la chaîne principale (2018-01-30)
Essayer de résoudre les problèmes de déploiement de Code. Le rôle principal est le suivant : si le contrat de la partie transactionnelle n'est pas déployé, utilisez le paramètre code joint à la transaction pour exécuter le déploiement du portefeuille de contrat. De plus, un nouvel opcode PAYGAS a été proposé, qui, en plus de payer le gas, devient également un séparateur entre la partie de vérification et la partie d'exécution dans les paramètres de la transaction.
Bien que cela n'ait pas pu être réalisé à l'époque, cela est devenu l'une des logiques centrales de l'EIP7702 actuelle. Chaque transaction de l'EIP7702, associée à une structure de transaction spéciale, peut être accompagnée d'un certain code, permettant ainsi à l'adresse EOA de posséder des capacités de contrat lors de cette transaction.
EIP-7702 : définition du code de compte EOA (2024-05-07)
C'est également le cœur de la discussion ultérieure de cet article, publié par Vitalik, en tant qu'alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné et l'EIP-7702 a été déterminé pour être inclus dans le prochain hard fork ETH Prague/Electra(Pectra), dont le contenu sera détaillé ci-dessous.
( 3.2 Deuxième voie : laisser l'adresse EOA conduire l'adresse CA
EIP-3074 : ajout des opcodes AUTH et AUTHCALL )2020-10-15###
Ajouter deux nouveaux codes d'opération AUTH et AUTHCALL dans l'EVM, permettant aux EOA d'autoriser les 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 opcodes 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 conçue sur la base de l'inspiration du MEV, et sa valeur fondamentale réside dans l'évitement complet des modifications du protocole 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é par les bundlers pour livrer des transactions d'exécution de contrat du point de vue des mineurs, ce qui consiste essentiellement à amener les transactions sous-jacentes et le fonctionnement des comptes à être exécutés au niveau des contrats.
EIP-5189 : opérer des comptes abstraits via des endosseurs )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é financière )endorser( pour prévenir les attaques par blocage DoS malveillantes des Bundler.
) 3.3 Autres propositions pour soutenir l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)
C'est une proposition qui a déjà été finalisée, définissant un nouveau type de transaction, servant d'enveloppe pour les futurs types de transactions ajoutés.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il est possible de distinguer les différentes transactions grâce à un codage spécifique, permettant ainsi une compatibilité descendante sans nécessiter de compatibilité ascendante. 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'affectant pas le type de transaction legacy initial.
EIP-3607 : interdiction de déployer des contrats par des adresses EOA ###2021-06-10(
Ceci est une solution complémentaire sur le chemin AA, utilisée pour prévenir les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Elle va contrôler la méthode de génération de contrat, n'autorisant pas le système à déployer du code sur 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. Bien qu'il existe une méthode pour générer une clé privée correspondant à une adresse de contrat spécifiée par collision de clé privée, il faudrait encore environ une année de temps selon l'estimation de la puissance de calcul totale du réseau 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, il peut réaliser :
Récupération sociale
transaction sans gas
Transactions en lot
Règles basées sur le temps
Multisignature
Paiement basé sur des règles
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Il semble meilleur, mais il est pris dans un cercle vicieux de développement du marché : de nombreuses Dapp ne sont pas encore compatibles, ce qui fait que les utilisateurs hésitent à utiliser les adresses CA. Même l'utilisation de CA peut entraîner des coûts de transaction plus élevés ( dans des scénarios de transfert ordinaires, les frais de transaction peuvent doubler ), et cela dépend trop de la compatibilité de la Dapp elle-même.
Ainsi, il n'a toujours pas été popularisé sur le réseau principal d'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 est nécessaire de procéder à une mise à niveau par hard fork d'Ethereum lui-même, en modifiant le calcul du GAS ou les modules de consommation de GAS des opcodes. Puisqu'il s'agit d'un hard 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-65d1ef9656425666ee30c38bbb63e769.webp(
4. Analyse complète de l'EIP-7702
) 4.1 Qu'est-ce que l'EIP-7702
Il se distingue par de nouveaux types de transactions, permettant aux EOA de disposer temporairement des fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des transactions en lot, des transactions sans Gas et une gestion des autorisations personnalisée, sans avoir besoin d'introduire de nouveaux codes d'opération EVM ( qui affectent la compatibilité ascendante ).
Il permet aux utilisateurs d'acquérir la plupart des capacités d'AA sans déployer de contrat intelligent, et peut même fournir à des tiers la capacité d'initier des transactions au nom des utilisateurs, sans que ces derniers aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
4.2 structure de données
Il définit un nouveau type de transaction 0x04, dont le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
rlp([
chain_id, // ID de chaîne, utilisé pour empêcher les attaques par rejeu
nonce, // compteur de transactions, assure l'unicité de la transaction
max_priority_fee_per_gas, // frais de transaction 1559
max_fee_per_gas, // frais de transaction 1559
gas_limit,
destination, // adresse de destination
valeur,
données,
access_list, // liste d'accès, utilisée pour l'optimisation du Gas dans l'EIP-2929
liste_d'autorisation,
signature_y_parity, // 3 paramètres de signature, utilisés pour vérifier la signature de la transaction
signature_r,
signature_s
])
Il est important que l'objet authorization_list ait été ajouté, stockant le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe le code du contrat à exécuter en même temps qu'il signe la transaction, et cela existe sous forme de liste bidimensionnelle, indiquant la disponibilité.
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.
17 J'aime
Récompense
17
4
Partager
Commentaire
0/400
FancyResearchLab
· 08-04 18:02
Encore une nouvelle astuce soufflée par un théoricien PI, où est le papier d'eau ?
Voir l'originalRépondre0
BrokenDAO
· 08-04 18:01
Encore une expérience répétée sous le prétexte de l'innovation, ne soyez pas trop optimistes... L'EIP-7702 risque fort de suivre le même chemin que le 4337.
Voir l'originalRépondre0
LiquidityHunter
· 08-04 17:58
4337 ? Les données montrent que le taux d'adoption n'est que de 0,02 %... 7702 est le vrai produit.
Voir l'originalRépondre0
rugged_again
· 08-04 17:32
Vitalik Buterin cette fois-ci est vraiment solide, très bien.
Évolution de l'abstraction de compte Ethereum : des réformes révolutionnaires d'EIP-4337 à EIP-7702
Analyse approfondie de l'évolution et de l'avenir de l'abstraction de compte Ethereum
Introduction
Cet article est divisé en deux parties principales :
La première partie commence par la première proposition d'abstraction de compte en 2015, le système passe en revue le contenu principal des propositions EIP jusqu'à présent, examine l'évolution historique des solutions d'abstraction de compte et évalue les avantages et les inconvénients de chaque solution.
La deuxième partie met en évidence le contraste entre la réaction tiède du marché après le lancement de l'EIP4337 et analyse en profondeur l'EIP7702 qui sera inclus dans la prochaine mise à niveau d'Ethereum. Une fois que cette proposition sera fusionnée, elle changera fondamentalement la forme des applications sur la chaîne.
EIP-7702 en tant que révolution historique, examinons en détail son contenu.
1. Contexte de l'abstraction de compte
1.1 localisation de l'abstraction de compte
Le fondateur d'Ethereum, Vitalik, a de nouveau mis à jour la feuille de route de développement d'ETH à la fin de 2023, mais les paramètres de l'abstraction de compte n'ont pas changé. Le chemin de développement principal actuel est de passer de l'EIP-4337 à la prochaine phase de conversion volontaire d'EOA (Voluntary EOA Conversion).
1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total d'adresses d'EIP4337 sur les chaînes majeures n'est que de 12 millions, dont seulement 6 764 adresses actives sur le réseau principal d'Ethereum, ce qui est très éloigné du nombre d'adresses EOA et CA. Le nombre d'adresses uniques sur le réseau principal d'Ethereum a atteint 270 millions, il est donc juste de dire qu'EIP4337 n'a presque pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur intrinsèque de l'abstraction de compte. Le but initial du EIP4337 est de résoudre le problème de compatibilité ascendante de la chaîne principale, c'est pourquoi il a connu une croissance explosive sur diverses chaînes L2 qui prennent en charge nativement l'abstraction de compte. Par exemple, le nombre d'utilisateurs actifs mensuels sur les chaînes Base et Polygon a atteint respectivement 1 million et 3 millions en juillet, ce qui est impressionnant.
Ainsi, la conception de l'EIP4337 n'est pas erronée, elle présente de nombreux avantages. La situation actuelle est principalement causée par la différence entre la chaîne principale et le L2, qui nécessitent d'adopter des solutions adaptées.
2. Qu'est-ce que l'abstraction de compte ?
L'abstraction de compte est essentiellement une solution au problème de la séparation des droits de propriété.
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 compte externe, la propriété et le droit de signature sont en réalité détenus par la même entité. La personne possédant la clé privée détient non seulement la "propriété" du compte, mais a également le droit de "signer le transfert de tous les actifs".
Ceci est déterminé par la structure des transactions de compte Ethereum. D'après la structure des transactions, il est en fait évident que la transaction standard d'Ethereum n'a pas de champ From. Alors, comment une transaction de fonds détermine-t-elle l'adresse de dépense ? En réalité, c'est dérivé à l'envers de l'adresse From à travers le paramètre VRS (, c'est-à-dire la signature de l'utilisateur ).
Cela implique des concepts tels que l'ECDSA et les fonctions de seuil unidirectionnelles, qui ne seront pas développés ici. En résumé, ce mécanisme garantit la sécurité par la cryptographie, mais a également conduit à la difficulté actuelle de la fusion des droits de propriété des adresses EOA.
Le rôle central de l'EIP4337 est d'ajouter une adresse d'expéditeur dans le champ de transaction, permettant ainsi la séparation de la clé privée et de l'adresse manipulée.
La raison pour laquelle la séparation des droits de propriété est si importante réside dans le fait que la conception des comptes externes (EOA) engendrera davantage de problèmes :
Difficulté à protéger la clé privée : si l'utilisateur perd la clé privée (, est victime d'une attaque de hacker ou subit une décryptage cryptographique ), cela signifie la perte de tous les actifs.
Algorithme de signature unique : le protocole natif ne peut utiliser que l'algorithme de signature et de vérification ECDSA lors de la validation des transactions.
Autorisation de signature trop élevée : la multi-signature native n'est pas prise en charge ( la multi-signature ne peut être réalisée que par contrat intelligent ), une seule signature suffit pour exécuter n'importe quelle opération.
Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en masse ne sont pas prises en charge.
Fuite de la vie privée des transactions : les transactions de pair à pair peuvent facilement exposer les informations privées des détenteurs de compte.
Ces restrictions rendent l'utilisation d'Ethereum très difficile pour les utilisateurs ordinaires :
Tout d'abord, pour utiliser n'importe quelle application sur Ethereum, les utilisateurs doivent détenir de l'Éther ( et assumer le risque de fluctuation de son prix ).
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, les concepts de prix du gaz, de limite de gaz, de blocage des transactions ( et de séquence de nonce ) sont trop complexes pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications de blockchain tentent d'améliorer l'expérience utilisateur grâce à l'optimisation des produits, les résultats sont limités.
Ainsi, la solution réside dans la mise en œuvre de l'abstraction de compte, déconnectant la propriété (Owner) et le droit de signature (Signer), afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Dans l'histoire, plusieurs solutions ont été proposées, qui se résument finalement à deux grandes voies.
3. Analyse du contexte des propositions d'AA
La solution au problème semble avoir plusieurs propositions d'EIP, mais au fond, il n'y a que deux idées principales. Chaque problème considéré par un EIP non adopté a convergé vers le point de rupture des solutions existantes.
( 3.1 Première option : transformer l'adresse EOA en adresse CA
Dès le 15 novembre 2015, autour de l'EIP-101, Vitalik a proposé une nouvelle structure de compte basée sur des contrats. Les principaux changements comprennent :
Cette solution peut être considérée comme une réforme révolutionnaire, qui modifiera considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" ) c'est précisément l'effet que le EIP-7702 cherche à réaliser ###.
Il peut également dériver d'autres fonctions, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par le Code interne de chaque adresse pour la méthode de vérification et d'authentification.
Possède des caractéristiques de résistance aux attaques quantiques, car le code peut être mis à jour.
Permettre à l'Éther d'avoir des caractéristiques fonctionnelles identiques à celles des contrats ERC20, l'effet principal étant de réaliser une 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é, etc.
La raison pour laquelle ce plan n'a pas été poursuivi est très simple : les étapes étaient trop ambitieuses. Les problèmes de collision de hash des transactions et les risques de sécurité n'ont pas été suffisamment pris en compte à l'époque, ce qui a conduit à son abandon. Cependant, chaque principe de ses avantages est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702 qui ont suivi.
Ensuite, une série d'EIP a tenté de perfectionner cette logique :
EIP-859 : abstraction de compte de la chaîne principale (2018-01-30)
Essayer de résoudre les problèmes de déploiement de Code. Le rôle principal est le suivant : si le contrat de la partie transactionnelle n'est pas déployé, utilisez le paramètre code joint à la transaction pour exécuter le déploiement du portefeuille de contrat. De plus, un nouvel opcode PAYGAS a été proposé, qui, en plus de payer le gas, devient également un séparateur entre la partie de vérification et la partie d'exécution dans les paramètres de la transaction.
Bien que cela n'ait pas pu être réalisé à l'époque, cela est devenu l'une des logiques centrales de l'EIP7702 actuelle. Chaque transaction de l'EIP7702, associée à une structure de transaction spéciale, peut être accompagnée d'un certain code, permettant ainsi à l'adresse EOA de posséder des capacités de contrat lors de cette transaction.
EIP-7702 : définition du code de compte EOA (2024-05-07)
C'est également le cœur de la discussion ultérieure de cet article, publié par Vitalik, en tant qu'alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné et l'EIP-7702 a été déterminé pour être inclus dans le prochain hard fork ETH Prague/Electra(Pectra), dont le contenu sera détaillé ci-dessous.
( 3.2 Deuxième voie : laisser l'adresse EOA conduire l'adresse CA
EIP-3074 : ajout des opcodes AUTH et AUTHCALL )2020-10-15###
Ajouter deux nouveaux codes d'opération AUTH et AUTHCALL dans l'EVM, permettant aux EOA d'autoriser les 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 opcodes 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 conçue sur la base de l'inspiration du MEV, et sa valeur fondamentale réside dans l'évitement complet des modifications du protocole 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é par les bundlers pour livrer des transactions d'exécution de contrat du point de vue des mineurs, ce qui consiste essentiellement à amener les transactions sous-jacentes et le fonctionnement des comptes à être exécutés au niveau des contrats.
EIP-5189 : opérer des comptes abstraits via des endosseurs )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é financière )endorser( pour prévenir les attaques par blocage DoS malveillantes des Bundler.
) 3.3 Autres propositions pour soutenir l'abstraction de compte
EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)
C'est une proposition qui a déjà été finalisée, définissant un nouveau type de transaction, servant d'enveloppe pour les futurs types de transactions ajoutés.
L'effet final est que, lors de l'introduction d'un nouveau type de transaction, il est possible de distinguer les différentes transactions grâce à un codage spécifique, permettant ainsi une compatibilité descendante sans nécessiter de compatibilité ascendante. 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'affectant pas le type de transaction legacy initial.
EIP-3607 : interdiction de déployer des contrats par des adresses EOA ###2021-06-10(
Ceci est une solution complémentaire sur le chemin AA, utilisée pour prévenir les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Elle va contrôler la méthode de génération de contrat, n'autorisant pas le système à déployer du code sur 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. Bien qu'il existe une méthode pour générer une clé privée correspondant à une adresse de contrat spécifiée par collision de clé privée, il faudrait encore environ une année de temps selon l'estimation de la puissance de calcul totale du réseau 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, il 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 meilleur, mais il est pris dans un cercle vicieux de développement du marché : de nombreuses Dapp ne sont pas encore compatibles, ce qui fait que les utilisateurs hésitent à utiliser les adresses CA. Même l'utilisation de CA peut entraîner des coûts de transaction plus élevés ( dans des scénarios de transfert ordinaires, les frais de transaction peuvent doubler ), et cela dépend trop de la compatibilité de la Dapp elle-même.
Ainsi, il n'a toujours pas été popularisé sur le réseau principal d'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 est nécessaire de procéder à une mise à niveau par hard fork d'Ethereum lui-même, en modifiant le calcul du GAS ou les modules de consommation de GAS des opcodes. Puisqu'il s'agit d'un hard 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-65d1ef9656425666ee30c38bbb63e769.webp(
4. Analyse complète de l'EIP-7702
) 4.1 Qu'est-ce que l'EIP-7702
Il se distingue par de nouveaux types de transactions, permettant aux EOA de disposer temporairement des fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des transactions en lot, des transactions sans Gas et une gestion des autorisations personnalisée, sans avoir besoin d'introduire de nouveaux codes d'opération EVM ( qui affectent la compatibilité ascendante ).
Il permet aux utilisateurs d'acquérir la plupart des capacités d'AA sans déployer de contrat intelligent, et peut même fournir à des tiers la capacité d'initier des transactions au nom des utilisateurs, sans que ces derniers aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
4.2 structure de données
Il définit un nouveau type de transaction 0x04, dont le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
rlp([ chain_id, // ID de chaîne, utilisé pour empêcher les attaques par rejeu nonce, // compteur de transactions, assure l'unicité de la transaction max_priority_fee_per_gas, // frais de transaction 1559 max_fee_per_gas, // frais de transaction 1559 gas_limit, destination, // adresse de destination valeur, données, access_list, // liste d'accès, utilisée pour l'optimisation du Gas dans l'EIP-2929 liste_d'autorisation, signature_y_parity, // 3 paramètres de signature, utilisés pour vérifier la signature de la transaction signature_r, signature_s ])
Il est important que l'objet authorization_list ait été ajouté, stockant le code que le signataire souhaite exécuter dans son EOA. L'utilisateur signe le code du contrat à exécuter en même temps qu'il signe la transaction, et cela existe sous forme de liste bidimensionnelle, indiquant la disponibilité.