Interprétation du passé et de l'avenir de la piste abstraite des comptes Ethereum de 4337 à 7702.

Préface

L’article est divisé en deux grandes sections :

Au cours de la première moitié, à partir de la première proposition AA de 2015, le système organisera les principaux contenus des propositions Eip à ce jour, dans l’espoir de retracer le parcours des propositions historiques AA depuis les temps anciens, et d’évaluer de manière exhaustive les avantages et les inconvénients de chaque proposition.

Dans la deuxième moitié, nous mettrons l’accent sur la comparaison des rétroactions négatives du marché après la proposition EIP4337, puis analyserons en profondeur la proposition EIP7702 qui sera bientôt intégrée à la prochaine mise à niveau d’Ethereum. Une fois cette proposition fusionnée, elle changera complètement la forme des applications off-chain.

EIP-7702 a un changement révolutionnaire, laissez-moi vous expliquer en détail.

1. Contexte de l’abstraction du compte

1.1 Signification et positionnement abstraits du compte

Le fondateur d’Ethereum, Vitalik, a mis à jour la feuille de route de développement de ETH fin 2023, mais n’a pas modifié la configuration de l’abstraction de compte. Le modèle dominant actuel passe également de l’EIP-4337 à la prochaine étape de la conversion volontaire de compte EOA.

Depuis plus d’un an depuis le lancement de l’EIP4337 (annoncé officiellement lors de WalletCon à Denver le 1er mars 2023, le contrat principal ERC-4337 conçu et mis en œuvre par l’équipe de développement de la fondation Ethereum a été audité par OpenZeppelin et est considéré comme un nœud historique officiellement lancé).

Il a toujours été largement reconnu par les utilisateurs, mais il n’est pas largement utilisé. Dans un environnement de marché aussi contradictoire, le progrès de l’EIP-7702 a été considérablement accéléré, voire confirmé pour être fusionné lors de la prochaine mise à niveau.

1.2 État actuel du marché de l’abstraction des comptes

Pas besoin de mots, regardez directement les données.

Après un an et demi de développement, l’EIP4337, sous la collection de comptes de chaîne principale, n’a que 12 millions d’adresses, ce qui est le plus surprenant, c’est qu’il n’y a que 6 764 adresses actives sur le réseau principal d’ETH, peut-être qu’il y a un problème avec les statistiques, mais au moins il existe un écart considérable par rapport au nombre d’adresses EOA et CA, il faut savoir que le nombre d’adresses indépendantes sur le réseau principal d’ETH a déjà atteint 270 millions (source: ).

On peut dire que sur le Mainnet, l’EIP4337 n’a pas connu de développement substantiel.

(Les données du graphique proviennent de:)

Cependant, cela n’efface pas la valeur intrinsèque d’AA, car sa conception initiale dans EIP4337 était destinée à ne pas bien gérer les problèmes de compatibilité rétroactive sur Mainnet. Par conséquent, avec l’intégration généralisée d’AA natif sur diverses chaînes de couche L2, le nombre d’adresses EIP4337 a explosé sur L2. En juillet, le nombre d’utilisateurs actifs mensuels sur les chaînes Base et Polygon était respectivement de 1 million et 3 millions, ce qui est assez remarquable.

Donc, ce n’est pas que la conception de l’EIP4337 soit mauvaise, elle a de nombreux avantages. Nous les résumerons systématiquement plus tard. La situation actuelle est due aux différences entre Mainnet et L2, et ils doivent utiliser des solutions adaptées à chacun.

2. Qu’est-ce que l’abstraction de compte ?

Abstraction de compte, cela peut sembler difficile à comprendre, mais en réalité, cela résout essentiellement le problème de la séparation des droits de propriété.

Dans l’architecture EVM (c’est-à-dire Ethereum Virtual Machine), il y a deux types de compte, le compte externe (EOA) et le compte de contrat (Contract Account). La propriété et le droit de signature du compte externe sont en fait détenus par la même entité. Une personne détenant la Clé privée possède non seulement la “propriété” de ce compte, mais aussi le droit de “signer le transfert de tous les actifs”.

Cela est déterminé par la structure de transaction du compte Ethereum.

