Lightning Network er trolig den mest etterlengtede teknologiske innovasjonen som vil bli distribuert på toppen av Bitcoin. Betalingslaget, som først ble foreslått av Joseph Poon og Tadge Dryja for rundt et år siden, lover å støtte et praktisk talt ubegrenset antall off-chain-transaksjoner blant brukerne, nesten uten kostnad – samtidig som den utnytter sikkerheten som tilbys av Bitcoin.

Minst tre selskaper – Poon og Dryja’s Lyn, Blockstream og Blockchain – jobber for tiden med implementeringer av teknologien. Men få utenfor denne lille teknologiske frontlinjen forstår fullstendig hvordan “fremtiden for mikrobetalinger” er satt til å øke Bitcoins evner.

I denne tredelte serien legger Bitcoin Magazine ut de grunnleggende byggesteinene i Lightning Network, og viser hvordan de passer sammen for å realisere dette kommende protokolllaget.

Den første delen av denne serien dekket grunnleggende byggesteiner, og forklarte hvordan disse brukes til å etablere toveis betalingskanaler. Den andre delen forklarte hvordan et nettverk dannes, og hvordan Hash Timelock Contracts (HTLC) knytter forskjellige kanaler i nettverket sammen. Denne tredje og siste delen av serien forklarer hvordan HTLC-er plasseres i toveis betalingskanaler for å sikre at transaksjoner kan skje helt utenfor kjeden..

The Lightning Network

Så langt åpnet Alice og Bob en toveis betalingskanal, som de begge finansierte med fem bitcoins. De har gjort to transaksjoner frem og tilbake, og i den nåværende kanaltilstanden kan både Alice og Bob kreve fem bitcoins for seg selv ved å “slippe kanalen” på blockchain.

Nå vil de inkludere en HTLC i kanalen. Dette er for å sikre at hvis Carol hevder en bitcoin fra Bob i retur for sin verdi, er Bob garantert en bitcoin fra Alice i retur.

I likhet med forrige trinn begynner Alice og Bob med å lage en ny forpliktelsestransaksjon hver. På mange måter er disse forpliktelsestransaksjonene veldig like tidligere forpliktelsestransaksjoner. De inkluderer en normal utgang, og en utgang til en funky multisig-adresse med en CSV (CheckSequenceVerify) -timelock og en spesiell hash-lås. På samme måte, som i forrige trinn, utveksler Alice og Bob sine gamle hemmeligheter for effektivt å ugyldiggjøre den gamle kanalen. Og når de er utvekslet, kan både Alice og Bob signere halvdelene av forpliktelsestransaksjonene og potensielt slippe dem på blockchain når som helst..

Alt kjent territorium. Bortsett fra en endring. Både Alice og Bobs forpliktelsestransaksjoner inkluderer nå en ny produksjon, verdt en bitcoin. (Dette gjør saldoen 4-5-1; fire for Alice, fem for Bob, en for den nye produksjonen.)

Denne nye utgangen er egentlig HTLC. Og det er enda morsommere enn alle andre utganger så langt, fordi det er tre måter å låse opp det på.

For det første frigjør den nye produksjonen (i både Alice og Bobs forpliktelsestransaksjoner) bitcoin på betingelse av at Bobs signatur og verdien er inkludert i den påfølgende transaksjonen. Som sådan, uansett om Alice eller Bob signerer og sender forpliktelsestransaksjonen, er det bare Bob som kan låse opp denne utgangen – hvis han inkluderer verdien. Men det er en liten forskjell mellom de to forpliktelsestransaksjonene: Hvis Bob dropper kanalen, er det en CSV-tidssperre involvert. Han må vente 1000 blokker. (Hvis Alice dropper kanalen kan han kreve denne bitcoin umiddelbart.)

Årsaken til at Bob må vente 1000 blokker hvis han dropper kanalen, er veldig lik det vi har sett før: Det lar Alice ta denne bitcoin i tilfelle Bob noen gang prøver å signere og kringkaste en gammel kanaltilstand. Det er der den andre måten å låse opp produksjonen inn. Alice kan “stjele” midlene hvis hun gir Bobs (nyeste) hemmelighet. 

