LSP je protistrana a poskytovatel služby, nikoli součást bitcoinového konsenzu; klient může držet vlastní klíče, ale musí posoudit cenu, dostupnost, podmínky kanálu a konkrétní trust model použitého LSPS protokolu.
Lightning Service Provider nasazuje vlastní nebo získanou likviditu ve prospěch klientů. Nejčastěji otevře kanál směrem k neúschovné peněžence, aby měla inbound capacity, případně propojí on-chain a off-chain prostředky swapem; za blokový prostor, kapitál, provoz a riziko účtuje cenu. [1]
Kapacita Lightning kanálu je pevná a dělí se mezi local a remote balance. Nová peněženka bez kanálu proto neumí přijmout běžnou Lightning platbu jen tím, že vytvoří invoice; LSP může dodat příchozí likviditu bez toho, aby uživatel ručně vybíral peer, UTXO a parametry funding transaction. [1]
LSPS0, nyní bLIP 50, sjednocuje komunikaci klienta s LSP jako JSON-RPC 2.0 přes Lightning BOLT8 peer-to-peer transport. Všechny LSPS zprávy používají message ID 37913 a metoda lsps0.list_protocols vrací přesný seznam podporovaných nadstaveb; samotná zkratka LSP tedy nezaručuje podporu každé služby. [2]
LSPS1 neboli bLIP 51 standardizuje přímou objednávku kanálu. Klient načte nabídku, vytvoří order, ověří kapacitu, cenu a expiraci a zaplatí on-chain nebo Lightning; specifikace výslovně říká, že nákup není atomický a klient důvěřuje LSP, že po platbě dodá slíbený kanál nebo provede předepsanou refundaci. [3]
LSPS2 neboli bLIP 52 řeší just-in-time channel. Klient získá parametry a do invoice vloží route hint s identifikátorem požadavku; když příchozí platba dorazí přes LSP, poskytovatel otevře zero-confirmation channel, odečte opening fee a zbytek pošle klientovi. Klient musí být v rozhodný okamžik připojen. [4]
Neúschovný LSP nedrží klientovy privátní klíče a ponechává mu jeho stranu kanálu, přesto vzniká provozní závislost. Poskytovatel vidí přímé spojení a část platebního toku, může odmítnout novou likviditu, změnit cenu v mezích nabídky nebo být offline; zero-confirmation channel a předplacená objednávka mají navíc rozdílná rizika. [1]
Standardy LSPS0, LSPS1 a LSPS2 byly z původního úložiště převedeny do procesu bLIP jako aktivní bLIP 50, 51 a 52. Referenční knihovna lightning-liquidity implementuje klientské handlery LSPS1 a LSPS2 i service handler LSPS2, ale konkrétní peněženka nebo uzel může podporovat jen podmnožinu a vlastní obchodní podmínky. [5]
Před použitím je nutné ověřit node ID a connection string LSP, výsledek lsps0.list_protocols, přesnou kapacitu a rozdělení balance, fee, expiraci, počet confirmations a refund policy. Po otevření má klient zkontrolovat funding transaction, channel state a skutečnou inbound capacity; logo poskytovatele ani úspěšně vytvořená invoice tyto vlastnosti nedokazují. [2]
Pro nejúplnější obraz čtěte toto heslo společně s Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. Opačným směrem na něj odkazují také Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Je Lightning Service Provider automaticky úschovná služba?+
Ne. LSP může otevřít kanál k peněžence, která drží vlastní klíče, a spravuje pouze svou stranu kanálu. Klient však stále spoléhá na jeho dostupnost, nabídku likvidity a splnění konkrétní objednávky.
02Lze přes LSP přijmout první platbu bez předchozího kanálu?+
Ano, pokud peněženka i poskytovatel podporují LSPS2 a platba pokryje požadovanou opening fee. LSP při příchodu platby otevře JIT channel a poplatek odečte; nejde o bezplatnou ani bezpodmínečnou příchozí kapacitu.