Il Channel Jamming è una minaccia per la rete lampo di Bitcoin?

(Un ringraziamento speciale ad Antoine Riard e Gleb Naumenko, il cui recente ricerca è la base di questo articolo.)

L'inceppamento dei canali è uno dei problemi in sospeso della rete Lightning in termini di cose che potrebbero interrompere il successo dei pagamenti instradati attraverso di essa. È un problema ampiamente noto tra gli sviluppatori che è stato compreso da prima che la rete stessa andasse effettivamente in diretta su mainnet e iniziasse a elaborare anche un singolo satoshi.

Finora la questione non ha avuto alcun effetto negativo sulla rete, ma quando si considera questo fatto, è importante tenere presente che la rete è ancora, nel grande schema delle cose, relativamente piccola. I processori commerciali hanno iniziato a supportarlo, così come alcuni scambi e molti servizi e attività nativi di Lightning/Bitcoin, ma in realtà non è molto. La rete è ancora una piccola cosa utilizzata prevalentemente dai Bitcoiner, e non è affatto una porzione molto ampia del mondo.

Inoltre, la quantità di Bitcoiner che spendono e usano regolarmente i loro bitcoin nelle impostazioni commerciali è un sottoinsieme ancora più piccolo di quel già piccolo gruppo. Solo perché gli attacchi possibili non si stanno verificando ora, le persone non dovrebbero presumere che ciò significhi che continueranno a non verificarsi quando la rete crescerà su scala più ampia. Più grande diventa, più competitivo e contraddittorio diventerà.

Che cos'è l'inceppamento dei canali?

Il concetto di base del channel jamming è instradare i pagamenti attraverso un canale Lightning che desideri bloccare da te stesso a te stesso, e quindi non finalizzarli rilasciando la preimmagine all'hash di pagamento nel contratti timelock con hash (HTLC). Le vittime non saranno in grado di rimuovere gli HTLC dal loro canale fino a quando non sarà scaduto il periodo di blocco per il rimborso, perché non avrebbero modo di far valere la loro richiesta di denaro che gli è dovuta se l'immagine preliminare fosse stata rilasciata dopo averla rimossa. Se blocchi completamente un canale in questo modo, quel canale non sarà in grado di instradare alcun pagamento fino a quando non sarà scaduto il timelock su tutti i pagamenti dannosi.

Ci sono due diverse strategie che possono essere impiegate qui per eseguire l'attacco. Puoi provare a bloccare l'importo instradabile disponibile in un canale, oppure puoi provare a bloccare tutti i singoli slot HTLC in un canale. Un canale Lightning può avere solo 483 HTLC in attesa in ogni direzione che può instradare, questo perché esiste un limite massimo di dimensione di quanto può essere grande una transazione Bitcoin. Se aggiungi più di 483 HTLC per direzione nel canale, la transazione per chiudere il canale, se necessario, sarebbe troppo grande e non valida per essere inviata alla rete. Ciò renderebbe tutto nel canale inapplicabile sulla catena.

Quindi, un utente malintenzionato può tentare di bloccare tutta la liquidità in un canale o provare a bloccare tutti gli slot HTLC in un canale. Entrambe le strategie renderebbero il canale inutilizzabile, ma l'inceppamento degli slot sarà generalmente più economico dell'inceppamento della quantità. L'attaccante deve disporre di monete sulla rete per eseguire questo attacco, quindi instradare il valore minimo consentito per un HTCL con capacità 483 sarà più conveniente rispetto al tentativo di bloccare tutta la liquidità disponibile nel canale.

Perché qualcuno dovrebbe voler disturbare un canale di illuminazione?

Ci sono molte ragioni per eseguire questo attacco. In primo luogo, un'entità malintenzionata che vuole attaccare Bitcoin stesso potrebbe bloccare tutti i canali chiave al "core" della rete per rendere la maggior parte della rete inutilizzabile per l'instradamento dei pagamenti, ad eccezione dei nodi che sono molto strettamente collegati tra loro. . Ciò richiederebbe molte più monete per funzionare su questa scala, ma non è qualcosa che dovrebbe essere scontato come possibilità con più Bitcoin cresce e diventa un'alternativa ai sistemi monetari e di pagamento approvati dal governo.

