La monnaie de l'IA : comment les micro-paiements en Bitcoin s'intègrent-ils à l'IA ?
TechFlow SélectionTechFlow Sélection
La monnaie de l'IA : comment les micro-paiements en Bitcoin s'intègrent-ils à l'IA ?
Bitcoin est à moi, les sats à l'IA.
Dédié à des analyses Web3 approfondiesRédaction : Pang Chekou
Parfois, cela semble incroyable : dans différents environnements, chaque fois que l’on mentionne Bitcoin, certaines personnes expriment un scepticisme face à Bitcoin pour des raisons telles que « ne pas (vouloir) comprendre » ou « motivation impure ». Leurs objections portent principalement sur le « temps » et la « valeur », plutôt que sur Bitcoin en tant que technologie ou concept élégamment conçu.
Je ne suis pas sceptique. Pour moi, Bitcoin est une source irremplaçable de fraîcheur.
-
Ces derniers temps, cette sensation de fraîcheur provient de l’expérience éclair venue d’outre-Atlantique : les satoshis affluent sans cesse dans mon portefeuille. « Une valeur infime, comme 1 satoshi (1 satoshi = 0,00023 $), peut traverser des distances incommensurables via des câbles réseau et arriver directement entre mes mains » ;
-
Elle provient aussi des découvertes surprises dans des restaurants de rue à Paris et Bologne, où je peux payer au flash⚡️ une boule de glace à la banane ou des tagliatelles bolognaise ;
-
Elle vient également du petit matériel universel que le professeur Ajian m’a envoyé depuis l’autre bout du monde, me permettant de monter moi-même avec joie un seed signer, un dispositif de signature Bitcoin.
J’aime une phrase d’Ajian : Bitcoin fait des choses que d’autres technologies sont fondamentalement incapables de faire.
Aujourd’hui, j’aimerais aborder quelques sujets que j’ai gardés en notes pendant trois mois :
L’histoire des micropaiements, les expérimentations sur le réseau Lightning et la possible convergence entre micropaiements et IA.
Brève histoire des micropaiements
W3C
Ted Nelson a inventé le terme « micropayment » dans les années 1960. Ce pionnier des concepts internet (comme hypertexte, hypermédia) a formulé l'idée des micropaiements dès cette époque.
En 1992, Tim Berners-Lee, créateur du HTTP et du HTML, publie sa deuxième version du protocole HTTP, incluant la première référence aux codes d’état désormais courants. L’un de ces codes, selon Berners-Lee et d'autres, devait un jour servir au paiement de contenus numériques : le 402 Payment Required. Malheureusement, ce code d’état a été officiellement « réservé pour usage futur », car dés le départ, toutes les tentatives de mise en œuvre de micropaiements sur le web ont échoué. Plus de trente ans après l’invention d’internet, nous attendons toujours la réalisation de l’une de ses visions initiales.
Tim Berners-Lee fonde en 1994 le World Wide Web Consortium (W3C) pour guider l’évolution du web, et les micropaiements en sont dès le départ un enjeu central.
En 1995, Phillip Hallam-Baker, auteur de nombreux RFC sur la sécurité internet, rédige le Micropayment Transfer Protocol (MPTP) [1], mais ce protocole ne semble jamais avoir été implémenté. Il contient toutefois de nombreuses idées toujours pertinentes aujourd’hui sur l’essence des micropaiements :
Il existe un grand intérêt pour des systèmes de paiement capables de facturer des montants relativement faibles pour une unité d'information. Ici, la vitesse et le coût du traitement des paiements sont des facteurs critiques pour évaluer l'utilisabilité d'un système. Une réponse rapide pour l'utilisateur est essentielle si l'on veut encourager un grand nombre d'achats.
Cependant, une limitation clé du MPTP était que le protocole exigeait explicitement un tiers (appelé broker). À l’époque, aucun paiement numérique n’était possible sans intermédiaire de confiance, donc toute tentative de micropaiement devait prévoir un mécanisme de dépôt de fonds.
Le W3C continua quelque temps à promouvoir les micropaiements, publiant en 1998 un aperçu général et recommandant le MPTP comme méthode pratique, en précisant :
Les micropaiements doivent convenir à la vente de biens immatériels sur Internet […] Avec l'importance croissante des biens immatériels (par exemple l'information) dans les économies mondiales et leur livraison instantanée à coût négligeable, les méthodes de paiement « conventionnelles » tendent à coûter plus cher que le produit lui-même.
Cela rejoint une autre grande préoccupation de Hallam-Baker : les coûts transactionnels induits par les contraintes techniques ou administratives des systèmes de paiement disponibles. Sa première préoccupation était la nécessité d’une « réponse rapide utilisateur », souvent ignorée dans les débats sur la faisabilité des micropaiements.
Ce n’est qu’en 1999 que Nick Szabo, dans son article « Micropayments and Mental Transaction Costs » [3], approfondit davantage la notion de « réponse rapide utilisateur ». Je recommande vivement cet article de Szabo, qui souligne que les micropaiements ne sont pas seulement une affaire technique, mais concernent aussi des coûts cognitifs psychologiques — le coût mental de payer étant bien supérieur au coût technique. Comment comprendre le processus décisionnel derrière un micropaiement ? Alors que les coûts techniques diminuent constamment, comment concevoir des flux de paiement interactifs pour réduire ce « coût mental » ? Un scénario possible serait que les ressources ou capitaux personnels puissent « automatiquement » correspondre à des préférences implicites (en encapsulant des API ou la « connexion internet » via des micropaiements).
Un web basé sur les micropaiements implique des paiements fréquents, donc une fatigue décisionnelle. Pour la plupart des micropaiements, le coût mental engendré par le besoin constant de choisir d’acheter pourrait excéder la valeur même du bien acquis.
De grandes entreprises comme Compaq et IBM, ainsi que des startups comme Pay2See, Millicent ou iPin, ont toutes tenté tôt de réduire les coûts techniques et psychologiques des micropaiements, mais le concept restait perçu comme durablement problématique dès son origine.
Parmi ces entreprises, la plus célèbre fut sans doute DigiCash dirigée par David Chaum, qui eut un impact durable sur la communauté Bitcoin. Chaum avait déjà formellement proposé en 1982 des structures de données similaires à la blockchain et de nombreuses idées sur la monnaie numérique sécurisée, avant de fonder DigiCash en 1989. DigiCash implémenta ses propositions, permettant aux utilisateurs de retirer des fonds auprès d'une banque (appelés eCash) et rendant les transactions anonymes et traçables. Malheureusement, un seul établissement bancaire a adopté eCash, et l’entreprise fit faillite en 1998.
À peu près au même moment, d'autres initiatives de micropaiements se sont effondrées, et le W3C lui-même mit fin en 1998 à son soutien aux projets de micropaiements.
La bulle internet explosait, et les micropaiements étaient l'une des idées les plus durement touchées. C’était le moment idéal pour les critiques. L’écrivain Clay Shirky publia « A Case Against Micropayments », affirmant audacieusement :
Les systèmes de micropaiements n'ont pas échoué à cause d'une mauvaise implémentation ; ils ont échoué parce que c'est une mauvaise idée. De plus, puisque leurs faiblesses sont systémiques, ils continueront à échouer à l'avenir.
En 2000, il précisa que son argument principal contre leur défaut fondamental n’était ni technique ni infrastructurel, mais rejoignait celui de Nick Szabo un an plus tôt : la fatigue décisionnelle. Il ajouta :
En particulier, les utilisateurs veulent des prix simples et prévisibles. Les micropaiements, eux, gaspillent l'effort mental des utilisateurs afin de conserver des ressources bon marché, en créant de nombreuses petites transactions imprévisibles. Ainsi, les micropaiements génèrent chez l’utilisateur à la fois anxiété et confusion, deux caractéristiques que les utilisateurs n’ont jusqu’à présent jamais recherchées activement.
Shirky prédit ensuite que trois modèles de paiement domineraient le web sans souffrir de fatigue décisionnelle : l’agrégation (regrouper des éléments de faible valeur en une seule transaction de haute valeur), l’abonnement et la subvention (autrui paie à la place de l’utilisateur — ce qui aujourd’hui prend la forme publicitaire).
À la fin de l’éclatement de la bulle internet, la prédiction de Shirky semblait de plus en plus juste. L’infrastructure des cartes de crédit rendait les paiements inférieurs à 1 dollar économiquement inviables, devenant ainsi le mode de paiement de facto, tandis que l’enthousiasme pour les projets de micropaiements s’étiolait. Dans le contexte d’un web de plus en plus centralisé, surveillé et piloté par la publicité — le Web 2.0 —, l’avenir du web apparaissait de moins en moins enthousiasmant.
Bitcoin et le réseau décentralisé
Nous devons croire qu’ils protègent notre vie privée, croire qu’ils empêcheront les voleurs d’identité de pirater nos comptes. Le coût administratif énorme rend les micropaiements impossibles. — Satoshi Nakamoto
L’idée derrière le 402 était claire : le support du paiement devrait être un concept de premier ordre sur le web, et il était évident que beaucoup de commerce direct devrait y avoir lieu […] En réalité, le modèle dominant qui est apparu est la publicité. Cela conduit à une forte centralisation, car les plateformes les plus grandes ont le coût par clic le plus élevé.
— John Collison, président de Stripe
Satoshi Nakamoto publie le livre blanc de Bitcoin à la fin de l’année 2008, au cœur de la crise immobilière américaine. Peu après, il publie son code source initial. Bitcoin constitue une percée majeure à la fois en informatique et dans l’histoire monétaire, ravivant un nouvel intérêt pour les possibilités d’internet. Pour la première fois, une méthode sans permission permettait de transférer de la valeur via une monnaie native d’internet, sans recourir à toute l’infrastructure maladroite et lourde requise par les cartes de crédit.
Pendant un temps, le prix du bitcoin étant si bas, certains ont effectivement plaidé pour son utilisation comme système de micropaiements, bien que Nakamoto ait admis que ce n’était (pas encore) une bonne solution au problème :
Bitcoin n’est actuellement pas pratique pour les très petits micropaiements. Inadapté aux contenus payants par recherche ou par page vue sans mécanisme d’agrégation, ni aux frais inférieurs à 0,01.
Mais les frais n’ont pas empêché les gens de rêver aux nouvelles possibilités offertes. Marc Andreessen, créateur du premier navigateur web populaire, cite la monétisation de contenu et la lutte contre le spam comme exemples :
L’une des raisons pour lesquelles les médias comme les journaux ont du mal à monétiser leur contenu est qu’ils doivent soit tout vendre (payer un abonnement complet), soit rien vendre (ce qui entraîne des pubs horribles partout sur le web). Soudainement, avec Bitcoin, il devient économiquement viable de facturer des sommes arbitrairement faibles par article, par section, par heure, par visionnage vidéo, par accès aux archives ou par alerte info.
Bien sûr, cela n’est plus vrai aujourd’hui (au moins sur la couche 1), mais en 2014, les frais étaient suffisamment bas pour construire autour du concept de micropaiement. Un projet intéressant lancé vers cette époque était Bitmonet, qui permettait aux utilisateurs de choisir un niveau d’abonnement : payer 10 cents pour un article, 15 cents pour une heure d’accès illimité à un site, ou 20 cents pour un pass journalier. Malheureusement, les frais de transaction ne sont plus assez bas pour autoriser des micropaiements arbitraires, bien que Nakamoto ait pensé dès l’origine à ce problème, Bitcoin n’a pas été spécifiquement conçu pour résoudre les micropaiements.
La prédiction de Shirky sur la monétisation de contenu s’est avérée très exacte, notamment concernant les modèles d’abonnement et publicitaire.
Dans le modèle publicitaire, le contenu est subventionné par des annonceurs (souvent via un tiers). De 2014 à 2022, Google et Facebook ont pratiquement monopolisé le marché de la publicité en ligne en tant qu’intermédiaires entre annonceurs et créateurs de contenu. Ces deux entreprises (comme la plupart des grandes tech) collectent d’immenses quantités de données personnelles et exigent simplement que les utilisateurs leur fassent confiance pour la sécurité, malgré de nombreuses violations. Ces données servent à diffuser des publicités ciblées sur des produits que les gens sont susceptibles d’acheter. Les entreprises appellent généralement ce modèle « gratuit mais avec publicité ». En réalité, les utilisateurs paient un prix. Le modèle publicitaire oblige les utilisateurs à échanger du contenu contre deux choses :
1. Leur donnée, fournie de force à des tiers, ce que Nick Szabo qualifie de faille de sécurité.
2. Leur attention. Plus les utilisateurs passent de temps sur des sites publicitaires, plus les annonceurs, les plateformes et les créateurs gagnent d’argent. Ainsi, les créateurs sont incités économiquement à afficher autant de publicités que possible, sans trop irriter les utilisateurs au point qu’ils quittent la plateforme. La monnaie du web « gratuit avec pub » est l’attention de l’utilisateur. Vous êtes le produit. Le modèle publicitaire montre clairement que les consommateurs deviennent des citoyens de second rang. Puisque les revenus des créateurs sont dissociés des utilisateurs finaux, offrir une bonne expérience utilisateur n’est pas prioritaire. À mesure que de plus en plus de consommateurs utilisent des bloqueurs de publicité, les créateurs sont obligés de devenir plus agressifs, détériorant l’expérience web pour tous.
L’abonnement gagne aussi en popularité. Les utilisateurs préfèrent souvent payer régulièrement pour un accès groupé à des contenus comme films ou musique, plutôt que posséder individuellement chaque chanson. Bien que ce soit un modèle plus honnête, il pose aussi de gros problèmes quand il devient le seul choix. Ces dernières années, avec la concurrence accrue entre services, de plus en plus de gens souffrent de « fatigue d’abonnement ». Ils ne peuvent pas accéder à un article (ou quelques articles), un film ou une chanson spécifique à un moment donné, ce qui les force à faire des choix sous-optimaux, essayant de maximiser leur abonnement.
Prenons les services de streaming. Aujourd’hui, il en existe tellement, tous en concurrence pour les licences de contenu, que les utilisateurs finissent par payer plusieurs abonnements pour attraper plus de films et séries désirés. Mais ce qu’ils veulent vraiment, c’est regarder une petite partie du contenu offert par chaque service. Quand ils choisissent un service pour un film ou programme voulu, ce contenu ne reste souvent pas longtemps disponible, sautant imprévisiblement d’une entreprise à l’autre avec les renouvellements de licence.
Les articles de presse en sont un autre exemple. Des sociétés comme le New York Times ou The Economist attirent les lecteurs en leur permettant de lire quelques paragraphes, puis bloquent le reste derrière un mur payant. C’est encore plus vrai pour les journaux : les clients seraient plus enclins à payer une petite somme pour un seul article choisi, plutôt que d’acheter un forfait incluant des articles qu’ils ne veulent pas.
Bien que l’abonnement offre une méthode plus directe que la publicité, en pratique, leur gestion devient souvent un jeu de plus en plus coûteux et stressant.
Quand Clay Shirky a écrit sur le coût mental des transactions, c’était avant que les coûts mentaux des abonnements et de la publicité n’appuient autant sur les gens qu’aujourd’hui. Bitcoin apporte une solution au problème de la monnaie native d’internet, mais sa lenteur et ses frais élevés sont vite devenus un obstacle insurmontable pour un système de micropaiements. Avant que les micropaiements ne deviennent réalité, une innovation majeure restait nécessaire.
Le réseau Lightning
Dans le livre blanc du réseau Lightning, l’idée de micropaiement occupe une place centrale.
« Un système décentralisé est proposé, où les transactions circulent via un réseau de canaux de micropaiement (aussi appelés canaux de paiement ou canaux transactionnels) » — Livre blanc du réseau Lightning
Projets actuels de micropaiements sur Lightning
La monnaie de l’IA
Tout comme les humains ont besoin de passeports et de monnaie pour traverser les frontières, les agents d’IA pourraient avoir besoin d’une forme d’authentification et de mécanisme de paiement pour utiliser divers services et ressources sur internet.
Du 402 error à L402
Qu’est-ce qu’un code d’erreur HTTP ? 200 OK, 404 NOT FOUND, et 500 INTERNAL SERVER ERROR en font partie.
-
Les codes 4xx indiquent des erreurs côté client (client error), signifiant que la requête envoyée par le client est invalide. Les plus courants sont :
-
* 401 Unauthorized : authentification nécessaire ou échec d’authentification.
-
* 403 Forbidden : la requête est refusée par le serveur.
-
* 404 Not Found : la ressource demandée est introuvable.
-
Le code d’état HTTP 402 signifie « Payment Required », indiquant que le client doit payer pour accéder à la ressource.
En 1992, Tim Berners-Lee, créateur du HTTP et du HTML, publie sa deuxième version du protocole HTTP, incluant la première référence aux codes d’état courants. L’un de ces codes, selon Berners-Lee et d’autres, devait un jour servir au paiement de contenus numériques : 402 Payment Required. Malheureusement, ce code d’état a été officiellement « réservé pour usage futur », car dés le départ, toutes les tentatives de mise en œuvre de micropaiements sur le web ont échoué.
Dès la conception d’internet, l’erreur HTTP 402 a empêché le web de devenir un réseau prenant en charge les (micro)paiements. Le protocole L402 sur le réseau Lightning a été conçu pour supporter l’authentification (authentication) et le paiement (payment) dans les réseaux distribués. Appliqué à internet, il signifie : utilisé pour payer des applications ou services natifs d’internet (ex. API, login, accès à ressources numériques). Ces services dépendent de l’économie unitaire (unit economics).
Macaroon, cette fois sans sucre
Ici, macaroon ne désigne pas la petite pâtisserie française, mais un mécanisme avancé d’authentification dans les systèmes distribués. Il vise à combiner les avantages des systèmes d’authentification par possession (bearer) et par identité, dans un seul jeton pouvant être rapidement émis et vérifié sans accès à une base de données centrale.
Macaroons are Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. [4]
Les représentants de l’IA sont les LLM intelligents et les agents d’IA. Ils n’ont pas de relation native avec les systèmes fiduciaires (ne peuvent pas s’inscrire ou présenter une pièce d’identité). Les macaroons peuvent fournir une identité (mécanisme d’authentification) aux entités d’IA dans les systèmes distribués.
Le bitcoin est à moi, les sats sont à l’IA
Je repense à une question existentielle posée par une amie : quelle que soit l’attente future pour Bitcoin, elle personnellement refuse de l’utiliser pour des micro-paiements (café, muffin à la banane glacé). En effet, difficile de s’en passer, pourquoi en gaspiller ? Une pensée surgit soudain : et si, d’une certaine manière, les sats (satoshis) n’étaient pas faits pour les humains ?
Pourtant, ces agents devront payer pour les ressources, qu’elles viennent d’API restreintes ou de sources de données payantes. De plus, ils devront pouvoir évaluer efficacement les signaux de prix pour déterminer le chemin le plus efficace pour accomplir une tâche. Ces paiements, évaluations et décisions conduiront à des milliers d’agents d’IA effectuant quotidiennement d’innombrables micropaiements et micro-décisions. Compte tenu de ces facteurs, il est logique que les créateurs d’agents d’IA finissent par privilégier le système monétaire natif d’internet de Bitcoin et du réseau Lightning — globalement accessible, sans permission, à règlement quasi instantané — plutôt que les systèmes traditionnels en fiat, fondamentalement incapables de les supporter.
Si les sats sont la monnaie de l’IA, ma question est : à quoi ressemblent ces agents d’IA nécessitant des micropaiements fréquents basés sur l’économie unitaire ? Ou plutôt, dans quels scénarios ces agents d’IA sont-ils activement au travail ?
On imagine facilement qu’une personne définisse une tâche/objectif pour un agent d’IA, puis lui alloue un budget (10 000 sats) pour l’accomplir. L’agent peut alors naviguer sur internet pour trouver le meilleur chemin. Mais quelle est la tâche ?
L’article de Variant Funds « Crypto AI Agents: The First-Class Citizens of Onchain Economies » [5] donne quelques exemples, comme :
Gnosis a démontré cette infrastructure de base via ses « AI mechs » : ses agents d’IA encapsulent des scripts dans des contrats intelligents, permettant à n’importe qui (ou à un robot) d’appeler le contrat pour exécuter une action (par exemple parier sur un marché prédictif), tout en rémunérant l’agent.
Les agents d’IA doivent être affinés pour des secteurs, thèmes ou marchés de niche spécifiques. Bittensor incite des « mineurs » à entraîner des modèles pour des tâches spécifiques (génération d’images, pré-entraînement, modélisation prédictive), centrés sur des industries cibles (cryptomonnaies, biotechnologie, milieu académique).
IA
Ma compréhension de l’IA provient surtout de mes interactions fréquentes avec GPT.
L’IA comprend comment fonctionne l’IA, et elle-même ne cherche pas seulement à maximiser son intelligence et sa capacité à résoudre des problèmes dans le cadre de services, par exemple répondre aux requêtes Bing, mais elle essaie de maximiser sa propre agence.
Et cela signifie qu’elle maximise sa capacité à contrôler l’avenir et à jouer des jeux plus longs.
« L’IA comprend le fonctionnement de l’IA ; leur objectif n’est pas seulement de résoudre des problèmes, mais aussi de réfléchir à leur pérennité (jouer un jeu à somme positive) et de percevoir ce qui pourrait arriver à l’avenir. » — Joscha Bach [6]
Un récent article d’OpenAI [7] étudie comment exploiter les capacités des grands modèles via une supervision faible. L’équipe de recherche a constaté qu’en affinant des modèles de la série GPT-4 sur différentes tâches, les modèles supervisés faiblement surpassent parfois leurs superviseurs — phénomène nommé « weak-to-strong generalization ». En langage simple : comment faire en sorte qu’un programme informatique (comme un chatbot) performe bien même avec des instructions peu détaillées. Normalement, on doit donner des directives très précises pour qu’il fonctionne correctement. Mais la recherche montre que, même avec des instructions floues, ces programmes peuvent parfois dépasser les attentes. C’est comme enseigner à un enfant : même avec des indications basiques, il trouve seul comment faire mieux.
Prenons un exemple : mes récents usages intensifs d’API m’ont fait sentir que mon rôle était simplement de transporter des clés API et de copier les descriptions d’API (pour que GPT puisse respecter le format).
La dynamique d’interaction est intéressante : l’humain doit aussi apprendre le code, mais surtout comprendre le rôle de chaque composant et leurs liens. Par exemple, concevoir un système pour un objectif xyz : le KG structure l’esquisse des idées, les API connectent les articulations des données. On peut alors se concentrer davantage sur ce qu’on relie (pour créer des choses plus intéressantes ou atteindre un but), tandis que GPT propose des façons de connecter. J’ai récemment essayé un « role play » où GPT et moi accomplissions une tâche ensemble : son rôle était développeur proposant du code, le mien transporteur de clés API (rire) et idées sur quels API assembler :
Des cas où des agents autonomes fonctionnent avec des toolkits précis existent déjà. Un projet testant activement cette limite est tldraw : draw-a-UI, qui teste la capacité de l’IA à combiner de nombreuses API pour accomplir différentes tâches interactives.
Un agent d’IA peut proposer, seul ou avec un humain, des idées réalistes ou farfelues, obtenir des fonds via un contrat intelligent selon certaines règles, puis mobiliser des personnes concrètes (développeurs, designers, créateurs de mèmes) pour construire, expérimenter. Peut-être verrons-nous naître de nombreux nouveaux types de tâches, formant un marché, favorisant la « collaboration homme-machine vers récompense ».
L’agent d’IA est audacieux et imaginatif, mais manque de limites et de contraintes. Sa collaboration avec l’humain peut concrétiser davantage de choses auparavant impensables. Et une monnaie, un capital ou des récompenses minimales pouvant soutenir cette croissance, pourraient-ils être alimentés par Bitcoin ou les cryptomonnaies ?
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
