LSP طرف مقابل ومزود خدمة وليس جزءا من Bitcoin consensus؛ يمكن للعميل الاحتفاظ بمفاتيحه، لكن عليه تقييم السعر والتوافر وشروط channel وtrust model المحدد في LSPS protocol المستخدم.
ينشر Lightning Service Provider سيولته أو سيولة حصل عليها لصالح العملاء. غالبا يفتح channel نحو non-custodial wallet لتوفير inbound capacity أو يصل أموالا on-chain وoff-chain عبر swap؛ ويتقاضى مقابل block space وcapital وoperation وrisk. [1]
Lightning channel capacity ثابتة ومقسمة بين local وremote balance. لذلك لا تستطيع wallet جديدة بلا channel استقبال Lightning payment عادي بمجرد إنشاء invoice؛ يمكن لـ LSP توفير inbound liquidity دون اختيار peer وUTXO وfunding transaction parameters يدويا. [1]
يوحد LSPS0، وهو الآن bLIP 50، اتصال client-LSP بصيغة JSON-RPC 2.0 عبر Lightning BOLT8 peer-to-peer transport. تستخدم كل LSPS messages معرف message ID 37913، وتعيد lsps0.list_protocols قائمة extensions المدعومة بدقة؛ ولا يضمن اسم LSP كل service. [2]
يوحد LSPS1 أو bLIP 51 طلب channel المباشر. يقرأ client العرض وينشئ order ويتحقق من capacity وprice وexpiry ثم يدفع on-chain أو عبر Lightning؛ وتصرح specification بأن purchase غير atomic وأن client يثق في LSP لتسليم channel أو تنفيذ refund المحدد. [3]
يعالج LSPS2 أو bLIP 52 قناة just-in-time channel. يحصل client على parameters ويضع route hint مع request identifier في invoice؛ وعند وصول incoming payment إلى LSP يفتح provider قناة zero-confirmation channel ويخصم opening fee ويرسل الباقي. يجب أن يكون client متصلا حينها. [4]
لا يحتفظ LSP غير الحافظ بمفاتيح client الخاصة ويترك له جانبه من channel، لكن operational dependency تبقى. يرى provider الاتصال المباشر وجزءا من payment flow، وقد يرفض liquidity أو يغير price ضمن العرض أو يكون offline؛ ولـ zero-confirmation channel وprepaid order مخاطر مختلفة. [1]
انتقلت معايير LSPS0 وLSPS1 وLSPS2 من repository الأصلي إلى عملية bLIP بصفتها bLIP 50 و51 و52 نشطة. تنفذ reference library lightning-liquidity كلا من LSPS1 وLSPS2 client handlers وLSPS2 service handler، لكن wallet أو node معينة قد تدعم subset بشروطها. [5]
قبل الاستخدام يجب فحص node ID وconnection string لـ LSP ونتيجة lsps0.list_protocols وcapacity وbalance split وfee وexpiry وconfirmations وrefund policy. بعد الفتح يفحص client funding transaction وchannel state وinbound capacity الفعلية؛ ولا يثبت logo أو invoice المنشأة ذلك. [2]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. تشير إلى هذا المدخل أيضًا Just-in-Time Channels, Trampoline Routing, Bitlifi.
01هل Lightning Service Provider خدمة custodial تلقائيا؟+
لا. يمكن لـ LSP فتح channel إلى wallet تحتفظ بمفاتيحها وإدارة جانبه فقط. يظل client معتمدا على availability وliquidity offer وتنفيذ order المحددة.
02هل يمكن استقبال أول payment عبر LSP بلا channel سابق؟+
نعم، إذا دعمت wallet وprovider بروتوكول LSPS2 وغطى payment قيمة opening fee. يفتح LSP قناة JIT channel عند الوصول ويخصم fee؛ وليست inbound capacity مجانية أو غير مشروطة.