Cos'è Lightning Network?

Tra i limiti ad oggi più stringenti della rete Bitcoin vi sono: l'incapacità di gestire un numero elevato di transazioni (al livello, ad esempio, del numero di transazioni gestite dal circuito VISA), le commissioni e i tempi di conferma elevati, che rendono di fatto Bitcoin inutilizzabile per i micropagamenti. Lightning Network è uno dei tentativi per risolvere tutti questi problemi. Vediamo come funziona e se davvero può essere la soluzione definitiva per rendere Bitcoin un mezzo di scambio efficiente.

Perché Lightning Network?

Attualmente tramite Bitcoin vengono effettuate circa 200 mila transazioni al giorno (fonte Blockchain.com). Tuttavia, nella sua attuale implementazione Bitcoin non è in grado neanche lontanamente di coprire la totalità degli scambi commerciali che avvengono oggi quotidianamente nel mondo. Basti pensare che la sola rete VISA ha raggiunto a fine 2013 un picco di 47 mila transazioni al secondo, mentre Bitcoin riesce al massimo a gestire all'incirca una decina di transazioni al secondo.

Un limite intrinseco è dato dall'approccio che il protocollo stesso utilizza per raggiungere il consenso sullo stato della blockchain. L'esecuzione di un pagamento sulla rete Bitcoin, infatti, avviene inviando in broadcast a tutti i nodi la relativa transazione, affinché possa essere validata ed inserita dai miner all'interno di un blocco nella blockchain. Ogni nodo della rete riceve pertanto le informazioni relative a tutte le transazioni effettuate.
Inoltre, la conferma di tale transazione, necessaria per evitare il fenomeno del double spending, richiede un tempo in alcuni casi non trascurabile, in quanto un nuovo blocco viene generato in media ogni 10 minuti.

Non solo, in alcuni casi l'inserimento di una transazione sulla blockchain richiede anche un costo non trascurabile. La restrizione ad 1 MB sulla dimensione massima di un blocco fa sì che quando nella rete vi sono troppe transazioni da validare si verifica un collo di bottiglia. Ovviamente in situazioni del genere ha precedenza chi paga commissioni più alte poiché i miner vogliono massimizzare il loro profitto, e dunque danno priorità alle transazioni in base alle commissioni pagate.

La seguente immagine, tratta dal sito BitInfoCharts, mostra come sul finire del 2017 il costo medio per registrare una transazione Bitcoin si sia impennato fino a raggiungere picchi di oltre 50 dollari a transazione.

Andamento del costo medio a transazione su rete Bitcoin

Sullo stesso sito è possibile vedere in tempo reale qual è l'attuale commissione media (in dollari) richiesta per avere una transazione scritta sul prossimo blocco generato.

Quindi il problema della scalabilità riguarda non solo la velocità della rete, espressa in numero di transazioni gestibili al secondo, ma anche il costo della stessa, espresso come commissione che è necessario pagare per l'inserimento della transazione nella blockchain, al crescere del numero di transazioni effettuate.

Nasce quindi la necessità di creare un meccanismo che permetta alla rete Bitcoin di gestire un numero più elevato di transazioni, in modo efficiente e senza che il costo delle stesse aumenti drasticamente.

Una prima, semplice, soluzione al problema è quella di aumentare la dimensione massima del blocco; è questa, ad esempio, una delle soluzioni seguite da Bitcoin Cash, un hard fork di Bitcoin, che ha portato la dimensione massima del blocco prima a 8MB e poi, di recente, a 32MB. Basta un semplice calcolo però per accorgersi che questa, da sola, non può essere la soluzione definitiva al problema della scalabilità.
Considerando che in media una transazione all'interno di un blocco occupa circa 300 byte e supponendo di non imporre alcun limite massimo alla dimensione di un blocco, se volessimo gestire con Bitcoin lo stesso picco di 47 mila transazioni al secondo gestito da VISA, un blocco giungerebbe ad avere una dimensione pari a circa 8 GB. Ovvero, supponendo un carico più o meno costante, avremmo oltre 400 TB di dati generati l'anno. Naturalmente questo farebbe sì che ben pochi nodi sarebbero in grado di gestire un tale carico, sia in termini di spazio occupato su disco dalla blockchain, sia in termini di banda richiesta: per l'ipotesi precedente sarebbe necessaria una banda di almeno 120 megabit al secondo. La riduzione del numero dei nodi della rete non è un bene per la rete stessa, poiché ciò porterebbe ad una maggiore centralizzazione, con tutti i rischi che ne conseguono.

Diversi approcci sono allora stati proposti per tentare di risolvere questo problema. Lightning Network è uno di questi, basato sull'idea di ridurre il numero di transazioni che devono essere effettivamente inserite nella blockchain.

Cos'è Lightning Network?

Lightning Network è un protocollo di pagamento detto di secondo livello (in gergo Layer-2 o semplicemente L-2). L’idea alla base di Lightning Network è che non tutti i pagamenti debbano essere registrati come transazioni sulla blockchain, come avviene oggi, ma che questi avvengano all'interno di "registri contabili" privati fra le due parti, chiamati in gergo canali di pagamento bidirezionali (o, in inglese, bidirectional payment channel), e che vengano registrate sulla blockchain solo due transazioni: quella che serve a creare il canale, in cui le due parti trasferiscono fondi al canale stesso, e quella in cui il canale viene chiuso ed il saldo finale viene redistribuito alle due parti.