Dans la structure ci-dessous, on peut voir que les transactions standard d’Ethereum n’ont pas de partie From. Donc, lorsque j’ai effectué un transfert de fonds, à quel Adresse précise les fonds ont-ils été prélevés ? En réalité, l’Adresse From est déduite en analysant les paramètres VRS (c’est-à-dire la signature de l’utilisateur).

Ici, il s’agit de concepts tels que ECDSA et d’autres chiffrements asymétriques, de fonctions de seuil à sens unique, etc. Nous ne les détaillerons pas, mais en gros, la sécurité est garantie par la cryptographie, ce qui a bien sûr conduit à la situation actuelle de fusion des droits de propriété et à l’impasse de l’EOAAdresse.

L’effet principal de l’EIP4337 est d’ajouter le champ de l’adresse de l’expéditeur dans le champ de transaction, ce qui permet de séparer la clé privée de l’adresse qui est manipulée.

Alors, pourquoi la séparation des droits de propriété est-elle si importante ?

Parce que la conception du compte externe (EOA) entraînera plus de problèmes:

1. La protection de la clé privée est difficile : la perte de la clé privée (perte, attaque de Hacker, décryptage cryptographique) signifie la perte de tous les actifs.
2. Algorithme de signature : Le protocole natif ne peut utiliser que la signature et la vérification ECDSA pour vérifier les transactions.
3. Haute autorité de signature : pas de multi-signature native (la multi-signature ne peut être réalisée qu’en utilisant un smart contract pour la collaboration), une signature unique peut exécuter n’importe quelle opération.
4. Les frais de transaction ne peuvent être payés qu’en ETH et les transactions groupées ne sont pas prises en charge.
5. Divulgation de la vie privée des transactions : les transactions de personne à personne facilitent l’analyse des informations de confidentialité du compte holder.

Les contraintes d’appel rendent difficile l’utilisation d’Éther par 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 du prix de l’Éther).

Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, les concepts de prix du gaz, de limite du gaz et de blocage des transactions (dans l’ordre du nonce) sont trop complexes pour les utilisateurs.

Finalement, bien que de nombreux blocs de chaînes Portefeuille ou applications essaient d’améliorer l’expérience utilisateur par une optimisation du produit, leurs effets réels sont minimes.

Donc, la clé pour briser l’impasse réside dans la réalisation de l’abstraction de compte, en dissociant la propriété (Owner) et le pouvoir de signer (Signer), afin de résoudre chaque problème individuellement.

En fait, il y a de nombreux plans historiques, qui finiront tous par converger vers deux voies.

3、Analyse de l’historique des propositions AA

La solution au problème semble être proposée par de nombreuses propositions EIP, mais fondamentalement, il y a deux idées principales, donc chaque EIP non approuvée dans le passé a finalement convergé vers la solution actuelle.

3.1 La première option consiste à faire passer l’EOAAdresse en CAAdresse

Dès le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte basée sur le contrat intelligent, autour de l’EIP-101. L’Adresse a été modifiée pour ne comporter que du code et de l’espace de stockage, les frais de transaction étant pris en charge par ERC20. Le solde des Jetons natifs a été modifié en Jetons similaires à ERC20 via un contrat intelligent pré-compilé (pouvant avoir des fonctionnalités telles que l’autorisation de retenue), et les champs de transaction ont été simplifiés pour inclure uniquement to, startgas, data et code.

Maintenant, il semble que ce soit une réforme de type Grand Bond en avant, qui modifiera considérablement la conception sous-jacente et permettra à chaque compteAdresse d’avoir sa propre logique de «code» (ce qui est en fait l’effet que EIP-7702 vise à atteindre).

Il peut également engendrer d’autres fonctionnalités, telles que

1. Permettre aux transactions d’utiliser plus d’algorithmes de cryptage, qui peuvent être spécifiés par le code interne de chaque adresse pour la méthode de vérification et d’authentification
2. Possède des caractéristiques de résistance aux attaques quantiques, car le code possède des caractéristiques de mise à niveau.
3. Permettre à l’Ether d’avoir les mêmes fonctionnalités que les contrats ERC20, avec comme effet principal l’autorisation de prélèvement, évitant ainsi la perte de jetons natifs
4. Améliorez l’espace personnalisé du compte, compatible avec la récupération sociale, le support sbt, la récupération de Clé secrète

