Il Lighting Network

Tra le sfide più importanti che bitcoin sta combattendo, fin dai suoi primi passi, c’è quella della scalabilità della tecnologia blockchain, che ne è alla base. Immaginando questa catena di blocchi, ognuno dei quali contenente n transazioni da validare, è facile intuire che se la dimensione di ogni blocco è limitata mentre il numero di transazioni effettuate aumenta, i blocchi non riusciranno a contenerle tutte. Si formeranno code di transazioni in attesa di essere processate, e il sistema risulterà lento e inefficiente.

L’incremento massiccio del numero delle transazioni ha avuto come conseguenza, ad oggi, che il costo della “commissione” spettante ai miners per processare la transazione, includendola nel blocco, aumentasse in modo rilevante e che – pertanto – l’architettura tecnologica non riuscisse a rendere né veloce né economicamente conveniente l’effettuare pagamenti con bitcoin, soprattutto se di piccoli importi (in quanto in tali casi la commissione poteva superare di molto l’importo della transazione stessa).

Tale problema di scalabilità ha aperto, ormai da tempo, un importante dibattito tra i developers, che hanno proposto diverse soluzioni per fronteggiare tale limite. Alcuni hanno proposto possibili miglioramenti del software, volti a migliorarne la scalabilità.

È ormai prassi che le proposte dei developers su eventuali modifiche al protocollo bitcoin, e destinate ad essere “votate” dalla comunità del network, prendano il nome di BIP, acronimo di Bitcoin Improvement Proposal. Si tratta di un documento dove vengono indicate le modifiche ed è il documento standard per veicolare idee di modifica alla tecnologia blockchain sottostante al bitcoin.

SegWit e il blocco da 8MB di Bitcoin Cash

Il 24 agosto 2017 – al Blocco numero #481824 – la community ha implementato il BIP 141, una proposta di variazione del protocollo bitcoin chiamata Segregated Witness (SegWit). Tralasciando una dettagliata quanto tecnica descrizione di tale upgrade, per renderlo di immediata comprensione ai non “addetti ai lavori” si può affermare che SegWit “restringe”, nel blocco, i dati relativi al riconoscimento della firma (witness, appunto) di soggetti parte della transazione da eseguire (dati che ammontano al 65% dei dati totali nel blocco). Pertanto SegWit permette che più transazioni entrino nello stesso blocco, rispetto a prima. In realtà – andando a studiare più nel dettaglio SegWit – quello che succede è che il concetto di block size (dimensione del blocco) viene sostituito con quello di block weight (peso del blocco) e, sulla base di questo criterio, il “peso” dei dati della transazione diversi da quelli di firma (non-witness) viene equiparato a 4 unità, mentre il “peso” dei dati di firma (witness) soltanto ad una unità. Quindi in realtà quello che succede è che i dati di firma vengono proporzionalmente ridimensionati.

SegWit ha sicuramente snellito l’architettura bitcoin, e molti tra i principali exchange hanno implementato tale aggiornamento. Tuttavia – anche se con SegWit il problema di scalabilità di bitcoin è stato in qualche modo “tamponato” – la necessità di scalare ulteriormente l’architettura tecnologica del protocollo resta di primaria importanza per lo sviluppo della criptomoneta.

Nel 2017, tale upgrade di SegWit (implementando il BIP 141) ha costituito un soft fork. Un soft fork è un cambiamento del protocollo blockchain backward compatible con la versione precedente: cioè un cambiamento che rende ancora possibile, per i nodi/miners della rete che non si siano aggiornati, continuare a validare le nuove transazioni/blocchi che vengono generati sulla base delle nuove regole (per rendere banalmente l’idea, quello che succede quando con il nostro vecchio smartphone riusciamo comunque a utilizzare una app rilasciata per la nuova versione).

Nell’agosto 2017, invece, la decisione di alcuni tra i miners di bitcoin di passare da blocchi di dimensioni di 1MB a blocchi di dimensioni di 8MB ha dato vita a una nuova criptovaluta, il Bitcoin Cash. Questo è stato un vero e proprio hard fork, ovvero un aggiornamento del software che di fatto crea una divergenza permanente rispetto alla versione precedente del software della blockchain, e pertanto non è backward compatible con quest’ultima. I nodi/miners che non aggiornano il software non verranno più accettati come nodi/miners dal nuovo software: questo crea una biforcazione della blockchain, dove una catena continua implementando il nuovo software, mentre un’altra continua ad operare con il vecchio software.