In secondo luogo, un nodo di instradamento, o commerciante, potrebbe tentare di eseguire l'attacco a un concorrente per fargli pagare le commissioni rispetto alla concorrenza. Un commerciante che vende prodotti simili potrebbe bloccare i canali di un concorrente per impedire ai clienti di effettuare acquisti lì, nella speranza di incentivarli invece a fare acquisti nel loro negozio. Un nodo di instradamento che ha una connettività di canale simile a un altro nodo potrebbe bloccare i canali del nodo di instradamento concorrente per renderli inutilizzabili per l'instradamento dei pagamenti. Nel tempo ciò distruggerebbe la reputazione di quel nodo in termini di affidabilità di instradamento e, a causa di una connettività simile, renderebbe sempre più probabile che i portafogli degli utenti scelgano il nodo dell'attaccante per instradare i pagamenti attraverso la rete.

Questi attacchi possono essere ancora più efficienti in termini di capitale per l'attaccante se vengono instradati circolarmente attraverso un singolo canale più volte. Se sono abbastanza vicini alla vittima sulla rete, possono costruire un percorso di pagamento che gira intorno e continua a passare attraverso il canale della vittima. Ci sono dei limiti alla lunghezza di un percorso di pagamento, quindi questo non può essere fatto all'infinito, ma fare un percorso di pagamento in loop come questo può ridurre drasticamente la quantità di monete di cui l'attaccante ha bisogno per bloccare completamente i canali di una vittima.

Mitigazione degli attacchi di disturbo del canale

Potrebbero essere applicate alcune mitigazioni parziali di base per aumentare il costo per gli aggressori e mitigare i danni per le vittime. Il primo sarebbe un processo in più fasi per la gestione degli HTLC.

Attualmente, ogni HTLC aggiunge individualmente un nuovo output nella transazione di impegno per lo stato del canale corrente. Un processo in due fasi potrebbe creare un singolo output extra nella transazione di impegno e quindi avere una seconda transazione dopo quella a cui viene aggiunto l'HTLC effettivo. Ciò consentirebbe un massimo di 483 moltiplicato per 483 slot HTLC per canale (o 233,289 slot). Tuttavia, questo in realtà non risolve nulla di per sé e richiederebbe l'estensione dei blocchi temporali perché si aggiunge una transazione aggiuntiva per far rispettare le cose sulla catena e potrebbe effettivamente aiutare l'attaccante più della vittima se utilizzassero questa nuova struttura di transazione e il la vittima no. Tuttavia, aiuterà in combinazione con un'altra tecnica spiegata momentaneamente.

La seconda sarebbe una strategia reattiva, in cui un nodo che è caduto vittima di jamming può semplicemente aprire un nuovo canale allo stesso peer di quello bloccato. Ciò, tuttavia, richiederebbe di disporre di capitale extra per farlo, non risolve il costo opportunità di avere l'altro canale inceppato e di perdere i ricavi delle commissioni, e anche il nuovo canale potrebbe essere successivamente inceppato se l'attaccante ha il capitale disponibile per farlo .

La terza tecnica consisterebbe nel raggruppare gli slot HTLC. Attualmente ci sono 483 slot, e questo è un unico limite di slot applicato universalmente a tutti i pagamenti indipendentemente dal valore del pagamento. I nodi potrebbero creare bucket separati di limiti di slot più piccoli e applicarli a pagamenti di valori diversi, ad esempio pagamenti di 100,000 sats o inferiori potrebbero avere accesso solo a 150 slot. Pertanto, i pagamenti di instradamento di valore inferiore non possono consumare tutti gli slot HTLC disponibili.

