Is kanaalstoring een bedreiging voor het Lightning-netwerk van Bitcoin?

(Speciale dank aan Antoine Riard en Gleb Naumenko, wiens recent onderzoek is de basis van dit artikel.)

Kanaalstoring is een van de grootste problemen van het Lightning Network in termen van dingen die het succes van betalingen die eroverheen worden gerouteerd, kunnen verstoren. Het is een algemeen bekend probleem onder ontwikkelaars dat al werd begrepen sinds het netwerk zelf live ging op het mainnet en zelfs maar een enkele satoshi begon te verwerken.

Tot nu toe heeft het probleem niet echt negatieve effecten gehad op het netwerk, maar als je dat in overweging neemt, is het belangrijk om in gedachten te houden dat het netwerk, in het grote geheel der dingen, nog steeds relatief klein is. Merchant-processors zijn begonnen het te ondersteunen, net als een paar beurzen en veel Lightning/Bitcoin-native services en bedrijven, maar in werkelijkheid is dat niet veel. Het netwerk is nog steeds een klein ding dat voornamelijk wordt gebruikt door Bitcoiners, en dat is helemaal niet een heel groot deel van de wereld.

Bovendien is het aantal Bitcoiners dat regelmatig hun bitcoins uitgeven en gebruiken in commerciële instellingen een nog kleinere subset van die toch al kleine groep. Alleen omdat aanvallen die mogelijk zijn nu niet plaatsvinden, moeten mensen er niet vanuit gaan dat dit betekent dat ze niet zullen plaatsvinden als het netwerk op grotere schaal groeit. Hoe groter het wordt, hoe competitiever en vijandiger het zal worden.

Wat is kanaalstoring?

