Subbit presenta un canale di pagamento su Cardano per la fatturazione delle API basata sull'utilizzo

Dominic Wallis ha presentato Subbit.xyz alla 77ª Cardano Developers Office Hours con un problema specifico: una richiesta API può costare meno della commissione e del tempo necessari per una transazione su blockchain. Il suo sistema abbina impegni di pagamento firmati a uno smart contract su Cardano, consentendo a un fornitore di soddisfare piccole richieste e riscuotere gli addebiti approvati in un secondo momento. La presentazione ha mostrato come i componenti di pagamento comunicano, mentre l'integrazione con un servizio in produzione resta il prossimo passo del progetto.

Un canale di pagamento pensato per servizi a consumo

Subbit.xyz è progettato per servizi che possono misurare ciò che un cliente consuma, come chiamate API, trasferimenti di dati o richieste di AI. Gli abbonamenti mensili addebitano un periodo di accesso, mentre le fatture arrivano dopo che l'utilizzo è avvenuto. Wallis ha proposto un legame più stretto tra ogni unità di servizio e l'importo che il cliente autorizza.

Un cliente apre un canale depositando fondi secondo le regole di uno smart contract su Cardano. Quando richiede il servizio, il cliente firma un IOU che indica l'importo cumulativo che il fornitore può riscuotere. Il fornitore verifica la firma e i fondi che la sostengono prima di evadere la richiesta. Ogni IOU è legato al proprio canale, impedendo che una firma destinata a un conto venga riutilizzata contro un altro.

Il canale è limitato a due partecipanti, con i pagamenti che fluiscono dal cliente al fornitore. Il cliente può smettere di autorizzare nuovi addebiti, mentre il fornitore detiene una pretesa per il servizio già erogato. Il canale regola il pagamento, non verifica la qualità di una risposta API né come il fornitore gestisce le informazioni sensibili.

Come funzionano le richieste di incasso e la chiusura del canale su Cardano

Il fornitore può inviare l'ultimo IOU allo smart contract e richiedere l'importo autorizzato finché il canale rimane aperto. Le richieste precedenti sono contabilizzate, quindi lo stesso importo non può essere prelevato di nuovo. Se il cliente aggiunge fondi, il rapporto può continuare senza aprire un nuovo canale.

Wallis ha illustrato la configurazione con 10 ADA destinati al servizio e ulteriori 2 ADA riservati ai requisiti UTxO di Cardano. Il cliente può chiudere il canale quando desidera andarsene. Il fornitore ha quindi un periodo, concordato all'apertura, per effettuare una richiesta finale, dopo di che il cliente può recuperare il saldo.

I fornitori che servono molti clienti possono combinare le richieste in un'unica transazione. Wallis ha mostrato un esempio che teneva conto di 47 canali a un costo di circa 38 centesimi di dollaro USA. Si trattava di una cifra della sua presentazione, non di una media riportata per il traffico in produzione. Ha individuato nella quantità di dati di transazione il vincolo immediato all'espansione di tali lotti.

Il design dell'integrazione prevede un emittente accanto all'applicazione del cliente e un proxy davanti al servizio esistente del fornitore. L'emittente allega un IOU a una richiesta. Il proxy lo verifica e inoltra una richiesta accettata al servizio.

I fornitori dovrebbero comunque gestire questi componenti di pagamento e seguire la relativa attività del canale su Cardano, anche se la loro applicazione originale non implementa logiche blockchain.

La prova restante è un'integrazione con un servizio reale

Le domande dei partecipanti hanno messo in luce diversi confini del modello. I rimborsi richiedono un pagamento separato perché il canale muove fondi in una sola direzione. Un fornitore preoccupato per le variazioni di prezzo degli asset può richiedere i fondi tempestivamente oppure rivedere i prezzi per le richieste future. Wallis ha anche dimostrato che un canale può usare un altro asset e ha citato USDM come esempio.

Le richieste regolate su Cardano rivelano gli importi riscossi, sebbene le singole richieste di servizio restino off chain. I partecipanti hanno chiesto se le prove a conoscenza zero potessero migliorare la privacy o il raggruppamento. Wallis ha sostenuto che un tale design aggiungerebbe complessità e che la dimensione dei dati di transazione è il problema di scalabilità più immediato per Subbit.xyz.

Un altro partecipante, David, ha incalzato Wallis sulla domanda: quale fornitore cambierebbe il proprio sistema di fatturazione per usare il canale? Wallis ha discusso potenziali usi nell'infrastruttura API, nella fatturazione per l'AI e nella consegna di dati a consumo. Ha descritto lavori precedenti con Orcfax e ha riconosciuto il supporto di Project Catalyst, ma non ha presentato un integratore in produzione attuale né dati di utilizzo commerciale.

Nella dimostrazione finale, l'emittente e il server si sono scambiati dati di pagamento, ma il servizio sottostante non è stato eseguito. Wallis ha invitato i fornitori a integrare Subbit.xyz. Ciò consentirebbe alla prossima dimostrazione di collegare tutte e tre le parti della transazione: una risposta di servizio misurata, l'IOU firmato dal cliente e la richiesta del fornitore su Cardano.