Bitcoin In Evidenza Lightning Network

[Guida] Lightning Network: ecco come funziona l’estensione del network di Bitcoin

Sicuramente avrete sentito parlare di Lightning Network, visto che molti lo definiscono 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 che lo rendono inadatto ad un potenziale uso di massa per i pagamenti. In primis vi è il grande problema della scalabilità e del numero di transazioni, fisso a meno di 7 transazioni per secondo. Già questo dunque, è un enorme vincolo. Inoltre i dati contenuti nella blockchain ne stanno aumentando sempre più le dimensioni. Già ad oggi l’intero registro distribuito ha un peso di più di 200 GB e, con costanti ritmi di crescita, potrebbe raggiungere valori di decine e decine di TeraByte, con una conseguente inusabilità del sistema da parte degli utenti, se non tramite un ente centrale.

In secondo luogo poi, vi è il problema delle fees. Infatti, durante periodi di gran congestione, come accaduto lo scorso dicembre, le fees da pagare ai miners per la conferma aumentano significativamente. Pensate che a dicembre per “pagare un caffè” in Bitcoin avreste dovuto sborsare un ventina di euro di spese di commissioni. Un sistema di pagamento decisamente inutilizzabile nell’uso pratico come forma di pagamento di massa.

Proprio per questo motivo, nel corso degli anni è stato sviluppato un layer aggiuntivo da affiancare alla blockchain di Bitcoin per aumentarne scalabilità, usabilità, velocità e diminuirne le spese di commissione. Questo layer è proprio Lightning Network di cui andremo a parlare in questo articolo. Vediamo dunque come funziona.

Caratteristiche dei canali e della rete Lightning Network

Per risolvere tutti i problemi sopra 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 Payement 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 possibili creare una particolare tipologia di Smart Contract tra i due membri del canale. Un esempio? Il pagamento della bolletta telefonica, un abbonamento o tutte quelle procedure da pagare con una certa cadenza temporale. Li vedremo più nel dettaglio più avanti. Oltre a tutti questi vantaggi, abbiamo poi la “teorica” eliminazione delle fees, che in alternativa possono essere ridotte significativamente.

Vediamo ora le principali caratteristiche base dei canali Lightning Network.

TRANSAZIONI NON CONFERMATE

Il protocollo Bitcoin è costituito essenzialmente da transazioni, tipicamente legate a transazioni precedenti e potenzialmente a transazioni 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 bitcoins, come 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, vediamo 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

Come è giusto che sia, 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 (o ingressi) si basano sullo stesso output, solo una può essere confermata.

Bisogna tenere in considerazione che anche le transazioni non confermate possono essere in conflitto, il che significa che solo una può essere confermata, evitando quindi il Double-Spending.

Nell’esempio in figura, vediamo che 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.

INDIRIZZI 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. Per esempio, possono richiedere due su tre possibili chiavi, o quindici su quindici, e così via.

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

Troviamo poi i blocco temporali. Essi possono bloccare i bitcoin in arrivo 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 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.

CRITTOGRAFIA: 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 chiameremo segreto) relativa per l’effettiva verifica. 

Creazione dei canali di pagamento bidirezionali

Come anticipato in apertura, 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 i nostri esempi, 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.

APERTURA DEL 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.

Mettiamo che Alice voglia 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 useremo 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 e 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. Stiamo dunque parlando di 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 loro parte delle transazione.

AGGIORNAMENTO DEL CANALE

Mettiamo poi che Bob voglia restituire ad Alice un bitcoin. Vogliono quindi aggiornare lo stato del canale per riportare i loro 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 bitcoins, mentre il firmatario dovrà attendere 1000 blocchi. Il canale quindi, è stato aggiornato.

Tuttavia possiamo chiederci: 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 bitcoins 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, vediamo ora come, mettendo insieme più canali e utenti, è possibile costruire un vero e proprio network.

IL NETWORK

Prima abbiamo visto come avvengono i pagamenti tra Alice e Bob, ora vediamo cosa bisogna fare per introdurre una terza persona, Carol, nel sistema. La via più semplice e scontata consiste nell’aprire un canale di tra Carol e Alice. Tuttavia, se sappiamo già 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 – ipotizziamo – 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.

Lightning Network

 

Tornando al network, è 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. Per questo motivo, gli HTLC hanno bisogno del CheckLockTimeVerify (CLTV) e non del CheckSequenceVerify (CSV) che abbiamo visto precedentemente.

Lightning Network

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

Vediamo ora come è possibili sfruttare tutto quello che abbiamo introdotto fino ad adesso per rendere il sistema parzialmente a-sincrono dalla blockchain e come sfruttare canali, contratti HTLC e le altre feature per il funzionamento di Lightning Network.

LIGHTNING NETWORK

Finora, Alice e Bob hanno aperto un canale di pagamento bidirezionale, entrambi finanziando con cinque bitcoins. Hanno fatto due transazioni, e, allo stato attuale del canale, sia Alice che Bob possono rivendicare cinque bitcoins per se stessi “inoltrando il canale” sulla blockchain. Abbiamo poi visto come sia 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 canale. 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 che abbiamo 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.

Infine, 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.

Lightning Network

Ricapitolando dunque, sia Alice che Bob detengono una transazione d’impegno mezza convalidata. Se Alice trasmette la sua transazione sulla blockchain, invia immediatamente cinque bitcoins 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, vediamo 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 off-chain, consentendo a Lightning Network di essere immediato, veloce ed efficiente.

Lightning Network

Naturalmente questi sono solo i concetti basi dietro alla logica del funzionamento del protocollo Lightning Network. A livello tecnico ci sono molti altri concetti per rendere automatiche alcune delle operazioni che abbiamo citato. Tuttavia, per tutta la parte tecnica vi rimando al whitepaper di Lightning Network.

La rete sta già venendo testata ed utilizzata da alcuni enti ed utenti. Non sappiamo se e quando diventerà realmente popolare, visto che molti rimangono dubbiosi sul rispetto della decentralizzazione, tuttavia il sistema offre una valida soluzione ai principali problemi del network di Bitcoin, fra cui la scalabilità, le dimensioni della blockchain, velocità di conferma, fees ridotte ed altro. Il sistema poi, potrebbe venir utilizzato anche su altre criptovalute, dato che si tratta di un layer aggiuntivo da affiancare alla blockchain nativa della moneta.

Sperando di essere stato abbastanza chiaro, per questo approfondimento dedicato a Lightning Network è tutto, alla prossima!

sharing-caring

Vi invitiamo a seguirci sul nostro canale Telegram ed anche sul gruppo ufficiale Telegram, dove sarà possibile discutere insieme delle notizie e dell’andamento del mercato, sulla nostra pagina Facebook e sul nostro account Twitter.

[ VIA | VIA | VIA | VIA ]

Emanuele Pagliari

Ingegnere delle telecomunicazioni appassionato di tecnologia. La mia avventura nel mondo del blogging è iniziata su GizChina.it nel 2014 per poi proseguire su LFFL.org, GizBlog.it, ed ora su CryptoMinando.it. Sono nel mondo delle criptovalute come minatore dal 2013 ed ad oggi seguo gli aspetti tecnici legati alla blockchain, crittografia e dApps, anche per applicazioni nell'ambito dell'Internet of Things, la mia branca di studio.
Follow Me:

Related Posts

Rispondi

CryptoMinando