Inbound Liquidity je příchozí likvidita: prostor, který má Lightning uzel pro přijímání plateb přes své kanály. Lightning slouží k rychlým bitcoinovým platbám. Uzel je program, který je zpracovává, a kanály jsou spojení mezi uzly s dohodnutým rozdělením prostředků. Příchozí prostor vychází z prostředků na straně protistran, které se při platbě mohou přesunout na vaši stranu. Není to váš vlastní utratitelný zůstatek. Skutečně přijatelnou částku navíc omezují pravidla kanálů, rozpracované platby a dostupná cesta od odesílatele.
Petr provozuje kavárnu a přijímá platby v Lightning Network. Na svém uzlu, programu obsluhujícím platby, vidí peníze, přesto zákazník nemůže zaplatit. Jednou z příčin může být chybějící příchozí likvidita. Platební kanál je dohoda mezi dvěma uzly o rozdělení vložených bitcoinů. Petrova část se označuje local balance, část protistrany remote balance. Při příjmu se část hodnoty protistrany přesune Petrovi. Aby takový přesun mohl nastat, musí být na její straně co přesouvat. Remote balance ale stále patří protistraně; pořízení možnosti přijímat není dar bitcoinů ani už získaná tržba. [1] [6]
Představme si kanál s kapacitou 1000000 sat. Sat je zkratka jednotky satoshi, malé části bitcoinu. Petr má local balance 800000 sat, protistrana remote balance 200000 sat. Hrubý prostor pro příjem je tedy 200000 sat. Pokud Petr přijme 100000 sat, jeho strana vzroste na 900000 sat a protistraně zbude 100000 sat. Petr má o přijatou platbu víc peněz, ale na další příjem mu zbývá méně prostoru. Příklad pro přehlednost vynechává rezervy, poplatky a čekající platby označované HTLC, vysvětlené níže. Když Petr nový kanál financuje sám bez počátečního převodu protistraně, získá hlavně možnost odesílat. Pouhé potvrzení otevření kanálu směr nezmění. [1] [2]
Během úspěšného dne přibývají peníze na Petrově straně, zatímco příchozí prostor použitých kanálů ubývá. Větší zůstatek tedy může jít ruku v ruce s horší schopností přijmout další platbu. U vlastní infrastruktury je potřeba sledovat dostupné kanály, očekávané částky, rozpracované platby a náklady doplnění likvidity. Některé peněženky část této práce řeší za uživatele, ale mechanismus tím nezmizí. Ani Petra nemusí neúspěšný pokus upozornit: platba se může zastavit dřív, než dorazí k jeho uzlu. Vystavená faktura nebo starší údaj o kapacitě nejsou potvrzením úhrady. [6]
Když Petr zaplatí dodavateli přes Lightning, local balance použitých kanálů klesne a remote balance vzroste. Tím si může uvolnit prostor pro budoucí příjem. Podobně funguje Loop Out: pomocí swapu, výměny mezi platebními vrstvami, odešle hodnotu z Lightningu a obdrží bitcoin na adrese v blockchainu. Kanály přitom není nutné zavřít. Loop In míří opačně: převádí prostředky z blockchainu do utratitelného zůstatku v Lightningu. Žádná z těchto operací nevytváří nové bitcoiny. Při porovnávání výsledku patří do nákladů poplatky za směrování, službu swapu i transakci na blockchainu; důležité je také ověřit dokončení operace. [1] [4]
Další možností je, že protistrana financuje kanál k Petrovi. Ten tak může získat příchozí prostor, aniž by mu protistrana své peníze darovala. Dokumentace Lightning Pool popisuje tržiště takových dohod: bid je poptávka po likviditě, ask nabídka jejího poskytnutí. Dohoda má dobu pronájmu vyjádřenou v blocích a zahrnuje prémii i další poplatky. Blok je skupina transakcí přidaná do blockchainu, veřejné historie bitcoinových plateb. Doba pronájmu se tedy odvíjí od přibývání bloků, nikoli od přesně daného počtu hodin. Není to koupě celého vzdáleného zůstatku. Samotná smluvená doba navíc neznamená, že po celou dobu zůstane k příjmu stejná částka; platby rozdělení zůstatků mění. Po skončení dohody také nelze předpokládat trvalou dostupnost kanálu. [1] [5]
Petr může mít více kanálů a potřebovat příchozí prostor právě u jiného partnera. Circular rebalancing, kruhové vyvážení, pošle jeho platbu jedním kanálem do sítě a vrátí ji jiným jeho kanálem. Kanál, kterým odesílá, získá příchozí prostor, zatímco kanál, kterým přijímá, ho spotřebuje. Peníze se přesouvají mezi jeho stranami kanálů, nevzniká nový kapitál a směrování stojí poplatky. Postup potřebuje průchozí cestu. Pokud na vzdálených stranách všech jeho kanálů chybí prostředky, nemá kudy přijmout návratovou část platby; samotné kruhové vyvážení to nevyřeší. [1]
Část peněz musí zůstat jako rezerva pro bezpečné fungování kanálu. Další část mohou dočasně vázat HTLC, podmíněné platební závazky. Příjemce je může získat předložením tajné hodnoty, z níž se vypočítá sjednaný platební hash, tedy údaj sloužící ke kontrole. Při neúspěchu má odesílající strana po uplynutí lhůty možnost prostředky získat zpět. BOLT 2, specifikace správy kanálů, omezuje také nejmenší částku, počet současných HTLC a jejich celkovou hodnotu. Pro další platbu tak nemusí být použitelný celý remote balance. Nestačí sečíst všechny vzdálené zůstatky a odečíst jednu univerzální rezervu; záleží na konkrétních kanálech a jejich aktuálním stavu. [2]
Platba obvykle putuje přes více uzlů. I když má Petr místo k příjmu, dřívější úsek cesty může být nedostupný nebo mu mohou chybět prostředky. BOLT 7 popisuje zprávy channel_update, kterými uzly oznamují podmínky směrování pro určitý směr kanálu. Patří sem poplatky a htlc_maximum_msat, horní hranice jedné podmíněné platby v msat, tisícinách satoshi. Nejde o příslib aktuálního zůstatku celé trasy. Ani součet Petrova příchozího prostoru proto nezaručuje příjem stejně velké platby od každého konkrétního odesílatele. Dostupná likvidita u příjemce je nutná část řešení, nikoli jediná. [3]
Pro nejúplnější obraz čtěte toto heslo společně s Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. Opačným směrem na něj odkazují také Lightningová likvidita, Lightning Routing, Lightning Address, Submarine Swap.