Jak funguje Lightning Network #4: Routing, první část

Jak funguje Lightning Network #4: Routing, první část

Propojování kanálů a payment routing (směrování platby) funguje jako internet ve svých počátcích. Nás bude zajímat především mechanismus bezpečného přesouvání přes prostředníky.

Zdroj: https://www.skalex.io/lightning-network/

Dnešní díl je nejdůležitější. Vynaložil jsem opravdu velkou energii, abych popsal vše přesně a jasně, protože na fórech legendárního Bitcointalku nebo Redditu se neustále objevovaly dotazy na toto téma. Dovolím si dnes trochu delší úvod. Jestli jste se pouze podívali do whitepaperu projektu Lightning Network, muselo se vám udělat zle. I Rustymu Russelovi, který na toto téma napsal hned pět dlouhých článků. A to je škoda, protože Lightning Network krásně spojuje blockchain a „hrátky s chytrými smlouvami“. Na něm spíše, než na kterékoliv další technologii založené na kryptu poznáte, k čemu to vlastně je.

Vše začíná už penalizační transakcí a sekretem, který demonstruje přímou aplikaci knowledge skriptů (krátky na to, kdo ví jakou informaci). Jde o hádanky – která hodnota vyprodukovala tento otisk? Přepis mechanismu do řeči stroje.

Obsah

Tento článek obsahuje detailní informace o HTLC kontraktech, CSV a CLTV časových zámcích a vzhled commitment transakce pro multi-hop payment channel.

Princip

Princip je, jako většina kryptografických triků, založen na přesunu knowledge (znalosti) informace, protože právě s nimi si počítače dokážou nejlépe poradit (chceme-li něco automatizovat, je nutné, aby si s tím poradil počítač). Alice chce zaplatit Carol, ale nemá s ní otevřen přímý kanál, a kdyby si měla otevřít nový kanál s každým, s kým provádí platby, neřešil by Lightning Network vůbec nic. Využije proto Boba (tzv. multihop transfer), který ho má. Co když ale Bob Alicin Bitcoin nepředá Carol a nechá si ho? K tomu použijeme jednoduchý kryptografický trik.

Payment route – platební cesta. Zdroj: https://masteringbitcoin.neocities.org/

HTLC

Podívejme se na první část Lightning route štafety (Lightning cesty přesunu 1 BTC zcela off-chain). Alice pošle svůj 1 BTC na multisig adresu (ne 2-of-2 multisig adresu! – tato funguje jinak), která funguje následovně: okud Bob doloží value, 1 BTC poputuje k němu; pokud Alice podepíše druhou možnost, tak se jí obsah multisigu po době (CLTV časový zámek – nepatrně jiný než v minulých dílech, ještě si o tom povíme), kterou má Bob na získání value, vrátí.

Zdroj: https://blog.usejournal.com/the-bitcoin-lightning-network-a-technical-primer-d8e073f2a82f

Ukázkový diagram (bohužel s jinými jmény). „R“ je hash (otisk) hodnoty (též preimage), „TX“ je transakce, žlutý klíček hodnota.

Úkol Boba je podobný. Aby získal value, než mu vyprší čas, tak také vytvoří multisig s Carol. Pokud by ale limit kanálu Boba s Carol byl delší než limit s Alicí, mohl by skončit s value, ale bez Bitcoinu, protože strana (Alice), která mu to nabízela, již vypršela. Proto je nutné, aby limit s Carol vypršel dříve než s Alicí, v případě více účastníků také. Představme si nyní nový druh časového zámku a zopakujme ten, co již známe.

Zdroj: https://masteringbitcoin.neocities.org/

Časové zámky

Zdroj: www.dailymagazine.news/a-look-at-bitcoin-s-timelocks-nid-829004.html

CLTV

HTLC používá CLTV (Check Lock-Time Verify) zámek, což je druh tzv. absolutního zámku, který nezávisí na hloubce bloku s transakcí v blockchainu od doby, kdy byl poprvé zahrnut, ale spíše na absolutní délce blockchainu v určitý moment. CLTV zámek je vždy nastaven na výstup transakce, který uzamyká. Nezáleží na tom, je kdy původní transakce potvrzena a součástí bloku.

