Voir la table des matières Ne plus voir la table des matières
Régler un abonnement tous les mois sans y penser est devenu si banal qu’on oublie la mécanique derrière. Sur une carte bancaire, l’opération repose sur un principe simple : le commerçant a le droit de venir prélever, et le payeur n’a rien à faire. Sur Ethereum, ce mouvement-là n’existe tout simplement pas. Le réseau ne connaît qu’un seul sens de circulation, celui où le détenteur des clés signe lui-même chaque transaction.
Le sujet paraît technique, il est en réalité très concret. Il sépare les portefeuilles auto-dépositaires, où l’utilisateur garde seul la maîtrise de sa clé privée, des portefeuilles confiés à un tiers qui peut signer à sa place. Le premier modèle protège de la faillite d’un intermédiaire, l’année 2022 l’a rappelé assez durement ; le second offre les commodités auxquelles trois consommateurs sur dix disent s’être habitués en changeant leur façon de payer leurs factures ces deux dernières années.
Visa vient de publier un document technique qui prétend réconcilier les deux. Ses équipes crypto y décrivent un type de compte capable d’autoriser un prélèvement récurrent sans jamais céder la clé privée. La démonstration tient debout, mais elle ne tourne pas là où on l’attendait. Que propose exactement le réseau de paiement, et pourquoi sa solution ne fonctionne pas sur Ethereum ?
Le problème que Visa a mis en scène
Le document, signé de cinq chercheurs et ingénieurs de Visa et publié le 19 décembre 2022, s’ouvre sur un cas d’école volontairement trivial. Une utilisatrice part en vacances le 25 février et rentre le 10 mars. Son crédit immobilier, son abonnement de télévision et ses factures d’énergie tombent le 5 de chaque mois, et sa paie n’arrive que le 1er. Elle ne peut ni payer avant de partir ni signer pendant son absence.
Avec un compte bancaire, la réponse tient en deux clics. Avec un portefeuille auto-dépositaire, elle n’existe pas : la signature requise pour créer la transaction ne peut être produite que par la détentrice de la clé, et personne d’autre. Les auteurs précisent que ce travail est né d’un concours interne d’ingénierie organisé chez Visa dans l’année, ce qui situe assez bien l’objet : une exploration technique, pas une annonce de produit.
Pourquoi Ethereum ne sait pas tirer un paiement
La raison est inscrite dans l’architecture du réseau, et elle mérite d’être posée clairement car elle explique la suite. Ethereum ne connaît que deux types de comptes, aux prérogatives disjointes :
- le compte détenu par un utilisateur, contrôlé par une clé privée, seul habilité à déclencher une transaction ;
- le compte de contrat, qui héberge du code exécutable mais ne peut initier aucune transaction de lui-même ;
- toute opération doit donc partir d’un compte utilisateur et porter sa signature, y compris lorsqu’elle enchaîne ensuite une série d’appels de contrats.
Le vocabulaire du paiement traduit exactement cette asymétrie. Un paiement poussé est déclenché par celui qui paie ; un paiement tiré est déclenché par celui qui encaisse. Le prélèvement automatique appartient à la seconde famille, et Ethereum ne prend en charge que la première.
La parade habituelle consiste à confier ses clés à un dépositaire, qui signe à la place de l’utilisateur. Elle fonctionne, au prix exact de ce que la garde autonome cherchait à éviter. Les raisons de conserver ses cryptos sans intermédiaire n’ont pas disparu parce qu’un abonnement doit être réglé chaque mois.
L’abstraction de compte, une idée plus ancienne que Visa
Le document mobilise un concept qui n’appartient pas au réseau de paiement, contrairement à ce que certains résumés laissent entendre. L’abstraction de compte est une proposition d’évolution d’Ethereum, discutée depuis des années par ses développeurs, qui vise à fondre comptes utilisateurs et contrats en un seul type de compte. Son parcours est jalonné : idée initiale formulée début 2016, proposition EIP-86 en 2017 sur l’abstraction de l’origine et de la signature d’une transaction, EIP-2938 en 2020, puis EIP-4337 en 2021, qui prétend y parvenir sans modifier le protocole.
Le principe consiste à remplacer des conditions de validité gravées dans le protocole par des règles programmables compte par compte. Aujourd’hui, une transaction n’est valide que si elle porte une signature conforme, un compteur correct et un solde suffisant. Demain, chaque compte pourrait définir les siennes, ce qui ouvre la porte aux comptes à plusieurs propriétaires, aux signatures résistantes à l’ordinateur quantique, ou même à des comptes publics dont la vérification de signature disparaît. Le débat sur la façon d’y arriver reste vif au sein de l’écosystème.
Le compte délégable, la vraie contribution du document
L’apport propre de Visa tient dans un objet baptisé compte délégable. L’idée consiste à étendre les règles de validité programmables à une liste blanche : un contrat de paiement automatique déployé par le commerçant, une fois approuvé par l’utilisateur, obtient le droit d’ordonner à son compte de pousser un virement. Le prélèvement devient possible sans que la clé privée quitte son propriétaire, ce qui était tout l’enjeu.
L’autorisation n’est pas un blanc-seing. Le contrat affiche à l’avance ce qu’il pourra faire, par exemple ne prélever qu’une fois par mois ou ne jamais dépasser un montant plafond, et ces bornes sont inscrites dans le code. Les auteurs en tirent une garantie qu’ils formulent sans détour.
Parce qu’il s’agit d’un contrat intelligent, l’utilisateur peut avoir la certitude que le contrat de paiement automatique ne pourra pas s’exécuter autrement que de la manière dont il a été écrit.
Équipes de recherche et d’ingénierie crypto de Visa, document technique Auto Payments for Self-Custodial Wallets, 19 décembre 2022
Du point de vue du jeton transféré, l’opération devient indiscernable d’un virement ordinaire. Les auteurs esquissent d’autres usages du même mécanisme : services de récupération de compte nécessitant l’accord de plusieurs parties, gestionnaires d’actifs tiers limités à certaines catégories de jetons, tout ce qui suppose de déléguer sans céder.
Une démonstration qui tourne sur StarkNet, pas sur Ethereum
C’est le point que les reprises de l’annonce ont souvent laissé de côté, alors qu’il change la portée du travail. Ethereum ne prenant pas encore en charge l’abstraction de compte, les équipes ont déployé leur solution sur StarkNet, un réseau de seconde couche construit par StarkWare au-dessus d’Ethereum. Son modèle de comptes est nativement abstrait : il vérifie d’où vient la transaction, pas comment elle a été signée.
Le déplacement n’a rien d’anecdotique. Il signifie que la fonctionnalité décrite n’existe pas sur le réseau principal et dépend de l’adoption d’une couche supplémentaire, avec ses propres compromis de sécurité et de liquidité. Les travaux de StarkWare sur les couches supérieures avancent vite, mais la distinction entre une première et une seconde couche reste décisive pour qui évalue une promesse.
Ce que la garantie du code ne couvre pas
La formule sur le contrat qui ne peut s’exécuter autrement que comme il est écrit mérite d’être prise au mot, et c’est précisément ce qui la rend fragile. Elle est exacte sur le plan logique et incomplète sur le plan pratique : un contrat fait exactement ce qui est écrit, y compris quand c’est mal écrit. Le secteur a passé l’année à compter les portefeuilles vidés par une signature accordée à un contrat malveillant ou simplement bogué.
La question de fond n’est donc pas la fiabilité de la mécanique, mais la capacité d’un utilisateur ordinaire à lire ce qu’il approuve. Un plafond mensuel inscrit dans un contrat ne vaut que si quelqu’un a vérifié le contrat, ce qui explique l’importance prise par les audits de contrats intelligents dans les projets sérieux. La délégation déplace le risque de garde vers un risque de compréhension du code, et rien ne dit que le second soit plus facile à porter que le premier.
Le signal, lui, n’est pas mince. Un réseau qui traite des milliers de milliards de dollars de flux annuels consacre des ingénieurs à faire fonctionner un prélèvement automatique sur une chaîne publique, en s’appuyant sur une proposition née dans la communauté Ethereum sept ans plus tôt. La plomberie du paiement traditionnel commence à regarder de très près les briques que ce secteur produit, et l’inverse est tout aussi vrai.
