HTLC

Anna chce poslat Pavlovi 20 000 sat přes Lightning Network. Sat je zkratka pro satoshi, nejmenší jednotku bitcoinu na řetězci. Nemají společný platební kanál, ale oba mají vhodné spojení přes Evu. Kanál je dohoda dvou účastníků o rozdělení bitcoinů, kterou lze průběžně měnit bez zápisu každé platby do bloku. Eva nabídne Pavlovi podmíněných 20 000 sat a Anna nabídne Evě 20 010 sat; rozdíl 10 sat je v tomto zjednodušeném příkladu poplatek Evě. Jde o dvě propojené změny zůstatků ve dvou kanálech, ne o putování téže konkrétní mince. Pavel má tajemství, jehož odhalením může splnit svou podmínku. Eva pak stejný údaj použije vůči Anně. Nemusí Pavlovi nejprve nevratně zaplatit jen na základě jeho slibu. Částky jsou příklad, nikoli běžný nebo doporučený poplatek. [1]

Pavel si pro platbu připraví náhodný tajný údaj o délce 32 bajtů, payment_preimage. Funkce SHA-256 z něj vypočítá payment_hash. Je snadné ověřit, zda odhalený údaj dává správný otisk; ze samotného otisku však nelze prakticky získat dobře zvolené tajemství. V běžné faktuře BOLT 11, tedy platebním požadavku Lightning, je hash v poli p, nikoli samotná preimage. Když Pavel splní platbu, tajemství se předá zpět podél trasy a propojí příslušné HTLC. Údaj payment_secret v poli s faktury je něco jiného: pomáhá správně zpracovat platbu u příjemce a nenahrazuje preimage. Žádný z těchto údajů není Seed Phrase (slova pro obnovu peněženky) ani soukromý klíč peněženky. [1] [4]

Kdyby obě podmíněné platby měly stejnou lhůtu, Pavel by mohl tajemství odhalit tak pozdě, že by Eva už nestihla uplatnit příchozí platbu. Proto má příchozí HTLC od Anny pozdější expiraci než Evin odchozí HTLC k Pavlovi. Rozdíl označovaný cltv_expiry_delta dává Evě rezervu. Potřebuje ji i pro případ, že druhá strana přestane odpovídat a bude nutné použít bitcoinové transakce přímo na řetězci. Rezerva se počítá v blocích, nikoli v přesných minutách, a musí počítat i se zpožděním a reorganizací řetězce. Její bezpečné nastavení řeší software a pravidla kanálu; malá rezerva může ohrozit prostředky. Při reorganizaci se část řetězce nahradí jinou platnou větví, což může změnit dřívější potvrzení transakcí. [1]

V Lightning určuje cltv_expiry výšku bloku, tedy jeho pořadí v řetězci. Není to Unix timestamp, tedy kalendářní čas vyjádřený počtem sekund, ani platnost faktury BOLT 11 měřená v sekundách. Po splnění časových podmínek se může otevřít timeout, tedy cesta k vypořádání bez tajemství. Peníze se ale samy nepřesunou: lightningové uzly, tedy programy spravující platební kanály, musejí správně dokončit změnu kanálu nebo použít příslušnou transakci na řetězci. Ani platná preimage se uplynutím lhůty automaticky nevypne. Pokud ještě nebyl stejný výstup, tedy částka s pravidly utracení, utracen jinak, mohou o něj soupeřit různé povolené cesty; obě utracení se v jednom platném řetězci potvrdit nemohou. Proto je včasná reakce součástí bezpečnosti. [1] [4] [5]

HTLC propojuje podmínky, nezajišťuje však průchod libovolné částky libovolnou trasou. Eva musí mít v odchozím směru dost prostředků, tedy likviditu, a volné místo pro další čekající HTLC. Platbu mohou zastavit limity, poplatky i nedostupný uzel. Dokud se čekající pokus řádně nevyřeší, může část prostředků zůstat vázaná. Stav v peněžence proto čti jako informaci o celém pokusu, ne jako důkaz odvozený z jediné zprávy. Odhalení preimage není totéž jako potvrzení bitcoinové transakce. Běžná úspěšná platba Lightning se vypořádá změnami kanálů, bez nového zápisu každé platby do bloku. [1] [3]

