Mreža strele je verjetno najbolj pričakovana tehnološka inovacija, ki se bo razvila na vrh Bitcoinov. Plačilna plast, ki sta jo pred približno letom dni predlagala Joseph Poon in Tadge Dryja, obljublja, da bo podpirala tako rekoč neomejeno število transakcij zunaj verige med uporabniki, skoraj brez stroškov – ob izkoriščanju varnosti, ki jo ponuja Bitcoin.

Vsaj tri podjetja – Poon in Dryja Strela, Blockstream in Blockchain – trenutno delajo na izvedbah tehnologije. Toda malokdo zunaj te majhne tehnološke fronte v celoti razume, kako naj bi “prihodnost mikroplačil” povečala zmogljivosti Bitcoina.

V tej tridelni seriji, Bitcoin Magazine predstavlja osnovne gradnike Lightning Network in prikazuje, kako se ujemajo za uresničitev te prihajajoče protokolarne plasti.

Prvi del te serije je zajemal osnovne gradnike in razložil, kako se ti uporabljajo za vzpostavitev dvosmernih plačilnih kanalov. Ta drugi del pojasnjuje, kako se dvosmerni plačilni kanali spremenijo v omrežje.

Omrežje

V prejšnjem članku sta Alice in Bob vzpostavila dvosmerni plačilni kanal. Zdaj želi Alice plačati en bitcoin tretji osebi Carol.

Za to bi lahko Alice in Carol med njima odprli plačilni kanal. Toda dejansko jim ni treba. Izkazalo se je, da imata Bob in Carol že vzajemni kanal, zato lahko Alice prek Boba preprosto plača Carol.

Natančneje, Alice lahko Bobu plača en bitcoin, Bob pa Carolu en bitcoin.

Vendar Alice v resnici ne zaupa Bobu – ali Carol. Boji se, da če bo plačala Bobu, Bob dejansko nikoli ne bo plačal Carol. Ali morda Bob volja plačaj Carol, toda Carol bo trdila, da denarja ni nikoli prejela, in Alice ne bi vedela, koga bi krivila.

Alice zato želi zagotoviti, da bo bobu plačala le en bitcoin, če Carol plača tudi en bitcoin. To se doseže (delno) s preprostim kriptografskim trikom.

Ko Alice želi Carol poslati bitcoin, pove Carol, naj ustvari vrednost (naključni niz številk) in ji pošlje razpršitev. Alice tudi pove Carol, naj prvotno vrednost z Bobom zamenja za bitcoin.

Alice medtem Carol vzame mešanico, se obrne na Boba in pove Bobu, da mu bo dala bitcoin, če ji bo priskrbel ustrezno vrednost (ki jo ima samo Carol).

Torej, Bob se obrne na Carol in ji v zameno za vrednost da en bitcoin.

Nato se Bob z vrednostjo vrne k Alice. Alice ve, da je Bob verjetno dobil vrednost od Carol v zameno za bitcoin, zato sklepa, da je Carol dobila bitcoin. Tako lahko Alice samozavestno daje Bobu bitcoin.

Vsi so srečni.

No… skoraj vsi so srečni.

V tem “naivnem” scenariju mora posrednik Bob še vedno zaupati Alice in Carol. Bob mora zaupati Carol, da mu bo resnično dal vrednost, potem ko ji je poslal bitcoin, in Bob mora zaupati Alice, da mu bo resnično dala bitcoin, ko ji bo predstavil vrednost.

Trgovanje z bitcoini za vrednost mora biti zato v celotnem omrežju popolnoma zajamčeno. Natančneje: če Bob Carol daje Bitcoin mora zagotovite, da boste od Alice dobili Bitcoin nazaj.

Tu nastopijo Hash Time-Locked Contracts (HTLC).

Hash časovno zaklenjene pogodbe

Torej Alice in Bob hočeta bitcoin zamenjati za vrednost prek HTLC. (In Bob in Carol si prav tako želita zamenjati bitcoin za isto vrednost – vendar zaenkrat ne glede na to.)

Da bi to storila, namesto da bi Bobu poslala bitcoin naravnost navzgor, Alice pošlje bitcoin na nov (in spet zabaven) multisig naslov. Bitcoinov, zaklenjenih na tem naslovu, je mogoče odkleniti na dva različna načina.

Prva možnost je, da Bob vključi svoj podpis in vrednost.

Druga možnost je, da Alice vključi svoj podpis. Vendar ima ta možnost CLTV-timelock: Alice lahko podpiše in odda transakcijo šele potem, ko mineta, recimo, dva tedna.

To pomeni, da ima Bob dva tedna časa, da ustvari nadaljnjo transakcijo, v katero vključi svoj podpis in vrednost, in jo odda, da si bitcoin z funky multisig naslova pošlje sam. Kot taka je ta trgovina zagotovljena. Bob lahko samo zahtevati Alicein bitcoin, če navede vrednost: oddajanje prek Bitcoin omrežja omogoča, da Alice vidi javno.

In če Bob ne zagotovi vrednosti pravočasno, obstaja možnost, da Alice dobi nazaj svoj bitcoin. Preprosto.

Nazaj v omrežje, saj je zato res potrebna ta nastavitev HTLC.

Kot smo že omenili, niso samo Alice in Bob, ampak tudi Bob in Carol ustanovili HTLC. Torej, če Carol trdi, da je Bitcoin od Boba, Boba volja dobite vrednost v zameno; bo viden na verigi blokov.

Torej, če to se zgodi, Bob bo zagotovo dobil bitcoin tudi od Alice. Bob lahko vzame vrednost, ki jo je Carol javno objavila na blockchainu, jo vključi v svoj HTLC z Alice in tudi sam zahteva bitcoin. Oba kanala sta učinkovito povezana.

Kot zadnja podrobnost je pomembno je, da Bob dobi vrednost od Carol prej Alice lahko svoj Bitcoin zahteva od Boba. Če Bob dobi vrednost samo od Carol po Alice je že vrnila svojega, Bob je navsezadnje obtičal na sredini. Časovna omejitev v Bobovem in Carolinem HTLC mora zato poteči prej poteče časovna omejitev v HTC Alice in Boba. (Na primer po natanko desetih dneh, namesto po dveh tednih. Tudi zato HTLC potrebujejo CheckLockTimeVerify (CLTV) – in ne CheckSequenceVerify (CSV).)

Nazadnje je treba rešiti še en problem: da bi bilo Lightning Network koristno, je vse to treba izvesti zunaj verige. Kako se to naredi, je opisano v tretjem in zadnjem članku te serije.