Introduction

Le passage des comptes détenus en externe (EOA) aux comptes de contrats intelligents (SCA) gagne du terrain et a été adopté par de nombreux enthousiastes, y compris Vitalik lui-même. Malgré cet engouement, l'adoption des SCA n'est pas aussi répandue que celle des EOA. Les principaux sont les défis posés par les marchés baissiers, les problèmes de migration, les problèmes de signature, les frais généraux liés au gaz et, surtout, les difficultés d'ingénierie.

L'avantage le plus important des Abstractions de comptes (AA) est la possibilité d'utiliser du code pour personnaliser les fonctionnalités. Cependant, l'un des principaux défis techniques est la non-interopérabilité des fonctionnalités des AA, et la fragmentation entrave l'intégration et ouvre la porte à l'enfermement dans le fournisseur. En outre, assurer la sécurité tout en mettant à jour et en composant des fonctionnalités peut s'avérer complexe.

L'abstraction modulaire des comptes est un sous-ensemble du mouvement AA plus large. Cette approche innovante permet de séparer les comptes intelligents de leurs fonctions personnalisées. L'objectif est de créer une structure modulaire permettant de développer des portefeuilles sécurisés, intégrés de manière transparente et dotés de diverses fonctionnalités. À l'avenir, elle pourrait créer un "magasin d'applications" gratuit pour les comptes de contrats intelligents, qui libérerait les portefeuilles et les dApps des fonctions de construction et se concentrerait sur l'expérience de l'utilisateur.

Après avoir lu cet article, les lecteurs pourront se faire une idée de ce qui suit :

1. Qu'est-ce que l'abstraction modulaire des comptes ?
2. Comment le compte interagit-il avec les modules ?
3. Quelle est la séquence des modules d'appel ?
4. Comment trouver et vérifier les modules de manière ouverte ?

Une brève revue de l'AA

Paysage SCA

L'EOA traditionnelle pose de nombreux problèmes, tels que la phrase d'amorçage, le gaz, la chaîne croisée et les transactions multiples. Nous n'avons jamais eu l'intention d'introduire de la complexité, mais en fait, la blockchain n'est pas un jeu facile pour les masses.

