Account abstraction : wallets intelligents et sécurité

Pourquoi les comptes Ethereum classiques montrent leurs limites

Le sujet prolonge celui de la sauvegarde et de la récupération d’une seed phrase. Un compte externe, ou EOA, dépend traditionnellement d’une clé privée. La même signature autorise les transactions, tandis que le protocole impose le format de validation.

Cette simplicité offre un modèle clair, mais elle rend la récupération difficile. Une clé perdue ne peut pas être remplacée. Un nouvel utilisateur doit aussi posséder le token natif pour payer le gas, même s’il reçoit un autre actif.

Un smart account place la logique de validation dans un contrat. Il peut demander deux signatures au-dessus d’un montant, accepter une passkey, limiter une session ou permettre une récupération après délai.

La programmation ne supprime pas les clés. Elle permet d’organiser leur rôle et leur remplacement selon des règles vérifiables. La sécurité dépend alors du contrat et de sa configuration.

Comment ERC-4337 fonctionne

L’ERC-4337 décrit une account abstraction sans changement de la couche de consensus. L’utilisateur crée une UserOperation qui ressemble à une transaction, avec destination, données, limites de gas, nonce et signature.

Cette opération rejoint un mempool distinct. Des bundlers regroupent plusieurs UserOperations puis appellent le contrat EntryPoint dans une transaction Ethereum. L’EntryPoint vérifie les comptes, collecte les frais et exécute les actions valides.

Un paymaster peut financer le gas selon ses règles. Une application peut donc sponsoriser une première opération ou accepter un paiement en token. Ce confort introduit une dépendance : le paymaster peut refuser, manquer de dépôt ou appliquer une politique restrictive.

Le bundler ne garde pas les fonds du compte. Il assure la transmission et paie d’abord le gas de la transaction groupée, puis récupère la somme selon le mécanisme prévu. Une panne peut retarder l’exécution sans nécessairement compromettre les actifs.

Les fonctions rendues possibles

La récupération sociale permet à des gardiens de valider un changement de clé après un délai. Les gardiens peuvent être des appareils, des proches ou des institutions. Une bonne configuration évite qu’une seule personne récupère le compte.

Les limites de dépenses imposent un plafond quotidien ou restreignent certaines destinations. Une clé de session peut autoriser un jeu à exécuter des actions précises pendant une durée définie sans demander une signature complète à chaque clic.

Le batching regroupe plusieurs actions : approval, swap et dépôt peuvent se dérouler dans une même opération logique. Cette fonction réduit les étapes, mais l’utilisateur doit encore comprendre l’effet global.

Le paiement du gas dans un token ou par un sponsor facilite l’arrivée d’un débutant. Il ne rend pas la transaction gratuite : quelqu’un paie, et le prix peut apparaître dans un spread, des frais ou des conditions commerciales.

Smart account, multisig et wallet custodial

Un multisig exige plusieurs validations selon une règle. Un smart account peut inclure cette fonction et bien d’autres. Les catégories se chevauchent donc.

Un wallet custodial garde les clés pour l’utilisateur et peut réinitialiser l’accès selon sa procédure interne. Un smart account non custodial laisse les règles on-chain et les signataires sous contrôle de l’utilisateur, même si une interface ou un service aide à les utiliser.

Certaines solutions gardent une clé serveur, un service de récupération ou un paymaster obligatoire. Elles restent programmables mais ajoutent une confiance opérationnelle. Lisez le modèle réel plutôt que l’étiquette « non custodial ».

Le meilleur choix dépend du montant, de la fréquence, de l’équipe et de la capacité à maintenir les sauvegardes. Un compte très complexe peut devenir plus difficile à récupérer qu’un wallet simple.

Les nouveaux risques de sécurité

Un bug dans la logique de validation pourrait autoriser une opération non signée ou bloquer le compte. Les modules ajoutés après le déploiement disposent parfois de permissions puissantes. Leur audit doit couvrir l’interaction avec le noyau.

La mise à niveau crée une autre question : qui peut changer l’implémentation ? Une clé d’administrateur compromise pourrait remplacer le code. Un timelock et un multisig réduisent ce risque sans l’éliminer.

Les bundlers subissent des contraintes anti-spam et simulent les opérations. Une UserOperation valide pour l’utilisateur peut être refusée par une infrastructure particulière. La possibilité de changer de bundler améliore la résilience.

Un paymaster peut censurer une opération ou appliquer des limites. Si le compte ne possède aucun ETH et dépend entièrement de ce service, une panne peut bloquer l’action urgente.

Récupération sociale : utile mais à préparer

Choisissez des gardiens indépendants qui ne partagent pas le même appareil, email ou opérateur. Trois gardiens contrôlés par un seul compte cloud ne créent pas trois barrières.

Fixez un seuil qui résiste à la compromission sans rendre la récupération impossible. Deux sur trois convient parfois à un particulier ; une organisation peut demander une politique plus structurée.

