Discussion approfondie sur la conception de comptes de contrats intelligents modulaires : résolution des problèmes techniques de mise en œuvre

Auteur : Rui S, SevenX Ventures ; Compilé par : Deep Wave TechFlow

introduire

Le passage des comptes externes (EOA) aux comptes de contrats intelligents (SCA) est en plein essor et est soutenu par de nombreux passionnés, dont Vitalik lui-même. Malgré l’enthousiasme suscité, l’adoption de la SCA n’a pas été aussi répandue que celle de l’EOA. Les problèmes clés incluent les défis du marché baissier, les problèmes de migration, les problèmes de signature, les frais généraux liés au gaz et, plus important encore, les défis d’ingénierie.

L’un des avantages les plus importants de l’abstraction de compte (AA) est la possibilité de personnaliser les fonctionnalités à l’aide de code. Cependant, un défi technique majeur réside dans la non-interopérabilité des fonctionnalités AA, et cette fragmentation entrave l’intégration et ouvre la porte à une dépendance vis-à-vis d’un fournisseur. De plus, assurer la sécurité lors de la mise à niveau et de la combinaison simultanée de fonctionnalités peut s’avérer complexe.

L’abstraction de compte modulaire est apparue comme un sous-ensemble du mouvement AA plus large, une approche innovante visant à dissocier les comptes intelligents de leurs fonctionnalités personnalisées. L’objectif est de créer une structure modulaire pour développer des portefeuilles sécurisés et parfaitement intégrés dotés de fonctionnalités diverses. À l’avenir, il pourra mettre en œuvre un « magasin d’applications » de compte de contrat intelligent gratuit afin que les portefeuilles et les dApp ne se concentrent plus sur la création de fonctions, mais sur l’expérience utilisateur.

AA Brève description

L’EOA traditionnelle introduit de nombreux défis tels que les phrases de départ, le gaz, les transactions inter-chaînes et multiples. Nous n’avons jamais eu l’intention d’introduire de la complexité, mais la réalité est que la blockchain n’est pas un jeu facile pour le grand public.

L’abstraction de compte exploite les comptes de contrats intelligents, permettant une vérification et une exécution programmables, permettant aux utilisateurs d’approuver une série de transactions à la fois, plutôt que d’avoir à signer et diffuser chaque transaction, et permettant davantage de fonctionnalités. Il apporte des avantages en termes d’expérience utilisateur (par exemple, abstraction de Gas et clés de session), de coût (par exemple, transactions par lots) et de sécurité (par exemple, récupération sociale, multi-signature). Actuellement, il existe deux manières d’implémenter l’abstraction de compte :

• Couche de protocole : certains protocoles eux-mêmes fournissent une prise en charge de l’abstraction de compte local. Les transactions ZKsync, qu’elles proviennent d’EOA ou de SCA, suivent le même processus, en utilisant un seul pool de mémoire et un seul processus de transaction pour prendre en charge AA, tandis que Starknet a supprimé EOA et tous les comptes. Les deux sont SCA. , et ils ont des portefeuilles de contrats intelligents natifs comme Argent.
• Couche de contrat : pour Ethereum et son équivalent L2, ERC 4337 introduit une entrée de transaction distincte pour prendre en charge AA sans modifier la couche de consensus. Des projets comme Stackup, Alchemy, Etherspot, Biconomy, Candide et Plimico créent une infrastructure de regroupement, tandis que des projets comme Safe, Zerodev, Etherspot et Biconomy créent des piles et des SDK.

Dilemmes liés à l’adoption de SCA

Le sujet de l’abstraction de compte (AA) est en discussion depuis 2015 et a été mis sous les projecteurs cette année par l’ERC 4337. Cependant, le nombre de comptes de contrats intelligents déployés est encore bien inférieur à celui de l’EOA.

Approfondissons ce dilemme :

• Impact du marché baissier :

Bien que AA ait introduit des avantages tels qu’une connexion transparente et l’abstraction de gaz, les personnes actuellement confrontées au marché baissier sont principalement composées d’utilisateurs EOA instruits plutôt que de nouveaux utilisateurs, il n’y a donc aucune incitation pour les dApps et les portefeuilles. Malgré cela, certaines applications de premier plan adoptent progressivement l’AA, comme Cyberconnect, qui a généré environ 360 000 UserOps (transactions AA) en seulement un mois en introduisant son système AA et sa solution sans gaz.

• Obstacles à la migration :