La raison pour laquelle il n’y a pas eu de poursuite est évidemment que le rythme était trop rapide et que la résolution des problèmes de conflit de hachage de transaction actuels et des considérations de sécurité n’a pas été suffisamment prise en compte, mais les idées de chaque avantage sont devenues l’un des principaux éléments des fonctionnalités clés de EIP4337 et EIP7702 ultérieurs.

Plus tard, une série de propositions d’amélioration de l’EIP a tenté de perfectionner cette logique.

EIP-859: Abstraction de compte de chaîne principale–2018-01-30

Essayant de résoudre les problèmes de déploiement de Code, sa fonction principale est, si un contrat de partie de transaction n’est pas déployé, alors le contrat Portefeuille sera exécuté avec le paramètre de code attaché, et il propose également un nouvel op-code PAYGAS, qui est utilisé non seulement pour payer le gas, mais aussi comme séparateur entre la partie de validation et la partie d’exécution des paramètres de transaction.

Bien que mort sans maladie à l’époque, cela est devenu l’une des logiques centrales de l’EIP7702 maintenant, chaque transaction de l’EIP7702 combinant une structure de transaction spéciale peut être accompagnée d’un certain code, permettant ainsi à l’EOAAdresse d’avoir la capacité contractuelle dans cette transaction.

EIP-7702: Code de compte EOA défini le 07-05-2024

C’est également au cœur de l’EIP de discussion ultérieure, publiée par Vitalik sous le nom de EIP-7702 en remplacement de l’EIP-3074 (7 mai 2024). Par conséquent, l’EIP-3074 est abandonné et l’EIP-7702 est inclus dans le prochain fork dur ETH Prague/Electra (Pectra), nous détaillerons cela dans la suite de l’article.

3.2 La deuxième option consiste à faire fonctionner CAAdresse via EOAAdresse

EIP-3074: Ajouter les opérateurs AUTH et AUTHCALL --2020-10-15

Ajoutez deux nouveaux OpCodes, AUTH et AUTHCALL, dans l’EVM, permettant aux EOA d’autoriser les contrats à appeler d’autres contrats au nom de l’EOA.

En combinant avec l’image ci-dessous, en général, un EOA peut envoyer un message signé (transaction) à un contrat de confiance (appelé Invoker), et ce contrat Invoker peut utiliser les codes d’opération AUTH et AUTHCALL pour envoyer la transaction au lieu de l’EOA.

EIP-4337：Utiliser le pool de mémoire des transactions pour implémenter l’abstraction de compte–2021-09-29

En somme, il a été inspiré par le MEV pour concevoir, sa valeur centrale étant d’éviter complètement les modifications du protocole de couche de consensus.

eip4337 propose un nouvel objet de transaction UserOperation, que l’utilisateur envoie dans le pool de mémoire (mempool), et que les mineurs empaquettent en lots depuis la perspective du mineur pour exécuter les transactions de contrat. Fondamentalement, cela permet d’exécuter les transactions et les opérations de compte au niveau du contrat.

EIP-5189: Opérer un compte abstrait via un endosseur-2022-06-29

Ceci est une optimisation de la logique EIP4337, qui vise à empêcher les attaques de blocage Dos malveillantes des Bundlers en établissant un mécanisme d’endorsement de sanction financière.

3.3 Autres propositions de soutien à l’AA

EIP-2718: Enveloppe de conteneur pour nouveaux types de transactions - 2020-06-13

Ceci est une proposition déjà finale, qui définit un nouveau type de transaction en tant qu’enveloppe pour les nouveaux types de transactions à venir.

Le résultat final est que lorsqu’un nouveau type de transaction est introduit, il est distingué par un encodage spécifique pour indiquer quel type de transaction il s’agit, ce qui permet une compatibilité ascendante sans nécessiter de compatibilité descendante. L’exemple le plus courant est EIP1559, qui différencie les frais de transaction en utilisant un nouvel encodage de type de transaction sans affecter les types de transaction hérités initiaux.

EIP-3607: Empêcher le déploiement de contrats intelligents sur les adresses EOA – 10 juin 2021

