“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution”
Questo è ciò che viene recitato nel whitepaper originale di Bitcoin creato da Satoshi Nakamoto;
dunque sintetizzando in estremo, qual è la natura e lo scopo di bitcoin se non quella di essere un sistema di contante digitale che garantisca transazioni irreversibili?
Ebbene, nonostante in parte l’abstract originale sia stato pienamente rispettato, (ad oggi BTC è censorship-resistant) non possiamo di certo affermare che sia una forma di pagamento diffusa, comoda e utilizzabile.
La problematica del protocollo Bitcoin è che non è scalabile;
il blocktime (ovvero il tempo per “minare” ossia creare un blocco) è all’incirca di 10 minuti e la dimensione massima dei blocchi stessi è di 1 megabyte.
Il risultato è che mediamente con la rete Bitcoin si possono effettuare 3.7 tps (transaction per second), dato che risulta decisamente “povero” per un sistema che in origine auspicava di essere un sistema di pagamento globale.
In questo contesto si inserisce la “lightning network” ovvero la soluzione di scalabilità che permette di trasferire bitcoin a velocità istantanea e con costi di commissione praticamente nulli; l’ideale in altre parole per utilizzare bitcoin come sistema di pagamento.
Ma in pratica cos’è la lightning network?
Lightning Network non è altro che un’applicazione di Bitcoin, un sistema di messaggistica decentralizzato (broadcasting) dove invece di inviare messaggi, viene scambiato del valore.
È formata da una rete di canali di pagamento Bitcoin tra nodi; più grande è la rete, maggiore è il numero di transazioni, quindi più canali e nodi significano più successo negli eventi di transazione.
A differenza di Bitcoin protocol, su Lightning Network solo due transazioni sono scritte sulla blockchain: la funding transaction e la settlement transaction.
Tutte le altre transazioni avvengono senza toccare la blockchain (commitment transaction).
Con le transazioni offchain di Bitcoin (Lightning), gli operatori dei nodi sui due lati del canale tengono traccia del saldo con il cosiddetto “stato del canale (Channel State)”.
Semplificando all’estremo, è un protocollo peer to peer per effettuare transazioni offchain tra un canale privato tra noi e il ricevente; questo canale va prima aperto ed effettivamente alimentato con fondi da ambo le parti (funding transaction), che poi si scambieranno valore per il numero di transazioni desiderate, a costo 0, illimitatamente e istantaneamente (commitment transaction).
Una volta terminate le operazioni e si decide di chiudere il canale, ll bilancio viene finalizzato onchain e aggiornato ufficialmente tenendo conto di tutte le transazioni effettuate (settlement transaction). Riassumendo, è una sorta di registro contabile ove al termine delle operazioni si vanno a conteggiare e aggiornare i saldi dei due operatori, scrivendo il risultato finale del loro bilancio al netto delle operazioni effettuate.
Vediamo dunque come funziona:
Alice vuole aprire un canale di 1M di satoshi verso il nodo di Bob (0.01 BTC).
Deve conoscere l’URI del nodo di Bob (L’URI è un parametro univoco come un URL web).
URI = Nodo PubKey @ IP (o onion address)
esempio: 02e74c09ca720c891221164424651f62176a4737a4b2fd4f75a5befee127e90b9e@170.75.160.17:9735
Alice crea una coppia di chiavi privata/pubblica utilizzando il suo nodo Bitcoin e informa il nodo di Bob che desidera aprire un canale tramite il messaggio open_channel (messaggio nel protocollo LN).
A sua volta anche Bob crea una nuova coppia di chiavi privata/pubblica e fornisce il consenso al canale che Alice sta creando, inviando la sua chiave pubblica ad Alice tramite il messaggio di accept_channel.
Alice ora crea una funding transaction (dal suo portafoglio Bitcoin) che invia 1M satoshi all’indirizzo multifirma ottenuto dalle due chiavi pubbliche (onchain multisig transaction).
Alice non trasmette ancora questa transazione alla rete Bitcoin, ma invia a Bob l’ID transazione in un messaggio LN (funding_created) insieme alla sua firma per consentire a Bob di creare la sua commitment transaction.
Entrambi creano la loro commitment transaction.
Questa transazione utilizza i fondi della Funding transaction: nel caso di Alice, le restituirà tutti i fondi, nel caso di Bob restituirà zero satoshi.
Alice e Bob non si scambiano le transazioni perché ognuno di loro può costruirle in modo indipendente, utilizzando la firma di entrambi; si scambiano dunque le sole firme.
Bob fornisce dunque una firma per la commitment transaction di Alice e invia questo messaggio usando funding_signed.
Ora che le firme sono state scambiate, Alice può trasmettere la funding transaction alla rete Bitcoin.
Il canale tra Alice e Bob è aperto.
I fondi di Alice sono ora sul canale come saldo locale/Local Balance (o capacità in uscita/outbound capacity).
Alice può spendere, ma NON ricevere.
Bob può ricevere, ma NON spendere.
Se Alice vuole ricevere su quel canale, deve prima spendere dei fondi
Dunque in che modo Alice invia i fondi?
Per le transazioni onchain, ha bisogno di un indirizzo pubblico Bitcoin.
Per le transazioni su Lightning, Alice ha bisogno di una Invoice (Bolt 11).
Esempio:
lnbc1m1p0m4sj8pp5rq72jn0qjpvut36u9et2j70n0l7rdake5v052kae5skumgz6zldqdqqcqzpgxqrrsssp577msvl9cvekq8z90lcvk86mpr0ve83zzwde9srcg0kesddstjqq9qy9qsqc7lyx5pdpr9wx2rv0y3cewg8qjja40lx4l3t93y84tvuz4x6429qh6wdczm97urd5p45hx4uy8qhyel5xfqfp987cr48867fyuccvpspqpxwaq
L’indirizzo pubblico di Bitcoin è statico e offline;
Può inviare quanti fondi vuole, quando vuole
L’Invoice è “dinamica” (per lo standard Bolt 11) e “online”;
Alice deve richiedere l’Invoice al destinatario in un momento specifico nel tempo (c’è una scadenza) e per un importo specifico.
Non può inviare fondi se il nodo del destinatario è offline.
Stessa cosa quando deve ricevere i fondi.
Ma veniamo alla vera potenzialità di lightning network:
Lightning prevede che si possano inviare dei fondi non solo da A a B e viceversa, ma anche a C, D, E…senza che questi siano direttamente collegati al mittente.
Per farlo, si utilizza un sistema di smart contract chiamato Hash Time – Locked Contracts (HTLC).
HTLC = hash verification (H) + time expiration verification
H = Hash(R)
R = Secret (detto anche Preimage)
Poniamo che Alice debba pagare Eric ma non ha un canale diretto:
Eric crea una preimage (il segreto R) e invia ad Alice l’hash di questo segreto.
Solo Eric conosce il segreto.
Alice crea un HTLC contenente l’hash inviato da Eric + un timelock di N blocchi Bitcoin.
Dentro questo HTLC Alice specifica quanti bitcoin vanno inviati:
x bitcoin per Eric, y bitcoin per i partecipanti della catena di pagamento, come commissione per l’invio.
Es. Alice deve pagare 1 bitcoin a Eric.
Blocca nell’ HTLC 1.0003 bitcoin, 1 per Eric, 0.0003 per i partecipanti della catena.
Alice invia a Bob questo HTLC.
Se Bob non scoprirà il segreto R di Eric entro N blocchi stabiliti da Alice, questa tornerà in possesso dei bitcoin bloccati nell’ HTLC.
Bob è incentivato a scoprire R per ottenere le commissioni.
Bob crea dunque un HTLC contenente l’hash dato da Eric ad Alice e un nuovo timelock di N-1 e lo invia a Carol.
Se Carol non scoprirà il segreto R di Eric entro N-1 blocchi stabiliti da Bob, questo tornerà in possesso dei bitcoin bloccati nell’ HTLC.
Carol è incentivata a scoprire R per ottenere le restanti commissioni.
Dentro questo HTLC Bob specifica quanti bitcoin vanno inviati:
1 bitcoin per Eric, 0.0002 per i partecipanti della catena.
Bob si intascherà 0.0001 bitcoin se il pagamento andrà a buon fine.
Carol crea dunque un HTLC contenente l’hash dato da Eric ad Alice e un nuovo timelock di N-2 e lo invia a Diana.
Se Diana non scoprirà il segreto R di Eric entro N-2 blocchi stabiliti da Carol, questa tornerà in possesso dei bitcoin bloccati nell’ HTLC.
Diana è incentivata a scoprire R per ottenere le restanti commissioni.
Dentro questo HTLC, Carol specifica quanti bitcoin vanno inviati:
1 bitcoin per Eric, 0.0001 per Diana.
Carol si intascherà 0.0001 bitcoin inviati da Bob se il pagamento andrà a buon fine.
Infine, Diana crea un HTLC contenente l’hash dato da Eric ad Alice e un nuovo timelock di N-3 e lo invia a Eric.
Eric ha il segreto R usato per creare l’hash iniziale.
Se Eric non sblocca l’ HTLC entro N-3 blocchi, allora non riceverà il pagamento e gli altri partecipanti riotterranno i loro fondi bloccati.
Eric è incentivato a sbloccare l’ HTLC per ottenere il pagamento.
Eric sblocca l’ HTLC rivelando il segreto a Diana.
Diana incassa definitivamente le commissioni perché rivela il segreto a Carol sbloccando l’ HTLC di quest’ultima.
Carol conosce R e, per incassare le commissioni inviate da Bob, sblocca l’ HTLC di Bob.
Bob ora conosce R, quindi per incassare le commissioni, sblocca l’ HTLC di Alice.
Alice ha inviato 1 bitcoin a Eric e 0.0003 bitcoin ai partecipanti, che si sono “spartiti” le commissioni.
Conclusioni finali:
Lightning Network potenzialmente è la killer app, che potrebbe davvero eliminare per sempre i circuiti di pagamento “terze parti”;
un sistema distribuito, decentralizzato, veloce, efficiente ed economico, oltre che con un importante grado di privacy che ad oggi con il prossimo avvento delle CBDC (central bank digital currency), sarebbe una validissima alternativa libertaria e indipendente.
Home
Market&Data
Scrivi per noi
Wallet
