Efter år av konceptualisering och utveckling är de första Lightning-implementeringarna nu i betaversion. Som ett resultat visas fler noder online varje dag, ett växande antal användare öppnar kanaler med varandra och vissa handlare började till och med acceptera blixtbetalningar.
Men det är naturligtvis fortfarande de allra första dagarna av Lightning Network. Medan de viktigaste implementeringarna är användbara och vissa plånböcker och andra applikationer är tillgängliga, förväntas Bitcoins överläggsbetalningsnät förbättras under de närmaste åren inom områden som sträcker sig från nätverksarkitektur till säkerhet och användbarhet och mer.
Detta är några av de viktigaste blixtprojekten som för närvarande är under utveckling.
Dubbelfinansierade kanaler
Lightning Network består av en serie betalningskanaler. Varje betalningskanal finns mellan två användare, vilket gör att medel kan skickas fram och tillbaka mellan dem.
I detta tidiga utvecklingsstadium kan dock betalningskanalerna bara finansieras av en av de två parterna. Finansieringspartiet måste först göra en transaktion med sin motpart. först då kan motparten returnera en betalning inom samma betalningskanal.
De Lightning Network vitbok, dock föreslagna dubbelfinansierade kanaler, för vilka a specifikationsförslag har nu också gjorts av ACINQ, företaget bakom eclair. Som namnet antyder kommer dubbelfinansierade kanaler att låta båda användare delvis finansiera en betalningskanal genom att var och en deponera lite bitcoin. Detta bör ge Lightning-användarupplevelsen mer flexibilitet, eftersom användare direkt kan skicka och ta emot betalning efter att ha öppnat en kanal.
Submarine Swaps
För att kunna göra en Lightning-betalning måste användarna sätta in pengar i en Lightning-kanal. En gång i en kanal kan dessa medel inte skickas till vanliga (on-chain) Bitcoin-adresser (såvida inte kanalen först stängs). Det betyder att bitcoin i en blixtkanal är något åtskilt från bitcoin i en vanlig plånbok, inte till skillnad från hur pengar på ett checkkonto skiljs åt från pengar på ett sparkonto.
Men det finns lösningar för att göra växlingen mellan Lightning och on-chain betalningar mer sömlös.
En lösning är Submarine Swaps. Utvecklad av Alex Bosworth (men konceptualiserad av Lightning Labs CTO Olaoluwa Osuntokun till och med före det), Submarine Swaps låter i huvudsak användare skicka Lightning-betalningar till en mellanhand på Lightning Network; den mellanhanden skickar en motsvarande mängd bitcoin till en vanlig (on-chain) Bitcoin-adress. Det fungerar också tvärtom: användare kan skicka regelbundna betalningar via kedjan till mellanhanden; den mellanhanden kommer sedan att skicka en motsvarande mängd bitcoin till en mottagande blixtnod i Lightning Network.
Det är viktigare att med Submarine Swaps görs denna omvandling “atomiskt”. Med hjälp av ett trick som redan är inbäddat i Lightning Network kan Lightning-betalningen och betalningen på kedjan effektivt kopplas till varandra. Detta gör det omöjligt för mellanhanden att stjäla medel genom att inte vidarebefordra betalningen. (I överenskommelse med användarna kunde han ta ut en liten avgift för sin tjänst.)
Skarvning
En annan lösning för att göra Lightning-användarupplevelsen mer sömlös kallas “splitsning”. I grund och botten skulle splitsning låta en användare “fylla på” medel i en befintlig blixtkanal eller “tömma” pengar från den, eventuellt samtidigt som kanalen hålls öppen.
Idén är enkel. Varje blixtkanal börjar med en öppningstransaktion, vilket säkerställer att båda användarna samtycker till att flytta medlen i kanalen. Resten av Lightning-kanalen består av en serie efterföljande transaktioner som utbyts mellan användarna, som vanligtvis inte sänds till Bitcoin-nätverket. Pengarna i öppningstransaktionen rör sig inte förrän kanalen stängs.
När “splitsas in” tar användare öppningstransaktionen för att istället skicka pengar till en ersättningsöppningstransaktion, som inkluderar mer bitcoin, från en eller båda användare. När denna nya öppningstransaktion har bekräftats på blockchain, fylls kanalen på. Tills den nya öppningstransaktionen är bekräftad kan de två användarna helt enkelt uppdatera både den gamla och den nya kanalen samtidigt för att undvika “kanalstopp”.
Omvänt, när de “splitsar ut”, tar användarna inledande transaktion för att skicka pengar till en vanlig (on-chain) adress och eventuellt behålla en del av den i kanalen med samma trick. På så sätt kan användare göra transaktioner direkt från en blixtkanal.
Eltoo
Varje gång en ny betalning görs uppdateras blixtkanaler mellan användare för att återspegla deras ömsesidiga saldon. Tricket som används för att uppnå detta inkluderar för närvarande ett straff för användare som försöker fuska genom att sända en äldre saldo (förmodligen för att den äldre saldot skulle betala dem mer). Fuskanvändare kan förlora alla pengar de har i en kanal.
Problemet är att sändningen av gamla saldor inte alltid är ett fuskförsök. Det finns ett antal scenarier där användare av misstag kan sända en äldre saldo; till exempel på grund av en programvarufel eller en säkerhetskopia som gått fel. I sådana scenarier är en fullständig förlust av kanalmedel ganska tungt straff.
Publicerades först den 30 april 2018, eltoo är det senaste förslaget i den här artikeln. Utvecklat av Blockstream c-blixt utvecklingsteam – Dr. Christian Decker och Rusty Russell – och Lightning Labs Osuntokun, uppdaterar eltoo en kanal genom att bygga en kedja av tidslåsta transaktioner, där varje transaktion spenderar medel från den tidigare för att återspegla den senaste kanalbalansen.
Om en användare sänder en äldre transaktion (som representerar en äldre kanalsaldo) har hennes motpart lite tid att sända den senaste transaktionen (som representerar den senaste kanalsaldot).
En sådan lösning kan fungera idag, men den är inte praktisk i fall av misslyckande. Det skulle kräva att hela transaktionskedjan sänds och spelas in på Bitcoin-blockkedjan, vilket mer eller mindre besegrar syftet med Lightning Network. Decker därför föreslagen en soft-fork ändring av Bitcoin-protokollet för att införa en typ av hierarki i dessa typer av transaktioner: varje nyare transaktion kan åsidosätta alla äldre transaktioner utan att kräva att alla transaktioner i hela kedjan sänds.
Om denna mjuka gaffel antas och aktiveras i Bitcoin-nätverket kan Lightning-användare skapa kanaler i både den aktuella stilen och genom att använda eltoo, beroende på vad de föredrar.
Kompakt blockfiltrering på klientsidan
Medan Lightning Network är ett protokoll i andra lagret, är Bitcoin-blockchain i sig fortfarande relevant för Lightning-användare av säkerhetsskäl. Specifikt måste Lightning-användare hålla koll på blockchain för att se om specifika transaktioner ingår. Detta kan vara resurskrävande, särskilt för mobilanvändare.
En lösning för detta kallas förenklad betalningsverifiering (SPV) och beskrivs i Bitcoin-vitboken. Nuvarande SPV-plånböcker använder ett trick som heter “Bloom-filter”För att ta reda på om några relevanta transaktioner har hänt.
Tyvärr är Bloom-filter ganska integritetsvänliga, eftersom plånböcker i huvudsak avslöjar alla sina adresser till noder i Bitcoin-nätverket. De har också vissa skalnings- och användbarhetsproblem, eftersom varje enskild SPV-plånbok tar upp resurser från minst en fullständig Bitcoin-nod.
För att ta itu med dessa frågor, Lightning Labs ‘Osuntokun och Alex Akselrod, tillsammans med Coinbase utvecklaren Jim Posen, designad en ny lösning som heter “kompakt blockfiltrering på klientsidan”, som de implementerar i Neutrino plånbok.
Kompakt blockfiltrering på klientsidan inverterar i huvudsak det trick som nuvarande SPV-plånböcker använder. I stället för att plånböcker begär transaktioner som är relevanta för dem genom att skapa och skicka ut ett Bloom-filter till fulla noder, skapar fulla noder ett filter för alla Neutrino-plånböcker. Neutrino-plånboken använder sedan detta filter för att fastställa att den relevanta transaktionen inte skedde – vilket verkligen är allt som användare behöver veta för att vara säkra på att de inte luras. (Om filtret producerar en matchning hämtar Neutrino det relevanta blocket för att se om matchningen verkligen gäller den exakta transaktionen istället för en falsk positiv.)
Intressant, även om detta trick designades med Lightning-upplevelsen i åtanke, kunde det också användas för att gynna vanliga ljusplånböcker.
Vakttornen
För att undvika att bli lurad måste Lightning-användare hålla reda på potentiella transaktioner i kedjan som kan vara relevanta för dem.
Medan kompakt blockfiltrering på klientsidan borde göra det mycket enklare, måste användarna “checka in” då och då för att se till att de inte luras. Om de glömmer att kontrollera skapar det en säkerhetsrisk.
“Watchtowers” är en potentiell lösning som kan spåras tillbaka till Lightning Network-vitboken och har varit sedan dess förbättrad av Lightning Network vitbok medförfattare och belyst utvecklaren Tadge Dryja och andra. Som namnet antyder kan Vakttorn låta användare lägga ut blockchain-övervakning till tredje part.
Nuvarande Vakttornsdesigner är inte gjorda i sten utan fungerar ungefär så här. När användare uppdaterar en kanal skickar de ett litet datapaket till en Vakttorn. Den första delen av detta paket är en “ledtråd” till en transaktion de borde se upp för, som om det vore ett pusselbit. Denna antydan ensam avslöjar ingenting om innehållet i transaktionen som Vakttornet måste se upp för; användare ger inte upp någon integritet i denna mening.
Men om den relevanta transaktionen dyker upp i Bitcoin-blockchain kan Vakttornet använda ledtråden för att känna igen den. Sedan, med transaktionsdata på blockchain själv, kan Vakttornet använda den andra delen av paketet de har fått för att rekonstruera strafftransaktionen. Denna strafftransaktion skickar alla medel i kanalen till användaren som luras. (Eller i fallet med eltoo sänder det bara rätt kanalsaldo.) Påföljdstransaktionen kan också utformas för att låta Vakttornet kräva en del av medlen som en belöning, som ett incitament att göra sitt jobb.
Användare kan lägga ut kanalövervakning till flera vakttorn. Även om en misslyckas kanske en annan inte gör det, vilket begränsar risken för blixtanvändare till den punkt där det antagligen är försumbar.
Atomic Multi-Path-betalningar
Vad gör Lightning Network till nätverk är att betalningskanalerna mellan användare är sammankopplade. Användare kan betala över betalningskanaler, via kamrater i nätverket som fungerar som “mellanhänder”, till användare som de inte har en direkt kanal öppen med.
Just nu måste dock en enda betalning dirigeras över en enda rutt. Om en användare vill betala 5 mBTC till en annan, måste han inte bara ha 5 mBTC i en enda kanal, alla mellanhänder på rutten måste också ha 5 mBTC redo i en kanal för att vidarebefordra. Ju större en betalning är, desto mindre är oddsen.
Atomic Multi-Path Payments (AMP) kan gå långt för att lösa denna begränsning. Först föreslogs av Osuntokun och Conner Fromknecht från Lightning Labs, tanken är enkel: Större betalningar kan “klippas upp” i mindre bitar, som alla har sin egen väg från betalaren till betalningsmottagaren, genom olika mellanhänder..
En utmaning att förverkliga denna lösning är att Lightning-betalningar kan misslyckas, vilket i detta fall skulle innebära att en betalning sker delvis. Delbetalningar kan lätt vara ett större problem än ingen betalning alls, dock: en handlare blir inte nöjd med en delbetalning, medan en kund inte kommer att vara glad att spendera några pengar för ingenting.
Lösningen på detta problem är att AMP: er använder en förlängning av de hash-tidslåsta kontrakten, som redan används längs Lightning-rutter och innebär att man skickar hemliga data längs ett nätverk. Med ett trick som liknar det som används av deterministiska plånböcker (som genererar flera Bitcoin-adresser från ett enda frö) kan de mindre delarna av en större betalning endast lösas in av betalningsmottagaren om alla är: om vissa hemliga uppgifter inte gör det klara hela vägen, hela betalningen misslyckas.
Atomic Swaps
Lightning Network är utformat som ett skalningsskikt för Bitcoin. Men eftersom många altcoins är mjukvarugafflar för Bitcoins kodbas, är det ofta inte svårt att skapa liknande skallager för dessa altcoins. Redan finns ett litet Litecoin Lightning Network och fler Lightning Networks kommer sannolikt att följa.
Intressant nog behöver dessa nätverk inte förbli åtskilda i framtiden.
Med hjälp av en grundläggande byggsten i Lightning Network kallad “atombyten” (först föreslagen av Tier Nolan och realiseras på Lightning av Lightning Labs Fromknecht) kan betalningskanaler länkas över olika blockkedjor. Med andra ord kan en användare skicka bitcoin, och så länge en nod i nätverket är villig att utbyta kan en annan användare ta emot betalningen som litecoin.
Naturligtvis betyder det också att användare kan skicka sådana betalningar till sig själva: de kan skicka bitcoin och ta emot litecoin. I själva verket kan Lightning Network skapa ett nätverk av pålitliga kryptovalutautbyten.
För mer information om detta ämne, se: “Atomic Swaps: How the Lightning Network Extensions to Altcoins.”
Kanalfabriker
Den främsta fördelen med Lightning Network är förmodligen dess potential att kraftigt öka den övre gränsen för bitcoin-transaktioner utan att belasta Bitcoin-nätverket. Så länge som två användare båda har pengar i sin kanal kan de betala varandra ett nästan obegränsat antal gånger, medan de bara kräver två transaktioner på kedjan: en för att öppna en betalningskanal och en för att stänga den.
Fortfarande kan två transaktioner per betalningskanal lägga sig om Bitcoin och Lightning Network får mer adoption över tiden.
Ett förslag av ETH Zürich forskarna Christian Decker (även Blockstream), Roger Wattenhofer och Conrad Burchert kallade ”Channel Factories” kan ytterligare minska det genomsnittliga antalet on-chain transaktioner som krävs per betalningskanal, kanske betydligt.
Löst baserat på ett tidigare blixtliknande förslag av Decker och Wattenhofer från 2015 är Channel Factories en typ av betalningskanal som kan finnas bland många användare. Under tiden, som alla betalningskanaler, kräver en Channel Factory bara två transaktioner via kedjan. (Om Schnorr-signaturer implementeras på Bitcoin kan dessa transaktioner vara ganska kompakta, även om det involverar många användare.)
Kanalfabrikerna kan i sin tur fungera som “underkanaler” för Lightning Network. Deltagare inom en kanalfabrik kan öppna och stänga ett praktiskt taget obegränsat antal blixtkanaler med varandra utan att kräva ytterligare transaktioner via kedjan. Genom att göra det skulle de i teorin kunna minska antalet nödvändiga on-chain-transaktioner för Lightning Network med en storlek.
För mer information om detta ämne, se: “Detta nya skalskikt kan göra betalningskanaler tio gånger mer effektiva”.
Tack till Blockstream-utvecklaren Christian Decker, Lightning Labs-utvecklaren Conner Fromknecht, ACINQ VD Pierre-Marie Padiou och andra för information och feedback.