Lightning Service Provider

Lightning Service Provider は自前または調達した liquidity を clients のために配置します。多くは non-custodial wallet に inbound capacity を与える channel を開くか、swap で on-chain と off-chain funds をつなぎ、block space、capital、operation、risk の対価を受け取ります。 [1]

Lightning channel capacity は固定され、local と remote balance に分かれます。そのため channel のない新しい wallet は invoice を作るだけでは通常の Lightning payment を受け取れません。LSP は peer、UTXO、funding transaction parameters を手動で選ばせず inbound liquidity を提供できます。 [1]

LSPS0、現在の bLIP 50 は、client と LSP の通信を Lightning BOLT8 peer-to-peer transport 上の JSON-RPC 2.0 に統一します。全 LSPS messages は message ID 37913 を使い、lsps0.list_protocols が対応 extensions を正確に返します。LSP という名称だけで全 service が保証されるわけではありません。 [2]

LSPS1、すなわち bLIP 51 は channel の直接 order を標準化します。Client は offer を読み、order を作成し、capacity、price、expiry を確かめて on-chain または Lightning で支払います。Specification は purchase が atomic ではなく、支払い後に LSP が channel を提供するか規定の refund を行うと client が信頼するモデルだと明記します。 [3]

LSPS2、すなわち bLIP 52 は just-in-time channel を扱います。Client は parameters を受け取り、request identifier を持つ route hint を invoice に入れます。Incoming payment が LSP に届くと provider は zero-confirmation channel を開き、opening fee を引いて残りを転送します。その時 client は接続中でなければなりません。 [4]

Non-custodial LSP は client の private keys を保持せず、client 側 channel を本人に残しますが、operational dependency は生じます。Provider は direct connection と payment flow の一部を見て、liquidity を断り、offer 内で price を変え、offline にもなり得ます。Zero-confirmation channel と prepaid order の risk も異なります。 [1]

LSPS0、LSPS1、LSPS2 は元 repository から bLIP process に移り、active bLIP 50、51、52 となりました。Reference library lightning-liquidity は LSPS1 と LSPS2 の client handlers および LSPS2 service handler を実装しますが、個々の wallet や node は独自 terms で subset だけを支援する場合があります。 [5]

利用前に LSP node ID と connection string、lsps0.list_protocols の結果、正確な capacity と balance split、fee、expiry、confirmations、refund policy を確認します。開設後は funding transaction、channel state、実際の inbound capacity を調べます。Provider logo や作成済み invoice はこれらの証明ではありません。 [2]