Analyse approfondie du passé et de l'avenir de l'abstraction de compte Ethereum

Introduction

Cet article est divisé en deux grands modules :

La partie supérieure commence avec la première proposition AA de 2015, elle systématise le contenu principal des propositions EIP à ce jour, explore l'évolution des propositions historiques d'AA et évalue de manière globale les avantages et les inconvénients de chaque solution.

La deuxième partie se concentre sur la comparaison de la réaction froide du marché face à la sortie de l'EIP4337, en analysant en profondeur l'EIP7702 qui sera inclus dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition intégrée, elle changera complètement la forme des applications sur chaîne.

EIP-7702 a une signification révolutionnaire, examinons cela en détail.

1. Contexte de l'abstraction de compte

1.1 La signification de l'abstraction de compte

Le fondateur d'Ethereum, Vitalik, a mis à jour à nouveau la feuille de route d'ETH à la fin de 2023, mais n'a apporté aucun changement à la position de l'abstraction de compte. Le modèle dominant passe actuellement de l'EIP-4337 à la prochaine étape "conversion volontaire des comptes EOA".

Depuis le lancement de l'EIP4337 il y a plus d'un an, le 1er mars 2023 lors de WalletCon à Denver, le contrat principal ERC-4337 conçu et réalisé par les développeurs de la fondation Ethereum a été audité par OpenZeppelin et est considéré comme officiellement lancé (, bien qu'il ait toujours été largement reconnu par les utilisateurs mais peu utilisé. Dans ce contexte de marché contradictoire, les progrès de l'EIP-7702 ont été considérablement avancés et il a été confirmé qu'il sera intégré lors de la prochaine mise à niveau.

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

Après un an et demi de développement, l'EIP4337 n'a que 12 millions d'adresses sur les chaînes principales, dont seulement 6 764 adresses actives sur le réseau principal Ethereum, ce qui est très loin du nombre d'adresses EOA et CA. Le nombre d'adresses uniques sur le réseau principal Ethereum a atteint 270 millions, il est donc juste de dire que l'EIP4337 n'a pas connu de développement substantiel sur le réseau principal.

Cependant, cela n'affecte pas la valeur intrinsèque de l'AA. Dès sa conception, l'EIP4337 était destiné à ne pas résoudre le problème de compatibilité en avant du réseau principal. Avec l'intégration native de l'AA dans divers L2, le nombre d'adresses EIP4337 a explosé sur les L2, dont les activités mensuelles de Base et Polygon ont atteint respectivement 1 million et 3 millions en juillet, ce qui est assez considérable.

Ainsi, ce n'est pas que le design de l'EIP4337 soit erroné, il présente de nombreux avantages. La situation actuelle provient des différences entre le réseau principal et le L2, qui nécessitent des solutions adaptées à chacun.

![Analyse approfondie de l'abstraction de compte Ethereum : passé et futur]###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 ) Contract Account (. La propriété et le droit de signature du compte externe sont 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 peut également "signer le transfert de tous les actifs".

Ceci est déterminé par la structure de transaction des comptes Ethereum. Dans une transaction standard, il n'y a pas de champ From ; le transfert de fonds est dérivé de l'adresse From grâce à la signature utilisateur ) avec les paramètres VRS (. Cela implique des concepts comme l'ECDSA et les fonctions de seuil unidirectionnelles, garantis par la cryptographie pour la sécurité, 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 de séparer la clé privée de l'adresse manipulée.

La séparation des droits de propriété est importante car le compte externe )EOA( a engendré davantage de problèmes de conception :

1. Difficulté à protéger la clé privée : perdre la clé privée signifie perdre tous les actifs.
2. Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme ECDSA.
3. Autorisations de signature trop élevées : pas de multi-signature natif, une seule signature suffit pour exécuter n'importe quelle opération.
4. Les frais de transaction ne peuvent être payés qu'en ETH, les transactions en masse ne sont pas supportées.
5. Fuite de la vie privée des transactions : les transactions en one-to-one facilitent l'analyse des informations privées des détenteurs de compte.

Ces restrictions rendent difficile l'utilisation d'Ethereum par les utilisateurs ordinaires :

Tout d'abord, l'utilisation de toute application Ethereum nécessite de détenir de l'ETH et d'assumer le risque de volatilité des prix.

Deuxièmement, les utilisateurs doivent gérer une logique de frais complexe, le prix du gaz, la limite du gaz, le blocage des transactions ) et l'ordre des nonces (, ces concepts étant trop complexes.

Enfin, bien que de nombreux portefeuilles ou applications de blockchain tentent d'améliorer l'expérience utilisateur par l'optimisation des produits, l'effet réel est très faible.

Ainsi, la solution réside dans l'abstraction de compte, qui découple la propriété )Owner( et le droit de signature )Signer(, afin de résoudre chacun des problèmes susmentionnés.

Dans l'histoire, plusieurs solutions ont émergé, se regroupant finalement en deux voies.

![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. Historique des propositions AA

La solution au problème semble comporter plusieurs propositions d'EIP, mais au fond, il n'y a que deux idées fondamentales. Chaque EIP non adopté soulève des questions qui se sont cristallisées en points de rupture des solutions existantes.

) 3.1 Première option : transformer l'adresse EOA en adresse CA

Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte sous forme de contrat dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, les frais de transaction ont été adaptés pour prendre en charge le paiement ERC20, et les tokens natifs ont été convertis en tokens de type ERC20 via des contrats précompilés, avec des fonctionnalités telles que l'autorisation de prélèvement, et le champ de transaction a été simplifié en to, startgas, data et code.

C'est 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 "code" ###, qui est précisément l'effet que l'EIP-7702 cherche à réaliser (.

peut également donner lieu à d'autres fonctions, telles que :

1. Les transactions utilisent davantage d'algorithmes cryptographiques, chaque adresse spécifie une méthode de vérification et d'authentification par code interne.
2. Possède des caractéristiques de résistance aux attaques quantiques, code pouvant être mis à jour
3. L'Éther possède des fonctionnalités de contrat ERC20 similaires, avec des effets clés tels que l'autorisation de prélèvement, sans perte de la monnaie native.
4. Améliorez l'espace de personnalisation du compte, compatibilité avec la récupération sociale, support SBT, récupération de clés, etc.

La raison pour laquelle il n'a pas été poursuivi est simple : les pas étaient trop grands et la question des conflits de hachage des transactions actuelles ainsi que les problèmes de sécurité n'ont pas été suffisamment pris en compte, ce qui a conduit à une mise en attente. Cependant, chaque concept positif est devenu l'une des fonctionnalités centrales des EIP4337 et EIP7702.

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(

Tenter de résoudre le problème de déploiement de Code, la fonction principale étant que si le contrat de la partie transactionnelle n'est pas déployé, alors le code joint à la transaction est utilisé pour déployer le portefeuille de contrats. Un nouvel opcode PAYGAS a également été proposé, qui, en plus de payer le gaz, devient un séparateur entre la partie de validation 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 logiques centraux de l'actuel EIP7702. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut être accompagnée d'un certain code, permettant aux adresses EOA de posséder des capacités de contrat dans cette transaction.

EIP-7702 : configurer le code de compte EOA )2024-05-07(

Ceci est le cœur du mécanisme de discussion ultérieure de cet article, publié par Vitalik comme alternative à l'EIP-3074. Par conséquent, l'EIP-3074 a été abandonné, et l'EIP-7702 est déterminé pour être inclus dans le prochain hard fork ETH Prague/Electra)Pectra(.

) 3.2 Deuxième option : faire en sorte que l'adresse EOA pilote l'adresse CA

EIP-3074 : ajout des opcodes AUTH et AUTHCALL (2020-10-15)

Ajouter deux nouveaux OpCodes dans l'EVM : AUTH et AUTHCALL, permettant aux EOA d'autoriser des contrats à appeler d'autres contrats en remplaçant l'identité EOA par ces deux opcodes.

En résumé, un EOA peut envoyer un message signé ### et une transaction ( à 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 l'EOA.

EIP-4337 : mise en œuvre de l'abstraction de compte dans le pool de mémoire des transactions )2021-09-29(

Inspiré par le MEV, la valeur fondamentale est d'éviter complètement les modifications du protocole de couche de consensus.

EIP4337 propose un nouvel objet de transaction appelé UserOperation, que les utilisateurs envoient à la mémoire tampon, où les bundlers le regroupent et le livrent aux mineurs pour exécuter les transactions de contrat. En essence, cela déplace les transactions sous-jacentes et le fonctionnement des comptes au niveau des contrats.

EIP-5189 : opération d'abstraction de compte par un endosseur )2022-06-29(

Optimisation de la logique EIP4337, pour prévenir les attaques par blocage DoS face à des Bundlers malveillants grâce à l'établissement d'un mécanisme d'endossement de pénalités financières.

) 3.3 Autres propositions prenant en charge l'abstraction de compte

EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)

La proposition finalisée définit un nouveau type de transaction comme une enveloppe pour les futurs types de transactions ajoutés.

Le résultat final est qu'en introduisant un nouveau type de transaction, on peut le distinguer par un codage spécifique, en n'ayant besoin que de la compatibilité descendante, sans nécessiter de compatibilité montante. L'exemple le plus courant est l'EIP1559, qui distingue les frais de transaction, utilisant un codage de nouveau 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(

Solutions complémentaires sur le chemin AA, pour éviter les conflits entre les adresses de déploiement de contrat et les adresses EOA. Contrôle des méthodes de génération de contrat, le système n'autorise pas le déploiement de code à une adresse qui est déjà une adresse EOA. Ce risque est très faible, 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 la puissance de calcul totale de Bitcoin.

) 3.4 Comment comprendre l'évolution de l'abstraction de compte ?

Tout d'abord, il faut comprendre la valeur après la conversion en CA.

C'est essentiellement l'effet réel de l'EIP-4337, qui peut réaliser :

1. Paiement des frais de gaz avec n'importe quel jeton
2. Transactions en gros
3. Programmabilité des signatures
4. La logique du portefeuille peut être mise à niveau
5. Multi-signature et récupération sociale
6. transaction sans gas
7. Paiement de gaz programmable

