168 / 736INBOUND

Inbound Liquidity

Lightning भुगतान प्राप्त करने की गुंजाइश

Lightning वॉलेट में पैसे होते हुए भी अगला भुगतान क्यों नहीं आ पाता? यह भी महत्वपूर्ण है कि चैनलों में पैसे किस तरफ हैं।

Inbound Liquidity वह आने वाली तरलता है जिससे Lightning नोड अपने चैनलों के जरिए भुगतान प्राप्त कर सकता है। Lightning से बिटकॉइन का तेज़ भुगतान किया जा सकता है। नोड वह प्रोग्राम है जो भुगतान संभालता है। चैनल नोड के बीच ऐसे कनेक्शन हैं जिनमें पैसों का बँटवारा तय होता है। प्राप्ति की इस क्षमता का आधार दूसरे पक्ष के वे पैसे हैं जो भुगतान के दौरान आपकी तरफ आ सकते हैं। यह आपका खुद का खर्च करने योग्य शेष नहीं है। चैनल के नियम, जारी भुगतान और भेजने वाले से उपलब्ध रास्ता भी वास्तविक प्राप्ति को सीमित करते हैं।

पेत्र कैफ़े चलाते हैं और Lightning Network से भुगतान लेते हैं। भुगतान संभालने वाला उनका नोड पैसे दिखा रहा है, फिर भी ग्राहक भुगतान नहीं कर पा रहा। एक कारण आने वाली तरलता की कमी हो सकती है। भुगतान चैनल दो नोड के बीच जमा बिटकॉइन के बँटवारे का समझौता है। पेत्र के हिस्से को local balance और दूसरे पक्ष के हिस्से को remote balance कहते हैं। भुगतान मिलने पर दूसरे पक्ष का कुछ मूल्य पेत्र की तरफ आता है। इसलिए उस तरफ स्थानांतरित होने के लिए पैसे होने चाहिए। Remote balance फिर भी दूसरे पक्ष की संपत्ति है: प्राप्त करने की क्षमता खरीदना बिटकॉइन का उपहार या पहले ही कमाई जा चुकी रकम नहीं है। [1] [6]

मान लें चैनल की क्षमता 1000000 sat है। Sat, satoshi का संक्षिप्त रूप है, जो बिटकॉइन की छोटी इकाई है। पेत्र का local balance 800000 sat और दूसरे पक्ष का remote balance 200000 sat है। इसलिए सीमाएँ घटाने से पहले प्राप्ति की गुंजाइश 200000 sat है। पेत्र को 100000 sat मिलें, तो उनकी तरफ 900000 sat हो जाते हैं और दूसरे पक्ष के पास 100000 sat बचते हैं। भुगतान से पैसे बढ़े, लेकिन अगली प्राप्ति की जगह घटी। सरलता के लिए इसमें आरक्षित राशि, शुल्क और लंबित HTLC भुगतान छोड़े गए हैं; इनकी चर्चा नीचे है। पेत्र नया चैनल अकेले भरें और शुरू में दूसरे पक्ष को कुछ न दें, तो मुख्यतः भेजने की क्षमता मिलती है। चैनल खुलने की पुष्टि से यह दिशा उलट नहीं जाती। [1] [2]

अच्छे दिन में पेत्र की तरफ पैसे बढ़ते हैं, जबकि इस्तेमाल किए गए चैनलों की आने वाली गुंजाइश घटती है। इसलिए अधिक शेष के साथ अगला भुगतान लेने की क्षमता कम हो सकती है। अपना ढाँचा चलाने पर उपयोगी चैनल, अपेक्षित रकम, जारी भुगतान और तरलता भरने का खर्च देखना पड़ता है। कुछ वॉलेट यह काम आंशिक रूप से उपयोगकर्ता के लिए करते हैं, पर तंत्र नहीं बदलता। असफल प्रयास पेत्र को दिखे भी नहीं: भुगतान उनके नोड तक पहुँचने से पहले रुक सकता है। बना हुआ इनवॉइस या क्षमता की पुरानी संख्या पैसे मिलने की पुष्टि नहीं है। [6]

पेत्र Lightning से आपूर्तिकर्ता को भुगतान करते हैं, तो इस्तेमाल किए गए चैनलों का local balance घटता है और remote balance बढ़ता है। इससे भविष्य की प्राप्ति के लिए जगह बन सकती है। Loop Out भी ऐसा करता है: swap, यानी भुगतान की परतों के बीच अदला-बदली, से वह Lightning से मूल्य भेजते हैं और ब्लॉकचेन के पते पर बिटकॉइन पाते हैं। चैनल बंद करना ज़रूरी नहीं। Loop In उल्टी दिशा में ब्लॉकचेन के पैसे को Lightning में खर्च करने योग्य शेष बनाता है। कोई प्रक्रिया नए बिटकॉइन नहीं बनाती। नतीजे की तुलना में रूटिंग, स्वैप सेवा और ब्लॉकचेन लेनदेन के शुल्क जोड़ें, और जाँचें कि प्रक्रिया वाकई पूरी हुई है। [1] [4]

