Préface

L'article est divisé en deux sections principales :

Dans une première partie, il commencera par la première proposition d’AA de 2015, en organisant systématiquement le contenu principal des propositions de PEI à ce jour. Il vise à explorer l’évolution historique des propositions d’AA et à évaluer de manière exhaustive les forces et les faiblesses de chaque proposition.

Dans la deuxième partie, il se concentrera sur la comparaison des retours du marché suite à l'introduction de l'EIP-4337, puis approfondira l'analyse de l'EIP-7702, qui devrait être inclus dans la prochaine mise à niveau d'Éthereum. Cette proposition, une fois fusionnée, devrait transformer de manière significative la nature des applications on-chain.

EIP-7702 promet des changements révolutionnaires, et nous en discuterons en détail.

1. Contexte de l'abstraction de compte

1.1 La signification de l'abstraction de compte

À la fin de 2023, le fondateur d'Ethereum, Vitalik Buterin, a une fois de plus mis à jour la feuille de route de développement de l'ETH. Cependant, les dispositions relatives à l'Abstraction de Compte sont restées inchangées. Le modèle mainstream actuel continue d'évoluer de l'EIP-4337 à la prochaine phase : Conversion EOA Volontaire (conversion auto-initiée des comptes EOA).

https://x.com/VitalikButerin/status/1741190491578810445