Pour les portefeuilles et les applications qui ont accumulé des utilisateurs et des actifs, la migration des actifs en toute sécurité et commodité reste un défi. Cependant, des initiatives telles que EIP-7377 permettent aux EOA de lancer des transactions de migration uniques.

*Problème de signature :

Le contrat intelligent lui-même ne peut pas naturellement signer de messages car il ne possède pas de clé privée comme EOA. Des efforts tels que l’ERC 1271 rendent une telle signature possible, mais la signature des messages ne fonctionne qu’à la première transaction, ce qui pose un défi pour les portefeuilles utilisant des déploiements contrefactuels. L’ERC-6492 proposé par Ambire est un successeur rétrocompatible de l’ERC-1271 et pourrait résoudre les problèmes précédents.

*Gaz frais généraux :

Le déploiement, la simulation et l’exécution de SCA entraînent des coûts plus élevés que l’EOA standard. Cela devient un obstacle à l’adoption. Cependant, certains tests ont été effectués, tels que le découplage de la création de compte des actions des utilisateurs et la possibilité d’éliminer les sels de compte et les contrôles d’existence, afin de réduire ces coûts.

• Problèmes d’ingénierie :

L’équipe ERC-4337 a créé le référentiel eth-infinitiism pour fournir aux développeurs des implémentations de base. Cependant, à mesure que nous nous étendons vers des fonctionnalités plus granulaires ou spécifiques dans différents cas d’utilisation, l’intégration et le décodage deviennent difficiles.

Dans cet article, nous approfondirons le cinquième problème : les défis d’ingénierie.

Comptes de contrats intelligents modulaires pour résoudre les problèmes d’ingénierie

Une explication supplémentaire des défis techniques est la suivante :

• Fragmentation : diverses fonctionnalités sont désormais activées de différentes manières, que ce soit via des SCA spécifiques ou des systèmes de plug-ins indépendants. Chacun suit ses propres normes, obligeant les développeurs à décider quelles plates-formes prendre en charge. Cela peut conduire à un blocage de la plateforme ou à une duplication des efforts.
• Sécurité : si la flexibilité entre les comptes et les fonctionnalités présente des avantages, elle peut également exacerber les problèmes de sécurité. Les fonctionnalités peuvent être auditées collectivement, mais l’absence d’évaluation indépendante peut augmenter le risque de violation de compte.
• Évolutivité : à mesure que les fonctionnalités évoluent, il est important de conserver la possibilité d’ajouter, de remplacer ou de supprimer des fonctionnalités. Le redéploiement des fonctionnalités existantes à chaque mise à jour introduit de la complexité.

Pour résoudre ces problèmes, nous avons besoin de contrats évolutifs pour garantir des mises à niveau sûres et efficaces, de cœurs réutilisables pour améliorer l’efficacité globale du développement et d’interfaces standardisées pour garantir que les comptes de contrats peuvent passer en douceur entre les différents frontaux.

Ces termes convergent vers un concept commun : construire une architecture d’abstraction de compte modulaire (Modular AA).

Modular AA est une niche au sein du mouvement AA plus large qui envisage de modulariser les comptes intelligents pour adapter les services aux utilisateurs et permettre aux développeurs d’améliorer de manière transparente les fonctionnalités avec un minimum de restrictions.

Cependant, l’établissement et la promotion de nouvelles normes constituent un défi de taille dans tout secteur. De nombreuses solutions différentes peuvent émerger dans les premières étapes avant que tout le monde n’accepte la solution principale. Cependant, il est encourageant de constater que le SDK 4337, les développeurs de portefeuilles, les équipes d’infrastructure et les concepteurs de protocoles travaillent ensemble pour accélérer ce processus.

Structure modulaire : compte principal et modules

Appel du délégué et contrat de procuration

Appels externes et appels délégués :

Bien que déléguécall soit similaire à call, au lieu d’exécuter le contrat cible dans son propre contexte, il exécute le contrat cible dans l’état actuel du contrat appelant. Cela signifie que tout changement d’état effectué par le contrat cible sera appliqué au stockage du contrat appelant.

Afin de mettre en œuvre des structures composables et évolutives, une connaissance de base appelée « contrats d’agence » est requise.

