56 / 736CHAN

Payment Channel

भुगतान चैनल

भुगतान चैनल में दो पक्ष हर भुगतान को ब्लॉकचेन पर दर्ज किए बिना बार-बार भुगतान कर सकते हैं। बदलता है बिटकॉइन के बँटवारे पर उनका समझौता; उसे ब्लॉकचेन पर निपटाने की क्षमता इस समझौते को आधार देती है। Lightning Network ऐसे ही चैनलों पर काम करता है।

Payment Channel यानी भुगतान चैनल में डिजिटल हस्ताक्षर वाले समझौतों से मिलकर लॉक किए गए बिटकॉइन का बँटवारा बदला जाता है। हस्ताक्षर नए बँटवारे पर सहमति बताते हैं; हर बदलाव ब्लॉकचेन, यानी बिटकॉइन लेनदेन के सार्वजनिक रिकॉर्ड, में दर्ज करना जरूरी नहीं होता। प्रतिभागियों के पास चैनल बंद करके ब्लॉकचेन पर हिसाब निपटाने का रास्ता भी रहता है। यहाँ सामान्य दो-पक्षीय Lightning चैनल समझाया गया है, जिसमें पुराना समझौता वापस लिया जा सकता है और बाद में उसे इस्तेमाल करने पर दंड लगाया जा सकता है। इसे revocation कहते हैं। दूसरे डिज़ाइन के नियम अलग हो सकते हैं।

दो पक्ष मिलकर लॉक की गई रकम पर अपना-अपना अधिकार बदलते रहते हैं। हर भुगतान के लिए ब्लॉक में अलग Bitcoin ट्रांज़ैक्शन की जरूरत नहीं होती। इसके बजाय वे नई स्थिति के हस्ताक्षर साझा करते हैं। यह सिर्फ भरोसे पर चलने वाली तालिका नहीं है: उनके पास ऐसे ट्रांज़ैक्शन होते हैं जिनसे तय शर्तों के अनुसार निपटान लागू किया जा सकता है। [1] [2]

फंडिंग ट्रांज़ैक्शन चैनल में बिटकॉइन डालता है। उसका आउटपुट एक राशि है जिसके नियम बताते हैं कि उसे कौन खर्च कर सकता है; पुष्टि का अर्थ है ट्रांज़ैक्शन का किसी ब्लॉक में शामिल होना। सामान्य Lightning चैनल में इस आउटपुट को खर्च करने के लिए दोनों पक्षों के हस्ताक्षर चाहिए: 2-of-2। फंडिंग प्रसारित करने से पहले प्रतिभागियों के पास एकतरफा बंद करने का वैध रास्ता होना चाहिए। आम तौर पर वे फंडिंग की पुष्टि का इंतजार करते हैं। कुछ शर्तों में zero-conf से पुष्टि का इंतजार किए बिना चैनल इस्तेमाल किया जा सकता है। तब पाने वाला पक्ष चैनल में धन डालने वाले पर अधिक भरोसा करता है: फंडिंग ट्रांज़ैक्शन अभी अपुष्ट है और उसकी जगह वही धन खर्च करने वाली दूसरी ट्रांज़ैक्शन आ सकती है। [2] [3]

Commitment ट्रांज़ैक्शन पर पहले से हस्ताक्षर किए जाते हैं, ताकि मौजूदा सहमति के अनुसार धन बाँटा जा सके। यहाँ नोड वह प्रोग्राम है जो चैनल और उसके अपडेट सँभालता है। हर पक्ष के पास commitment ट्रांज़ैक्शन का अपना संस्करण होता है। अपडेट करते समय नोड commitment_signed और revoke_and_ack के जरिए हस्ताक्षर तथा revocation के गुप्त मानों का समन्वित आदान-प्रदान करते हैं। नया समझौता पुराने हस्ताक्षरित ट्रांज़ैक्शन को Bitcoin के सहमति नियमों के अनुसार अमान्य नहीं बनाता। इसलिए वापस ली गई स्थिति प्रकाशित करने से बचाव आउटपुट खर्च करने की शर्तों में होना चाहिए। [2] [3]

सामान्य revocation चैनल में अपना commitment प्रकाशित करने वाले पक्ष को अपने धन के उपयोग से पहले to_self_delay तक इंतजार करना होता है। यह प्रतीक्षा commitment ट्रांज़ैक्शन की पुष्टि से ब्लॉक की संख्या में गिनी जाती है। यदि उसने वापस ली गई स्थिति प्रकाशित की है, तो दूसरा पक्ष revocation कुंजी से संबंधित आउटपुट खर्च करके सुधारात्मक कार्रवाई कर सकता है। उसे समय पर कदम उठाना और ट्रांज़ैक्शन की पुष्टि करानी होगी। Watchtower एक सेवा है जो चेन पर नजर रखती है और पहले से तैयार जानकारी से वापस ली गई स्थिति प्रकाशित होने पर कार्रवाई कर सकती है। फिर भी यह सेवा सफलता की गारंटी या बैकअप का विकल्प नहीं है। [3] [4]