Depuis la publication de l'EIP-4337 il y a plus d'un an (le 1er mars 2023, à WalletCon à Denver, les développeurs de la Fondation Ethereum ont annoncé que les contrats de base de l'ERC-4337 avaient passé l'audit d'OpenZeppelin, marquant ainsi une étape historique pour son lancement officiel), il a reçu une large reconnaissance des utilisateurs mais n'a pas été largement adopté. Cet environnement de marché paradoxal a accéléré le progrès de l'EIP-7702, qui est maintenant confirmé pour être inclus dans la prochaine mise à niveau.

1.2 État actuel du marché de l'abstraction de compte

Sans plus tarder, regardons les données.

Après un an et demi de développement, l'EIP-4337 n'a rassemblé que 12 millions d'adresses sous des comptes de chaîne grand public. Ce qui est particulièrement surprenant, c'est que sur le réseau principal d'Ethereum, il n'y a que 6 764 adresses actives. Bien qu'il puisse y avoir des problèmes avec les dimensions statistiques, ce nombre est encore très différent des comptages d'adresses pour les EOAs et les CAs. Pour information, le nombre d'adresses uniques sur le réseau principal d'Ethereum a atteint 270 millions (source: https://etherscan.io/chart/address).

On peut dire que l'EIP-4337 n'a pas fait de progrès substantiels sur le mainnet.

(Source du graphique: https://dune.com/niftytable/account-abstraction)

Cependant, cela ne diminue en rien la valeur intrinsèque de l'Abstraction de compte (AA). Dès le départ, la conception de l'EIP-4337 était destinée à rencontrer des problèmes importants de compatibilité ascendante sur le mainnet. Par conséquent, avec diverses chaînes de couche 2 intégrant l'AA native, l'EIP-4337 a connu une croissance substantielle du nombre d'adresses en couche 2. Par exemple, en juillet, le nombre d'utilisateurs actifs sur les chaînes Base et Polygon a atteint respectivement 1 million et 3 millions, ce qui est assez impressionnant.

Par conséquent, ce n'est pas que la conception de l'EIP-4337 est défectueuse; elle présente de nombreux avantages que nous résumerons de manière systématique. La situation actuelle découle des différences entre le mainnet et la couche 2, nécessitant chacun des solutions sur mesure.

2. Qu'est-ce que l'Abstraction de Compte?

L'Abstraction de compte peut sembler complexe, mais elle traite essentiellement du problème de la séparation de la propriété.

Dans l'architecture de la machine virtuelle Ethereum (EVM), il existe deux types de comptes : les comptes détenus par des entités externes (EOA) et les comptes de contrat. Dans les EOA, la propriété et l'autorité de signature sont détenues par la même entité. La personne ayant la clé privée possède non seulement le compte, mais a également le droit de signer et de transférer tous ses actifs.

Cette configuration est déterminée par la structure de transaction de compte d'Ethereum. Dans une transaction standard d'Ethereum, il n'y a pas d'adresse "De" directe visible. Lorsqu'un transfert de fonds se produit, l'adresse réelle à partir de laquelle les fonds sont dépensés est déduite à travers les paramètres VRS (c'est-à-dire, la signature de l'utilisateur).

Cela implique des concepts tels que le chiffrement asymétrique ECDSA et les fonctions seuils uniques, mais nous n'entrerons pas dans les détails ici. Fondamentalement, la cryptographie garantit la sécurité, ce qui conduit à la situation actuelle où la propriété et l'autorité de signature sont combinées dans les EOAs.

L'effet principal de l'EIP-4337 est d'ajouter un champ d'adresse d'expéditeur à la transaction, permettant de séparer la clé privée et l'adresse exploitée.

Alors pourquoi est-il si important de séparer la propriété ?

Parce que la conception des comptes externes possédés (EOAs) entraîne plusieurs problèmes :

Protection de la clé privée : Perdre la clé privée (en raison d'une perte, d'un piratage ou d'une compromission cryptographique) signifie perdre tous les actifs.

Algorithmes de signature limités**: Le protocole natif ne prend en charge que l'ECDSA pour la signature et la vérification.

Haute autorité de signature : Sans prise en charge native de la multi-signature (qui ne peut être réalisée que par le biais de contrats intelligents), une seule signature peut exécuter n'importe quelle opération.

Frais de transaction : Les frais ne peuvent être payés qu'en Éther, ce qui ne prend pas en charge un volume élevé de transactions.

Confidentialité des transactions : Les transactions de personne à personne facilitent l'analyse des informations privées du titulaire du compte.

Ces contraintes rendent difficile l'utilisation d'Ethereum pour les utilisateurs moyens :

Pour utiliser n'importe quelle application sur Ethereum, les utilisateurs doivent détenir de l'ETH (et supporter le risque des fluctuations de prix de l'ETH).

Les utilisateurs doivent faire face à une logique de frais complexe, telle que le prix du gaz, la limite de gaz et le blocage des transactions (ordre de hachage), qui peut être trop compliquée.

Bien que de nombreux portefeuilles ou applications blockchain tentent d'améliorer l'expérience utilisateur grâce à l'optimisation du produit, leur efficacité a été limitée.

La solution réside dans la mise en œuvre de l'Abstraction de Compte, qui découple la propriété (Propriétaire) et l'autorité de signature (Signataire) pour résoudre ces problèmes. Historiquement, de nombreuses solutions ont émergé, convergent finalement vers deux approches principales.

3. Aperçu historique des propositions d'abstraction de compte

Bien qu'il puisse sembler qu'il y ait de nombreuses propositions d'EIP abordant le problème, fondamentalement, il n'y a que deux approches principales. Les problèmes considérés dans les propositions passées qui n'ont pas été approuvées ont finalement convergé vers les solutions actuelles.

3.1 Le premier itinéraire consiste à transformer l'adresse EOA en une adresse CA

Le 15 novembre 2015, Vitalik Buterin a proposé une nouvelle structure de compte autour de l'EIP-101, qui impliquait l'utilisation de contrats en tant que comptes. Cela transformerait les adresses en entités avec uniquement du code et de l'espace de stockage, modifierait le support des frais pour être payé via des jetons ERC20, et utiliserait des contrats précompilés pour convertir des jetons natifs en jetons similaires aux ERC20 pour le stockage des soldes (avec des fonctionnalités telles que l'autorisation déléguée). Les champs de transaction ont été simplifiés pour inclure uniquement to, startgas, data et code)

Avec le recul, il s'agissait d'un changement révolutionnaire qui modifierait radicalement la conception sous-jacente, donnant à chaque adresse de compte sa propre logique de « code », ce que l'EIP-7702 vise essentiellement à réaliser aujourd'hui. Cette approche pourrait également permettre des fonctionnalités supplémentaires, telles que :

Autoriser les transactions à utiliser davantage d'algorithmes cryptographiques spécifiés par le code interne de chaque adresse pour la vérification et l'authentification.

Fournir une résistance quantique en raison de la nature évolutif du code.

Doter Éther des mêmes caractéristiques fonctionnelles que les contrats ERC20, avec des fonctionnalités telles que l'autorisation déléguée, éliminant ainsi le besoin de dépenser des pièces natives.

Amélioration de la personnalisation du compte, prise en charge de la récupération sociale, SBT (jetons liés à l'âme) et récupération de clé.

La raison pour ne pas faire avancer cette proposition était simple : les étapes étaient trop ambitieuses. Des problèmes tels que les collisions de hachage de transaction et les préoccupations de sécurité n'ont pas été entièrement résolus, ce qui a entraîné son report. Cependant, bon nombre de ses avantages sont devenus des fonctionnalités de base dans les EIP suivants, y compris l'EIP-4337 et l'EIP-7702.

Plusieurs EIP ont ensuite tenté de raffiner cette logique :

EIP-859: Account Abstraction sur Mainnet (30 janvier 2018) visait à résoudre les problèmes de déploiement de code. Sa fonction principale était d'utiliser le codeparamètre attaché aux transactions pour déployer des portefeuilles de contrat si le contrat n'a pas été déployé. Il a également introduit un nouvel opcode PAYGAS pour séparer les parties de vérification et d'exécution d'une transaction.

Bien que cela n'ait pas progressé à l'époque, cette logique est devenue un composant essentiel de l'EIP-7702, qui permet aux adresses EOA d'avoir des capacités de contrat grâce à des structures de transaction spéciales pouvant inclure du code.

EIP-7702: Définition du code du compte EOA (7 mai 2024) est la clé EIP discutée ici. Vitalik a proposé l'EIP-7702 comme une alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonnée et l'EIP-7702 est destinée à être incluse dans la prochaine fourchette dure ETH Prague/Electra (Pectra). D'autres détails seront discutés ci-dessous.

3.2 La deuxième approche consiste à laisser les adresses EOA piloter les adresses CA.

EIP-3074: Ajout des opcodes AUTH et AUTHCALL (15 octobre 2020)

Cet EIP introduit deux nouveaux opcodes, AUTH et AUTHCALL, dans l'EVM, permettant aux EOAs d'autoriser les contrats à remplacer leur identité et à appeler d'autres contrats. En essence, un EOA peut envoyer un message signé (transaction) à un contrat de confiance (appelé un Invoker). Le contrat Invoker peut ensuite utiliser les opcodes AUTH et AUTHCALL pour envoyer la transaction au nom de l'EOA.

EIP-4337: Mise en œuvre de l'abstraction de compte via les pools de transactions (29 septembre 2021)

Inspiré par le MEV, la valeur fondamentale de cet EIP est qu'il évite les modifications du protocole de la couche de consensus. L'EIP-4337 introduit un nouvel objet de transaction, UserOperation, que les utilisateurs soumettent à un pool de mémoire. Les Bundlers regroupent ensuite et livrent ces transactions à l'exécution de contrat, déplaçant efficacement les opérations de transaction et de compte de niveau inférieur vers la couche de contrat.

EIP-5189: Opérations de compte abstraites via les endosseurs (29 juin 2022)

Cet EIP optimise l'EIP-4337 en traitant les problèmes potentiels liés aux regroupeurs malveillants. Il introduit un mécanisme de fonds soutenus par les endosseurs pour prévenir les attaques par déni de service en pénalisant les mauvais acteurs.

3.3 Autres propositions soutenant l'abstraction de compte

EIP-2718: Nouvel Enveloppe de Type de Transaction (13 juin 2020)

Cette proposition finalisée définit un nouveau type de transaction comme une enveloppe pour les futurs types de transaction. Elle garantit que lorsque de nouveaux types de transaction sont introduits, ils peuvent être distingués par un encodage spécifique, tout en maintenant la compatibilité ascendante sans affecter les types hérités. Un exemple courant est l'EIP-1559, qui a différencié les frais de transaction avec un nouvel encodage de type de transaction tout en préservant les types hérités.

EIP-3607: Empêcher les adresses EOA de déployer des contrats (10 juin 2021)

Cette proposition supplémentaire aborde le problème des adresses de déploiement de contrat en conflit avec les adresses EOA. Elle contrôle les méthodes de création de contrat, empêchant le déploiement de code aux adresses déjà utilisées par les EOAs. Le risque est minime compte tenu de la longueur de 160 bits des adresses Ethereum, bien que théoriquement possible grâce aux collisions de clés, cela nécessiterait des efforts de calcul significatifs.

3.4 Comprendre le développement de l'abstraction de compte

Pour comprendre la valeur de la transition vers les adresses CA, il est essentiel de saisir les effets pratiques de l'EIP-4337, qui peut atteindre…

Cependant, l'inconvénient principal de l'EIP-4337 est qu'il viole le principe des incitations humaines. Bien qu'il semble offrir des améliorations, il tombe dans une impasse de développement du marché. De nombreuses Dapps ne sont toujours pas compatibles avec lui, ce qui rend les utilisateurs réticents à utiliser les adresses CA. De plus, l'utilisation des CA peut entraîner des coûts de transaction plus élevés (par exemple, les frais de transaction peuvent doubler dans des scénarios de transfert ordinaires), ce qui le rend fortement dépendant de la compatibilité des Dapps.

Par conséquent, il n'est pas encore largement répandu sur le réseau principal d'Ethereum à ce jour. Le coût est le facteur le plus crucial pour les utilisateurs, et il doit être réduit. Pour vraiment réduire les coûts en GAS, Ethereum lui-même aurait besoin d'une mise à niveau de fork souple pour modifier les calculs en GAS ou changer la consommation de GAS des opcodes. Étant donné le besoin d'un fork souple, pourquoi ne pas envisager directement l'EIP-7702?

4. Analyse complète de l'EIP-7702

4.1 Qu'est-ce que l'EIP-7702

Il se distingue par de nouveaux types de transactions, ce qui permet à EOA d'avoir temporairement la fonction d'un contrat intelligent dans une seule transaction, prenant ainsi en charge les transactions groupées, les transactions sans gaz et la gestion des autorisations personnalisées dans les affaires, sans avoir besoin d'introduire un nouvel opCode EVM (affectant la compatibilité ascendante).

Il permet aux utilisateurs d'obtenir la plupart des capacités d'AA sans déployer de contrats intelligents, et peut même fournir à un tiers la possibilité d'initier des transactions au nom des utilisateurs. Il n'est pas nécessaire que les utilisateurs fournissent les clés privées, mais seulement qu'ils signent les informations autorisées.

4.2 Structure de données

Il a défini un nouveau type de transaction 0x04. Le TransactionPayload de ce type de transaction est le résultat de la sérialisation de codage RLP du contenu suivant

rlp([

chain_id, //Identifiant de chaîne, utilisé pour prévenir les attaques de rejeu.

nonce, // Compteur de transaction pour garantir l'unicité de la transaction.

max_priority_fee_per_gas, //frais de transaction 1559

max_fee_per_gas, //frais de transaction 1559

limite_de_gaz,

destination, //Adresse cible de la transaction

valeur,

données,

access_list, //Liste d'accès, utilisée pour l'optimisation du gaz dans l'EIP-2929.

liste d'autorisations,

signature_y_parity, // 3 paramètres de signature, utilisés pour vérifier la signature de la transaction.

signature_r,

signature_s

])

L'important est que l'objet authorization_list soit ajouté pour stocker le code que le signataire souhaite exécuter dans son EOA. Lorsque l'utilisateur signe la transaction, il signe également le code du contrat à exécuter. Il existe sous forme de liste bidimensionnelle, indiquant que plusieurs informations d'opération peuvent être stockées par lots, effectuer des opérations par lots.

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

4.3 Cycle de vie de la transaction

Phase de vérification 4.3.1

Au début de la phase d'exécution de la transaction, pour chaque [chain_id, address, nonce, y_parity, r, s]tuple dans leliste d'autorisation:

Utilisez le ecrecoverfonction pour récupérer l'adresse de l'expéditeur à partir de la signature(r, s)Notez que cela utilise le mécanisme existant d'Ethereum, de sorte que l'algorithme de signature reste inchangé par cet EIP. L'adresse est récupérée en utilisant :autorité = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s). C'est similaire à la façon dont le de L’adresse est dérivée des signatures, mais elle s’applique à la signature de liste spécifique.

Vérifiez l'identifiant de chaîne pour éviter les attaques de rejeu sur différentes chaînes.

Vérifiez si le autoritéLe code du signataire est soit vide, soit délégué (pour confirmer si la transaction est une transaction valide EIP-7702, avec des mécanismes de délégation gérant l'exécution).

Vérifiez le autoriténonce du signataire pour prévenir les attaques de rejeu sur les signatures.

Définir le autoritéle code du signataire à 0xef0100 || adresse(pour contourner les stratégies de prévention des collisions EIP-3607).

Incrémenter le autoriténonce du signataire (pour éviter la relecture locale de la signature).

Ajouter le autoritéau compte du signataire à la liste d'accès (pour passer au stockage à chaud, réduisant les coûts de gaz pour l'accès).

4.3.2 Phase d'exécution

Où le code du contrat et les instructions opérationnelles sont-ils exécutés?

La version “nouvelle” modifie la manière dont le code du contrat est déployé. Au lieu de définir directement le code du compte, il récupère le code à partir du liste d'autorisationadresse et la définit comme le code du compte.

Lors de l'exécution du code autorisé, chargez le code à partir de l'adresse spécifiée dans le liste d'autorisationet l'exécuter dans le contexte du compte du signataire. Cela signifie que le code du contrat de l'utilisateur est stocké à une adresse spécifique sur la chaîne de blocs, plutôt que directement inclus dans la transaction.

Les instructions opérationnelles et les paramètres associés sont stockés dans le donnéeschamp de la charge utile de la transaction.

Quelle est la valeur de l'EIP-7702?

L'EIP-7702 apporte une valeur significative car elle modifie fondamentalement l'ensemble du processus de transaction pour les portefeuilles Web3, entraînant une transformation drastique de l'expérience utilisateur. Les transactions ordinaires initiées par un EOA (Externally Owned Account) peuvent désormais exécuter plusieurs logiques similaires à des exécutions de contrats intelligents, telles que des transferts groupés. Cela a également un impact sur les scénarios CeFi, affectant l'identification des transactions et les frais de retrait et de consolidation.

EIP-7702 casse de nombreuses hypothèses de longue date : elle casse l'invariant selon lequel le solde d'un compte ne peut diminuer que par des transactions provenant de ce compte. Elle casse l'invariant selon lequel le nonce de l'EOA augmente de 1 après le début de l'exécution d'une transaction (il peut désormais augmenter simultanément de plusieurs valeurs). Elle casse la logique de protection qui repose sur la comparaison tx.originetmsg.sender, introduisant ainsi des risques potentiels pour de nombreux contrats existants. Cela casse également le fait qu'un EOA lui-même ne peut pas émettre d'événements, ce qui pourrait affecter l'identification et la surveillance de certains événements on-chain. Enfin, cela casse l'hypothèse selon laquelle une adresse EOA recevra toujours avec succès des actifs ERC20, 721, 1155 et autres (car cela pourrait échouer en raison du mécanisme de rappel).

4.5 Comparaison entre l'EIP-7702 et l'EIP-4337

1.Avantages de l'EIP-7702

L'EIP-7702 présente plusieurs avantages. L'un est des coûts de gaz plus bas, car il ne nécessite pas de passer par le module de point d'entrée, réduisant les opérations on-chain. Un autre est des coûts de migration d'utilisateur plus bas, car il n'est pas nécessaire de déployer un contrat on-chain en tant qu'entité principale à l'avance.

Comparé à l'EIP-4337, l'EIP-7702 prend également en charge l'exécution de code déléguée et propose deux types de délégation:

Délégation complète : Cela signifie déléguer le contrôle total d'une certaine opération à une adresse spécifique. Par exemple, un utilisateur peut déléguer la gestion de tous les jetons ERC-20 à une adresse de contrat intelligent, permettant au contrat d'effectuer toutes les opérations associées au nom de l'utilisateur.

Délégation protégée : Cela implique d'ajouter des restrictions et des garanties lors de la délégation pour assurer la sécurité et la contrôlabilité des opérations déléguées. Par exemple, un utilisateur peut déléguer uniquement des droits de gestion partiels des jetons ERC-20 à un contrat intelligent ou définir des conditions (par exemple, dépenser un maximum de 1 % du solde total par jour).

2. Inconvénients de l'EIP-7702

Le principal inconvénient de l'EIP-7702 est qu'il implique une mise à niveau du fork souple, nécessitant un consensus de la communauté pour avancer. Ses changements sont importants et pourraient avoir un large impact sur l'écosystème on-chain. Sur la base d'une évaluation initiale de Shisi Jun, plusieurs défis ont été identifiés, mais ces défis pourraient également représenter des opportunités de marché:

Le haut degré de liberté rend l’audit difficile, ce qui conduit les utilisateurs à exiger des portefeuilles plus fiables pour assurer la protection de la sécurité.

Les modifications apportées à l'architecture d'origine sont importantes. Bien que différents types de transactions puissent être distingués, de nombreuses infrastructures fondamentales, en particulier les contrats immuables sur la chaîne, peuvent ne pas être directement compatibles.

Alors que l'EIP-7702 fournit des capacités de contrat aux adresses EOA, l'espace de stockage correspondant ne peut pas être conservé.

Le coût des transactions individuelles est légèrement plus élevé en raison d'une augmentation significative de la section Calldata. Le coût total estimé d'un appel sera de 16 (gas)15 (bytes) = 240 (gas) pour les coûts de calldata, plus le coût de l'EIP-3860 de 215 = 30, et environ 150 pour les coûts d'exécution. Par conséquent, même la préparation d'un compte sans opérations augmenterait les coûts de gaz d'environ 500.

« Si le destinataire signe un code qui manque d'une fonction de réception, l'expéditeur peut être confronté à un DoS lorsqu'il tente d'envoyer des actifs. » Voir le cas. Ce problème survient lorsque l'EOA A signe quelque chose qu'il ne devrait pas avoir - un fichier rejouable avec une implémentation incorrecte (manquantreceive()).

La logique de consolidation et de retrait sur chaîne peut être incohérente. Par exemple, lors du transfert de jetons ERC-20, si le compte du destinataire contient du code, le contrat de jeton appelleraonERC20Receivedsur le compte du destinataire. Si onERC20Receivedreverts or returns an incorrect value, the token transfer will revert.

De plus, si un EOA peut émettre des événements, pourrait-il y avoir des problèmes ? Certaines infrastructures peuvent avoir besoin de prêter attention à cela.

Ce ne sont que quelques-uns des inconvénients résumés par Shisi Jun sur la base de la proposition EIP-7702 actuelle et des discussions sur le forum officiel. Une analyse complète nécessitera d'examiner le code d'implémentation final.

5. Résumé

L'article peut sembler étendu, mais il ne contient que environ 6 000 mots. De nombreuses références aux interprétations passées de l'EIP sont liées dans le texte pour une exploration plus approfondie, donc je ne m'étendrai pas sur celles-ci ici.

Actuellement, il semble que l'abstraction de compte ne peut être placée que dans le sixième module, qui est la dernière étape de la fixation de tout avant de le pousser vers l'avant. Le progrès accéléré de l'EIP-7702 apporte principalement des défis à la sécurité du système. Il est prévisible qu'il sera finalement mis en œuvre. Après tout, la fusion Ethereum, qui a impliqué une refonte majeure de l'algorithme de consensus, s'est déjà produite. Un nouveau type de transaction est relativement mineur en comparaison.

Cependant, cette fois, les changements sont assez perturbateurs, enfreignant plusieurs règles précédemment “impossibles” on-chain et modifiant la logique de la plupart des DApps. Pourtant, l'EIP-7702 saisit fermement le point le plus crucial : il réduit considérablement les coûts pour les utilisateurs. En revanche, l'EIP-4337 augmente presque de moitié les coûts de transaction.

Les utilisateurs restent des adresses EOA (Externally Owned Account) mais n'invoquent et n'utilisent la logique CA (Contract Account) que lorsque cela est nécessaire, réduisant ainsi les coûts de détention. Il n'est pas nécessaire de convertir d'abord en identité CA on-chain avant d'effectuer des actions, ce qui signifie que les utilisateurs n'ont pas besoin de s'inscrire.

Les utilisateurs peuvent facilement effectuer plusieurs transactions en parallèle à l'aide de leur EOA, telles que la combinaison de l'autorisation de déduction et l'exécution des déductions. Cela réduit intrinsèquement les coûts de transaction pour les utilisateurs. Pour les DApps, en particulier les projets nécessitant une gestion de niveau entreprise on-chain, tels que les échanges, cette optimisation est révolutionnaire. Si la consolidation par lots est mise en œuvre nativement, les coûts opérationnels de base des échanges pourraient être réduits de plus de la moitié, ce qui profiterait finalement également aux utilisateurs.

Par conséquent, bien qu'EIP-7702 introduise de nombreux changements, son impact sur les coûts seuls le rend digne d'être étudié et adapté pour tous les DApps. Cette fois, les utilisateurs sont sans aucun doute du côté de l'EIP-7702.

Avertissement：

1. Cet article est repris de [PANews]. Tous les droits d'auteur appartiennent à l'auteur original [Quatorzième Seigneur]. If there are objections to this reprint, please contact the Portail Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.