Due mondi che condividono la catena d’origine ma “non si parlano più”. Come tra Bitcoin e Bitcoin Cash.

Anche in questo caso, come con l’implementazione di SegWit, il problema della scalabilità non è stato risolto alla radice: anche blocchi più grandi, prima o poi, diventeranno troppo piccoli se il numero delle transazioni sulla blockchain continuerà ad aumentare.

Sia SegWit che l’aumento della blocksize di Bitcoin Cash sono state soluzioni on-chain, ovvero implementazioni di scalabilità operate direttamente sulla blockchain stessa. Cosa differente, invece, è un implementazione off-chain (o second layer technology), che non impattano direttamente sulla catena principale. La più promettente, a oggi, è il Lightning Network.

Il Lightning Network

Il Lightning Network (“LN”) è un protocollo di pagamento second-layer che opera al di sopra della blockchain principale bitcoin, costituendo – di fatto – un “secondo strato” rispetto a quest’ultima, rendendo possibili pagamenti istantanei, anche di piccole entità, basandosi su una rete di canali di pagamento bidirezionali. Tutto ciò assicurando la caratteristica dell’assenza di necessaria fiducia in terze parti per eseguire la transazione, elemento tipico del Bitcoin.

L’idea principale su cui si basa il LN è che non è necessario che tutte le transazioni debbano essere registrate sulla blockchain principale. Se, ad esempio, Alfa e Beta si conoscono e hanno rapporti commerciali da lungo tempo in base ai quali reciproci pagamenti avvengono tra di loro in modo frequente, non è necessario che – per ogni pagamento – debbano istruire la data operazione sulla blockchain. Possono, invece, aprire tra di loro un canale, registrando sulla blockchain principale soltanto il primo pagamento, quello di apertura del relativo canale. E il canale resterà aperto fino a quando Alfa e Beta non decideranno si chiuderlo, registrando il pagamento “di chiusura” sulla blockchain, come un settlement finale.

Inoltre, se Alfa e Beta hanno un payment channel aperto tra di loro e Beta ne ha uno con Gamma, allora – nel caso in cui Alfa debba effettuare un pagamento a Gamma – potrà utilizzare Beta come “router” per veicolare la transazione tramite il payment channel che Beta ha già in essere con Gamma. I pagamenti all’interno del “pipeline” non toccheranno la blockchain e pertanto saranno immediati.

Il meccanismo sottostante

Tutto si basa sul fatto che le due parti aprono il canale di pagamento nel LN, depositando – con la transazione di apertura che avviene sulla blockchain – una uguale somma di bitcoin ognuno in una sorta di conto di deposito, dal quale nessun bitcoin può essere movimentato se non con l’accordo di entrambe le parti.

Dopo di che entra in gioco la rivoluzione principale del LN: le parti iniziano a effettuare pagamenti tra di esse trasferendosi l’un l’altra non veri e propri bitcoin (BTC), ma delle promesse di pagamento di bitcoin (anche indicate con IOU, formula utilizzata per indicare l’inglese “I owe you”, “Io ti devo”). Si passa pertanto dal traferire la proprietà dell’asset (transfer of ownership) a effettuare una promessa a trasferire (promise to trasfer the ownership), come se fosse una ricognizione di debito. Il trasferimento effettivo dei bitcoin avverrà con la chiusura del payment channel, quando il deposito verrà “sbloccato” e i bitcoin all’interno trasferiti ad ognuna delle parti a seguito del conteggio dei reciproci IOUs emessi dalle stesse a canale aperto (un meccanismo molto simile al bilateral netting tra controparti di contratti derivati swap).

Inoltre, siccome nessuna delle parti può chiudere il canale (smobilizzando quindi il deposito di BTC cosi creato) senza il consenso dell’altra, è impossibile che uno dei due soggetti possa “rubare” i BTC nel deposito movimentandoli unilateralmente. Ciò rende il LN estremamente sicuro.

Nodi e Onion Routing nel Lighting Network

Il reticolo dei “payment channel” che man mano si crea tra i partecipanti, di fatto fa sì che ognuno di questi ultimi possa non solo essere mittente e/o destinatario di un pagamento, ma anche decidere di operare come un vero e proprio nodo del network (diventando una sorta di “routing hub” della rete). Naturalmente applicando delle fee, seppur esigue.