Het basisconcept van channel jamming is om betalingen via een Lightning-kanaal dat u wilt jammen van uzelf naar uzelf te routeren, en ze vervolgens niet af te ronden door de preimage vrij te geven aan de betalingshash in de gehashte timelock-contracten (HTLC's). Het (de) slachtoffer(s) kunnen de HTLC's pas van hun kanaal verwijderen nadat de tijdslot voor de terugbetaling is verlopen, omdat ze geen manier zouden hebben om hun claim op het geld dat ze verschuldigd zijn af te dwingen als de voorafbeelding werd vrijgegeven nadat deze was verwijderd. Als je een kanaal volledig vastloopt door dit te doen, kan dat kanaal pas betalingen doorsturen nadat de timelock is verlopen voor alle kwaadwillende betalingen.

Er zijn twee verschillende strategieën die hier kunnen worden gebruikt om de aanval uit te voeren. Je kunt proberen de routeerbare hoeveelheid die beschikbaar is in een kanaal te blokkeren, of je kunt proberen alle individuele HTLC-slots in een kanaal te blokkeren. Een Lightning-kanaal kan slechts 483 HTLC's in behandeling hebben in elke richting die het kan routeren - dit komt omdat er een maximale grootte is voor hoe groot een Bitcoin-transactie kan zijn. Als u meer dan 483 HTLC's per richting in het kanaal toevoegt, zou de transactie om het kanaal indien nodig te sluiten te groot en niet geldig zijn om aan het netwerk te onderwerpen. Dit zou alles in het kanaal onafdwingbaar maken in de keten.

Een aanvaller kan dus ofwel proberen alle liquiditeit in een kanaal op te sluiten, of alle HTLC-slots in een kanaal proberen op te sluiten. Beide strategieën zouden het kanaal onbruikbaar maken, maar het vastlopen van slots zal over het algemeen goedkoper zijn dan het vastlopen van hoeveelheden. De aanvaller moet munten op het netwerk hebben om deze aanval uit te voeren, dus het routeren van de minimaal toegestane waarde voor een HTCL met een capaciteit van 483-capaciteit zal kosteneffectiever zijn dan proberen alle beschikbare liquiditeit in het kanaal op te sluiten.

Waarom zou iemand een verlichtingskanaal willen jammen?

Er zijn veel redenen om deze aanval uit te voeren. Ten eerste kan een kwaadwillende entiteit die Bitcoin zelf wil aanvallen, alle belangrijke kanalen in de "kern" van het netwerk blokkeren om het grootste deel van het netwerk onbruikbaar te maken voor het routeren van betalingen, behalve knooppunten die zeer nauw met elkaar verbonden zijn . Dit zou veel meer munten vereisen om op deze schaal te presteren, maar het is niet iets dat als een mogelijkheid moet worden verdisconteerd naarmate Bitcoin groeit en een alternatief wordt voor door de overheid gesanctioneerde geld- en betalingssystemen.

Ten tweede zou een routeringsknooppunt, of handelaar, kunnen proberen de aanval op een concurrent uit te voeren om hen vergoedingen te bezorgen in tegenstelling tot de concurrentie. Een handelaar die vergelijkbare producten verkoopt, kan de kanalen van een concurrent blokkeren om te voorkomen dat klanten daar aankopen doen, in de hoop hen te stimuleren om in plaats daarvan in hun winkel te winkelen. Een routeringsknooppunt met vergelijkbare kanaalconnectiviteit als een ander knooppunt kan de kanalen van het concurrerende routeringsknooppunt blokkeren om ze onbruikbaar te maken voor het routeren van betalingen. Na verloop van tijd zou dit de reputatie van dat knooppunt vernietigen in termen van betrouwbaarheid van routering, en vanwege vergelijkbare connectiviteit, zou het steeds waarschijnlijker worden dat de portemonnee van gebruikers het knooppunt van de aanvaller zou kiezen om betalingen over het netwerk te routeren.

Deze aanvallen kunnen nog kapitaalefficiënter zijn voor de aanvaller als ze meerdere keren circulair door een enkel kanaal lopen. Als ze dicht genoeg bij het slachtoffer op het netwerk staan, kunnen ze een betalingsroute bouwen die ronddraait en blijft gaan via het kanaal van het slachtoffer. Er zijn limieten aan hoe lang een betalingsroute kan zijn, dus dit kan niet oneindig worden gedaan, maar het doen van een lopende betalingsroute als deze kan het aantal munten dat de aanvaller nodig heeft om het kanaal of de kanalen van een slachtoffer volledig te blokkeren, drastisch verminderen.

Aanvallen door kanaalstoringen beperken

Sommige elementaire, gedeeltelijke maatregelen zouden kunnen worden toegepast om de kosten voor aanvallers te verhogen en de schade voor de slachtoffers te beperken. De eerste zou een meertrapsproces zijn voor het omgaan met HTLC's.

Momenteel voegt elke HTLC afzonderlijk een nieuwe uitvoer toe aan de vastleggingstransactie voor de huidige kanaalstatus. Een proces in twee fasen zou een enkele extra output in de toezeggingstransactie kunnen creëren en vervolgens een tweede transactie hebben waaraan de daadwerkelijke HTLC wordt toegevoegd. Dit zou een maximum van 483 mogelijk maken, vermenigvuldigd met 483 HTLC-slots per kanaal (of 233,289 slots). Dit lost echter niets op zichzelf op en zou de tijdsloten moeten verlengen omdat je een extra transactie toevoegt om dingen on-chain af te dwingen, en de aanvaller meer zou kunnen helpen dan het slachtoffer als ze deze nieuwe transactiestructuur en de slachtoffer niet. Het zal echter helpen in combinatie met een andere techniek die even wordt uitgelegd.

De tweede zou een reactieve strategie zijn, waarbij een node die het slachtoffer is geworden van jamming, eenvoudig een nieuw kanaal kan openen voor dezelfde peer als degene die wordt vastgelopen. Dit zou echter extra kapitaal vereisen om dit te doen, het lost niet de alternatieve kosten op van het vastlopen van het andere kanaal en het verlies van inkomsten uit vergoedingen, en het nieuwe kanaal kan vervolgens ook worden vastgelopen als de aanvaller het kapitaal beschikbaar heeft om dit te doen .

De derde techniek zou zijn om HTLC-slots te bucket. Momenteel zijn er 483 slots, en dit is een enkele slotlimiet die universeel wordt toegepast op alle betalingen, ongeacht de waarde van de betaling. Knooppunten kunnen afzonderlijke buckets met kleinere slotlimieten creëren en deze toepassen op betalingen van verschillende waardes, dat wil zeggen, betalingen van 100,000 sats of kleiner kunnen slechts toegang hebben tot 150 slots. Het routeren van betalingen met een kleinere waarde kan dus niet alle beschikbare HTLC-slots verbruiken.

Betalingen van 100,000 sats tot 1 miljoen sats kunnen toegang hebben tot 300 slots, en 1 miljoen sats tot 10 miljoen sats kunnen toegang hebben tot de volledige 483 slots. Dit zou de kapitaalkosten van een aanvaller voor slotjam aanzienlijk verhogen, omdat ze niet langer in staat zouden zijn om alle 483 slots te gebruiken met de laagst mogelijke waardebetaling. Bovendien, omdat HTLC-uitvoer onder de stofdrempel (momenteel 546 sats) niet eens kan worden uitgezonden en afgedwongen in een keten, kan alles onder deze limiet worden behandeld als een "0-bucket" omdat er hoe dan ook geen HTLC-uitvoer wordt gemaakt. Knooppunten kunnen eenvoudig limieten op deze transacties afdwingen op basis van gebruikte CPU-bronnen of andere metrische gegevens om te voorkomen dat ze denial-of-service-risico's worden, afhankelijk van hoeveel ze zich kunnen veroorloven te verliezen als ze niet eerlijk worden afgehandeld.

Slotbucking in combinatie met HTLC-verwerking in twee fasen kan worden gebruikt om de toepassing van HTLC-limieten te optimaliseren, dwz betalingen met een hogere waarde kunnen de structuur in twee fasen gebruiken om meer slots per kanaal te creëren, omdat de hogere betalingswaarde de kosten van jammen voor een aanvaller, waardoor het minder waarschijnlijk wordt dat een hogere slotlimiet wordt misbruikt om aanvallers te jammen.

In hun hierboven aangehaalde onderzoek hebben Riard en Naumenko aangetoond dat met de optimale combinatie van sleufsleuven en tweetraps sleufverlenging, de oorzaak van het vastlopen van de sleuf even duur kan worden gemaakt als het vastlopen van de hoeveelheid. Dit zou het probleem niet volledig oplossen, maar het verhoogt wel de minimale kosten van het uitvoeren van de aanval als het breed wordt geïmplementeerd door knooppunten in het netwerk.

De twee uitgebreide oplossingen die ze hebben bekeken, zijn een vooruitbetaling / vasthoudtijd voor het vastzetten van liquiditeit en een reputatiesysteem dat gebruik maakt van geblindeerde Chaumian-tokens. De TLDR van het vergoedingenschema is dat een obligatie voor een vooruitbetaling zou worden betaald voor het routeren van een HTLC die naar verwachting lang zal duren om af te wikkelen, en hoe langer het onzeker blijft, het zou een vergoeding vrijgeven aan elk routeringsknooppunt per stuk tijd dat is verstreken zonder verrekening. Het probleem is dat het afdwingen hiervan kan leiden tot de noodzaak om kanalen te sluiten als er geen vergoedingen worden verzonden wanneer dat nodig is, en het zal legitieme use-cases veroorzaken die lange vergrendelingstijden vereisen om dezelfde hogere vergoeding te betalen als een aanvaller die probeert kanalen te jammen.

Het reputatieschema zou een "stake bond" inhouden met behulp van zero-knowledge proof om de controle over Bitcoin te bewijzen als een Sybil-verdediging, en vervolgens de band te gebruiken die aan uw reputatie is gekoppeld om geblindeerde Chaumian-tokens van routeringsknooppunten te verwerven die zouden worden ingewisseld en opnieuw uitgegeven op HTLC's succesvol vestigen op een privacy-behoudende manier. Nodes zouden tokens één keer per identiteit uitgeven, en als een HTLC niet tijdig werd afgewikkeld of terugbetaald, zouden nodes kunnen weigeren het token opnieuw uit te geven, waardoor een gebruiker niet door zijn knooppunt kan routeren, tenzij hij de tijd en het geld besteedt aan het maken van een nieuwe obligatie met verschillende munten die in een nieuw token worden uitgegeven.

Voor degenen die meer willen lezen over deze twee oplossingen, meer informatie is te vinden in secties vijf en zes in het onderzoek van Riard en Naumenko.

Het is ook vermeldenswaard dat als routeringsknooppunten escrow-systemen van derden of op vertrouwen gebaseerde kredietlijnen zouden gebruiken, zoals ik schreef over hier, zouden al deze problemen met betrekking tot kanaalstoringen hen niet meer raken. Dit zou een enorme verandering zijn in het vertrouwensmodel voor routeringsknooppunten, maar het zou geen enkel effect hebben op mensen die echte Lightning-kanalen gebruiken om sats te verzenden en te ontvangen, de veiligheid van hun geld of hun vermogen om dat in de keten af ​​te dwingen.

Mensen willen het misschien niet horen, maar aan het eind van de dag, als de bovenstaande oplossingen voor het verminderen van kanaalstoringen voor echte kanalen niet genoeg zijn, zijn deze systemen van derden altijd een mogelijke optie.

Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.