Portefeuilles de contrats intelligents : le pipeline…

Les portefeuilles de contrats intelligents et l'abstraction de compte déplacent l'activité des portefeuilles Ethereum des règles de transaction eoa fixes vers un pipeline programmable où une UserOperation est simulée, tarifée, et transformée plus tard en une transaction on-chain par un bundler.

L'ERC-4337 est le design dominant au niveau de l'application pour cela, et le véritable déblocage réside dans la compréhension des nouveaux intermédiaires, des API et des modes de défaillance plutôt que de mémoriser les fonctionnalités UX.

Points clés

• L'ERC-4337 remplace l'objet de transaction normal par une UserOperation qui se trouve dans un mempool séparé jusqu'à ce qu'un bundler l'inclue on-chain via la méthode handleOps d'EntryPoint.
• Les bundlers sont des routeurs de sélection et d'exécution, pas des relais passifs, car ils simulent des opérations, gèrent le risque de spam et choisissent ce qu'il faut regrouper.
• L'ERC-7769 standardise les méthodes JSON-RPC wallet↔bundler comme eth_sendUserOperation et eth_getUserOperationReceipt, permettant la portabilité des bundlers et un meilleur suivi des reçus.
• L'abstraction de comptecrée de nouvelles surfaces de coût de DoS et de calcul, donc les règles de validation, les systèmes de réputation et le durcissement de la production comme le blocage des points de terminaison debug_* deviennent partie intégrante du modèle de sécurité.

Comment les portefeuilles de contrats intelligents diffèrent des EOAs

Deux types de "comptes" différents apparaissent sur unEthereumécran : un eoa qui signe une transaction directement, et un compte de contrat qui n'agit que lorsque le code s'exécute. Un contrat intelligent le portefeuille fait de ce compte de contrat le portefeuille principal, de sorte que les vérifications de signature, les règles de nonce et la logique d'exécution deviennent programmables.

C'est le cœur de l'abstraction de compte, et cela s'inscrit dans la carte plus large des types de portefeuilles crypto expliqués : le « portefeuille » n'est plus simplement une paire de clés et un compteur de nonce.

La conséquence immédiate est que les fonctionnalités du portefeuille cessent d'être codées en dur dans les règles eoa du protocole. Un compte intelligent peut accepter différents schémas de signature, appliquer des politiques de dépenses, ou restreindre des actions derrière plusieurs conditions parce que la validation est du code.

C'est de là que viennent des fonctionnalités comme la récupération sociale et la catégorie plus large des portefeuilles sans graine et de récupération sociale. Le détail important est que ces fonctionnalités sont en aval du modèle d'exécution, pas du modèle lui-même.

Sur Ethereum, le chemin dominant vers l'abstraction de compte est l'ERC-4337, qui est explicitement cadré comme un changement au niveau des applications plutôt qu'un changement au niveau du consensus. Ce cadrage est important car il implique une nouvelle chaîne d'approvisionnement de transactions au lieu d'une réécriture du protocole. L'« action de portefeuille » n'est plus synonyme de « transaction diffusée dans le mempool public. » Cela devient un objet d'intention qui nécessite un agent d'inclusion.

Ce niveau d'agent d'inclusion est là où la plupart des explications deviennent paresseuses. Le modèle mental utile n'est pas « une transaction normale avec des étapes supplémentaires. » Le modèle utile est « un marché de transactions parallèle » avec son propre mempool, ses propres routeurs et ses propres contraintes opérationnelles.

Le flux d'opération utilisateur ERC-4337

Une UserOperation ne se retrouve pas sur la chaîne par elle-même. Elle vit hors chaîne jusqu'à ce qu'un bundler décide qu'il vaut la peine de la transformer en une transaction sur chaîne.

Les définitions de l'ERC-7769 rendent la séquence explicite : dans les flux ERC-4337, les transactions utilisateur sont remplacées par des objets UserOperation, et un bundler collecte une ou plusieurs UserOperations et les soumet au contrat EntryPoint dans un seul appel handleOps.

Ce pipeline a un ordre d'événements clair :

1. Le portefeuille construit une UserOperation qui encode ce que l'utilisateur veut faire et comment les frais seront couverts. 2. La UserOperation est envoyée à un nœud de mempool UserOperation qui la valide et la simule avant de l'accepter. 3. Un bundler sélectionne les UserOperations acceptées, les regroupe et soumet une transaction sur chaîne appelant EntryPoint.handleOps. 4.

EntryPoint exécute les opérations, et la chaîne produit un reçu de transaction normal pour le bundle plus les résultats par UserOperation.

La thèse du "marché parallèle" apparaît à l'étape 3. L'inclusion et la tarification ne sont plus uniquement le problème de l'utilisateur qui doit définir maxFeePerGas et attendre. Le bundler assume le coût de calcul et le risque de sélection.

C'est pourquoi certains développeurs soutiennent que la valeur clé de l'ERC-4337 est un marché des frais décentralisé pour les opérations des utilisateurs entrant dans les portefeuilles de contrats intelligents, et pas seulement une meilleure expérience utilisateur.

