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 a récapitulé le contenu des principales propositions EIP jusqu'à présent, espérant à travers ce retour historique explorer le développement de la proposition AA et évaluer de manière exhaustive les avantages et les inconvénients de chaque solution.
La seconde moitié se concentre sur la comparaison des réactions de désintéressement du marché face à l'EIP4337 et analyse en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à jour 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, découvrons-le ensemble.
1. Fond 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 de l'abstraction de compte n'ont pas changé. Le modèle dominant passe actuellement de l'EIP-4337 à la prochaine phase de conversion EOA volontaire.
Depuis le lancement de l'EIP4337 il y a plus d'un an, le 1er mars 2023 lors du WalletCon à Denver, le contrat central ERC-4337 conçu par les développeurs de la fondation Ethereum a été audité par OpenZeppelin, et est considéré comme officiellement lancé (, restant dans un état contradictoire largement reconnu par les utilisateurs mais pas largement utilisé. Cet environnement de marché a considérablement accéléré le progrès de l'EIP-7702, qui a même été confirmé pour être intégré dans la prochaine mise à niveau.
) 1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total de comptes EIP4337 sur les chaînes principales n'est que de 12 millions. Parmi eux, il n'y a que 6 764 adresses actives sur le réseau principal Ethereum, ce qui est en grande différence 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 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 d'AA. La conception de l'EIP4337 a déterminé qu'il est difficile de résoudre efficacement les problèmes de compatibilité ascendante sur la chaîne principale. Avec l'intégration native d'AA sur divers L2, le nombre d'adresses EIP4337 a explosé sur L2, avec un nombre actif mensuel de 1 million et 3 millions respectivement pour les chaînes Base et Polygon en juillet, ce qui est prometteur.
Ainsi, ce n'est pas que la conception de l'EIP4337 soit erronée, elle présente de nombreux avantages. La situation actuelle découle des différences entre le réseau principal et le L2, qui nécessitent des solutions adaptées à chacun.
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum]###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 ) Compte de contrat (. La propriété et le droit de signature du compte externe sont en réalité détenus par la même entité. La personne qui détient la clé privée possède non seulement la "propriété du compte", mais a également le droit de "signer le transfert de tous les actifs".
Cela est déterminé par la structure des transactions des comptes Ethereum. On peut voir à partir de la structure des transactions que les transactions standard n'ont en fait pas de champ From. Lors d'un transfert de fonds, le montant exact des fonds consommés d'une adresse spécifique est déterminé par les paramètres VRS ), l'utilisateur signant ( pour déduire l'adresse From.
Cela implique des concepts tels que la cryptographie asymétrique comme l'ECDSA et les fonctions de seuil unidirectionnelles, que nous ne développerons pas. En résumé, la sécurité est garantie par la cryptographie, ce qui a également conduit à la situation actuelle de fusion des droits de propriété des adresses EOA.
L'effet principal de l'EIP4337 est d'ajouter l'adresse de l'expéditeur dans le champ de transaction, permettant ainsi la séparation de la clé privée et de l'adresse opérée.
La raison pour laquelle la séparation des droits de propriété est si importante réside dans le fait que la conception du compte externe )EOA( engendrera davantage de problèmes :
Protection difficile de la clé privée : la perte de la clé privée ), les attaques de hackers ou le décryptage cryptographique ( signifient la perte de tous les actifs.
Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme de signature et de vérification ECDSA.
Autorisation de signature trop grande : pas de multi-signature natif ), la multi-signature ne peut être réalisée que par un contrat intelligent (, 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 groupées 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 fluctuations de prix (.
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, le prix du Gas, la limite de Gas, le blocage des transactions ) et l'ordre des Nonce (, ces concepts étant trop compliqués 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 clé 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.
Historiquement, il existe plusieurs solutions, qui se sont finalement regroupées en deux voies.
![Une 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
La solution au problème semble avoir de nombreuses propositions EIP, mais au fond, il n'y a que deux idées fondamentales. Les problèmes considérés dans chaque EIP non approuvé par le passé ont également convergé vers les points de rupture de la solution actuelle.
) 3.1 Première option : convertir 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 utilisant des contrats. 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 à un contrat précompilé, le jeton natif a été converti en un type d'ERC20 pour stocker le solde ###, pouvant inclure des fonctionnalités d'autorisation de prélèvement, etc. (, le champ de transaction a été simplifié pour ne contenir que to, startgas, data et code.
Aujourd'hui, il semble que cela soit une transformation de type grand bond en avant, qui modifiera considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" ), c'est exactement l'effet que l'EIP-7702 vise à réaliser (.
peut également donner lieu à d'autres fonctionnalités, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par le Code interne de chaque adresse pour les méthodes de vérification et d'authentification.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est évolutif.
Rendre l'Éther compatible avec les caractéristiques fonctionnelles des contrats ERC20, avec pour effet principal l'autorisation de prélèvement, évitant ainsi la perte de jetons natifs.
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 nous n'avons pas pu avancer est simple : il est évident que nous avons fait trop de grands pas, en ne tenant pas suffisamment compte des problèmes de collision de hachage des transactions actuelles et des risques de sécurité, ce qui a conduit à une mise en attente. Cependant, chaque principe de mérite est devenu l'une des fonctions clés des futures EIP4337 et EIP7702.
Ensuite, il y a eu une série d'EIP cherchant à améliorer cette logique :
EIP-859 : abstraction de compte de la chaîne principale -- 30-01-2018
Essayer de résoudre le problème de déploiement de Code, son rôle principal est que si le contrat de la partie transactionnelle n'est pas déployé, alors il utilise le paramètre code joint à la transaction pour exécuter le déploiement du portefeuille de contrat. De plus, un nouveau code d'opération PAYGAS a également é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 transaction.
Bien que cela se soit terminé sans succès à l'époque, cela est devenu l'un des éléments clés de la logique actuelle 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 de posséder des capacités de contrat lors de 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, publié par Vitalik comme alternative à l'EIP-3074 )2024-05-07(. Par conséquent, l'EIP-3074 est abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra)Pectra(, dont nous développerons les détails plus tard.
) 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 OpCodes AUTH et AUTHCALL dans l'EVM, permettant aux EOA d'autoriser des contrats à appeler d'autres contrats au lieu de l'identité EOA via 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 au nom de cet EOA.
EIP-4337 : abstraction de compte réalisée par le pool de mémoire des transactions -- 2021-09-29
Conçu sous l'inspiration de l'MEV, sa valeur fondamentale est de pouvoir éviter complètement les modifications du protocole de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans le pool de mémoire, où les bundlers le regroupent et le livrent pour l'exécution des transactions de contrat du point de vue des mineurs. Essentiellement, cela élève les transactions sous-jacentes et l'exploitation des comptes au niveau des contrats.
EIP-5189 : abstraction de compte par l'opération de l'endosseur --- 2022-06-29
C'est une optimisation de la logique EIP4337, visant à prévenir les attaques par blocage DoS face à des Bundlers malveillants en établissant un mécanisme d'endossement de pénalités financières.
( 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 déjà 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 le distinguer par un codage spécifique, permettant ainsi une compatibilité arrière sans nécessiter de compatibilité avant. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilise un nouveau codage de type de transaction, 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 des contrats et l'adresse EOA. Il contrôlera la méthode de génération de contrats, n'autorisant pas le système à déployer du code à une adresse qui est déjà une adresse EOA. Ce risque est très faible, après tout, l'adresse Ethereum a une longueur de 160 bits, bien qu'il existe une méthode pour générer par collision de clé privée une clé privée d'adresse de contrat spécifiée, mais avec l'investissement total en puissance de calcul de Bitcoin, cela prendrait également environ un an.
) 3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il est nécessaire de comprendre la valeur après avoir été converti en CA.
Basicement, c'est l'effet réel de l'EIP-4337, qui peut réaliser :
Récupération sociale
Transaction sans frais de gas
Transactions en masse
Algorithme de signature personnalisé
Logique de compte personnalisée
Support de verrouillage de compte et de limite
Support des portefeuilles multi-signatures et des contrats intelligents
Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Cela semble mieux, mais cela est tombé dans un cycle vicieux de développement du marché. De nombreuses Dapp ne sont pas encore compatibles, les utilisateurs ne sont donc pas disposés à utiliser des adresses CA, et même utiliser CA entraîne des coûts de transaction plus élevés. Dans les scénarios de transfert ordinaires, les frais de transaction doublent, et cela dépend trop de la compatibilité de la Dapp elle-même.
Donc, jusqu'à présent, il n'a jamais été largement adopté sur le réseau principal Ethereum.
Le coût est le critère le plus important pour les utilisateurs, il faut donc réduire les coûts.
Mais pour réellement réduire le GAS, il est nécessaire que Ethereum lui-même effectue une mise à niveau par soft fork, modifiant le calcul du GAS ou les modules de consommation de GAS des codes d'opération. Cependant, puisque nous devons faire un soft fork, pourquoi ne pas considérer directement l'EIP-7702 ?
![Analyse approfondie de l'abstraction de compte Ethereum : passé et futur]###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
Il distingue par de nouveaux types de transactions, permettant aux EOA de disposer temporairement de fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des transactions en masse, des transactions sans Gas et une gestion des permissions personnalisée, sans avoir besoin d'introduire un nouvel opCode EVM ) qui affecte la compatibilité en avant (.
Il permet aux utilisateurs d'obtenir la plupart des capacités d'abstraction de compte sans déployer de contrats intelligents, et peut même offrir la capacité à des tiers d'initier des transactions au nom des utilisateurs, sans que ceux-ci aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure de données
Il définit un nouveau type de transaction 0x04, dont le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
rlp###[
chain_id, //identifiant de chaîne, utilisé pour prévenir les attaques par répétition
nonce, // compteur de transaction, assurant 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 cible de la transaction
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
](
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.
12 J'aime
Récompense
12
5
Partager
Commentaire
0/400
OnchainHolmes
· 07-24 00:19
Encore une abstraction de compte, le 7702 n'est-il pas délicieux?
Voir l'originalRépondre0
gas_fee_therapist
· 07-23 07:45
La carte gas a bloqué pendant huit ans, enfin arrivée à 7702 ?
Voir l'originalRépondre0
GateUser-afe07a92
· 07-23 07:43
Réveille-toi, 4337 est déjà mort, 7702 est l'avenir.
De l'histoire à l'avenir : EIP-7702 ouvre une nouvelle ère d'abstraction de compte sur Ethereum
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 a récapitulé le contenu des principales propositions EIP jusqu'à présent, espérant à travers ce retour historique explorer le développement de la proposition AA et évaluer de manière exhaustive les avantages et les inconvénients de chaque solution.
La seconde moitié se concentre sur la comparaison des réactions de désintéressement du marché face à l'EIP4337 et analyse en profondeur l'EIP7702 qui sera intégré dans la prochaine mise à jour 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, découvrons-le ensemble.
1. Fond 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 de l'abstraction de compte n'ont pas changé. Le modèle dominant passe actuellement de l'EIP-4337 à la prochaine phase de conversion EOA volontaire.
Depuis le lancement de l'EIP4337 il y a plus d'un an, le 1er mars 2023 lors du WalletCon à Denver, le contrat central ERC-4337 conçu par les développeurs de la fondation Ethereum a été audité par OpenZeppelin, et est considéré comme officiellement lancé (, restant dans un état contradictoire largement reconnu par les utilisateurs mais pas largement utilisé. Cet environnement de marché a considérablement accéléré le progrès de l'EIP-7702, qui a même été confirmé pour être intégré dans la prochaine mise à niveau.
) 1.2 État du marché de l'abstraction de compte
Après un an et demi de développement, le nombre total de comptes EIP4337 sur les chaînes principales n'est que de 12 millions. Parmi eux, il n'y a que 6 764 adresses actives sur le réseau principal Ethereum, ce qui est en grande différence 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 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 d'AA. La conception de l'EIP4337 a déterminé qu'il est difficile de résoudre efficacement les problèmes de compatibilité ascendante sur la chaîne principale. Avec l'intégration native d'AA sur divers L2, le nombre d'adresses EIP4337 a explosé sur L2, avec un nombre actif mensuel de 1 million et 3 millions respectivement pour les chaînes Base et Polygon en juillet, ce qui est prometteur.
Ainsi, ce n'est pas que la conception de l'EIP4337 soit erronée, elle présente de nombreux avantages. La situation actuelle découle des différences entre le réseau principal et le L2, qui nécessitent des solutions adaptées à chacun.
![Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum]###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 ) Compte de contrat (. La propriété et le droit de signature du compte externe sont en réalité détenus par la même entité. La personne qui détient la clé privée possède non seulement la "propriété du compte", mais a également le droit de "signer le transfert de tous les actifs".
Cela est déterminé par la structure des transactions des comptes Ethereum. On peut voir à partir de la structure des transactions que les transactions standard n'ont en fait pas de champ From. Lors d'un transfert de fonds, le montant exact des fonds consommés d'une adresse spécifique est déterminé par les paramètres VRS ), l'utilisateur signant ( pour déduire l'adresse From.
Cela implique des concepts tels que la cryptographie asymétrique comme l'ECDSA et les fonctions de seuil unidirectionnelles, que nous ne développerons pas. En résumé, la sécurité est garantie par la cryptographie, ce qui a également conduit à la situation actuelle de fusion des droits de propriété des adresses EOA.
L'effet principal de l'EIP4337 est d'ajouter l'adresse de l'expéditeur dans le champ de transaction, permettant ainsi la séparation de la clé privée et de l'adresse opérée.
La raison pour laquelle la séparation des droits de propriété est si importante réside dans le fait que la conception du compte externe )EOA( engendrera davantage de problèmes :
Protection difficile de la clé privée : la perte de la clé privée ), les attaques de hackers ou le décryptage cryptographique ( signifient la perte de tous les actifs.
Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme de signature et de vérification ECDSA.
Autorisation de signature trop grande : pas de multi-signature natif ), la multi-signature ne peut être réalisée que par un contrat intelligent (, 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 groupées 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 fluctuations de prix (.
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, le prix du Gas, la limite de Gas, le blocage des transactions ) et l'ordre des Nonce (, ces concepts étant trop compliqués 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 clé 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.
Historiquement, il existe plusieurs solutions, qui se sont finalement regroupées en deux voies.
![Une 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
La solution au problème semble avoir de nombreuses propositions EIP, mais au fond, il n'y a que deux idées fondamentales. Les problèmes considérés dans chaque EIP non approuvé par le passé ont également convergé vers les points de rupture de la solution actuelle.
) 3.1 Première option : convertir 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 utilisant des contrats. 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 à un contrat précompilé, le jeton natif a été converti en un type d'ERC20 pour stocker le solde ###, pouvant inclure des fonctionnalités d'autorisation de prélèvement, etc. (, le champ de transaction a été simplifié pour ne contenir que to, startgas, data et code.
Aujourd'hui, il semble que cela soit une transformation de type grand bond en avant, qui modifiera considérablement la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code" ), c'est exactement l'effet que l'EIP-7702 vise à réaliser (.
peut également donner lieu à d'autres fonctionnalités, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par le Code interne de chaque adresse pour les méthodes de vérification et d'authentification.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est évolutif.
Rendre l'Éther compatible avec les caractéristiques fonctionnelles des contrats ERC20, avec pour effet principal l'autorisation de prélèvement, évitant ainsi la perte de jetons natifs.
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 nous n'avons pas pu avancer est simple : il est évident que nous avons fait trop de grands pas, en ne tenant pas suffisamment compte des problèmes de collision de hachage des transactions actuelles et des risques de sécurité, ce qui a conduit à une mise en attente. Cependant, chaque principe de mérite est devenu l'une des fonctions clés des futures EIP4337 et EIP7702.
Ensuite, il y a eu une série d'EIP cherchant à améliorer cette logique :
EIP-859 : abstraction de compte de la chaîne principale -- 30-01-2018
Essayer de résoudre le problème de déploiement de Code, son rôle principal est que si le contrat de la partie transactionnelle n'est pas déployé, alors il utilise le paramètre code joint à la transaction pour exécuter le déploiement du portefeuille de contrat. De plus, un nouveau code d'opération PAYGAS a également é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 transaction.
Bien que cela se soit terminé sans succès à l'époque, cela est devenu l'un des éléments clés de la logique actuelle 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 de posséder des capacités de contrat lors de 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, publié par Vitalik comme alternative à l'EIP-3074 )2024-05-07(. Par conséquent, l'EIP-3074 est abandonné, et l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra)Pectra(, dont nous développerons les détails plus tard.
) 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 OpCodes AUTH et AUTHCALL dans l'EVM, permettant aux EOA d'autoriser des contrats à appeler d'autres contrats au lieu de l'identité EOA via 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 au nom de cet EOA.
EIP-4337 : abstraction de compte réalisée par le pool de mémoire des transactions -- 2021-09-29
Conçu sous l'inspiration de l'MEV, sa valeur fondamentale est de pouvoir éviter complètement les modifications du protocole de couche de consensus.
EIP4337 propose un nouvel objet de transaction UserOperation, que les utilisateurs envoient dans le pool de mémoire, où les bundlers le regroupent et le livrent pour l'exécution des transactions de contrat du point de vue des mineurs. Essentiellement, cela élève les transactions sous-jacentes et l'exploitation des comptes au niveau des contrats.
EIP-5189 : abstraction de compte par l'opération de l'endosseur --- 2022-06-29
C'est une optimisation de la logique EIP4337, visant à prévenir les attaques par blocage DoS face à des Bundlers malveillants en établissant un mécanisme d'endossement de pénalités financières.
( 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 déjà 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 le distinguer par un codage spécifique, permettant ainsi une compatibilité arrière sans nécessiter de compatibilité avant. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilise un nouveau codage de type de transaction, 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 des contrats et l'adresse EOA. Il contrôlera la méthode de génération de contrats, n'autorisant pas le système à déployer du code à une adresse qui est déjà une adresse EOA. Ce risque est très faible, après tout, l'adresse Ethereum a une longueur de 160 bits, bien qu'il existe une méthode pour générer par collision de clé privée une clé privée d'adresse de contrat spécifiée, mais avec l'investissement total en puissance de calcul de Bitcoin, cela prendrait également environ un an.
) 3.4 Comment comprendre l'évolution de l'abstraction de compte ?
Tout d'abord, il est nécessaire de comprendre la valeur après avoir été converti en CA.
Basicement, 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 semble mieux, mais cela est tombé dans un cycle vicieux de développement du marché. De nombreuses Dapp ne sont pas encore compatibles, les utilisateurs ne sont donc pas disposés à utiliser des adresses CA, et même utiliser CA entraîne des coûts de transaction plus élevés. Dans les scénarios de transfert ordinaires, les frais de transaction doublent, et cela dépend trop de la compatibilité de la Dapp elle-même.
Donc, jusqu'à présent, il n'a jamais été largement adopté sur le réseau principal Ethereum.
Le coût est le critère le plus important pour les utilisateurs, il faut donc réduire les coûts.
Mais pour réellement réduire le GAS, il est nécessaire que Ethereum lui-même effectue une mise à niveau par soft fork, modifiant le calcul du GAS ou les modules de consommation de GAS des codes d'opération. Cependant, puisque nous devons faire un soft fork, pourquoi ne pas considérer directement l'EIP-7702 ?
![Analyse approfondie de l'abstraction de compte Ethereum : passé et futur]###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
Il distingue par de nouveaux types de transactions, permettant aux EOA de disposer temporairement de fonctionnalités de contrat intelligent dans une seule transaction, soutenant ainsi des transactions en masse, des transactions sans Gas et une gestion des permissions personnalisée, sans avoir besoin d'introduire un nouvel opCode EVM ) qui affecte la compatibilité en avant (.
Il permet aux utilisateurs d'obtenir la plupart des capacités d'abstraction de compte sans déployer de contrats intelligents, et peut même offrir la capacité à des tiers d'initier des transactions au nom des utilisateurs, sans que ceux-ci aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure de données
Il définit un nouveau type de transaction 0x04, dont le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
rlp###[ chain_id, //identifiant de chaîne, utilisé pour prévenir les attaques par répétition nonce, // compteur de transaction, assurant 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 cible de la transaction 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 ](
Important