Sat, satoshi का संक्षिप्त रूप है, जो बिटकॉइन चेन पर इस्तेमाल होने वाली सबसे छोटी इकाई है। क्षमता चैनल की कुल राशि है, हर प्रतिभागी का अलग-अलग बैलेंस नहीं। मान लें चैनल में 100000 sat हैं: ऐलिस के पास 70000 sat और बॉब के पास 30000 sat हैं। ऐलिस, बॉब को 10000 sat देती है तो नया बँटवारा 60000 sat और 40000 sat होगा। उदाहरण सरल रखने के लिए फीस और आरक्षित रकम छोड़ दी गई हैं। क्षमता नहीं बदली, लेकिन ऐलिस अब कम भेज सकती है और अधिक प्राप्त कर सकती है। वास्तविक सीमा पर आरक्षित रकम और चल रहे भुगतान भी असर डालते हैं। [6]

Lightning कई जुड़े चैनलों से होकर रास्ता खोजता है। HTLC एक सशर्त भुगतान है: धन पाने के लिए preimage नाम का गुप्त मान उजागर करना होता है, जिसका हैश, यानी डिजिटल निशान, पहले से ज्ञात मान से मेल खाए। भुगतान पूरा न हो तो समय की शर्तें निपटान का रास्ता देती हैं। मध्यस्थों को लिक्विडिटी, यानी जरूरी दिशा में भेजने के लिए उपलब्ध धन चाहिए, और वे फीस ले सकते हैं। हर व्यापारी से सीधा चैनल जरूरी नहीं, लेकिन केवल कनेक्शन होना किसी भी रकम के लिए उपयोगी रास्ते की गारंटी नहीं है। [2] [4]

आपसी सहमति से बंद करने, यानी cooperative close, में प्रतिभागी बंद करने वाले ट्रांज़ैक्शन, धन के बँटवारे और फीस पर सहमत होते हैं। दोनों हस्ताक्षर करके उसे ब्लॉकचेन पर प्रसारित करते हैं। यह सामान्यतः एकतरफा निपटान से सरल है, लेकिन अपने आप मुफ्त या तत्काल नहीं होता। इस ट्रांज़ैक्शन को भी पुष्टि और नेटवर्क की स्थिति के अनुरूप फीस चाहिए। [2] [4]

एकतरफा बंद करने, यानी force close, में दूसरे पक्ष की नई सहमति के बिना अपना मौजूदा commitment प्रकाशित किया जा सकता है। धन तुरंत खर्च करने योग्य हो, यह जरूरी नहीं: प्रतीक्षा की शर्तें और जरूरत पड़ने पर HTLC का निपटान लागू रहता है। अतिरिक्त ट्रांज़ैक्शन और फीस भी लग सकती हैं। आपात रास्ता मौजूद है, लेकिन उसका समय और खर्च चैनल की स्थिति तथा ब्लॉकचेन की परिस्थितियों पर निर्भर है। [3] [4]

Seed Phrase बैकअप शब्दों का समूह है, जिससे वॉलेट अपनी कुंजियाँ बहाल कर सकता है। लेकिन अकेले इन शब्दों से खुले चैनल की नवीनतम स्थिति वापस नहीं आती, इसलिए अपने वॉलेट की बहाली प्रक्रिया अपनाएँ। उदाहरण के लिए, Lightning नोड चलाने वाला प्रोग्राम LND इन शब्दों के साथ Static Channel Backup (SCB) का इस्तेमाल करता है। इस स्थिर बैकअप में दूसरे पक्षों से संपर्क करने और चैनल बंद करने का अनुरोध भेजने के लिए जरूरी जानकारी रहती है; इससे चैनल बहाल करके भुगतान जारी नहीं रखे जा सकते। इस तरह बहाली दूसरे पक्षों के जवाब देने पर भी निर्भर करती है। इसके विपरीत channel.db चैनलों की डेटाबेस फ़ाइल है, जिसकी पुरानी कॉपी में खतरनाक रूप से पुरानी स्थिति हो सकती है। चैनल की “मरम्मत” के लिए अपने असली बैकअप शब्द किसी अन्य की वेबसाइट पर कभी न डालें। [5]

पता करें कि कुंजियाँ किसके पास हैं, चैनलों की निगरानी कौन करता है और डिवाइस खोने पर पहुँच कैसे बहाल होगी। कस्टोडियल का मतलब है कि सेवा देने वाला कुंजियाँ रखता है। कस्टोडियल सेवा में दिखने वाला Lightning बैलेंस जरूरी नहीं कि आपका अपना चैनल हो। खुद कुंजियाँ रखने पर बैकअप, उपलब्धता और समस्याओं से निपटने की जिम्मेदारी आपकी है। चैनल ब्लॉकचेन पर दर्ज होने वाली प्रविष्टियाँ घटाते हैं; वे सभी संचालन संबंधी जिम्मेदारियाँ या निपटान का खर्च नहीं मिटाते। [4] [5]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Lightning Network, HTLC, Lightning तरलता, Lightning Watchtower. इस प्रविष्टि का उल्लेख यहाँ भी है पुष्टि, दोहरा खर्च, Timelock, HTLC.

DOC · 001Lightning Network paperप्राथमिक स्रोत DOC · 002BOLT #2 — Channel lifecycleप्राथमिक स्रोत DOC · 003BOLT #3 — Transaction and script formatsप्राथमिक स्रोत DOC · 004BOLT #5 — On-chain handlingप्राथमिक स्रोत DOC · 005Lightning Labs — Disaster recoveryदस्तावेज़ DOC · 006Lightning Labs — Managing Liquidityदस्तावेज़
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है