Subbit présente un canal de paiement Cardano pour la facturation d’API basée sur l’usage

Dominic Wallis a présenté Subbit.xyz lors de la 77e session Cardano Developers Office Hours avec un problème précis : une requête API peut coûter moins que les frais et le temps requis pour une transaction sur la blockchain. Son système associe des engagements de paiement signés à un contrat intelligent Cardano, permettant à un fournisseur de traiter de petites requêtes et d’encaisser ultérieurement les montants approuvés. La présentation a montré comment les composants de paiement communiquent, tandis que l’intégration à un service en production demeure la prochaine étape du projet.

Un canal de paiement conçu pour des services à la consommation mesurée

Subbit.xyz est conçu pour des services capables de mesurer ce qu’un client consomme, comme des appels API, des transferts de données ou des requêtes d’IA. Les abonnements mensuels facturent une période d’accès, tandis que les factures arrivent après que l’usage a eu lieu. Wallis a proposé un lien plus étroit entre chaque unité de service et le montant que le client autorise.

Un client ouvre un canal en déposant des fonds selon les règles d’un contrat intelligent Cardano. Lorsqu’il demande un service, le client signe un IOU indiquant le montant cumulatif que le fournisseur peut percevoir. Le fournisseur vérifie la signature et les fonds qui la garantissent avant de satisfaire la demande. Chaque IOU est lié à son canal, empêchant qu’une signature destinée à un compte soit réutilisée contre un autre.

Le canal est limité à deux participants, avec des paiements allant du client vers le fournisseur. Le client peut cesser d’autoriser de nouveaux prélèvements, tandis que le fournisseur détient une créance pour le service déjà rendu. Le canal régit le paiement ; il ne vérifie ni la qualité d’une réponse API ni la manière dont le fournisseur traite les informations sensibles.

Fonctionnement des créances et de la fermeture de canal sur Cardano

Le fournisseur peut soumettre le dernier IOU au contrat intelligent et réclamer le montant autorisé tant que le canal reste ouvert. Les créances antérieures sont prises en compte, de sorte que le même montant ne peut pas être retiré une seconde fois. Si le client ajoute des fonds, la relation peut continuer sans ouvrir un nouveau canal.

Wallis a illustré la configuration avec 10 ADA alloués au service et 2 ADA supplémentaires réservés aux exigences UTxO de Cardano. Le client peut fermer le canal lorsqu’il souhaite partir. Le fournisseur dispose alors d’une période convenue à l’ouverture pour effectuer une réclamation finale, après quoi le client peut récupérer le solde.

Les fournisseurs qui servent de nombreux clients peuvent regrouper des créances dans une seule transaction. Wallis a montré un exemple qui prenait en compte 47 canaux pour un coût d’environ 38 cents US. Il s’agissait d’un chiffre issu de sa présentation, et non d’une moyenne rapportée pour du trafic en production. Il a identifié la quantité de données de transaction comme la contrainte immédiate à l’extension de tels lots.

La conception de l’intégration place un émetteur à côté de l’application du client et un proxy devant le service existant du fournisseur. L’émetteur joint un IOU à une requête. Le proxy le vérifie et transmet au service une requête acceptée.

Les fournisseurs devraient malgré tout exploiter ces composants de paiement et suivre l’activité pertinente des canaux sur Cardano, même si leur application d’origine n’implémente pas de logique blockchain.

Le test restant est une intégration à un service réel

Les questions des participants ont mis en lumière plusieurs limites du modèle. Les remboursements nécessitent un paiement séparé car le canal déplace les fonds dans une seule direction. Un fournisseur préoccupé par les variations de prix des actifs peut réclamer les fonds rapidement ou réviser les tarifs pour des requêtes futures. Wallis a aussi démontré qu’un canal peut utiliser un autre actif et a cité USDM comme exemple.

Les créances réglées sur Cardano révèlent les montants perçus, bien que les requêtes de service individuelles restent hors chaîne. Des participants ont demandé si des preuves à divulgation nulle de connaissance pouvaient améliorer la confidentialité ou le regroupement. Wallis a soutenu qu’une telle conception ajouterait de la complexité et que la taille des données de transaction est la question d’échelle la plus immédiate pour Subbit.xyz.

Un autre participant, David, a interrogé Wallis sur la demande : quel fournisseur changerait son système de facturation pour utiliser le canal ? Wallis a évoqué des usages potentiels dans l’infrastructure API, la facturation de l’IA et la livraison de données mesurées. Il a décrit un travail antérieur avec Orcfax et a reconnu le soutien de Project Catalyst, mais n’a présenté ni intégrateur en production actuellement ni chiffres d’utilisation commerciale.

Lors de la démonstration de clôture, l’émetteur et le serveur ont échangé des données de paiement, mais le service sous-jacent n’a pas été exécuté. Wallis a invité des fournisseurs à intégrer Subbit.xyz. Cela permettrait à la prochaine démonstration de relier les trois parties de la transaction : une réponse de service mesurée, l’IOU signé du client et la créance du fournisseur sur Cardano.