C'est également là que "l'abstraction de compte expliquée" a tendance à se tromper. L'objet que l'utilisateur signe n'est pas garanti de devenir une transaction. L'utilisateur peut tout faire correctement et ne pas être inclus si les agrégateurs ne le prennent pas, si la simulation échoue, ou si l'opération expire.

La bonne posture UX est de traiter le hash de UserOperation comme le principal identifiant de suivi jusqu'à l'inclusion, puis de le mapper au hash de la transaction d'agrégation après coup.

API et outils de portefeuille à bundler

ERC-4337 ne devient utilisable à grande échelle que lorsque les portefeuilles peuvent communiquer avec les bundlers de manière standardisée. C'est ce que rajoute l'ERC-7769 : une interface JSON-RPC qui reflète l'ergonomie de la soumission de transactions Ethereum normale et de la recherche de reçus, mais pour les UserOperations.

Les méthodes principales définies par l'ERC-7769 sont celles qui modifient les décisions d'intégration au jour le jour :

1. eth_sendUserOperation soumet une UserOperation au mempool UserOperation. Le client la valide et la simule, et ne doit retourner un userOpHash que si elle a réussi la simulation et a été acceptée dans le pool. 2. eth_estimateUserOperationGas estimegazchamps pour un UserOperation, avec la signature ignorée à des fins d'estimation. 3.

eth_getUserOperationByHash permet à un portefeuille de vérifier si une opération est en attente, incluse ou inconnue, et retourne des métadonnées d'inclusion telles que blockNumber et transactionHash lorsque disponibles. 4. eth_getUserOperationReceipt retourne un reçu par opération une fois inclus, y compris actualGasCost, actualGasUsed et un indicateur de succès, tout en retournant également le TransactionReceipt du bundle. 5.

eth_supportedEntryPoints indique au portefeuille quels adresses EntryPoint le bundler prend en charge, ce qui est le premier contrôle de portabilité qu'un backend de portefeuille doit effectuer.

C'est l'histoire de l'infrastructure silencieuse : la normalisation est ce qui rend possible un marché compétitif de bundlers. Si un portefeuille parle ERC-7769, il peut échanger des backends de bundlers sans réécrire toute sa logique de soumission et de suivi. C'est cela.décentralisation par interface, pas par slogan.

ERC-7769 trace également une ligne dure entre les tests et la production. Il définit debug_ méthodes pour le développement et les tests de compatibilité, et spécifie que ces debug_ méthodes JSON-RPC doivent être bloquées sur les serveurs de production. Ce n'est pas de l'étiquette. C'est une partie du modèle de sécurité pour quiconque opérant une infrastructure AA publique.

ERC-7769 fait également référence explicitement au support de l'eip 7702 dans l'objet UserOperation sur les réseaux où il est activé, via un tuple eip7702Auth. Les sources fournies ne précisent pas la portée ou l'état d'activation final de l'eip 7702 à travers les réseaux, mais le travail d'interface dans l'ERC-7769 signale que la plomberie wallet↔bundler est en cours de conception pour s'adapter à cette direction.

Sécurité du mempool, simulation et risques de DoS

La simulation est le centre de coût qui fait que l'abstraction de compte ressemble à l'exécution d'un moteur d'appariement plutôt qu'à une boîte RPC passive. L'ERC-7769 est franc à ce sujet : faire fonctionner un nœud ERC-4337 public en production est intensif en calcul et peut être une cible de DoS. C'est le prix à payer pour avoir un mempool UserOperation séparé où les nœuds doivent valider et simuler avant d'accepter des opérations.

La surface de DoS est structurelle. Un acteur malveillant peut soumettre des opérations qui sont peu coûteuses à envoyer mais coûteuses à simuler, forçant les bundlers et les nœuds de mempool à consommer des ressources de calcul.

L'ERC-7769 pointe vers des atténuations via les règles de validation ERC-7562 et les mécanismes de réputation, qui sont conçus pour empêcher les nœuds d'accepter des UserOperations malveillamment conçues et pour suivre la réputation des participants.

L'insistance du même document sur le blocage de debug_* en production est une autre atténuation pratique, car les points de terminaison de débogage peuvent exposer des comportements de réinitialisation d'état et de regroupement forcé qui sont utiles dans les tests et dangereux sur Internet ouvert.

L'ERC-5189 existe parce que la santé du mempool est la partie difficile, et il attaque le problème sous un angle différent. Il propose l'abstraction de compte via une structure Operation et des contrats “endorser”, évitant explicitement les nouveaux types de transactions de couche de consensus tout en restant compatible avec les portefeuilles de contrats intelligents existants.

Le travail de l'endorser est d'aider les bundlers à filtrer les “bonnes opérations” des “mauvaises opérations” dans un mempool d'opérations dédié.

Le mécanisme clé de l'ERC-5189 est que l'endorser renvoie des informations de disponibilité plus des informations de dépendance. Ce signalement de dépendance indique aux bundlers quels changements d'état devraient déclencher une réévaluation, ce qui est un moyen d'empêcher un mempool de pourrir avec des opérations qui ne sont plus valides.

