Fermata #89 - Bitcoin Training: il routing su Lightning Network

Nella fermata #27 abbiamo affrontato le basi del Lightning Network, il protocollo tecnologico costruito sopra a Bitcoin che consente pagamenti istantanei. Lightning è ciò che permette alla scoperta di Satoshi Nakamoto di scalare a livello globale come tecnologia di pagamento. La quantità di transazioni eseguibili è ordini di grandezza superiore a quella della timechain e, soprattutto, su LN non è necessario aspettare almeno 10 minuti affinché un pagamento venga confermato.

Sempre nella fermata #27 - di cui consiglio la lettura preventiva per comprendere questa puntata - abbiamo visto che LN è fondato sul concetto di canali di pagamento e abbiamo approfondito il funzionamento di questi ultimi. Ma cosa succede quando un peer di rete vuole pagarne un altro con cui non ha aperto un canale. La transazione avviene comunque tramite il routing.

Qui puoi ascoltare un estratto gratuito di Bitcoin Train Podcast!

Per accedere alla completa versione narrata dell’articolo ed entrare nel gruppo Telegram dedicato alla newsletter, abbonati a Bitcoin Train!

Il routing dei pagamenti

La rete Lightning permette di raggiungere peer con cui non si hanno canali aperti direttamente instradando il pagamento tramite altri peer, a patto che esista un percorso in grado di collegare il mittente al destinatario.

Nell’illustrazione il nodo A vuole pagare il nodo Q, con cui però non ha un canale diretto. Tuttavia è connesso con il nodo C, il quale ha un canale con il nodo F, che ne ha uno con il nodo K, che ne ha uno con il nodo L, che ne ha uno con il nodo Q.

Seguendo il percorso da A a Q, passando per C, F, K ed L, il pagamento viene effettuato. Ad una condizione: che la liquidità di ogni canale sia sufficiente per inoltrare l’importo al nodo successivo.

Il pathfinding

Prima che un pagamento venga effettivamente eseguito, il nodo deve trovare il percorso da far seguire ai fondi: questo processo prende il nome di pathfinding.

Oggi la rete Lightning conta oltre 16.000 nodi, connessi tra loro da quasi 43.000 canali con una liquidità media di 4.000.000 di sats. L’algoritmo di pathfinding, dunque, non ha difficoltà a trovare percorsi di pagamento: a parte nodi remoti e isolati - perché magari mal gestiti e abbandonati dopo veloci esperimenti - la stragrande maggioranza dei nodi Lightning può raggiungere, in qualche modo, un qualunque altro nodo della rete.

Una serie di problemi si presenta quando è il momento di verificare se i percorsi trovati abbiano la liquidità necessaria per supportare il pagamento.

Quando un canale di pagamento viene aperto da un nodo A a un nodo B con una liquidità di 1.000.000 di sats, il canale è sbilanciato: il nodo A ha 1.000.000 di sats di liquidità in uscita (meno qualche satoshi di commissione per la transazione di apertura canale on-chain), il nodo B li ha in entrata. Se A invia 500.000 sats a B, allora il canale diventa perfettamente bilanciato. 500.000 sats di liquidità sia in entrata che in uscita, sia per il nodo A che per il nodo B.

L’immagine seguente rappresenta un canale ben bilanciato del mio nodo Lightning. Il canale è aperto con il peer freedom.btcpayserver.it e ha 493.274 sats di liquidità in uscita e 503.354 sats di liquidità in entrata. Questo significa che il mio nodo, tramite questo canale, potrà inviare o inoltrare pagamenti fino a 493.274 sats e ricevere o inoltrare pagamenti fino a 503.354 sats.

I lettori più attenti avranno già notato la criticità. Tornando all’esempio originario - quello del pagamento dal nodo A al nodo Q - se il nodo A volesse pagare 1.000.000 di sats a Q ma anche solo uno dei canali intermedi non fosse finanziato con tale liquidità, la transazione non potrebbe andare a buon fine. Perché il pagamento viene finalizzato in questo modo: A paga C, C paga F, F paga K, K paga L e L paga Q.

Annuncio sponsorizzato