दूसरा पक्ष पेत्र की ओर चैनल के लिए पैसे भी दे सकता है। पेत्र को प्राप्ति की जगह मिलती है, दूसरे पक्ष का पैसा उपहार में नहीं। Lightning Pool के दस्तावेज़ ऐसे समझौतों का बाज़ार बताते हैं: bid तरलता की माँग और ask उसे देने की पेशकश है। किराए की अवधि ब्लॉक में मापी जाती है और उसमें प्रीमियम तथा अन्य शुल्क होते हैं। ब्लॉक लेनदेन का एक समूह है जो बिटकॉइन के सार्वजनिक लेनदेन इतिहास, यानी ब्लॉकचेन, में जुड़ता है। इसलिए अवधि नए ब्लॉक जुड़ने से पूरी होती है, घंटों की किसी बिल्कुल तय संख्या से नहीं। यह पूरे दूरस्थ शेष की खरीद नहीं है। तय अवधि का मतलब यह भी नहीं कि पूरे समय वही राशि लेने योग्य रहेगी; भुगतान से बँटवारा बदलता है। समझौता खत्म होने के बाद चैनल हमेशा उपलब्ध रहेगा, यह भी नहीं मान सकते। [1] [5]

पेत्र के कई चैनल हो सकते हैं और जगह किसी दूसरे साथी के साथ चाहिए हो सकती है। Circular rebalancing, यानी गोल रास्ते से संतुलन बदलना, उनका भुगतान एक चैनल से नेटवर्क में भेजता है और दूसरे अपने चैनल से वापस लाता है। भेजने वाले चैनल में आने की जगह बढ़ती है, पाने वाले में खर्च होती है। पैसा एक चैनल में पेत्र के हिस्से से दूसरे चैनल में उनके हिस्से में पहुँचता है; नया धन नहीं बनता और रूटिंग शुल्क लगता है। चलने योग्य रास्ता चाहिए। सभी चैनलों के दूरस्थ पक्षों पर पैसे न हों, तो लौटते भुगतान के आने का कोई चैनल नहीं है। सिर्फ इस तरह पैसा घुमाने से समस्या हल नहीं होगी। [1]

सुरक्षित चैनल संचालन के लिए कुछ पैसा आरक्षित रहना चाहिए। कुछ राशि HTLC में अस्थायी रूप से लगी हो सकती है। ये शर्त वाले भुगतान समझौते हैं। प्राप्तकर्ता ऐसा गुप्त मान बताकर पैसे ले सकता है जिससे तय भुगतान हैश की गणना होती हो। हैश यहाँ शर्त की जाँच के लिए इस्तेमाल किया जाने वाला मान है। भुगतान विफल हो तो भेजने वाला पक्ष समय-सीमा के बाद राशि वापस पाने का रास्ता अपना सकता है। चैनल प्रबंधन का विनिर्देश BOLT 2 न्यूनतम राशि, एक साथ जारी HTLC की संख्या और उनकी कुल राशि भी सीमित करता है। इसलिए अगले भुगतान के लिए पूरा remote balance उपलब्ध हो, यह ज़रूरी नहीं। सभी दूरस्थ शेष जोड़कर एक समान रिज़र्व घटाना पर्याप्त नहीं; हर चैनल और उसकी मौजूदा स्थिति अहम है। [2]

भुगतान अक्सर कई नोड से होकर गुजरता है। पेत्र के पास जगह हो, फिर भी उससे पहले का रास्ता बंद या कम पैसे वाला हो सकता है। BOLT 7 में channel_update संदेश बताए गए हैं, जिनसे नोड चैनल की एक दिशा के रूटिंग नियम बताते हैं। इनमें शुल्क और htlc_maximum_msat शामिल हैं—एक शर्त वाले भुगतान की अधिकतम राशि, msat में, जो satoshi का हज़ारवाँ हिस्सा है। ये पूरी राह के ताज़ा शेष का वादा नहीं करते। इसलिए पेत्र की आने वाली गुंजाइश का जोड़ यह गारंटी नहीं देता कि हर खास भेजने वाला उतनी राशि भेज सकेगा। प्राप्तकर्ता की तरलता समाधान का आवश्यक हिस्सा है, अकेला हिस्सा नहीं। [3]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. इस प्रविष्टि का उल्लेख यहाँ भी है Lightning तरलता, Lightning Routing, Lightning Address, Submarine Swap.

DOC · 001Lightning Labs — Managing liquidityदस्तावेज़ DOC · 002BOLT 2 — Channel managementविनिर्देश DOC · 003BOLT 7 — Routing gossipविनिर्देश DOC · 004Lightning Loop — Direction and channel balancesदस्तावेज़ DOC · 005Lightning Pool — Orders and leasesदस्तावेज़ DOC · 006Lightning Labs — Merchant liquidityदस्तावेज़
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है