Er Channel Jamming en trussel mot Bitcoins Lightning Network?

(Spesiell takk til Antoine Riard og Gleb Naumenko, hvis nyere forskning er grunnlaget for denne artikkelen.)

Kanaljamming er et av de utestående problemene til Lightning Network når det gjelder ting som kan forstyrre suksessen til betalinger rutet over det. Det er et allment kjent problem blant utviklere som har vært forstått siden før selve nettverket faktisk gikk live på mainnet og begynte å behandle til og med en enkelt satoshi.

Så langt har ikke problemet egentlig hatt noen negative effekter på nettverket, men når man vurderer det faktum, er det viktig å huske på at nettverket fortsatt er relativt lite i det store og hele. Salgprosessorer har begynt å støtte det, det samme har noen få børser og mange innfødte Lightning/Bitcoin-tjenester og virksomheter, men i virkeligheten er det ikke mye. Nettverket er fortsatt en liten ting som hovedsakelig brukes av Bitcoiners, og det er ikke en veldig stor del av verden i det hele tatt.

Enda videre er mengden bitcoinere som regelmessig bruker og bruker bitcoin i handelsinnstillinger en enda mindre delmengde av den allerede lille gruppen. Bare fordi angrep som er mulig ikke skjer nå, bør folk ikke anta at det betyr at de vil fortsette å ikke forekomme når nettverket vokser til en større skala. Jo større det blir, jo mer konkurransedyktig og motstandsdyktig vil det bli.

Hva er Channel Jamming?

Det grunnleggende konseptet med kanaljamming er å rute betalinger gjennom en Lightning-kanal du ønsker å jamme fra deg selv til deg selv, og deretter ikke fullføre dem ved å frigi forhåndsbildet til betalingshashen i hashed timelock-kontrakter (HTLC-er). Offeret(e) vil ikke kunne fjerne HTLC-ene fra kanalen sin før etter at tidslåsen for refusjonen har utløpt, fordi de ikke ville ha noen måte å håndheve kravet på penger de skylder hvis forhåndsbildet ble utgitt etter at det ble fjernet. Hvis du blokkerer en kanal fullstendig ved å gjøre dette, vil den kanalen ikke være i stand til å dirigere noen betalinger før etter at tidslåsen utløper for alle ondsinnede betalinger.

Det er to forskjellige strategier som kan brukes her for å utføre angrepet. Du kan enten prøve å blokkere det rutebare beløpet som er tilgjengelig i en kanal, eller du kan prøve å blokkere alle de individuelle HTLC-sporene i en kanal. En Lightning-kanal kan bare ha 483 ventende HTLC-er i hver retning den kan rute - dette er fordi det er en maksimal størrelsesgrense for hvor stor en Bitcoin-transaksjon kan være. Hvis du legger til mer enn 483 HTLC-er per retning i kanalen, vil transaksjonen for å lukke kanalen om nødvendig være for stor og ikke gyldig til å sendes til nettverket. Dette vil gjøre alt i kanalen uhåndhevelig på kjeden.

Så en angriper kan enten prøve å låse opp all likviditeten i en kanal, eller prøve å låse opp alle HTLC-sporene i en kanal. Begge strategier vil gjøre kanalen ubrukelig, men slotjamming vil generelt være billigere enn mengdejamming. Angriperen må ha mynter på nettverket for å kunne utføre dette angrepet, så å dirigere minimumsverdien for en HTCL med 483 kapasitet vil være mer kostnadseffektiv enn å prøve å låse opp all likviditeten som er tilgjengelig i kanalen.

Hvorfor skulle noen ønske å jamme en lyskanal?

Det er mange grunner til å utføre dette angrepet. For det første kan en ondsinnet enhet som ønsker å angripe Bitcoin selv blokkere alle nøkkelkanalene i "kjernen" av nettverket for å gjøre det meste av nettverket ubrukelig for å dirigere betalinger, bortsett fra noder som er veldig nært knyttet til hverandre . Dette vil kreve mye flere mynter for å prestere i denne skalaen, men er ikke noe som bør diskonteres som en mulighet med jo mer Bitcoin vokser og blir et alternativ til statlig sanksjonerte penge- og betalingssystemer.