Další části jsou technická reference. Stav kanálu říká, komu připadá která částka a které HTLC ještě čekají. Commitment transaction je podepsaná bitcoinová transakce umožňující tento stav vynutit na řetězci. Zpráva update_add_htlc teprve navrhuje přidání; update_fulfill_htlc oznamuje splnění a update_fail_htlc selhání. Změnu však nestačí jen oznámit. Pomocí commitment_signed a revoke_and_ack si strany předají podpisy nového stavu a údaje, které umožňují postihnout použití starého stavu. Obě musejí podle BOLT 2 neodvolatelně přijmout příslušnou změnu, než na ni naváže další závazek. Toto potvrzení mezi účastníky není potvrzením v bloku. Financování a případné uzavření kanálu se naopak opírají o bitcoinové transakce. [1]

Pole jsou jednotlivé údaje ve zprávě. Millisatoshi je tisícina satoshi, účetní jednotka používaná uvnitř Lightning; není to samostatně utratitelný zlomek na bitcoinovém řetězci. Základ zprávy update_add_htlc tvoří channel_id, id, amount_msat, payment_hash, cltv_expiry a onion_routing_packet. amount_msat je v millisatoshi. Uzel kontroluje kanálové limity, dostupnou likviditu a podmínky přeposlání; odchozí HTLC má vlastní parametry. Navazující HTLC nesmí nabídnout, dokud přidání příchozího není neodvolatelně potvrzené podle BOLT 2. [1]

Onion routing balí pokyny pro jednotlivé prostředníky do oddělených šifrovaných vrstev. Eva dostane potřebné pokyny pro svůj krok, nikoli otevřený seznam všech účastníků. Uzel dešifruje svou onion vrstvu a ověří její integritu. U běžné nezastřené trasy porovnává amt_to_forward a outgoing_cltv_value s příchozí částkou, poplatkem a požadovaným časovým rozdílem. Paket mu neposkytuje celou trasu. To však nevylučuje korelaci provozu ani jiné odvození identity; onion routing není zárukou absolutní anonymity. [3]

Výstup je částka s pravidly utracení a Script je jazyk pro zápis těchto pravidel. Offered označuje nabídnutý HTLC a received přijatý. Druhá fáze je navazující transakce; CHECKSEQUENCEVERIFY (CSV) vynucuje čekání od potvrzení utráceného výstupu. Revokační klíč slouží k postihu zveřejněného starého, již odvolaného stavu. BOLT 3 rozlišuje offered a received výstupy a cesty HTLC-success či HTLC-timeout. Nestačí znát hash: uplatní se příslušné podpisy, preimage a časové podmínky. Lokální výstup druhé fáze má CSV prodlevu to_self_delay, zatímco správný revokační klíč dovoluje protistraně trestnou větev bez této prodlevy. Přesný Script závisí na typu kanálu. [2] [6]

Trimming znamená, že se drobný HTLC při převodu stavu kanálu na řetězec vůbec nestane samostatným výstupem. Dust je zde označení takto malých částek. Dust exposure vyjadřuje souhrnnou částku vystavenou tomuto omezení. Pokud částka po příslušném poplatku druhé fáze nedosáhne dust_limit_satoshis, commitment transakce HTLC výstup nevytvoří. Pravidla závisí na dohodnutém typu: option_anchors a zero_fee_commitments nemají tento poplatek druhé fáze; zero_fee_commitments může vyřazenou hodnotu směrovat do shared_anchor. Chybějící výstup nelze samostatně nárokovat na řetězci. Součet takových HTLC tvoří dust exposure. [2] [1]

Následující kontrola je pro provozovatele uzlu a vývojáře. Dekódování převádí záznam do čitelných polí; samo nic neodesílá a nepotvrzuje, že jsou všechny podmínky splněny. Porovnej příchozí a odchozí amount_msat, payment_hash a cltv_expiry; ověř preimage pomocí SHA-256. Sleduj také commitment_signed, revoke_and_ack a konečný stav, nikoli jen jednu zprávu fulfill/fail. Při vynucení na řetězci dekóduj skutečnou commitment transakci a zkontroluj existenci výstupu, použitou větev i HTLC-success/HTLC-timeout. Zkontroluj podpisy, časové podmínky a potvrzení; samotné dekódování platnost nedokazuje. [1] [2]