Ajoutez un délai et une possibilité d’annulation. Le titulaire peut alors détecter une récupération frauduleuse. Les alertes doivent passer par plusieurs canaux.

Testez le processus avec un petit compte. Une procédure jamais répétée peut échouer le jour où la clé principale disparaît. Documentez les étapes sans enregistrer tous les secrets au même endroit.

Passkeys et authentification moderne

Une passkey utilise une paire cryptographique liée à un domaine ou une application. Elle résiste mieux au phishing qu’un mot de passe ou un code SMS. Son intégration dans un smart account exige toutefois une vérification compatible avec la chaîne.

La synchronisation cloud simplifie le changement d’appareil, mais transfère une partie du risque vers le compte Apple, Google ou un gestionnaire. Une passkey liée uniquement à un appareil exige une sauvegarde séparée.

Vérifiez si le wallet permet d’exporter, d’ajouter un second authentificateur et de récupérer sans son entreprise. Une dépendance propriétaire peut devenir problématique si le service ferme.

Pour les montants importants, combinez passkey, clé matérielle et règle multisig plutôt que d’attendre d’un seul facteur qu’il couvre tous les scénarios.

Gas sponsorisé et paiement en token

Le paymaster valide une UserOperation avant de financer son gas. Il peut exiger une signature du service, un abonnement, un token précis ou une action autorisée. Son contrat doit disposer d’un dépôt suffisant auprès de l’EntryPoint.

Une application peut offrir quelques transactions pour faciliter l’inscription. Elle peut aussi convertir un token de l’utilisateur afin de couvrir les frais. Comparez le coût implicite avec le prix normal du gas Ethereum.

Le sponsor ne devrait pas recevoir une autorisation illimitée sans justification. Lisez les permissions et appuyez-vous sur la méthode pour examiner un smart contract sans coder.

Une panne du paymaster ne doit pas rendre les fonds inaccessibles. Vérifiez si une opération classique payée en ETH ou un autre paymaster peut prendre le relais.

Sessions, délégations et limites de dépense

Une clé de session autorise un ensemble restreint d’actions pendant une période. Un jeu peut permettre des mouvements internes sans exposer le droit de transférer les fonds vers une adresse arbitraire. Une application professionnelle peut limiter un collaborateur à certains contrats et à un montant quotidien.

La portée doit rester lisible avant la signature : destinations, fonctions, tokens, plafond et date d’expiration. Une délégation vague revient presque à remettre la clé principale. Les interfaces devraient montrer les sessions actives et permettre leur révocation sans dépendre du fournisseur qui les a créées.

Le nonce et les règles anti-rejeu empêchent la réutilisation d’une autorisation déjà consommée. Les signatures doivent aussi dépendre de la chaîne et de l’EntryPoint, comme le précise ERC-4337. Sans ce contexte, une opération pourrait produire un effet inattendu sur un autre environnement.

Après un test, révoquez la session et confirmez l’événement sur un explorateur. Cette discipline réduit la durée d’exposition d’un appareil secondaire ou d’une application de jeu.

Évaluer un wallet fondé sur l’account abstraction

Identifiez le contrat du compte, sa version et son mécanisme de mise à niveau. Consultez les audits, les bug bounties et les incidents. Un audit ne remplace pas une analyse des permissions.

Listez les signataires, gardiens, modules, bundlers et paymasters. Demandez ce qui arrive si chacun disparaît. Le compte permet-il de changer de fournisseur depuis une interface alternative ?

Contrôlez la récupération et les délais. Une promesse comme « aucun risque de perte » masque souvent un tiers capable de rétablir l’accès. Comprenez les conditions exactes.

Vérifiez la compatibilité avec les applications utilisées. Certains protocoles traitent différemment les smart accounts, les signatures ou les messages hors chaîne. Testez avant de transférer une grande somme.

Migrer sans exposer tous ses fonds

Créez d’abord le smart account depuis la documentation officielle. Ajoutez les méthodes de récupération et testez une petite transaction. Confirmez que vous pouvez utiliser une seconde interface ou appeler directement le contrat.

Transférez ensuite un montant limité. Testez un swap, une approval, un retrait et une récupération simulée. Surveillez les frais et délais du bundler.

Ne supprimez pas l’ancien wallet avant d’avoir validé les sauvegardes. Une migration progressive réduit l’impact d’un bug de configuration. Pour une organisation, faites approuver la politique par plusieurs responsables.

L’account abstraction rapproche le wallet d’un compte programmable adapté aux usages modernes. Elle peut réduire les erreurs d’onboarding, améliorer la récupération et distribuer l’autorité. En échange, elle ajoute des contrats, des modules et des services. La meilleure configuration ne multiplie pas les fonctions : elle retient celles qui répondent à un risque précis et reste utilisable lorsque le fournisseur principal tombe en panne.

À lire aussi : Acheter USDT avec Airtel Money : règles, frais et risques