L'abstraction de compte s'appuie sur le compte du contrat intelligent pour permettre une validation et une exécution programmables, où l'utilisateur peut approuver une série de transactions en une seule fois, plutôt que de signer et de diffuser chacune d'entre elles, et mettre en œuvre de nombreuses autres fonctionnalités. Il apporte des avantages à l'expérience de l'utilisateur (par ex. l'abstraction de gaz et les clés de session), le coût (ex. transaction par lots), et la sécurité (ex. récupération sociale, multi-sig). Actuellement, il existe deux façons de réaliser l'abstraction des comptes :

1. Couche du protocole : Certains protocoles fournissent eux-mêmes un support natif d'abstraction de compte, les transactions ZKsync suivent le même flux qu'elles proviennent de l'EOA ou du SCA qui utilise un seul mempool et un seul flux de transaction pour supporter l'AA, et Starknet a supprimé l'EOA et tous les comptes sont SCA, et ils ont des portefeuilles de contrats intelligents natifs comme Argent.
2. Couche de contrat : Pour Ethereum et ses L2 équivalentes, l' ERC4337 introduit un point d'entrée distinct pour les transactions afin de prendre en charge l'AA sans modifier la couche de consensus. Des projets comme Stackup, Alchemy, Etherspot, Biconomy, Candide et Plimico construisent une infrastructure de regroupement, et beaucoup d'autres comme Safe, Zerodev, Etherspot et Biconomy construisent une pile et un SDK.

👉 Si vous ne connaissez pas l'AA ou l'ERC4337, consultez les recherches précédentes de SevenX ici.

Le dilemme de l'adoption du SCA

Le thème de l'abstraction de compte (AA) fait l'objet de discussions depuis 2015 et a été propulsé sous les feux de la rampe par l'ERC4337 cette année. Toutefois, le nombre de comptes de contrats intelligents déployés reste dérisoire par rapport aux EOA.

Penchons-nous sur ce dilemme :

1. Impact sur le marché baissier :
   Même si l'AA présente des avantages tels que la connexion transparente et l'abstraction de gaz, le marché baissier actuel se compose principalement d'utilisateurs de l'EOA éduqués plutôt que de nouveaux utilisateurs, ce qui n'incite pas les dApps et les portefeuilles à s'en prévaloir. Même en disant cela, les principales applications sont toujours sur la voie de l'adoption de l'AA, comme Cyberconnect qui a réalisé environ 360 000 UserOps (transactions d'AA) par mois rien qu'en introduisant son système d'AA et sa solution sans gaz.
2. Obstacles à la migration :
   Pour les portefeuilles et les applications qui ont accumulé des utilisateurs et stocké des actifs dans des EOA, la migration des actifs de manière sûre et pratique reste un défi. Néanmoins, des initiatives telles que l'EIP-7377 permettent aux EOA d'initier une opération de migration unique.
3. Problème de signature :
   Le contrat intelligent lui-même ne peut naturellement pas signer les messages, puisqu'il ne possède pas de clé privée comme les EOA. Des efforts tels que l'ERC1271 le rendent possible, mais la signature du message ne fonctionnera pas avant la première transaction, ce qui pose un problème pour les portefeuilles utilisant le déploiement contrefactuel. L'ERC-6492 proposé par Ambire est un successeur rétrocompatible de l'ERC-1271 qui résout potentiellement le problème précédent.
4. Frais généraux liés au gaz :
   Le déploiement, la simulation et l'exécution des SCA entraînent des coûts plus élevés que les EOA standard. Cela devient un facteur de dissuasion pour l'adoption. Cependant, plusieurs tests ont été effectués, tels que le découplage de la création de compte des opérations de l'utilisateur, et l'élimination du sel de compte et des vérifications d'existence sont envisagés pour réduire ces coûts.
5. Difficultés techniques :
   L'équipe ERC-4337 a mis en place le repo eth-infinitism pour fournir aux développeurs une implémentation fondamentale. Cependant, lorsque nous passons à des fonctions plus nuancées ou spécifiques pour différents cas d'utilisation, l'intégration et le décodage deviennent un défi.

Dans cet article, nous allons nous pencher sur le problème n°5 : les difficultés d'ingénierie.

🤔️

Un compte modulaire pour les contrats intelligents afin de résoudre les problèmes d'ingénierie

Pour en savoir plus sur les difficultés d'ingénierie :

1. Fragmentation :
   Les fonctionnalités sont désormais activées de différentes manières, que ce soit de manière native par des SCA spécifiques ou par le biais de systèmes d'extension indépendants. Chacune suit sa propre norme, ce qui oblige les développeurs à choisir les plateformes qu'ils souhaitent adopter. Cela conduit à des blocages potentiels de la plateforme ou à des efforts redondants.
2. Sécurité :
   Si la flexibilité entre les comptes et les fonctionnalités présente des avantages, elle peut aussi amplifier les problèmes de sécurité. Les caractéristiques peuvent faire l'objet d'un audit collectif, mais l'absence d'évaluations indépendantes pourrait accroître le risque de vulnérabilité des comptes.
3. Évolutivité :
   Au fur et à mesure de l'évolution des fonctionnalités, il est important de conserver la capacité d'ajouter, de remplacer ou de supprimer des fonctionnalités. Le redéploiement des fonctionnalités existantes à chaque mise à jour introduit des complexités.

Pour naviguer dans ces eaux, nous avons besoin de contrats évolutifs qui garantissent des mises à niveau sûres et efficaces, de noyaux réutilisables pour améliorer l'efficacité globale du développement et d'interfaces normalisées pour garantir que les comptes contractuels puissent passer sans heurts d'un front-end à l'autre.

Ces termes convergent vers un concept singulier : La construction d'une architecture modulaire d'abstraction de comptes (Modular AA).

L'AA modulaire est une niche au sein du mouvement AA plus large qui envisage la modularisation des comptes intelligents afin de les personnaliser pour les utilisateurs et de permettre aux développeurs d'améliorer les fonctionnalités de manière transparente avec un minimum de restrictions.

Cependant, quel que soit le secteur, la mise en place et la promotion d'une nouvelle norme constituent un défi de taille. Les phases initiales peuvent donner lieu à de nombreuses solutions différentes avant que tout le monde ne se mette d'accord sur la solution principale. Cependant, il est encourageant de voir que ceux qui travaillent sur l'abstraction des comptes, qu'il s'agisse du SDK 4337, des développeurs de portefeuilles, des équipes chargées de l'infrastructure ou des concepteurs de protocoles, s'unissent pour accélérer le processus.

Structure modulaire : Compte principal et modules

Comment le compte appelle-t-il les modules à réaliser des fonctions

Appel des délégués et contrat de procuration

Appel externe et appel de délégué :

À propos de delegateCall

L'appel de délégué est similaire à l'appel, mais au lieu d'exécuter le contrat cible dans son propre contexte, il l'exécute dans le contexte de l'état actuel du contrat appelant. Cela signifie que tout changement d'état effectué par le contrat cible est répercuté sur le stockage du contrat appelant.

Contrat de mandataire et appel de délégué

Pour réaliser la structure composable et évolutive, il est nécessaire de disposer d'une connaissance fondamentale appelée "contrat de mandataire".

1. Contrat proxy : un contrat normal stocke sa logique et ses états, ce qui ne permet pas de les mettre à jour après le déploiement. Un contrat proxy utilisant l'appel délégué à un autre contrat. En faisant référence à la fonction d'implémentation, il l'exécute dans l'état actuel du contrat proxy.
2. Cas d'utilisation : Alors que le contrat de proxy reste immuable, vous pouvez déployer une nouvelle implémentation derrière le proxy. Les contrats par procuration sont utilisés pour l'évolutivité et sont moins chers à déployer et à maintenir sur les blockchains publiques.

Une architecture sûre

Une architecture sûre

Ce qui est sûr :

Safe est une infrastructure modulaire de comptes intelligents conçue pour offrir une sécurité et une flexibilité éprouvées. Elle permet aux développeurs de créer des applications et des portefeuilles diversifiés. Notamment, de nombreuses équipes construisent sur Safe ou s'en inspirent. Biconomy a lancé son compte en élargissant Safe avec les signatures natives 4337 et 1/1. Avec le déploiement de plus de 164 000 contrats et une valeur de plus de 30,7 milliards d'euros, Safe est sans aucun doute le leader dans le domaine de l'espace.

Quelle est la structure de Safe ?

1. Contrat de compte sécurisé : contrat proxy principal (avec état)
   Le compte sécurisé est un contrat proxy car il appelle par délégation un contrat singleton. Le compte sécurisé contient des propriétaires, des seuils et des adresses de mise en œuvre qui sont tous définis comme des variables du proxy, définissant ainsi son état.
2. Contrat Singleton : Hub d'intégration (sans état)
   Singleton sert le compte Safe et intègre et définit différentes intégrations, notamment Plugin, Hook, Function Handler et Signature Validator.
3. Contrat de module : logique et fonctionnalités personnalisées :
   Les modules sont puissants. Les plugins, en tant que type modulaire, peuvent définir différentes caractéristiques telles que les flux de paiement, les mécanismes de récupération et les clés de session, et peuvent servir de pont entre web2 et web3 en récupérant des données hors chaîne. D'autres modules comme le crochet, qui sert de garde-fou, et le gestionnaire de fonctions répondent à toutes les instructions.

Ce qui se passe lorsque nous adoptons Safe :

1. Contrats évolutifs :
   Le déploiement d'un nouveau singleton est nécessaire lorsque de nouveaux plugins sont introduits. Les utilisateurs conservent l'autonomie de mettre à niveau leur coffre-fort vers la version unique souhaitée, en fonction de leurs préférences et de leurs besoins.
2. Modules composables et réutilisables :
   La nature modulaire des plugins permet aux développeurs de créer des fonctionnalités de manière indépendante. Ils peuvent ensuite choisir et combiner librement ces plugins en fonction de leurs cas d'utilisation, ce qui favorise une approche hautement personnalisable.

ERC-2535 Diamond Proxies

Architecture de diamant ERC2535

À propos de l'ERC2535, Diamond Proxies :

L'ERC2535 normalise les diamants, un système de contrat intelligent modulaire qui peut être mis à niveau/étendu après le déploiement et n'a pratiquement aucune limite de taille. Jusqu'à présent, de nombreuses équipes s'en sont inspirées, comme le Kernel de Zerodev et l'expérience de Soul Wallet.

Qu'est-ce que la structure du diamant ?

1. Contrat diamant : contrat proxy principal (avec état) Un diamant est un contrat proxy qui appelle des fonctions à partir de ses implémentations à l'aide de l'appel de délégué.
2. Contrat de module/plugin/facette : logique et fonctionnalités personnalisées (sans état) Un module ou une facette est un contrat sans état qui peut déployer ses fonctionnalités sur un ou plusieurs diamants. Il s'agit de contrats distincts et indépendants qui peuvent partager des fonctions internes, des bibliothèques et des variables d'état.

Ce qui se passe lorsque nous adoptons Diamond :

1. Contrats évolutifs : Diamond fournit un moyen systématique d'isoler différents plugins, de les connecter ensemble et de partager des données entre eux. Il permet également d'ajouter/remplacer/supprimer directement n'importe quel plugin à l'aide de la fonction diamondCut. Il n'y a pas de limite au nombre de plugins qui peuvent être ajoutés aux diamants au fil du temps.
2. Plugin modulaire et réutilisable : Un plugin déployé peut être utilisé par un nombre illimité de diamants, ce qui réduit considérablement les coûts de déploiement.

Différence entre Safe Smart Account et Diamond Approach :

Les architectures Safe et Diamond présentent de nombreuses similitudes : elles s'appuient toutes deux sur des contrats de substitution et font référence à des contrats logiques pour assurer l'évolutivité et la modularité.

Néanmoins, la principale distinction réside dans le traitement des contrats logiques. Voici un aperçu plus détaillé :

1. Flexibilité :
   Dans le contexte de l'activation de nouveaux plugins, Safe nécessite le redéploiement de son contrat Singleton pour mettre en œuvre le changement dans son Proxy. En revanche, Diamond y parvient directement grâce à la fonction diamondCut de son Proxy. Cette différence d'approche se traduit par le fait que Safe conserve un degré de contrôle plus élevé, tandis que Diamond introduit une flexibilité et une modularité accrues.
2. Sécurité :
   delegatecall, utilisé dans les deux structures pour l'instant, peut permettre à un code externe de manipuler le stockage du contrat principal. Dans l'architecture Safe, l'appel de délégué pointe vers un seul contrat logique, alors que Diamond utilise l'appel de délégué à travers plusieurs contrats de modules - les plugins. Par conséquent, un plugin malveillant a le potentiel d'écraser un autre plugin, introduisant ainsi le risque de collisions de stockage qui pourraient compromettre l'intégrité du Proxy.
3. Le coût :
   La flexibilité inhérente à l'approche Diamant va de pair avec des préoccupations accrues en matière de sécurité. Cela augmente le facteur coût, nécessitant des audits complets à chaque ajout d'un nouveau plugin. La clé est de s'assurer que ces plugins n'interfèrent pas avec les fonctions des autres, ce qui représente un défi, en particulier pour les petites et moyennes entreprises qui s'efforcent de maintenir des normes de sécurité solides.

L'approche "Safe Smart Account" et l'approche "Diamond" sont des exemples de structures distinctes impliquant des mandataires et des modules. Il est essentiel de trouver un équilibre entre la flexibilité et la sécurité, et ces deux méthodes pourraient se compléter à l'avenir.

Séquence de modules : Validateur, exécuteur et crochet

Quelle est la séquence des modules d'appel ?

Développons notre discussion en présentant l'ERC6900, une norme proposée par l'équipe Alchemy, inspirée par Diamond et adaptée spécifiquement à l'ERC-4337. Il relève le défi de la modularité des comptes intelligents en fournissant des interfaces communes et en coordonnant les efforts entre les développeurs de plugins et de portefeuilles.

Le processus de transaction de l'AA comprend trois processus principaux : la validation, l'exécution et l'accrochage. Toutes ces étapes peuvent être gérées en utilisant le compte proxy pour appeler les modules, comme nous l'avons vu précédemment. Bien que différents projets puissent utiliser des noms différents, il est important de comprendre la logique sous-jacente similaire.

Noms de fonctions dans différents modèles

1. Validation : Assure l'authenticité et l'autorité de l'appelant sur le compte.
2. Exécution : Exécute toute logique personnalisée autorisée par le compte.
3. Crochet : Il s'agit d'un module qui s'exécute avant ou après une autre fonction. Elle peut modifier l'état ou annuler l'ensemble de l'appel.

ERC6900

Il est essentiel de séparer les modules en fonction d'une logique différente. Une approche normalisée devrait dicter la manière dont les fonctions de validation, d'exécution et de crochet pour les comptes de contrats intelligents devraient être écrites. Qu'il s'agisse de Safe ou d'ERC6900, la normalisation permet de réduire les efforts de développement spécifiques à certaines implémentations ou à certains écosystèmes et d'éviter le verrouillage des fournisseurs.

Modules Découverte et sécurité

Comment trouver et vérifier les modules de manière ouverte ?

Une solution qui prend de l'ampleur consiste à créer un lieu permettant aux utilisateurs de découvrir des modules vérifiables, que l'on peut appeler "registre". Ce registre fonctionne comme un "App Store" et vise à favoriser un marché modulaire simplifié mais florissant.

Protocole Safe{Core}

Protocole Safe{Core}

Le protocole Safe{Core} Le protocole Safe est un protocole open-source interopérable pour les comptes de contrats intelligents, conçu pour améliorer l'accessibilité pour les différents fournisseurs et développeurs tout en maintenant une sécurité solide grâce à des normes et des règles bien définies.

1. Compte : Dans le protocole Safe{Core}, le concept de compte est souple et n'est pas lié à une mise en œuvre spécifique. Cela permet à divers fournisseurs de services de compte de participer.
2. Gestionnaire : Le gestionnaire sert de coordinateur entre les comptes, les registres et les modules. Il est également responsable de la sécurité en tant que couche d'autorisation.
3. Les registres : Les registres définissent les attributs de sécurité et appliquent des normes telles que la norme ERC6900 pour les modules, afin de créer un environnement ouvert de "magasin d'applications" pour la découverte et la sécurité.
4. Modules : Les modules gèrent les fonctionnalités et se présentent sous différents types initiaux, notamment les plugins, les crochets, les validateurs de signature et les gestionnaires de fonction. Les développeurs peuvent y contribuer, à condition qu'ils respectent les normes établies.

Motif en strass

Motif en strass

Le processus se déroule comme suit :

1. Création d'une définition de schéma : Un schéma est une structure de données prédéfinie nécessaire à l'attestation. Il peut être personnalisé par les entreprises pour s'aligner sur leurs cas d'utilisation spécifiques.
2. Création de modules basés sur un schéma : Les contrats intelligents sont enregistrés en tant que modules, en obtenant du bytecode et en choisissant un identifiant de schéma. Ces données sont ensuite stockées dans le registre.
3. Attestation d'un module : Les certificateurs/auditeurs peuvent fournir des attestations pour des modules sur la base d'un schéma. Ces attestations peuvent inclure un identifiant unique (UID) et des références à d'autres attestations pour le chaînage. Ils peuvent se propager à travers les chaînes et vérifier si des seuils spécifiques sont atteints sur les chaînes de destination.
4. Mise en œuvre d'une logique complexe avec des résolveurs : Les résolveurs, optionnellement définis dans le schéma, entrent en jeu. Ils peuvent être invoqués lors de la création du module, de l'établissement de l'attestation et de la révocation. Ces résolveurs permettent aux développeurs d'incorporer une logique complexe et diversifiée tout en maintenant les structures d'attestation.
5. Accès convivial aux requêtes : Les requêtes permettent aux utilisateurs d'accéder aux informations relatives à la sécurité à partir de l'interface utilisateur. Vous trouverez ce PIE ici.

Bien que ce schéma n'en soit qu'à ses débuts, il offre la possibilité d'établir une norme de manière décentralisée et collaborative. Leur registre permet aux développeurs d'enregistrer leurs modules, aux auditeurs de vérifier leur sécurité et aux portefeuilles de s'intégrer, et aux utilisateurs de localiser facilement les modules et de vérifier leurs informations d'attestation. Plusieurs utilisations futures pourraient être envisagées :

1. Attestateurs : Des entités dignes de confiance, comme Safe, pourraient collaborer avec Rhinestone en tant qu'attestateurs pour les modules internes. Simultanément, des attestataires indépendants peuvent s'y joindre.
2. Développeurs de modules : Au fur et à mesure qu'un marché ouvert se met en place, les développeurs de modules pourraient potentiellement monétiser leur travail par l'intermédiaire du registre.
3. Les utilisateurs : En s'engageant via des interfaces conviviales, telles que des portefeuilles ou des dApps, les utilisateurs peuvent examiner les informations des modules et déléguer la confiance à divers attestataires.

Le concept de "registre des modules" ouvre des perspectives de monétisation pour les développeurs de plugins et de modules. Il pourrait également ouvrir la voie à un "marché des modules". Certains aspects pourraient être supervisés par l'équipe de Safe, tandis que d'autres pourraient se manifester sous la forme de places de marché décentralisées, invitant à des contributions et à des enregistrements d'audit transparents pour tous. En intégrant cela, nous pouvons éviter le verrouillage des fournisseurs et soutenir l'expansion de l'EVM en ajoutant une expérience utilisateur améliorée qui attire un public plus large.

Si ces approches garantissent la sécurité d'un seul module, la sécurité générale des comptes de contrats intelligents n'est pas infaillible. Il peut être difficile de combiner des modules légitimes et de prouver qu'ils n'ont pas de collisions de stockage, ce qui souligne l'importance de l'infrastructure des portefeuilles ou des AA pour répondre à ces préoccupations.

Réflexions finales

En utilisant une pile de comptes de contrats intelligents modulaires, les fournisseurs de portefeuilles et les dApps peuvent être libérés des complexités de la maintenance technique. Par ailleurs, les développeurs de modules externes ont la possibilité d'offrir des services spécialisés adaptés aux besoins individuels. Toutefois, les défis à relever consistent à trouver un équilibre entre flexibilité et sécurité, à faire progresser les normes modulaires et à mettre en œuvre des interfaces normalisées qui permettent aux utilisateurs de mettre à niveau et de modifier facilement leurs comptes intelligents.

Cependant, les comptes modulaires de contrats intelligents (SCA) ne représentent qu'une pièce du puzzle de l'adoption. Pour exploiter pleinement le potentiel de l'ACS, il faut que les solutions de la couche 2 apportent un soutien supplémentaire à la couche protocolaire, par exemple une infrastructure de regroupement robuste et un système de mise en commun d'égal à égal, un mécanisme de signature de l'ACS plus rentable et plus réalisable, une synchronisation et une gestion de l'ACS entre les chaînes et la mise au point d'interfaces conviviales.

Nous envisageons un avenir où la participation sera généralisée, ce qui soulève des questions intéressantes : Une fois que le flux d'ordres SCA devient suffisamment rentable, comment les mécanismes traditionnels de valeur extractible par les mineurs (MEV) entreront-ils dans le champ pour construire des bundlers et capturer de la valeur ? Lorsque l'infrastructure arrivera à maturité, comment les Abstractions de comptes (AA) pourront-elles servir de couche fondamentale pour les transactions "basées sur l'intention" ? Restez à l'écoute ; le paysage évolue de minute en minute.

Pièces importantes

1. Livre blanc sur la sécurité : https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Doc strass : https://docs.rhinestone.wtf/
3. Biconomie doc : https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Clause de non-responsabilité：

1. Cet article est repris de[SevenX Ventures ]. Tous les droits d'auteur appartiennent à l'auteur original[SevenX Ventures]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. 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, distribuer ou plagier les articles traduits.