Lightning Network er sandsynligvis den mest forventede teknologiske innovation, der vil blive implementeret oven på Bitcoin. Betalingslaget, der først blev foreslået af Joseph Poon og Tadge Dryja for ca. et år siden, lover at støtte et næsten ubegrænset antal off-chain-transaktioner blandt brugerne næsten uden omkostninger – samtidig med at den sikkerhed, der tilbydes af Bitcoin, udnyttes.

Mindst tre virksomheder – Poon og Dryja’s Lyn, Blockstream og Blockchain – arbejder i øjeblikket med implementeringer af teknologien. Men få uden for denne lille teknologiske frontlinje forstår fuldt ud, hvordan “mikropayments-fremtiden” er indstillet til at øge Bitcoins muligheder.

I denne tredelte serie lægger Bitcoin Magazine de grundlæggende byggesten i Lightning Network ud og viser, hvordan de passer sammen for at realisere dette kommende protokollag.

Den første del af denne serie dækkede grundlæggende byggesten og forklarede, hvordan disse bruges til at etablere tovejs betalingskanaler. Den anden del forklarede, hvordan et netværk dannes, og hvordan Hash Timelock-kontrakter (HTLC’er) forbinder forskellige kanaler i netværket. Denne tredje og sidste del af serien forklarer, hvordan HTLC’er placeres inden i tovejs betalingskanaler for at sikre, at transaktioner kan forekomme helt uden for kæden.

The Lightning Network

Indtil videre åbnede Alice og Bob en tovejs betalingskanal, som de begge finansierede med fem bitcoins. De har foretaget to transaktioner frem og tilbage, og i den aktuelle kanaltilstand kan både Alice og Bob kræve fem bitcoins for sig selv ved at “droppe kanalen” på blockchain.

Nu vil de medtage en HTLC i kanalen. Dette er for at sikre, at hvis Carol hævder en bitcoin fra Bob til gengæld for sin værdi, er Bob garanteret en bitcoin fra Alice til gengæld.

Ligesom det forrige trin starter Alice og Bob med at oprette en ny forpligtelsestransaktion hver. På mange måder svarer disse forpligtelsestransaktioner meget til tidligere forpligtelsestransaktioner. De inkluderer en normal output og en output til en funky multisig-adresse med en CSV (CheckSequenceVerify) -timelock og en speciel hash-lås. På samme måde som i det forrige trin udveksler Alice og Bob deres gamle hemmeligheder for effektivt at ugyldiggøre den gamle kanal. Og når de er udvekslet, kan både Alice og Bob underskrive deres halvdele af forpligtelsestransaktionerne og potentielt droppe dem på blockchain når som helst.

Alt velkendt område. Bortset fra en ændring. Både Alice og Bobs forpligtelsestransaktioner inkluderer nu en ny output til en bitcoin-værdi. (Dette gør balancen 4-5-1; fire for Alice, fem for Bob, en for den nye output.)

Denne nye output er i det væsentlige HTLC. Og det er endnu sjovere end alle andre output hidtil, fordi der er tre måder at låse det op på.

For det første frigiver den nye output (i både Alice og Bobs forpligtelsestransaktioner) bitcoin på betingelse af, at Bobs signatur og værdien er inkluderet i den efterfølgende transaktion. Som sådan, uanset om Alice eller Bob underskriver og sender forpligtelsestransaktionen, er det kun Bob, der kan låse op for denne output – hvis han inkluderer værdien. Men der er en lille forskel mellem de to forpligtelsestransaktioner: Hvis Bob taber kanalen, er der en CSV-timelock involveret. Han bliver nødt til at vente 1.000 blokke. (Hvis Alice taber kanalen, kan han straks kræve denne bitcoin.)

Årsagen til, at Bob skal vente 1.000 blokke, hvis han taber kanalen, ligner meget det, vi har set før: Det giver Alice mulighed for at tage denne bitcoin, hvis Bob nogensinde prøver at underskrive og udsende en gammel kanaltilstand. Det er her, den anden måde at låse output op på. Alice kan “stjæle” pengene, hvis hun giver Bobs (nyeste) hemmelighed. 

