La Lightning Network \u00e8 la parte di Bitcoin che sposta davvero denaro: pagamenti che si chiudono in una frazione di secondo e costano frazioni di centesimo di euro. Eppure quasi nessuno spiega come funziona sotto il cofano. Nel 2026 la rete ha toccato i suoi massimi storici di capacit\u00e0 e ha iniziato a trasportare dollari in stablecoin, ma il modo in cui un pagamento trova la sua strada, il motivo per cui procurarsi liquidit\u00e0 \u00e8 cos\u00ec difficile e la reale convenienza economica di gestire un nodo restano una scatola nera per la maggior parte delle persone.<\/p>\n\n\n\n
Questa \u00e8 una guida all’idraulica e al modello di business della rete. Seguiremo un pagamento dal portafoglio del mittente a quello del destinatario, capiremo perch\u00e9 la inbound liquidity<\/em> \u00e8 il problema pi\u00f9 ostico, faremo i conti su quanto rende (o quanto costa) far girare un nodo di routing e vedremo gli aggiornamenti del 2026 che stanno cambiando le regole: gli offer di BOLT12, lo splicing, i canali taproot e i Taproot Assets. Per il dibattito su sicurezza e decentralizzazione e per l’analisi dedicata a stablecoin e MiCA restano i due articoli di approfondimento collegati pi\u00f9 avanti.<\/p>\n\n\n\n Il registro principale di Bitcoin produce un blocco ogni dieci minuti circa e regge solo una manciata di transazioni al secondo, in genere stimata intorno a sette. Quando lo spazio nei blocchi diventa conteso, le commissioni salgono e un pagamento piccolo diventa antieconomico. Va benissimo per il regolamento finale e per la conservazione di valore, molto meno per pagare un caff\u00e8 o mandare cinque euro dall’altra parte del mondo. Lightning nasce per questo: \u00e8 un layer 2 che sposta milioni di pagamenti fuori dalla catena e tocca la blockchain solo in due momenti, quando apre e quando chiude un canale. L’immagine pi\u00f9 utile \u00e8 quella di un conto che due parti tengono aperto tra loro, regolando il saldo sulla base layer solo alla fine.<\/p>\n\n\n\n La tentazione di risolvere tutto ingrandendo i blocchi \u00e8 stata al centro delle guerre di scalabilit\u00e0 del 2017, e ha perso. Blocchi pi\u00f9 grandi renderebbero pi\u00f9 costoso e centralizzato far girare un nodo completo, minando proprio la propriet\u00e0 che rende Bitcoin credibile come rete senza fiducia. La scelta della comunit\u00e0 \u00e8 stata mantenere conservativa la base layer e spostare il volume sui livelli superiori. Lightning \u00e8 la risposta pi\u00f9 matura a quella scelta, anche se non l’unica, e il confronto con rollup e sidechain resta un tema ricorrente.<\/p>\n\n\n\n L’idea non \u00e8 nuova. Il white paper che descrive la rete porta la firma di Joseph Poon e Thaddeus Dryja ed \u00e8 del 2015; la rete principale \u00e8 entrata in funzione nel 2018 e ha attraversato tappe simboliche come la Lightning Torch del 2019, il pagamento passato di mano in mano lungo la rete. Nel 2021 El Salvador ha reso bitcoin moneta a corso legale appoggiandosi in buona parte a Lightning, e nel 2026 \u00e8 arrivata la svolta delle stablecoin. In poco meno di dieci anni la rete \u00e8 passata da esperimento per crittografi a infrastruttura che regola oltre un miliardo di dollari al mese.<\/p>\n\n\n\n Alla base di tutto c’\u00e8 il canale di pagamento. Due parti bloccano dei bitcoin in una transazione di finanziamento con firma congiunta 2 su 2 (una multisig che richiede entrambe le firme per muovere i fondi). Da quel momento possono aggiornare il saldo tra loro quante volte vogliono senza scrivere nulla sulla blockchain: si scambiano transazioni di aggiornamento firmate, chiamate commitment transaction<\/em>, in cui cambia solo la ripartizione dei fondi.<\/p>\n\n\n\n Immaginiamo che Alice apra un canale con Bob depositando 0,02 BTC. Alice pu\u00f2 pagare Bob, Bob pu\u00f2 restituirle parte dei fondi, e cos\u00ec via, migliaia di volte, aggiornando ogni volta lo stato del canale. Ogni nuovo stato invalida il precedente grazie a un meccanismo di chiavi di revoca: se una delle due provasse a chiudere il canale pubblicando un vecchio saldo a proprio favore, l’altra potrebbe reclamare l’intero contenuto come penale. Alla chiusura, cooperativa o unilaterale, sulla catena finisce solo il saldo finale. La propriet\u00e0 chiave \u00e8 che nessuno affida i propri fondi all’altro: in qualsiasi momento puoi chiudere il canale in autonomia e riprenderti i tuoi bitcoin.<\/p>\n\n\n\n Un canale collega due sole parti, ma tu non hai un canale con chiunque nel mondo. La forza di Lightning \u00e8 che i pagamenti saltano da un canale all’altro attraversando nodi intermedi, e lo fanno senza che tu debba fidarti di quei nodi. Lo strumento che rende tutto questo sicuro \u00e8 l’HTLC, ovvero Hash Time-Locked Contract<\/em>. In pratica ogni salto del percorso \u00e8 vincolato a una condizione: il fondo viene sbloccato solo se, entro una finestra di tempo, viene rivelato il numero segreto (il preimage<\/em>) che corrisponde a un certo hash. Il destinatario conosce quel segreto; rivelandolo per incassare, sblocca a catena tutti i salti precedenti. O l’intero percorso va a buon fine, o non si muove nulla.<\/p>\n\n\n\n Un esempio rende l’idea. Se Alice vuole pagare Bob ma non ha un canale diretto, il pagamento pu\u00f2 passare per Carol, che ha un canale con entrambi. Alice non deve fidarsi di Carol: l’HTLC garantisce che Carol possa incassare la sua commissione solo se gira davvero il pagamento a Bob, e che tutto si annulli se qualcosa va storto entro la finestra di tempo. Ogni salto ha un margine di sicurezza temporale (il CLTV delta) leggermente pi\u00f9 ampio del successivo, cos\u00ec ciascun nodo ha il tempo di reagire prima che scada il proprio contratto.<\/p>\n\n\n\n La privacy \u00e8 affidata all’onion routing, la stessa idea che sta dietro a Tor. Il pagamento viaggia dentro una cipolla di cifratura a strati: ogni nodo intermedio riesce a sbucciare solo il proprio strato, scopre da chi ha ricevuto il pacchetto e a chi deve passarlo, ma non conosce n\u00e9 il mittente originale n\u00e9 il destinatario finale n\u00e9 la lunghezza totale del percorso. Nel 2024 l’implementazione LND ha aggiunto il route blinding<\/em>, un ulteriore accorgimento che protegge anche l’identit\u00e0 di chi riceve, come documentato nelle note di rilascio della versione 0.18<\/a>. \u00c8 grazie a questa combinazione che i nodi possono instradare valore senza sapere chi sta pagando chi.<\/p>\n\n\n\n Ecco il punto che manda in crisi la maggior parte dei nuovi utenti. In ogni canale ci sono due lati: quello che sta dalla tua parte \u00e8 la capacit\u00e0 outbound<\/em>, cio\u00e8 quanto puoi spendere; quello dall’altra parte \u00e8 la capacit\u00e0 inbound<\/em>, cio\u00e8 quanto puoi ricevere. Quando apri un canale nuovo depositando i tuoi fondi, hai tutta capacit\u00e0 in uscita e zero capacit\u00e0 in entrata: puoi pagare, ma non puoi essere pagato finch\u00e9 parte di quei fondi non \u00e8 transitata dall’altro lato. Un negozio ha bisogno soprattutto di inbound per incassare; chi spende ha bisogno di outbound.<\/p>\n\n\n\n Gestire questo equilibrio \u00e8 la vera fatica di Lightning. Jameson Lopp, ingegnere Bitcoin e cofondatore di Casa, nella sua guida alla gestione della liquidit\u00e0<\/a> definisce la capacit\u00e0 in entrata come una delle sfide pi\u00f9 grandi nel far girare un nodo di routing. E illustra il paradosso con un esempio: apri un bel canale capiente verso qualcuno che a sua volta non ha inbound, ci instradi molti satoshi, ottimo, ora hai inbound da lui; ma lui non ha inbound da nessuno, quindi di fatto ti ritrovi di nuovo senza capacit\u00e0 in entrata. \u00c8 un gioco a somma quasi zero che si riequilibra di continuo, e spiega perch\u00e9 l’onboarding di un nuovo portafoglio sia storicamente il punto pi\u00f9 fragile dell’esperienza utente.<\/p>\n\n\n\n Intorno a questo problema \u00e8 nata un’intera industria. I Lightning Service Provider (LSP) sono operatori che aprono canali verso gli utenti e forniscono capacit\u00e0 in entrata su richiesta, spesso in modalit\u00e0 just-in-time<\/em>: il canale viene creato nell’istante esatto in cui arriva il primo pagamento in entrata, cos\u00ec l’utente non deve pensarci. Le specifiche LSPS hanno standardizzato queste interazioni, permettendo ai portafogli di parlare con provider diversi in modo uniforme.<\/p>\n\n\n\n Chi vuole gestire la liquidit\u00e0 in autonomia ha altri strumenti. I mercati di liquidit\u00e0 permettono di comprare inbound da chi ce l’ha in eccesso. I submarine swap, come il servizio Loop di Lightning Labs, spostano fondi tra la catena principale e Lightning per riequilibrare i canali senza chiuderli. Lo splicing, di cui parliamo pi\u00f9 avanti, consente addirittura di ridimensionare un canale al volo. E con le inbound fee introdotte in LND 0.18<\/a> un nodo pu\u00f2 applicare sconti o sovrapprezzi per attrarre o scoraggiare il traffico in una certa direzione, trasformando la liquidit\u00e0 in un vero mercato con un prezzo. Portafogli come Phoenix e Breez nascondono tutta questa complessit\u00e0 dietro un’interfaccia che assomiglia a una normale app di pagamenti.<\/p>\n\n\n\n Un nodo che instrada pagamenti guadagna commissioni composte da due parti: una base fee<\/em> fissa per ogni pagamento e una fee rate<\/em> proporzionale all’importo, misurata in ppm (parti per milione). Cento ppm equivalgono allo 0,01%: il nodo trattiene cento satoshi per ogni milione instradato. Le tariffe di equilibrio per un nodo di routing stanno in genere da 50 a 500 ppm, ma la mediana della rete \u00e8 molto pi\u00f9 bassa, nell’ordine di poche decine di ppm, perch\u00e9 la concorrenza per instradare i pagamenti \u00e8 feroce.<\/p>\n\n\n\n La domanda che tutti si fanno \u00e8: rende? La risposta onesta \u00e8 che dipende quasi tutto dalla scala. Il nodo di routing gestito da Block, la societ\u00e0 di Jack Dorsey, ha comunicato un rendimento annuo intorno al 9,7% sulla liquidit\u00e0 investita, come riportato da Atlas21<\/a>: un risultato notevole, ma frutto di un’operazione professionale con decine di bitcoin in canali e software di ottimizzazione dedicato. Scendendo di dimensione i rendimenti crollano rapidamente, tra l’1% e il 4% l’anno, e per l’hobbista la realt\u00e0 \u00e8 spesso il pareggio o la perdita, una volta contati i costi di hosting e le commissioni on-chain per aprire e chiudere i canali.<\/p>\n\n\n\n Lo stesso Lopp, dopo mesi di gestione attiva, ha raccontato<\/a> che il suo nodo aveva incassato circa 60.000 satoshi di commissioni di routing spendendone all’incirca altrettanti in gestione on-chain, e che meno del 5% dei suoi tentativi di ribilanciamento andava a buon fine. Il ribilanciamento, del resto, costa da 50 a 200 ppm: se pareggiare un canale ti costa 100 ppm, la tariffa che applichi deve superare quella soglia, altrimenti instradare diventa una perdita. La gestione delle tariffe \u00e8 ormai una disciplina a s\u00e9: si alzano le fee sui canali molto richiesti e si abbassano su quelli sbilanciati per attirare traffico che li riequilibri gratis. \u00c8 un mestiere a margini sottili, ad alta intensit\u00e0 di capitale e di competenze, e questo spiega perch\u00e9 la rete si stia consolidando verso pochi grandi hub professionali invece di distribuirsi su migliaia di macchine amatoriali, una dinamica che abbiamo analizzato nel pezzo su quanto \u00e8 sicura e decentralizzata la rete<\/a>.<\/p>\n\n\n\nPerch\u00e9 Lightning esiste: il limite della base layer<\/h2>\n\n\n\n
I canali di pagamento: un conto congiunto tra due parti<\/h2>\n\n\n\n
Dalla coppia alla rete: HTLC e onion routing<\/h2>\n\n\n\n
Il problema della liquidit\u00e0: inbound, outbound e come si risolve<\/h2>\n\n\n\n
L’economia di un nodo di routing: quanto si guadagna davvero<\/h2>\n\n\n\n