Lightning Network viene definito da molti come il protocollo che rilancerà bitcoin e che lo renderà fruibile come mezzo di pagamento destinato alla massa. Bitcoin, infatti, ad oggi ha diversi problemi dovuti alle capacità limitate della propria blockchain che lo rendono inadatto ad un potenziale uso di massa per i micro-pagamenti.
In primis vi è il grande problema della scalabilità e del numero di transazioni, fisso a circa 7 transazioni per secondo. In secondo luogo vi è il problema delle fee. Infatti, durante periodi di gran congestione, come accaduto lo scorso dicembre 2017, le fee da pagare ai miner per la conferma aumentano significativamente.
Nel dicembre 2017 per pagare un caffè in bitcoin era necessario sborsare una ventina di euro di spese di commissioni, risultando dunque un sistema di pagamento decisamente inutilizzabile.
Proprio per questo motivo, nel corso degli anni è stato sviluppato un layer aggiuntivo da affiancare alla blockchain di bitcoin, così da aumentarne scalabilità, usabilità, velocità e diminuirne le spese di commissione. Questo layer è proprio Lightning Network.
Caratteristiche dei canali e della rete Lightning Network
Per risolvere i problemi citati, Lightning Network prevede l’esecuzione di alcune transazioni off-chain, dunque non trasmesse nella blockchain di bitcoin. Il concetto sfrutta la creazione di un canale – evoluzione del Payment Channel – tra i due membri della transazione che effettuano scambi di denaro.
In sostanza, dunque, le transazioni eseguite sul canale dedicato avvengono istantaneamente senza alcuna trasmissione alla blockchain. Ad essa, infatti, verrà trasmessa solamente la transazione di apertura e di chiusura.
Tramite l’utilizzo di questi canali è anche possibile creare una particolare tipologia di smart contract tra i due membri del canale. Oltre a tutti questi vantaggi, con Lightning Network si ha la teorica eliminazione delle fee.
Transazioni non confermate
Il protocollo Bitcoin è costituito essenzialmente da transazioni legate a transazioni precedenti e future. Ogni transazione contiene degli ingressi, che si riferiscono agli indirizzi da cui vengono inviati i bitcoin, e le uscite, che si riferiscono agli indirizzi a cui vengono inviati. Inoltre, gli input devono includere i requisiti per inviare i bitcoin, ovvero le firme che dimostrano la proprietà degli indirizzi di input. Gli output, nel frattempo, stabiliscono i nuovi requisiti, che devono essere inclusi nell’input di una transazione successiva.
Una delle caratteristiche principali di Lightning Network consiste nel fatto che è costituita da transazioni bitcoin più o meno regolari. Queste transazioni di solito non vengono trasmesse attraverso la rete bitcoin. Infatti, esse vengono memorizzate localmente nei nodi degli utenti, ma possono poi essere trasmessi in qualsiasi momento attraverso la rete.
Nell’esempio in figura, si vede come Alice possa firmare ed effettuare il broadcast delle transazioni non confermate, così da inviare due bitcoin a Bob. Ma è solamente dopo che Alice avrà effettuato il broadcasting che Bob potrà mandare uno dei due bitcoin ricevuti da Alice a Carol.
Protezione dal double spending
Anche Lightning Network integra un meccanismo di protezione dal double-spending, ovvero il tentativo di spendere più volte il proprio denaro. Infatti, se due transazioni si basano sullo stesso output, solo una può essere confermata.
Le transazioni non confermate possono essere in conflitto, il che significa che solo una può essere confermata, evitando quindi il cosiddetto double-spending.
Nell’esempio in figura, Alice deve decidere quale transazione firmare e trasmettere. Non potrà infatti firmarle entrambe, in quanto, in caso accadesse, solo una delle due verrebbe effettivamente confermata.
Multi signature
Il terzo elemento base della rete Lightning Network è costituito dagli indirizzi multi-signature (multifirma), detti anche indirizzi P2SH.
Gli indirizzi multisig sono indirizzi Bitcoin che – come suggerisce il nome – richiedono più chiavi private per sbloccare e spendere bitcoin. Possono essere impostati in qualsiasi configurazione.
La rete Lightning Network utilizza spesso configurazioni multisig due su due (2-of-2). Lo sblocco di bitcoin provenienti da indirizzi multisig 2-of-2 quindi richiede due firme, da due chiavi dedicate.
Nell’esempio in figura, Alice e Bob hanno creato un indirizzo multisig 2-2 di cui detengono entrambi una chiave. Quando Alice proverà a spendere i bitcoin provenienti da tale indirizzo, non ci riuscirà perché anche Bob dovrà firmare la transazione. Va quindi fatto notare che una volta firmata una transazione, non è più possibile cambiarne il contenuto, in quanto essa è marchiata da una funzione crittografica immutabile.
Blocchi temporali
I blocchi temporali possono bloccare i bitcoin in arrivo o in un’uscita, così da renderli spendibili solo in un certo momento futuro.
Esistono due diversi tipi di blocchi temporali: quello assoluto, chiamato CheckLockTimeVerify (CLTV), e quello relativo, definito CheckSequenceVerify (CSV). CLTV blocca i bitcoin fino a un tempo definito: ora e data effettive, oppure un numero specifico dei blocchi. CSV, invece, utilizza il tempo relativo. Una volta che un’uscita CVS viene registrata sulla blockchain, da quel momento in poi dovrà essere generata una quantità specifica di blocchi prima che i bitcoin possano essere nuovamente spesi.
Nell’esempio in figura, viene applicato il CSV. Alice dovrà aspettare la generazione di mille blocchi prima di poter ottenere i due bitcoin e mandarli a Bob.
Hash e segreti
L’ultima parte relativa ai canali riguarda la crittografia, parte fondamentale di tutte le criptovalute. Tuttavia, nella rete Lightning Network essa è applicata in maniera leggermente differente.
Una funzione crittografica è un algoritmo matematico che mappa dei dati di lunghezza arbitraria (messaggio) in una stringa di dimensione fissa chiamata hash o digest. Tale funzione di hash è progettata per essere unidirezionale, ovvero una funzione difficile da invertire: l’unico modo per ricreare i dati di input dall’output di una funzione di hash ideale è quello di tentare un attacco brute-force dei possibili input per vedere se vi è corrispondenza.
La crittografia in Lightning Network può essere utilizzata per bloccare i bitcoin. Ad esempio, un hash può essere incluso in un’uscita così che l’input successivo risulti spendibile solamente se include la chiave segreta (che d’ora in poi verrà chiamata segreto) relativa per l’effettiva verifica.
Creazione dei canali di pagamento bidirezionali
Il concetto dei canali di pagamento era già da tempo in uso grazie al sistema Payment Channel. I classici canali di pagamento sono utili per determinati scopi, ma anche limitati, in quanto unidirezionali. Sfruttando gli esempi visti in precedenza, Alice può pagare a Bob diverse transazioni off-chain, ma Bob non può pagare Alice attraverso lo stesso canale.
Lightning Network, dunque, introduce uno dei concetti chiave di tale sistema, ovvero i canali di pagamento bidirezionali, sicuri ed affidabili.
Come aprire un canale
Per creare un canale di pagamento bidirezionale, entrambe le parti coinvolte devono prima concordare una transazione di apertura. Questa transazione di apertura determina quanti bitcoin vengono depositati nel canale da ciascuna delle due parti.
Nel’esempio di riferimento, Alice vuole inviare un bitcoin a Bob. Dal momento che Alice e Bob si aspettano di effettuare operazioni frequentemente, decidono di aprire un canale di pagamento bidirezionale. In questo esempio verranno usate quantità intere di bitcoin, ma è ovviamente possibile eseguire le medesime operazioni anche con piccole frazioni di BTC. Il sistema dunque, dovrebbe rendere bitcoin adatto anche alle micro-transazioni.
Per aprire il canale, Alice e Bob inviano cinque bitcoin ciascuno a un indirizzo multisig 2 di 2. Questa viene considera come la transazione di apertura. I bitcoin potranno essere spesi al di fuori di questo indirizzo solamente se sia Alice che Bob firmano la transazione. Inoltre, sia Alice che Bob creano un segreto, ovvero una stringa di numeri, e si scambiano il relativo hash.
Alice crea ora una transazione successiva all’operazione di apertura, ovvero un operazione d’ impegno. Con essa, Alice invia quattro bitcoin a se stessa e sei bitcoin ad un secondo indirizzo multisig. Questo secondo indirizzo multisig può essere sbloccato da Bob da solo, ma solo dopo che 1000 blocchi BTC sono stati estratti. Entra dunque in gioco un’applicazione pratica del blocco temporale CSV.
In alternativa, può essere sbloccata da Alice, ma solo se essa include anche l’hash di Bob. Alice firma quindi la sua conclusione di questa operazione senza però effettuare il broadcast.
Nel frattempo, Bob fa lo stessa cosa, ma in maniera speculare. Crea anche lui una transazione di impegno, da cui invia sei bitcoin a se stesso, e quattro ad un nuovo indirizzo multisig. Alice potrà sbloccare questo indirizzo solamente dopo 1000 blocchi, oppure potrà farlo Bob usando l’hash di Alice.
Dopo questi scambi di operazioni d’impegno “semi-valide”, entrambi firmano le transazioni e trasmettono l’operazione d’apertura alla blockchain per assicurarsi che essa venga registrata. A questo punto il canale è finalmente aperto.
D’ora in poi, sia Alice che Bob possono firmare e trasmettere le transazioni effettuate tra di loro. Se lo fa Alice, Bob ottiene immediatamente sei bitcoin. Se lo fa Bob, Alice ottiene immediatamente quattro bitcoin. Tuttavia, chi firma e diffonde la transazione dovrà attendere 1000 blocchi per sbloccare il successivo indirizzo multisig e rivendicare i bitcoin rimanenti.
Emerge quindi il meccanismo alla base dei canali di pagamento: nessuno dei due firma e trasmette completamente la propria parte delle transazione.
Aggiornamento del canale
Il passo successivo prevede che Bob voglia restituire ad Alice un bitcoin. Si vuole quindi aggiornare lo stato del canale per riportare i bilanci allo stato iniziale, ovvero cinque bitcoin ciascuno.
In primo luogo, entrambi ripetono il processo descritto sopra saltando la fase relativa alla transazione d’apertura. Questa volta, sia Alice che Bob si attribuiscono cinque bitcoin a testa e cinque ad un nuovo indirizzo multisig. Le condizioni dei nuovi multisig sono simili ma richiedono nuovi segreti: sia Alice che Bob si scambiano quindi gli hash. Entrambi firmano poi la loro nuova transazione d’impegno.
Il secondo passo, prevede che Alice e Bob si scambino il primo segreto utilizzato nella fase di apertura del canale. Così facendo, entrambi sono in possesso del segreto dell’altro.
A questo punto, ancora una volta, sia Alice che Bob hanno potuto firmare e trasmettere la nuova transazione di impegno appena conclusa. La loro controparte riceverà immediatamente cinque bitcoin, mentre il firmatario dovrà attendere 1000 blocchi. Il canale quindi, è stato aggiornato.
Tuttavia sorge spontanea una domanda: cosa impedisce a Bob di trasmettere la vecchia transazione così da ottenere sei bitcoin invece che cinque? Ciò che impedisce a Bob di effettuare tale operazione è il suo primo segreto, posseduto ora da Alice.
Bob quindi non può più firmare e trasmettere la vecchia transazione perché Alice conosce il primo segreto di Bob. Se Bob firmasse e trasmettesse quella transazione, invierebbe immediatamente quattro bitcoin ad Alice e dovrebbe attendere 1000 blocchi per rivendicare i suoi sei bitcoin. Ma dato che Alice ora possiede il segreto, potrebbe sfruttare il tempo di attesa dei mille blocchi per firmare la vecchia transazione e dunque rivendicare gli altri sei bitcoin oltre ai quattro che ha già ricevuto.
E dal momento che Bob possiede anche il segreto di Alice, è possibile eseguire tale procedura anche sul proprio reciproco. Se Alice cerca di firmare e trasmettere una vecchia transazione, Bob può rubare tutti i bitcoin nel canale.
Questo implica quindi che sia Alice che Bob siano fortemente incentivati a firmare e trasmettere solo lo stato più recente del canale. Un vero e proprio meccanismo di fair play e fiducia reciproca.
Costruzione della rete Lightning Network
Dopo aver introdotto i concetti base relativi al funzionamento dei canali e delle feature offerte, ecco come, mettendo insieme più canali e utenti, è possibile costruire un vero e proprio network.
Prima è stato illustrato come avvengono i pagamenti tra Alice e Bob, ora verrà mostrato cosa bisogna fare per introdurre una terza persona, Carol, nel sistema. La via più semplice e scontata consiste nell’aprire un canale tra Carol e Alice. Tuttavia, se si è già a conoscenza del fatto che Bob e Carol hanno già aperto un canale tra di loro, non c’è bisogno di creare un nuovo canale, in quanto Alice può semplicemente pagare Carol attraverso Bob.
Infatti, Alice può pagare a Bob un bitcoin, e Bob può pagare a Carol un bitcoin. Ovviamente l’operazione non può essere fatta così puramente in fiducia. Potrebbe succedere infatti, che, Alice paghi Bob ma poi Bob non paghi Carol. Oppure che Bob paghi Carol, ma che quest’ultimo affermi di non aver mai ricevuto nulla, rendendo Alice incapace di trovare il colpevole.
Tale operazione di passaggio sfruttando il canale di Bob può avvenire tramite un semplice trucco crittografico. Quando Alice vuole inviare un bitcoin a Carol, avvisa Carol, dicendogli di creare una stringa casuale di numeri e di inviarle il relativo hash. Alice dice anche a Carol di scambiare la stringa numerica originale con Bob in cambio di un bitcoin.
Nel frattempo Alice riceve l’hash da Carol e riferisce a Bob che gli darà un bitcoin se le fornisce la stringa numerica di Carol, che però è ancora solo in possesso di Carol.
Dunque, Bob da un bitcoin a Carol in cambio della stringa numerica. Poi Bob torna da Alice con la stringa. A questo punto, Alice sa che Bob deve avere ottenuto la stringa da Carol in cambio di una bitcoin, e quindi conclude che Carol ha ottenuto il suo bitcoin. Perciò Alice può tranquillamente pagare a Bob un bitcoin.
Tuttavia nella situazione appena ipotizzata, Bob deve avere fiducia sia di Carol che di Alice. Deve fidarsi di Carol che gli consegnerà la stringa numerica in cambio di un bitcoin, ma deve fidarsi anche di Alice, che gli pagherà un bitcoin solamente dopo averle consegnato la stringa di Carol.
Gli scambi di bitcoin per le stringhe numeriche devono avvenire con l’assoluta certezza che chi fa da tramite verrà poi ripagato. Ed è qui che entrano in gioco gli Hash Time-Locked Contracts (HTLCs).
HASH TIME-LOCKED CONTRACTS
Alice e Bob vogliono scambiare un bitcoin in cambio della stringa attraverso un HTLC. Al contempo, Bob e Carol vogliono effettuare uno scambio di un bitcoin per la medesima stringa.
Per fare questo, invece di inviare un bitcoin direttamente a Bob, Alice invia un bitcoin a un nuovo indirizzo multisig. I bitcoin bloccati su questo indirizzo possono essere sbloccati in due modi diversi.
- La prima opzione è che Bob includa la sua firma e la stringa che ha ottenuto da Bob;
- La seconda opzione è che Alice includa la propria firma. Tuttavia, questa opzione ha un effetto sospensivo e servirà per riottenere il pagamento nel caso in cui Bob non fornisca la stringa. Il sistema infatti, attua un blocco temporale di tipo CLTV. Alice può firmare e trasmettere l’operazione per riottenere il bitcoin solo dopo – per esempio – due settimane.
Questo significa che Bob ha due settimane di tempo per creare una transazione in cui includa la sua firma e la stringa, e per trasmetterla alla blockchain, così da riscattare il bitcoin dall’indirizzo multisig creato da Alice. In questo modo, lo scambio è garantito. Bob può rivendicare il bitcoin di Alice solo se fornisce la stringa. Può dunque trasmetterla attraverso la rete bitcoin per renderla pubblicamente visibile ad Alice ed ottenere il pagamento.
Nel caso in cui Bob non fornisse la stringa ad Alice in tempo, allo scadere del blocco temporale CLTV Alice riotterrà il suo bitcoin ed il contratto HTLC verrà distrutto.
Nel caso del network dunque, è proprio per questo motivo che l’uso dei contratti HTLC è necessario.
Come accennato, non solo Alice e Bob, ma anche Bob e Carol hanno sottoscritto un contratto HTLC. Quindi, se Carol rivendica il suo bitcoin da Bob, Bob otterrà la stringa in cambio. Il tutto sarà trasmesso e reso visibile sulla rete.
Pertanto, se questo accade, Bob è sicuro di ottenere un bitcoin da Alice. Bob può quindi prendere la stringa che Carol ha reso visibile sulla rete ed includerla nel suo HTLC con Alice. Potrà quindi rivendicare il bitcoin per se stesso. I due canali dunque, sono stati effettivamente collegati.
Vi è però un dettaglio importante, ovvero Bob deve ottenere la stringa da Carol prima che Alice possa recuperare il suo bitcoin dal HTLC con Bob. Se Bob ottenesse la stringa dopo che Alice ha già recuperato il bitcoin, Bob risulterebbe bloccato nel mezzo della transazione. Proprio per questo motivo, il time-out del HTLC di Bob e Carol deve pertanto scadere prima della scadenza del HTLC di Alice e Bob. Ecco perchè gli HTLC hanno bisogno del CheckLockTimeVerify (CLTV) e non del CheckSequenceVerify (CSV) visto in precedenza.
C’è però un ulteriore problema da risolvere. Per rendere Lightning Network davvero utile e veloce, tutte queste operazioni devono essere eseguite off-chain, dunque senza sincronizzazione con la blockchain di Bitcoin.
Unione del network e chiusura dei canali
Verrà ora approfondito come è possibile sfruttare tutto ciò che è stato introdotto fino ad adesso per rendere il sistema parzialmente a-sincrono dalla blockchain.
LIGHTNING NETWORK
Finora, Alice e Bob hanno aperto un canale di pagamento bidirezionale, entrambi finanziando con cinque bitcoin. Hanno fatto due transazioni, e, allo stato attuale del canale, sia Alice che Bob possono rivendicare cinque bitcoin per se stessi inoltrando il canale sulla blockchain. E’ stato poi approfondito come è possibile includere un contratto HTLC nel canale. Questo serve a garantire che se Carol rivendica un bitcoin da Bob in cambio della sua stringa, Bob è sicuro di ottenere un bitcoin da Alice in cambio.
Come nel passo precedente, Alice e Bob hanno iniziato creando una nuova transazione di impegno. Per molti versi, queste operazioni d’impegno sono molto simili alle precedenti operazioni. Includono un’uscita normale e un’uscita ad un indirizzo multisig con un blocco temporale CSV ed uno speciale hash-lock. Allo stesso modo, come nel passo precedente, Alice e Bob si scambiano i loro vecchi segreti, per rendere inutilizzabile il vecchio stato. A questo punto, sia Alice che Bob possono firmare le loro transazioni mezze verificate e potenzialmente trasmetterle sulla blockchain in qualsiasi momento.
Tuttavia c’è qualcosa che non torna. Sia le transazioni di Alice che di Bob includono un nuovo output del valore di un bitcoin. Dunque il bilancio non è di cinque bitcoin a testa ma di quattro per Alice, cinque per Bob, ed uno per il nuovo output. Questo nuovo output è l’HTLC e ci sono tre modi per sbloccarlo.
Innanzitutto, il nuovo output (in entrambe le operazioni di Alice e Bob) libera il bitcoin a condizione che la firma di Bob e la stringa (quella ottenuta da Carol) siano inclusi nella transazione successiva. Indipendentemente dal fatto che Alice o Bob segnalino e trasmettano l’operazione, solo Bob può sbloccare questo output. Se però Bob trasmette le operazioni alla blockchain, dovrà rispettare il blocco temporale CSV coinvolto. Dovrà quindi attendere 1.000 blocchi prima di ottenere il bitcoin, mentre se Alice abbandona il canale potrà rivendicarlo immediatamente.
Il motivo per cui Bob deve aspettare 1.000 blocchi se trasmette il canale è molto simile a quello visto prima: permette ad Alice di riscattare il bitcoin nel caso in cui Bob cerchi di firmare e trasmettere un vecchio stato del canale. Entra quindi in gioco il secondo modo per riscattare l’uscita. Nel caso in cui Bob trasmettesse un vecchio stato, Alice può utilizzare la vecchia chiave di Bob per rubare i fondi di Bob, che sta compiendo un’operazione illecita.
Ovviamente può accadere anche il contrario, ovvero che Alice inoltri un vecchio stato del canale. A questo punto, Bob tramite lo stesso stratagemma, potrà rivendicare il bitcoin in sospeso utilizzando il segreto di Alice.
La terza possibilità consiste, così come in qualsiasi HTLC, nella scadenza del blocco temporale CLTV, che quindi restituirà il bitcoin ad Alice. Se Bob non rispetta il time-out del contratto, Alice può rivendicare il suo bitcoin e riottenerlo. Anche in questo caso, che sia Alice o Bob a chiudere il canale non ha importanza.
Infine, come ultima opzione vi è il caso in cui Alice decide di chiudere il canale forzatamente. In questo caso, per prendersi il suo bitcoin, oltre ad aspettare il CLTV, deve anche attendere 1000 blocchi da quando ha trasmesso la prima transazione.
Ricapitolando dunque, sia Alice che Bob detengono una transazione d’impegno mezza convalidata. Se Alice trasmette la sua transazione sulla blockchain, invia immediatamente cinque bitcoin a Bob. Deve poi attendere 1.000 blocchi per riscattare i quattro bitcoin che le spettano. Bob ha invece due settimane per fornire la stringa e dichiararla nell’output del contratto HTLC. Una volta fatto, potrà quindi riscattare anche quel bitcoin.
In alternativa, Bob può trasmettere la sua transazione in qualsiasi momento e inviare immediatamente quattro bitcoin ad Alice. Quindi, dopo aver aspettato 1.000 blocchi, potrà rivendicare i cinque bitcoin dall’indirizzo ed il sesto bitcoin dall’output HTLC fornendo la stringa numerica.
Naturalmente, se uno dei due cerca di imbrogliare l’altro firmando e trasmettendo un canale non aggiornato, entrambi possono bloccare completamente l’altro, ed impossessarsi di tutti i bitcoin nel canale.
REGOLAMENTAZIONE DELLO STATO
A questo punto, Bob ha la garanzia di ricevere un bitcoin in cambio della stringa, supponendo che ne sia in possesso. Tutto quello che deve fare è firmare, includere la stringa e trasmettere l’operazione che ha ottenuto da Alice in una transazione successiva. Alice non può in alcun modo imbrogliare Bob, nemmeno se avesse scoperto la stringa attraverso altri mezzi.
I due però, potrebbero anche mettersi d’accordo al di fuori del canale. In questo modo, Bob può semplicemente dare la stringa ad Alice, ed Alice può aggiornare lo stato del canale senza HTLC e time-out. Se entrambi le parti vogliono mantenere aperto il canale, questo è la soluzione più immediata, in quanto è meno problematica che trasmettere il canale alla blockchain.
CHIUSURA DEL CANALE
Infine, ecco perché tutto ciò che è appena stato descritto non avrà mai bisogno di essere completamente trasmesso alla blockchain di bitcoin.
Se Alice e Bob vogliono chiudere il canale pacificamente, possono semplicemente creare una transazione a partire dall’operazione di apertura originale per annullare tutto ciò che è successo dopo di essa. Da questa transazione di chiusura, essi si inviano la loro parte di bitcoin presenti nel canale, come indicato nello stato più recente del canale.
Questo significa che se Alice vuole chiudere il canale, può semplicemente creare una transazione destinandosi quattro bitcoin e gli altri sei a Bob. Dovrà poi chiedere a Bob di firmare e trasmettere la transazione, visto che è di tipo multisig 2-2. Dal momento che non c’ è alcun motivo per non farlo, egli probabilmente coopererà e chiuderà il canale.
Alla fine, solo due transazioni sono state trasmesse sulla rete bitcoin e incluse in un blocco: la transazione di apertura e quella di chiusura. Ciò varrà anche nel caso in cui Alice e Bob effettuino un milione di transazioni. Verranno trasmesse solo l’operazione di apertura e chiusura, mentre tutte le altre saranno eseguite senza venir trasmesse sulla blockchain, consentendo a Lightning Network di essere immediato, veloce ed efficiente.
Naturalmente questi sono solo i concetti base dietro alla logica del funzionamento del protocollo Lightning Network. A livello tecnico ci sono molti altri concetti per rendere automatiche alcune delle operazioni citate. Tuttavia, per tutta la parte tecnica è possibile consultare il whitepaper di Lightning Network.
La rete sta già venendo testata ed utilizzata da migliaia di enti ed utenti. Sono infatti più di 8500 i nodi LN attivi sulla rete, per un totale di ben 35mila canali e quasi mille BTC di capacità.
Tale sistema offre una valida soluzione ai principali problemi del network di bitcoin, fra cui la scalabilità, le dimensioni della blockchain, velocità di conferma, fee ridotte ed altro. Si sta lentamente affermando come second layer di bitcoin, affiancato dalle diverse migliorie che verranno introdotti nel protocollo Bitcoin. Fra esse vi sono firme di Schnorr e Taproot, che a sua volta include MAST, e forse anche Mimble Wimble. Seguiranno poi le Confidential Transaction sfruttando le BulletProofs, già attive su Monero.
Infine, Lightning Network potrebbe venir utilizzato anche su altre criptovalute, dato che si tratta di un layer aggiuntivo da affiancare alla blockchain nativa della moneta.