To kan spille dette spil: Hvis Alice nogensinde prøver at snyde og udsende denne kanal, når den allerede er forældet, kan Bob hævde denne bitcoin ved hjælp af Alice’s hemmelighed. (Han behøvede ikke engang at give værdien.)

Og for det tredje, som med enhver anden HTLC, inkluderer begge forpligtelsestransaktioner også den sædvanlige tilbagevenden til CLTV-timeout for Alice. Hvis Bob ikke inkluderer værdien i – siger – to uger (for eksempel fordi han ikke fik den fra Carol), kan Alice kræve sin bitcoin tilbage. Igen, om Alice eller Bob taber kanalen, betyder ikke noget for denne mulighed.

Så hvor fik alt dette os?

Både Alice og Bob har en halvgyldig forpligtelsestransaktion. Hvis Alice dropper sin forpligtelsestransaktion på blockchain, sender hun straks fem bitcoins til Bob. Derudover kan hun vente på 1.000 blokke og kræve fire bitcoins til sig selv. Plus, Bob har to uger til at give værdien og kræve bitcoin i “HTLC-output.” (Hvis han ikke giver værdien om to uger, kan Alice kræve denne bitcoin tilbage.)

I mellemtiden kan Bob også til enhver tid droppe sin forpligtelsestransaktion og straks sende fire bitcoins til Alice. Derefter ville han have ventet 1.000 blokke for at kræve yderligere fem bitcoins fra en adresse og en anden bitcoin fra HTLC-output, hvis han angiver værdien. (Hvis han ikke giver værdien om to uger, kan Alice genvinde den.)

Og selvfølgelig, hvis enten Alice eller Bob prøver at snyde på et hvilket som helst tidspunkt i fremtiden og underskrive og udsende denne kanal, når den er forældet, kan begge helt blokere den anden og stjæle alle bitcoins i kanalen.

Betalingskanal

Afregning af status

På dette tidspunkt er Bob garanteret at modtage en bitcoin i bytte for værdien (forudsat at han har den). Alt hvad han skal gøre er at underskrive og udsende den forpligtelsestransaktion, han fik fra Alice, inkludere værdien i en efterfølgende transaktion og også underskrive og udsende det.

Alice ved dette. Der er ingen måde, hun kan snyde Bob ud af sin bitcoin – ikke engang hvis hun fandt ud af, hvad værdien er på anden måde.

Som sådan kan de to lige så godt bare “slå sig ned” uden for kanalen. Bob kan simpelthen give værdien til Alice, og Alice kan acceptere at opdatere kanalstatus til den mere normale tilstand uden HTLC og timeout-deadline.

Under forudsætning af at begge parter vil holde kanalen åben, er det, hvad de naturligvis ville gøre: det er mindre besvær end at skulle droppe kanalen på blockchain.

Betalingskanal

Lukning af kanalen

Og endelig er her den reelle kraft i Lightning Network: Næsten alt det, der er beskrevet i disse tre artikler, behøver typisk aldrig at ramme Bitcoin-blockchain overhovedet.

Hvis både Alice og Bob vil lukke kanalen “fredeligt”, kan de blot oprette en transaktion fra den oprindelige åbningstransaktion for at tilsidesætte alt, hvad der skete siden åbningstransaktionen. Fra denne afsluttende transaktion sender de sig deres retfærdige andel af kanalen, som repræsenteret af den seneste kanalstat.

Konkret betyder det, at hvis Alice ønsker at lukke kanalen, kan hun på dette tidspunkt simpelthen oprette en transaktion, der betaler sig selv fire bitcoins og Bob seks, og bede Bob om at underskrive og udsende transaktionen. Da der ikke er nogen grund til, at han ikke gør det, vil han sandsynligvis samarbejde og lukke kanalen.

I sidste ende vil kun to transaktioner være sendt over Bitcoin-netværket og inkluderet i en blok: åbnings- og lukningstransaktionerne. Det vil være tilfældet, selvom Alice og Bob handler en million gange imellem og derfor aflæsser en enorm byrde væk fra blockchain.

Betalingskanal

Tak til Rusty Russell og Joseph Poon for information og tilføjet feedback.