• Contrat d’agent : les contrats ordinaires stockent leur logique et leur statut et ne peuvent pas être mis à jour après le déploiement. Un contrat proxy utilise un délégué pour appeler un autre contrat. Implémentez une fonction par référence, qui s’exécute dans l’état actuel du contrat d’agent.
• Cas d’utilisation : même si le contrat de proxy reste le même, vous pouvez déployer de nouvelles implémentations derrière le proxy. Les contrats proxy sont utilisés pour l’évolutivité et sont moins chers à déployer et à maintenir sur les blockchains publiques.

Architecture de sécurité

Safe est une infrastructure de compte intelligent modulaire de premier plan conçue pour offrir une sécurité et une flexibilité éprouvées, permettant aux développeurs de créer diverses applications et portefeuilles. Il convient de noter que de nombreuses équipes s’appuient sur Safe ou s’en inspirent. Biconomy lance son compte en étendant la multi-signature native 4337 et 1/1 sur Safe. Avec plus de 164 000 contrats déployés et une valeur bloquée de plus de 30,7 milliards de dollars, Safe est sans aucun doute le premier choix dans ce domaine.

Structure sécurisée

• Contrat de compte sécurisé : contrat d’agent principal (avec état)

Le compte Safe est un contrat proxy car il appelle un contrat singleton. Le compte Safe contient le propriétaire, le seuil et l’adresse d’implémentation, qui sont définis comme variables pour l’agent, définissant ainsi son état.

• Contrat Singleton : centre d’intégration (apatride)

Le singleton sert le compte Safe et intègre et définit différentes intégrations, notamment des plugins, des hooks, des gestionnaires de fonctions et des validateurs de signature.

• Contrat module : logique et fonctions personnalisées

Les modules sont très puissants. En tant que type modulaire, les plug-ins peuvent définir différentes fonctions telles que les flux de paiement, les mécanismes de récupération et les clés de session, et servir de pont entre les chaînes entre Web2 et Web3 en obtenant des données hors chaîne. D’autres modules tels que Hooks agissent comme des gardes de sécurité et les gestionnaires de fonctions répondent à toutes les instructions.

Que se passe-t-il lorsque nous adoptons Safe

• Contrats évolutifs :

Chaque fois qu’un nouveau plugin est introduit, un nouveau singleton doit être déployé. Les utilisateurs conservent l’autonomie nécessaire pour mettre à niveau Safe vers la version singleton souhaitée en fonction de leurs préférences et exigences.

• 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 sont ensuite libres de sélectionner et de combiner ces plug-ins en fonction de leurs propres cas d’utilisation, facilitant ainsi une approche hautement personnalisable.

ERC-2535 Agent diamant

À propos de l’ERC 2535 et de l’agent Diamond

ERC 2535 standardise Diamond Agent, un système de contrat intelligent modulaire qui peut être mis à niveau/étendu après le déploiement et qui n’a pratiquement aucune restriction de taille. Jusqu’à présent, de nombreuses équipes s’en sont inspirées, comme les expériences Kernel de Zerodev et Soul Wallet.

Quelle est la structure du Diamant ?

• Contrat Diamond : Contrat d’agent principal (avec état) Diamond est un contrat proxy qui appelle des fonctions dès sa mise en œuvre via des appels de délégués.
• Modules/plugins/contrats à facettes : logique et fonctionnalités personnalisées (sans état) Un module ou ce qu’on appelle une facette est un contrat sans état qui peut déployer ses fonctionnalités dans un ou plusieurs Diamonds. Ce sont des contrats indépendants qui peuvent partager des fonctions internes, des bibliothèques et des variables d’état.

Que se passe-t-il lorsque nous utilisons Diamond

• Contrats évolutifs : Diamond fournit un moyen systématique d’isoler différents plug-ins et de les connecter ensemble, et d’ajouter/remplacer/supprimer n’importe quel plug-in directement via la fonction DiamondCut. Il n’y a pas de limite au nombre de plug-ins pouvant être ajoutés à Diamond au fil du temps.
• Plug-ins modulaires et réutilisables : Un plug-in déployé peut être utilisé par n’importe quel nombre de Diamonds, réduisant ainsi considérablement les coûts de déploiement.

Différence entre le compte intelligent sécurisé et la méthode Diamond

Il existe de nombreuses similitudes entre les architectures Safe et Diamond, les deux s’appuyant sur des contrats proxy comme noyau et faisant référence à des contrats logiques pour l’évolutivité et la modularité.

Cependant, la principale différence réside dans la gestion des contrats logiques. Voici des instructions plus détaillées :