Ceci est un plan de secours sur le chemin AA, utilisé pour éviter les conflits entre le déploiement du contrat Adresse et EOAAdresse. Il contrôlera la méthode de génération du contrat pour empêcher le déploiement du code sur une Adresse qui est déjà une EOA Adresse. Ce risque est en fait très faible, après tout, l’Adresse Ethereum est longue de 160 bits, bien qu’il existe des méthodes pour collisionner les Clé privée et obtenir une Adresse de contrat spécifiée par Clé privée, mais avec la puissance de calcul totale de BTC investie, cela prendrait encore environ un an.

3.4 Comment comprendre le développement abstrait du compte ?

Il est d’abord nécessaire de comprendre la valeur après la conversion en CA.

Essentiellement, c’est l’effet réel de l’EIP-4337, il peut être réalisé

Cependant, le principal inconvénient de l’EIP-4337 est qu’il contrevient au principe de motivation humaine.

Il semble qu’il se soit amélioré, mais il est coincé dans une boucle mortelle de développement du marché. De nombreux Dapp ne sont pas encore compatibles, ce qui rend les utilisateurs réticents à utiliser l’adresse CA, même si cela entraîne un Coût de transaction plus élevé (même dans les scénarios de transfert ordinaires, il peut doubler le Blanchiment de capitaux), et cela dépend trop de la compatibilité de Dapp lui-même.

Donc, jusqu’à présent, cela n’a pas été largement adopté sur le réseau principal d’Éther.

Le coût est la norme de mesure la plus importante pour les utilisateurs, il faut réduire les coûts.

Cependant, pour réduire GoutteGAS de manière significative, il est nécessaire de mettre à niveau Ethereum lui-même en effectuant une mise à jour logicielle en douceur (soft fork), en modifiant les modules de calcul du GAS ou les modules de consommation de GAS des opcodes. Cependant, puisqu’il s’agit d’un soft fork, pourquoi ne pas envisager directement l’EIP-7702 ?

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

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

Il se distingue par un nouveau type de transaction qui permet aux EOA de temporairement avoir la fonctionnalité de contrat intelligent dans une transaction unique, ce qui permet de prendre en charge des transactions en vrac, des transactions sans gaz et une gestion de l’autorisation personnalisée dans les activités commerciales, sans avoir besoin d’introduire un nouveau code opEVM (qui affecterait la compatibilité ascendante).

Il permet aux utilisateurs d’obtenir la plupart des capacités de AA sans déployer de smart contract, et même de fournir la capacité à des tiers de lancer des transactions au nom des utilisateurs sans avoir besoin de Clé privée, mais simplement d’informations d’autorisation signées.

4.2 Structures de données

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

Il est important que le nouvel objet authorization_list soit ajouté, qui stocke le code que les signataires souhaitent exécuter dans leur EOA. Lorsque les utilisateurs signent une transaction, ils signent également le code du contrat à exécuter. Il existe sous forme de liste à deux dimensions, ce qui indique qu’il peut stocker plusieurs informations d’opération en vrac et exécuter des opérations en vrac.

4.3 Cycle de vie des transactions

4.3.1 Phase de vérification

Au début de l’exécution des transactions, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] de l’autorisation_list :

1. En utilisant ecrecover pour récupérer l’Adresse du signataire à partir des signatures r et s (remarquez que c’est le mécanisme interne d’Ethereum, donc cet EIP ne modifie pas l’algorithme de signature). authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (tout comme pour la vérification précédente, cela génère une Adresse de signature locale pour cette liste).
2. Vérifier l’ID de la chaîne (empêcher la rediffusion de la chaîne fork).
3. Vérifiez si le code du signataire de l’autorité est vide ou a été délégué (pour vérifier si la transaction est une transaction valide 7702 et sera exécutée par le mécanisme de délégation).
4. Vérifiez le nonce du signataire de l’autorité (pour empêcher la répétition de la signature de l’autorité).
5. Définir le code du signataire de l’autorité comme 0xef0100 || adresse (utilisée pour contourner la stratégie anti-collision EIP3607)
6. Ajouter le nonce du signataire de l’autorité (pour éviter la répétition partielle de la signature).
7. Ajouter le compte signataire authority à la liste des adresses accessibles (convertir l’adresse en adresse de réception, vérifier les frais de gaz stockés Goutte)