To kan spille dette spillet: Hvis Alice noen gang prøver å jukse og kringkaste denne kanalen når den allerede er utdatert, kan Bob kreve denne bitcoin ved hjelp av Alice’s hemmelighet. (Han trenger ikke engang å oppgi verdien.)

Og for det tredje, som med enhver annen HTLC, inkluderer begge forpliktelsestransaksjoner også den vanlige tilbaketrekningen for CLTV-time-out for Alice. Hvis Bob ikke inkluderer verdien i – si – to uker (for eksempel fordi han ikke fikk den fra Carol), kan Alice kreve bitcoin tilbake. Igjen, om Alice eller Bob dropper kanalen, spiller ingen rolle for dette alternativet.

Så hvor fikk alt dette oss?

Både Alice og Bob har en halvgyldig forpliktelsestransaksjon. Hvis Alice dropper forpliktelsestransaksjonen på blockchain, sender hun umiddelbart fem bitcoins til Bob. I tillegg kan hun vente på 1000 blokker, og kreve fire bitcoins for seg selv. I tillegg har Bob to uker på å oppgi verdien, og kreve bitcoin i “HTLC-utgang.” (Hvis han ikke gir verdien på to uker, kan Alice kreve denne bitcoin tilbake.)

Bob kan i mellomtiden droppe sin forpliktelsestransaksjon når som helst også, og umiddelbart sende fire bitcoins til Alice. Deretter ville han ha ventet 1000 blokker for å kreve fem bitcoins til fra en adresse, og en annen bitcoin fra HTLC-utgangen hvis han oppgir verdien. (Hvis han ikke oppgir verdien på to uker, kan Alice gjenvinne den.)

Og selvfølgelig, hvis Alice eller Bob prøver å jukse når som helst i fremtiden, og signere og kringkaste denne kanalen når den er utdatert, kan begge blokkere den andre og stjele alle bitcoins i kanalen.

Betalingskanal

Å avgjøre statusen

På dette tidspunktet er Bob garantert å motta en bitcoin i bytte for verdien (forutsatt at han har den). Alt han trenger å gjøre er å signere og kringkaste forpliktelsestransaksjonen han fikk fra Alice, inkludere verdien i en påfølgende transaksjon, og signere og kringkaste det også.

Alice vet dette. Det er ingen måte hun kan jukse Bob ut av bitcoin – ikke engang om hun fant ut hva verdien er på andre måter.

Som sådan kan de to like godt “slå seg” utenfor kanalen. Bob kan ganske enkelt gi verdien til Alice, og Alice kan godta å oppdatere kanalstatusen til den mer normale tilstanden uten HTLC og tidsfristen.

Forutsatt at begge parter vil holde kanalen åpen, er det det de ville gjort: det er mindre problemer enn å måtte slippe kanalen på blockchain.

Betalingskanal

Stenger kanalen

Og til slutt, her er den virkelige kraften til Lightning Network: Nesten alt beskrevet i disse tre artiklene trenger vanligvis aldri å treffe Bitcoin blockchain i det hele tatt.

Hvis både Alice og Bob ønsker å stenge kanalen “fredelig”, kan de ganske enkelt opprette en transaksjon fra den opprinnelige åpningstransaksjonen for å overstyre alt som skjedde siden åpningstransaksjonen. Fra denne avsluttende transaksjonen sender de seg sin rettferdige andel av kanalen, som representert av den siste kanalstaten.

Konkret betyr dette at hvis Alice ønsker å stenge kanalen, kan hun på dette tidspunktet bare lage en transaksjon som betaler seg selv fire bitcoins og Bob seks, og be Bob om å signere og kringkaste transaksjonen. Siden det ikke er noen grunn til at han ikke gjør det, vil han sannsynligvis samarbeide og stenge kanalen.

Til slutt vil bare to transaksjoner ha blitt kringkastet over Bitcoin-nettverket og inkludert i en blokk: åpnings- og avsluttende transaksjoner. Det vil gjelde selv om Alice og Bob handler en million ganger i mellom, og derfor laster ut en stor byrde vekk fra blockchain.

Betalingskanal

Takk til Rusty Russell og Joseph Poon for informasjon og tilbakemelding.