Conception de comptes intelligents modulaires : résolution des problèmes techniques d'implémentation
TechFlow SélectionTechFlow Sélection
Conception de comptes intelligents modulaires : résolution des problèmes techniques d'implémentation
En exploitant une pile de comptes intelligents modulaires, les fournisseurs de portefeuilles et les dApps peuvent se libérer de la complexité liée à la maintenance technique.
Dédié à des analyses Web3 approfondiesRédaction : Rui S (SevenX Ventures)
Traduction : TechFlow
Introduction
La transition des comptes détenus par des entités externes (EOA) vers les comptes à contrats intelligents (SCA) est en plein essor et bénéficie du soutien de nombreux passionnés, y compris Vitalik lui-même. Bien qu’elle suscite beaucoup d’enthousiasme, l’adoption des SCA n’est pas aussi répandue que celle des EOA. Les principaux obstacles incluent les difficultés liées au marché baissier, les préoccupations autour de la migration, les problèmes de signature, les frais de gaz, ainsi que le défi technique fondamental.
L’un des principaux avantages de l’abstraction de compte (AA) réside dans la possibilité de personnaliser les fonctionnalités via du code. Toutefois, un défi majeur en matière d’ingénierie est la non-interopérabilité des fonctions AA, dont la fragmentation nuit à l’intégration et ouvre la porte au verrouillage fournisseur. De plus, assurer la sécurité lors de la mise à niveau simultanée et de la combinaison de fonctionnalités peut s’avérer complexe.
L’émergence de l’abstraction de compte modulaire constitue un sous-ensemble du mouvement AA plus large. Cette approche innovante permet de séparer le compte intelligent de ses fonctionnalités personnalisées. L’objectif est de créer une architecture modulaire afin de développer des portefeuilles dotés de diverses fonctionnalités, intégrés de manière fluide et sécurisée. À terme, cela pourrait aboutir à un « magasin d’applications » libre pour comptes à contrats intelligents, permettant aux portefeuilles et aux dApps de se concentrer moins sur la construction de fonctionnalités et davantage sur l’expérience utilisateur.
Présentation rapide de l’AA
Les EOA traditionnels posent de nombreux défis tels que les phrases de récupération, les frais de gaz, les opérations multi-chaînes et les multiples transactions. Nous n’avions jamais voulu introduire cette complexité, mais il est clair que la blockchain ne constitue pas un jeu simple pour le grand public.
L’abstraction de compte exploite les comptes à contrats intelligents, autorisant une validation et une exécution programmables. Elle permet aux utilisateurs d’approuver une série de transactions en une seule fois, plutôt que de signer et diffuser chaque transaction individuellement, tout en offrant davantage de fonctionnalités. Cela apporte des bénéfices en termes d’expérience utilisateur (par exemple, abstraction de gaz, clés de session), de coûts (exécution groupée des transactions) et de sécurité (récupération sociale, signatures multiples). Actuellement, deux méthodes permettent de mettre en œuvre l’abstraction de compte :
-
Couche protocole : certains protocoles intègrent nativement le support de l’AA. ZKsync traite indifféremment les transactions provenant d’un EOA ou d’un SCA selon un même processus, utilisant un seul mempool et flux transactionnel. Starknet a carrément supprimé les EOA : tous les comptes sont désormais des SCA, avec notamment Argent comme portefeuille intelligent natif.
-
Couche contrat : pour Ethereum et ses équivalents L2, ERC4337 introduit une entrée transactionnelle distincte pour supporter l’AA sans modifier la couche de consensus. Des projets comme Stackup, Alchemy, Etherspot, Biconomy, Candide et Plimico construisent l’infrastructure des agrégateurs (bundlers), tandis que Safe, Zerodev, Etherspot et Biconomy développent des piles logicielles (stacks) et SDK.
Le dilemme de l’adoption des SCA
Depuis 2015, le concept d’abstraction de compte (AA) fait l’objet de discussions, et cette année, il a été mis en lumière grâce à ERC4337. Pourtant, le nombre de comptes à contrats intelligents déployés reste très inférieur à celui des EOA.
Examinons ce dilemme de plus près :
-
Impact du marché baissier :
Bien que l’AA apporte des avantages tels qu’une connexion transparente et l’abstraction de gaz, les utilisateurs actuels traversant le marché baissier sont principalement des détenteurs d’EOA expérimentés, et non de nouveaux arrivants. Il n’existe donc guère d’incitation pour les dApps et portefeuilles. Néanmoins, certaines applications leaders adoptent progressivement l’AA : Cyberconnect, par exemple, a généré environ 360 000 UserOps (transactions AA) en un mois grâce à son système AA et sa solution sans frais de gaz.
-
Obstacles à la migration :
Pour les portefeuilles et applications ayant déjà accumulé des utilisateurs et des actifs, migrer ces derniers de façon sûre et pratique demeure un défi. Toutefois, des initiatives telles que l’EIP-7377 permettent à un EOA d’initier une transaction unique de migration.
-
Problèmes de signature :
Un contrat intelligent ne peut naturellement pas signer de messages, car il ne possède pas de clé privée comme un EOA. Des efforts tels que ERC1271 rendent cette signature possible, mais elle ne fonctionne pas avant la première transaction, ce qui pose problème pour les portefeuilles déployés de manière factuelle (« counterfactually »). ERC-6492, proposé par Ambire, est un successeur rétrocompatible d’ERC-1271 qui pourrait résoudre ce problème.
-
Coût en gaz :
Déployer, simuler et exécuter un SCA entraîne des coûts supérieurs à ceux d’un EOA standard. Cela constitue un frein à l’adoption. Toutefois, plusieurs tests ont été menés, comme découpler la création du compte de l’UserOp, ou encore envisager l’élimination du sel du compte et des vérifications d’existence, afin de réduire ces coûts.
-
Difficultés techniques :
L’équipe ERC-4337 a créé le dépôt eth-infinitism, fournissant aux développeurs une implémentation de base. Cependant, au fur et à mesure que nous explorons des cas d’usage plus spécifiques ou complexes, l’intégration et le décodage deviennent problématiques.
Dans cet article, nous allons approfondir le cinquième point : les difficultés techniques.
Comptes à contrats intelligents modulaires pour résoudre les défis techniques
Approfondissons davantage ces difficultés techniques :
-
Fragmentation : les différentes fonctionnalités sont actuellement activées de manières disparates, soit via des SCA spécifiques, soit par des systèmes de plugins indépendants. Chaque solution suit ses propres standards, forçant les développeurs à choisir quels plateformes ils souhaitent supporter. Cela peut conduire au verrouillage ou à des efforts redondants.
-
Sécurité : bien que la flexibilité entre compte et fonctionnalités présente des avantages, elle peut également amplifier les risques. Les fonctionnalités peuvent être auditées collectivement, mais l’absence d’évaluation indépendante augmente le risque de vulnérabilités dans le compte.
-
Capacité d’évolution : à mesure que les fonctionnalités évoluent, il est crucial de conserver la possibilité d’ajouter, remplacer ou supprimer des modules. Redéployer toutes les fonctionnalités existantes à chaque mise à jour introduit une complexité inutile.
Pour relever ces défis, nous avons besoin de contrats évolutifs garantissant des mises à jour sécurisées et efficaces, d’un noyau réutilisable pour améliorer l’efficacité générale du développement, et d’interfaces normalisées assurant une transition fluide des comptes entre différents fronts.
Ces exigences convergent vers un concept commun : la construction d’une architecture d’abstraction de compte modulaire (Modular AA).
L’AA modulaire est un sous-domaine du mouvement AA plus vaste, qui vise à modulariser les comptes intelligents afin de mieux servir les utilisateurs, tout en permettant aux développeurs d’améliorer leurs fonctionnalités de manière transparente et avec un minimum de contraintes.
Toutefois, dans n’importe quel secteur, établir et promouvoir une nouvelle norme représente un défi colossal. Avant que tous n’adoptent une solution dominante, la phase initiale connaît souvent de nombreuses solutions concurrentes. Heureusement, tant les équipes de SDK 4337, développeurs de portefeuilles, infrastructures que concepteurs de protocoles collaborent étroitement pour accélérer ce processus.
Structure modulaire : Compte principal et Modules
Appel délégué et contrats proxy
Appel externe et appel délégué :
Bien que delegatecall ressemble à call, il n’exécute pas le contrat cible dans son propre contexte, mais dans l’état courant du contrat appelant. Ainsi, toute modification d’état effectuée par le contrat cible s’applique au stockage du contrat appelant.
Pour obtenir une structure composable et évolutionnaire, une notion fondamentale est requise : le « contrat proxy ».
-
Contrat proxy : un contrat classique stocke sa logique et son état, et ne peut pas être mis à jour après déploiement. Un contrat proxy utilise delegatecall pour appeler un autre contrat. En référençant une implémentation, il exécute les fonctions dans l’état courant du proxy.
-
Cas d’usage : bien que le contrat proxy reste inchangé, on peut déployer une nouvelle implémentation derrière lui. Le proxy permet l’évolution du contrat, avec un coût moindre de déploiement et de maintenance sur la blockchain publique.
Architecture sécurisée
Safe est une infrastructure leader en matière de comptes intelligents modulaires, conçue pour offrir sécurité éprouvée et flexibilité, permettant aux développeurs de créer des applications et portefeuilles variés. Beaucoup d’équipes construisent aujourd’hui dessus ou s’en inspirent. Biconomy, par exemple, étend Safe en y ajoutant nativement le support ERC-4337 et une multisignature 1/1. Safe a déployé plus de 164 000 contrats et sécurisé plus de 30,7 milliards de dollars. Incontestablement, Safe est le choix dominant dans ce domaine.
Structure de Safe
-
Contrat de compte Safe : contrat proxy principal (avec état)
Le compte Safe est un contrat proxy, car il utilise delegatecall pour appeler un contrat singleton. Le compte Safe contient les propriétaires, le seuil et l’adresse d’implémentation, définissant ainsi son état.
-
Contrat singleton : centre d’intégration (sans état)
Le singleton fournit des services au compte Safe et intègre/définit différentes intégrations, notamment les plugins, les hooks, les gestionnaires de fonctions et les validateurs de signature.
-
Contrats de modules : logique et fonctionnalités personnalisées
Les modules sont extrêmement puissants. En tant que type modulaire, les plugins peuvent définir diverses fonctionnalités comme les flux de paiement, les mécanismes de récupération ou les clés de session, et agir comme pont entre Web2 et Web3 en exploitant des données hors chaîne. D’autres modules, comme les hooks servant de garde-fous de sécurité, ou les gestionnaires de fonctions répondant à toute instruction.
Ce qui change lorsque l’on adopte Safe
-
Contrats évolutifs :
À chaque ajout d’un nouveau plugin, un nouveau singleton doit être déployé. Les utilisateurs conservent l’autonomie de mettre à jour leur Safe vers la version de singleton souhaitée, selon leurs préférences.
-
Modules composable et réutilisables :
La nature modulaire des plugins permet aux développeurs de construire des fonctionnalités indépendamment. Ils peuvent ensuite les sélectionner et les combiner librement selon leurs cas d’usage, favorisant une grande personnalisation.
Proxy Diamond ERC-2535
À propos d’ERC2535 et du proxy Diamond
ERC2535 standardise le proxy Diamond, un système de contrats intelligents modulaires pouvant être mis à jour ou étendus après déploiement, presque sans limite de taille. Plusieurs équipes s’en inspirent déjà, comme Zerodev avec Kernel ou Soul Wallet dans ses expérimentations.
Quelle est la structure d’un Diamond ?
-
Contrat Diamond : contrat proxy principal (avec état). Diamond est un contrat proxy qui utilise delegatecall pour appeler des fonctions depuis ses implémentations.
-
Contrats de modules/plugins/facettes : logique et fonctionnalités personnalisées (sans état). Un module, ou « facette », est un contrat sans état pouvant déployer ses fonctions dans un ou plusieurs Diamonds. Ce sont des contrats autonomes pouvant partager des fonctions internes, bibliothèques et variables d’état.
Ce qui change lorsque l’on adopte Diamond
-
Contrats évolutifs : Diamond offre une méthode systématique pour isoler différents plugins et les connecter ensemble, permettant d’ajouter/remplacer/supprimer directement des plugins via la fonction diamondCut. Le nombre de plugins pouvant être ajoutés à un Diamond est illimité.
-
Plugins modulaires et réutilisables : un plugin déployé peut être utilisé par un nombre illimité de Diamonds, réduisant considérablement les coûts de déploiement.
Différences entre la méthode Safe et la méthode Diamond
Les architectures Safe et Diamond présentent de nombreuses similitudes : les deux reposent sur un contrat proxy comme noyau, et référencent des contrats logiques pour assurer évolutivité et modularité.
La différence principale réside dans la gestion des contrats logiques. Voici une explication détaillée :
-
Flexibilité : pour activer un nouveau plugin, Safe doit redéployer son contrat singleton afin d’appliquer les changements dans son proxy. En revanche, Diamond réalise cela directement via la fonction diamondCut dans son proxy. Cette divergence signifie que Safe conserve un meilleur contrôle, tandis que Diamond offre une modularité et une flexibilité supérieures.
-
Sécurité : actuellement, les deux structures utilisent delegatecall, qui permet à du code externe de manipuler le stockage du contrat principal. Dans Safe, delegatecall pointe vers un seul contrat logique, alors que Diamond utilise delegatecall entre plusieurs modules (plugins). Un plugin malveillant pourrait ainsi écraser un autre, provoquant des conflits de stockage et compromettant l’intégrité du proxy.
-
Coût : la flexibilité inhérente à Diamond s’accompagne de risques accrus en matière de sécurité. Cela implique un coût supplémentaire : chaque ajout de plugin nécessite un audit complet, afin de garantir qu’ils n’interfèrent pas mutuellement. Ce défi est particulièrement critique pour les PME soucieuses de maintenir des standards de sécurité élevés.
Les approches « Safe » et « Diamond » illustrent différentes architectures basées sur les proxies et modules. Trouver un équilibre entre flexibilité et sécurité est essentiel, et ces deux méthodes pourraient à l’avenir se compléter mutuellement.
Ordre des modules : Validateurs, Exécuteurs et Hooks
Approfondissons notre discussion en introduisant ERC6900, une norme proposée par l’équipe Alchemy, inspirée de Diamond mais spécialement adaptée à ERC-4337. Elle répond aux défis de modularité des comptes intelligents en fournissant des interfaces communes et en coordonnant le travail entre développeurs de plugins et de portefeuilles.
Concernant le processus transactionnel de l’AA, trois étapes principales interviennent : validation, exécution et hook. Comme mentionné précédemment, l’utilisation d’un compte proxy appelant des modules permet de gérer ces étapes. Bien que les projets utilisent des noms différents, il est important de comprendre la logique fondamentale commune.
-
Validation : garantir l’authenticité et les permissions de l’appelant sur le compte.
-
Exécution : appliquer toute logique personnalisée autorisée par le compte.
-
Hook : module exécuté avant ou après une autre fonction. Il peut modifier l’état ou annuler complètement l’appel.
Il est crucial de séparer les modules selon leur logique. Une approche normalisée devrait préciser comment doivent être écrites les fonctions de validation, d’exécution et de hook d’un compte intelligent. Que ce soit Safe ou ERC6900, la normalisation réduit le besoin de développements spécifiques à une implémentation ou écosystème, et prévient le verrouillage fournisseur.
Découverte et sécurité des modules
Une solution en plein essor consiste à créer un lieu permettant aux utilisateurs de découvrir des modules vérifiés, que nous pouvons appeler un « registre ». Ce registre ressemble à un « magasin d’applications », visant à faciliter un marché modulaire simplifié mais dynamique.
Protocole Safe{Core}
Safe{Core} est un protocole open source et interopérable pour comptes intelligents, conçu pour améliorer l’accessibilité pour divers fournisseurs et développeurs via des standards et règles clairement définis, tout en maintenant une sécurité robuste.
-
Compte : dans Safe{Core}, le concept de compte est flexible, non lié à une implémentation spécifique, permettant à divers fournisseurs de services de participer.
-
Gestionnaire : le gestionnaire agit comme coordinateur entre compte, registre et modules. Il assure également la sécurité en tant que couche d’autorisation.
-
Registre : le registre définit les attributs de sécurité et impose des standards de modules tels qu’ERC6900, créant un environnement ouvert similaire à un « magasin d’applications » pour la découverte et la sécurité.
-
Module : les modules gèrent les fonctionnalités, disponibles sous divers types initiaux : plugins, hooks, validateurs de signature, gestionnaires de fonctions. Tant qu’ils respectent les standards établis, les développeurs peuvent contribuer.
Conception Rhinestone
Le processus se déroule comme suit :
-
Définir un schéma : le schéma constitue une structure de données prédéfinie utilisée pour la preuve. Les entreprises peuvent personnaliser des schémas selon leurs cas d’usage spécifiques.
-
Créer des modules basés sur un schéma : les contrats intelligents sont enregistrés comme modules, récupérant leur bytecode et choisissant un ID de schéma. Ces données sont ensuite stockées dans le registre.
-
Obtenir une preuve pour le module : un émetteur de preuve ou auditeur peut fournir une preuve selon le schéma. Ces preuves incluent un identifiant unique (UID) et des références à d'autres preuves, pouvant être chaînées. Elles peuvent être diffusées sur chaîne et vérifier si des seuils sont atteints sur la chaîne cible.
-
Utiliser des parseurs pour logiques complexes : les parseurs sont facultatifs et configurables dans le schéma. Ils peuvent être appelés lors de la création du module, de l’établissement ou de la révocation d’une preuve. Ils permettent d’intégrer des logiques variées tout en préservant la structure de preuve.
-
Accès convivial via requêtes : les requêtes offrent aux utilisateurs un moyen d’accéder aux informations de sécurité depuis l’interface. L’EIP correspondant est disponible ici.
Bien que ce modèle en soit encore à ses débuts, il a le potentiel de bâtir une norme de manière décentralisée et collaborative. Leur registre permet aux développeurs d’enregistrer leurs modules, aux auditeurs de valider leur sécurité, aux portefeuilles d’intégrer facilement, et aux utilisateurs de trouver simplement les modules et vérifier leurs preuves. À l’avenir, plusieurs usages sont envisageables :
-
Émetteurs de preuves : des entités fiables comme Safe peuvent collaborer avec Rhinestone en tant qu’émetteurs pour leurs modules internes. Des émetteurs indépendants peuvent aussi rejoindre.
-
Développeurs de modules : avec un marché ouvert, les développeurs pourront potentiellement monétiser leurs travaux via le registre.
-
Utilisateurs : via des interfaces conviviales (portefeuilles ou dApps), les utilisateurs pourront consulter les informations des modules et déléguer leur confiance à différents émetteurs de preuves.
Le concept de « registre de modules » offre des opportunités de monétisation aux développeurs de plugins. Il pourrait aussi ouvrir la voie à un « marché de modules », supervisé en partie par l’équipe Safe, ou décentralisé, invitant chacun à contribuer avec des audits transparents. Cette approche évite le verrouillage fournisseur et soutient l’expansion EVM en attirant un public plus large grâce à une meilleure expérience utilisateur.
Bien que ces méthodes garantissent la sécurité des modules individuels, la sécurité globale du compte intelligent n’est pas absolue. Combiner des modules légitimes et prouver l’absence de conflits de stockage reste un défi, soulignant l’importance des portefeuilles ou infrastructures AA dans la résolution de ces problèmes.
Conclusion
En exploitant une pile de comptes à contrats intelligents modulaires, les fournisseurs de portefeuilles et les dApps peuvent se libérer de la complexité de la maintenance technique. Parallèlement, les développeurs externes de modules ont l’opportunité de proposer des services spécialisés adaptés à des besoins précis. Toutefois, des défis persistent : trouver un équilibre entre flexibilité et sécurité, faire avancer les standards modulaires, et mettre en œuvre des interfaces normalisées permettant aux utilisateurs de mettre à jour et modifier facilement leurs comptes intelligents.
Néanmoins, les comptes à contrats intelligents modulaires (SCA) ne constituent qu’une pièce du puzzle de l’adoption. Pour exploiter pleinement leur potentiel, il faut aussi le soutien des protocoles au niveau L2, une infrastructure solide de bundlers, des mempools P2P, des mécanismes de signature SCA plus rentables et praticables, une synchronisation et gestion multi-chaînes des SCA, ainsi que le développement d’interfaces simples d’utilisation.
Nous imaginons un avenir largement inclusif, soulevant des questions intrigantes : une fois que les flux de commande SCA deviendront suffisamment lucratifs, comment les mécanismes traditionnels de valeur extractible par les mineurs (MEV) entreront-ils en jeu, en construisant des bundlers pour capter cette valeur ? Quand l’infrastructure sera mature, comment l’abstraction de compte (AA) deviendra-t-elle la couche fondamentale des transactions « basées sur l’intention » ? Restez à l’écoute : ce domaine évolue rapidement.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@SevenXVentures
