Facebook
Twitter
Lightning Network är förmodligen den mest efterlängtade tekniska innovationen som ska läggas ut ovanpå Bitcoin. Betalningsskiktet, som först föreslogs av Joseph Poon och Tadge Dryja för ungefär ett år sedan, lovar att stödja ett praktiskt taget obegränsat antal off-chain-transaktioner bland användare, nästan utan kostnad – samtidigt som den säkerhet som erbjuds av Bitcoin utnyttjas.
Minst tre företag – Poon och Dryja’s Blixt, Blockstream och Blockchain – arbetar för närvarande med implementeringar av tekniken. Men få utanför denna lilla tekniska frontlinje förstår fullständigt hur “framtiden för mikrobetalningar” är inställd för att öka Bitcoins kapacitet.
I den här tredelade serien presenterar Bitcoin Magazine de grundläggande byggstenarna i Lightning Network och visar hur de passar ihop för att förverkliga detta kommande protokolllager..
Denna första del av serien fastställer de nödvändiga byggstenarna och visar hur dessa kan kombineras för att skapa ”smarta kontrakt”, som kan användas för att förverkliga Lightning Network: s första krav: en dubbelriktad betalningskanal.
(Obs! Alla med en solid förståelse för Bitcoin kan hoppa över byggstenarna.)
Byggsten 1: Obekräftade transaktioner
Kärnan består Bitcoin-protokollet av transaktioner som vanligtvis är kopplade till tidigare transaktioner och potentiellt till framtida transaktioner. Varje transaktion innehåller ingångar, som hänvisar till adresser som bitcoins skickas från, och utgångar som hänvisar till adresser som bitcoins skickas till. Dessutom måste ingångarna innehålla kraven för att skicka bitcoins, som signaturer som bevisar “ägande” av ingångsadresserna. Utdata fastställer under tiden de nya kraven som måste ingå i ingången för en efterföljande transaktion.
Som en av dess nyckelfunktioner är Lightning Network uppbyggt av mer eller mindre vanliga Bitcoin-transaktioner. Det är bara att dessa transaktioner vanligtvis inte sänds över Bitcoin-nätverket. Istället lagras de lokalt på användarnas noder – men de kan sändas över nätverket när som helst.
Byggsten # 2: Skydd med dubbla utgifter
Det andra byggstenen för Lightning Network kräver förmodligen inte så mycket förklaring, eftersom det förmodligen är raison d’être för Bitcoin själv: dubbel-spendera skydd. Om två transaktioner (eller: ingångar) är beroende av samma utdata kan endast en bekräfta.
Det viktiga att tänka på här är att även obekräftade transaktioner kan vara motstridiga, vilket betyder att endast en någonsin kan bekräfta.
Byggsten # 3: Multisig
Den tredje byggstenen i Lightning Network är också en enkel: multisignatur (multisig) adresser. (Eller mer allmänt: P2SH-adresser.)
Multisig-adresser är Bitcoin-adresser som – som namnet antyder – kräver flera privata nycklar för att “låsa upp” och spendera bitcoins från. Multisig-adresser kan ställas in under alla möjliga förhållanden. Till exempel att kräva två av tre möjliga tangenter, eller femton av femton, eller nästan vilken annan kombination som helst.
Lightning Network använder ofta två av två (2-av-2) multisig-inställningar. För att låsa upp bitcoins från 2-av-2 multisig-adresser krävs två signaturer, från två dedikerade nycklar.
Byggsten # 4: Time-Locks
Den fjärde byggstenen är tidslåset. Tidlås kan “låsa bitcoins upp” i en utgång för att göra dem användbara (för att ingå i en efterföljande ingång) bara någon gång i framtiden.
Det finns två olika typer av tidslås: den absoluta typen, kallad CheckLockTimeVerify (CLTV), och den relativa typen, CheckSequenceVerify (CSV). CLTV låser bitcoins fram till en (mer eller mindre) konkret tid i framtiden: en faktisk tid och ett datum eller en specifik blockhöjd. CSV använder istället relativ tid. När en CVS-utgång har spelats in på blockchain tar det en viss mängd block från den punkten innan bitcoins kan spenderas igen.
Byggsten # 5: Hashvärden och hemligheter
Den femte och sista byggstenen – kryptografi – är den mest grundläggande byggstenen för Bitcoin själv. Men i Lightning Network tillämpas det på ett nytt sätt.
Kort sagt, ett “värde” eller “hemlighet” är en lång och unik talsträng som är praktiskt taget omöjligt att gissa, även för en dator med oändliga försök. Med en speciell beräkning kan detta värde (eller hemlighet) “hashas” i en annan talsträng, en “hash”. Och här är tricket: den som känner till värdet kan enkelt reproducera hashen. Men detta fungerar inte tvärtom; det är en enkelriktad gata.
Detta trick kan användas i Bitcoin själv, igen för att “låsa upp bitcoins.” (I själva verket är det verkligen hur Bitcoin fungerar.) Till exempel kan en hash inkluderas i en utgång och kräver att den efterföljande ingången innehåller motsvarande värde för att kunna spenderas.
Den första utmaningen: dubbelriktade betalningskanaler
Redan innan Lightning Network presenterades hade begreppet betalningskanaler funnits under en tid. Typiska betalningskanaler är användbara för vissa ändamål, men också begränsade: de är enriktade. Alice kan betala Bob flera transaktioner utanför kedjan, men Bob kan inte betala Alice via samma kanal alls.
Som en nyckelfunktion i Lightning Network föreslog Poon och Dryja pålitliga dubbelriktade betalningskanaler.
Öppnar kanalen
För att skapa en dubbelriktad betalningskanal måste båda inblandade parterna först komma överens om en inledande transaktion. Denna öppningstransaktion avgör hur många bitcoins var och en sätter in i kanalen.
Låt oss säga att Alice vill skicka en bitcoin till Bob. Eftersom Alice och Bob förväntar sig att göra transaktioner oftare bestämmer de sig för att öppna en dubbelriktad betalningskanal och använda den för att skicka bitcoin. (Att skicka en hel bitcoin är förmodligen mycket för en betalningskanal, eftersom dessa kan vara mer användbara för mikrobetalningar – men det är helt möjligt.)
För att öppna kanalen skickar Alice och Bob var fem bitcoins till en 2-av-2 multisig-adress. Detta är “öppningstransaktion.” Bitcoins kan bara spenderas från den här adressen om både Alice och Bob undertecknar en efterföljande transaktion.
Dessutom skapar Alice och Bob båda en hemlighet (en rad siffror) och byter hash.
Alice skapar nu omedelbart en efterföljande transaktion från den inledande transaktionen. Detta är en “åtagandetransaktion”. Med åtagandetransaktionen skickar Alice fyra bitcoins till sig själv och sex bitcoins till en andra multisig-adress. Denna andra multisig-adress är lite funky. Det kan låsas upp av Bob på egen hand, men först efter att 1000 extra block har bryts efter att det ingår i blockchain; det inkluderar ett CSV-lås. Eller, det kan öppnas av Alice på egen hand, men bara om hon också inkluderar hemligheten som Bob just nu har gett henne hashen för. (Naturligtvis har Alice ingen aning om vad denna hemlighet är – hon vet bara hash – så det finns inget sätt att hon kan använda det här alternativet just nu.)
Alice undertecknar sitt slut på denna åtagandetransaktion. Men hon sänder inte det! Istället ger hon det till Bob.
Under tiden gör Bob detsamma, men speglas. Han skapar också en åtagandetransaktion, från vilken han skickar sex bitcoins till sig själv och fyra till en funky ny multisig-adress. Alice kan låsa upp denna adress om hon väntar ytterligare 1000 kvarter, eller Bob kan låsa upp den med Alice med hjälp av sin hemlighet.
Bob undertecknar den här halvan och ger den till Alice.
Efter allt detta utbyte av “halvgiltiga” åtagandetransaktioner och hashes av hemligheter, signerar och sänder de båda öppningstransaktionen för att se till att den registreras i blockchain. Kanalen är nu officiellt öppen.
Vid denna tidpunkt kunde både Alice och Bob underteckna och sända den halvgiltiga åtagandetransaktion som de fick från den andra. Om Alice gör det får Bob omedelbart sex bitcoins. Om Bob gör det får Alice omedelbart fyra bitcoins. Men vem som helst som undertecknar och sänder transaktionen måste vänta 1000 block för att låsa upp den efterföljande multisig-adressen och hävda de återstående bitcoinsna.
Men och detta är det viktigaste för en betalningskanal: varken underteckna och sända sin hälft av transaktionen alls.
Uppdaterar kanalen
Lite senare vill Bob skicka tillbaka en bitcoin till Alice. De vill uppdatera kanaltillståndet för att göra balansen fem-fem igen. För att uppnå detta gör Alice och Bob två saker.
Först upprepar båda processen som beskrivs ovan (förutom att öppningstransaktionen redan är registrerad i blockchain; den delen hoppas över). Den här gången tillskriver både Alice och Bob sig fem bitcoins och båda tilldelar fem bitcoins till funky multisig-adresser. Villkoren för dessa multisig-adresser är likartade, förutom att de kräver nya hemligheter: både Alice och Bob ger varandra nya haschar. De undertecknar båda sin nya halvgiltiga åtagandetransaktion och ger den till varandra.
För det andra ger Alice och Bob varandra sina första hemligheter, som de använde i den första inställningen.
Vid denna tidpunkt kunde både Alice och Bob återigen underteckna och sända den nya “halvgiltiga” åtagandetransaktion som de just fick. Deras motpart skulle få fem bitcoins omedelbart, medan sändaren skulle behöva vänta 1000 block. Som sådan uppdateras kanalen.
Men vad hindrar Bob från att sända den äldre åtagandetransaktionen istället? Denna åtagandetransaktion ledde till en väg som betalade honom sex bitcoins istället för fem ….
Vad som hindrar Bob är naturligtvis hans första hemlighet, som han nu har gett Alice.
Bob kan inte säkert signera och sända den äldre åtagandetransaktionen längre, för Alice känner nu till Bobs första hemlighet. Om Bob skulle underteckna och sända den åtagandetransaktionen skulle han omedelbart skicka fyra bitcoins till Alice … och han skulle behöva vänta 1000 block för att hämta sina egna sex bitcoins. Det är ett problem, för nu när Alice känner till hans hemlighet, kan hon använda den här tiden för att slå Bob till punch och hävda de andra sex bitcoins också!
Och eftersom Bob har Alice’s hemlighet också, så är det lika sant för tvärtom. Om Alice försöker skriva och sända en gammal åtagandetransaktion kan Bob stjäla alla bitcoins i kanalen.
Detta betyder naturligtvis att både Alice och Bob är starkt uppmuntrade att spela rättvist, och bara någonsin underteckna och sända kanalens senaste tillstånd.
Därefter måste denna dubbelriktade betalningskanalinställning expanderas för att tillåta betalningar via ett nätverk. Detta behandlas i den andra artikeln i denna serie.
Tack till Rusty Russell och Joseph Poon för extra feedback.