Aby byly věci ještě složitější, jsou bloky přece řešeny v náhodných desetiminutových intervalech. Neexistuje žádná vlastní záruka, že následující blok bude vyřešen 10 minut po předchozím. Mohlo by se to stát o 1 sekundu později. Proto jsou namísto CSV používány přesnější CLTV. Je nezbytné, aby účastníci (huby, mediátory) poskytovali dostatek bloků mezi „timeouty“ kanálu, čímž brání ztrátě finančních prostředků.

CSV

CSV tikot neběží, dokud není transakce zahrnuta v bloku, resp. plně závisí na čase, kdy v něm zahrnuta je. Příklad:

Teď je blockchain time 500 000 bloků a já vyslal transakci, která je utratitelná až po deseti blocích (CSV). Blockchain sám o sobě neumí započítat transakci až po určité době, takže se stane to, že bude transakce odmítnuta. Než se může stát součástí nějakého bloku, musí uběhnout 5 bloků (od doby, co byl poprvé potvrzen, resp. utracen její vstup). První potvrzení vstupu nastalo v čase 500 005 bloků, od něhož se teprve počítá těch deset dalších, po kterých bude transakce utratitelná.

Proč to tak detailně vysvětluji? Vzpomeňte si na commitment transakce a na penalizace. Vstup, kterému zvýrazněná část Aliciny transakce „počítá“ hloubku v blockchainu, resp. potvrzení, než jí odešle 5 BTC, je multisig (nahoře) z funding transakce. Jakmile proto Alice multisig podepíše a vyšle na blockchain, pět Bitcoinů se (což není v obrázku naznačeno a může to být matoucí) pošle na další adresu (resp. na vstup transakce s podmínkami) a v tu chvíli časová CSV podmínka teprve začíná běžet.

Proč se BTC pošlou ještě na další adresu? Protože v Bitcoinu (a všech kryptoměnách vůbec) nelze „nechat“ na adrese zbytek (maximálně si ho můžete poslat jako cashback zase na další adresu). Ve chvíli, kdy celá Alicina transakce utrácí, tak proto musí zbylých 5 BTC poslat na další adresu, která v obrázku není vidět. To je ale zase jiná písnička.

Upraveno. Zdroj: https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-creating-the-network-1465326903/

Pokud transakce na vstupu, kterou CSV „měří“, bude dlouho nepotvrzená (přetížení sítě apod.), čas nepoběží. Proto je CSV dynamický a závislý na procesu těžby.

Nová commitment transakce

Alice a Bob mají otevřený kanál a vyměňují si Bitcoiny off-chain. Vždy vytvoří nový commitment, podepíšou ho, pošlou druhé straně a vymění si secrety. To už známe.

Commitment transakce potřebná pro multihop transfer (převod mezi více uzly) má ale tři výstupy (a opět má každý svou verzi).

Upraveno. Zdroj: https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-completing-the-puzzle-and-closing-the-channel-1466178980/

