Lightning Network är förmodligen den mest efterlängtade tekniska innovationen som kommer att användas 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 transaktioner utanför kedjan bland användare, nästan utan kostnad – samtidigt som den säkerhet som Bitcoin erbjuder erbjuder.

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..

Den första delen av denna serie täckte grundläggande byggstenar och förklarade hur dessa används för att skapa dubbelriktade betalningskanaler. Den andra delen förklarade hur ett nätverk bildas och hur Hash Timelock Contracts (HTLCs) länkar olika kanaler i nätverket. Denna tredje och sista del av serien förklarar hur HTLC: er placeras i dubbelriktade betalningskanaler för att säkerställa att transaktioner kan ske helt utanför kedjan.

Blixtnätverket

Hittills öppnade Alice och Bob en dubbelriktad betalningskanal, som de båda finansierade med fem bitcoins. De har gjort två transaktioner fram och tillbaka, och i nuvarande kanalstatus kan både Alice och Bob kräva fem bitcoins för sig själva genom att “släppa kanalen” på blockchain.

Nu vill de inkludera en HTLC i kanalen. Detta för att säkerställa att om Carol hävdar en bitcoin från Bob i gengäld för sitt värde, är Bob garanterad en bitcoin från Alice i gengäld.

Liksom föregående steg börjar Alice och Bob med att skapa en ny åtagandetransaktion var och en. På många sätt liknar dessa åtagandetransaktioner mycket tidigare transaktioner. De inkluderar en normal utgång och en utgång till en funky multisig-adress med en CSV (CheckSequenceVerify) -timelock och ett speciellt hash-lås. På samma sätt, som i föregående steg, utbyter Alice och Bob sina gamla hemligheter för att effektivt ogiltigförklara den gamla kanalen. Och efter utbyte kan både Alice och Bob underteckna sina halvor av åtagandetransaktionerna och eventuellt släppa dem i blockchain när som helst..

Allt känt territorium. Förutom en förändring. Både Alice och Bobs engagemangstransaktioner inkluderar nu en ny produktion, värt en bitcoin. (Detta gör balansen 4-5-1; fyra för Alice, fem för Bob, en för den nya produktionen.)

Denna nya utgång är i huvudsak HTLC. Och det är ännu roligare än alla andra utgångar hittills, för det finns tre sätt att låsa upp det.

För det första släpper den nya produktionen (i både Alice och Bobs åtagandetransaktioner) bitcoin under förutsättning att Bobs signatur och värdet ingår i den efterföljande transaktionen. Som sådan, oavsett om Alice eller Bob undertecknar och sänder åtagandetransaktionen, är det bara Bob som kan låsa upp denna utdata – om han inkluderar värdet. Men det finns en liten skillnad mellan de två åtagandetransaktionerna: om Bob tappar kanalen är det en CSV-tidlås inblandad. Han kommer att behöva vänta 1000 kvarter. (Om Alice tappar kanalen kan han göra anspråk på denna bitcoin omedelbart.)

Anledningen till att Bob måste vänta 1000 kvarter om han tappar kanalen liknar mycket det vi har sett tidigare: Det gör att Alice kan ta denna bitcoin om Bob någonsin försöker skriva och sända en gammal kanalstatus. Det är där det andra sättet att låsa upp produktionen kommer in. Alice kan “stjäla” pengarna om hon ger Bobs (nyaste) hemlighet. 

Två kan spela det här spelet: Om Alice någonsin försöker fuska och sända den här kanalen när den redan är föråldrad, kan Bob göra anspråk på denna bitcoin med hjälp av Alices hemlighet. (Han skulle inte ens behöva ange värdet.)

Och för det tredje, som med alla andra HTLC, inkluderar båda åtagandetransaktionerna också den vanliga återgången för CLTV-time-out för Alice. Om Bob inte inkluderar värdet i – säg – två veckor (till exempel för att han inte fick det från Carol), kan Alice hämta tillbaka sin bitcoin. Återigen, huruvida Alice eller Bob tappar kanalen spelar ingen roll för det här alternativet.

Så var fick allt detta oss?

Både Alice och Bob har en halvgiltig åtagandetransaktion. Om Alice tappar sin åtagandetransaktion på blockchain skickar hon omedelbart fem bitcoins till Bob. Dessutom kan hon vänta på 1000 block och kräva fyra bitcoins för sig själv. Dessutom har Bob två veckor på sig att ange värdet och göra anspråk på bitcoin i “HTLC-utdata.” (Om han inte tillhandahåller värdet på två veckor kan Alice kräva tillbaka bitcoin.)

Bob kan emellertid när som helst släppa sin åtagandetransaktion och omedelbart skicka fyra bitcoins till Alice. Sedan skulle han ha väntat 1000 block för att kräva ytterligare fem bitcoins från en adress och en annan bitcoin från HTLC-utgången om han anger värdet. (Om han inte ger värdet på två veckor kan Alice återkräva det.)

Och naturligtvis, om antingen Alice eller Bob försöker fuska någon gång i framtiden och underteckna och sända den här kanalen när den är föråldrad, kan båda helt blockera den andra och stjäla alla bitcoins i kanalen.

Betalningskanal

Avgör status

Vid denna tidpunkt är Bob garanterat att få en bitcoin i utbyte mot värdet (förutsatt att han har det). Allt han behöver göra är att underteckna och sända åtagandetransaktionen han fick från Alice, inkludera värdet i en efterföljande transaktion och underteckna och sända det också.

Alice vet det här. Det finns inget sätt hon kan fuska Bob ur sin bitcoin – inte ens om hon fick reda på vad värdet är på något annat sätt.

Som sådan kan de båda lika gärna “slå sig” utanför kanalen. Bob kan helt enkelt ge värdet till Alice, och Alice kan gå med på att uppdatera kanalstatusen till det mer normala tillståndet utan HTLC och tidsgränsen.

Förutsatt att båda parter vill hålla kanalen öppen är det vad de naturligtvis skulle göra: det är mindre krångel än att behöva släppa kanalen i blockchain.

Betalningskanal

Stänger kanalen

Och slutligen, här är Lightning Network: den verkliga kraften: Nästan allt som beskrivs i dessa tre artiklar behöver vanligtvis aldrig slå Bitcoin blockchain alls.

Om både Alice och Bob vill stänga kanalen “fredligt” kan de helt enkelt skapa en transaktion från den ursprungliga öppningstransaktionen för att åsidosätta allt som hände sedan öppningstransaktionen. Från denna avslutande transaktion skickar de sig sin rättvisa andel av kanalen, som representeras av den senaste kanalstaten.

Konkret betyder det att om Alice vill stänga kanalen kan hon just nu skapa en transaktion som betalar fyra bitcoins och Bob sex och ber Bob att underteckna och sända transaktionen. Eftersom det inte finns någon anledning för honom att inte göra det kommer han förmodligen att samarbeta och stänga kanalen.

Till slut kommer bara två transaktioner att sändas över Bitcoin-nätverket och inkluderas i ett block: öppnings- och stängningstransaktionerna. Det kommer att vara sant även om Alice och Bob handlar en miljon gånger däremellan och lossar därför en enorm börda från blockchain.

Betalningskanal

Tack till Rusty Russell och Joseph Poon för information och tillagd feedback.