Este bruiarea canalului o amenințare pentru rețeaua de fulgere a Bitcoin?

(Mulțumiri speciale lui Antoine Riard și Gleb Naumenko, ale căror cercetare recentă este baza acestui articol.)

Bruiajul canalelor este una dintre problemele restante ale rețelei Lightning în ceea ce privește lucrurile care ar putea perturba succesul plăților direcționate prin aceasta. Este o problemă cunoscută pe scară largă în rândul dezvoltatorilor, care a fost înțeleasă încă de înainte ca rețeaua în sine să intre în funcțiune pe rețeaua principală și să înceapă să proceseze chiar și un singur satoshi.

Până acum, problema nu a avut cu adevărat niciun efect negativ asupra rețelei, dar luând în considerare acest fapt, este important să rețineți că rețeaua este încă, în marea schemă a lucrurilor, relativ mică. Procesoarele de comercianți au început să o susțină, la fel ca câteva schimburi și o mulțime de servicii și afaceri native Lightning/Bitcoin, dar, în realitate, asta nu este mult. Rețeaua este încă un lucru mic, folosit predominant de Bitcoiners, și nu este deloc o parte foarte mare a lumii.

Chiar și mai mult, cantitatea de Bitcoiners care cheltuiesc și își folosesc în mod regulat bitcoin în setările comerciale este un subset și mai mic al acelui grup deja mic. Doar pentru că atacurile care sunt posibile nu au loc acum, oamenii nu ar trebui să presupună că asta înseamnă că vor continua să nu aibă loc atunci când rețeaua crește la o scară mai mare. Cu cât devine mai mare, cu atât va deveni mai competitivă și mai adversară.

Ce este Channel Jamming?

Conceptul de bază al bruiajului canalului este să direcționați plățile printr-un canal Lightning pe care doriți să îl blocați de la dvs. la dvs. și apoi să nu le finalizați prin eliberarea preimaginei către hash-ul de plată din contracte de blocare a timpului (HTLC). Victimele nu vor putea elimina HTLC-urile de pe canal decât după expirarea perioadei de blocare pentru rambursare, deoarece nu ar avea nicio modalitate de a-și impune pretenția la banii care îi sunt datorați dacă preimaginea a fost eliberată după eliminarea acesteia. Dacă blocați complet un canal făcând acest lucru, atunci canalul respectiv nu va fi capabil să direcționeze nicio plată până după expirarea timpului de blocare pentru toate plățile rău intenționate.

Există două strategii diferite care pot fi folosite aici pentru a efectua atacul. Puteți fie să încercați să blocați cantitatea rutabilă disponibilă într-un canal, fie să încercați să blocați toate sloturile individuale HTLC dintr-un canal. Un canal Lightning poate avea doar 483 de HTLC-uri în așteptare în fiecare direcție pe care o poate direcționa - asta pentru că există o limită de dimensiune maximă a cât de mare poate fi o tranzacție Bitcoin. Dacă adăugați mai mult de 483 de HTLC pe direcție în canal, tranzacția de închidere a canalului, dacă este necesar, ar fi prea mare și nu este validă pentru a fi trimisă în rețea. Acest lucru ar face ca totul din canal să nu fie aplicabil în lanț.

Deci, un atacator poate fie să încerce să blocheze toată lichiditatea dintr-un canal, fie să încerce să blocheze toate sloturile HTLC dintr-un canal. Oricare dintre strategii ar face canalul inutilizabil, dar blocarea sloturilor va fi, în general, mai ieftină decât blocarea sumei. Atacatorul trebuie să aibă monede în rețea pentru a efectua acest atac, așa că direcționarea valorii minime permise pentru un HTCL de 483 de capacitate va fi mai rentabilă decât încercarea de a bloca toată lichiditatea disponibilă pe canal.

De ce ar vrea cineva să blocheze un canal de iluminat?

Există multe motive pentru a efectua acest atac. În primul rând, o entitate rău intenționată care dorește să atace Bitcoin în sine ar putea bloca toate canalele cheie în „nucleul” rețelei pentru a face cea mai mare parte a rețelei inutilizabilă pentru rutarea plăților, cu excepția nodurilor care sunt foarte strâns conectate între ele. . Acest lucru ar necesita mult mai multe monede pentru a funcționa la această scară, dar nu este ceva care ar trebui să fie exclus ca o posibilitate cu cât Bitcoin crește și devine o alternativă la sistemele de bani și de plată sancționate de guvern.

