Comptes intelligents Ethereum : UserOperations, bundlers et frais sponsorisés

Un compte détenu par une personne, ou EOA, prouve le contrôle par une signature de clé privée. Son nonce ordonne les transactions.

Ce modèle est simple, mais la même clé autorise généralement toutes les actions et une transaction ordinaire lance généralement un seul appel de premier niveau au contrat, qui peut ensuite effectuer plusieurs appels internes.

Cette distinction complète le guide sur les transactions Ethereum en attente, qui traite du pool EOA, pas du parcours ERC-4337.

Un compte intelligent est un contrat qui peut détenir des actifs et exécuter des appels.

Son code de validation peut appliquer des règles propres au compte : une signature, un seuil de signatures multiples ou des autorisations qui expirent à une date donnée.

ERC-4337 n’impose ni produit de portefeuille ni politique de récupération unique ; il fournit une interface permettant à un compte contractuel d’autoriser et d’exécuter des opérations.

Ethereum.org présente des options possibles, comme les clés de secours, les autorisations limitées et le sponsoring des frais.

Chaque portefeuille peut toutefois proposer des fonctionnalités différentes.

L’appellation « portefeuille intelligent » ne suffit pas à déterminer la sécurité du compte ou qui le contrôle.

Vérifiez quel contrat détient les actifs, quel code et quel EntryPoint le compte accepte, ainsi que les signataires qui peuvent autoriser des appels.

Si la logique du compte peut être mise à niveau, les droits d’administration et la procédure de modification influent aussi sur le contrôle des actifs.

Une UserOperation est un objet qui décrit l’action souhaitée par un compte intelligent.

Elle comprend généralement l’adresse du compte émetteur, un nonce propre au compte, les données d’appel, une signature, des limites de gaz et des conditions de frais.

Elle peut aussi contenir les données d’une factory pour créer un compte ou celles d’un paymaster pour demander un sponsoring. Les champs exacts dépendent de la version de l’EntryPoint.

Au lieu d’envoyer cet objet sur la chaîne avec la méthode ordinaire eth_sendTransaction, le portefeuille le transmet à un bundler ou à un relais qui expose une API ERC-4337 telle que eth_sendUserOperation.

La demande passe par un pool de UserOperations distinct du pool des transactions Ethereum ordinaires. Le hash de UserOperation identifie la demande ; la transaction on-chain créée par le bundler possède un autre hash et un autre reçu.

La norme ERC-7769 définit les méthodes RPC de soumission, de recherche par hash et de consultation du reçu d’une UserOperation.

La réponse du bundler peut signifier que sa vérification a réussi et que la demande a rejoint son pool. Elle ne prouve pas qu’un bloc l’a incluse ni que l’action de l’application a réussi.

La façon dont un bundler partage la demande avec d’autres dépend de son infrastructure et de ses règles. Distinguez l’accusé de réception d’un fournisseur du résultat inscrit sur la chaîne.

Le bundler reçoit une UserOperation, vérifie sa compatibilité avec sa version d’EntryPoint, puis simule la validation du compte et du paymaster.

Il contrôle la signature, la confiance du compte envers cet EntryPoint, le nonce, le gaz et les conditions de sponsoring. Il peut rejeter une opération qui enfreint ses règles ou échoue à la simulation.

Le guide des bundlers ERC-4337 décrit cette simulation et la soumission par lots.

Le bundler sélectionne une ou plusieurs opérations acceptées, puis crée une transaction Ethereum ordinaire qui appelle handleOps sur l’EntryPoint.

L’inclusion de cette transaction dans un bloc dépend encore de la production des blocs et de l’état du réseau. Le hash de UserOperation renvoyé n’est pas la preuve que l’exécution a eu lieu sur la chaîne canonique.

Le pool de UserOperations est distinct du pool EOA ; ne supposez pas que tous les fournisseurs partagent les mêmes demandes. Un bundler peut rejeter une opération ou la laisser en attente.

Les chaînes, versions d’EntryPoint et politiques prises en charge varient selon les portefeuilles et les fournisseurs.

Pour vérifier l’état, distinguez l’écran du portefeuille, le reçu de l’opération et le reçu on-chain de la transaction groupée.

L’EntryPoint reçoit l’appel handleOps du bundler et invoque la fonction de validation de chaque compte intelligent. Le compte vérifie que l’appel passe par un EntryPoint de confiance et valide la signature ou ses autres règles.

L’EntryPoint valide et incrémente la séquence de 64 bits pour chaque compte et chaque clé ; le compte peut appliquer sa propre logique au champ de clé de 192 bits. Un compte peut ainsi utiliser plusieurs clés, chacune avec sa séquence.

Un paymaster facultatif vérifie également s’il sponsorisera l’opération. Une fois la validation réussie, l’EntryPoint appelle la fonction d’exécution du compte pour réaliser l’action décrite dans callData, puis règle les frais.

L’EntryPoint est le contrat central qui permet ces parcours sans modifier le protocole Ethereum pour chaque modèle de portefeuille. Vérifiez l’adresse déployée, la version et les chaînes prises en charge par le portefeuille.

Le guide ERC-4337 de l’EntryPoint décrit plus en détail la validation et l’exécution.

La simulation est un aperçu utile, pas une promesse d’inclusion. L’état de la chaîne, les frais, une fenêtre de validité ou l’état d’un contrat externe peuvent changer pendant l’attente et modifier la validation on-chain.

