Lightning Network er sandsynligvis den mest forventede teknologiske innovation, der skal implementeres 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, Bitcoin Magazine beskriver de grundlæggende byggesten i Lightning Network 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. Denne anden del forklarer, hvordan tovejs betalingskanaler omdannes til et netværk.

Netværket

I den forrige artikel oprettede Alice og Bob en tovejs betalingskanal. Nu vil Alice betale en bitcoin til en tredje person, Carol.

For at gøre det kunne Alice og Carol åbne en betalingskanal mellem dem. Men det har de faktisk ikke brug for. Som det viser sig, har Bob og Carol allerede en fælles kanal, så Alice kan simpelthen betale Carol gennem Bob.

Specifikt kan Alice betale Bob en bitcoin, og Bob kan betale Carol en bitcoin.

Alice stoler dog ikke rigtig på Bob – eller Carol for den sags skyld. Hun er bange for, at hvis hun betaler Bob, vil Bob faktisk aldrig betale Carol. Eller måske Bob vilje betale Carol, men Carol vil hævde, at hun aldrig har modtaget pengene, og Alice ville ikke vide, hvem hun skulle bebrejde.

Alice vil derfor sikre, at hun kun betaler Bob en bitcoin, hvis han betaler også Carol en bitcoin. Dette opnås (delvist) med et simpelt kryptografisk trick.

Når Alice ønsker at sende Carol en bitcoin, beder hun Carol om at oprette en værdi (en tilfældig række af numre) og sende hashen til hende. Alice beder også Carol om at bytte den oprindelige værdi med Bob for en bitcoin.

Alice tager i mellemtiden hashen fra Carol, vender sig til Bob og fortæller Bob, at hun vil give ham en bitcoin, hvis han giver hende den tilsvarende værdi (som kun Carol har).

Så Bob henvender sig til Carol og giver Carol en bitcoin til gengæld for værdien.

Derefter vender Bob tilbage til Alice med værdien. Alice ved, at Bob må have fået værdien fra Carol i bytte for en bitcoin, og derfor konkluderer, at Carol fik sin bitcoin. Så Alice kan med sikkerhed give Bob en bitcoin.

Alle er glade.

Godt… næsten alle er glade.

I dette “naive” scenario skal mellemmand Bob stadig stole på Alice og Carol. Bob må stole på Carol for virkelig at give ham værdien, efter at han sendte hende en bitcoin, og Bob må stole på Alice for virkelig at give ham en bitcoin, når han først præsenterer hende for værdien.

Bitcoin-for-værdi-handlerne skal derfor garanteres absolut langs netværket. Mere specifikt: hvis Bob giver en bitcoin til Carol, han skal være garanteret at få en bitcoin tilbage fra Alice.

Det er her, Hash-låste kontrakter (HTLC’er) kommer ind.

Hash tidslåste kontrakter

Så Alice og Bob vil bytte en bitcoin til værdien gennem en HTLC. (Og Bob og Carol vil også bytte bitcoin til den samme værdi – men husk det lige nu.)

For at gøre det, i stedet for at sende Bob en bitcoin lige op, sender Alice en bitcoin til en ny (og igen: funky) multisig-adresse. Bitcoins låst på denne adresse kan låses op på to forskellige måder.

Den første mulighed er, at Bob inkluderer sin underskrift og værdien.

Den anden mulighed er, at Alice inkluderer hendes egen signatur. Denne mulighed har dog en CLTV-tidslås på det: Alice kan kun underskrive og udsende transaktionen efter – siger – to uger er gået.

Dette betyder, at Bob har to uger til at oprette en efterfølgende transaktion, hvor han inkluderer sin signatur og værdien, og sender den til at sende bitcoin fra den funky multisig-adresse til sig selv. Som sådan er denne handel garanteret. Bob kan kun hævde Alice’s bitcoin, hvis han giver værdien: udsendelse af den over Bitcoin-netværket gør det offentligt synligt for Alice at se.

Og hvis Bob ikke giver værdien i tide, er der et “time-out-alternativ” for Alice for at få sin bitcoin tilbage. Enkel.

Tilbage til netværket, da det virkelig er nødvendigt, at denne HTLC-opsætning er nødvendig.

Som nævnt etablerede ikke kun Alice og Bob, men også Bob og Carol en HTLC. Så, hvis Carol hævder sin bitcoin fra Bob, Bob vilje få værdien til gengæld det vil være synligt på blockchain.

Derfor, hvis det sker, Bob får garanteret også en bitcoin fra Alice. Bob kan tage den værdi, som Carol gjorde offentligt synlig på blockchain, medtage den i sin HTLC med Alice og også kræve en bitcoin for sig selv. De to kanaler er effektivt forbundet.

Som en sidste detalje er det er vigtigt at Bob får værdien fra Carol Før Alice kan genvinde sin bitcoin fra Bob. Hvis Bob kun får værdien fra Carol efter Alice genvundet allerede sin ryg, Bob sidder trods alt fast i midten. Time-out i Bob og Carol’s HTLC skal derfor udløbe Før timeout i Alice og Bobs HTLC udløber. (For eksempel efter nøjagtigt ti dage i stedet for to uger. Dette er også grunden til, at HTLC’er har brug for CheckLockTimeVerify (CLTV) –og ikke CheckSequenceVerify (CSV).)

Endelig er der endnu et problem at løse: for at Lightning Network skal være nyttigt, skal alt dette ske uden for kæden. Hvordan dette gøres er beskrevet i den tredje og sidste artikel i denne serie.