Příklad vzhledu transakce, kterou dostal Bob předpodepsanou Alicí, je 4 BTC Alici, 5 Bobovi a 1 BTC na zvláštní třetí výstup, kde existují dokonce tři způsoby, jak ho odemknout:

  1. Vložit hodnotu. Tuto možnost může odemknout tedy pouze on a pokud to udělá, musí čekat, dejme tomu, 1000 bloků (CSV relativní časový zámek závislý na počtu bloků od prvního potvrzení bloku s transakcí blockchainu), než se mu ten 1 BTC při vyslání této transakce pošle na jeho adresu.
  2. V případě, že nedošlo k možnosti 1) a Bob nezískal hodnotu (tzn. když může dojít k zamražení toho 1 BTC), dojde k navrácení 1 BTC Alici, a to po uplynutí např. dvou týdnů od vyslání commitmentu na blockchain (schválně neříkám bloky, abych dal najevo vyšší přesnost CLTV před CSV), než bude 1 BTC její – to je tzv. time-out fall-back, jakási časová pojistka proti zamražení (bagholdingu), kterou poskytuje časově absolutní CLTV zámek.
  3. Vložit klasický secret pro penalizaci (pokud by se Bob pokusil vyslat starší transakci) – to může udělat Alice. Po dokončení této commitment transakce Bobem se jeden Bitcoin neprodleně přesune na tu „nezakreslenou“ adresu. V tu chvíli běží CLV zámek, který mu umožní si z ní poslat prostředky k sobě až za 1000 bloků a Alice má po celou tu dobu možnost si ten 1 BTC poslat zpět vložením secretu. Protože ale na obrázku vidíte, že pro zrušení přesunu jednoho BTC je na obrázku ještě jedno pole, kde je nakreslen ten samý červený klíček – přesun zůstatku Boba (5 BTC) v kanálu Alici, přijde Bob podváděním i o všechny své peníze v kanálu. Pokud Alice vloží secret později, penalizace nebude mít z čeho brát, protože už tam bude prázdno. Proto je CSV i CLTV zámek tzv. transakční – funguje jako šek. Příklad: za rok ti tato transakce pošle 100 BTC, ale do té doby si můžu nechat všechny prostředky z jejího vstupu poslat jinam a šek bude bezcenný.
Zdroj: https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-completing-the-puzzle-and-closing-the-channel-1466178980/

Všimněte si, že spodní červeně ohraničený obdélník má tři pole (dvě vrchní jsou klasicky pro penalizaci a ustanovení nové bilance) oddělená tenčí černou čarou – to jsou ty tři outputy (výstupy) commitment transakce uzpůsobené pro multihopový přenos. Poslední pole má tři možnosti (to nové). Alice to podepíše pouze na vstupu. Představte si, že mezi Bobem a Alicí nedošlo v poslední době k žádné off-chain transakci. Potom je stejně potřeba na commitment transakci pro multihop zopakovat stávající bilanci.

Motivační závěr

Jak se tedy prostředky přesunou ke Carol? Všechno, co jsem dnes řekl, je záruka, že Bob dostane Bitcoin, pokud zná value. Neexistuje způsob, jak by ho mohla Alice podvést, i kdyby value znala.

Pokud vezmeme v úvahu, že ty tři scénáře HTLC by nastaly pouze v případě podvádění nebo neaktivity druhého, tak jsme právě stvořili logický trapdoor, který iniciuje Alici, aby, jakmile jí Bob off-chainově pošle value, aktualizovala kanál na commitment bez HTLC a poslala mu předpodepsanou transakci, kde má o Bitcoin navíc (není třeba nic posílat na blockchain, i když tato akce proběhne de facto z dobré vůle, protože není v podmínkách HTLC definována). V praxi to samozřejmě probíhá v řádech milisekund a vše složité řídí aplikační rozhraní.

Carol má zase kanál s HTLC kontraktem s Bobem, nastavený na kratší časový limit. Bitcoin se nemůže zaseknout, v nejhorším případě přestanou prostředníci odpovídat a bude třeba transakce vyslat. Pokud se to stane, Bob má dva týdny na to, aby poskytl value.

Je zvláštní si uvědomit, co všechno bylo třeba udělat, aby mohl celý proces proběhnout naprosto trustless (bez důvěry).

Co je přesně HTLC?

HTLC je část commitment transakce, kterou jsme přidali v dnešním dílu a která má tři podmínky.

Zdroj: https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-completing-the-puzzle-and-closing-the-channel-1466178980/

Závěr

Ono je to v podstatě strašně jednoduché, ale horší na představivost. Už nás čekají poslední dva díly. Příště, v druhé části routingu, tedy směrování, budeme mluvit o perličkách celého mechanismu – o propojeních s mnohem vyšším počtem účastníků.

Zdroje

https://blog.usejournal.com/the-bitcoin-lightning-network-a-technical-primer-d8e073f2a82f – timelocky

https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-completing-the-puzzle-and-closing-the-channel-1466178980/ – princip

Sdílet příspěvek

Napsat komentář

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..