Même après validation, l’appel à l’application peut échouer ou être annulé. L’inclusion dans un bloc ne prouve pas à elle seule que le transfert ou l’action attendue a réussi.

Si une UserOperation contient les données d’un paymaster, l’EntryPoint lui demande s’il accepte de la sponsoriser.

Une application peut ainsi prendre en charge les frais de transaction ou permettre à un utilisateur d’agir sans détenir d’ETH sur son compte.

Certains modèles autorisent aussi un paiement en jetons ou imposent d’autres critères ; tout dépend du portefeuille et de l’implémentation du paymaster.

Le sponsoring ne fait pas disparaître le gaz et ne supprime pas les conditions. Un paymaster peut limiter les applications, utilisateurs, nombres d’opérations ou montants admissibles, examiner la demande et la refuser.

Son dépôt auprès de l’EntryPoint sert à payer les coûts des opérations. Si une mise en jeu séparée est requise, elle constitue une garantie selon les règles de validation ; ce n’est pas le même fonds que le dépôt disponible pour les frais.

Le guide des paymasters ERC-4337 et EIP-4337 décrivent la validation et le règlement.

Un frais affiché à zéro dans une application ne signifie pas qu’il n’y a aucun coût. Le sponsor peut payer d’abord puis récupérer de la valeur par un abonnement, un paiement en jetons ou les conditions du service.

Vérifiez qui supporte finalement les frais, si le sponsoring a un plafond ou une limite d’usage, et si une opération échouée peut tout de même occasionner des frais.

Si le portefeuille le permet, un utilisateur peut placer l’approbation d’une application et un échange dans une seule UserOperation. Les deux actions sont alors soumises comme une opération via l’EntryPoint.

Ce n’est ni une transaction EOA ordinaire ni le regroupement par un bundler de plusieurs UserOperations distinctes dans une transaction on-chain. Consultez l’aperçu du portefeuille pour savoir quelle structure est utilisée.

Prenons un exemple hypothétique : supposons qu’une opération sponsorisée et acceptée coûte réellement 0,0012 ETH en gaz.

Les frais peuvent être réglés depuis le dépôt du paymaster auprès de l’EntryPoint plutôt que depuis le solde de l’utilisateur. Les 0,0012 ETH sont un chiffre illustratif, pas un cours ni un devis actuel.

Le montant réel dépend du gaz consommé, des conditions de frais et du réseau.

Le regroupement n’est pas automatiquement moins cher ou plus sûr. L’atomicité de plusieurs appels dépend de la façon dont le compte intelligent traite les échecs.

Vérifiez si l’échec d’un appel annule tout le lot, si certaines actions peuvent tout de même aboutir et qui paie le gaz. Une estimation imprécise ou une application indisponible peut entraîner un rejet ou un échec d’exécution.

Le guide des frais de gaz Ethereum explique les champs de frais généraux.

Un compte intelligent peut prévoir des signataires de secours ou une récupération où des gardiens de confiance atteignent un seuil pour remplacer une clé. Certains modèles imposent un délai pendant lequel l’ancienne clé peut s’y opposer.

Mais si une signature unique est toujours nécessaire, la perte de cette clé peut ne laisser aucune voie de récupération.

ERC-4337 permet aux comptes de valider selon leurs propres règles ; il ne fournit pas automatiquement des clés de secours ou une récupération sociale.

Trop peu de gardiens ou des règles faibles de remplacement peuvent créer une voie d’attaque. Un groupe trop important ou des conditions trop exigeantes peuvent retarder la récupération légitime du propriétaire.

Examinez le seuil, le délai, les droits d’annulation et la façon dont les clés de récupération sont protégées. Ces règles déterminent aussi qui peut bloquer une opération, pas seulement qui peut l’autoriser.

Un portefeuille contractuel n’est pas automatiquement dépositaire ou sans dépositaire.

Le contrôle dépend de la personne qui détient les clés de signature, de l’existence de pouvoirs d’administration ou de mise à niveau et des autorisations accordées à un signataire hébergé ou à un service de récupération.

Examinez séparément le contrat qui détient les actifs et les clés ou services qui le contrôlent.

La sauvegarde d’une phrase de récupération classique est un sujet distinct traité dans le guide de récupération du portefeuille.

Dans l’aperçu du portefeuille, contrôlez le réseau, l’adresse du compte, les contrats ciblés, les données d’appel, la portée des approbations de jetons et le nombre d’appels.

Une signature peut autoriser davantage que la seule action mise en avant par l’interface. Si vous ne comprenez pas les données signées, consultez la documentation officielle de l’application et du portefeuille avant de continuer.

Pour comprendre le sponsoring, lisez ses critères, ses limites d’usage, les modalités de paiement alternatives et les règles de frais en cas d’échec au lieu de vous fier au nom du paymaster.

Une mention « sponsorisé » ne veut pas dire que l’application est toujours gratuite, et le paymaster peut encore refuser l’opération. La congestion du réseau et les retards d’inclusion restent des risques distincts.

Si une UserOperation reste longtemps en attente, n’appliquez pas automatiquement les fonctions EOA « accélérer » ou « annuler » : vérifiez d’abord le fonctionnement du portefeuille pour ces opérations.

Recherchez le hash de l’opération et son reçu. Si le hash de la transaction du bundler est disponible, vérifiez également le reçu du bloc et le résultat d’exécution.

Les reçus RPC peuvent distinguer le coût et le résultat d’une opération du reçu de toute la transaction groupée. Cela diffère du remplacement ou de l’annulation d’une transaction EOA ayant le même nonce.