• Flexibilité : avec les nouveaux plugins activés, Safe doit redéployer son contrat singleton pour implémenter les modifications dans son agent. En revanche, Diamond le fait directement via la fonction DiamondCut de son délégué. Cette différence d’approche signifie que Safe conserve un degré de contrôle plus élevé, tandis que Diamond introduit une plus grande flexibilité et modularité.
• Sécurité : actuellement, déléguécall est utilisé dans les deux structures, ce qui permet à un code externe de manipuler le stockage du contrat principal. Dans l’architecture Safe, déléguécall pointe vers un seul contrat logique, tandis que Diamond utilise déléguécall entre plusieurs contrats de module (plug-ins). Par conséquent, il est possible qu’un plug-in malveillant écrase un autre plug-in, introduisant ainsi un risque de conflits de stockage pouvant compromettre l’intégrité de l’agent.
• Coût : La flexibilité inhérente à l’approche Diamond s’accompagne de problèmes de sécurité accrus. Cela ajoute un facteur de coût et nécessite un audit complet à chaque fois qu’un nouveau plugin est ajouté. La clé est de garantir que ces plugins n’interfèrent pas avec les fonctionnalités des autres, ce qui peut constituer un défi pour les petites et moyennes entreprises qui tentent de maintenir des normes de sécurité strictes.

La « méthode Safe Smart Account » et la « méthode Diamond » sont des exemples de différentes structures impliquant des agents et des modules. Il est essentiel de trouver un équilibre entre flexibilité et sécurité, et les deux approches sont susceptibles de se compléter à l’avenir.

Ordre des modules : validateur, exécuteur et Hook

Développons notre discussion en introduisant le standard proposé par l’équipe Alchemy, ERC 6900, inspiré de Diamond et spécifiquement adapté pour ERC-4337. Il résout le défi de la modularité des comptes intelligents en fournissant une interface commune et en coordonnant le travail entre les développeurs de plugins et de portefeuilles.

En ce qui concerne le processus de transaction d’AA, il existe trois processus principaux : la vérification, l’exécution et le hook. Comme nous l’avons vu précédemment, ces étapes peuvent être gérées en appelant le module à l’aide d’un compte proxy. Même si différents projets peuvent utiliser des noms différents, il est important de saisir une logique sous-jacente similaire.

• Vérification : garantissez l’authenticité et l’autorité du compte de l’appelant.
• Exécution : exécutez toute logique personnalisée autorisée par le compte. *Hook : en tant que module qui s’exécute avant ou après une autre fonction. Cela peut modifier l’état ou entraîner l’annulation de l’intégralité de l’appel.

Séparer les modules en fonction de logiques différentes est crucial. Une approche standardisée devrait spécifier comment les fonctions de vérification, d’exécution et de Hook des comptes de contrats intelligents doivent être écrites. Qu’il s’agisse de Safe ou d’ERC 6900, la normalisation contribue à réduire le besoin d’efforts de développement uniques pour une implémentation ou un écosystème spécifique et évite la dépendance vis-à-vis d’un 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érifiables, ce que l’on pourrait appeler un « registre ». Ce registre est similaire à un « magasin d’applications » conçu pour faciliter un marché modulaire simplifié mais prospère.

Protocole{Core}sûr

Safe{Core} Protocol est un protocole de compte de contrat intelligent open source et interopérable conçu pour accroître l’accessibilité pour une variété de fournisseurs et de développeurs grâce à des normes et des règles clairement définies, tout en maintenant une sécurité renforcée.

• Compte : Dans le protocole Safe{Core}, la notion de compte est flexible et n’est pas restreinte par une implémentation spécifique. Cela permet à divers fournisseurs de services de compte de participer.
• Manager : Manager agit en tant que coordinateur entre les comptes, les registres et les modules. Il est également responsable de la sécurité, agissant comme une couche d’autorisations.
• Registre : le registre définit les attributs de sécurité et applique des normes de module telles que ERC 6900, visant à créer un environnement « App Store » ouvert pour la découverte et la sécurité.
• Modules : les modules gèrent les fonctionnalités et sont fournis sous différents types initiaux, notamment des plugins, des hooks, des validateurs de signature et des gestionnaires de fonctions. Les développeurs peuvent y contribuer à condition de respecter les normes établies.

Conception de strass

Le processus se déroule comme suit :

