Background

EOA vs Contract

Account Externally Owned Account (EOA) et Contract Account sont deux types de compte définis dans le livre blanc Ethereum. Les comptes EOA sont contrôlés par des clés privées et les utilisateurs peuvent signer diverses transactions via les clés privées pour contrôler les actifs du compte. Le contrat compte est contrôlé par le code de l’compte lui-même, et d’autres comptes peuvent faire en sorte que le contrat compte exécuter une logique spécifique en appelant le code du contrat compte.

Abstraction

de compte Le concept de comptes abstraits remonte à 2016 (https://github.com/ethereum/EIPs/issues/86). Le abstraction de compte est basé sur les deux types de compte actuels de Ethereum : les comptes EOA et les comptes contractuels. Cela améliorera l’expérience interactive des utilisateurs d’Ethereum par les moyens suivants :

1. Permet aux utilisateurs d’utiliser plusieurs signatures, telles que Schnorr, BLS, signatures post-quantiques, etc.
2. Permet aux utilisateurs de payer des frais de gas en utilisant des jetons ERC20 ou une logique de paiement personnalisée ;
3. Permet aux utilisateurs de récupérer leurs comptes en utilisant le courrier électronique, les médias sociaux, etc.
4. Permet aux utilisateurs de gérer les fonds de leurs comptes avec des autorisations précises, telles que la définition d’une limite de retrait quotidienne ;
5. Permet d’effectuer plusieurs opérations off-chain dans une seule transaction atomique. Par exemple, un utilisateur peut effectuer les opérations d’approbation et d’échange dans une transaction DEX avec une signature.

Ethereum Feuille

de route La feuille de route Ethereum (https://ethereum.org/en/roadmap/) met en évidence la future voie de mise à niveau de Ethereum. Actuellement, la plupart des recherches dans la communauté Ethereum tournent autour de la feuille de route Ethereum. L’abstraction des comptes en est un élément impératif :

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

La communauté Ethereum espère s’appuyer sur ERC-4337 et mettre en œuvre des solutions d’abstraction de compte au sein du protocole, grâce à des propositions telles que EIP-3074 ou EIP-7702, et enfin atteindre l’abstraction de compte de fin de partie.

Malgré l’amélioration de l’expérience utilisateur, Endgame abstraction de compte est également crucial pour l’informatique anti-quantique de Ethereum, car l’algorithme de ECDSA utilisé par l’EOA actuelle compte n’est pas sûr à l’ère de l’informatique quantique. L’adoption de l’abstraction de compte prend en charge les signatures post-quantiques qui protègent les comptes d’utilisateurs contre les menaces en constante évolution de l’informatique quantique.

EIP-3074 vs ERC-4337

Pour comprendre compte comptes abstraits, nous devons comprendre le fonctionnement de l’EOA. L’image ci-dessous est le processus d’achat et de vente de jetons le plus courant sur la chaîne :

D’une manière générale, les utilisateurs doivent effectuer deux transactions lors de l’achat et de la vente : autoriser d’abord Uniswap à transférer leurs USDC pour l’échange, puis envoyer une autre demande de transaction pour qu’Uniswap exécute l’action. Uniswap transfère le USDC de l’utilisateur compte et envoie le montant de ETH correspondant à l’utilisateur en fonction du prix actuel.

ERC-4337 fusionne les deux transactions ci-dessus en une seule :

Comme on peut le voir sur la figure ci-dessus, l’utilisateur doit signer deux fois pour autoriser le bundler à exploiter les ressources de l’utilisateur dans le compte 4337, qui est différent du compte EOA de l’utilisateur. Une fois que le bundler a obtenu l’autorisation, il fusionne le contenu autorisé dans un bundle et l’émet pour terminer la transaction. Dans le même temps, si l’utilisateur n’a pas de jetons Ethereum pour les frais de gaz, le rôle de paymaster peut également être introduit, permettant au paymaster de payer les frais de gas et d’obtenir des jetons ERC20 de valeur égale de l’utilisateur.

EIP-3074 et ERC-4337 ont quelques similitudes, mais la méthode d’implémentation d’EIP-3074 est dans le protocole d’Ethereum :

Dans ERC-4337, nous autorisons Bundler à gérer les actifs de notre portefeuille de contrats intelligents off-chain par le biais de signatures. Dans EIP-3074, le bundler est autorisé à gérer directement les actifs de notre portefeuille EOA par le biais de signatures. Pour ordre ce faire, la communauté Ethereum doit ajouter deux nouveaux opcodes au Ethereum protocole : AUTH et AUTHCALL.

AUTH est utilisé pour vérifier si le comportement du bundler de traitement des ressources compte EOA de l’utilisateur est autorisé, et AUTHCALL est utilisé pour « tromper » le contrat intelligent d’interaction de l’utilisateur (dans notre exemple, USDC et Uniswap), faisant croire au contrat intelligent que la transaction provient de l’EOA compte de l’utilisateur. L’avantage est que les mainteneurs d’Uniswap et d’USDC n’ont pas besoin de mettre à niveau les contrats intelligents déployés, et en même temps, les comptes EOA peuvent profiter des fonctions d’abstraction de compte.

Une comparaison entre EIP-3074 et ERC-4337

Dans la communauté Ethereum, EIP fait généralement référence aux propositions qui nécessitent la prise en charge de mises à niveau Ethereum, tandis que l’ERC fait référence aux spécifications qui peuvent être prises en charge sans Ethereum mises à niveau.

Par conséquent, on peut voir à partir de la dénomination des deux schémas d’abstraction de compte que ERC-4337 est plus facile à mettre en œuvre que EIP-3074, car ERC-4337 ne nécessite pas de fork dur du réseau Ethereum. C’est aussi l’une des raisons pour lesquelles ERC-4337 a été lancé et est de plus en plus utilisé sur polygone et base, mais EIP-3074 vient d’être accepté par le 183e Ethereum All Core Developers Execution Call (ACDE).

Source : https://dune.com/niftytable/account-abstraction

De plus, ERC-4337 exige que les utilisateurs migrent leurs comptes courants vers de nouveaux comptes contractuels et nécessite DApp support pour que EIP-1271 fonctionne. EIP-3074 ne nécessite pas ces soutiens supplémentaires. C’est l’une des principales raisons du faible taux d’adoption de l’ERC-4337. Dans le même temps, ERC-4337 ne peut pas support une signature pour autoriser plusieurs opérations on-chain sans introduire un contrat multi-appels intermédiaire, mais EIP-3074 le peut, ce qui entraîne également les limitations de ERC-4337.

Cependant, EIP-3074 a aussi ses propres problèmes. Le plus important est que le code d’opération AUTH a des comptes trop élevés, ce qui peut permettre à l’attaquant de contrôler complètement le compte EOA de l’utilisateur. Après tout, aussi longue qu’un pirate fraude votre signature AUTH, il peut disposer des actifs de votre portefeuille EOA. Étant donné que les attaques de phishing sont actuellement endémiques et que la plupart d’entre elles trompent les signatures des utilisateurs, une fois que EIP-3074 sera mis en œuvre, cela deviendra un problème plus grave.

À cet égard, lightclient, l’un des auteurs de EIP-3074, a proposé une méthode d’atténuation pour intercepter les signatures malveillantes au niveau du portefeuille. Pour plus de détails, veuillez vous référer à : https://x.com/lightclients/status/1778823652584120497. ERC-4337 n’a pas ce problème, bien que les pirates puissent toujours tromper les utilisateurs pour qu’ils signent des UserOps malveillants. Cela est dû à la difficulté pour un UserOp d’obtenir l’autorité de disposition sur tous les actifs du compte utilisateur. Au moment de la rédaction de cet article, les développeurs d’ACDE ont accepté de supprimer EIP-3704 de Pectra Devent 0 et d’inclure EIP-7702 dans le prochain Pectra Devnet 1.

Solana Adresse dérivé du programme

h2 id="h2-compte-abstraction-on-solana">L’abstraction du compte sur Solana

abstraction de compte de Solana est similaire à l’ERC-4337 de Ethereum. Il s’agit de comptes dérivés des comptes d’origine (similaires aux comptes EOA), semblables aux comptes de contrat 4337. Avant de comprendre l’abstraction de compte de Solana, il est nécessaire de comprendre le modèle de compte utilisé par Solana.

D’une manière générale, les comptes peuvent être classés comme des comptes exécutables qui peuvent exécuter du code ou des comptes non exécutables qui ne sont pas en mesure de le faire. En examinant cela plus en profondeur, il existe trois types de comptes sur Solana : Programme natif, Compte programme et Compte de données.

Les programmes natifs font partie de la mise en œuvre du validateur et fournissent des fonctions de base pour le réseau Solana, telles que la création de nouveaux comptes de données et de programmes personnalisés. Les comptes de programme sont des programmes personnalisés qui contiennent du code exécutable. Les comptes de données peuvent stocker des données et gérer l’état du programme tel que défini par le compte de programme de son propriétaire.

Ce modèle de compte permet nativement aux comptes de programme de créer et de gérer des comptes spécifiques, offrant aux développeurs la possibilité de définir des règles et une logique personnalisées pour les gérer. Grâce à ce modèle compte, le Adresse dérivé du programme (PDA), un type de compte de données, étend les possibilités de abstraction de compte capacités sur Solana, de l’amélioration de la sécurité des utilisateurs grâce à des portefeuilles multisig et à l’authentification à deux facteurs, à l’activation de mécanismes de récupération sociale, entre autres.

Program Derived Adresse

Pour le contexte, tous les comptes se trouvent sur la courbe Ed25519 et ont une paire de clés publique-privée. Le PDA, qui se trouve en dehors de la courbe Ed25519, est une chaîne de 32 octets dérivée de manière déterministe qui ressemble à une clé publique et n’est pas fournie avec une clé privée correspondante. Les PDA permettent aux développeurs de créer des règles personnalisées et des mécanismes de signature de transaction qui peuvent permettre au propriétaire du programme compte du PDA d’effectuer de manière autonome des transactions au nom des PDA, entièrement reconnus et pris en charge par le réseau Solana.

PDA et abstraction de compte

Maintenant que nous comprenons comment les PDA sont dérivés, vous vous demandez peut-être comment ces concepts sont liés à abstraction de compte. L’abstraction de compte se produit sous le capot grâce à l’exécution d’une fonction connue sous le nom d’appel interprogramme (CPI).

Les CPI sont des fonctions qui permettent à un programme d’invoquer les instructions d’un autre programme, ce qui permet la composabilité des programmes Solana. Lorsqu’un programme lance un CPI soit par le biais d’invoke_signed, les programmes peuvent signer au nom des PDA dérivés.

La source : Solana

Pour vérifier la légitimité des transactions impliquant des PDA, Solana environnement d’exécution appelle le create_program_address en interne à l’aide de la signers_seeds et de la program_id du programme appelant. Si un PDA valide est trouvé, le runtime associe le PDA au programme appelant et reconnaît le programme en tant que signataire autorisé.

Actuellement, Squads développe une solution d’abstraction de compte sur Solana basée sur PDA. Cependant, le produit fourni par Squads s’apparente actuellement davantage à la solution de compte de contrats intelligents de Gnosis Safe et n’a pas encore complètement développé ses fonctionnalités abstraction de compte.

Avantages des PDA

1. Exécution automatisée des contrats intelligents : les PDA permettent des conceptions de contrats intelligents plus complexes qui peuvent effectuer de manière autonome plusieurs opérations pour le compte de l’utilisateur par le biais d’appels interprogrammes.
2. Amélioration de l’expérience utilisateur : les utilisateurs n’ont pas besoin de gérer plusieurs transactions ou d’être exposés à la complexité technique.
3. Sécurité et flexibilité accrues : sans clé privée, cela réduit le risque de compromission de la clé. Les PDA peuvent être utilisés pour les portefeuilles multisig ou s’adapter à d’autres modèles de gouvernance flexibles qui réduisent un seul point de risque et sont particulièrement utiles pour les organisations qui gèrent de grandes ressources partagées.

Limitations des PDA

1. Les PDA, bien qu’utiles pour jeter les bases des capacités d’abstraction de compte, peuvent être complexes à mettre en œuvre par rapport à un compte de paires de clés.
2. Et comme ERC-4337, il oblige les utilisateurs à effectuer compte migration vers un nouveau compte ce qui peut supprimer le taux d’adoption de Solana abstraction de compte.

Cosmos x/authz

Avec abstraction de compte qui prend de plus en plus la part de l’esprit des développeurs, authz, qui fait partie du SDK Cosmos de base, a été lancé pour permettre à un compte d’effectuer certaines actions pour le compte d’un autre compte grâce à l’utilisation d’autorisations similaires aux EIP-3074 et EIP-7702.

Authz est livré avec plusieurs types d’autorisation prédéfinis qui délèguent l’exécution de certaines actions telles que le jalonnement à un bénéficiaire, améliorant ainsi l’expérience utilisateur.

Avec authz, 3 types d’autorisations peuvent être accordés :

1. GenericAuthorization.GenericAuthorization. Cette autorisation accorde au bénéficiaire l’autorisation illimitée d’exécuter le message au nom du concédant.
2. SendAuthorization. Cette autorisation, comme l’approbation de l’ERC20, vise à donner au bénéficiaire l’accès à une limite de dépenses positive qui définit le montant maximum qui peut être dépensé pour le compte du donateur.
3. StakeAuthorization. Cette subvention permet aux bénéficiaires de gérer des actions de jalonnement telles que déléguer, déléguer ou redéléguer au nom de l’octroi.

Une subvention se compose des octets d’adresse du donateur, des octets d’adresse des bénéficiaires et des types d’autorisation. Une période de temps peut également être définie pour limiter les autorisations au cours d’une période spécifique. À la fin de chaque bloc, le réseau supprime les autorisations expirées par le biais d’un processus appelé élagage.

Comprendre le cadre opérationnel

Authz peut être utilisé pour donner des autorisations pour une variété d’actions, mais pour simplifier, nous examinerons comment authz fonctionne pour permettre des transactions de vote génériques.

1. Implémente l’interface d’autorisation avant que les autorisations ne puissent être exécutées. À ce stade, le type de message sera également défini, qui dans ce cas sera MsgVote. Ici, nous voyons une autorisation de subvention d’Alice pour une action de vote de gouvernance.
2. Bob génère une transaction de vote non signé.
3. Bob génère une transaction signée et exécutée du vote du bénéficiaire. La transaction est terminée et l’autorisation sera retirée si elle a expiré.

Quels sont les avantages d’authz ?

1. Sécurité opérationnelle : les validateurs et les autres utilisateurs peuvent accorder des autorisations à un compte distinct pour voter sur des propositions de gouvernance ou effectuer certaines actions, ce qui améliore la sécurité compte et réduit la charge de sécurité.
2. Opérations rationalisées : les transactions peuvent être effectuées avec un accès aux clés de validation, les transactions de portefeuille multisig peuvent également être rationalisées à l’aide d’une seule transaction pour accorder des Authz au bénéficiaire compte.
3. Aucune migration n’est nécessaire : comme pour EIP-3074 et EIP-7702, les opérations d’autorisation se produisent dans le compte d’origine de l’utilisateur. Les utilisateurs n’ont pas besoin de transférer leurs ressources de la compte d’origine vers une nouvelle compte pour activer abstraction de compte.
4. Efficacité opérationnelle et flexibilité de la DAO : Un sous-ensemble de droits d’exécution peut être accordé à des membres individuels de la DAO pour des actions spécifiques.
5. Staking Reward Compounding : Authz facilite l’utilisation du retaking et des services équivalents pour la composition automatisée des récompenses de staking.

Limitations et risques pour Authz :

Faites attention aux types de transactions que vous autorisez via Authz. Une autorisation malveillante peut exécuter différents types d’autorisations qui pourraient être préjudiciables à l’utilisateur.

1. GenericAuthorization : donne l’autorisation illimitée d’exécuter le msg fourni pour le compte de l’octroyeur. À moins d’être pleinement conscient de ce que vous signez, il est fortement conseillé d’éviter de signer de tels types d’autorisation. Certains portefeuilles peuvent également ne pas fournir d’avertissements lors de la signature de transactions Authz.
2. SendAuthorization : permet au bénéficiaire d’envoyer le montant maximal de jetons qu’il peut dépenser s’il n’est pas spécifié par le concédant. Il est également important de vérifier la liste d’autorisation qui spécifie l’adresse spécifique à laquelle le bénéficiaire peut envoyer les jetons.

Module d’octroi de frais

Un autre obstacle à l’expérience utilisateur qui en a frustré plus d’un est la nécessité pour les utilisateurs de blockchains de détenir divers jetons natifs en ordre d’interagir avec ces différents écosystèmes. Cela a entaché l’expérience globale de l’utilisateur, en particulier pour les personnes non natives de la crypto qui ont été exposées pour la première fois à une myriade de chaînes existantes sur l’écosystème Cosmos.

Cependant, cet obstacle a connu une percée avec l’intégration du module d’octroi de frais. Semblable au contrat paymaster qui permet l’abstraction de compte sur Ethereum, le module d’octroi de frais sur Cosmos permet au concédant d’accorder des allocations de frais au bénéficiaire, en payant une partie ou la totalité des frais de transaction. Les fonds restent sous le contrôle du donateur et celui-ci peut révoquer l’allocation de subvention à tout moment.

Types de subventions pour frais de scolarité

L’allocation de frais peut être classée en deux types : l’allocation de base et l’allocation périodique.

BasicAllowance permet au bénéficiaire d’utiliser les comptes du concédant jusqu’à ce que la limite de dépenses ou l’heure d’expiration soit atteinte. La subvention sera alors résiliée par l’État. Il est important de noter que BasicAllowance met en œuvre une subvention unique de frais. Si la limite de dépenses et le temps sont vides, il n’y a pas de limite d’expiration et de dépenses sur l’allocation de frais.

PeriodicAllowance permet de renouveler périodiquement les subventions de frais après chaque période spécifiée. Period_spend_limit spécifie le nombre maximum de pièces pouvant être dépensées au cours de la période. Period_reset garde une trace du moment où la prochaine période devrait se produire et period_can_spend suit la quantité de pièces restantes avant le début d’une nouvelle période.

Comprendre le cadre opérationnel

L’utilisation de AllowedMsgAllowance crée une allocation pour les types de message spécifiés. L’allocation peut être BasicAllowance ou PeriodicAllowance. Si l’heure d’expiration est définie, FeeAllowance est mis en file d’attente dans l’état avec le préfixe d’expiration ajouté à l’octroi et Endblocker vérifie l’état FeeAllowanceQueue pour les autorisations expirées, en élaguant celles qui sont trouvées. Outre MsgGrantAllowance, une allocation de frais peut également être révoquée à l’aide de MsgRevokeAllowance.

Ensemble, les modules Authz et Fee Grant ouvrent la voie à des cas d’utilisation innovants et diversifiés qui permettent d’améliorer l’expérience utilisateur dans l’écosystème Cosmos.

Conclusion

Abstraction du compte Au 27 mai 2024, les chiffres sont estimés.

Avec l’approbation des ETF BTC au comptant et des ETF ETH, la demande institutionnelle et de détail a considérablement augmenté, promettant d’inaugurer une nouvelle vague d’utilisateurs cherchant à s’exposer à l’industrie. L’abstraction des comptes deviendra un récit important cette année, car les protocoles et les dapps cherchent à créer une expérience transparente pour élargir leurs communautés.

DISCLAIMER

Ce document est fourni à titre d’information générale uniquement et ne constitue pas, ni ne doit être interprété comme, toute forme de résultat de recherche, de conseil professionnel, de sollicitation, d’offre, de recommandation ou de stratégie de trading. Aucune garantie, représentation, garantie ou engagement, explicite ou implicite, n’est donné quant à l’équité, l’exactitude, l’actualité, l’exhaustivité ou l’exactitude des informations financières et de marché, des analyses et/ou des opinions générales fournies dans ce rapport, et aucune responsabilité n’est acceptée par HashKey Capital en ce qui concerne l’utilisation ou la confiance accordée à ces informations. Toute information contenue dans ce rapport est susceptible d’être modifiée sans préavis. Ce rapport n’a pas été examiné par la Securities and Futures Commission de Hong Kong, l’Autorité monétaire de Singapour ou toute autre autorité de réglementation de Hong Kong ou de Singapour.

Veuillez noter que les actifs numériques, y compris les crypto-monnaies, sont très volatils et soumis à des risques de marché. La valeur des actifs numériques peut fluctuer considérablement et il n’y a aucune garantie de profit ou de préservation du capital. Vous devez examiner attentivement votre propre tolérance au risque et votre situation financière avant de prendre une décision.

La distribution de ce rapport peut être restreinte dans certaines juridictions. Ce matériel ne constitue pas la distribution d’informations ou la réalisation d’une offre ou d’une sollicitation par une juridiction dans laquelle une telle action n’est pas autorisée ou à toute personne à qui il est illégal de distribuer un tel rapport.

Restez à jour avec les dernières nouvelles de HashKey Capital -

Site Web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

Medium]. Tous les droits d’auteur appartiennent à l’auteur original [Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.