I pagamenti da 100,000 sat a 1 milione di sat potrebbero avere accesso a 300 slot e da 1 milione a 10 milioni di sat potrebbero avere accesso a tutti i 483 slot. Ciò aumenterebbe in modo significativo il costo del capitale di un utente malintenzionato per slot jam, poiché non sarebbe più in grado di consumare tutti i 483 slot con il pagamento di valore più basso possibile. Inoltre, poiché le uscite HTLC al di sotto della soglia della polvere (attualmente, 546 sat) non possono nemmeno essere trasmesse e applicate sulla catena, qualsiasi cosa al di sotto di questo limite potrebbe essere gestita come un "secchio 0" poiché non viene comunque creata alcuna uscita HTLC. I nodi potrebbero semplicemente imporre limiti a queste transazioni in base alle risorse della CPU utilizzate o ad altre metriche per impedire che diventino rischi di negazione del servizio, a seconda di quanto possono permettersi di perdere se non vengono risolti onestamente.

Il bucket di slot in combinazione con la gestione HTLC a due fasi può essere utilizzato per ottimizzare l'applicazione dei limiti HTLC, ovvero i pagamenti di valore più elevato possono utilizzare la struttura a due fasi per creare più slot per canale poiché il valore di pagamento più elevato aumenta il costo di bloccandoli per un utente malintenzionato, rendendo meno probabile l'abuso di un limite di slot più elevato per eseguire attacchi di disturbo.

Nella loro ricerca sopra citata, Riard e Naumenko hanno dimostrato che con la combinazione ottimale di slot di bucket e estensione di slot a due stadi, la causa dell'inceppamento degli slot può essere resa costosa quanto l'inceppamento della quantità. Ciò non risolverebbe in modo completo il problema, ma aumenterebbe il costo minimo di esecuzione dell'attacco se ampiamente implementato dai nodi attraverso la rete.

Le due soluzioni complete che hanno esaminato sono una commissione anticipata/di attesa per bloccare la liquidità e un sistema di reputazione che utilizza token Chaumian accecati. Il TLDR del sistema tariffario è che verrebbe pagata un'obbligazione per una commissione anticipata per l'instradamento di un HTLC che dovrebbe richiedere molto tempo per essere regolato e, più a lungo rimane non regolato, rilascerebbe una commissione a ciascun nodo di instradamento per pezzo di tempo trascorso senza liquidazione. Il problema è che l'applicazione di questo potrebbe portare alla necessità di chiudere i canali se le tariffe non vengono inviate quando richiesto e causerà casi d'uso legittimi che richiedono lunghi tempi di blocco per pagare la stessa tariffa più alta che pagherebbe un utente malintenzionato che tenti di bloccare il canale.

Lo schema di reputazione comporterebbe un "vincolo di puntata" utilizzando prove a conoscenza zero per dimostrare il controllo di Bitcoin come difesa Sybil, e quindi utilizzando il legame legato alla tua reputazione per acquisire token Chaumian accecati dai nodi di instradamento che sarebbero riscattati e riemessi su HTLC sistemarsi con successo in un modo che preserva la privacy. I nodi emetterebbero i token una volta per identità e, se un HTLC non fosse saldato o rimborsato in modo tempestivo, i nodi potrebbero rifiutarsi di riemettere il token, impedendo così a un utente di instradare attraverso il proprio nodo a meno che non spenda tempo e denaro per creare un nuovo puntata obbligazionaria con diverse monete da emettere in un nuovo gettone.

Per chi volesse saperne di più su queste due soluzioni, maggiori informazioni sono disponibili nelle sezioni cinque ed sei nelle ricerche di Riard e Naumenko.

Vale anche la pena notare che se i nodi di instradamento dovessero adottare sistemi di deposito a garanzia di terze parti o linee di credito basate sulla fiducia, come ho scritto su qui, tutti questi problemi legati all'inceppamento dei canali smetterebbero di interessarli. Questo sarebbe un enorme cambiamento nel modello di fiducia per i nodi di instradamento, ma non avrebbe alcun effetto sulle persone che utilizzano canali Lightning reali per inviare e ricevere sat, la sicurezza dei loro fondi o la loro capacità di applicarlo sulla catena.

Le persone potrebbero non volerlo ascoltare, ma alla fine della giornata, se le soluzioni di cui sopra per mitigare l'inceppamento dei canali per i canali effettivi non sono sufficienti, questi sistemi di terze parti sono sempre un'opzione potenziale.

Questo è un guest post di Shinobi. Le opinioni espresse sono interamente proprie e non riflettono necessariamente quelle di BTC Inc o Bitcoin Magazine.