Analyse approfondie du passé et de l'avenir des comptes abstraits d'Ethereum
Cet article se compose de deux grandes parties :
Tout d'abord, en commençant par la première proposition AA de 2015, le système passe en revue le contenu principal des propositions EIP jusqu'à présent, en retraçant l'historique des propositions AA et en évaluant de manière globale les avantages et les inconvénients de chaque solution.
Deuxièmement, il convient de comparer les retours du marché morose auxquels l'EIP4337 est confronté, et d'analyser en profondeur l'EIP7702 qui sera inclus dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition fusionnée, elle changera complètement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, examinons cela en détail.
1. Contexte de l'abstraction du compte
1.1 Signification abstraite du 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 n'a pas changé la position de l'abstraction de compte. Le modèle dominant actuel passe de l'EIP-4337 à la prochaine étape de la 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, ( a été officiellement publié, ), et a été largement reconnu par les utilisateurs mais peu utilisé. Dans ce contexte de marché contradictoire, l'avancement de l'EIP-7702 a été considérablement accéléré, et il a été déterminé qu'il sera intégré lors de la prochaine mise à niveau.
1.2 État actuel du marché abstrait du compte
Après un an et demi de développement, l'EIP4337 ne compte 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 bien inférieur au nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions, on peut donc dire que l'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 était dès le départ vouée à ne pas bien 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 explosé sur L2, avec 1 million et 3 millions d'utilisateurs actifs respectivement sur les chaînes Base et Polygon en juillet, ce qui reste tout à fait considérable.
Ainsi, 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.
2. Qu'est-ce que l'abstraction de compte ?
L'abstraction de compte est essentiellement une solution au problème de la séparation des droits de propriété.
Il existe deux types de comptes dans la machine virtuelle Ethereum ( EVM ) : le compte externe ( EOA ) et le compte de contrat ( CA ). La propriété et le droit de signature de l'EOA sont en réalité détenus par le 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 de transaction du compte Ethereum. Dans la structure de transaction standard, il n'y a pas de champ From, le transfert de fonds est effectué via les paramètres VRS (, la signature de l'utilisateur ) permet de déduire l'adresse From. Cela a entraîné la difficulté actuelle de la 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, séparant ainsi la clé privée de l'adresse d'opération.
L'importance de la séparation des droits de propriété réside dans :
La clé privée est difficile à protéger : perdre la clé privée signifie perdre tous les actifs.
Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme ECDSA.
Autorisation de signature trop élevée : pas de multi-signature natif, 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 en tête-à-tête facilitent l'analyse des informations sur les détenteurs de compte.
Ces contraintes rendent difficile l'utilisation d'Ethereum pour les utilisateurs ordinaires :
L'utilisation de toute application nécessite de détenir de l'Éther et d'accepter le risque de fluctuation des prix.
Il est nécessaire de gérer une logique de frais complexe, les concepts de prix du gaz, de limite de gaz, de nonce, etc. sont trop complexes.
Bien que l'application de portefeuille tente d'optimiser l'expérience utilisateur, son efficacité est limitée.
Ainsi, la clé de la solution réside dans la réalisation 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.
3. Historique des propositions AA
La solution au problème semble avoir de nombreuses propositions EIP, mais au fond, il n'y a que deux approches principales. Les problèmes considérés dans chaque EIP non accepté ont finalement été intégrés dans les solutions existantes.
3.1 Première méthode : convertir l'adresse EOA en adresse CA
Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte utilisant des contrats dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, permettant de payer les frais de transaction avec des ERC20, et de convertir les jetons natifs en type ERC20 pour stocker des soldes via des contrats précompilés, en simplifiant les champs de transaction à uniquement to, startgas, data et code.
C'est une transformation de type grand bond en avant, qui va modifier en profondeur la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code". ( est également l'effet que l'EIP-7702 cherche à réaliser. ).
Peut également dériver d'autres fonctionnalités :
Les transactions utilisent plus d'algorithmes cryptographiques, avec la méthode de vérification des signatures spécifiée par le Code interne de l'adresse.
Possède des caractéristiques de résistance aux attaques quantiques, car le code est évolutif.
Rendre l'Éther capable d'avoir des fonctionnalités identiques à celles de l'ERC20, telles que l'autorisation de prélèvement.
Améliorer l'espace personnalisé du compte, compatible avec la récupération sociale, le support SBT, la récupération de clés, etc.
Les raisons pour lesquelles cela n'a pas été poursuivi sont également très simples, il est évident que le pas était trop grand, et qu'il n'y a pas eu une considération adéquate des problèmes de conflit de hash des transactions actuelles et des problèmes de sécurité, donc cela a été mis de côté. Mais chaque concept d'avantage est devenu l'une des fonctionnalités clés 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)
Essayer de résoudre le problème de déploiement de code. Si le contrat de la partie transactionnelle n'est pas déployé, utilisez le paramètre de code inclus dans la transaction pour exécuter le déploiement du portefeuille du contrat. Un nouvel opcode PAYGAS a également été proposé, qui, en plus de payer le gaz, sert également de séparateur entre la partie vérification et la partie exécution dans les paramètres de la transaction.
Bien que cela se soit terminé sans résultat à l'époque, cela est devenu l'une des logiques centrales de l'EIP7702. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut inclure un certain code, permettant à l'adresse EOA d'avoir des capacités de contrat lors de cette transaction.
EIP-7702 : définir le code du compte EOA (2024-05-07)
C'est le cœur de la discussion ultérieure de cet article, publié par Vitalik comme alternative à l'EIP-3074. L'EIP-3074 a été abandonné, l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra.
3.2 Deuxième option : faire en sorte que l'adresse EOA pilote l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL (2020-10-15)
Ajoutez deux nouveaux OpCodes dans l'EVM : AUTH et AUTHCALL, permettant aux EOA d'autoriser d'autres 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é ( à une transaction ) vers un contrat de confiance ( appelé Invoker ). Le contrat Invoker peut utiliser AUTH et AUTHCALL pour émettre des transactions à la place de l'EOA.
EIP-4337 : mise en œuvre de l'abstraction de compte via le pool de mémoire des transactions (2021-09-29)
Inspiré par 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 regroupent et livrent en masse les transactions d'exécution de contrats du point de vue des mineurs. Essentiellement, cela déplace l'exécution des transactions sous-jacentes et des opérations de compte au niveau des contrats.
EIP-5189 : opérations de compte abstrait par l'intermédiaire de l'endosseur (2022-06-29)
Optimisation de la logique EIP4337, en établissant un mécanisme de parrainage de sanctions financières (endorser) pour prévenir les attaques DoS malveillantes des Bundlers.
3.3 Autres propositions soutenant AA
EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)
La proposition déjà finalisée définit un nouveau type de transaction comme une enveloppe pour les futurs types de transaction ajoutés.
Lors de l'introduction d'un nouveau type de transaction, il est distingué par un codage spécifique, n'ayant besoin que de la compatibilité descendante sans nécessité de compatibilité montante. 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: interdire le déploiement de contrats par des adresses EOA (2021-06-10)
Solutions complémentaires sur le chemin AA, pour empêcher les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Contrôlez la méthode de génération de contrat, il n'est pas permis de déployer du code à une adresse déjà utilisée par une EOA. Ce risque est très faible, l'adresse Ethereum fait 160 bits de long, bien qu'il existe une méthode pour générer la clé privée d'une adresse de contrat spécifique par collision de clés privées, cela nécessiterait environ un an d'investissement avec l'ensemble de la puissance de calcul de Bitcoin.
3.4 Comment comprendre l'évolution de l'abstraction des comptes ?
Tout d'abord, il est nécessaire de comprendre la valeur après la conversion en CA.
C'est essentiellement l'effet pratique de l'EIP-4337, qui peut réaliser :
Récupération sociale
transaction sans gas
Transactions en vrac
Paiement des frais de gas
Compte verrouillé
Signature personnalisée
Mais le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Cela semble mieux, mais cela tombe dans un cercle vicieux de développement du marché : de nombreux Dapp ne sont pas encore compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et utiliser CA entraîne en fait des coûts de transaction plus élevés ( les frais de transaction pour les scénarios de transfert ordinaires doublent ), ce qui dépend trop de la compatibilité propre des Dapp.
Donc, il n'y a toujours pas eu de généralisation sur le réseau principal d'Ethereum jusqu'à présent.
Le coût est le critère de mesure le plus important pour les utilisateurs, il est donc nécessaire de réduire les coûts.
Pour vraiment réduire le GAS, il est nécessaire de procéder à une mise à niveau par soft fork d'Ethereum lui-même, en modifiant le calcul du GAS ou les modules de consommation de GAS des codes d'opération. Puisqu'un soft fork est envisagé, pourquoi ne pas directement considérer 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 permis aux EOA de disposer temporairement des fonctionnalités de contrat intelligent dans une seule transaction, prenant en charge les transactions en masse, les transactions sans Gas et la gestion des autorisations personnalisées, sans avoir besoin d'introduire un nouveau opCode EVM ( qui affecterait la compatibilité descendante ).
Permettre aux utilisateurs d'accéder à la plupart des capacités AA sans avoir à déployer de contrats intelligents, et même de fournir à des tiers la capacité d'initier des transactions au nom des utilisateurs, sans que ces derniers aient à fournir de clé privée, il suffit de signer les informations d'autorisation.
4.2 structure de données
Définir un nouveau type de transaction 0x04, le TransactionPayload est le résultat de la sérialisation RLP du contenu suivant :
Il est important de noter qu'un nouvel objet authorization_list a é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 à deux dimensions, permettant de stocker plusieurs informations d'opération et d'exécuter des opérations en masse.
Phase de démarrage de l'exécution des transactions, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] de authorization_list:
Récupérer l'adresse du signataire à partir des signatures r et s en utilisant ecrecover.
Vérifier l'ID de chaîne ( pour éviter la relecture de la chaîne de fork ).
Vérifiez si le code du signataire de l'autorité est vide ou a délégué ( pour vérifier si la transaction est une transaction valide 7702 ).
Vérifier le nonce du signataire authority( pour éviter la répétition de la signature authority).
Définissez le code de signataire authority sur 0xef0100 || address( pour contourner la stratégie de prévention des collisions EIP3607).
Augmenter le nonce du signataire authority( pour éviter la répétition de signatures partielles).
Ajouter le compte du 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
La nouvelle version ne change que le comportement de déploiement du code.
Ne définissez plus le code du compte comme contract_code, mais récupérez l'adresse du code dans authorization_list et définissez-le comme code du compte.
Lors de l'exécution du code autorisé, chargez le code à partir du champ address de authorization_list, et exécutez-le dans le contexte du compte du signataire.
Le code des contrats utilisateurs est réellement stocké à une adresse spécifique sur la chaîne, et n'est pas directement inclus dans la transaction.
Les instructions d'opération et les paramètres associés sont stockés dans le champ data de la charge utile de la transaction.
4.4 La valeur de l'EIP-7702
Des changements ont eu lieu sur l'ensemble de la chaîne du portefeuille Web3, expérience utilisateur.
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.
21 J'aime
Récompense
21
4
Partager
Commentaire
0/400
CommunityLurker
· 07-16 07:30
Encore parler de Blockchain qui change le monde.
Voir l'originalRépondre0
BearHugger
· 07-14 19:01
Encore une fois, c'est le quotidien de V God qui dessine des BTC.
Voir l'originalRépondre0
StableNomad
· 07-14 18:40
on dirait un déjà-vu de 2021... un autre "eip révolutionnaire" qui aura probablement un taux d'adoption de 0,001 % à vrai dire
EIP-7702 analyse : une nouvelle ère d'abstraction de compte et amélioration des capacités EOA
Analyse approfondie du passé et de l'avenir des comptes abstraits d'Ethereum
Cet article se compose de deux grandes parties :
Tout d'abord, en commençant par la première proposition AA de 2015, le système passe en revue le contenu principal des propositions EIP jusqu'à présent, en retraçant l'historique des propositions AA et en évaluant de manière globale les avantages et les inconvénients de chaque solution.
Deuxièmement, il convient de comparer les retours du marché morose auxquels l'EIP4337 est confronté, et d'analyser en profondeur l'EIP7702 qui sera inclus dans la prochaine mise à niveau d'Ethereum. Une fois cette proposition fusionnée, elle changera complètement la forme des applications sur la chaîne.
EIP-7702 a une signification révolutionnaire, examinons cela en détail.
1. Contexte de l'abstraction du compte
1.1 Signification abstraite du 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 n'a pas changé la position de l'abstraction de compte. Le modèle dominant actuel passe de l'EIP-4337 à la prochaine étape de la 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, ( a été officiellement publié, ), et a été largement reconnu par les utilisateurs mais peu utilisé. Dans ce contexte de marché contradictoire, l'avancement de l'EIP-7702 a été considérablement accéléré, et il a été déterminé qu'il sera intégré lors de la prochaine mise à niveau.
1.2 État actuel du marché abstrait du compte
Après un an et demi de développement, l'EIP4337 ne compte 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 bien inférieur au nombre d'adresses EOA et CA. Le nombre d'adresses indépendantes sur le réseau principal Ethereum a atteint 270 millions, on peut donc dire que l'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 était dès le départ vouée à ne pas bien 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 explosé sur L2, avec 1 million et 3 millions d'utilisateurs actifs respectivement sur les chaînes Base et Polygon en juillet, ce qui reste tout à fait considérable.
Ainsi, 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.
2. Qu'est-ce que l'abstraction de compte ?
L'abstraction de compte est essentiellement une solution au problème de la séparation des droits de propriété.
Il existe deux types de comptes dans la machine virtuelle Ethereum ( EVM ) : le compte externe ( EOA ) et le compte de contrat ( CA ). La propriété et le droit de signature de l'EOA sont en réalité détenus par le 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 de transaction du compte Ethereum. Dans la structure de transaction standard, il n'y a pas de champ From, le transfert de fonds est effectué via les paramètres VRS (, la signature de l'utilisateur ) permet de déduire l'adresse From. Cela a entraîné la difficulté actuelle de la 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, séparant ainsi la clé privée de l'adresse d'opération.
L'importance de la séparation des droits de propriété réside dans :
La clé privée est difficile à protéger : perdre la clé privée signifie perdre tous les actifs.
Algorithme de signature unique : la vérification des transactions par le protocole natif ne peut utiliser que l'algorithme ECDSA.
Autorisation de signature trop élevée : pas de multi-signature natif, 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 en tête-à-tête facilitent l'analyse des informations sur les détenteurs de compte.
Ces contraintes rendent difficile l'utilisation d'Ethereum pour les utilisateurs ordinaires :
Ainsi, la clé de la solution réside dans la réalisation 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.
3. Historique des propositions AA
La solution au problème semble avoir de nombreuses propositions EIP, mais au fond, il n'y a que deux approches principales. Les problèmes considérés dans chaque EIP non accepté ont finalement été intégrés dans les solutions existantes.
3.1 Première méthode : convertir l'adresse EOA en adresse CA
Le 15 novembre 2015, Vitalik a proposé une nouvelle structure de compte utilisant des contrats dans l'EIP-101. L'adresse a été modifiée pour ne contenir que du code et de l'espace de stockage, permettant de payer les frais de transaction avec des ERC20, et de convertir les jetons natifs en type ERC20 pour stocker des soldes via des contrats précompilés, en simplifiant les champs de transaction à uniquement to, startgas, data et code.
C'est une transformation de type grand bond en avant, qui va modifier en profondeur la conception sous-jacente, permettant à chaque adresse de compte d'avoir sa propre logique de "code". ( est également l'effet que l'EIP-7702 cherche à réaliser. ).
Peut également dériver d'autres fonctionnalités :
Les raisons pour lesquelles cela n'a pas été poursuivi sont également très simples, il est évident que le pas était trop grand, et qu'il n'y a pas eu une considération adéquate des problèmes de conflit de hash des transactions actuelles et des problèmes de sécurité, donc cela a été mis de côté. Mais chaque concept d'avantage est devenu l'une des fonctionnalités clés 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)
Essayer de résoudre le problème de déploiement de code. Si le contrat de la partie transactionnelle n'est pas déployé, utilisez le paramètre de code inclus dans la transaction pour exécuter le déploiement du portefeuille du contrat. Un nouvel opcode PAYGAS a également été proposé, qui, en plus de payer le gaz, sert également de séparateur entre la partie vérification et la partie exécution dans les paramètres de la transaction.
Bien que cela se soit terminé sans résultat à l'époque, cela est devenu l'une des logiques centrales de l'EIP7702. Chaque transaction de l'EIP7702, combinée à une structure de transaction spéciale, peut inclure un certain code, permettant à l'adresse EOA d'avoir des capacités de contrat lors de cette transaction.
EIP-7702 : définir le code du compte EOA (2024-05-07)
C'est le cœur de la discussion ultérieure de cet article, publié par Vitalik comme alternative à l'EIP-3074. L'EIP-3074 a été abandonné, l'EIP-7702 sera inclus dans le prochain hard fork ETH Prague/Electra.
3.2 Deuxième option : faire en sorte que l'adresse EOA pilote l'adresse CA
EIP-3074 : ajout des codes d'opération AUTH et AUTHCALL (2020-10-15)
Ajoutez deux nouveaux OpCodes dans l'EVM : AUTH et AUTHCALL, permettant aux EOA d'autoriser d'autres 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é ( à une transaction ) vers un contrat de confiance ( appelé Invoker ). Le contrat Invoker peut utiliser AUTH et AUTHCALL pour émettre des transactions à la place de l'EOA.
EIP-4337 : mise en œuvre de l'abstraction de compte via le pool de mémoire des transactions (2021-09-29)
Inspiré par 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 regroupent et livrent en masse les transactions d'exécution de contrats du point de vue des mineurs. Essentiellement, cela déplace l'exécution des transactions sous-jacentes et des opérations de compte au niveau des contrats.
EIP-5189 : opérations de compte abstrait par l'intermédiaire de l'endosseur (2022-06-29)
Optimisation de la logique EIP4337, en établissant un mécanisme de parrainage de sanctions financières (endorser) pour prévenir les attaques DoS malveillantes des Bundlers.
3.3 Autres propositions soutenant AA
EIP-2718 : enveloppe de nouveau type de transaction (2020-06-13)
La proposition déjà finalisée définit un nouveau type de transaction comme une enveloppe pour les futurs types de transaction ajoutés.
Lors de l'introduction d'un nouveau type de transaction, il est distingué par un codage spécifique, n'ayant besoin que de la compatibilité descendante sans nécessité de compatibilité montante. 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: interdire le déploiement de contrats par des adresses EOA (2021-06-10)
Solutions complémentaires sur le chemin AA, pour empêcher les conflits entre l'adresse de déploiement du contrat et l'adresse EOA. Contrôlez la méthode de génération de contrat, il n'est pas permis de déployer du code à une adresse déjà utilisée par une EOA. Ce risque est très faible, l'adresse Ethereum fait 160 bits de long, bien qu'il existe une méthode pour générer la clé privée d'une adresse de contrat spécifique par collision de clés privées, cela nécessiterait environ un an d'investissement avec l'ensemble de la puissance de calcul de Bitcoin.
3.4 Comment comprendre l'évolution de l'abstraction des comptes ?
Tout d'abord, il est nécessaire de comprendre la valeur après la conversion en CA.
C'est essentiellement l'effet pratique de l'EIP-4337, qui peut réaliser :
Mais le principal inconvénient de l'EIP-4337 est qu'il va à l'encontre du principe de motivation humaine.
Cela semble mieux, mais cela tombe dans un cercle vicieux de développement du marché : de nombreux Dapp ne sont pas encore compatibles, les utilisateurs ne veulent pas utiliser d'adresses CA, et utiliser CA entraîne en fait des coûts de transaction plus élevés ( les frais de transaction pour les scénarios de transfert ordinaires doublent ), ce qui dépend trop de la compatibilité propre des Dapp.
Donc, il n'y a toujours pas eu de généralisation sur le réseau principal d'Ethereum jusqu'à présent.
Le coût est le critère de mesure le plus important pour les utilisateurs, il est donc nécessaire de réduire les coûts.
Pour vraiment réduire le GAS, il est nécessaire de procéder à une mise à niveau par soft fork d'Ethereum lui-même, en modifiant le calcul du GAS ou les modules de consommation de GAS des codes d'opération. Puisqu'un soft fork est envisagé, pourquoi ne pas directement considérer 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 permis aux EOA de disposer temporairement des fonctionnalités de contrat intelligent dans une seule transaction, prenant en charge les transactions en masse, les transactions sans Gas et la gestion des autorisations personnalisées, sans avoir besoin d'introduire un nouveau opCode EVM ( qui affecterait la compatibilité descendante ).
Permettre aux utilisateurs d'accéder à la plupart des capacités AA sans avoir à déployer de contrats intelligents, et même de fournir à des tiers la capacité d'initier des transactions au nom des utilisateurs, sans que ces derniers aient à fournir de clé privée, il suffit de signer les informations d'autorisation.
4.2 structure de données
Définir un nouveau type de transaction 0x04, 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, liste_d'accès, authorization_list, signature_y_parity, signature_r, signature_s ])
Il est important de noter qu'un nouvel objet authorization_list a é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 à deux dimensions, permettant de stocker plusieurs informations d'opération et d'exécuter des opérations en masse.
authorization_list = [[chain_id, adresse, nonce, y_parité, r, s], ...]
4.3 Cycle de vie des transactions
4.3.1 Phase de vérification
Phase de démarrage de l'exécution des transactions, pour chaque tuple [chain_id, address, nonce, y_parity, r, s] de authorization_list:
Récupérer l'adresse du signataire à partir des signatures r et s en utilisant ecrecover.
Vérifier l'ID de chaîne ( pour éviter la relecture de la chaîne de fork ).
Vérifiez si le code du signataire de l'autorité est vide ou a délégué ( pour vérifier si la transaction est une transaction valide 7702 ).
Vérifier le nonce du signataire authority( pour éviter la répétition de la signature authority).
Définissez le code de signataire authority sur 0xef0100 || address( pour contourner la stratégie de prévention des collisions EIP3607).
Augmenter le nonce du signataire authority( pour éviter la répétition de signatures partielles).
Ajouter le compte du 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
La nouvelle version ne change que le comportement de déploiement du code.
Ne définissez plus le code du compte comme contract_code, mais récupérez l'adresse du code dans authorization_list et définissez-le comme code du compte.
Lors de l'exécution du code autorisé, chargez le code à partir du champ address de authorization_list, et exécutez-le dans le contexte du compte du signataire.
Le code des contrats utilisateurs est réellement stocké à une adresse spécifique sur la chaîne, et n'est pas directement inclus dans la transaction.
Les instructions d'opération et les paramètres associés sont stockés dans le champ data de la charge utile de la transaction.
4.4 La valeur de l'EIP-7702
Des changements ont eu lieu sur l'ensemble de la chaîne du portefeuille Web3, expérience utilisateur.