- Rubrique
62247 Popularité
20061 Popularité
5782 Popularité
3183 Popularité
3546 Popularité
28403 Popularité
15111 Popularité
21282 Popularité
11307 Popularité
1730 Popularité
- Épingler
62247 Popularité
20061 Popularité
5782 Popularité
3183 Popularité
3546 Popularité
28403 Popularité
15111 Popularité
21282 Popularité
11307 Popularité
1730 Popularité
Analyse approfondie : la percée révolutionnaire de l'abstraction de compte Ethereum EIP-7702
Analyse approfondie du passé et de l'avenir de la piste d'abstraction des comptes Ethereum
Cet article est divisé en deux grandes parties :
La première partie part de la première proposition AA de 2015, le système a organisé jusqu'à présent le contenu des principales propositions EIP, a exploré l'évolution des propositions historiques AA et a effectué une évaluation globale des différentes solutions.
La seconde moitié se concentre sur l'analyse comparative des raisons pour lesquelles le marché a réagi tièdement après le lancement de l'EIP4337, et examine en profondeur l'EIP7702 qui sera inclus dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition intégrée, elle transformera intégralement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, examinons cela en détail.
1. Contexte de l'abstractisation du compte
1.1 Signification abstraite du compte
Le fondateur d'Ethereum, Vitalik, n'a pas modifié la définition de l'abstraction de compte lors de la mise à jour de la feuille de route ETH à la fin de 2023. Le modèle principal évolue actuellement d'EIP-4337 vers la prochaine étape de conversion volontaire des comptes EOA.
Depuis le lancement de l'EIP4337 il y a plus d'un an, le 1er mars 2023, lors de la WalletCon à Denver, ( a été officiellement annoncé. Bien qu'il ait été largement reconnu par les utilisateurs, son taux d'utilisation reste faible. Dans ce contexte de marché contradictoire, l'avancement de l'EIP-7702 a été considérablement accéléré et il a été confirmé qu'il sera intégré dans la prochaine mise à niveau.
) 1.2 État du marché abstrait des comptes
Après un an et demi de développement, le nombre de comptes d'EIP4337 sur les chaînes majeures n'est que de 12 millions, dont seuls 6 764 sont des 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 indépendantes sur le réseau principal d'Ethereum a atteint 270 millions, on peut donc dire qu'EIP4337 n'a presque pas connu de développement substantiel sur le réseau principal.
Cependant, cela n'affecte pas la valeur fondamentale d'AA. La conception de l'EIP4337 détermine qu'il est difficile de résoudre le problème de compatibilité ascendante du réseau principal. Avec l'intégration native d'AA dans divers L2, le nombre d'adresses EIP4337 a connu une explosion sur L2, les utilisateurs actifs mensuels de Base et de la chaîne Polygon atteignant respectivement 1 million et 3 millions en juillet.
Par conséquent, ce n'est pas que la conception de l'EIP4337 soit erronée, elle a de nombreux avantages. L'état actuel provient 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é.
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(. 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".
Ceci est déterminé par la structure des transactions du compte Ethereum. On peut voir à partir de la structure de la transaction que la transaction standard d'Ethereum n'a pas de champ From. Lors du transfert de fonds, le montant spécifique qui est consommé à partir de quelle adresse est déduit à partir des paramètres VRS ), c'est-à-dire que la signature de l'utilisateur ( est utilisée pour obtenir l'adresse From.
Cela concerne des concepts tels que l'ECDSA et les fonctions de seuil unidirectionnelles, que nous ne développerons pas. En résumé, la sécurité ici est garantie par la cryptographie, mais cela a également entraîné la difficulté actuelle de la fusion des droits de propriété des comptes EOA.
L'effet principal de l'EIP4337 est d'ajouter un champ d'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 de la propriété est si importante est que la conception des comptes externes )EOA( peut entraîner davantage de problèmes :
Difficulté à protéger la clé privée : la perte de la clé privée ), une attaque de hacker ou un décryptage cryptographique ( signifie perdre tous ses 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 : pas de multi-signature natif ), 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 facilitent l'analyse des informations privées du titulaire du compte.
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 fluctuation des prix (.
Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, le prix du Gas, la limite du Gas, le blocage des transactions ) l'ordre des Nonces ( et d'autres concepts qui sont trop compliqués pour les utilisateurs.
Enfin, bien que de nombreux portefeuilles ou applications blockchain essaient d'améliorer l'expérience utilisateur par 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, en découplant la propriété )Owner( et le droit de signature )Signer(, afin de résoudre progressivement les problèmes mentionnés ci-dessus.
Il y a eu plusieurs solutions dans l'histoire, qui se sont finalement regroupées en deux voies.
![Analyse approfondie du passé et de l'avenir de la piste d'abstraction des comptes Ethereum])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
3. Contexte historique des propositions AA
Il semble y avoir de nombreuses propositions EIP pour résoudre le problème, mais au fond, il n'y a que deux idées principales. Chaque problème considéré par un EIP non approuvé a finalement convergé vers des points de rupture dans les solutions existantes.
) 3.1 Première méthode : 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. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, et le soutien des frais de transaction a été transféré au paiement par ERC20, en convertissant les tokens natifs en un format similaire à l'ERC20 pour garder le solde ###, permettant des fonctionnalités telles que l'autorisation de prélèvement (, et en simplifiant les champs de transaction pour ne contenir que to, startgas, data et code.
À première vue, il s'agit d'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 précisément l'effet que l'EIP-7702 vise à réaliser (.
Il peut également dériver d'autres fonctionnalités, par exemple :
Permettre aux transactions d'utiliser davantage d'algorithmes cryptographiques, pouvant être spécifiés par la méthode de vérification et d'authentification interne du Code de chaque adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est évolutif.
Permettre à l'Éther d'avoir les mêmes caractéristiques fonctionnelles que les contrats ERC20, l'effet principal étant de réaliser une autorisation de prélèvement sans perte de 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és, etc.
La raison pour laquelle nous n'avons pas pu avancer est simple : il est évident que nous avons fait un pas trop grand, en ne tenant pas compte des problèmes de conflit de hachage des transactions actuelles et des risques de sécurité, c'est pourquoi cela a été mis de côté. Mais chaque concept de mérite est devenu l'une des fonctionnalités clés des EIP4337 et EIP7702 qui ont suivi.
Plus tard, une série d'EIP a également tenté d'améliorer cette logique :
EIP-859: abstraction de compte de la chaîne principale )2018-01-30(
Essayer de résoudre le problème de déploiement du code. La fonction principale est que, si le contrat de la partie transactionnelle n'est pas déployé, le déploiement du portefeuille de contrat s'effectue en utilisant le paramètre code joint à la transaction. 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 validation et la partie d'exécution dans les paramètres de la transaction.
Bien que cela se soit terminé sans succès à l'époque, cela est devenu l'un des éléments centraux 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 d'avoir des capacités de contrat dans cette transaction.
EIP-7702 : définir le code du compte EOA )2024-05-07(
C'est le cœur du mécanisme de discussion de cet article, l'EIP. Vitalik a publié l'EIP-7702 comme alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné, et l'EIP-7702 sera intégré 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 piloter l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL ###2020-10-15(
Ajout de deux nouveaux OpCodes AUTH et AUTHCALL dans l'EVM, permettant aux EOA d'autoriser des contrats à appeler d'autres contrats en remplaçant l'identité de l'EOA grâce à 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 à la place de cet EOA.
EIP-4337 : Implémentation de l'abstraction de compte via le pool de mémoire des transactions (2021-09-29)
Il est conçu en s'inspirant de 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 la mémoire tampon, et qui est ensuite regroupé en masse par les bundlers pour être livré aux transactions d'exécution de contrat du point de vue des mineurs, essentiellement en déplaçant le fonctionnement des transactions et des comptes au niveau des contrats.
EIP-5189 : Opération de comptes abstraits par des endosseurs (2022-06-29)
Cela optimise la logique de l'EIP4337, en faisant face aux Bundlers malveillants par la mise en place d'un mécanisme de pénalité financière pour endosser afin de prévenir les attaques de blocage DoS.
( 3.3 Autres propositions pour soutenir AA
EIP-2718 : enveloppe de nouveaux types de transactions )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 de futurs types de transactions supplémentaires.
L'effet final est qu'en introduisant un nouveau type de transaction, on peut distinguer les différentes transactions par un codage spécifique, permettant ainsi une compatibilité uniquement en arrière, sans nécessiter de compatibilité en avant. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilisant un nouveau codage de type de transaction, sans affecter le type de transaction legacy initial.
EIP-3607 : rendre les adresses EOA incapables de déployer des contrats (2021-06-10)
Ceci est un plan complémentaire sur le chemin AA, destiné à prévenir les conflits entre les adresses de déploiement de contrat et les adresses EOA. Il contrôlera la méthode de génération de contrat, empêchant ainsi le système de déployer du code à une adresse qui est déjà une adresse EOA. Ce risque est en réalité très faible, car les adresses Ethereum ont une longueur de 160 bits. Bien qu'il existe une méthode pour générer une clé privée qui correspond à une adresse de contrat spécifiée, cela nécessiterait environ un an avec l'ensemble de la puissance de calcul de Bitcoin.
( 3.4 Comment comprendre l'évolution des comptes abstraits ?
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.
Cela a l'air mieux, mais cela est tombé dans un cercle vicieux de développement du marché. Beaucoup de Dapp ne sont pas encore compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et même l'utilisation de CA entraîne des coûts de transaction plus élevés dans des scénarios de transfert ordinaires, les frais de transaction doublent, et cela dépend trop de la compatibilité des Dapp elles-mêmes.
Donc, il n'a pas encore é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 vraiment réduire le GAS, il est nécessaire que l'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 envisager directement l'EIP-7702?
![Analyse approfondie du passé et de l'avenir de l'abstraction des comptes Ethereum])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp###
4. Analyse complète de l'EIP-7702
( 4.1 Qu'est-ce que l'EIP-7702
Il se distingue par un nouveau type de transaction, permettant aux EOA de temporairement posséder les fonctionnalités des contrats intelligents dans une seule transaction, soutenant ainsi des transactions en masse, des transactions sans Gas et une gestion des droits personnalisée, sans avoir besoin d'introduire un nouvel opCode EVM) affectant la compatibilité ascendante(.
Il permet aux utilisateurs d'acquérir la plupart des capacités d'AA sans déployer de contrats intelligents, et peut même offrir la capacité d'initier des transactions au nom des utilisateurs par des tiers, sans que les utilisateurs aient besoin de fournir leur clé privée, il suffit de signer les informations d'autorisation.
) 4.2 structure des 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, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, valeur, données, access_list, liste_d'autorisation, signature_y_parity, 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, qui existe sous forme de liste bidimensionnelle, permettant de stocker plusieurs informations d'opération et d'exécuter des opérations en lot.
authorization_list = [[chain_id, adresse, nonce, y_parity, r, s], ...]
)