Lightning Network 2026: quanto è sicura e decentralizzata
Nel 2026 la Lightning Network muove volumi record e attira le istituzioni, ma perde nodi e si concentra. Analisi di jamming, rischio quantistico, centralizzazione e deriva custodial.
Il 2026 è l’anno in cui la Lightning Network ha smesso di essere soltanto un esperimento per pagamenti da pochi centesimi. Gli stablecoin come USDT hanno iniziato a viaggiare sui suoi canali attraverso i Taproot Assets, un desk regolamentato ha spostato un milione di dollari verso l’exchange Kraken in meno di mezzo secondo, e i grandi custodi istituzionali hanno cominciato a vendere l’accesso a Lightning come un servizio chiavi in mano. Quella svolta, il momento in cui la seconda rete di Bitcoin è diventata un binario per i dollari, l’abbiamo raccontata in un’analisi dedicata.
Qui la domanda è un’altra, meno celebrativa: il binario sotto quei dollari è davvero solido? Dietro i record di volume c’è una rete che perde nodi da anni, che concentra quasi metà della sua infrastruttura su due fornitori cloud statunitensi, che convive con un attacco denial-of-service mai risolto e che ha visto uno dei suoi sviluppatori più esperti farsi da parte proprio per ragioni di sicurezza. Nel frattempo un dibattito sul rischio quantistico ha diviso la comunità tra chi definisce Lightning «senza speranza» e chi parla di allarmismo. Questo articolo mette in fila le fragilità strutturali della rete, senza sconti e senza catastrofismi, e spiega perché contano per chi, in Europa, la usa o la deve regolare.
Come funziona Lightning: canali, HTLC e fiducia minima
La Lightning Network è un reticolo di canali di pagamento costruiti sopra la blockchain di Bitcoin. Due parti bloccano dei fondi in un indirizzo multisig 2-di-2 con una transazione on-chain (l’apertura del canale), poi si scambiano fuori dalla catena una sequenza di aggiornamenti di saldo firmati. Finché il canale resta aperto quei pagamenti sono istantanei e quasi gratuiti, perché non toccano la blockchain: solo l’apertura e la chiusura del canale vengono registrate on-chain. Per pagare qualcuno con cui non si ha un canale diretto, il pagamento viene instradato attraverso una catena di nodi intermedi tramite gli HTLC (Hashed Time-Locked Contracts), contratti che rilasciano i fondi solo dietro presentazione di un segreto crittografico entro una scadenza. Il tragitto è costruito da chi paga con una tecnica a cipolla, così ogni nodo conosce solo il salto precedente e quello successivo.
Il modello di sicurezza di Lightning non è «senza fiducia», ma «a fiducia minima», ed è una distinzione che pesa. La garanzia fondamentale è la transazione di penalità: se la controparte prova a chiudere il canale trasmettendo un vecchio stato a lei più favorevole, l’altra parte può punirla portandosi via l’intero saldo del canale, a patto di accorgersene prima della scadenza del timelock. Quel «a patto di accorgersene» è il cuore del problema, perché richiede di restare online o di delegare la sorveglianza a un servizio esterno chiamato watchtower. La stessa costruzione a multisig, del resto, sta cambiando grazie a schemi di firma più efficienti: le firme a soglia come MuSig2 e FROST rendono questi accordi più compatti e privati, e sono la base di alcune delle reti che vedremo più avanti. In fondo alla catena, la sicurezza ultima di ogni saldo Lightning resta ancorata al livello base di Bitcoin.
Lo stato della rete nel 2026: capacità record, nodi in calo
I numeri di Lightning nel 2026 raccontano due storie opposte. La capacità pubblica, cioè i bitcoin bloccati nei canali visibili, ha toccato un massimo storico di 5.637 BTC a dicembre 2025, spinta dai depositi istituzionali di exchange come Binance, OKX e Coinbase, per poi ripiegare a circa 4.898 BTC a maggio 2026, distribuiti su 41.080 canali pubblici e 17.438 nodi, secondo la ricerca di Spark. Ai circa 56.000 euro per bitcoin di inizio agosto 2026 (CoinGecko) sono poco più di 270 milioni di euro di liquidità visibile; i canali privati e non annunciati, usati da wallet mobili e provider di liquidità, valgono probabilmente il doppio o più.
È l’altra metà del quadro a preoccupare. Il volume mensile ha superato 1,17 miliardi di dollari a novembre 2025, con una crescita del 266% su base annua e circa 12 milioni di transazioni verso fine anno, eppure il numero di nodi continua a scendere: dai circa 20.700 del picco del 2022 ai 17.438 di oggi. La rete, in altre parole, muove più denaro che mai attraverso sempre meno nodi, più grandi e più professionali. È il primo indizio di una tendenza che attraversa tutto questo articolo: Lightning sta diventando più capace e, allo stesso tempo, più concentrata.
| Indicatore | Valore | Periodo |
|---|---|---|
| Capacità pubblica (picco storico) | 5.637 BTC | dicembre 2025 |
| Capacità pubblica (minimo 2025) | circa 4.200 BTC | agosto 2025 |
| Capacità pubblica (ultimo dato) | circa 4.898 BTC | maggio 2026 |
| Canali pubblici | 41.080 | maggio 2026 |
| Nodi pubblici | 17.438 | maggio 2026 |
| Nodi pubblici (picco) | circa 20.700 | 2022 |
| Volume mensile | oltre 1,17 mld USD | novembre 2025 |
| Crescita del volume (annua) | +266% | 2025 |
Channel jamming: il difetto che nessuno ha ancora risolto
Il channel jamming è l’attacco che gli sviluppatori di Lightning conoscono da anni e che nessuno ha ancora chiuso. Il meccanismo è elementare: un attaccante instrada un pagamento verso sé stesso passando per i canali di un nodo bersaglio, poi si rifiuta di completarlo. Finché il pagamento resta in sospeso, la liquidità impegnata è congelata e non può instradare altri pagamenti che frutterebbero commissioni, fino a quando il timelock dell’HTLC non scade, ore dopo. L’attaccante non rischia quasi nulla, perché i pagamenti falliti non pagano commissioni di routing: è il cosiddetto problema dell’opzione gratuita, un incentivo perverso incorporato nel protocollo.
Esistono due varianti, spiega Bitcoin Magazine. Il jamming per importo blocca capacità immobilizzando somme rilevanti; il jamming per slot è più insidioso e più economico, perché sfrutta un limite tecnico preciso: ogni canale può avere al massimo 483 HTLC in sospeso per direzione, un tetto che deriva dalla dimensione massima di una transazione Bitcoin (oltre quel numero, la transazione di chiusura del canale diventerebbe troppo grande e non valida). Riempire 483 slot con micro-pagamenti costa pochissimo e paralizza il canale. Le contromisure proposte, dai sistemi di reputazione e credenziali all’endorsement degli HTLC fino alla gestione a bucket degli slot studiata da Antoine Riard e Gleb Naumenko, esistono, ma nessuna è ancora uno standard diffuso. A metà 2026 il jamming resta irrisolto e, per fortuna, non ancora sfruttato su larga scala.
L’addio di Antoine Riard e i limiti strutturali
Quanto sia difficile mettere in sicurezza Lightning lo dice una vicenda del 2023. Nell’ottobre di quell’anno Antoine Riard, tra gli sviluppatori più esperti di Bitcoin Core e di Lightning, annunciò il proprio passo indietro dallo sviluppo del protocollo, contestualmente alla divulgazione di una classe di attacchi che chiamò «replacement cycling», o transaction-relay jamming (Coingape). L’attacco consente, in teoria, di espellere dalla mempool di Bitcoin la transazione onesta con cui una vittima prova a chiudere un canale, facendola scadere e aprendo una finestra per sottrarre i fondi degli HTLC in transito. Il problema, sottolineò Riard, non riguardava solo Lightning: toccava anche i discreet log contract, i coinjoin, i payjoin e ogni percorso di spesa sensibile al tempo.
La vulnerabilità venne mitigata e non è mai stata sfruttata in modo malevolo, ma le contromisure disponibili non erano mai state provate contro attacchi di jamming reali. Il messaggio implicito nella scelta di Riard è scomodo: difendere un protocollo che dipende dalla propagazione tempestiva delle transazioni, contro un avversario paziente e ben finanziato, è un problema aperto. A questo si sommano attriti più prosaici ma altrettanto strutturali, la difficoltà di procurarsi liquidità in entrata (inbound liquidity), la complessità di gestire i canali e il vincolo di dover restare connessi. Sono proprio questi attriti a spingere gli utenti verso le scorciatoie che erodono la decentralizzazione, ed è lì che si annidano i rischi più concreti.
La centralizzazione nascosta: i nodi su AWS e Google Cloud
La prima scorciatoia è l’hosting. Una delle analisi più citate sulla topologia di Lightning ha rilevato che circa il 48% dei nodi gira su appena due fornitori: Amazon Web Services, con circa il 29%, e Google Cloud, con circa il 19% (Bitcoinist). La ragione è pratica: Lightning premia chi resta sempre online, perché entrambe le parti di un canale devono essere raggiungibili per aggiornare i saldi e reagire a una chiusura ostile, e il cloud offre una continuità di servizio vicina al 100%. Il risultato, però, è un paradosso: una rete nata per eliminare gli intermediari di fiducia poggia in buona parte su due colossi statunitensi.
Le implicazioni non sono teoriche. Un disservizio esteso di AWS potrebbe mettere offline nello stesso momento una quota rilevante dei nodi di instradamento; un fornitore cloud, in linea di principio, potrebbe censurare o disattivare i nodi che ospita. Va detto con onestà che quella cifra è una fotografia, con metodologie che oscillano tra il 45% e il 49% a seconda della rilevazione, e che il numero esatto conta meno della dipendenza strutturale che descrive. Questa dipendenza, come vedremo, ha un curioso riflesso nella normativa europea.
Liquidità concentrata: la topologia hub-and-spoke
Oltre a dove girano i nodi, conta come è distribuito il capitale. La liquidità di Lightning non è spalmata in modo uniforme: la rete ha una struttura hub-and-spoke, con pochi grandi nodi di instradamento e provider di liquidità (gli LSP, Lightning Service Provider) che intermediano la maggior parte dei pagamenti. Un’analisi accademica pubblicata su New Journal of Physics, basata su dati del 2019, misurò un coefficiente di Gini della capacità intorno a 0,88, con il 10% dei nodi a detenere circa l’80% dei bitcoin impegnati (arXiv). I dati sono datati, ma la forma della rete non è cambiata nella sostanza, e anzi il calo dei nodi tende ad accentuarla.
Questa concentrazione ha una logica: instradare attraverso pochi hub ben capitalizzati aumenta la probabilità che un pagamento vada a buon fine, e i mercati della liquidità che riforniscono i canali rendono il sistema più usabile. Ma ogni hub è anche un punto di fallimento e un potenziale collo di bottiglia per la censura. Il problema dell’inbound liquidity, la difficoltà per un nuovo utente di ricevere fondi senza che qualcuno gli apra un canale in entrata, spinge ulteriormente verso gli LSP, cioè verso l’intermediazione. Prima di proseguire, conviene mettere in fila le fragilità viste finora e quelle che restano.
| Fragilità | Meccanismo | Stato nel 2026 | Mitigazione |
|---|---|---|---|
| Channel jamming | Blocco della liquidità sfruttando il limite di 483 HTLC per direzione | Irrisolto, non sfruttato su larga scala | Reputazione, credenziali, bucket degli slot (non ancora standard) |
| Concentrazione dei nodi | Circa il 48% dei nodi su AWS e Google Cloud | Strutturale | Nessuna a livello di protocollo; DORA per i CASP regolati |
| Concentrazione della liquidità | Topologia hub-and-spoke (Gini circa 0,88) | Strutturale | LSP e mercati della liquidità |
| Deriva custodial | Gli utenti delegano le chiavi a wallet ed exchange | In crescita | Spark, Ark, hardware wallet con supporto LN |
| Rischio quantistico | Il force-close espone la chiave pubblica | Teorico, non imminente | Firme post-quantum (in ricerca) |
| Privacy | Gli LSP e i nodi vedono i pagamenti che instradano | Parziale | BOLT12, blinded path, PTLC |
La deriva custodial: quando l’utente rinuncia alle chiavi
La scorciatoia più diffusa, però, è un’altra: rinunciare del tutto all’autocustodia. Far girare un nodo Lightning non custodial è complicato (gestione dei canali, liquidità in entrata, sorveglianza contro le chiusure fraudolente), e così la stragrande maggioranza dell’uso reale passa da servizi custodial: exchange come Kraken, Coinbase e Binance, e wallet in cui è il gestore a tenere le chiavi. È comodo, ma è esattamente il tipo di intermediario di fiducia che Bitcoin voleva rendere superfluo.
Lo ha ammesso senza giri di parole, già nel 2023, David Marcus, cofondatore e amministratore delegato di Lightspark: per rendere una Lightning non custodial pienamente funzionante (con ricezione anche offline) ed economicamente sostenibile, ha spiegato, «you have to accept some form of compromise on the trustlessness level of the solution», cioè bisogna scendere a compromessi sul grado di fiducia richiesto (Bitcoin.com News). È il nodo irrisolto dell’autocustodia su Lightning: la ricezione offline, la sorveglianza dei canali e le commissioni di apertura per piccoli importi hanno un costo, e quel costo si paga in fiducia. Il rischio, per l’ecosistema, è che Lightning diventi tecnicamente decentralizzata ma praticamente custodiale, con grandi depositi concentrati che diventano bersagli appetibili e punti di controllo.
Il rovescio del binario-dollari: stablecoin e nuova complessità
C’è poi una fragilità che nasce proprio dal successo del 2026. Portare gli stablecoin su Lightning, USDT tramite i Taproot Assets e, in prospettiva, una seconda strada basata su RGB, ha aggiunto superfici di rischio nuove. I canali in bitcoin ora instradano anche asset che bitcoin non sono, con prezzi negoziati salto per salto (il meccanismo RFQ), il che frammenta la liquidità e complica il routing. Soprattutto, uno stablecoin reintroduce esattamente il rischio di controparte e di emittente che Bitcoin era stato pensato per eliminare: dietro un USDT che viaggia veloce su Lightning c’è pur sempre Tether. Approcci come il protocollo RGB, che tiene lo stato degli asset lato client e ancora on-chain solo un impegno crittografico, spostano il modello di fiducia ma non lo annullano.
Per l’utente europeo l’ironia è doppia. Il binario trasporta al meglio proprio l’asset, USDT, che MiCA ha di fatto spinto fuori dalle sedi regolamentate dell’Unione, come abbiamo ricostruito nell’analisi sul binario dei dollari. La rete più neutrale finisce così a veicolare lo strumento più conteso, e la robustezza dell’insieme dipende non solo dal protocollo ma dalla solidità di emittenti e custodi che stanno ai suoi bordi. Ogni nuovo asset che sale sulla rete allarga la superficie da difendere.
Il dibattito quantistico: «senza speranza» o rischio gestibile?
Nell’aprile 2026 il tema della sicurezza di Lightning è esploso su un fronte inatteso. Udi Wertheimer, cofondatore di Taproot Wizards, ha definito la rete «senza speranza» (helplessly broken) di fronte ai computer quantistici (CryptoPotato). Il ragionamento: quando un canale viene chiuso forzatamente (force-close), la transazione di commitment finisce on-chain ed espone una chiave pubblica; un computer quantistico abbastanza potente, eseguendo l’algoritmo di Shor, potrebbe ricavarne la chiave privata e spendere quei fondi prima della scadenza del timelock. Poiché il force-close mette in chiaro la chiave pubblica, sostiene Wertheimer, i fondi su Lightning sarebbero strutturalmente esposti.
La replica è arrivata da Bobby Shell in un editoriale su CoinDesk, che ha giudicato fuorviante quella cornice. La vulnerabilità è reale e specifica, ha scritto, ma è «una corsa contro il tempo con un attaccante»: la finestra utile è di circa 144 blocchi (poco più di 24 ore), e per gli output HTLC può scendere a 40 blocchi (sei o sette ore); soprattutto, un computer quantistico crittograficamente rilevante non esiste ancora, e lo stesso identico problema riguarda il livello base di Bitcoin, dove le chiavi pubbliche riutilizzate sono altrettanto esposte. «La domanda che le imprese dovrebbero porsi non è se abbandonare Lightning sulla base di una minaccia futura e teorica», ha concluso Shell. La sintesi ragionevole: il rischio quantistico è autentico ma non imminente, ed è un problema di migrazione dell’intero Bitcoin verso firme post-quantum, non una condanna a morte esclusiva di Lightning.
Privacy: cosa Lightning nasconde e cosa rivela
Un’altra convinzione diffusa è che Lightning sia privata per definizione. La realtà è più sfumata. I pagamenti sono instradati con una tecnica a cipolla (onion routing) simile a Tor, così ogni nodo intermedio vede solo il salto precedente e quello successivo, non l’intero percorso: un buon punto di partenza. Ma chi invia sceglie la rotta e ne conosce molto; il primo nodo, in genere il proprio LSP, vede i pagamenti in uscita; un wallet custodial vede tutto; e le transazioni di apertura e chiusura dei canali restano pubbliche e collegabili sulla blockchain. Tecniche di sondaggio dei saldi (balance probing) e analisi dei tempi possono, in certe condizioni, deanonimizzare gli utenti.
Il fronte dei miglioramenti è aperto. Le offerte BOLT12, con i loro percorsi accecati (blinded path) che nascondono il destinatario, e i PTLC (Point Time-Locked Contracts), che sostituiscono gli HTLC per spezzare la correlazione tra i salti di uno stesso pagamento, alzano l’asticella; la versione LND v0.21, uscita a giugno 2026, ha introdotto l’inoltro dei messaggi onion, un primo passo verso il pieno supporto a BOLT12 (Lightning Labs). Sul versante on-chain il complemento naturale sono i Silent Payments, che nascondono il lato Bitcoin delle aperture e chiusure di canale. La privacy su Lightning, insomma, è possibile ma non automatica: dipende da come e con chi la si usa.
Gli sfidanti senza canali: Spark, Ark e Wavelength
Molte delle fragilità viste finora nascono dalla stessa radice: i canali di pagamento sono potenti ma scomodi da gestire. Da qui una nuova generazione di protocolli senza canali, che promettono l’istantaneità di Lightning senza la gestione della liquidità, in cambio di un modello di fiducia diverso. Spark, sviluppato da Lightspark, si basa sulle statechain (un’idea di Ruben Somsen del 2018) e sulle firme a soglia FROST: alcuni operatori (oggi Lightspark e Flashnet) co-firmano le transazioni, e la sicurezza regge finché almeno uno tra loro e l’utente è onesto (un modello 1-di-n). Nessun canale da gestire; in cambio, ci si affida agli operatori. Da non confondere con Spark Protocol (token SPK), il mercato di prestito su Ethereum: sono due cose diverse con lo stesso nome.
Ark, con la sua implementazione Arkade di Ark Labs, usa i VTXO (UTXO virtuali) gestiti a round da un Ark Service Provider, in beta pubblica su mainnet dal 2025 e sostenuta da un seed round con Tether tra gli investitori. Wavelength, annunciata da Lightning Labs nel luglio 2026 in versione alpha su testnet, è di fatto un terzo protocollo in stile Ark, compatibile con Lightning e pensato anche per i pagamenti degli agenti AI. Il filo comune è chiaro: eliminano la gestione dei canali introducendo un operatore di cui fidarsi almeno per la disponibilità (liveness). Tutti regolano su Bitcoin, tutti sono molto più piccoli di Lightning, e tutti spostano l’ago della bilancia dalla fiducia minima verso la comodità.
| Sistema | Architettura | Ipotesi di fiducia | Gestione dei canali |
|---|---|---|---|
| Lightning | Canali di pagamento + HTLC | Fiducia minima (serve monitorare o restare online) | A carico dell’utente |
| Spark (Lightspark) | Statechain + firme FROST | 1-di-n onesto tra gli operatori | Nessuna |
| Ark / Arkade | VTXO + ASP a round | Fiducia nella disponibilità dell’ASP | Nessuna |
| Wavelength (Lightning Labs) | Stile Ark + ponte Lightning | Simile ad Ark | Nessuna |
Istituzioni e regole: Consob, MiCA e DORA
Due forze stanno professionalizzando Lightning, con effetti ambivalenti sulla decentralizzazione. La prima sono le istituzioni. Il 28 gennaio 2026 il desk Secure Digital Markets ha inviato un milione di dollari all’exchange Kraken su Lightning, con regolamento in 0,43 secondi e instradamento gestito dall’infrastruttura di Voltage: la più grande transazione Lightning pubblicamente documentata, contro un record informale precedente di circa 1,24 BTC (Bitcoin Magazine). «Spostare un milione di dollari verso Kraken sulla Lightning Network segna un cambiamento definitivo nell’architettura del regolamento globale», ha commentato Mostafa Al-Mashita, cofondatore di SDM. Custodi come BitGo e Xapo Bank e provider come Voltage stanno vendendo Lightning come servizio: ottimo per l’adozione, ma significa che sempre più capitale scorre attraverso pochi intermediari regolamentati.
La seconda forza è il diritto europeo, e qui la distinzione è cruciale: a livello di protocollo Lightning è aperta e senza permessi, e né Consob né MiCA la regolano. Ciò che viene regolato sono i CASP, gli exchange e i wallet custodial che la toccano. In Italia MiCA è attuato dal D.lgs. 129/2024, che affida a Consob la condotta di mercato e a Banca d’Italia i profili prudenziali e sugli stablecoin; il periodo transitorio abbreviato è scaduto il 1° luglio 2026, quindi chi serve clienti italiani deve ormai essere autorizzato. Per i servizi di custodia, considerati ad alto impatto, MiCA richiede un capitale minimo di 150.000 euro (contro i 50.000 della consulenza e i 125.000 delle piattaforme di negoziazione), secondo l’ESMA; è una parte della mappa dei CASP autorizzati che abbiamo tracciato altrove.
Il riflesso più interessante riguarda proprio la concentrazione sul cloud. Dal 17 gennaio 2025 il regolamento DORA impone agli operatori finanziari europei di gestire il rischio di concentrazione sui fornitori ICT terzi, mappando le dipendenze ed evitando di affidarsi a pochi provider; a novembre 2025 le autorità di vigilanza europee hanno pubblicato il primo elenco dei fornitori ICT critici (EUR-Lex). Eppure la Lightning Network in sé, con il suo 48% di nodi su AWS e Google Cloud, resta fuori dal perimetro di DORA, perché non è un’entità finanziaria regolata: solo i CASP che la usano devono rispondere del rischio di concentrazione. L’Europa, in sostanza, ha un libro di regole sulla concentrazione per i bordi regolamentati della rete e nessuna leva sul suo nucleo concentrato.
Cosa servirebbe per rendere Lightning più solida
Nessuno di questi problemi è insormontabile, ma le soluzioni procedono lentamente. Sul jamming servirebbe rendere standard i sistemi di reputazione e la gestione a bucket degli slot; sul fronte della privacy e dell’usabilità, le offerte BOLT12 sono già native in Core Lightning, LDK ed Eclair, mentre LND, che fa girare la maggior parte dei nodi pubblici, resta indietro: la v0.21 di giugno 2026 ha aggiunto solo l’inoltro dei messaggi onion come primo passo, e la v0.22 non è ancora uscita ad agosto 2026. Contro la deriva custodial servono strumenti più semplici per l’autocustodia (canali just-in-time, splicing, le specifiche LSPS) e un hosting più diversificato. Sul rischio quantistico, infine, la risposta è una migrazione dell’intero Bitcoin verso firme resistenti ai computer quantistici, negli anni a venire.
- Rendere standard le contromisure anti-jamming (reputazione, credenziali, bucket degli slot).
- Completare il supporto a BOLT12 su LND e diffondere i PTLC per privacy e affidabilità.
- Ridurre la dipendenza dal cloud e semplificare l’autocustodia (canali just-in-time, splicing, LSPS).
- Avviare per tempo la migrazione di Bitcoin verso la crittografia post-quantum.
Il verdetto onesto è che Lightning, nel 2026, è insieme più capace e più concentrata che mai. Funziona, muove volumi record, regge pagamenti istituzionali da sette cifre in meno di un secondo ed è genuinamente utile a milioni di persone. Ma la decentralizzazione e la fiducia minima che ne giustificano l’esistenza si stanno logorando ai margini, un nodo cloud e un wallet custodial alla volta. Per una rete che si presenta come il livello di pagamento sovrano di Bitcoin, questa è la tensione da tenere d’occhio nei prossimi mesi, molto più del prossimo record di capacità.
Domande frequenti
È sicura la Lightning Network?
È adatta e sicura per l’uso quotidiano di piccoli importi, ma il suo modello è a fiducia minima, non a fiducia zero: per evitare frodi bisogna restare online o affidarsi a un watchtower, e restano problemi irrisolti come il channel jamming. Per grandi somme o custodia a lungo termine sono più indicati i wallet on-chain in autocustodia.
Che cos’è il channel jamming su Lightning?
È un attacco denial-of-service in cui un malintenzionato instrada pagamenti verso sé stesso e si rifiuta di completarli, congelando la liquidità dei canali altrui finché scadono i timelock. Sfrutta il limite di 483 HTLC per direzione ed è molto economico; a metà 2026 non è stato ancora risolto, ma nemmeno sfruttato su larga scala.
I computer quantistici possono rubare i fondi su Lightning?
Non oggi. Un computer quantistico sufficientemente potente potrebbe in teoria attaccare la chiave pubblica esposta durante un force-close prima della scadenza del timelock, ma una macchina simile non esiste ancora e la finestra utile è di poche ore. È un problema dell’intero Bitcoin, non solo di Lightning.
La Lightning Network è davvero decentralizzata?
Meno di quanto sembri. Circa il 48% dei nodi gira su AWS e Google Cloud, la liquidità è concentrata in pochi hub e gran parte dell’uso reale passa da servizi custodial. La rete resta aperta e senza permessi, ma la sua topologia è fortemente concentrata.
Meglio un wallet Lightning custodial o non custodial?
Dipende dal compromesso che si accetta. I wallet custodial sono semplici ma fanno rinunciare al controllo delle chiavi; quelli non custodial preservano l’autonomia ma richiedono gestione della liquidità e connettività. In Europa i wallet custodial rientrano in MiCA come servizi CASP.
Di Alessandro Conti, redattore senior di HOGE Wire.