4.3.2 Phase d’exécution des opérations

Où se trouve le code du contrat à exécuter ainsi que les instructions d’opération ?

“La” nouvelle version ne modifie que le comportement du déploiement du code.

Il ne définit plus le code de compte comme contract_code, mais récupère le code d’adresse à partir de la liste d’autorisations et définit ce code comme le code de compte.

Ainsi, lorsque le code d’autorisation doit être exécuté, le code est chargé à partir de l’adresse spécifiée dans le champ d’adresse du authorization_list et exécuté dans le contexte du compte du signataire.

Cela signifie que le code de contrat de l’utilisateur est réellement stocké à une Adresse spécifique off-chain, plutôt que d’être directement inclus dans la transaction.

Les instructions de fonctionnement et les paramètres associés sont stockés dans le champ de données de la charge utile de la transaction.

4.4 Quelle est la valeur de l’EIP-7702 ?

Il y aura des changements dans l’ensemble du processus de Web3Portefeuille, ce qui entraînera également un changement majeur dans l’expérience utilisateur, car les transactions normales initiées par EOA peuvent également exécuter diverses logiques similaires aux contrats, telles que le transfert en lot. Cela affectera l’authentification des transactions dans le contexte de CeFi, ainsi que les frais de regroupement des dépôts et des retraits.

En raison de son apparition, il a brisé de nombreux préjugés, tels que:

1. Il a rompu l’invariabilité selon laquelle le solde du compte ne peut diminuer que par des transactions provenant de ce compte.
2. A rompu l’invariabilité de l’augmentation de 1 du nonce EOA après le début de l’exécution de la transaction (peut augmenter simultanément plusieurs).
3. Il a brisé la logique de protection des comparaisons entre tx.origin et msg.sender, ce qui pose un risque pour de nombreux contrats passés.
4. Rompre avec la situation actuelle où l’EOA ne peut pas émettre d’événements, il peut être nécessaire de faire attention à la reconnaissance et à l’écoute de certains événements hors chaîne.
5. A brisé le statu quo selon lequel l’EOAAdresse accepte inévitablement des actifs tels que ERC20, 721, 1155 (en raison du mécanisme pullback, il peut échouer)

4.5 Comparaison entre EIP-7702 et EIP-4337

1. Les avantages de l’EIP-7702

Le gaz est plus faible car il n’a pas besoin de passer par le module d’entrée pour réduire les opérations hors chaîne.

Les coûts de migration des utilisateurs sont plus faibles et il n’est pas nécessaire de déployer préalablement des contrats off-chain en tant que corps principal.

Comparé à Eip4337, il y aura également une exécution déléguée de code et deux façons de le faire :

Délégation complète (Full Delegation)

La délégation complète fait référence à la délégation de tous les droits d’une opération à une Adresse spécifique. Par exemple, un utilisateur peut déléguer tous les droits de gestion des jetons ERC-20 à une Adresse de contrat intelligent, ce qui permet à ce contrat intelligent d’exécuter toutes les opérations pertinentes au nom de l’utilisateur.

Délégation protégée

L’ordre protégé fait référence à l’ajout de certaines restrictions et mesures de protection pendant le processus de passation de l’ordre, afin de garantir la sécurité et la maîtrise des opérations de passation de l’ordre.

Par exemple, les utilisateurs peuvent déléguer uniquement une partie des droits de gestion des Jetons ERC-20 à un Smart Contract, ou définir certaines conditions restrictives (par exemple, ne pas dépenser plus de 1 % du solde total par jour).

2. Inconvénients de l’EIP-7702

Son inconvénient majeur est qu’il s’agit d’une mise à niveau Soft Fork, qui nécessite un consensus de la part de tous et entraîne des modifications majeures ayant un impact considérable sur l’écosystème off-chain. Après une évaluation initiale, il présente les défis suivants, mais ces défis sont aussi des opportunités sur le marché :

