OKX Ventures : Analyse systématique de la trajectoire du compte abstrait, passé, présent et futur
TechFlow SélectionTechFlow Sélection
OKX Ventures : Analyse systématique de la trajectoire du compte abstrait, passé, présent et futur
OKX Ventures aborde ce concept en partant de son origine, offrant un aperçu systématique du passé, de l'état actuel et des opportunités futures liées à l'abstraction des comptes.
Dédié à des analyses Web3 approfondiesAuteur : Kiwi, chercheur chez OKX Ventures
Cet article ne constitue aucun conseil d'investissement.
Depuis que Vitalik Buterin a proposé l'EIP-4337 en septembre 2021, le concept de compte abstrait (account abstraction) est progressivement intégré aux portefeuilles Web3 grand public. OKX Ventures prend ce concept comme point d'entrée pour reconstituer systématiquement l’histoire, l’état actuel et les opportunités futures de l’abstraction des comptes.
Points clés de l'article
À propos des informations de base :
-
L’abstraction du compte (AA), qui prend en charge les clés de session, permet de découpler la source des transactions et la signature. Elle aide les utilisateurs à éviter des opérations complexes telles que la sauvegarde des clés privées ou le paiement des frais de gaz, réduisant ainsi le seuil d’entrée dans l’écosystème Web3 ;
-
Pour simplifier les types de comptes, offrir plus de liberté aux actions sur chaîne et placer les comptes à un niveau de sécurité supérieur, l’abstraction des comptes s’avère nécessaire.
-
Après avoir traversé les EIP-86, EIP-1014, EIP-2938 et EIP-3074, l’EIP-4337 est désormais considéré comme la version finale de l’AA sur Ethereum, car il n’exige aucune modification de la couche de consensus.
Deux voies vers l’abstraction multi-chaînes : méthode compatible avec 4337 (4337 compatible method) et solution native d’abstraction des comptes (native account abstraction).
-
Solution compatible avec 4337 : Actuellement, Arbitrum, Polygon, Optimism et BNB n’intègrent pas nativement l’abstraction des comptes. Toutefois, ils prennent en charge cette fonctionnalité via des produits liés à 4337 (comme Biconomy, Stackup, etc.), bien que le déploiement des infrastructures en soit encore au stade conceptuel ;
-
Solution native d’abstraction des comptes : Starknet et zkSync intègrent nativement l’abstraction des comptes, contrairement à la solution 4337. Différences notables : Starknet n’a ni Bundler ni Paymaster, c’est le Séquenceur (Sequencer) qui détermine l’ordre des transactions, paie les frais de gaz et exécute celles-ci. zkSync utilise quant à lui un Opérateur (Operator) pour définir l’ordre des transactions et payer les frais, puis invoque le bootloader pour effectuer les opérations.
Données de développement : Plus de 520 000 comptes AA ont été déployés sur Ethereum, Arbitrum, Optimism et Polygon. Parmi eux, plus de 80 % ont été créés entre juillet et août, principalement grâce à la forte croissance observée sur Polygon et Optimism après le lancement de nouveaux produits AA. Les protocoles impliqués dans les rôles de Bundler et Paymaster restent peu nombreux, avec une domination quasi totale par des projets tels que Pimlico et StackUp sur toutes les chaînes.
Les opportunités offertes par l’AA :
-
Le Paymaster est un contrat intelligent déployé par une dApp. Il est activé par le Bundler afin de payer les frais de gaz pour une UserOperation spécifique. Le Paymaster étant un service standardisé, difficilement viable en tant que projet autonome, il peut être intégré comme fonctionnalité par des services web2 pour servir leurs activités web3. Opportunités commerciales pour les payeurs : passerelle de trafic, échange automatique, intégration avec des projets DeFi ou jeux pour rediriger le trafic — phénomène similaire aux innovations dans l’industrie des paiements. Bien que l’innovation autour du Paymaster soit limitée, il s’agit du maillon le plus stable en termes de capture de valeur, abaissant le seuil d’entrée des utilisateurs web2 vers le web3, ce qui pourrait inciter de nombreuses institutions web2 à déployer leurs propres services Paymaster.
-
Le Bundler est l’un des composants les plus prometteurs, dont l’essence ressemble à celle d’un relayer. Ses sources de revenus proviennent principalement du regroupement de transactions, notamment la marge sur les frais de gaz, la MEV et des pools privés orientés vers les besoins B2B. Toutefois, un échec de traitement des transactions entraîne des pertes pour le Bundler, rendant le choix des transactions critique.
-
Les protocoles disposant déjà de nœuds ou de services Relayer peuvent construire leur réseau de Bundlers plus facilement. Par exemple, un service RPC peut aider à décentraliser le Bundler en tant qu’infrastructure distribuée ;
-
Une collaboration entre le Bundler, le Searcher et le Sequencer s'avère être un meilleur choix. À l’avenir, des partages MEV pourraient redistribuer les revenus aux utilisateurs via divers canaux, rendant le système de plus en plus équitable ;
-
Actuellement, tous les Bundlers sont des pools privés, sans pool public. Seul Stackup affiche une bonne performance et rentabilité, tandis que Biconomy se situe au niveau moyen ;
-
Le Bundler est un bien public très utile mais difficilement rentable. Aucun modèle mature de gestion de biens publics n'existe sur le marché, et la plupart des projets préfèrent le garder privé pour des raisons de profitabilité ;
-
Les axes d'amélioration technique du Bundler incluent : éviter les collisions de nonce, pouvant être optimisées via marquage et suppression dans un réseau p2p ; et résoudre les cas où la modification du storage du contrat empêche le Bundler d’obtenir une compensation suffisante, nécessitant des propositions ultérieures pour améliorer ces points.
-
-
Combinaison de l’AA et de la MEV : L’AA, le Sequencer et l’intention (intent) prolongent essentiellement la chaîne d’opérations sur chaîne, allongeant ainsi la chaîne de corruption potentielle pour la MEV. Tant le Bundler AA que le solveur d’intentions pourraient collaborer avec des rôles comme le Searcher dans la chaîne MEV, formant un modèle de partage MEV. Du fait que l’AA fournit un Bundler et un contrat EntryPoint, il devrait théoriquement pouvoir participer au partage du revenu PEV (Prover Extractable Value) ;
-
NFT : L’amélioration de l’expérience utilisateur attire davantage de nouveaux utilisateurs, tout en rendant la surveillance et les transactions du marché plus automatisées. ERC6551 et 4337 offrent tous deux des capacités de compte au niveau perçu par l’utilisateur, pouvant être intégrés à des jeux multichaînes, des identités décentralisées (DID) et des middlewares. Les futurs jeux multichaînes auront besoin de la compositabilité d’ERC-6551 pour proposer des expériences de jeu combinant plusieurs chaînes et des comptes équipables échangeables ;
-
Social et jeux : L’optimisation des infrastructures d’identité améliore considérablement l’ergonomie des produits. La baisse du seuil d’entrée dans les jeux multichaînes, associée à l’optimisation du modèle de compte et du système multichaîne, ouvre la voie à des univers de jeux multichaînes ;
AA et intention (intent) :
-
Fondamentalement, l’intention n’est pas intrinsèquement liée à l’AA. L’intention relève de l’innovation au niveau de l’expérience utilisateur, consistant à mieux comprendre et décomposer les besoins de l’utilisateur pour les transformer en une ou plusieurs UserOperations ; l’AA, quant à lui, correspond à une optimisation backend, visant à exécuter plus efficacement les instructions de l’utilisateur. Un bot Telegram illustre parfaitement l’innovation par l’intention, même si son backend repose toujours sur un portefeuille EOA, sans impact sur l’expérience utilisateur.
-
L’intention consiste à trouver le chemin optimal d’opérations pour atteindre un objectif donné. Jusqu’à présent, les intentions étaient simples, mais elles pourraient évoluer vers des problèmes complexes comportant plusieurs conditions, étapes et environnements d’exécution, voire intégrant des agents IA.
-
Opportunités liées aux intentions : Réduction du nombre de signatures côté utilisateur, améliorant ainsi l’expérience. Côté application, les intentions peuvent fonder de nouvelles infrastructures, langages et méthodes de résolution, faisant de ce domaine l’une des applications les plus prometteuses à venir.
-
Pools intermédiaires d'intentions ou blockchain spécialisée dans les intentions : Les applications basées sur les intentions impliquent non seulement un nouveau format de message pour interagir avec les contrats intelligents, mais aussi de nouveaux mécanismes de découverte et de mise en relation des contreparties, remplaçant la mempool traditionnelle. Concevoir un tel mécanisme compatible avec les incitations et évitant la centralisation s’avère particulièrement difficile.
-
Diversification des chemins d’implémentation des solveurs : À court terme, les super contrats intelligents matures seront les premiers intégrés. À long terme, les agents IA, bien plus flexibles, représenteront la forme idéale, bien que leur réalisation reste extrêmement complexe. Les solveurs introduiront un nouveau paradigme : prétraitement hors chaîne suivi d’exécution sur chaîne, bénéficiant à certains protocoles d’automatisation (comme Uniswap X). Actuellement, le coprocesseur ZK Axiom peut servir de démonstration pour les solveurs privés.
-
Nouveaux langages pour exprimer les intentions : Des projets comme Juvix et Essential existent déjà. Ces projets doivent bénéficier d’un avantage précoce et instaurer rapidement la confiance auprès des utilisateurs ;
-
-
Opportunités pour les portefeuilles et les points d’entrée : Les portefeuilles peuvent entièrement jouer le rôle de couche d’intention, augmentant considérablement leur importance stratégique. Ils peuvent devenir des infrastructures vitales pour attirer des utilisateurs vers différents protocoles. Le backend des intentions peut intégrer les portefeuilles traditionnels EOA, MPC et contrats intelligents. Les applications de trading et multichaînes verront leur expérience utilisateur améliorée grâce à une plus grande diversité des points d’entrée (automatisation, multiples solutions) ;
-
Opportunités pour les applications ZK : Les intentions des utilisateurs génèrent d’importants besoins de confidentialité. Le mécanisme 4337 peut déjà répondre à cela, mais une intégration plus poussée se développera dans le marché des preuves ZK.
-
Risques et barrières : Les intentions exigent une forte confiance, ce qui crée une barrière d’entrée élevée, conduisant potentiellement à une centralisation excessive et à un manque d’innovation.
Projets clés :
-
Le marché de l’abstraction des comptes compte deux catégories d’acteurs : ceux qui proposent des portefeuilles à contrats intelligents dotés de fonctions comme la connexion sociale, la récupération, l’abstraction de gaz, le traitement groupé des transactions et l’intégration de services tiers (comme les entrées/sorties fiduciaires et les protocoles DeFi). Ce secteur accueille beaucoup de startups, souvent à un stade préliminaire. L’autre catégorie concerne les fournisseurs modulaires de Bundler et Paymaster, dont la majorité, hormis Biconomy et Stackup, en sont encore aux débuts.
-
Projets clés : Biconomy, Stackup et Pimlico sont actuellement les solutions 4337 les plus matures. Le perfectionnement continu de leurs SDK et architectures modulaires leur permettrait de dominer le marché précoce et d’atteindre une forte couverture technologique. Stackup a déjà mis en œuvre deux types de Paymaster et deux modes de Bundler. Son expansion future reposera sur des solutions complètes et une bibliothèque variée de composants.
-
Pimlico détient une part de marché dominante (52 % des UserOps agrégées sur l’ensemble des chaînes selon Dune) et est rentable (premier sur Polygon, générant 637 MATIC en juillet, positif également sur Optimism) ;
-
Stackup exploite des activités de Bundler sur plusieurs chaînes, dominant en rentabilité sur Arbitrum (5 ETH en août) et Ethereum (0,4 ETH en juillet). Bien que ses Bundlers connaissent de nombreux échecs, leurs gains restent importants.
-
-
Projets innovants : La confidentialité constitue un besoin fondamental. Par exemple, le coprocesseur ZK Axiom peut servir de démonstration pour des solveurs privés. Nocturne propose une couche AA privée et composable : les utilisateurs déposent des fonds depuis un EOA ou un contrat, puis interagissent avec un contrat utilisant des preuves ZK pour garantir la confidentialité. L’IA est un thème populaire : Echooo Wallet combine MPC et IA pour permettre la validation multisignature et la surveillance automatisée des risques. Enfin, des innovations basées sur des projets existants retiennent l’attention, comme le Universal Paymaster d’Uniswap, qui crée un marché de liquidités appariant les utilisateurs de portefeuilles et les opérateurs de Paymaster.
Autres EIP et opportunités :
-
Concernant les EIP liés à 4337, la direction officielle étant fixée, la plupart des propositions se concentrent désormais sur l’optimisation du déploiement de l’AA. Par exemple, ERC 6551 soutient les produits dérivés de 4337 ; EIP 6662, ERC 6900, ERC 1271, ERC 6492, EIP 7204 et EIP 7197 visent tous à améliorer l’AA ; ERC 7377 facilite les migrations de comptes à l’avenir ;
-
Autres projets primés : L’Ethereum a financé quatre projets liés à l’abstraction des comptes durant les premier et deuxième trimestres 2023. Deux proviennent de l’équipe officielle 4337 (l’équipe AA elle-même et son portefeuille Trampoline). Les deux autres combinent 4337 avec des protocoles ou technologies existantes : zkShield utilise ZKP et l’abstraction de compte pour masquer les propriétaires de comptes via un système multisignature privé ; le Universal Paymaster d’Uniswap agit comme un marché unique pour le paiement de gaz en ERC-20.
Perspectives futures : À court terme, priorité à l’expansion du marché et à une dynamique d’encouragement mutuel avec les layer 2. À moyen terme, focalisation sur le déploiement de Bundlers et Paymasters modulaires, ainsi que sur les SDK, avec des améliorations ergonomiques (réduction des coûts de gaz, ajout d'une conversion optionnelle EOA vers ERC-4337, etc.). À long terme, envisager une migration obligatoire des portefeuilles EOA.
1. Introduction à l’abstraction des comptes
Définition et aperçu :
-
L’essence de l’abstraction des comptes réside dans la dissociation entre la source des transactions et la signature ;
-
Pourquoi avons-nous besoin de l’abstraction des comptes :
1) Simplifier les types de comptes ;
2) Dissocier les comptes des signatures, offrant plus de liberté aux actions sur chaîne et plaçant les comptes à un niveau de sécurité supérieur ;
-
Évolution de l’abstraction des comptes : Une distinction directe impliquerait une charge de travail et une complexité trop élevées. Les EIP 2938 et 3074 nécessitaient des modifications de la couche de consensus, finalement abandonnées au profit de l’EIP 4337, qui ne requiert aucune modification du noyau.
Principe de l’ERC 4337 :
-
Rôles : L’EIP 4337 standardise les portefeuilles à contrats intelligents et leurs infrastructures associées en cinq interfaces de contrat : Bundler, contrat EntryPoint, Paymaster, usine de portefeuilles (Wallet Factory) et agrégateur de signatures. Il introduit également un nouveau type de transaction (UserOperation).
-
Étapes de transaction : Sans modifier la couche de consensus d’Ethereum, 4337 introduit une nouvelle logique appelée useroperation, prise en charge par le Bundler chargé de regrouper les userops. Après le processus initial, l’EntryPoint et le contrat Wallet divisent la vérification et l’exécution pour accomplir des tâches personnalisées, tandis que le Paymaster externalise la logique de paiement des frais de gaz. L'utilisateur envoie un userop → le userop est envoyé à une « mempool d’userops » → le Bundler sélectionne et regroupe les UserOps en une seule transaction soumise à l’EntryPoint → l’EntryPoint valide l’opération utilisateur, le portefeuille à contrat exécute l’opération et l’inclut dans un bloc.
Comparaison entre 4337 et d'autres solutions :
-
Solution AA via EIP-3074 : Nécessite deux nouveaux opcodes pour permettre aux comptes EOA d’utiliser des contrats, impliquant une modification de la couche de consensus, raison pour laquelle elle a été abandonnée ;
1.1 Définition et aperçu de la solution
Qu'est-ce que l'abstraction des comptes ?
-
Ethereum possède deux types de comptes : les comptes externes (EOA) et les comptes de contrat (CA). L’EOA, en tant que solution traditionnelle, dépend fortement de la gestion des clés et de la signature ECDSA, avec une logique d’opération rigide. Ce lien strict entre signature et compte nuit à l’accueil des nouveaux utilisateurs et au développement futur ;
-
Il faut donc une solution permettant aux utilisateurs d’utiliser des portefeuilles à contrats intelligents intégrant une logique de validation arbitraire pour résoudre ce problème. Cette solution, appelée abstraction des comptes (Account Abstraction, AA), repose sur le principe de dissociation entre la source des transactions et la signature.
Pourquoi avons-nous besoin de l’abstraction des comptes ?
1) Simplifier les types de comptes ;
2) Dissocier les comptes des signatures, offrant plus de liberté aux actions sur chaîne et plaçant les comptes à un niveau de sécurité supérieur ;
Évolution de l’abstraction des comptes : Une distinction directe serait trop complexe. Les EIP 2938 et 3074 nécessitent des changements au niveau du consensus, ce pourquoi la solution 4337, ne demandant aucune modification de base, a été choisie.
-
Distinction directe : Ajouter de nouveaux types de transactions via des propositions comme EIP 86, EIP 101 ou EIP 859 ;
-
Élever le statut d’un type de compte :
-
EIP 2938 : Permet aux comptes de contrat de devenir des comptes « principaux » capables de payer des frais et d’exécuter des opérations ;
-
EIP 3074 : Introduit deux nouveaux opcodes permettant aux comptes EOA d’utiliser des contrats ;
-
EIP 4337 : Introduit une nouvelle logique opérationnelle – le pool d’opérations utilisateur ;
1.2 Principes fondamentaux de l’ERC 4337
-
Introduction : En septembre 2021, Vitalik Buterin, accompagné de chercheurs Ethereum de OpenGSN et Nethermind, a proposé l’EIP-4337. Celui-ci ajoute un nouveau pool de UserOperations, espérant remplacer complètement le pool de transactions actuel, réalisant ainsi l’abstraction des comptes.
Rôles
-
UserOperation : Transaction initiée par l’utilisateur, envoyée au Bundler, puis regroupée avec d’autres UserOperations en un Bundle ;
-
Bundler : Nœud qui sélectionne des transactions dans le pool, regroupe plusieurs UserOperations et crée une transaction pour l’appel EntryPoint.handleOps() ;
-
EntryPoint : Contrat intelligent qui traite la validation et l’exécution des bundles de UserOperations, servant d’intermédiaire entre le Bundler et le portefeuille à contrat ;
-
Contrat Wallet : Contrat intelligent capable de créer des portefeuilles compatibles 4337 pour les utilisateurs ;
-
Agrégateur : Valide les signatures agrégées ;
-
Paymaster : Contrat intelligent capable de payer les frais de gaz pour l’utilisateur.
Étapes de transaction
-
Signature de transaction : L’utilisateur lance une opération de portefeuille, signe cette opération avec une clé privée quelconque (instruction inchangée, champs modifiés, signature non-ECDSA possible), produisant un UserOperation signé envoyé à une mempool d’attente ;
-
Envoi de transaction : Le Bundler regroupe les UserOperations présents dans la mempool, puis signe une transaction englobant les instructions, transformant les UserOps en une transaction unique soumise au contrat EntryPoint. Après regroupement, les Bundlers simulent d’abord la transaction pour détecter les échecs d’exécution et calculer si les frais de gaz sont suffisants. Si la simulation réussit, les UserOperations sont soumis comme une seule transaction au validateur ;
-
Traitement de l’opération utilisateur : Le contrat EntryPoint vérifie l’existence du portefeuille, demande au portefeuille de valider l’opération, puis transmet l’opération au portefeuille à contrat pour exécution. Il agit comme intermédiaire entre le Bundler et le portefeuille à contrat ;
-
Inclusion dans un bloc : Le portefeuille à contrat exécute l’opération utilisateur et l’inclut dans un bloc.
1.3 Comparaison avec les portefeuilles traditionnels et MPC
1.4 Solution AA via EIP-3074
-
EIP-3074 : Requiert deux nouveaux opcodes pour permettre aux comptes EOA d’utiliser des contrats, impliquant une modification de la couche de consensus, donc abandonné ;
-
Si l’EIP-4337 permet aux comptes CA de fonctionner comme des EOA, alors l’EIP-3074 vise à donner aux portefeuilles EOA les fonctions programmables d’un compte de contrat. Le cœur du mécanisme repose sur une signature autorisant une autre entité à émettre des instructions en mon nom.
-
L’EIP-3074 introduit deux nouveaux opcodes, AUTH et AUTHCALL. Il permet à l’utilisateur (EOA) d’utiliser un contrat (Invoker Contract, non mis à jour) comme agent pour exécuter diverses actions, tout en donnant aux développeurs un cadre plus flexible pour concevoir des objets de transaction et des mécanismes de validation (algorithmes de signature), permettant à tout EOA de fonctionner comme un compte de contrat sans déployer de contrat soi-même.
-
Avantages : 1) Plus de liberté, permettant des transactions groupées, emballées, paiement de frais, multisignatures, etc. ; 2) Possibilité de payer les frais avec plusieurs types de jetons, permettant aux comptes externes de régler les frais de l’Invoker avec leur jeton favori ;
-
Inconvénients : 1) L’EIP-3074 implique de profondes modifications de la couche de consensus, nécessitant une hard fork en cas de problème ; 2) L’EIP-3074 donne aux comptes EOA des fonctionnalités de contrat, mais conserve la signature ECDSA fixe, contrairement à l’EIP-4337 qui permet toute forme de signature ;
-
EIP-5003 : Extension de l’EIP-3074 (AUTH et AUTHCALL), introduisant un nouvel opcode AUTHUSURP. Si l’adresse A (EOA) a autorisé l’adresse B à agir pour elle, AUTHUSURP permet à B de définir le code de A, mettant ainsi à niveau l’EOA existant en contrat et permettant une migration de ECDSA vers des schémas de signature plus efficaces ou résistants aux ordinateurs quantiques.
2. Solutions multichaînes d’abstraction des comptes
Synthèse
-
Deux voies : solution compatible 4337 (4337 compatible method) et solution d’abstraction native (native account abstraction).
-
Solution compatible 4337 :
-
Actuellement, Arbitrum, Polygon, Optimism et BNB n’intègrent pas nativement l’abstraction des comptes. Toutefois, ils sont supportés via des produits liés à 4337 (comme Biconomy, Stackup, etc.), bien que le déploiement des infrastructures en soit encore au stade conceptuel ;
-
Arbitrum a adopté en juillet une proposition soutenant le point d’accès AA ;
-
Polygon zkEVM indique dans sa documentation officielle qu’il prendra en charge le paiement de gaz en plusieurs jetons à l’avenir ;
-
Optimism et BNB offrent une infrastructure partielle d’abstraction des comptes, comme Alchemy, Biconomy, Pimlico et Stackup.
-
Solution d’abstraction native : Starknet et zkSync prennent en charge nativement l’abstraction des comptes, contrairement à la solution 4337.
Solution compatible 4337
Arbitrum :
-
Arbitrum a adopté le projet de loi AIP-2 le 17 juillet 2023, concernant le soutien au point d'accès de l'abstraction des comptes. Offchain Labs a désormais activé ce support sur Arbitrum One et Arbitrum Nova ;
-
Cette proposition mentionne qu'un nouveau point d'accès RPC, eth_sendRawTransactionConditional, a été conçu par les chercheurs Ethereum pour adapter le séquenceur L2 aux besoins spécifiques des Bundlers ERC-4337.
Polygon :
-
Polygon est compatible 4337 et a publié des solutions liées aux transactions métas, comme Biconomy (protocole de relais multichaîne), Gas Station Network (GSN) (protocole d’objet public décentralisé aidant à abstraire le paiement des gaz), Infura (fournisseur de nœuds) et Gelato (SDK de relais permettant le paiement en plusieurs jetons).
-
Dans sa documentation officielle, Polygon zkEVM indique prendre en charge l’abstraction des comptes via ERC 4337 et permettra aux utilisateurs de payer les frais avec n’importe quel jeton, d’autres détails à venir.
Optimism : Actuellement, la mainnet OP fournit une infrastructure partielle d’abstraction des comptes, via des projets comme Alchemy, Biconomy, CyberConnect, Pimlico et Stackup, bien que les détails architecturaux ne soient pas encore publiés ;
BNB : Dans la feuille de route technique 2023 de BNB Chain, l’équipe annonce la construction d’une infrastructure d’abstraction des comptes. 4377 est déjà compatible sur BNB, d’autres détails à venir.
Solution d’abstraction native
Starknet prend en charge nativement l’abstraction des comptes, tous les comptes étant des comptes intelligents.
- Objectif de la solution : abstraction des signatures (contrats de comptes différents utilisant différents schémas de validation) et abstraction des paiements (différents modèles et formes de jetons pour les transactions).
- Processus : Avant d'être ajoutée au pool, la transaction subit une vérification du nonce, puis est envoyée à l’adresse du contrat de compte pour validation, avant d’être incluse dans un bloc. Ces deux phases sont codées dans deux fonctions distinctes du contrat de compte : validate et execute.
-
Le Séquenceur (Sequencer) exige d’abord que le contrat de compte valide la transaction. Pour éviter les attaques DoS, le Séquenceur acceptant la transaction doit simuler localement selon l’état connu avant d’ajouter la transaction à la mempool et de la diffuser aux autres Séquenceurs.
-
Après une simulation réussie, la transaction est exécutée, ajoutée au pool et diffusée sur le réseau.
-
Différences entre Starknet et la solution Ethereum :
-
Dans l’abstraction native de Starknet, tous les comptes sont des comptes intelligents, devant contenir les fonctions validate et execute. Les utilisateurs implémentent une logique arbitraire dans ces fonctions pour étendre les fonctionnalités du compte.
-
StarkNet prend en charge plusieurs courbes elliptiques, avec une validation de signature hautement programmable. Validate assure par signature que seul le propriétaire du compte peut initier une transaction, tout en garantissant que l’exécuteur obtient assez de gaz. L’utilisateur peut implémenter différents algorithmes de vérification dans la fonction validate.
-
Suppression de la complexité supplémentaire due au Bundler : Starknet simplifie le flux en assignant au Séquenceur le rôle du Bundler ;
-
Starknet n’a pas de protocole équivalent au Paymaster pour l’abstraction des frais de transaction ;
-
Pas de distinction entre transactions classiques et UserOperations : Sur Starknet, toutes les transactions sont déclenchées par des comptes de contrat. Sur Ethereum, les Bundlers exécutent les transactions UserOperation, tandis que sur Starknet, le Séquenceur exécute toutes les transactions ;
-
Méthodes différentes de déploiement des comptes de contrat :
-
Sur Starknet, le déploiement du compte de contrat précède son utilisation. Un compte doté d’un solde appelle une fonction dédiée deploy_account pour créer un nouveau compte de contrat, qui peut payer des frais de gaz ;
-
Sur EIP 4337, aucun déploiement préalable n’est requis. Le Bundler déploie le compte de contrat en exécutant une transaction UserOperation dont le paramètre initCode n’est pas vide. Ce processus ne nécessite pas forcément un compte avec solde, et les frais de gaz peuvent être payés par un Paymaster.
-
zkSync : zkSync Era relève de la solution d’abstraction native, tout en étant compatible EVM.
-
Objectif de la solution : abstraction des signatures (contrats de comptes utilisant différents schémas de validation) et abstraction des paiements (différents modèles et formes de jetons pour les transactions).
-
Processus : L’utilisateur envoie localement la transaction signée à l’Opérateur (Operator), qui la transmet au bootloader pour validation. Après validation et obtention des frais, le bootloader appelle la fonction executeTransaction du contrat de compte pour exécuter la transaction.
-
Différences entre zkSync et 4337 :
-
zkSync ne distingue pas EOA et comptes de contrat ;
-
zkSync autorise la fonction validateTransaction à appeler des contrats externes déployés : ces contrats étant immuables sur zkSync ; Ethereum interdit cela pour éviter les changements d’état causant une validation réussie mais une exécution échouée ;
-
zkSync autorise validateTransaction et Paymaster à lire le stockage externe du contrat de compte, comme son solde en jetons sur un contrat tiers, ce qu’Ethereum inter
-
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
OKX Ventures
