Lightning Network er trolig den mest etterlengtede teknologiske innovasjonen som skal distribueres 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, Bitcoin Magazine legger 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. Denne andre delen forklarer hvordan toveis betalingskanaler blir omgjort til et nettverk.

Nettverket

I den forrige artikkelen opprettet Alice og Bob en toveis betalingskanal. Nå vil Alice betale en bitcoin til en tredje person, Carol.

For å gjøre det kunne Alice og Carol åpne en betalingskanal mellom dem. Men det trenger de faktisk ikke. Som det viser seg har Bob og Carol allerede en felles kanal, så Alice kan ganske enkelt betale Carol gjennom Bob.

Nærmere bestemt kan Alice betale Bob en bitcoin, og Bob kan betale Carol en bitcoin.

Alice stoler imidlertid ikke på Bob – eller Carol for den saks skyld. Hun er redd for at hvis hun betaler Bob, vil Bob faktisk aldri betale Carol. Eller kanskje Bob vil betale Carol, men Carol vil hevde at hun aldri mottok pengene, og Alice ville ikke vite hvem hun skulle skylde på.

Alice vil derfor sørge for at hun bare betaler Bob en bitcoin, hvis han betaler også Carol en bitcoin. Dette oppnås (delvis) med et enkelt kryptografisk triks.

Når Alice ønsker å sende Carol en bitcoin, forteller hun Carol å lage en verdi (en tilfeldig streng med tall) og sende hasjen. Alice ber også Carol om å bytte ut den opprinnelige verdien med Bob mot en bitcoin.

Alice tar i mellomtiden hasjen fra Carol, vender seg til Bob og forteller Bob at hun vil gi ham en bitcoin hvis han gir henne den tilsvarende verdien (som bare Carol har).

Så, Bob henvender seg til Carol, og gir Carol en bitcoin i retur for verdien.

Så snur Bob seg tilbake til Alice med verdien. Alice vet at Bob må ha fått verdien fra Carol i bytte for en bitcoin, og konkluderer derfor med at Carol fikk sin bitcoin. Så Alice kan trygt gi Bob en bitcoin.

Alle er glade.

Vi vil… nesten alle er glade.

I dette “naive” scenariet må mellommann Bob fortsatt stole på Alice og Carol. Bob må stole på Carol for virkelig å gi ham verdien etter at han sendte henne en bitcoin, og Bob må stole på Alice for å virkelig gi ham en bitcoin når han har presentert henne verdien.

Bitcoin-for-verdi-handler må derfor garanteres absolutt langs nettverket. Mer spesifikt: hvis Bob gir en bitcoin til Carol, han må være garantert å få en bitcoin tilbake fra Alice.

Det er der Hash Time-Locked Contracts (HTLCs) kommer inn.

Hash tidslåste kontrakter

Så Alice og Bob vil bytte ut en bitcoin for verdien gjennom en HTLC. (Og Bob og Carol vil også bytte bitcoin for den samme verdien – men husk det foreløpig.)

For å gjøre det, i stedet for å sende Bob en bitcoin rett opp, sender Alice en bitcoin til en ny (og igjen: funky) multisig-adresse. Bitcoins låst på denne adressen kan låses opp på to forskjellige måter.

Det første alternativet er at Bob inkluderer sin signatur og verdien.

Det andre alternativet er at Alice inkluderer sin egen signatur. Dette alternativet har imidlertid en CLTV-tidssperre: Alice kan kun signere og kringkaste transaksjonen etter – si – to uker har gått.

Dette betyr at Bob har to uker på seg til å lage en påfølgende transaksjon der han inkluderer sin signatur og verdien, og kringkaste den for å sende bitcoin fra den funky multisig-adressen til seg selv. Som sådan er denne handelen garantert. Bob kan kun kreve Alice’s bitcoin hvis han gir verdien: å kringkaste den over Bitcoin-nettverket gjør det offentlig synlig for Alice å se.

Og hvis Bob ikke gir verdien i tid, er det et “time-out-alternativ” for Alice å få bitcoin tilbake. Enkel.

Tilbake til nettverket, da det virkelig er dette HTLC-oppsettet er nødvendig.

Som nevnt etablerte ikke bare Alice og Bob, men også Bob og Carol en HTLC. Så, hvis Carol hevder sin bitcoin fra Bob, Bob vil få verdien i retur; det vil være synlig på blockchain.

Derfor, hvis det skjer, Bob får garantert også en bitcoin fra Alice. Bob kan ta verdien som Carol gjorde offentlig synlig på blockchain, inkludere den i sin HTLC med Alice, og kreve en bitcoin for seg selv også. De to kanalene er effektivt koblet sammen.

Som en siste detalj, det er viktig at Bob får verdien fra Carol før Alice kan gjenvinne sin bitcoin fra Bob. Hvis Bob bare får verdien fra Carol etter Alice gjenvunnet allerede ryggen hennes, Bob sitter tross alt fast i midten. Tidsavbruddet i Bob og Carol’s HTLC må derfor utløpe før tidsavbruddet i Alice og Bobs HTLC utløper. (For eksempel etter nøyaktig ti dager, i stedet for to uker. Dette er også grunnen til at HTLC-er trenger CheckLockTimeVerify (CLTV) –og ikke CheckSequenceVerify (CSV).)

Til slutt er det ett problem å løse: for at Lightning Network skal være nyttig, må alt dette gjøres utenfor kjeden. Hvordan dette gjøres, blir dekket i den tredje og siste artikkelen i denne serien.