În al doilea rând, un nod de rutare, sau comerciant, ar putea încerca să efectueze atacul asupra unui concurent pentru a le aduce taxe spre deosebire de concurență. Un comerciant care vinde produse similare ar putea bloca canalele unui concurent pentru a-i împiedica pe clienți să facă achiziții acolo, în speranța de a-i stimula să facă cumpărături la magazinul lor. Un nod de rutare care are o conexiune de canal similară cu un alt nod ar putea bloca canalele nodului de rutare concurent pentru a le face inutilizabile pentru rutarea plăților. În timp, acest lucru ar distruge reputația nodului respectiv în ceea ce privește fiabilitatea de rutare și, datorită conectivității similare, ar face din ce în ce mai probabil ca portofelele utilizatorilor să aleagă nodul atacatorului pentru a direcționa plățile în rețea.

Aceste atacuri pot fi și mai eficiente de capital pentru atacator dacă se direcționează circular printr-un singur canal de mai multe ori. Dacă sunt suficient de aproape de victimă în rețea, ei pot construi o rută de plată care circulă și continuă prin canalul victimei. Există limite pentru cât de lungă poate fi o rută de plată, așa că acest lucru nu se poate face la infinit, dar efectuarea unei rute de plată în buclă ca aceasta poate reduce drastic cantitatea de monede de care are nevoie atacatorul pentru a bloca complet canalul (canalele) victimei.

Atenuarea atacurilor de bruiaj de canal

Ar putea fi aplicate unele atenuări de bază, parțiale, pentru a crește costul pentru atacatori și pentru a atenua daunele pentru victime. Primul ar fi un proces în mai multe etape pentru manipularea HTLC.

În prezent, fiecare HTLC adaugă individual o nouă ieșire în tranzacția de angajament pentru starea curentă a canalului. Un proces în două etape ar putea crea o singură ieșire suplimentară în tranzacția de angajament și apoi poate avea o a doua tranzacție după aceea care are HTLC-ul real adăugat. Acest lucru ar permite un maxim de 483 înmulțit cu 483 de sloturi HTLC pe canal (sau 233,289 de sloturi). Cu toate acestea, acest lucru nu rezolvă nimic de la sine și ar necesita extinderea timpului de blocare, deoarece adăugați o tranzacție suplimentară pentru aplicarea lucrurilor în lanț și, de fapt, ar putea ajuta atacatorul mai mult decât victima dacă ar folosi această nouă structură de tranzacție și victima nu a făcut-o. Cu toate acestea, va ajuta în combinație cu o altă tehnică explicată pentru moment.

A doua ar fi o strategie reactivă, în care un nod care a căzut victima bruiajului poate deschide pur și simplu un nou canal către același peer ca și cel care este blocat. Acest lucru, totuși, ar necesita un capital suplimentar pentru a face acest lucru, nu fixează costul de oportunitate al celuilalt canal blocat și pierderea veniturilor din comisioane, iar noul canal ar putea fi blocat ulterior, de asemenea, dacă atacatorul are capitalul disponibil pentru a face acest lucru. .

A treia tehnică ar fi să gătiți sloturi HTLC. În prezent, există 483 de sloturi, iar aceasta este o singură limită de slot aplicată universal tuturor plăților, indiferent de valoarea plății. Nodurile ar putea crea compartimente separate cu limite de sloturi mai mici și le pot aplica plăților de valori diferite, adică plățile de 100,000 de sats sau mai mici ar putea avea acces doar la 150 de sloturi. Deci, rutarea plăților de valoare mai mică nu poate consuma toate sloturile HTLC disponibile.

Plățile de la 100,000 de sat la 1 milion de sat ar putea avea acces la 300 de sloturi, iar 1 milion de sat la 10 milioane de sat ar putea avea acces la cele 483 de sloturi complete. Acest lucru ar crește semnificativ costul de capital al unui atacator la blocarea sloturilor, deoarece nu ar mai putea consuma toate cele 483 de sloturi cu cea mai mică valoare de plată posibilă. În plus, deoarece ieșirile HTLC sub pragul de praf (în prezent, 546 sat) nici măcar nu pot fi difuzate și aplicate în lanț, orice ieșire sub această limită ar putea fi tratată ca „0 găleată”, deoarece oricum nu este creată nicio ieșire HTLC. Nodurile ar putea pur și simplu impune limite pentru aceste tranzacții pe baza resurselor CPU utilizate sau a altor metrici pentru a preveni ca acestea să devină riscuri de refuzare a serviciului, în funcție de cât de mult își pot permite să piardă dacă nu sunt soluționate cinstit.