For det andre kan en rutingnode, eller kjøpmann, forsøke å utføre angrepet på en konkurrent for å drive avgifter til dem i motsetning til konkurrentene. En kjøpmann som selger lignende produkter kan blokkere kanalene til en konkurrent for å hindre kunder i å foreta kjøp der, i håp om å motivere dem til å handle i butikken deres i stedet. En rutingnode som har lignende kanaltilkobling som en annen node kan blokkere den konkurrerende rutingnodens kanaler for å gjøre dem ubrukelige for ruting av betalinger. Over tid vil dette ødelegge den nodens omdømme når det gjelder rutingpålitelighet, og på grunn av lignende tilkobling, gjøre det mer og mer sannsynlig at brukernes lommebøker vil velge angriperens node for å rute betalinger over nettverket.

Disse angrepene kan være enda mer kapitaleffektive for angriperen hvis de går sirkulært gjennom en enkelt kanal flere ganger. Hvis de er nær nok offeret på nettverket, kan de konstruere en betalingsrute som går rundt og fortsetter å gå gjennom offerets kanal. Det er grenser for hvor lang en betalingsrute kan være, så dette kan ikke gjøres uendelig, men å gjøre en betalingsrute som denne kan drastisk redusere mengden mynter angriperen trenger for å blokkere et offers kanal(er).

Reduserende kanaljammingangrep

Noen grunnleggende, delvise avbøtende tiltak kan brukes for å øke kostnadene for angripere og redusere skadene for ofrene. Den første ville være en flertrinnsprosess for håndtering av HTLC-er.

For øyeblikket legger hver HTLC individuelt til en ny utgang i forpliktelsestransaksjonen for gjeldende kanaltilstand. En to-trinns prosess kan skape en enkelt ekstra utgang i forpliktelsestransaksjonen, og deretter ha en andre transaksjon etter den som har den faktiske HTLC lagt til seg. Dette vil tillate maksimalt 483 multiplisert med 483 HTLC-spor per kanal (eller 233,289 XNUMX spor). Dette løser imidlertid ikke noe i seg selv, og vil kreve å utvide tidslåsene fordi du legger til en ekstra transaksjon for å håndheve ting på kjeden, og faktisk kan hjelpe angriperen mer enn offeret hvis de brukte denne nye transaksjonsstrukturen og offer gjorde det ikke. Det vil imidlertid hjelpe i kombinasjon med en annen teknikk forklart et øyeblikk.

Den andre ville være en reaktiv strategi, der en node som har blitt offer for jamming ganske enkelt kan åpne en ny kanal til samme peer som den som blir jamming. Dette vil imidlertid kreve å ha ekstra kapital for å gjøre det, og fikser ikke alternativkostnaden ved å ha den andre kanalen fastkjørt og tape gebyrinntekter, og den nye kanalen kan også bli blokkert i etterkant hvis angriperen har kapitalen tilgjengelig for å gjøre det. .

Den tredje teknikken ville være å bøtte HTLC-spor. For øyeblikket er det 483 spilleautomater, og dette er en enkelt spilleautomatgrense som brukes universelt for alle betalinger uavhengig av verdien på betalingen. Noder kan lage separate bøtter med mindre sporgrenser og bruke dem på betalinger med forskjellige verdier, dvs. betalinger på 100,000 150 sats eller mindre kan bare ha tilgang til XNUMX spor. Så, ruting av betalinger av mindre verdi kan ikke konsumere alle de tilgjengelige HTLC-sporene.