Cependant, le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.

Cela semble meilleur, mais cela tombe dans un cycle mort de développement du marché. De nombreuses Dapps ne sont pas compatibles, les utilisateurs ne souhaitent pas utiliser l'adresse CA, et utiliser CA entraîne même des coûts de transaction plus élevés dans le scénario de transfert ordinaire, les frais de transaction doublent, trop dépendant de la compatibilité de la Dapp elle-même.

Donc, cela n'a jamais été largement répandu sur Ethereum mainnet jusqu'à présent.

Le coût est le critère de mesure le plus important pour les utilisateurs, il faut réduire les coûts.

Mais pour vraiment réduire le GAS, il faut que l'Ethereum lui-même effectue une mise à niveau de fork doux, en modifiant le calcul du GAS ou en modifiant les modules de consommation de GAS des codes d'opération. Puisqu'il s'agit d'un fork doux, 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

Grâce à un nouveau type de transaction, il est possible de distinguer et de permettre 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 autorisations personnalisée, le tout sans introduire de nouveaux opCode EVM ( affectant la compatibilité ascendante ).

permet aux utilisateurs d'obtenir la plupart des capacités d'AA sans déployer de contrats intelligents, et même de fournir à des tiers la capacité d'initier des transactions pour les utilisateurs, sans que ceux-ci aient besoin de fournir une clé privée, mais seulement une information d'autorisation signée.

( 4.2 structure de données

Définir un nouveau type de transaction 0x04, ce type de transaction 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, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s]###

Il est important d'ajouter un objet authorization_list, qui stocke le code que les signataires souhaitent exécuter dans leur EOA. L'utilisateur signe la transaction tout en signant également le code du contrat à exécuter, qui existe sous forme de liste bidimensionnelle, indiquant qu'il est possible de stocker plusieurs informations d'opération en vrac et d'exécuter des opérations en masse.

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

( 4.3 cycle de vie des transactions

)# 4.3.1 phase de validation

Exécution de la phase de début de transaction, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] de authorization_list :

1. Récupérer l'adresse du signataire ### à partir des signatures r, s en utilisant ecrecover selon le mécanisme d'Ethereum, cet EIP n'a pas modifié l'algorithme de signature (.
2. Vérifiez l'ID de la chaîne ) pour éviter la relecture de la chaîne de fork ###.
3. Vérifiez si le code du signataire authority est vide ou si ### a été délégué pour vérifier si la transaction est une transaction valide 7702, puis exécutez la transaction par la suite via le mécanisme de délégation (.
4. Vérifier la nonce du signataire authority ) pour prévenir la relecture de la signature authority (.
5. Définir le code de signataire authority à 0xef0100 || address) contourner la stratégie de prévention des collisions EIP3607 (.
6. Augmenter le nonce des signataires d'autorité ) pour prévenir la reproduction locale des signatures (.
7. Ajouter le compte signataire authority à la liste des adresses visitées ) pour l'adresse de transfert de chaleur, réduire les frais de gaz de stockage de requête (.

)# 4.3.2 Phase d'exécution des opérations