Il soggetto che decide di operare come nodo sarà più o meno “capiente” a seconda di quanti payment channel avrà operativi e aperti con altri nodi del network, aspetto che in ultima analisi dipende dall’ammontare di Bitcoin che il dato nodo detiene: perché – come sopra indicato – l’apertura di un payment channel presuppone che vi sia un deposito di BTC a garantire il pagamento finale on-chain degli IOUs veicolati tramite tale canale. In altre parole, il nodo potrà smistare tanti IOUs quanti sono i BTC che effettivamente detiene secondo la blockchain. Un qualcosa che ricorda il ruolo della controparte centrale (CCP) nell’infrastruttura finanziaria di oggi, che infrapponendosi tra gli istituti suoi membri e diventandone (per novazione) l’unica controparte nei contratti, deve per sua natura detenere un importantissima riserva di liquidità.

All’origine del “viaggio” della transazione, il nodo che per primo deve veicolarla nel lightning network riceve tutte le informazioni riguardo (i) a tutti i gli altri nodi posizionati adeguatamente nella rete, aventi la necessaria capacity per instradare la transazione fino al nodo finale (i.e. il nodo che avrà un payment channel aperto con il destinatario finale del pagamento) e (ii) alle fee che, di nodo in nodo, un determinato tragitto (routing path) richiede per il transito.

Sulla base di queste informazioni – proprio come un pilota di aereo che, presi in considerazione fattori metereologici, tempo di volo e carburante a disposizione, sceglie la rotta ottimale per raggiungere l’aeroporto di destinazione -, il nodo sceglie la migliore routing path per il pagamento da inviare nella rete (i.e. la meno costosa in termini di fee).

Altro aspetto fondamentale è che i nodi del LN operano un sistema di routing chiamato onion routing (routing “a cipolla”). Le informazioni relative alla route da seguire vengono criptate ad ogni passaggio intermedio da nodo a nodo, con una struttura a cipolla, appunto. Questo vuol dire che ogni nodo intermedio della catena può leggere esclusivamente il dati relativi (a) allo strato informativo da esso ricevuto, cioè da quale nodo gli è giunta la transazione, e quelli relativi (b) allo strato informativo da esso decriptabile, ovvero a quale nodo ad esso collegato deve trasmettere la transazione. Ne consegue che i nodi intermedi non conoscono l’identità né del mittente né del destinatario finale del pagamento che veicolano: hanno solo conoscenza del nodo prima e quello dopo rispetto alla loro posizione nella rete. Il nodo ultimo, poi, quando andrà a decriptare l’unico strato informativo ad esso accessibile, scoprirà di essere il destinatario finale del pagamento. Cosi come il primo nodo era l’unico a sapere di essere il nodo che aveva generato la transazione.

Exchange come nodi maggiori del Lighting Network?

Molto hanno considerato che, in quanto (come sopra evidenziato) un nodo del LN sarà tanto più capiente quanto più ingenti saranno le risorse di Bitcoin da esso effettivamente detenute, gli exchange di cripto valute saranno molto probabilmente i nodi maggiori presenti nel network. Questo ha aperto un grande dibattito tra gli studiosi di questa nuova tecnologia second layer, alcuni tra i quali pensano che lo strapotere degli exchange possa andare ad inficiare i principi di net neutrality applicati alla base dell’architettura IT del protocollo bitcoin, qualora tali borse diventassero i nodi “padroni” della rete lighting.

Mentre il dibattito su questo resta aperto, è però interessante considerare le riflessioni, su questo aspetto, di Andreas Antonopoulos, tra i personaggi e divulgatori scientifici più influenti nella community dei developers e studiosi della tecnologia blockhain. Secondo Antonopoulos, infatti, gli obblighi di compliance a livello AML/KYC (normative antiriciclaggio e Know Your Customer) che gravano sugli exchange sono del tutto incompatibili con la struttura di onion-routing sopra descritta.

Infatti, mentre gli exchange applicano tali normative nei confronti dei loro clienti finali per le transazioni on-chain, non potrebbero fare altrettanto se – in qualità di nodi – si trovassero a veicolare, sul lighting network, pagamenti riguardo ai quali gli exchange non hanno alcun tipo di visibilità né sul mittente né circa il destinatario finale (anche qualora fosse il loro stesso cliente finale, “censito” solo su operazioni in blockchain, ma totalmente anonimo sulla struttura di onion routing).

Gioacchino Rinaldi