Hai una società con cui vuoi investire in bitcoin? Per le aziende che vogliono acquistare più di € 50.000 in un’unica operazione c’è RELAI Business, il servizio dell’azienda svizzera RELAI che mette a disposizione del cliente un intero team di esperti per un’assistenza 24/7.

RELAI Business offre:

• Un’avanzata assistenza individuale step-by-step da parte del team di RELAI;

• L’acquisto di bitcoin in meno di 24 ore tramite il Relationship Manager dedicato;

• Accesso a contenuti esclusivi, webinar e sessioni di condivisione delle competenze.

Comunica il codice d’invito “FEDERICO” al Relationship Manager.

Il routing

Se il pagamento viene passato di mano in mano fino alla destinazione finale, come si può essere certi che un nodo del percorso non si comporti in modo malevolo sottraendo i fondi? A questa domanda risponde il concetto di Hashed Timelock Contract (HTLC).

Ciò che avviene dietro le quinte quando si effettua un pagamento è quanto segue:

Alice deve pagare 100 sats a David passando tramite i nodi di Bob e di Carol. Bob e Carol, dunque, devono mettere a disposizione la propria liquidità per finalizzare la transazione. Per convincerli a farlo serve un incentivo economico: una commissione. Alice dunque paga 106 sats a Bob, il quale ne tiene 3 e invia 103 sat a Carol, la quale ne tiene 3 e invia 100 sats a David. In questo modo il pagamento va a buon fine e i nodi di Bob e Carol hanno guadagnato 3 sats a testa in commissioni di routing.

Per evitare che Bob o Carol decidano di imbrogliare intascandosi l’intera somma, il Lightning Network sfrutta quello che possiamo a tutti gli effetti definire uno smart-contract: Hashed Timelock Contract.

Per prima cosa David, il destinatario del pagamento, crea da un generatore di numeri casuali un valore chiamato Payment Secret, calcolandone poi l’hash SHA-2561. Il risultato prende il nome di Payment Hash e viene inviato da David ad Alice, la mittente della transazione.

Le parti coinvolte nel pagamento stipulano quindi fra di loro un contratto ricorrente:

• Alice deposita 106 sats che Bob può sbloccare solo comunicandole il Payment Secret che sta dietro al Payment Hash;

• Bob stabilisce a sua volta di versare 103 dei 106 sats che riceverà da Alice a Carol, se Carol gli comunicherà il Payment Secret che sta dietro al Payment Hash;

• Carol stabilisce di versare 100 dei 103 sats che riceverà da Bob a David, se David le comunicherà il Payment Secret che sta dietro al Payment Hash.

A questo punto David può comunicare il suo Payment Secret originale a Carol, la quale ne verificherà la corrispondenza con il Payment Hash e quindi gli verserà la somma pattuita di 100 sats. Carol seguirà poi lo stesso processo comunicando il Payment Secret a Bob e ottenendo da lui i 103 sats. Quest’ultimo comunicherà il Payment Secret ad Alice ricevendo i 106 sats.

In questo modo il contratto viene rispettato da tutti e il flusso di pagamenti viene finalizzato per completare la transazione.

Nuovo speaker annunciato da BTC Prague, la conferenza Bitcoin più grande d’Europa che si terrà a Praga dall’8 al 10 giugno!

Rogzy sta costruendo un'educazione per le masse. Il suo progetto DecouvreBitcoin mira a favorire un'adozione mondiale dal basso che non può essere fermata. Produce contenuti educativi open-source di alta qualità.

Usa il codice BTCTRAIN per ottenere il 10% di sconto sui biglietti d’ingresso. Ulteriore sconto del 5% pagando in bitcoin. Biglietti acquistabili da qui.

Online su YouTube la live di lunedì scorso con Massimo Musumeci

E’ online il nuovo video-approfondimento dedicato al tema della settimana di Bitcoin Train sul canale YouTube di Massimo Musumeci, fisico, ricercatore Bitcoin ed esperto di privacy e sicurezza informatica.

Questa settimana si è parlato de dibattito su Bitcoin nella politica americana. Appuntamento a lunedì 17 aprile!