Vi har skrivit om Lightning Network tidigare och det blir mycket prat om kanaler hit och dit och hur man kanske inte har någon “kapacitet" för att ta emot betalningar i början och måste lösa detta på andra vis etc. Vi har testat nån metafor med en kulram men troligtvis är det ändå svårt att få en överblick över vad som händer i nätverket. Det här är ett försök att förklara Lightning Network med enkla bilder.
Ovan visas ett enkelt nätverk. Det som är blått är det vi brukar kalla kanaler, så du kan tänka på det som tuber som pengarna (bitcoin) åker runt i eller kanske som faktiska kanaler där pengarna är små båtar, välj vad som känns enklast för dig. Vi kommer att låta en liten cirkel representera en satoshi, den minsta enheten av bitcoin. I verkligheten skulle det förstås vara betydligt fler satoshis i kanalerna än i vårt lilla exempel. Den första principen som är viktig att förstå är satoshis inte kan hoppa från en kanal till en annan, de är fast i den kanal där de finns (tills kanalen stängs). Låt oss nu först titta på det superenkla fallet där A vill skicka 1 satoshi till B.
Simpelt alltså, en satoshi flyttas helt enkelt från A:s sida till B:s sida av kanalen. Om A och B nu skulle bestämma för att stänga kanalen så skulle 2 satoshis tillfalla A och 1 satoshi tillfalla B. Det är den här fördelningen av de 3 satoshis som kanalen totalt innehåller som är kanalens tillstånd eller "state" och där har vi bland annat skrivit om hur A kanske skulle vilja försöka stänga kanalen utifrån det tidigare tillståndet där 3 satoshis finns på A:s sida och hur watchtowers är ett sätt att skydda B så att det inte kan hända.
Låt oss nu istället säga att A vill skicka 2 satoshis till C. Då skulle det se ut såhär:
Notera hur B här agerar mellanhand. När transaktionen är klar så äger B precis som innan 4 satoshis men med den skillnaden att 2 av dem finns i kanalen med A istället för i kanalen med C. Det viktiga för B här är förstås att hen kan vara säker på att båda kanaluppdateringarna faktiskt sker så att B inte råkar skicka iväg sina 2 satoshis till C och sedan aldrig får något från A. Lösningen av detta är en av nyckeluppfinningarna i Lightning Network och kallas för Hashed Timelocked Contracts, något som vi kort går igenom på den här sidan. Det säkerställer både att B inte riskerar något genom att agera mellanhand men också att A kan vara säker på att B inte behåller några av pengarna. Att Lightning Network använder mellanhänder på det här sättet är alltså inte alls samma sak som att t.ex. förvara sina bitcoin hos en tredje part som du behöver lita på.
Tänk nu att A istället vill skicka sina satoshis till I, kan vi då bara förlänga kedjan från C via F? Tyvärr går det inte det eftersom C inte har något sätt att skicka 2 satoshis till F (C har ju bara 1 satoshi på sin sida). Däremot så funkar det om A istället skickar via D och H, såhär:
Att få pengarna att hitta en framkomlig väg genom nätverket kallas för routning och är en annan av utmaningarna i Lightning Network. Det ser ju enkelt ut i fallet ovan men i verkligheten kanske nätverket består av miljontals noder och kanaler, som dessutom hela tiden ändras. I nuläget används något som kallas "source routing" där det är den som skickar som själv hittar en lämplig väg fram till mottagaren men även andra idéer håller på att utforskas.
Nu ska vi titta på en situation där en ny aktör vill in och vara med, nämligen G. Att skapa en kanal med en annan nod är inga problem så länge man själv är beredd att stoppa in pengarna i den. Alltså kan G här t.ex. sätta upp en kanal med D och det ser då ut såhär:
Sådär, bara för G att sätta igång och skicka betalningar. Men vad händer om G vill ta emot betalningar? Hur många kanaler G än öppnar på det här sättet kommer ingen att kunna skicka pengar till G över Lightning Network. Det var det här problemet vi skrev om när vi testade Bitrefills tjänst Thor. Där kan man betala Bitrefill (t.ex. med en vanlig Bitcointransaktion) för att istället få dem att öppna en kanal till dig.
Nu har G möjlighet att ta emot betalningar! Problemet med den här lösningen är att vi har blandat in en tredjepart som G måste lita på. Efter att ha betalat Bitrefill för tjänsten får G helt enkelt lita på att de håller sitt löfte om att stoppa in pengar i en kanal. Det finns dock fler uppfinningar som kan lösa detta och liknande problem, Lightning Labs har skapat något de kallar för loop som åstadkommer ungefär samma sak men utan att det krävs tillit till en tredjepart. Loop kan användas antingen för att flytta pengar till "din sida" (Loop In) eller för att flytta pengar till "andra sidan" (Loop Out) av en redan existerande kanal. Detta gör man genom att kombinera en Lightningtransaktion med en vanlig "on chain"-bitcointransaktion i något som kallas för submarine swaps. Det häftiga här är att en sådan swap garanterar att både onchain- och Lightningtransaktionen kommer att ske (eller att ingen av dem sker). Precis som med vanliga Lightningtransaktioner finns här alltså ingen möjlighet att luras.
I figurerna nedan kan du se varför det kallas för "Loop", vilket alltså i princip innebär att G skickar pengar till sig själv, i ena fallet ut från Lightningnätveket och i det andra fallet in i Lightningnätverket. De lila rutorna representerar en vanlig Bitcoinplånbok, som alltså finns utanför Lightningnätverket.
I framtiden kan man tänka sig att alla dessa tricks integreras snyggt i plånböcker som stödjer båda klassiska bitcointransaktioner och Lightning Network så att användaren knappt behöver veta vilket som är vilket och aldrig behöver tänka på att fylla på sin kanalar eller liknande. Lightning Labs mobilplånbok som nyligen släppts i testversion till både Android och iOS har kommit en bit på vägen.
Kommentarer