• Créer une définition de schéma : le schéma sert de structure de données prédéfinie pour la preuve. Les entreprises peuvent personnaliser le modèle en fonction de leurs cas d’utilisation spécifiques.
• Créez un module basé sur un modèle : le contrat intelligent est enregistré en tant que module, obtient le bytecode et sélectionne l’ID du modèle. Ces données sont ensuite stockées dans le registre.
• Obtenir des preuves de modules : les certificateurs/auditeurs peuvent fournir des preuves de modules basées sur le schéma. Ces certificats peuvent inclure des identifiants uniques (UID) et des références à d’autres certificats pour la liaison. Ils peuvent être propagés sur la chaîne et vérifier que certains seuils sont respectés sur la chaîne cible.
• Utilisez des analyseurs pour implémenter une logique complexe : les analyseurs sont éventuellement définis dans le modèle. Ils peuvent être appelés lors de la création du module, de l’établissement de la preuve et du démontage. Ces analyseurs permettent aux développeurs d’incorporer une logique complexe et diversifiée tout en conservant la structure de la preuve.
• Accès convivial aux requêtes : la requête permet aux utilisateurs d’accéder aux informations de sécurité depuis le front-end. L’EIP peut être trouvé ici.

Bien que ce modèle en soit encore à ses débuts, il a le potentiel 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é, aux portefeuilles à intégrer et aux utilisateurs de trouver facilement des modules et de vérifier leurs informations d’attestation. Il pourrait y avoir les utilisations suivantes à l’avenir :

• Certificateur : des entités de confiance, telles que Safe, peuvent coopérer avec Rhinestone en tant que certificateurs pour les modules internes. Dans le même temps, des prouveurs indépendants peuvent également participer.
• Développeurs de modules : avec la formation d’un marché ouvert, il est possible pour les développeurs de modules de commercialiser leur travail via le registre.
• Utilisateurs : grâce à des interfaces conviviales telles que des portefeuilles ou des dApps, les utilisateurs peuvent afficher les informations du module et déléguer la confiance à différents prouveurs.

Le concept de « registre de modules » offre des opportunités rentables aux développeurs de plugins et de modules. Cela pourrait également ouvrir la voie à un « marché des modules ». Certains de ces aspects peuvent être supervisés par l’équipe Safe, tandis que d’autres peuvent se manifester sous la forme de marchés décentralisés qui invitent chacun à contribuer et fournissent une piste d’audit transparente. En adoptant cette approche, nous pouvons éviter la dépendance vis-à-vis d’un fournisseur et soutenir l’expansion d’EVM en offrant une meilleure expérience utilisateur qui attire un public plus large.

Bien que ces méthodes garantissent la sécurité des modules individuels, la sécurité globale des comptes de contrats intelligents n’est pas absolument fiable. Combiner des modules légitimes et prouver qu’ils n’ont pas de conflits de stockage peut être un défi, soulignant l’importance des portefeuilles ou de l’infrastructure AA pour résoudre de tels problèmes.

Résumer

En tirant parti d’une pile de comptes de contrats intelligents modulaire, les fournisseurs de portefeuilles et les dApps peuvent échapper à la complexité de la maintenance technique. Dans le même temps, les développeurs de modules externes ont la possibilité de fournir des services professionnels adaptés aux besoins individuels. Cependant, les défis à relever incluent la recherche d’un équilibre entre flexibilité et sécurité, la promotion de normes modulaires et la mise en œuvre d’interfaces standardisées permettant aux utilisateurs de mettre à niveau et de modifier facilement leurs comptes intelligents.

Cependant, les comptes de contrats intelligents modulaires (SCA) ne sont qu’une pièce du puzzle de l’adoption. Pour exploiter pleinement le potentiel de SCA, la prise en charge de la couche de protocole par des solutions de deuxième couche est également requise, ainsi qu’une infrastructure de regroupement puissante et des pools de mémoire peer-to-peer, des mécanismes de signature SCA plus rentables et réalisables, une synchronisation SCA inter-chaînes. et de gestion, ainsi que le développement d’interfaces conviviales.

Nous envisageons un avenir avec une large participation, ce qui soulève des questions intéressantes : une fois que le processus de commande de SCA deviendra suffisamment rentable, comment les mécanismes traditionnels de valeur extractible par les mineurs (MEV) entreront-ils dans l’espace, créeront-ils des regroupeurs et capteront-ils de la valeur ? Lorsque l’infrastructure arrive à maturité, comment l’abstraction de compte (AA) peut-elle devenir la couche de base pour les transactions « basées sur l’intention » ? Restez à l’écoute car ce domaine est en constante évolution.