L’inventore di Hashcash e Ceo di Blockstream parla con Atlas21 di come Greenlight possa semplificare la self custody sul Lightning Network. BitVM è “un modo interessante con cui puoi verificare alcune cose basilari con lo script di Bitcoin“.
Negli ultimi mesi si è parlato molto del Lightning Network. La difficoltà di utilizzare Lightning in modo non-custodial e le prospettive di scalabilità della rete sono state al centro del dibattito. Il primo di questi problemi sta provando a risolverlo, tra gli altri, Blockstream, con un servizio chiamato Greenlight.
Per parlare di questo e altro, Atlas21 si è rivolto all’amministratore delegato della società e creatore di Hashcash, Adam Back.
Come funziona Greenlight?
Greenlight è un modo più leggero per le applicazioni con wallet Lightning integrati di interagire con il Lightning Network. È non-custodial – quindi hai le chiavi e firmi nel wallet o nel wallet integrato internamente all’app – ma gli stati della rete (come i nodi, gli stati del gossip protocol, ecc.) sono tutti gestiti da un nodo in cloud, e Blockstream fornisce un servizio per gestirli per te.
Quello che fa il client è fare una richiesta remota per pagare una particolare invoice lightning, la invia al server e il server dà istruzioni su come firmare questo blocco di dati. Fornisce anche dati extra, che sono sufficienti per il client per verificare che ciò che stanno firmando sia sicuro: che pagherà solo la persona giusta. È un po’ come l’interazione tra un hardware wallet e la rete Bitcoin. Gli hardware wallet ricevono informazioni, verificano alcune cose specifiche per essere sicuri e poi firmano, e la rete fa rispettare il resto.
Il principale compromesso è che si perde un po’ di privacy perché si sta rivelando alla rete chi si intende pagare. Un vantaggio è che c’è meno traffico di rete. Se sei offline per giorni o settimane e torni online, puoi normalmente fare transazioni. Mentre normalmente, se porti online altri wallet lightning sincronizzano il nodo completo, la rete gossip, questi wallet hanno una visione meno aggiornata di quali nodi Lightning nella rete siano affidabili – perché i nodi Lightning fanno una sorta di sondaggio per vedere cosa è affidabile e cosa no. In Greenlight questo viene fatto dal server, quindi è sempre aggiornato. Greenlight ti aiuta anche con i backup, perché ha una sorta di backup ridondante nel cloud.
Greenlight offre la possibilità di passare comodamente alla gestione autonoma di un proprio nodo?
Sì, Greenlight è un aiuto per iniziare a usare il Lightning Network in modo non-custodial senza doverti fidare di qualcuno, ma comunque assistito. Puoi anche migrare a un full-node autonomo. Puoi migrare i tuoi stati e la tua storia del nodo Lightning, Greenlight ti aiuta a fare l’upgrade per passare al tuo nodo fisico.
Greenlight ha anche la capacità di utilizzare i servizi LSP (Lightning Service Provider): lavoriamo con Breez per esempio. Il wallet Breez ora sta utilizzando Greenlight e l’LSP di Breez. Abbiamo aggiunto Greenlight al wallet Green in beta, che sta anche utilizzando l’LSP di Breeze. Il sistema Green è anche per gli sviluppatori, per aiutarli a integrare wallet Lightning integrati in, ad esempio, un’applicazione Nostr o un gioco, dove integrare un wallet Lightning completo è un po’ pesante.
Pensi che questo tipo di modello, Greenlight e futuri servizi concorrenti, insieme agli LSP, potrebbero essere la soluzione definitiva per i servizi non-custodial sul Layer 2? O devono essere trovate altre soluzioni?
Penso che lo renda molto più facile perché fare un wallet Lightning custodial è facile lato client, perché non hai chiavi né stato da gestire, quindi sono davvero solo chiamate API. Questa soluzione è un po’ a metà strada. Hai le chiavi, devi firmare e verificare dati, ma c’è molta meno interazione di rete. Quindi, è davvero una cosa molto più facile per un’applicazione o un wallet da usare.
Se guardi i wallet Lightning esistenti, ce ne sono alcuni custodial come Wallet of Satoshi. Poi hai i cosiddetti portafogli con full node come Phoenix, che, se ho capito bene, sincronizza effettivamente un full node prunato, ricevendo le informazioni dal gossip protocol, facendo il calcolo del routing, tutto su mobile. Ci sono LDK e BDK, il toolkit di Block/Square, e sono intesi per aiutare gli sviluppatori di applicazioni a costruire wallet che funzioni un po’ come Phoenix. Quindi, come ho detto prima, è un po’ come il modo in cui un hardware wallet interagisce con la blockchain di Bitcoin. Non riceve tutti i dati, non è un full node, ma tuttavia può essere sicuro e sapere che non verrà ingannato. Con un hardware wallet hai lo stesso problema: i server gestiti da Ledger o Trezor conoscono chi stai cercando di pagare, perché il loro nodi inviano tipicamente la transazione.
Quest’anno abbiamo avuto molte nuove proposte, come ARK, PRIME e recentemente BitVM, che Federico Tenga ha spiegato qui su Atlas21. Hai un’opinione su BitVM?
È abbastanza nuovo, si sta ancora cercando di capirne i limiti. Per il momento, sembra che stia facendo qualcosa di diverso rispetto ad altri sistemi di verifica. La proposta è delle stesse persone che hanno fatto ZeroSync, che è un modo per scaricare uno snapshot UTXO fino a un’altezza di blocco valida e poi ricevere una grande “prova a conoscenza zero” (Zero-knowledge Proof). La verifichi, e la verifica ti dice che tutte le transazioni dal genesis block, fino a questo hash e altezza del blocco, sono transazioni Bitcoin formattate in modo valido, senza la necessità verificare tutte le firme.
È una sorta di prova proattiva, ma con BitVM è semplificata. Il prover mette alcuni fondi in escrow, e un verifier può impegnarsi in un protocollo interattivo, come una partita a scacchi o un gioco di applicazione – dove i due scommettono sul risultato o fanno un’attività commerciale – e si scambiano “prove a conoscenza zero” sullo stato del gioco. Quando il gioco è concluso – come con Lightning, dove si può fare una chiusura collaborativa – possono entrambi firmare.
Ma se c’è una disputa – dove il prover dice “Ho vinto il gioco” e il verifier si sente imbrogliato – il verifier dovrebbe avere abbastanza informazioni per smentire. E si scopre che la smentita è molto più compatta della prova. L’idea è che se il prover fa un’affermazione falsa, sarà costretto a rivelare cose incoerenti con la prova. È un modo interessante in cui lo script di Bitcoin di oggi può verificare alcune cose di base dove sarebbe troppo costoso verificare un’intera prova.
Il titolo del white paper è abbastanza ambizioso: ‘Calcolare qualsiasi cosa su Bitcoin’. Pensi che questo tipo di funzione possa portare alcune delle funzioni delle altcoin su Bitcoin in futuro?
Beh, la proposta iniziale è in realtà un gioco tra due parti, un po’ come un canale lightning. Ci sono fondi in escrow, time locks e se una parte se ne va, l’altra può riavere i fondi. Al momento, è un protocollo a due parti.
La domanda sull’applicabilità generale si riduce a: “Puoi usarlo per tutto, andando oltre le due parti?” Una possibilità menzionata da Robin Linus è un protocollo tra il prover e dozzine o ‘n’ verifier, in modo tale che se anche un solo verificatore può confutare la prova, allora sai che non è corretta. Puoi rendere la verifica aperta a più persone. Ovviamente ciò aggiunge un certo rischio, che è quello che uno dei verifier maliziosamente concordi con il fatto che la chiusura del canale sia corretta e prenda i soldi attraverso la collusione con il prover. Non ci sono pasti gratis. La vera domanda aperta è se puoi creare l’interazione tra un prover con fondi in escrow e tutti gli altri, affidandoti ai miner per rivendicare la prova di frode. Questa è una possibilità più potente ma ha alcuni rischi di prevaricazione dei miner, e altre questioni aperte. È qui che diventa più ambizioso.