1. Très grande liberté, difficile à auditer, les utilisateurs auront davantage besoin d’un portefeuille fiable pour assurer leur sécurité.
2. Les changements apportés à l’architecture d’origine sont trop importants, même s’ils sont différenciés par différents types de transactions, de nombreux aspects fondamentaux, en particulier les contrats non modifiables sur la chaîne, ne peuvent pas être directement adaptés.
3. La capacité de contrat est fournie pour EOAAdresse, mais l’espace de stockage correspondant ne peut pas être conservé.
4. Le coût des transactions individuelles est légèrement plus élevé car cela augmentera considérablement la partie Calldata. Le coût total estimé de l’appel sera de 240 (gas) coûts Calldata = 16 (gas) * 15 (octets), plus les coûts EIP-3860 2 * 15 = 30, plus environ 150 coûts d’exécution. Par conséquent, la simple préparation du compte, même sans rien faire, nécessitera une augmentation de 500 Gas.
5. “Si le destinataire signe un code qui n’a pas de fonction de réception, l’expéditeur pourrait être confronté à un DOS lors de la tentative d’envoi d’actifs.” Voir l’affaire. En fait, le problème est que l’EOA A a signé quelque chose qu’il ne devrait pas signer - un fichier de rejeu avec une implémentation erronée (pas de receive()).
6. La logique de dépôt et de retrait hors chaîne peut être incohérente, par exemple lors du transfert de Jeton ERC-20, si le compte destinataire a du code, alors le contrat Jeton appellera le compte destinataire à onERC20Received. Si onERC20Received renvoie une valeur invalide ou une erreur, le transfert de jetons sera annulé.
7. De plus, si EOA peut émettre des événements, y aura-t-il des problèmes ? Certaines infrastructures peuvent nécessiter une attention particulière.

Ce ne sont que quelques-uns des défauts identifiés par Shijun basés sur le contenu actuel de la proposition EIP7702 et les résumés des discussions sur le forum officiel. Une analyse complète ne pourra être réalisée qu’à partir du code d’implémentation final.

Référence ci-dessous:

5. Résumé complet

Cet article semble être de grande envergure, mais en réalité, le contenu textuel ne compte que plus de 6 000 caractères. De nombreux interprétations EIP passées impliquées au milieu sont liées dans le texte pour l’expansion, donc je ne vais pas les examiner davantage.

À première vue, l’abstraction de compte ne peut être placée que dans le sixième module, c’est-à-dire la réparation de tout, et finalement mise en œuvre. Maintenant, EIP7702 accélère considérablement sa progression, ce qui pose davantage de défis en termes de sécurité du système. On peut s’attendre à ce qu’il soit finalement réalisé, après tout, l’intégration de l’ETH et la modification de l’algorithme de consensus sont des événements révolutionnaires qui peuvent se produire, alors pourquoi parler de simples nouveaux types de transactions.

Mais cette fois-ci, il y a tellement de contenus perturbateurs, ça brise de nombreuses règles invisibles en dehors de la chaîne, ça brise aussi la logique d’application de la plupart des Dapp, mais il maintient fermement un point crucial, c’est que le coût pour les utilisateurs est plus bas ! Par rapport au Coût de transaction presque doublé de l’EIP4337.

L’utilisateur lui-même est toujours un EOAAdresse, mais il active et utilise la logique de CA uniquement lorsque cela est nécessaire, ce qui réduit les coûts de possession. Il n’est pas nécessaire de convertir d’abord l’identité de CA sur la chaîne avant d’effectuer des opérations, ce qui équivaut à ce que l’utilisateur n’a pas besoin de s’inscrire.

Les utilisateurs peuvent facilement effectuer plusieurs transactions en parallèle avec leur EOA, telles que l’autorisation de prélèvement et l’exécution de prélèvement, ce qui réduit le Coût de transaction pour les utilisateurs. Pour les Dapp, en particulier celles nécessitant une gestion off-chain de niveau entreprise, telles que les plateformes d’échange, il s’agit d’une optimisation révolutionnaire. Une fois la collecte en masse réalisée dans l’écosystème natif, les coûts des plateformes d’échange peuvent être réduits de plus de la moitié instantanément, ce qui profitera finalement aux utilisateurs.

Par conséquent, bien qu’il ait beaucoup changé, occuper le coût de cette dimension vaut la peine que tous les Dapp l’étudient et s’y adaptent, car cette fois, les utilisateurs seront inévitablement du côté de l’EIP7702.