Possiamo vedere Lightning Network un po' come l'equivalente tecnologico del vecchio taccuino del droghiere, su cui le nostre nonne facevano segnare gli importi dei piccoli acquisti fatti quotidianamente per poi saldare la somma totale a fine settimana (o, più comunemente, una volta al mese all'arrivo dello stipendio).

Rimuovendo la necessità di inserire ogni transazione nella blockchain principale, gli utenti possono effettuare pagamenti fra di loro senza dover attendere 10 minuti per il mining del blocco, senza dover competere fra di loro per uno spazio sul blocco, ed eventualmente dover anche pagare commissioni elevate rispetto all'entità del pagamento.

Transazioni non confermate

Bitcoin gestisce transazioni, ovvero trasferimenti di valuta in bitcoin. Ciascuna transazione contiene input, ovvero indirizzi da cui vengono prelevati bitcoin, e output, ovvero indirizzi verso cui sono inviati bitcoin. Ogni input deriva dall'output di una transazione precedente e deve pertanto includere i requisiti necessari a sbloccare tale output, come ad esempio la firma effettuata con la chiave privata corrispondente all'indirizzo. Allo stesso modo gli output stabiliscono nuovi requisiti che devono essere inclusi nell'input di una transazione successiva affinché tale output possa essere utilizzato.

Il protocollo Lightning Network fa largo uso di transazioni non confermate, ovvero transazioni che non vengono immediatamente inviate in broadcast sulla rete Bitcoin per essere registrate sulla blockchain. Esse sono invece memorizzate localmente sui nodi degli utenti. Tuttavia, se si dispone dei requisiti necessari a sbloccare l'input, queste transazioni possono essere in ogni momento inviate sulla rete e registrate sulla blockchain.

Nell'immagine sottostante, ad esempio, le transazioni confermate sulla blockchain sono rappresentate con un bordo nero e sfondo verde. La transazione in blu invece non è confermata ma è conservata privatamente da Anna. La transazione in rosso, infine, non è confermata ed è conservata privatamente da Bruno. Le frecce stanno ad indicare come l'output di una transazione sia utilizzato come input di un'altra transazione.

In qualsiasi momento Anna può firmare e registrare la propria transazione ed in tal modo inviare 1 BTC a Bruno. Solo dopo che tale transazione è stata registrata in un blocco della blockchain, Bruno può firmare e registrare la sua transazione, nella quale invia 0.4 BTC a Carlo (e tiene 0.6 BTC per sé).

In verde e con il simbolo è indicato il saldo finale una volta che tutte le transazioni sono state confermate sulla blockchain.

Transazioni non confermate

Come funziona Lightning Network?

Cerchiamo di capire meglio il funzionamento di Lightning Network attraverso un esempio concreto.

Ipotizziamo che Bruno abbia un negozio di vendita online che accetta pagamenti in bitcoin e che Anna sia una cliente che effettua molti acquisti (anche di piccolo importo) sul negozio di Bruno. Attualmente, per ogni acquisto in bitcoin effettuato da Anna, è necessario che ella registri una transazione di pagamento sulla blockchain affinché Bruno possa riconoscere e verificare il pagamento effettuato da Anna.

Supponiamo ora che Bruno voglia offrire ad Anna la possibilità di pagare tramite Lightning Network. Per far ciò, come detto, Anna e Bruno devono creare un canale di pagamento. Questo viene realizzato registrando sulla blockchain una transazione nella quale Anna e Bruno inviano entrambi un importo stabilito a priori ad un indirizzo multifirma 2-di-2. Gli importi depositati da Anna e Bruno non devono necessariamente essere uguali e, almeno in teoria, una delle due parti può anche non depositare nulla nel canale.

Cos'è un indirizzo multifirma ?

Gli indirizzi multifirma (in gergo multisig) sono indirizzi Bitcoin che, come dice il nome stesso, richiedono più chiavi private per sbloccare l'output di cui fanno parte. La loro introduzione nel protocollo Bitcoin è descritta nel BIP 11.

Ciò che rende ancor più interessante questo tipo di indirizzi è la possibilità di definire condizioni di tipo M-di-N, ovvero per sbloccare ed utilizzare l'output della transazione è richiesta la firma di M chiavi private fra le N indicate (naturalmente M deve essere minore o uguale ad N).

Ad esempio, in un servizio di escrow, una somma può essere depositata su un indirizzo multifirma 2-di-3, in cui ciascuna delle due parti che effettuano la transazione possiede una chiave privata mentre la terza è in possesso del servizio di escrow. In caso di disaccordo fra le parti, l'output potrà dunque essere sbloccato solo tramite la firma dell'escrow (oltre che di una delle due parti).

Lightning Network utilizza indirizzi multifirma 2-di-2. Ciò significa che lo sblocco dell'output richiede le firme di entrambe le parti (nel nostro caso Anna e Bruno).

In realtà Lightning Network utilizza una versione più generica di indirizzi multifirma chiamata Pay to script hash o, in breve, P2SH, descritta nel BIP 16 (tali indirizzi sono riconoscibili perché iniziano con la cifra 3 anziché 1). Nulla cambia però per ciò che riguarda la nostra analisi.

Nell'esempio in figura, Anna e Bruno hanno creato un indirizzo multifirma di cui possiedono le chiavi di sblocco. Anna non può spendere i bitcoin presenti in questo indirizzo senza avere anche la firma di Bruno sulla transazione. Si noti che, dopo che è stata firmata una transazione non è più possibile modificare il contenuto della transazione stessa.

Multifirma

Ad esempio supponiamo che Anna depositi 1 BTC nel canale e Bruno depositi 0.5 BTC. Sarà allora creata e convalidata un transazione, detta transazione di apertura del canale (o, in inglese, funding transaction), in cui come input avremo 1 BTC proveniente da Anna e 0.5 BTC provenienti da Bruno, e come output avremo 1.5 BTC assegnati ad un indirizzo multifirma 2-di-2.

Anna e Bruno creeranno (e firmeranno) inoltre una corrispondente transazione, in cui i rispettivi saldi vengono restituiti alle due parti, ovvero 1 BTC ad Anna e 0.5 BTC a Bruno. Tale transazione è detta transazione di chiusura del canale. Tuttavia questa transazione di chiusura non viene confermata, cioè scritta sulla blockchain, ma viene conservata privatamente sia da Anna che da Bruno.

Transazioni di apertura e chiusura di un canale

A questo punto il canale Lightning Network è stato creato. Supponiamo ora che Anna effettui un acquisto da Bruno per un importo di 0.2 BTC, e che decida di pagare Bruno utilizzando tale canale. Anna e Bruno allora aggiorneranno il saldo sul canale nel seguente modo: 0.8 BTC ad Anna (= 1 - 0.2 BTC) e 0.7 BTC a Bruno (= 0.5 + 0.2 BTC). L'aggiornamento del saldo avviene generando una nuova transazione di chiusura che va a sostituire quella generata precedentemente, che viene dunque scartata. In questo caso i rispettivi saldi restituiti alle due parti, sono 0.8 BTC ad Anna e 0.7 BTC a Bruno. Anche in questo caso la transazione non viene registrata sulla blockchain.

Nuova transazione di chiusura di un canale

Immaginiamo ora che Anna faccia un reso di parte della merce acquistata e che pertanto Bruno restituisca 0.1 BTC ad Anna. Anche in questo caso Anna e Bruno aggiorneranno il saldo sul canale generando una nuova transazione di chiusura (la terza) in cui i saldi restituiti alle parti saranno 0.9 BTC ad Anna (= 0.8 + 0.1 BTC) e 0.6 BTC a Bruno (= 0.7 - 0.1 BTC). Di conseguenza, anche la seconda transazione di chiusura dovrà essere scartata.

Anna e Bruno potranno continuare a fare transazioni fra loro nel modo sopra descritto, aggiornando di volta in volta il bilancio del canale tramite la generazione di una nuova transazione che andrà a sostituire quelle precedenti. Quando Anna e Bruno decideranno di chiudere il canale di pagamento, uno di loro (è indifferente chi) registrerà sulla blockchain l'ultima transazione di chiusura disponibile, in cui i saldi (aggiornati) verranno restituiti alle due parti.

È importante osservare che, effettuando pagamenti tramite la Lightning Network, non si stanno in realtà scambiando effettivamente dei bitcoin. Si sta invece aggiornando un registro condiviso fra due partecipanti al canale Lightning. L'unica occasione in cui vengono realmente trasferiti dei bitcoin all'interno della blockchain principale è quando viene aperto il canale (per "caricare" bitcoin nel wallet multifirma) e quando viene chiuso il canale (per redistribuire il saldo finale alle due parti che hanno aperto il canale).

Fidarsi è bene ... non fidarsi è meglio

Ciò che abbiamo sin qui descritto è il comportamento ideale del protocollo Lightning Network; abbiamo infatti implicitamente assunto che tutte le parti coinvolte siano cooperative e non abbiano comportamenti fraudolenti.

Ma che succede se una delle due parti coinvolte vuol provare a frodare la controparte? Cosa succede ad esempio se, nel caso precedente, Bruno dopo aver restituito 0.1 BTC ad Anna, registra sulla blockchain la precedente transazione di chiusura, quella in cui a lui sono attribuiti 0.7 BTC anziché 0.6 BTC?

Ovviamente il protocollo Lightning Network deve essere in grado di gestire in modo opportuno anche questi casi. L'idea alla base della soluzione prevista è quella per cui entrambe le parti abbiano interesse ad utilizzare sempre il saldo più aggiornato in una eventuale registrazione della transazione di chiusura del canale. Il disincentivo a violare tale regola è dato dal fatto che se così non fosse, se ad esempio Bruno registrasse una vecchia transazione con un saldo non aggiornato, la controparte avrebbe modo di ottenere tutto l'importo depositato nel canale.

Per capire nel dettaglio come viene implementato questo meccanismo dobbiamo introdurre un nuovo strumento: le transazioni con lock temporali.

Cosa sono i lock temporali (Time-Lock) ?

I lock temporali (o time-lock) sono meccanismi che consentono di bloccare l'output di una transazione per renderlo non spendibile (ovvero, tecnicamente, non utilizzabile come input in una transazione successiva) sino ad un determinato momento nel futuro.

Vi sono due tipi differenti di time-lock. Il primo, chiamato CheckLockTimeVerify (in breve CLTV), descritto nel BIP 65, consente di definire dei lock assoluti, ovvero bloccare un output fino ad una certa data/ora futura o fino ad uno specifico numero di blocco. Oltre che nei casi che vedremo in questo articolo, un lock di questo tipo può essere utile ad esempio nel caso in cui un padre vuole donare dei bitcoin al proprio figlio ma desidera assicurarsi che li possa spendere solo dopo aver compiuto i 18 anni, oppure per effettuare un pagamento (ad esempio un affitto) in una data specifica nel futuro.

Il secondo tipo di lock, chiamato CheckSequenceVerify (in breve CSV), descritto nei BIP 68, 112 e 113, consente di definire un lock relativo; una volta che una transazione con output di tipo CSV è registrata sulla blockchain, deve essere generato un determinato numero di blocchi prima che tale output possa essere spendibile.

Sebbene i due meccanismi possano sembrare all'apparenza molto simili, vedremo nel seguito che nell'ambito di Lightning Network essi avranno due casi d'uso diversi.

Nell'esempio della seguente immagine, l'output della prima transazione è bloccato da un lock di tipo CSV con valore 1000. La seconda transazione non potrà dunque essere registrata sulla blockchain nei 1000 blocchi successivi al blocco in cui si trova la prima transazione.

Lock temporali

Apertura di un canale

Torniamo al caso precedente e rivediamo le operazioni compiute al fine di renderle resistenti a comportamenti fraudolenti. Per aprire il canale Anna e Bruno inviano rispettivamente 1 BTC e 0.5 BTC ad un indirizzo multifirma 2-di-2.

In più Anna e Bruno, generano ciascuno una preimage, e ne inviano l'hash alla controparte.

Cos'è una preimage?

Una preimage (o segreto) è una lunga sequenza di numeri generata in modo casuale, e praticamente impossibile da indovinare. Tramite un algoritmo di hash è possibile generare, a partire dalla preimage, una sequenza differente e più breve (256 bit) detta appunto hash. Chiunque conosce la preimage può facilmente calcolarne l'hash, ma non è possibile il viceversa, cioè, a partire dall'hash risalire alla preimage.

Bitcoin fa largo uso di algoritmi di hash, ad esempio nell'algoritmo di proof-of-work hashcash utilizzato per il mining dei blocchi si utilizza SHA256.

Nel nostro caso l'hash prodotto da una preimage serve a dimostrare che essa è stata generata e, successivamente, a verificare che la preimage ricevuta come controparte di uno scambio sia quella originaria. Inoltre, utilizzeremo una particolare tipologia di transazione, detta hashlocked, il cui output potrà essere sbloccato solo se si avrà a disposizione una determinata preimage.

Nelle immagini di questo articolo rappresenteremo una preimage tramite una chiave colorata cui è eventualmente associato un numero, mentre il corrispondente hash è rappresentato con un lucchetto dello stesso colore e con lo stesso numero. In particolare, nella seguente immagine, l'output della prima transazione è bloccato da un hashlock, rappresentato dal lucchetto blu. Per poter utilizzare tale output in una nuova transazione, Anna dovrà inserire in essa, oltre alla propria firma, anche la preimage (la chiave blu) corrispondente all'hashlock.

Preimage (o segreto)

A questo punto Anna genera immediatamente una transazione successiva a partire dalla transazione di apertura del canale. Questa transazione è detta transazione di impegno (commitment transaction). Tramite la transazione di impegno, Anna invia 1 BTC a se stessa e 0.5 BTC ad un secondo indirizzo multifirma. Questo output è un po' particolare poiché include un lock temporale di tipo CSV ed un hashlock. Può essere sbloccato solo da Bruno, ma solo dopo che 1000 blocchi sono stati minati successivamente alla scrittura di questa transazione sulla blockchain, ovvero circa 7 giorni dopo. Oppure può essere sbloccato da Anna, ma solo se essa include anche la preimage di Bruno. Naturalmente, in questo momento Anna possiede solo l'hash di tale preimage e non ha alcun modo di risalire alla sequenza originaria, per cui in questo momento questa seconda opzione non è praticabile. Fatto ciò, Anna firma la sua transazione di impegno e la invia a Bruno.

Nel frattempo Bruno fa la stessa cosa: crea una transazione di impegno, per cui invia 0.5 BTC a se stesso e 1 BTC ad un nuovo indirizzo multifirma. Anna può sbloccare questo indirizzo se attende ulteriori 1000 blocchi, oppure può sbloccarlo Bruno se include la preimage di Anna. Anche in questo caso Bruno firma la transazione e la invia ad Anna.

Dopo essersi scambiati queste transazioni di impegno (e l'hash delle rispettive preimage), entrambi firmano la transazione di apertura e la inviano in broadcast affinché possa essere registrata sulla blockchain. Ora il canale è ufficialmente aperto.

Transazioni di impegno

Transaction malleability e Segregated Witness

Il requisito che la transazione di impegno venga generata prima che Anna e Bruno firmino la corrispondente transazione di apertura del canale può esser causa di un problema rilevante. La transazione di impegno infatti deve fare riferimento all'identificativo (transaction id o TXID) della transazione di apertura, che non è altro che un hash dei dati della transazione stessa. Il problema deriva dal fatto che anche le firme sono utilizzate per il calcolo dell'hash della transazione. Dunque, una volta che la transazione di apertura viene firmata da Anna e Bruno, il suo hash (e quindi il suo identificativo) cambia e pertanto le transazioni di impegno generate precedentemente farebbero riferimento ad un identificativo della transazione di apertura non più valido. Questo è un caso particolare di un problema più generale noto come transaction malleability.

L'introduzione del meccanismo della Segregated Witness (o SegWit), definito nel BIP 141 e attivato sulla rete Bitcoin il 24 Agosto 2017, risolve questo problema. Con essa viene introdotta una nuova struttura dati chiamata witness (testimone), in cui vengono spostati i dati necessari a verificare la validità della transazione ma non a definirne gli effetti. In particolare, le firme e gli eventuali script di sblocco sono inseriti in questa nuova struttura. La witness è inserita in una parte separata del blocco, e non è utilizzata per il calcolo della transaction id, risolvendo così il problema della transaction malleability, e consentendo pertanto l'implementazione della Lightning Network descritta precedentemente.

Nota. L'introduzione della segregated witness ha portato anche altre migliorie a Bitcoin fra cui l'incremento della dimensione massima di un blocco al di là del precedente limite ad 1MB ed un aumento dell'efficienza, specialmente per i nodi di tipo Simplified Payment Verification (SPV). Torneremo prossimamente sulla segregated witness con un articolo di approfondimento.

Osserviamo che, a questo punto, sia Anna che Bruno potrebbero firmare e registrare sulla blockchain la transazione di impegno ricevuta dalla controparte. Se Anna registra la transazione ricevuta da Bruno, egli ottiene subito 0.5 BTC. Se lo fa Bruno, Anna ottiene immediatamente il proprio bitcoin. Tuttavia, chiunque firma e registra la transazione di impegno deve attendere 1000 blocchi per sbloccare l'indirizzo multifirma ed ottenere i propri bitcoin.

Possibili usi delle transazioni di impegno

Tuttavia, e questo è l'elemento chiave di un canale di pagamento, nessuno dei due firma e registra la transazione di impegno ricevuta dalla controparte.

Aggiornamento del canale

Ripercorriamo l'esempio visto prima e supponiamo ora che Anna voglia inviare un pagamento di 0.2 BTC a Bruno. Sarà sufficiente aggiornare lo stato del canale di pagamento in modo da assegnare 0.8 BTC ad Anna e 0.7 BTC a Bruno. Per fare questo, Anna e Bruno devono fare 2 cose.

Primo, devono generare una nuova transazione di impegno del tutto simile alla precedente. Questa volta Anna genera una transazione in cui invia 0.8 BTC a se stessa a 0.7 BTC ad un indirizzo multifirma e Bruno genera una transazione in cui invia 0.7 BTC a se stesso a 0.8 BTC ad un indirizzo multifirma. Le condizioni degli indirizzi multifirma sono le stesse di quelli descritti in precedenza, con l'unica eccezione che sono richieste due nuove preimage. Anna e Bruno pertanto generano entrambi una nuova preimage e ne forniscono alla controparte l'hash. Inoltre, entrambi firmano la nuova transazione di impegno generata e se la scambiano. Infine (e qui sta il trucco) Anna e Bruno si scambiano anche il preimage utilizzato nella transazione di impegno precedente.

Il canale è dunque stato aggiornato.

Ora, di nuovo, sia Anna che Bruno possono firmare e registrare sulla blockchain la nuova transazione d'impegno "semi-valida" che hanno appena ricevuto. In tal caso la controparte riceverebbe subito i suoi bitcoin, mentre egli dovrebbe attendere 1000 blocchi prima di sbloccare i propri.

Canale di pagamento bidirezionale

Ma a questo punto potremmo chiederci: cosa impedisce a Anna di registrare sulla blockchain la transazione precedente, quella cioè che le garantiva 1 BTC anziché 0.8 BTC?

Ciò che impedisce a Anna di fare questo è il fatto che ora Bruno ha a disposizione la prima preimage utilizzata da Anna.

Se Anna provasse a firmare e registrare la vecchia transazione sulla blockchain, oltre ad inviare subito 0.5 BTC a Bruno, dovrebbe attendere la produzione di 1000 blocchi (come detto circa 7 giorni) per ottenere il suo bitcoin dall'indirizzo multifirma. Ma a questo punto Bruno, accorgendosi che Anna ha provato a "frodare" pubblicando la vecchia transazione d'impegno, può a sua volta registrare una nuova transazione in cui utilizza la prima preimage di Anna per ottenere anche il bitcoin dell'indirizzo multifirma, prima che Anna possa utilizzarlo. Tale transazione è detta in gergo breach remedy transaction o revocation (nelle immagini indichiamo tali transazioni con il simbolo di uno scudo).

Se dunque Anna provasse a frodare la controparte rischierebbe di perdere tutto l'ammontare depositato nel canale. Naturalmente ciò è specularmente vero se viceversa Bruno provasse ad avere un comportamento non corretto; in tal caso sarebbe Anna in grado di ottenere tutti i bitcoin depositati nel canale avendo a disposizione la prima sequenza segreta generata da Bruno.

Con questa tecnica, Anna e Bruno sono dunque fortemente incentivati ad avere un comportamento corretto, firmando e registrando sulla blockchain solo la transazione di impegno più recente.

Nota. È opportuno fare ora una importante osservazione. Affinché Bruno possa prendere le contromisure in caso di un eventuale comportamento non corretto di Anna, egli deve intervenire prima che, trascorsi i 1000 blocchi, Anna possa reclamare l'importo presente sull'indirizzo multifirma. Per stare al sicuro da eventuali frodi nei suoi confronti, Bruno ha pertanto bisogno di accedere alla rete per verificare la blockchain con una certa frequenza, all'incirca almeno una volta a settimana per singolo canale aperto. Questo è un requisito che può essere in certi casi molto vincolante. In alternativa Bruno può porre la sua fiducia su una terza parte che, per conto suo, monitora la rete Bitcoin al fine di individuare ed eventualmente contrastare comportamenti non corretti da parte di tutte le controparti con cui egli ha un canale aperto. Tuttavia ciò va in un certo senso contro la filosofia di Bitcoin per cui tutto è progettato in modo tale che non sia necessario porre la propria fiducia su terze parti. Torneremo su questo più avanti.

Chiusura del canale

Tutto quanto descritto sino ad ora in genere non avrà mai bisogno di essere registrato sulla blockchain.
Se sia Anna che Bruno vogliono chiudere il canale in modo "amichevole" essi possono semplicemente creare una transazione a partire dalla transazione di apertura che raccolga tutto ciò che è avvenuto dall'apertura del canale sino ad ora. Attraverso questa transazione di chiusura, essi inviano a se stessi l'importo di bitcoin corrispondente al bilancio corretto ed aggiornato del canale, così come descritto nello stato condiviso più recente, ovvero nell'ultima transazione di impegno generata.

In concreto ciò significa che se Anna vuole chiudere il canale, può a questo punto semplicemente creare una nuova transazione che paga 0.8 BTC a se stessa e 0.7 BTC a Bruno e chiedere a Bruno di firmare e registrare questa transazione. Poiché non c'è motivo per cui Bruno non debba farlo, egli probabilmente coopererà e chiuderà il canale.

Alla fine solo 2 transazioni saranno registrate sulla blockchain: la transazione di apertura e quella di chiusura.

Transazione di chiusura

Concatenazione di canali di pagamento

Osserviamo ora che non è sempre necessario aprire un canale di pagamento diretto con la persona con cui vogliamo effettuare una transazione tramite Lightning Network. È possibile infatti concatenare canali già presenti, utilizzando altri utenti come nodi intermediari su cui possiamo "far passare" la nostra transazione.

Per esempio, ipotizziamo che Anna debba inviare dei bitcoin a Carlo, e che non esista un canale di pagamento aperto fra Anna e Carlo (i nodi client utilizzati da Anna e Carlo devono comunque essere in grado di comunicare fra loro tramite una connessione TCP).

Supponiamo però che Bruno, essendo un commerciante, abbia già un canale di pagamento aperto sia con Anna che con Carlo. In questo caso Anna può inviare a Carlo un pagamento per mezzo di Bruno, utilizzando quest'ultimo come intermediario. In questo modo Anna e Carlo evitano di dover aprire un nuovo canale con la associata commissione necessaria per inserire la transazione nella blockchain.

Bisogna però fare attenzione al fatto che, affinché Anna possa inviare a Carlo un determinato importo, Bruno deve avere tale importo disponibile nel canale di pagamento con Carlo. Anna infatti non può passare direttamente a Carlo l'importo dovuto, ma deve affidarsi al fatto che Bruno paghi per lei, e poi lei ripagherà Bruno.

Tuttavia Anna non si fida completamente delle controparti. Ha paura che se lei paga Bruno, egli poi non pagherà Carlo; oppure Bruno pagherà Carlo ma quest'ultimo potrebbe affermare di non aver mai ricevuto il pagamento (e Anna non saprebbe chi sta mentendo). Anna pertanto vuole assicurarsi di pagare Bruno se e solo se egli paga a Carlo il corrispondente importo dovuto.

In questo caso, ci può venire di nuovo in aiuto il meccanismo delle preimage, già visto in precedenza.

Supponiamo che Anna voglia inviare 0.5 BTC a Carlo. Chiede allora a Carlo di generare una preimage e di inviarle il relativo hash (fase 1 nell'immagine seguente). Inoltre chiede a Carlo di inviare tale preimage a Bruno solo dopo aver ricevuto da quest'ultimo l'importo pattuito, ovvero 0.5 BTC.

Implementazione naïve di una rete di pagamenti

Nel frattempo Anna prende l'hash ricevuto da Carlo, e si rivolge a Bruno offrendogli l'importo di 0.5 BTC se egli le fornisce la preimage di tale hash (fase 2 nell'immagine).

Pertanto Bruno si rivolge a Carlo e gli offre 0.5 BTC in cambio della preimage (fase 3).

Una volta ricevuta la sequenza Bruno invia ad Anna il valore ottenuto. Ricevuta la preimage, Anna ne calcola l'hash e lo confronta con quello inizialmente ricevuto da Carlo. Dal fatto che questi hash coincidono, Anna ne deduce che Carlo ha ricevuto il bitcoin da Bruno, e può allora pagare l'importo di 0.5 BTC a Bruno (fase 4).

La transazione è stata portata a termine e tutti sono felici.

Beh! Non proprio ....

Innanzitutto, in questo scenario Bruno non ha nulla da guadagnare nel prendere parte alla transazione. Questo problema si può risolvere facendo sì che Anna paghi a Bruno, in aggiunta al bitcoin che va a Carlo, una piccola commissione che Bruno può tenere per sé.

Tuttavia, e questo è il problema maggiore, questa soluzione richiede che Bruno abbia completa fiducia nelle controparti. Bruno deve aver fiducia in Carlo in quanto egli potrebbe non inviare a Bruno la preimage dopo aver ricevuto il pagamento. Bruno deve inoltre aver fiducia in Anna, perché ella potrebbe non inviare i bitcoin a Bruno dopo che quest'ultimo ha fornito la preimage ad Anna.

Anche in questo caso Lightning Network offre dei meccanismi che risolvono questo problema e consentono di effettuare in modo completamente trustless una transazione di questo tipo.

Prima di procedere dobbiamo analizzare il meccanismo di base necessario a realizzare quanto segue, ovvero i contratti hash time-locked.

Contratti Hash Time-Locked

Un contratto hash time-locked (o HTLC), introdotto e descritto nella BIP 199, è una transazione che ha come output uno script che prevede due possibili modalità di sblocco: una parte può utilizzare l'output fornendo, oltre alla propria firma, la preimage di origine di uno specifico hash; un'altra parte può invece sbloccare l'output al raggiungimento di una determinata scadenza temporale di tipo CLTV.

Le due parti sono anche chiamate rispettivamente seller (venditore) e buyer (acquirente) poiché il caso d'uso più comune dei contratti HTLC è quello in cui le due parti si scambiano un valore (associato alla preimage) in cambio di uno specifico importo. L'acquirente invia un determinato importo ad un contratto HTLC. Se il venditore vuole utilizzare tale importo deve necessariamente rivelare la preimage. Se entro la scadenza prestabilita il venditore non rivela la propria preimage, l'acquirente può riavere automaticamente indietro l'importo depositato sul contratto HTLC.

Oltre che per Lightning Network, i contratti HTLC sono importanti anche perché consentono di effettuare atomic swap, ovvero scambi di una criptovaluta con un’altra criptovaluta, senza la necessità di utilizzare un exchange come terza parte.

Contratto Hash Time-Locked

Anna e Bruno decidono allora di scambiarsi 0.5 BTC per mezzo di un contratto Hash Time-Locked (per semplificare ignoriamo una eventuale piccola commissione che Anna potrebbe dover pagare a Bruno affinché faccia da intermediario).

Per far ciò, anziché inviare l'importo direttamente a Bruno, Anna invia l'importo ad un nuovo indirizzo multifirma, il cui output può essere sbloccato in due modi differenti: Bruno può sbloccare l'importo utilizzando la sua firma e la preimage di Carlo; Anna può semplicemente utilizzare la sua firma, ma deve attendere un lock di tipo CLTV, fissato ad esempio a 2 settimane. In questo modo, lo scambio è garantito. Bruno può ottenere i 0.5 bitcoin di Anna solo se fornisce la preimage di Carlo inviando la relativa transazione in broadcast sulla rete, e rendendolo con ciò pubblicamente visibile ad Anna. Se viceversa Bruno non fornisce la preimage nel tempo stabilito, Anna ha la possibilità di riottenere indietro i propri bitcoin.

Ritornando alla rete esaminata in precedenza, successivamente all'apertura del contratto HTLC con Anna, Bruno stabilisce un contratto di tipo HTLC anche con Carlo; quest'ultimo, per ottenere i 0.5 bitcoin pagati da Bruno, dovrà rivelare a Bruno la propria preimage rendendola visibile sulla blockchain. Pertanto Bruno ha la garanzia di ottenere i bitcoin da Anna, prendendo la preimage di Carlo, includendola nella propria transazione HTLC con Anna, ed ottenendo in cambio i bitcoin. I due canali sono stati effettivamente collegati.

Concatenazione di contratti HTLC

È opportuno osservare che affinché tutto funzioni nel modo corretto, è necessario che Bruno ottenga la sequenza di Carlo prima che Anna possa ottenere indietro i bitcoin che aveva inviato a Bruno. Se Bruno dovesse ottenere la sequenza di Carlo solo dopo che Anna ha riottenuto indietro i suoi 0.5 bitcoin, egli ci rimetterebbe 0.5 bitcoin. Per evitare che ciò accada, la scadenza del lock temporale nella transazione HTLC fra Bruno e Carlo deve scadere prima della scadenza del corrispondente lock nella transazione fra Anna e Bruno; ad esempio 10 giorni anziché 2 settimane.

Concatenazione di canali di pagamento su Lightning Network

C'è ora un ultimo problema da risolvere: affinché possa essere utilizzato in Lightning Network tutto il meccanismo ora descritto deve poter funzionare off-chain, ovvero senza dover andare a scrivere le transazioni sulla blockchain.

Come nel caso precedente, Anna e Bruno iniziano creando ciascuno una nuova transazione di impegno. Questa transazione è molto simile a quella vista precedentemente, ma definisce 3 output anziché 2:

  • un output normale (verso la controparte),
  • un output verso un indirizzo multifirma con un lock di tipo CSV ed un lock di tipo hash associato ad una nuova preimage generata da Anna/Bruno,
  • un terzo output con importo pari ai bitcoin da trasferire nella transazione (nel nostro esempio 0.5 BTC); questo output è sostanzialmente l'HTLC, e può essere sbloccato in 3 modi diversi.

Canali di pagamento bidirezionali tramite HTLC

Il nuovo output, presente sia nella transazione di impegno di Anna sia in quella di Bruno, rende disponibili 0.5 bitcoin sbloccabili con la firma di Bruno e la preimage di Carlo. Pertanto, indipendentemente da chi tra Anna e Bruno firmi e registri sulla blockchain la transazione di impegno, solo Bruno può ottenere quell'importo, se include la preimage di Carlo. Ma c'è una piccola differenza nelle due transazioni di impegno generate. Mentre se Anna registra sulla blockchain la transazione ricevuta da Bruno, Bruno può utilizzare immediatamente tale output, se viceversa è Bruno a registrare la transazione generata da Anna, l'output è bloccato da un lock di tipo CSV; pertanto Bruno per utilizzare l'output dovrà attendere 1000 blocchi.

La ragione per cui Bruno deve attendere 1000 blocchi nel caso in cui sia lui a registrare la transazione e chiudere il canale è molto simile a quella che abbiamo visto precedentemente, ovvero consentire ad Anna di prendere questi bitcoin nel caso in cui Bruno provi a registrare sulla blockchain una transazione di chiusura con un bilancio non aggiornato. Ecco dove entra in gioco il secondo meccanismo di sblocco dell'output. Anna può "confiscare" il bitcoin se fornisce la nuova preimage di Bruno.

Se Anna provasse ad imbrogliare e a registrare una vecchia transazione di impegno, Bruno può ottenere il bitcoin in output utilizzando la preimage di Anna.

Infine, così come ogni altra transazione di tipo HTLC, entrambe le transazioni di impegno includono il solito meccanismo di scadenza di tipo CLTV a vantaggio di Anna. Se Bruno non include la preimage entro ad esempio 2 settimane (poiché non l'ha avuto da Carlo), Anna può ottenere indietro i suoi bitcoin. Di nuovo, per questo terzo caso non importa se sia Anna o Bruno a registrare la transazione di chiusura sulla Blockchain.

A questo punto sia Anna che Bruno hanno a disposizione una transazione di impegno semi-validata (manca la loro firma). Se Anna chiude il canale registrando sulla blockchain la transazione di impegno a sua disposizione, invia immediatamente 0.7 BTC a Bruno; inoltre può attendere 1000 blocchi ed ottenere per sé 0.3 BTC. In più Bruno ha 2 settimane di tempo per fornire la preimage di Carlo ed ottenere 0.5 BTC nell'output con il vincolo di tipo HTLC; se Bruno non riesce a fornire la preimage entro le 2 settimane, tale output può essere utilizzato da Anna.

Inoltre, se Anna o Bruno in futuro tentassero di imbrogliare inviando questa transazione dopo che è diventata non utilizzabile poiché ne è stata generata una nuova, la controparte può comunque intervenire ed ottenere tutti i Bitcoin presenti nel canale utilizzando la preimage numero 3 della controparte in una transazione di breach remedy.

A questo punto Bruno ha la garanzia di ricevere 0.5 BTC in cambio della preimage di Carlo (assumendo che la abbia). Tutto ciò che deve fare è firmare e registrare sulla blockchain la transazione di impegno ricevuta da Anna, includere la preimage in una transazione successiva e poi firmare e registrare anch'essa sulla blockchain. Si noti che non c'è modo in cui Anna possa imbrogliare e rubare a Bruno tale importo, anche se, per caso, venisse a conoscenza in altri modi della preimage generata da Carlo.

Potremmo allora chiederci: ma è necessario chiudere il canale per portare a termine l'operazione?

La risposta è no: non è necessario chiudere il canale registrando sulla blockchain la transazione di chiusura. Le due parti infatti possono regolare la transazione fuori dal canale. Bruno può infatti inviare ad Anna la sequenza segreta ed accordarsi con lei nell'aggiornare lo stato del canale, creando una nuova transazione di impegno in formato standard, ovvero con 2 output e senza l'output di tipo HTLC e la relativa scadenza.

Si avrebbe pertanto la situazione descritta nell'immagine seguente.

Canale di pagamento bidirezionale

Instradamento di pagamenti sul Lightning Network

Quanto visto nel paragrafo precedente riguardo la concatenazione fra 2 canali, può essere esteso ad n canali: tramite Lightning Network è possibile effettuare un pagamento fra due qualsiasi entità purché esista fra loro una sequenza di canali di pagamento aperti.

Nell'immagine seguente, ad esempio, Anna può effettuare un pagamento ad Elena utilizzando i canali aperti fra Anna e Bruno, quello fra Bruno e Carlo, quello fra Carlo e Daniela, ed infine il canale fra Daniela ed Elena.

Instradamento su più canali

Naturalmente, l'entità massima del pagamento è uguale al minimo tra gli importi disponibili su tutti i canali utilizzati dal cammino, nel verso del pagamento. Ad esempio, nell'immagine precedente, Anna può effettuare un pagamento ad Elena utilizzando il cammino rappresentato, ma l'importo di tale pagamento può essere al massimo pari a 0.8 BTC poiché questo è l'ammontare massimo pagabile da Carlo a Daniela.

Vi sono però due problemi rilevanti da risolvere.

Primo, ogni volta che un nodo desidera inviare un pagamento ad un altro nodo, esso (o meglio, l'implementazione Lightning Network da esso utilizzata) deve prima essere in grado di costruire un percorso sulla rete connettendo canali di pagamento che abbiano capacità sufficiente, possibilmente scegliendo il percorso migliore rispetto ad una determinata metrica (ad esempio le commissioni totali pagate). Per far ciò, ogni nodo dovrebbe essere a conoscenza dell'intera topologia della rete, ovvero di tutti i canali di pagamento aperti e delle loro caratteristiche (commissioni, importi disponibili, configurazioni dei lock, etc.). Oltre a porre evidenti problemi di occupazione di memoria (è stato calcolato che la memorizzazione di tutte queste informazioni in una rete da 1 milione di nodi richiederebbe circa 120MB), il problema è reso ancor più complesso dal fatto che la rete cambia in continuazione, sia perché alcuni nodi possono disconnettersi dalla rete (chiusura del canale), sia perché gli importi disponibili sul canale possono cambiare con elevata frequenza (lo stesso articolo ha calcolato che l'aggiornamento di tali informazioni dinamiche, sempre in una rete da un milione di nodi, richiederebbe un trasferimento di oltre 120GB al giorno).

Secondo, il fatto di far transitare un pagamento attraverso diversi attori pone un significativo problema di privacy: senza opportune contromisure, nell'esempio precedente, Bruno, Carlo e Daniela verrebbero a conoscenza del fatto che Anna ha effettuato un pagamento verso Elena di una determinata entità. È chiaro come questo potrebbe favorire meccanismi di sorveglianza o, peggio ancora, censura.

Per quanto riguarda il primo problema, l'idea di base è che tutti i nodi inviano agli altri nodi le informazioni necessarie all'instradamento, fra cui: quali canali hanno aperti, qual è la loro capacità e quali commissioni applicano per instradare dei pagamenti su questi canali. Esistono diversi modi con cui queste informazioni possono essere condivise e, con lo sviluppo di questa tecnologia, stanno emergendo diversi approcci. Le prime implementazioni di Lightning Network utilizzavano il protocollo IRC (quello delle chat che andavano di moda negli anni '90) come meccanismo per annunciare agli altri nodi le informazioni di instradamento. Altre implementazioni utilizzano un modello peer-to-peer, in cui i nodi propagano in modalità flooding gli annunci dei canali ai loro peer, in modo simile al meccanismo con cui la rete Bitcoin propaga le nuove transazioni da inserire nella blockchain.

Un altro protocollo, chiamato Flare è stato sviluppato da BitFury ed incluso nell'implementazione di Lightning Network prodotta da ACINQ. L'obiettivo di questo algoritmo è quello di assicurare di trovare i percorsi nel modo più rapido possibile, minimizzando al tempo stesso la quantità di dati memorizzata su ciascun nodo. Ciò viene ottenuto facendo sì che ciascun nodo raccolga in modo proattivo le informazioni sulla topologia della rete Lightning Network. Le informazioni raccolte riguardano canali che si trovano a breve distanza dal nodo stesso (informazioni locali) e percorsi verso nodi più distanti scelti a caso (chiamati nodi beacon). L'esistenza di canali di pagamento viene verificata utilizzando le informazioni presenti sulla blockchain e le informazioni fornite dai nodi con cui è aperto un canale di pagamento diretto. Come risultato, un nodo avrà una mappa ben definita del suo "vicinato" nella rete, con in più dei pezzi di visibilità su nodi lontani, abilitata dalla selezione dei nodi beacon. La combinazione di nodi vicini e nodi lontani (beacon) consente di trovare con una elevata probabilità un percorso verso un qualsiasi altro nodo, minimizzando al tempo stesso la quantità di informazioni che un nodo deve mantenere per l'instradamento.

Nel nostro esempio precedente, il nodo di Anna utilizzerà uno di questi meccanismi di route discovery per individuare uno o più percorsi di collegamento con il nodo di Elena. Una volta che il nodo di Anna ha definito il percorso, ella inizializzerà tale percorso attraverso la rete, propagando una serie di istruzioni per connettere ciascuno dei canali di pagamento utilizzati.

Per risolvere la seconda criticità relativa alla privacy, il percorso completo deve essere noto solo ad Anna. Tutti gli altri partecipanti al percorso di pagamento dovranno avere visibilità solo sui nodi adiacenti (cioè il nodo con cui è aperto un canale attraverso il quale deve essere instradato il pagamento). Ad esempio, dal punto di vista di Carlo, questo deve risultare come un pagamento fra Bruno e Daniela. Carlo non deve sapere che Bruno in realtà sta inoltrando un pagamento da parte di Anna, né che Daniela inoltrerà il pagamento ad Elena.

Ma in che modo Anna può stabilire questo percorso di pagamento senza rivelare nulla ai nodi intermediari?

Lightning Network implementa un protocollo di onion routing, del tutto simile a quello utilizzato dalla rete Tor, basato su uno schema chiamato Sphinx. Questo protocollo assicura che colui che effettua un pagamento su Lightning Network può costruire un percorso tale che i nodi intermedi possano verificare e decifrare la loro porzione di percorso e possano trovare il nodo successivo ma, oltre che il nodo precedente ed il nodo successivo, essi non posso venire a conoscenza di alcun altro nodo che fa parte del percorso; inoltre, essi non possono individuare la lunghezza totale del percorso di pagamento o la loro posizione all'interno di tale percorso. Ciascuna parte del percorso è cifrata in modo tale che un eventuale attaccante che opera a livello di rete non può associare fra loro i pacchetti da parti diverse del percorso e, al contrario di Tor, non vi sono nodi di uscita che possono essere messi sotto sorveglianza.

Utilizzando questo protocollo, Anna impacchetta in un livello di cifratura ciascun elemento del percorso, iniziando dall'ultimo nodo (il destinatario del pagamento) e procedendo a ritroso. Inizia dunque cifrando il messaggio di Elena con la chiave pubblica di Elena. Questo messaggio è imbustato in un messaggio cifrato per Daniela, in cui viene indicata Elena come destinatario del messaggio successivo. Il messaggio per Daniela è imbustato in un messaggio cifrato con la chiave pubblica di Carlo (e destinato a quest'ultimo) in cui viene indicata Daniela come prossimo destinatario. Il messaggio per Carlo viene dunque cifrato con la chiave pubblica di Bruno.

In questo modo Anna ha costruito una serie di strati di messaggi cifrati. Ella invia questo messaggio a Bruno, il quale può solo decifrare lo strato più esterno. Al suo interno Bruno trova un messaggio destinato a Carlo che può inoltrare a Carlo ma che non può decifrare egli stesso.

Andando avanti così, il messaggio viene inoltrato, poi decifrato, poi di nuovo inoltrato e così via fino a raggiungere Elena. Ciascun partecipante è a conoscenza solo del nodo precedente e del nodo successivo del cammino.

Come abbiamo visto in precedenza, ciascun elemento del cammino contiene informazioni sul contratto HTLC che devono essere estese al nodo successivo, l'ammontare che deve essere inviato, le commissioni da includere e le informazioni sul lock CLTV che definiscono la scadenza del contratto HTLC. Al propagarsi delle informazioni lungo il percorso, i nodi si impegnano in contratti HTLC verso il nodo successivo.

A questo punto potremmo chiederci: come è possibile che un nodo non riesca ad individuare la lunghezza del cammino e la sua posizione all'interno dello stesso? In fin dei conti, esso riceve un messaggio e ne inoltra il contenuto al nodo successivo, per cui man mano che ci si avvicina alla destinazione il messaggio diventa sempre più piccolo. Per risolvere questo problema, l'implementazione fa in modo tale che la lunghezza del percorso sia sempre fissata a 20 nodi e, se necessario, riempita con dati casuali. Ciascun nodo vede il nodo successivo ed un messaggio cifrato da inoltrare di lunghezza fissa. Solo il nodo finale è in grado di vedere che non esiste un nodo successivo. Per qualsiasi altro nodo del cammino è come se mancassero sempre 20 nodi per raggiungere il nodo finale di destinazione del pagamento.

Chiudiamo con una osservazione.

La bontà o meno di un algoritmo di instradamento dipende fortemente dalle caratteristiche della rete su cui opera; ciò ovviamente non può essere stabilito a priori ma sarà un risultato che emergerà man mano che la rete Lightning Network verrà utilizzata dagli utenti.

Possiamo però provare a fare una previsione.

La commissione totale pagata agli intermediari dipenderà in genere dal numero di canali utilizzati e dunque dalla lunghezza del cammino, così come il tempo necessario a portare a termine la transazione e, da non sottovalutare, il rischio che la transazione si blocchi a causa del crash di un nodo o, peggio, di un nodo non cooperante. Si tenderanno dunque a preferire, laddove possibile, cammini brevi rispetto a cammini più lunghi.

Poiché come abbiamo visto esiste un costo associato all'apertura di un canale, nonché la necessità di tenere una quantità di bitcoin "bloccata" nel canale stesso, è probabile che la maggior parte delle transazioni passeranno per coloro che saranno in grado di aprire un gran numero di canali, ovvero le grandi società o individui con una gran quantità di bitcoin a disposizione.

Da ciò possiamo dedurre che in un futuro assai plausibile, se Lightning Network dovesse divenire popolare, società come ad esempio Coinbase potrebbero emergere come "hub" di pagamento, mettendo a disposizione canali diretti di pagamento aperti con tutti i propri utenti. Verosimilmente questi hub saranno tutti interconnessi fra loro tramite canali di pagamento costantemente aperti.

Una siffatta tipologia di rete, già nota soprattutto in ambito aviazione, prende il nome di Hub and Spoke.

In tal caso le forme più comuni di cammino generate per effettuare un pagamento Lightning Network fra da due utenti qualsiasi, che non hanno un canale di pagamento aperto diretto fra loro, saranno:

  • utente 1 - hub - utente 2 : nel caso in cui i due utenti abbiano canali aperti con uno stesso hub;
  • utente 1 - hub 1 - hub 2 - utente 2: nel caso in cui i due utenti abbiano canali aperti con 2 hub diversi.

Conclusioni

Abbiamo presentato in questo articolo Lightning Network e ne abbiamo visto il principio di funzionamento. Questa tecnologia consente di effettuare transazioni off-chain mantenendo allo stesso tempo la caratteristica di operare in modo trustless, ovvero senza che le due parti debbano avere fiducia reciproca e senza dover far uso di una terza parte che faccia da garante.

L'implementazione e l'uso di Lightning Network porterà notevoli benefici a Bitcoin, fra cui:

  • Aumento della capacità della rete: l'uso di Lightning Network potrà incrementare la capacità della rete Bitcoin di diversi ordini di grandezza; il fatto di non dover registrare tutte le transazioni sulla blockchain rimuove un limite superiore al numero di pagamenti al secondo che possono essere effettuati sulla rete, poiché ciò dipenderà esclusivamente dalla capacità e dalla velocità di ciascun nodo.

  • Maggiore velocità nei pagamenti: le transazioni effettuate tramite Lightning Network potranno essere verificate nel giro di pochissimi secondi (il tempo di generare, condividere ed infine aggiornare una transazione HTLC); non sarà necessario attendere minuti per la produzione di un blocco nella blockchain, e la sua eventuale conferma tramite la concatenazione di blocchi successivi.

  • Possibilità di effettuare micropagamenti: i micropagamenti saranno resi possibili dal fatto che le commissioni sono nulle (nel caso in cui esiste un canale di pagamento diretto) o comunque molto più basse rispetto a quelle richieste dai miner per l'inserimento di una transazione in un blocco della blockchain (di norma la commissione richiesta può essere una piccola percentuale dell'importo pagato).

  • Aumento della privacy: i pagamenti effettuati tramite Lightning Network sono molto più privati rispetto a quelli registrati pubblicamente sulla blockchain; anche nel caso di pagamenti instradati, i partecipanti possono vedere i pagamenti propagati attraverso i loro canali, ma non sono a conoscenza né del mittente, né del destinatario del pagamento.

  • Aumento della fungibilità: l'uso di Lightning Network rende molto più difficile l'applicazione di metodi di sorveglianza o censura sulla rete bitcoin, incrementandone così la fungibilità.

A fronte di questi vantaggi vi sono però delle criticità da risolvere o di cui tener conto:

  • Impossibilità di effettuare pagamenti off-line: poiché, come abbiamo visto, il pagamento tramite Lightning Network richiede che le due parti generino e si scambino fra loro transazioni di impegno, entrambe le parti devono essere online durante il pagamento; inoltre abbiamo visto che la verifica di un eventuale comportamento fraudolento della controparte richiede un continuo monitoraggio della blockchain (o una eventuale delega ad un servizio esterno).

  • Sconsigliato per pagamenti di importo consistente: l'esecuzione di un pagamento richiede che le parti abbiano "caricato" il canale con un ammontare sufficiente alla transazione; inoltre in caso di instradamento è richiesto che tutti i canali che compongono il cammino abbiano disponibile l'importo del pagamento. Osserviamo infine che anche da un punto di vista economico può non essere conveniente instradare un pagamento di importo consistente tramite Lightning Network: mentre la commissione applicata dai miner per l'inserimento di una transazione nel blocco dipende solo dalla dimensione (in byte) della transazione e non dall'importo trasferito nella stessa, di norma le commissioni su Lightning Network sono calcolate su un importo fisso più una percentuale dell'importo trasferito. In conseguenza di ciò, la prima versione delle specifiche di Lightning Network imponeva un limite massimo di 0.04294967296 BTC per ciascun pagamento e di 0.17179869184 (4 volte tanto) per l'importo depositato su un canale.

  • Inconvenienti in caso di indisponibilità di un nodo: se la controparte va offline o va in crash, o se questo succede ad un nodo intermedio nel caso di un pagamento instradato, potrebbe essere necessario attendere ore o anche giorni per riavere l'importo a disposizione.

  • Ottimizzazione degli algoritmi di instradamento: abbiamo visto come il problema di mantenere ed aggiornare in modo efficiente le informazioni sui canali aperti, necessario ai fini dell'instradamento di un pagamento rimane ancora un problema aperto e che potrà porre nuove sfide al crescere delle dimensioni della rete man mano che prenderà piede l'uso di Lightning Network fra gli utenti.

  • Rischio di centralizzazione: poiché l'apertura (e la relativa chiusura) di un canale Lightning richiede la scrittura di una coppia di transazioni sulla blockchain ed il deposito di una somma nel canale stesso, è assai improbabile che una persona qualsiasi abbia l'interesse e la capacità di tenere aperti molti canali di pagamento; è probabile invece che alla lunga nascano dei grandi hub Lightning centralizzati, con un elevato numero di canali aperti e che offrono servizi di routing in cambio di una piccola commissione. Sebbene questa configurazione di rete possa semplificare l'instradamento dei pagamenti, in un protocollo come Bitcoin che fa della decentralizzazione il suo punto di forza, la centralizzazione non è mai un bene ed è bene fare attenzione ai rischi che ne potrebbero conseguire.

L'infrastruttura necessaria alla Lightning Network è già stata implementata sulla mainnet di Bitcoin. Diverse società sono da tempo al lavoro per la realizzazione di client Lightning Network funzionanti. Tuttavia, la necessità di garantire la massima sicurezza ed al tempo stesso la necessità di nascondere all'utente finale la complessità di questa tecnologia e fornire una esperienza d'uso quanto più semplice possibile, fanno sì che tali implementazioni stiano richiedendo un tempo di sviluppo considerevolmente maggiore rispetto a quello inizialmente stimato.

Nel prossimo articolo della serie vedremo a che punto siamo arrivati con le implementazioni di Lightning Network, quali sono i problemi che rimangono ancora da risolvere e quando, ragionevolmente, potremmo cominciare ad utilizzare questa tecnologia nei nostri pagamenti Bitcoin.

Per approfondire

Sito ufficiale di Lightning Network

Paper originali

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments di Joseph Poon, Thaddeus Dryja - Gennaio 2016.
Contiene la descrizione dell'idea originale di Lightning Network. Pubblicato nel 2015 e successivamente aggiornato fino a Gennaio 2016. Si noti che nel frattempo il protocollo è cambiato e la descrizione presente nel paper non è esattamente uguale a quella fornita in questo articolo.

Reaching the Ground with Lightning di Rusty Russell - Novembre 2015.
Rusty Russell propone alcune migliorie al protocollo originale di Poon e Dryja.

Flare - An approach to routing in Lightning Network di P. Prihodko, S. Zhigulin, M. Sahno, A. Ostrovskiy, O. Osuntokun - Luglio 2016.
Viene descritto il protocollo Flare per l'instradamento dei pagamenti su Lightning Network.

Sphinx: A Compact and Provably Secure Mix Format di George Danezis, Ian Goldberg - 2009.
Descrizione di Sphinx.

Using Sphinx to Improve Onion Routing Circuit Construction di Aniket Kate and Ian Goldberg - 2010.
Descrive il modo in cui Sphinx può essere utilizzato per migliorare le prestazioni del protocollo di Onion Rounting.

Descrizioni e tutorial

What is the Lightning Network and how can it help Bitcoin scale? di Elizabeth Stark - Settembre 2016.
Breve articolo che spiega in modo semplice cos'è Lightning Network.

Bitcoin Magazine - Understanding the Lightning Network - di Aaron van Wirdum ( Parte 1, Parte 2, Parte 3 ) - Maggio, Giugno 2016.
Serie di articoli in cui viene spiegato in dettaglio il funzionamento di Lightning Network.

Lightning Networks - Technical Explainer di Rusty Russell ( Parte 1 - Revocable Transactions, Parte 2 - Hashed Timelock Contracts (HTLCs), Parte 3 - Channeling Contracts, Parte 4 - Summary ) - Marzo, Aprile 2015.
Serie di articoli in cui Rusty Russell spiega alcuni punti chiave della tecnologia che sta dietro a Lightning Network.

#bitcoin-lightning: Things to Know di Rusty Russell - Dicembre 2016.
Breve serie di FAQ su Lightning Network.

Bitcoin’s Lightning Network Will Likely Fail Due To Several Possible Reasons di Curt0 - Dicembre 2017.
Per concludere, un punto di vista diametralmente opposto: un elenco di motivi per cui Lightning Network, secondo l'autore, è destinato a fallire. Uno su tutti, l'ipotesi che i nodi che svolgono il ruolo di intermediari debbano ottenere una licenza di money transmitter.

Video

I video sono ordinati temporalmente per data di pubblicazione.

Lightning Network Tech Talk at Coinbase (58:11) con Joseph Poon e Thaddeus Dryja- 29 Gennaio 2016.
Joseph Poon e Thaddeus Dryja spiegano come funziona Lightning Network, descrivendo in dettaglio i canali di pagamento bidirezionali ed i pagamenti instradati su più canali.

Lightning Network as a Directed Graph: Single-Funded Channel Network Topology (54:53) con Thaddeus Dryka - Aprile 2016.

Lightning Network Deep Dive (48:10) con Laolu "Roasbeef" Osuntokun - Agosto 2016.

Onion Routing in Lightning con Laolu Osuntokun - Ottobre 2016.
Onion Routing come tecnica per mantenere la privacy su Lightning Network. Qui la trascrizione del video.

Outsourced Channel Monitoring con Thaddeus Dryja - Ottobre 2016.
Come e perché delegare a terzi semi-fidati il monitoraggio di un canale. Qui la trascrizione del video. Qui le slide.

The Blockchain and Us: Interview Elizabeth Stark, Lightning Network (6:52) con Elizabeth Stark - Marzo 2017.
Episodio della serie di video podcast "The Blockchain and Us" in cui Elizabeth Stark spiega Lightning Network e le sue implicazioni.

Autore
Fabiano Sarracco
Ingegnere informatico, sviluppatore software freelance. Alcuni anni fa ha deciso di approfondire lo studio delle tecnologie alla base delle criptovalute e di applicazioni della blockchain; da allora si occupa anche di divulgazione e formazione in questo ambito.

Ti è piaciuto questo articolo? Condividilo!

Commenti