Betalinger på 100,000 1 sats til 300 million sats kan ha tilgang til 1 plasser, og 10 million sats til 483 millioner sats kan ha tilgang til hele 483 plasser. Dette vil øke kapitalkostnaden betydelig for en angriper til slot jam, ettersom de ikke lenger vil være i stand til å konsumere alle 546 slots med minst mulig verdibetaling. I tillegg, fordi HTLC-utganger under støvterskelen (for øyeblikket 0 sats) ikke engang kan kringkastes og håndheves på kjede, kan alt under denne grensen håndteres som en "XNUMX-bøtte" siden ingen HTLC-utgang opprettes uansett. Noder kan ganske enkelt håndheve grenser for disse transaksjonene basert på CPU-ressurser som brukes eller andre beregninger for å forhindre at de blir risikoen for tjenestenekt, avhengig av hvor mye de har råd til å tape hvis de ikke avgjøres ærlig.

Slot bucketing i kombinasjon med to-trinns HTLC-håndtering kan brukes til å optimalisere anvendelsen av HTLC-grenser, dvs. betalinger med høyere verdi kan bruke totrinnsstrukturen til å lage flere slots for dem per kanal fordi den høyere betalingsverdien øker kostnadene for jamming dem for en angriper, noe som gjør misbruk av en høyere sporgrense for å utføre jamming angripere mindre sannsynlig.

I sin forskning sitert ovenfor, har Riard og Naumenko vist at med den optimale kombinasjonen av bøttespor og to-trinns spalteforlengelse, kan årsaken til spaltestopp gjøres like dyr som mengden fastkjøring. Dette vil ikke løse problemet fullstendig, men det øker minimumskostnadene ved å utføre angrepet hvis det implementeres bredt av noder på tvers av nettverket.

De to omfattende løsningene de har sett på er et forhånds-/holdtidsgebyr for å låse opp likviditet, og et omdømmesystem som bruker blindede Chaumian-tokens. TLDR for gebyrordningen er at en obligasjon for et forhåndsgebyr vil bli betalt for ruting av en HTLC som forventes å ta lang tid å avgjøre, og jo lenger den forblir uoppgjort, vil den frigjøre et gebyr til hver rutingnode per stykke tid som har gått uten oppgjør. Problemet er at å håndheve dette kan føre til behovet for å stenge kanaler hvis avgifter ikke sendes når det kreves, og det vil føre til at legitime brukstilfeller som krever lange låsetider betaler samme høyere avgift som en angriper som forsøker kanaljamming ville.

Omdømmeordningen vil innebære en "innsatsobligasjon" ved å bruke nullkunnskapsbevis for å bevise kontroll over Bitcoin som et Sybil-forsvar, og deretter bruke obligasjonen knyttet til ditt rykte for å skaffe blindede Chaumian-tokens fra rutingnoder som vil bli innløst og utstedt på nytt på HTLC-er med hell på en personvernbevarende måte. Noder vil utstede tokens én gang per identitet, og hvis en HTLC ikke ble avgjort eller refundert i tide, kunne noder nekte å utstede tokenet på nytt, og dermed forhindre en bruker fra å rute gjennom noden sin med mindre de bruker tid og penger på å lage en ny innsatsobligasjon med forskjellige mynter som skal utstedes i en ny token.

For de som ønsker å lese mer om disse to løsningene, finnes mer informasjon i avsnitt fem og seks i Riards og Naumenkos forskning.

Det er også verdt å merke seg at hvis rutingnoder skulle ta i bruk tredjepartsbaserte deponeringssystemer eller tillitsbaserte kredittlinjer, som jeg skrev om her., vil alle disse problemene knyttet til kanalstopp slutte å påvirke dem. Dette ville være en enorm endring i tillitsmodellen for ruting av noder, men det ville ha null effekt på folk som bruker ekte Lightning-kanaler for å sende og motta sats, sikkerheten til deres midler eller deres evne til å håndheve det på kjeden.

Folk vil kanskje ikke høre det, men på slutten av dagen, hvis løsningene ovenfor for å redusere kanalstopp for faktiske kanaler ikke er nok, er disse tredjepartssystemene alltid et potensielt alternativ.

Dette er et gjesteinnlegg av Shinobi. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc eller Bitcoin Magazine.