Slot bucketing în combinație cu gestionarea HTLC în două etape poate fi utilizată pentru a optimiza aplicarea limitelor HTLC, adică plățile cu valoare mai mare pot folosi structura în două etape pentru a crea mai multe sloturi pentru ele pe canal, deoarece valoarea de plată mai mare crește costul blocarea acestora pentru un atacator, făcând abuzul unei limite mai mari de slot pentru a efectua bruiaj atacatori mai puțin probabil.

În cercetările lor citate mai sus, Riard și Naumenko au arătat că, odată cu combinația optimă a sloturilor de găleat și extensia slotului în două etape, cauza blocării sloturilor poate fi la fel de costisitoare ca și blocarea cantității. Acest lucru nu ar rezolva problema în mod cuprinzător, dar crește costul minim al efectuării atacului dacă este implementat pe scară largă de nodurile din rețea.

Cele două soluții cuprinzătoare pe care le-au analizat sunt o taxă inițială/pentru timp de păstrare pentru blocarea lichidității și un sistem de reputație care utilizează jetoane Chaumian orbite. TLDR-ul schemei de taxe este că o obligațiune pentru o taxă inițială ar fi plătită pentru rutarea unui HTLC care se așteaptă să dureze mult timp pentru a se deconta și, cu cât rămâne mai mult nedecontat, va elibera o taxă pentru fiecare nod de rutare. pe bucată de timp care a trecut fără decontare. Problema este că aplicarea acestui lucru ar putea duce la necesitatea închiderii canalelor dacă taxele nu sunt trimise atunci când este necesar și va determina cazuri de utilizare legitime care necesită timpi lungi de blocare pentru a plăti aceeași taxă mai mare pe care o ar face un atacator care încearcă să bruieze canalul.

Schema de reputație ar implica o „obligație de miză” folosind dovezi fără cunoștințe pentru a dovedi controlul Bitcoin ca apărare Sybil și apoi utilizarea obligațiunii legate de reputația ta pentru a achiziționa jetoane Chaumian orbite de la nodurile de rutare care ar fi răscumpărate și reemise pe HTLC. stabilirea cu succes într-un mod care să păstreze intimitatea. Nodurile ar emite jetoane o dată pe identitate, iar dacă un HTLC nu a fost decontat sau rambursat în timp util, nodurile ar putea refuza să emită din nou jetoanele, împiedicând astfel un utilizator să se deplaseze prin nodul lor, cu excepția cazului în care cheltuie timp și bani pentru a crea un nou simbol. obligațiune de miză cu diferite monede care urmează să fie emise într-un jeton nou.

Pentru cei care doresc să citească mai multe despre aceste două soluții, mai multe informații pot fi găsite în secțiuni cinci și şase în cercetările lui Riard şi Naumenko.

De asemenea, este de remarcat faptul că, dacă nodurile de rutare ar adopta sisteme de escrow bazate pe terțe părți sau linii de credit bazate pe încredere, așa cum am scris despre aici, toate aceste probleme legate de bruiaj de canale ar înceta să le afecteze. Aceasta ar fi o schimbare uriașă în modelul de încredere pentru nodurile de rutare, dar ar avea niciun efect asupra persoanelor care folosesc canale Lightning reale pentru a trimite și primi sat, securitatea fondurilor lor sau capacitatea lor de a le aplica în lanț.

Oamenii s-ar putea să nu vrea să audă, dar la sfârșitul zilei, dacă soluțiile de mai sus pentru atenuarea bruiajului de canale pentru canalele reale nu sunt suficiente, aceste sisteme terțe sunt întotdeauna o opțiune potențială.

Aceasta este o postare pentru oaspeți de Shinobi. Opiniile exprimate sunt în întregime proprii și nu reflectă neapărat cele ale BTC Inc sau Bitcoin Magazine.