L'ERC-5189 n'échappe toujours pas à la contrainte fondamentale : les bundlers doivent simuler l'exécution hors chaîne avant inclusion, et les opérateurs de mempool peuvent interdire les endorsers qui se comportent mal. La conception négocie le même compromis entre ouverture et résistance au spam, juste avec une plomberie différente.

Chemins concurrents pour l'abstraction de compte

Les développeurs d'Ethereum ne débattent pas de l'utilité des portefeuilles de contrats intelligents. Ils débattent de quel chemin devient le défaut à long terme et quels compromis sont acceptables.

Une ligne de faille visible est EIP-3074 contre ERC-4337, avec des arguments selon lesquels 3074 pourrait offrir des améliorations UX plus immédiates tandis que le camp 4337 met l'accent sur des propriétés telles que la résistance à la censure et, surtout, le marché des frais décentralisé pour les opérations des utilisateurs.

Ce débat est important pour les constructeurs car il change ce que signifie "infrastructure de portefeuille". ERC-4337 pousse la complexité dans un marché de transactions parallèle : UserOperations, bundlers, EntryPoint, règles de simulation, systèmes de réputation, et maintenant RPC standardisé via ERC-7769.

Cette pile peut évoluer sans un fork de protocole dur, mais elle crée également de nouveaux intermédiaires dont les incitations et le temps de disponibilité deviennent partie de l'expérience utilisateur.

L'autre raison pour laquelle plusieurs propositions existent est que "l'abstraction de compte" est un terme fourre-tout. Certaines propositions se concentrent sur la soumission d'intention et les marchés d'inclusion. D'autres se concentrent sur la manière de faire en sorte que les comptes de contrat ressemblent à des EOAs sans forcer chaque portefeuille à se mettre à jour.

L'objectif de compatibilité d'ERC-5189 est explicite : soutenir les implémentations existantes de portefeuilles de contrats intelligents sans exiger que chaque instance de portefeuille soit mise à jour manuellement.

Les sources signalent également l'eip 7702 comme une nouvelle direction introduite en mai 2024 par Vitalik Buterin et d'autres, présentée comme une réponse aux limitations de l'approche au niveau des applications.

Le matériel fourni n'inclut pas les détails de spécification de l'eip 7702, donc la seule conclusion responsable est la prise de conscience du champ : l'écosystème construit des interfaces, comme le tuple eip7702Auth optionnel d'ERC-7769, qui anticipent le changement.

Idées reçues courantes sur les portefeuilles de contrats intelligents et l'abstraction de compte

"L'abstraction de compte est une mise à niveau du protocole qui change les comptes Ethereum." ERC-4337 est présenté comme au niveau des applications, ce qui signifie qu'il ne change pas la façon dont le protocole Ethereum lui-même voit les comptes. Le protocole voit toujours les EOAs et les comptes de contrat. L'abstraction est construite par des contrats plus une infrastructure hors chaîne.

"Les bundlers ne sont que des relayeurs." Un relayer transmet une transaction. Un bundler exécute la validation et la simulation, choisit quelles UserOperations accepter et les regroupe dans un appel handleOps à EntryPoint. Ce rôle de sélection est la raison pour laquelle les bundlers héritent de l'exposition au DoS et pourquoi des mécanismes de réputation et de filtrage apparaissent dans les normes.

"L'AA concerne principalement la récupération sociale et les clés de session." Ce sont des fonctionnalités de portefeuille qui deviennent plus faciles lorsque la validation est programmable, et la récupération sociale est un exemple courant. Le facteur différenciateur qui change la structure du marché est le pipeline UserOperation + bundler + EntryPoint et le mempool séparé qu'il implique.

"Le suivi fonctionne comme des hachages de tx normaux." ERC-7769 ajoute explicitement des méthodes par-hachage et de reçu pour les UserOperations parce que la sémantique des hachages de tx ne s'applique pas tant qu'un bundler n'inclut pas l'opération. Les portefeuilles qui traitent la soumission comme finale expédieront des états en attente cassés et une gestion des échecs déroutante.

La Prise

J'ai vu des équipes livrer une "expérience utilisateur de compte intelligent" qui avait l'air élégante lors des démonstrations et qui s'est ensuite effondrée sous la charge parce qu'elles ont traité l'ERC-4337 comme une transaction normale embellie. L'erreur coûteuse est d'ignorer la couche d'inclusion.

Un UserOperation est un ordre dans un lieu séparé, et il ne devient une transaction de chaîne que lorsqu'un bundler choisit de le router via EntryPoint.handleOps.

S'il y a une posture qui fait gagner du temps, c'est de construire autour de la plomberie : méthodes ERC-7769 pour le suivi de soumission et de réception, états en attente explicites, et portabilité des bundlers via eth_supportedEntryPoints. Du côté infra, j'ai vu des gens exposer des points de terminaison debug_* sur des serveurs publics et agir surpris lorsqu'ils sont abusés. L'ERC-7769 le souligne pour une raison. L'abstraction de compte est un marché de transactions parallèles, et les marchés attirent un flux adversarial.

Sources

• Propositions d'Amélioration Ethereum
• Propositions d'Amélioration Ethereum
• Démantelé
• blockcryptowriter.medium.com