*Note de l’éditeur : Les comptes de contrats intelligents (SCA) prennent de l’ampleur et sont soutenus par de nombreux entrepreneurs de base, y compris Vitalik, mais il existe encore de nombreux défis à relever pour l’adoption de la SCA. L’abstraction de compte (AA) a l’avantage d’utiliser la personnalisation du code, mais sa non-interopérabilité introduit des problèmes d’intégration et de dépendance vis-à-vis d’un fournisseur. L’abstraction de compte modulaire vise à créer une structure modulaire pour développer des portefeuilles polyvalents, sécurisés et parfaitement intégrés. *
M. Rui, investisseur chez SevenX Ventures >, a identifié les cinq principaux défis liés à l’adoption de la SCA – l’impact du marché baissier, la difficulté de la migration, les problèmes de signature, les coûts élevés du gaz et les défis d’ingénierie – et en a discuté plus en détail. En outre, une analyse de l’architecture des comptes de contrats intelligents modulaires souligne que la SCA modulaire ne représente qu’une petite partie des défis d’adoption.
Pour exploiter pleinement le potentiel de la SCA, des solutions de couche 2 sont nécessaires pour fournir une prise en charge supplémentaire de la couche de protocole, une infrastructure de regroupement robuste et des pools de mémoire peer-to-peer, un mécanisme de signature SCA plus rentable et plus viable, une synchronisation et une gestion SCA inter-chaînes, et le développement d’interfaces conviviales.
Que se passera-t-il à l’avenir, à mesure que les défis actuels seront résolus et que de plus en plus de personnes adopteront la SCA ? Rui pose également des questions intéressantes. BlockBeats a compilé le texte original comme suit :
Le passage des comptes détenus par des tiers (EOA) aux comptes de contrats intelligents (SCA) prend de l’ampleur et est déjà soutenu par de nombreux entrepreneurs de premier plan, dont Vitalik. Malgré cela, l’adoption de la SCA n’a pas été aussi répandue que celle de l’EOA. Les principaux enjeux comprennent l’impact du marché baissier, la difficulté de migrer de l’EOA vers le DSR, les problèmes de signature, les coûts élevés du gaz et, surtout, les défis liés au développement.
L’avantage le plus important de l’abstraction de compte (AA) est la possibilité de personnaliser les fonctionnalités à l’aide de code. Cependant, la non-interopérabilité des fonctionnalités AA représente un défi majeur, car cette fragmentation entrave l’intégration des AA et renforce la dépendance vis-à-vis d’un fournisseur. De plus, c’est aussi un défi important d’assurer la sécurité tout en étant évolutif et composable.
L’émergence de l’abstraction modulaire des comptes est un créneau dans la tendance AA, une approche innovante qui sépare les comptes intelligents de leurs fonctionnalités personnalisées. L’objectif était de créer une structure modulaire pour développer des portefeuilles dotés de multiples fonctionnalités, d’une sécurité et d’une intégration transparente. À l’avenir, l’abstraction modulaire des comptes permettra un « magasin d’applications » gratuit pour les comptes de contrats intelligents, permettant aux portefeuilles et aux dApps de se concentrer sur l’amélioration de l’expérience utilisateur plutôt que d’avoir à consacrer trop d’efforts à la création de fonctionnalités.
Brève abstraction de compte (AA)
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
L’EOA traditionnelle présente de nombreux défis pour l’exposition des gens à la blockchain, tels que les phrases de récupération, les frais de gaz, les opérations inter-chaînes et les transactions multiples.
L’abstraction de compte s’appuie sur les comptes de contrats intelligents pour permettre une validation et une utilisation programmables. Cela signifie que les utilisateurs seront en mesure d’approuver une série de transactions à la fois, plutôt que d’avoir à signer et à diffuser chaque transaction. L’abstraction de compte peut également permettre d’offrir davantage de fonctionnalités telles que l’amélioration de l’expérience utilisateur (par exemple, l’extraction de gaz et les clés de session), la réduction des coûts (par exemple, les transactions en masse) et l’amélioration de la sécurité (par exemple, la récupération sociale, la multisignature). À l’heure actuelle, il existe deux façons d’abstraire des comptes :
· Couche de protocole : Certains protocoles fournissent nativement une prise en charge native de l’abstraction de compte, les transactions ZKSync utilisent un seul mempool et un seul flux de transaction pour prendre en charge AA, à la fois d’EOA et de SCA suivent le même processus, tandis que Starknet a supprimé EOA, tous les comptes sont SCA et ils ont des portefeuilles de contrats intelligents natifs comme Argent.
· Couche de contrat : pour Ethereum et les L2 similaires, ERC4337 introduit un mempool séparé pour prendre en charge AA sans modifier la couche de consensus. Des sites comme Stackup, Alchemy, Etherspot, Biconomy, Candide et Plimico construisent une infrastructure de bundler, tandis que des choses comme Safe, Zerodev, Etherspot et Biconomy construisent des bundlers et des SDK.
Le dilemme de l’adoption de la SCA
Le sujet de l’abstraction de compte (AA) est discuté depuis 2015 et a été mis en lumière cette année par l’ERC 4337. Cependant, le nombre de comptes de contrats intelligents déployés est encore loin d’être aussi bas que celui de l’EOA.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Penchons-nous sur ce dilemme :
L’impact du marché baissier
Malgré les avantages d’AA tels que la connexion transparente et l’abstraction du gaz, dans le marché baissier actuel, où tous les utilisateurs sont des utilisateurs éduqués d’EOA et où il n’y a pas beaucoup de nouveaux utilisateurs, il n’y a aucune incitation pour les dApps et les portefeuilles à adopter la SCA. Malgré cela, certaines des principales dApps 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 migratoires
Pour les portefeuilles et les applications qui ont déjà accumulé des utilisateurs et des actifs, il reste difficile de migrer les actifs de manière sûre et pratique. Cependant, un système tel que EIP-7377 permet à EOA d’initier une transaction de migration unique.
Problèmes de signature
Le contrat intelligent lui-même ne peut pas signer de messages car il ne dispose pas d’une clé privée comme EOA. Des tentatives comme ERC1271 rendent cela possible, mais la signature des messages ne fonctionne pas avant la première transaction, ce qui pose un défi pour les portefeuilles déployés avec des contrefactuels. L’ERC-6492, proposé par Ambire, est le successeur rétrocompatible de l’ERC-1271 et pourrait être en mesure de résoudre le problème précédent.
Coût de l’essence
Le coût plus élevé du déploiement, de la simulation et de l’exécution de la SCA par rapport à l’EOA standard est également un obstacle à l’adoption. Cependant, certains tests ont été effectués, tels que la séparation de la création de compte des actions de l’utilisateur, l’élimination du « sel » associé à un compte, etc.
Problèmes d’ingénierie
L’équipe ERC-4337 a construit un référentiel eth-infinitism qui fournit une implémentation de base pour les développeurs. Cependant, à mesure que les développeurs évoluent vers des fonctionnalités plus granulaires et spécifiques pour différents cas d’utilisation, l’intégration et le décodage sont confrontés à de plus en plus de défis. Dans cet article, nous allons nous plonger dans les défis d’ingénierie.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
Résolvez les problèmes d’ingénierie avec des comptes de contrats intelligents modulaires
Les défis d’ingénierie peuvent être développés en trois aspects : la fragmentation, la sécurité et l’évolutivité.
· Fragmentation : les fonctionnalités peuvent désormais être activées de différentes manières, que ce soit par le biais d’un SCA spécifique ou d’un système de plug-in autonome. Chaque plate-forme et fournisseur de services suit ses propres normes, ce qui incite les développeurs à décider quelles plates-formes et quels fournisseurs de services prendre en charge. Cela peut conduire à une dépendance potentielle à la plate-forme (fournisseur) ou à un travail redondant.
· Sécurité : si le découplage des comptes et des fonctions offre l’avantage de la flexibilité, il peut également aggraver les problèmes de sécurité. Étant donné que toutes les fonctionnalités peuvent être examinées ensemble, l’absence d’une évaluation indépendante peut augmenter le risque de vulnérabilités des comptes.
· Évolutivité : au fur et à mesure que votre compte se développe, il est important de conserver la possibilité d’ajouter, de remplacer ou de supprimer des fonctionnalités, et chaque mise à jour qui redéploie des fonctionnalités existantes 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 assurer une transition en douceur entre les différents frontends.
Ces termes convergent vers un concept commun : la construction d’une architecture modulaire d’abstraction de compte (Modular AA).
L’abstraction modulaire des comptes est une subdivision du développement plus large des comptes AA qui envisage la modularisation des comptes intelligents afin de fournir des services personnalisés aux utilisateurs et de permettre aux développeurs d’améliorer de manière transparente les fonctionnalités avec un minimum de contraintes.
Cependant, l’établissement et la promotion de nouvelles normes dans n’importe quel secteur constituent un énorme défi. Tant que tout le monde n’acceptera pas la même norme, de nombreuses solutions différentes peuvent émerger dans la phase initiale. Il est encourageant de voir que ceux qui s’efforcent d’affiner et de promouvoir l’abstraction des comptes, qu’il s’agisse du SDK 4337, des portefeuilles, des équipes d’infrastructure ou des concepteurs de couches de protocole, travaillent ensemble pour accélérer ce processus.
Structure modulaire : comptes maîtres et modules
Comment le compte appelle le module pour implémenter la fonction
Déléguer le contrat d’appel et de procuration
Appels externes et délégués :
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
À propos des appels de délégués
Bien qu’un « appel délégué » soit similaire à un « appel », il n’est pas exécuté dans le contexte du contrat cible, mais dans le contexte de l’état actuel du contrat d’appel. Cela signifie que tout changement d’état effectué par le contrat cible modifiera le stockage du contrat d’appel.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Contrats de procuration et appels de délégués
**Pour parvenir à une structure composable et évolutive, un concept de base de « contrat d’agence » doit être introduit. **
Contrat proxy : un contrat normal stocke sa logique et son état, et ne peut pas être mis à jour après le déploiement. Le contrat de proxy est déployé dans un autre contrat à l’aide d’un appel de délégué. Implémentez la fonction par référence pour l’exécuter dans l’état actuel du contrat de procuration.
Cas d’utilisation : bien que le contrat de proxy reste le même, vous pouvez déployer une nouvelle implémentation derrière le répartiteur. Les contrats de procuration sont évolutifs et moins coûteux à déployer et à maintenir sur les blockchains publiques.
Architecture sûre ! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Architecture sécurisée
Qu’est-ce que Safe : Safe est la principale infrastructure modulaire de compte intelligent conçue pour offrir une sécurité et une flexibilité éprouvées, et elle permet aux développeurs de créer diverses applications et portefeuilles. De nombreuses équipes créent des applications sur Safe (ou s’en inspirent). Par exemple, Biconomy a étendu Safe avec le 4337 natif et le multisig 1/1 lors du lancement de son compte de contrat intelligent. Ayant été témoin du déploiement de plus de 164 000 contrats et d’une valeur de plus de 30,7 milliards de dollars, Safe est sans aucun doute un chef de file dans son domaine.
La structure de Safe comprend un contrat de compte sécurisé, un contrat singleton et un contrat de module.
Contrat de procuration : avec état
Le compte sécurisé est un contrat de proxy, car l’appel délégué est un contrat singleton. Un compte de sécurité contient des variables dans lesquelles le propriétaire, le seuil et l’adresse d’implémentation sont tous définis en tant qu’agents, et leur état est défini en fonction de celles-ci.
单例合约(singleton contract) :Integration Hub(无状态)
Le contrat singleton sert les comptes sécurisés et définit différentes intégrations de contrats de module, notamment le plug-in, le hook, le gestionnaire de fonctions et le validateur de signature.
Modules : Logique et fonctionnalités personnalisées
Les contrats de modules sont puissants. Les plugins en tant que types modulaires 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 peuvent servir de pont entre le Web2 et le Web3 en récupérant des données hors chaîne. D’autres modules, tels que les Hooks et les Function Handlers en tant qu’agents de sécurité, peuvent répondre à n’importe quelle commande.
Les changements qui ont changé depuis l’adoption de Safe :
Contrats évolutifs : chaque fois qu’un nouveau plugin est introduit, un nouveau singleton doit être déployé. L’utilisateur conserve l’autonomie nécessaire pour mettre à niveau Safe vers la version singleton souhaitée.
Modules composables et réutilisables : la nature modulaire des plugins permet aux développeurs de développer des fonctionnalités de manière indépendante. Ils sont libres de choisir et de combiner ces plugins en fonction de leur cas d’utilisation, ce qui donne une approche hautement personnalisable.
ERC-2535 Diamond 代理
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
À propos de ERC2535, Diamond Agent :
ERC2535 modèle Diamond standardisé, un système de contrat intelligent modulaire qui peut être mis à niveau/mis à l’échelle après le déploiement sans pratiquement aucune limitation de taille. Actuellement, de nombreuses équipes telles que Kernel de Zerodev et les expériences de Soul Wallet se sont inspirées de la structure de Diamond.
Qu’est-ce que la structure du diamant :**
Diamond Contract : Primary Proxy Contract (Stateful) Diamond est un contrat de proxy qui utilise une méthode d’appel déléguée pour appeler une fonction à partir de son implémentation.
Contrat Module/Plugin/Facette : Logique et fonctionnalité personnalisées (Stateless) Un module ou ce que l’on appelle une facette est un contrat sans état qui peut déployer ses fonctionnalités sur un ou plusieurs Diamonds. Il s’agit de contrats distincts et indépendants qui peuvent partager des fonctions intrinsèques, des bibliothèques et des variables d’état.
Changements avec Diamond :
Contrats évolutifs : Diamond fournit un moyen systématique d’isoler différents plugins et de les connecter entre eux, de partager des données entre eux, et également d’ajouter/remplacer/supprimer n’importe quel plugin directement à l’aide de la fonction diamondCut. Au fil du temps, il n’y aura plus de limite au nombre de plugins pouvant être ajoutés à Diamond.
Plug-ins modulaires et réutilisables : les plug-ins déployés peuvent être utilisés par n’importe quel nombre de Diamonds, ce qui réduit 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, qui s’appuient toutes deux sur leurs contrats proxy de base et font référence à des contrats logiques pour l’évolutivité et la modularité.
La principale différence entre les deux est la gestion des contrats logiques. Spécifiquement:
· Flexibilité : avec un nouveau plug-in activé, Safe doit redéployer son contrat singleton pour mettre en œuvre des modifications dans son proxy. En revanche, Diamond y parvient directement par le biais de la fonction diamondCut dans son contrat de procuration. La différence d’approche signifie que Safe conserve un degré de contrôle plus élevé, tandis que Diamond introduit une flexibilité et une modularité accrues.
· Sécurisé : Actuellement utilisé dans les deux structures, il permet à du code externe de manipuler le stockage du contrat principal. Dans l’architecture Safe, les appels de délégué pointent vers un seul contrat logique, tandis que Diamond utilise des appels de délégué sur plusieurs contrats-plugins de module. Par conséquent, il est possible qu’un plug-in malveillant écrase un autre plug-in, ce qui présente un risque de conflits de stockage et compromet l’intégrité du proxy.
· Coût : Dans l’approche Diamond, flexibilité et sécurité vont de pair. Cela augmente le coût, et chaque fois qu’un nouveau plugin est ajouté, il doit être entièrement audité. La clé est de s’assurer que ces plugins n’interfèrent pas avec les fonctionnalités les uns des autres, un objectif qui est difficile, en particulier pour les petites et moyennes entreprises qui ont du mal à maintenir des normes de sécurité élevées.
La « Safe Smart Account Method » et la « Diamond Method » 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 ces deux approches continueront d’évoluer et de se compléter à l’avenir.
Ordre des modules : validateur, exécuteur et crochet
Discutons-en plus en détail en présentant ERC6900, une norme inspirée de Diamond par l’équipe d’Alchemy qui est spécialement conçue pour l’ERC-4337. Il résout les défis de la modularité des comptes intelligents en fournissant une interface commune et coordonne 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 validation, l’exécution et le rattachement. Comme nous l’avons vu précédemment, ces étapes peuvent toutes être gérées à l’aide du module d’appel de compte proxy. Bien que différents projets puissent utiliser des noms différents, il est important de saisir la logique sous-jacente de la similitude.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
Le nom de la fonction dans différentes conceptions
Validateur : garantit l’authenticité et les autorisations de l’appelant du compte.
Exécution (UTOR) : exécutez toute logique personnalisée autorisée par le compte.
Hook : Agit comme un module qui s’exécute avant ou après une autre fonction. Il peut modifier l’état ou annuler l’ensemble de l’appel.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
Il est important de séparer les modules selon des logiques différentes. L’approche standardisée doit spécifier comment écrire des fonctions de validation, d’exécution et de rattachement pour les comptes de contrats intelligents. Qu’il s’agisse de Safe ou de ERC6900, la standardisation permet de réduire le besoin d’efforts de développement spécifiques à certaines implémentations ou écosystèmes et d’éviter la dépendance vis-à-vis d’un fournisseur.
Découverte et sécurité des modules
Comment trouver et valider des modules de manière ouverte : Une solution en cours de développement consiste à créer une zone qui permet aux utilisateurs de découvrir des modules vérifiables, que l’on peut appeler un « registre ». Le registre fonctionne comme un « magasin d’applications » et vise à favoriser un marché modulaire simplifié mais florissant.
Safe{Core} 协议
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
Le protocole Safe{Core} est un protocole open source et interopérable pour les comptes de contrats intelligents, conçu pour améliorer l’accessibilité pour un large éventail de fournisseurs et de développeurs tout en maintenant une sécurité renforcée grâce à des normes et des règles bien définies.
· Comptes : Dans le protocole Safe{Core}, le concept de comptes est flexible et n’est pas lié à une implémentation spécifique. Cela permet à différents fournisseurs de services de compte de s’impliquer.
· Manager : Le manager agit en tant que coordinateur entre les comptes, les registres et les modules. Il s’occupe également de la sécurité en tant que couche de licence.
· Registre : le registre définit les attributs de sécurité et applique les normes de module telles que ERC6900 créer un environnement ouvert de type « magasin d’applications » pour la découverte et la sécurité.
· Modules : les modules gèrent les fonctionnalités et ont une variété de types initiaux, y compris des plug-ins, des hooks, des validateurs de signature et des gestionnaires de fonctions. Les développeurs peuvent s’impliquer tant qu’ils répondent aux critères établis.
Strass 设计
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
Le processus se déroule comme suit :
· Créer un schéma : un schéma fournit une structure de données prédéfinie. Les gens peuvent l’adapter à leur cas d’utilisation spécifique.
· Créer des modules en fonction du schéma : le contrat intelligent enregistré en tant que module obtient le bytecode et sélectionne l’ID de schéma, et les données sont stockées dans le registre.
· Obtenir l’attestation du module : Le prouveur/auditeur peut fournir une preuve du module en fonction de l’architecture. Ces attestations peuvent inclure un identifiant unique (UID) et des références à d’autres attestations utilisées pour le lien. Ils peuvent se propager à travers les chaînes et vérifier que la chaîne cible atteint certains seuils.
· Implémenter une logique complexe avec un résolveur : l’analyseur syntaxique (facultatif) entre en jeu. Ils peuvent être appelés lors de la création du module, de l’établissement de l’attestation et de la révocation. Ces analyseurs permettent aux développeurs d’intégrer une logique complexe et diversifiée tout en conservant des structures de preuve.
Accès convivial aux requêtes : Query permet aux utilisateurs d’accéder aux informations de sécurité à partir du front-end.
Bien que le modèle n’en soit encore qu’à ses débuts, il a le potentiel d’établir des normes de manière décentralisée et collaborative. Le registre permet aux développeurs d’enregistrer leurs modules, aux auditeurs de vérifier leur sécurité, aux portefeuilles d’intégrer, et permet aux utilisateurs de trouver facilement des modules et de vérifier leurs informations d’attestation. Plusieurs utilisations futures pourraient être :
· Attesteur : une entité de confiance comme Safe peut travailler avec Rhinestone en tant que prouveur pour les modules internes. Dans le même temps, les certificateurs indépendants peuvent également s’inscrire.
· Développeur de modules : Avec la formation d’une place de marché ouverte, il est possible pour les développeurs de modules de monétiser leur travail par le biais d’un registre.
· Utilisateurs : La participation via une interface conviviale, telle qu’un portefeuille ou une dApp, permet aux utilisateurs de vérifier les informations du module et de déléguer la confiance à différents prouveurs.
Le concept de « registre de modules » ouvre des possibilités de monétisation pour les développeurs de plugins et de modules. Cela pourrait encore ouvrir la voie à un « marché des modules ». Certains aspects peuvent être supervisés par l’équipe Safe, tandis que d’autres peuvent se manifester sous la forme d’une place de marché décentralisée qui invite tout le monde à contribuer et fournit une piste d’audit transparente. L’intégration de cette solution permet d’éviter la dépendance vis-à-vis d’un fournisseur et de soutenir l’expansion de l’EVM en ajoutant une expérience utilisateur améliorée qui s’adresse à un public plus large.
Bien que ces méthodes garantissent la sécurité des modules individuels, les comptes de contrats intelligents ne sont pas infaillibles lorsqu’il s’agit d’une sécurité plus large. Il peut être difficile de les combiner avec des modules de conformité et de prouver qu’ils n’ont pas de conflits de stockage, ce qui souligne l’importance des portefeuilles ou de l’infrastructure AA pour résoudre ces problèmes.
Résumé
En tirant parti d’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. Dans le même temps, les développeurs de modules externes ont la possibilité de fournir des services professionnels personnalisés. Cependant, les défis à relever comprennent la recherche d’un équilibre entre flexibilité et sécurité, la mise en place de normes modulaires et la mise en œuvre d’interfaces standardisées qui permettent aux utilisateurs de mettre à niveau et de modifier facilement leurs comptes intelligents.
De plus, les comptes modulaires de contrats intelligents (SCA) ne sont qu’une petite partie du puzzle de l’adoption. Pour réaliser le plein potentiel de la SCA, des solutions de couche 2 sont nécessaires pour fournir une prise en charge supplémentaire de la couche de protocole, telle qu’une infrastructure de regroupement robuste et des pools de mémoire peer-to-peer, un mécanisme de signature SCA plus rentable et plus viable, des mécanismes de synchronisation et de gestion SCA inter-chaînes, et le développement d’interfaces conviviales.
À l’avenir, il y aura une plus grande adoption de la SCA, mais cela soulèvera également des questions intéressantes : comment les mécanismes traditionnels de la valeur extractible des mineurs (MEV) entreront-ils dans l’espace pour créer des bundlers et capturer de la valeur une fois que le flux d’ordres SCA sera suffisamment rentable, et comment l’abstraction de compte (AA) servira-t-elle de couche de base pour les transactions « basées sur l’intention » lorsque l’infrastructure arrivera à maturité ?
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Un examen approfondi des architectures et des défis des comptes de contrats intelligents modulaires
作者 :Rui,Investisseur de SevenX Ventures
编译 :Luccy,Joyce,BlockBeats
M. Rui, investisseur chez SevenX Ventures >, a identifié les cinq principaux défis liés à l’adoption de la SCA – l’impact du marché baissier, la difficulté de la migration, les problèmes de signature, les coûts élevés du gaz et les défis d’ingénierie – et en a discuté plus en détail. En outre, une analyse de l’architecture des comptes de contrats intelligents modulaires souligne que la SCA modulaire ne représente qu’une petite partie des défis d’adoption.
Le passage des comptes détenus par des tiers (EOA) aux comptes de contrats intelligents (SCA) prend de l’ampleur et est déjà soutenu par de nombreux entrepreneurs de premier plan, dont Vitalik. Malgré cela, l’adoption de la SCA n’a pas été aussi répandue que celle de l’EOA. Les principaux enjeux comprennent l’impact du marché baissier, la difficulté de migrer de l’EOA vers le DSR, les problèmes de signature, les coûts élevés du gaz et, surtout, les défis liés au développement.
L’avantage le plus important de l’abstraction de compte (AA) est la possibilité de personnaliser les fonctionnalités à l’aide de code. Cependant, la non-interopérabilité des fonctionnalités AA représente un défi majeur, car cette fragmentation entrave l’intégration des AA et renforce la dépendance vis-à-vis d’un fournisseur. De plus, c’est aussi un défi important d’assurer la sécurité tout en étant évolutif et composable.
L’émergence de l’abstraction modulaire des comptes est un créneau dans la tendance AA, une approche innovante qui sépare les comptes intelligents de leurs fonctionnalités personnalisées. L’objectif était de créer une structure modulaire pour développer des portefeuilles dotés de multiples fonctionnalités, d’une sécurité et d’une intégration transparente. À l’avenir, l’abstraction modulaire des comptes permettra un « magasin d’applications » gratuit pour les comptes de contrats intelligents, permettant aux portefeuilles et aux dApps de se concentrer sur l’amélioration de l’expérience utilisateur plutôt que d’avoir à consacrer trop d’efforts à la création de fonctionnalités.
Brève abstraction de compte (AA)
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
L’EOA traditionnelle présente de nombreux défis pour l’exposition des gens à la blockchain, tels que les phrases de récupération, les frais de gaz, les opérations inter-chaînes et les transactions multiples.
L’abstraction de compte s’appuie sur les comptes de contrats intelligents pour permettre une validation et une utilisation programmables. Cela signifie que les utilisateurs seront en mesure d’approuver une série de transactions à la fois, plutôt que d’avoir à signer et à diffuser chaque transaction. L’abstraction de compte peut également permettre d’offrir davantage de fonctionnalités telles que l’amélioration de l’expérience utilisateur (par exemple, l’extraction de gaz et les clés de session), la réduction des coûts (par exemple, les transactions en masse) et l’amélioration de la sécurité (par exemple, la récupération sociale, la multisignature). À l’heure actuelle, il existe deux façons d’abstraire des comptes :
· Couche de protocole : Certains protocoles fournissent nativement une prise en charge native de l’abstraction de compte, les transactions ZKSync utilisent un seul mempool et un seul flux de transaction pour prendre en charge AA, à la fois d’EOA et de SCA suivent le même processus, tandis que Starknet a supprimé EOA, tous les comptes sont SCA et ils ont des portefeuilles de contrats intelligents natifs comme Argent.
· Couche de contrat : pour Ethereum et les L2 similaires, ERC4337 introduit un mempool séparé pour prendre en charge AA sans modifier la couche de consensus. Des sites comme Stackup, Alchemy, Etherspot, Biconomy, Candide et Plimico construisent une infrastructure de bundler, tandis que des choses comme Safe, Zerodev, Etherspot et Biconomy construisent des bundlers et des SDK.
Le dilemme de l’adoption de la SCA
Le sujet de l’abstraction de compte (AA) est discuté depuis 2015 et a été mis en lumière cette année par l’ERC 4337. Cependant, le nombre de comptes de contrats intelligents déployés est encore loin d’être aussi bas que celui de l’EOA.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Penchons-nous sur ce dilemme :
Malgré les avantages d’AA tels que la connexion transparente et l’abstraction du gaz, dans le marché baissier actuel, où tous les utilisateurs sont des utilisateurs éduqués d’EOA et où il n’y a pas beaucoup de nouveaux utilisateurs, il n’y a aucune incitation pour les dApps et les portefeuilles à adopter la SCA. Malgré cela, certaines des principales dApps 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.
Pour les portefeuilles et les applications qui ont déjà accumulé des utilisateurs et des actifs, il reste difficile de migrer les actifs de manière sûre et pratique. Cependant, un système tel que EIP-7377 permet à EOA d’initier une transaction de migration unique.
Le contrat intelligent lui-même ne peut pas signer de messages car il ne dispose pas d’une clé privée comme EOA. Des tentatives comme ERC1271 rendent cela possible, mais la signature des messages ne fonctionne pas avant la première transaction, ce qui pose un défi pour les portefeuilles déployés avec des contrefactuels. L’ERC-6492, proposé par Ambire, est le successeur rétrocompatible de l’ERC-1271 et pourrait être en mesure de résoudre le problème précédent.
Le coût plus élevé du déploiement, de la simulation et de l’exécution de la SCA par rapport à l’EOA standard est également un obstacle à l’adoption. Cependant, certains tests ont été effectués, tels que la séparation de la création de compte des actions de l’utilisateur, l’élimination du « sel » associé à un compte, etc.
L’équipe ERC-4337 a construit un référentiel eth-infinitism qui fournit une implémentation de base pour les développeurs. Cependant, à mesure que les développeurs évoluent vers des fonctionnalités plus granulaires et spécifiques pour différents cas d’utilisation, l’intégration et le décodage sont confrontés à de plus en plus de défis. Dans cet article, nous allons nous plonger dans les défis d’ingénierie.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
Résolvez les problèmes d’ingénierie avec des comptes de contrats intelligents modulaires
Les défis d’ingénierie peuvent être développés en trois aspects : la fragmentation, la sécurité et l’évolutivité.
· Fragmentation : les fonctionnalités peuvent désormais être activées de différentes manières, que ce soit par le biais d’un SCA spécifique ou d’un système de plug-in autonome. Chaque plate-forme et fournisseur de services suit ses propres normes, ce qui incite les développeurs à décider quelles plates-formes et quels fournisseurs de services prendre en charge. Cela peut conduire à une dépendance potentielle à la plate-forme (fournisseur) ou à un travail redondant.
· Sécurité : si le découplage des comptes et des fonctions offre l’avantage de la flexibilité, il peut également aggraver les problèmes de sécurité. Étant donné que toutes les fonctionnalités peuvent être examinées ensemble, l’absence d’une évaluation indépendante peut augmenter le risque de vulnérabilités des comptes.
· Évolutivité : au fur et à mesure que votre compte se développe, il est important de conserver la possibilité d’ajouter, de remplacer ou de supprimer des fonctionnalités, et chaque mise à jour qui redéploie des fonctionnalités existantes 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 assurer une transition en douceur entre les différents frontends.
Ces termes convergent vers un concept commun : la construction d’une architecture modulaire d’abstraction de compte (Modular AA).
L’abstraction modulaire des comptes est une subdivision du développement plus large des comptes AA qui envisage la modularisation des comptes intelligents afin de fournir des services personnalisés aux utilisateurs et de permettre aux développeurs d’améliorer de manière transparente les fonctionnalités avec un minimum de contraintes.
Cependant, l’établissement et la promotion de nouvelles normes dans n’importe quel secteur constituent un énorme défi. Tant que tout le monde n’acceptera pas la même norme, de nombreuses solutions différentes peuvent émerger dans la phase initiale. Il est encourageant de voir que ceux qui s’efforcent d’affiner et de promouvoir l’abstraction des comptes, qu’il s’agisse du SDK 4337, des portefeuilles, des équipes d’infrastructure ou des concepteurs de couches de protocole, travaillent ensemble pour accélérer ce processus.
Structure modulaire : comptes maîtres et modules
Comment le compte appelle le module pour implémenter la fonction
Déléguer le contrat d’appel et de procuration
Appels externes et délégués :
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
À propos des appels de délégués
Bien qu’un « appel délégué » soit similaire à un « appel », il n’est pas exécuté dans le contexte du contrat cible, mais dans le contexte de l’état actuel du contrat d’appel. Cela signifie que tout changement d’état effectué par le contrat cible modifiera le stockage du contrat d’appel.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Contrats de procuration et appels de délégués
**Pour parvenir à une structure composable et évolutive, un concept de base de « contrat d’agence » doit être introduit. **
Contrat proxy : un contrat normal stocke sa logique et son état, et ne peut pas être mis à jour après le déploiement. Le contrat de proxy est déployé dans un autre contrat à l’aide d’un appel de délégué. Implémentez la fonction par référence pour l’exécuter dans l’état actuel du contrat de procuration.
Cas d’utilisation : bien que le contrat de proxy reste le même, vous pouvez déployer une nouvelle implémentation derrière le répartiteur. Les contrats de procuration sont évolutifs et moins coûteux à déployer et à maintenir sur les blockchains publiques.
Architecture sûre ! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Architecture sécurisée
Qu’est-ce que Safe : Safe est la principale infrastructure modulaire de compte intelligent conçue pour offrir une sécurité et une flexibilité éprouvées, et elle permet aux développeurs de créer diverses applications et portefeuilles. De nombreuses équipes créent des applications sur Safe (ou s’en inspirent). Par exemple, Biconomy a étendu Safe avec le 4337 natif et le multisig 1/1 lors du lancement de son compte de contrat intelligent. Ayant été témoin du déploiement de plus de 164 000 contrats et d’une valeur de plus de 30,7 milliards de dollars, Safe est sans aucun doute un chef de file dans son domaine.
La structure de Safe comprend un contrat de compte sécurisé, un contrat singleton et un contrat de module.
Contrat de procuration : avec état
Le compte sécurisé est un contrat de proxy, car l’appel délégué est un contrat singleton. Un compte de sécurité contient des variables dans lesquelles le propriétaire, le seuil et l’adresse d’implémentation sont tous définis en tant qu’agents, et leur état est défini en fonction de celles-ci.
单例合约(singleton contract) :Integration Hub(无状态)
Le contrat singleton sert les comptes sécurisés et définit différentes intégrations de contrats de module, notamment le plug-in, le hook, le gestionnaire de fonctions et le validateur de signature.
Modules : Logique et fonctionnalités personnalisées
Les contrats de modules sont puissants. Les plugins en tant que types modulaires 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 peuvent servir de pont entre le Web2 et le Web3 en récupérant des données hors chaîne. D’autres modules, tels que les Hooks et les Function Handlers en tant qu’agents de sécurité, peuvent répondre à n’importe quelle commande.
Les changements qui ont changé depuis l’adoption de Safe :
Contrats évolutifs : chaque fois qu’un nouveau plugin est introduit, un nouveau singleton doit être déployé. L’utilisateur conserve l’autonomie nécessaire pour mettre à niveau Safe vers la version singleton souhaitée.
Modules composables et réutilisables : la nature modulaire des plugins permet aux développeurs de développer des fonctionnalités de manière indépendante. Ils sont libres de choisir et de combiner ces plugins en fonction de leur cas d’utilisation, ce qui donne une approche hautement personnalisable.
ERC-2535 Diamond 代理
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
À propos de ERC2535, Diamond Agent :
ERC2535 modèle Diamond standardisé, un système de contrat intelligent modulaire qui peut être mis à niveau/mis à l’échelle après le déploiement sans pratiquement aucune limitation de taille. Actuellement, de nombreuses équipes telles que Kernel de Zerodev et les expériences de Soul Wallet se sont inspirées de la structure de Diamond.
Qu’est-ce que la structure du diamant :**
Diamond Contract : Primary Proxy Contract (Stateful) Diamond est un contrat de proxy qui utilise une méthode d’appel déléguée pour appeler une fonction à partir de son implémentation.
Contrat Module/Plugin/Facette : Logique et fonctionnalité personnalisées (Stateless) Un module ou ce que l’on appelle une facette est un contrat sans état qui peut déployer ses fonctionnalités sur un ou plusieurs Diamonds. Il s’agit de contrats distincts et indépendants qui peuvent partager des fonctions intrinsèques, des bibliothèques et des variables d’état.
Changements avec Diamond :
Contrats évolutifs : Diamond fournit un moyen systématique d’isoler différents plugins et de les connecter entre eux, de partager des données entre eux, et également d’ajouter/remplacer/supprimer n’importe quel plugin directement à l’aide de la fonction diamondCut. Au fil du temps, il n’y aura plus de limite au nombre de plugins pouvant être ajoutés à Diamond.
Plug-ins modulaires et réutilisables : les plug-ins déployés peuvent être utilisés par n’importe quel nombre de Diamonds, ce qui réduit 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, qui s’appuient toutes deux sur leurs contrats proxy de base et font référence à des contrats logiques pour l’évolutivité et la modularité.
La principale différence entre les deux est la gestion des contrats logiques. Spécifiquement:
· Flexibilité : avec un nouveau plug-in activé, Safe doit redéployer son contrat singleton pour mettre en œuvre des modifications dans son proxy. En revanche, Diamond y parvient directement par le biais de la fonction diamondCut dans son contrat de procuration. La différence d’approche signifie que Safe conserve un degré de contrôle plus élevé, tandis que Diamond introduit une flexibilité et une modularité accrues.
· Sécurisé : Actuellement utilisé dans les deux structures, il permet à du code externe de manipuler le stockage du contrat principal. Dans l’architecture Safe, les appels de délégué pointent vers un seul contrat logique, tandis que Diamond utilise des appels de délégué sur plusieurs contrats-plugins de module. Par conséquent, il est possible qu’un plug-in malveillant écrase un autre plug-in, ce qui présente un risque de conflits de stockage et compromet l’intégrité du proxy.
· Coût : Dans l’approche Diamond, flexibilité et sécurité vont de pair. Cela augmente le coût, et chaque fois qu’un nouveau plugin est ajouté, il doit être entièrement audité. La clé est de s’assurer que ces plugins n’interfèrent pas avec les fonctionnalités les uns des autres, un objectif qui est difficile, en particulier pour les petites et moyennes entreprises qui ont du mal à maintenir des normes de sécurité élevées.
La « Safe Smart Account Method » et la « Diamond Method » 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 ces deux approches continueront d’évoluer et de se compléter à l’avenir.
Ordre des modules : validateur, exécuteur et crochet
Discutons-en plus en détail en présentant ERC6900, une norme inspirée de Diamond par l’équipe d’Alchemy qui est spécialement conçue pour l’ERC-4337. Il résout les défis de la modularité des comptes intelligents en fournissant une interface commune et coordonne 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 validation, l’exécution et le rattachement. Comme nous l’avons vu précédemment, ces étapes peuvent toutes être gérées à l’aide du module d’appel de compte proxy. Bien que différents projets puissent utiliser des noms différents, il est important de saisir la logique sous-jacente de la similitude.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
Le nom de la fonction dans différentes conceptions
Validateur : garantit l’authenticité et les autorisations de l’appelant du compte.
Exécution (UTOR) : exécutez toute logique personnalisée autorisée par le compte.
Hook : Agit comme un module qui s’exécute avant ou après une autre fonction. Il peut modifier l’état ou annuler l’ensemble de l’appel.
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
Il est important de séparer les modules selon des logiques différentes. L’approche standardisée doit spécifier comment écrire des fonctions de validation, d’exécution et de rattachement pour les comptes de contrats intelligents. Qu’il s’agisse de Safe ou de ERC6900, la standardisation permet de réduire le besoin d’efforts de développement spécifiques à certaines implémentations ou écosystèmes et d’éviter la dépendance vis-à-vis d’un fournisseur.
Découverte et sécurité des modules
Comment trouver et valider des modules de manière ouverte : Une solution en cours de développement consiste à créer une zone qui permet aux utilisateurs de découvrir des modules vérifiables, que l’on peut appeler un « registre ». Le registre fonctionne comme un « magasin d’applications » et vise à favoriser un marché modulaire simplifié mais florissant.
Safe{Core} 协议
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
Le protocole Safe{Core} est un protocole open source et interopérable pour les comptes de contrats intelligents, conçu pour améliorer l’accessibilité pour un large éventail de fournisseurs et de développeurs tout en maintenant une sécurité renforcée grâce à des normes et des règles bien définies.
· Comptes : Dans le protocole Safe{Core}, le concept de comptes est flexible et n’est pas lié à une implémentation spécifique. Cela permet à différents fournisseurs de services de compte de s’impliquer.
· Manager : Le manager agit en tant que coordinateur entre les comptes, les registres et les modules. Il s’occupe également de la sécurité en tant que couche de licence.
· Registre : le registre définit les attributs de sécurité et applique les normes de module telles que ERC6900 créer un environnement ouvert de type « magasin d’applications » pour la découverte et la sécurité.
· Modules : les modules gèrent les fonctionnalités et ont une variété de types initiaux, y compris des plug-ins, des hooks, des validateurs de signature et des gestionnaires de fonctions. Les développeurs peuvent s’impliquer tant qu’ils répondent aux critères établis.
Strass 设计
! [Un examen approfondi de l’architecture et des défis des comptes de contrats intelligents modulaires] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
Le processus se déroule comme suit :
· Créer un schéma : un schéma fournit une structure de données prédéfinie. Les gens peuvent l’adapter à leur cas d’utilisation spécifique.
· Créer des modules en fonction du schéma : le contrat intelligent enregistré en tant que module obtient le bytecode et sélectionne l’ID de schéma, et les données sont stockées dans le registre.
· Obtenir l’attestation du module : Le prouveur/auditeur peut fournir une preuve du module en fonction de l’architecture. Ces attestations peuvent inclure un identifiant unique (UID) et des références à d’autres attestations utilisées pour le lien. Ils peuvent se propager à travers les chaînes et vérifier que la chaîne cible atteint certains seuils.
· Implémenter une logique complexe avec un résolveur : l’analyseur syntaxique (facultatif) entre en jeu. Ils peuvent être appelés lors de la création du module, de l’établissement de l’attestation et de la révocation. Ces analyseurs permettent aux développeurs d’intégrer une logique complexe et diversifiée tout en conservant des structures de preuve.
Accès convivial aux requêtes : Query permet aux utilisateurs d’accéder aux informations de sécurité à partir du front-end.
Bien que le modèle n’en soit encore qu’à ses débuts, il a le potentiel d’établir des normes de manière décentralisée et collaborative. Le registre permet aux développeurs d’enregistrer leurs modules, aux auditeurs de vérifier leur sécurité, aux portefeuilles d’intégrer, et permet aux utilisateurs de trouver facilement des modules et de vérifier leurs informations d’attestation. Plusieurs utilisations futures pourraient être :
· Attesteur : une entité de confiance comme Safe peut travailler avec Rhinestone en tant que prouveur pour les modules internes. Dans le même temps, les certificateurs indépendants peuvent également s’inscrire.
· Développeur de modules : Avec la formation d’une place de marché ouverte, il est possible pour les développeurs de modules de monétiser leur travail par le biais d’un registre.
· Utilisateurs : La participation via une interface conviviale, telle qu’un portefeuille ou une dApp, permet aux utilisateurs de vérifier les informations du module et de déléguer la confiance à différents prouveurs.
Le concept de « registre de modules » ouvre des possibilités de monétisation pour les développeurs de plugins et de modules. Cela pourrait encore ouvrir la voie à un « marché des modules ». Certains aspects peuvent être supervisés par l’équipe Safe, tandis que d’autres peuvent se manifester sous la forme d’une place de marché décentralisée qui invite tout le monde à contribuer et fournit une piste d’audit transparente. L’intégration de cette solution permet d’éviter la dépendance vis-à-vis d’un fournisseur et de soutenir l’expansion de l’EVM en ajoutant une expérience utilisateur améliorée qui s’adresse à un public plus large.
Bien que ces méthodes garantissent la sécurité des modules individuels, les comptes de contrats intelligents ne sont pas infaillibles lorsqu’il s’agit d’une sécurité plus large. Il peut être difficile de les combiner avec des modules de conformité et de prouver qu’ils n’ont pas de conflits de stockage, ce qui souligne l’importance des portefeuilles ou de l’infrastructure AA pour résoudre ces problèmes.
Résumé
En tirant parti d’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. Dans le même temps, les développeurs de modules externes ont la possibilité de fournir des services professionnels personnalisés. Cependant, les défis à relever comprennent la recherche d’un équilibre entre flexibilité et sécurité, la mise en place de normes modulaires et la mise en œuvre d’interfaces standardisées qui permettent aux utilisateurs de mettre à niveau et de modifier facilement leurs comptes intelligents.
De plus, les comptes modulaires de contrats intelligents (SCA) ne sont qu’une petite partie du puzzle de l’adoption. Pour réaliser le plein potentiel de la SCA, des solutions de couche 2 sont nécessaires pour fournir une prise en charge supplémentaire de la couche de protocole, telle qu’une infrastructure de regroupement robuste et des pools de mémoire peer-to-peer, un mécanisme de signature SCA plus rentable et plus viable, des mécanismes de synchronisation et de gestion SCA inter-chaînes, et le développement d’interfaces conviviales.
À l’avenir, il y aura une plus grande adoption de la SCA, mais cela soulèvera également des questions intéressantes : comment les mécanismes traditionnels de la valeur extractible des mineurs (MEV) entreront-ils dans l’espace pour créer des bundlers et capturer de la valeur une fois que le flux d’ordres SCA sera suffisamment rentable, et comment l’abstraction de compte (AA) servira-t-elle de couche de base pour les transactions « basées sur l’intention » lorsque l’infrastructure arrivera à maturité ?