HTLC

एना Lightning Network से पावेल को 20,000 sat भेजना चाहती है। Sat, satoshi का संक्षिप्त रूप है; यह बिटकॉइन चेन पर इस्तेमाल होने वाली सबसे छोटी इकाई है। दोनों का साझा भुगतान चैनल नहीं है, लेकिन ईवा के जरिए उपयुक्त संपर्क है। चैनल दो लोगों के बीच बिटकॉइन के बँटवारे का समझौता है, जिसे हर भुगतान के लिए ब्लॉक में नया लेनदेन दर्ज किए बिना बदला जा सकता है। ईवा पावेल को सशर्त 20,000 sat देने का प्रस्ताव रखती है और एना ईवा को 20,010 sat का। इस सरल उदाहरण में 10 sat का अंतर ईवा का शुल्क है। ये दो चैनलों में जुड़ी हुई शेष-राशि की तब्दीलियाँ हैं, एक ही खास सिक्के का दोनों चैनलों से गुजरना नहीं। पावेल ऐसा रहस्य जानता है जिससे अपनी शर्त पूरी कर सकता है। फिर ईवा उसी मान का इस्तेमाल एना के साथ कर सकती है। उसे केवल पावेल के वादे पर पहले अपरिवर्तनीय भुगतान नहीं करना पड़ता। रकम कार्यप्रणाली समझाने के लिए है, सामान्य या सुझाया गया शुल्क नहीं। [1]

पावेल भुगतान के लिए 32 बाइट का यादृच्छिक गुप्त मान, payment_preimage, तैयार करता है। SHA-256 उससे payment_hash निकालता है। यह जाँचना आसान है कि उजागर मान सही निशान देता है या नहीं; केवल निशान से अच्छी तरह चुना गया रहस्य निकालना व्यावहारिक रूप से संभव नहीं है। सामान्य BOLT 11 इनवॉइस, यानी Lightning भुगतान अनुरोध, के p फ़ील्ड में हैश होता है, preimage नहीं। पावेल जब भुगतान की शर्त पूरी करता है, रहस्य मार्ग पर वापस भेजा जाता है और संबंधित HTLC जोड़ता है। s फ़ील्ड का payment_secret अलग मान है: यह प्राप्तकर्ता को भुगतान सही ढंग से सँभालने में मदद करता है, preimage की जगह नहीं लेता। इनमें से कोई भी मान Seed Phrase (वॉलेट वापस पाने के लिए इस्तेमाल होने वाले शब्द) या वॉलेट की निजी कुंजी नहीं है। [1] [4]

यदि दोनों भुगतानों की समय-सीमा एक होती, तो पावेल इतनी देर से रहस्य उजागर कर सकता था कि ईवा आने वाला भुगतान लेने से चूक जाती। इसलिए एना से आने वाले HTLC की समाप्ति, ईवा से पावेल को जाने वाले HTLC के बाद होती है। cltv_expiry_delta कहलाने वाला यह अंतर ईवा को समय का अंतराल देता है। दूसरे पक्ष के जवाब देना बंद कर देने और समझौता बिटकॉइन के ऑन-चेन लेनदेन से लागू करने की जरूरत पड़ने पर भी यह आवश्यक है। यह अंतर ब्लॉक में मापा जाता है, सटीक मिनटों में नहीं, और इसमें देरी तथा चेन पुनर्गठन की गुंजाइश होनी चाहिए। सुरक्षित सेटिंग सॉफ़्टवेयर और चैनल नियम तय करते हैं; बहुत कम अंतर धन को जोखिम में डालता है। चेन के पुनर्गठन में उसका एक हिस्सा दूसरी वैध शाखा से बदल जाता है, जिससे पहले पुष्ट हुए लेनदेन की पुष्टि की स्थिति बदल सकती है। [1]

Lightning में cltv_expiry ब्लॉक की ऊँचाई, यानी चेन में उसका क्रम बताता है। यह Unix timestamp (तारीख और समय को सेकंड की गिनती में बताने वाला मान) या सेकंड में मापी गई BOLT 11 इनवॉइस की वैधता नहीं है। समय की शर्तें पूरी होने पर timeout वाला रास्ता खुल सकता है, जिससे रहस्य के बिना निपटान संभव होता है। धन अपने आप नहीं चलता: भुगतान चैनल सँभालने वाले प्रोग्राम, यानी Lightning नोड, को चैनल बदलाव सही ढंग से पूरा करना या संबंधित ऑन-चेन लेनदेन इस्तेमाल करना होता है। वैध preimage भी समय-सीमा खत्म होते ही अपने आप बेकार नहीं हो जाती। यदि वही आउटपुट, यानी खर्च के नियमों वाली राशि, दूसरे तरीके से पहले ही खर्च नहीं हुआ है, तो अनुमत खर्च के रास्ते प्रतिस्पर्धा कर सकते हैं; दोनों खर्च एक वैध चेन में पुष्ट नहीं हो सकते। इसलिए समय पर कार्रवाई सुरक्षा का हिस्सा है। [1] [4] [5]

HTLC शर्तों को जोड़ता है, लेकिन किसी भी राशि को किसी भी मार्ग से नहीं गुजार सकता। ईवा के पास बाहर जाने वाली दिशा में पर्याप्त धन, यानी तरलता, और एक और लंबित HTLC के लिए जगह होनी चाहिए। सीमाएँ, शुल्क या अनुपलब्ध नोड भुगतान रोक सकते हैं। लंबित प्रयास ठीक से सुलझने तक कुछ धन बँधा रह सकता है। वॉलेट की स्थिति पूरे प्रयास की जानकारी देती है; केवल एक संदेश परिणाम का प्रमाण नहीं है। preimage उजागर करना बिटकॉइन लेनदेन की पुष्टि नहीं है। सामान्य सफल Lightning भुगतान चैनल बदलावों से निपटता है, हर भुगतान को नए ब्लॉक में दर्ज किए बिना। [1] [3]

आगे के भाग तकनीकी संदर्भ हैं। चैनल की अवस्था बताती है कि किस राशि का अधिकार किसे है और कौन-से HTLC अभी लंबित हैं। Commitment transaction हस्ताक्षरित बिटकॉइन लेनदेन है जिससे उस अवस्था को ऑन-चेन लागू किया जा सकता है। update_add_htlc केवल जोड़ने का प्रस्ताव है; update_fulfill_htlc पूर्ति और update_fail_htlc विफलता बताता है। बदलाव घोषित करना पर्याप्त नहीं। commitment_signed और revoke_and_ack से दोनों पक्ष नई अवस्था के हस्ताक्षर और ऐसी जानकारी साझा करते हैं जिससे पुरानी अवस्था इस्तेमाल करना असुरक्षित हो जाता है। BOLT 2 के अनुसार दोनों को संबंधित बदलाव अपरिवर्तनीय रूप से स्वीकार करना होता है, तभी अगला दायित्व उस पर आधारित हो सकता है। प्रतिभागियों की यह सहमति ब्लॉक की पुष्टि नहीं है। वहीं चैनल में धन डालना और जरूरत पड़ने पर उसे बंद करना बिटकॉइन लेनदेन पर आधारित है। [1]

फ़ील्ड संदेश के अलग-अलग मान हैं। Millisatoshi, satoshi का हजारवाँ भाग है और Lightning के भीतर हिसाब की इकाई है; बिटकॉइन चेन पर इस अंश को अलग से खर्च नहीं किया जा सकता। update_add_htlc संदेश के मूल फ़ील्ड channel_id, id, amount_msat, payment_hash, cltv_expiry और onion_routing_packet हैं। amount_msat की इकाई millisatoshi है। नोड चैनल सीमाएँ, उपलब्ध तरलता और अग्रेषण शर्तें जाँचता है; आउटगोइंग HTLC के अपने पैरामीटर होते हैं। BOLT 2 के अनुसार इनकमिंग HTLC का जोड़ना अपरिवर्तनीय रूप से प्रतिबद्ध होने से पहले संबंधित आउटगोइंग HTLC प्रस्तावित नहीं करना चाहिए। [1]

Onion routing हर मध्यस्थ के निर्देश अलग एन्क्रिप्टेड परतों में रखता है। ईवा को अपने चरण की जरूरी जानकारी मिलती है, सभी प्रतिभागियों की खुली सूची नहीं। नोड अपनी onion परत को डिक्रिप्ट करके उसकी अखंडता जाँचता है। सामान्य गैर-ब्लाइंड मार्ग पर वह amt_to_forward और outgoing_cltv_value की तुलना आने वाली राशि, शुल्क और आवश्यक समय अंतर से करता है। पैकेट उसे पूरा मार्ग नहीं बताता। फिर भी ट्रैफ़िक को आपस में जोड़ने या अन्य तरीकों से पहचान का अनुमान लगाने की संभावना रहती है; onion routing पूर्ण गुमनामी की गारंटी नहीं है। [3]

आउटपुट खर्च के नियमों वाली राशि है, जिन नियमों को Script नाम की भाषा में लिखा जाता है। Offered और received चैनल प्रतिभागी के नजरिए से दिए और मिले HTLC हैं। दूसरा चरण अगला लेनदेन है; CHECKSEQUENCEVERIFY (CSV) खर्च किए जा रहे आउटपुट की पुष्टि से गिनी जाने वाली प्रतीक्षा लागू करता है। Revocation कुंजी पुरानी, पहले ही रद्द अवस्था प्रकाशित करने पर दंड लगाने देती है। BOLT 3, offered और received आउटपुट तथा HTLC-success या HTLC-timeout मार्ग अलग करता है। केवल कोई हैश जानना पर्याप्त नहीं: संबंधित हस्ताक्षर, preimage और समय शर्तें लागू होती हैं। दूसरे चरण के स्थानीय आउटपुट पर to_self_delay की CSV देरी होती है, जबकि सही revocation कुंजी दूसरे पक्ष को इस देरी के बिना दंड शाखा उपयोग करने देती है। सटीक Script चैनल के प्रकार पर निर्भर है। [2] [6]

Trimming का अर्थ है कि चैनल की अवस्था ऑन-चेन लाते समय छोटा HTLC अलग आउटपुट नहीं बनता। Dust ऐसे छोटे धन को कहते हैं। Dust exposure इस सीमा के अधीन कुल राशि मापता है। लागू दूसरे चरण का शुल्क घटाने के बाद राशि dust_limit_satoshis से कम हो तो commitment लेनदेन HTLC आउटपुट नहीं बनाता। नियम तय किए गए प्रकार पर निर्भर हैं: option_anchors और zero_fee_commitments में दूसरे चरण का यह शुल्क नहीं होता; zero_fee_commitments छाँटी गई राशि shared_anchor को दे सकता है। मौजूद न होने वाले आउटपुट पर अलग ऑन-चेन दावा नहीं किया जा सकता। ऐसे HTLC का कुल योग dust exposure बनाता है। [2] [1]

आगे की जाँच नोड संचालकों और डेवलपरों के लिए है। Decoding रिकॉर्ड को पढ़ने योग्य फ़ील्ड में बदलती है; यह कुछ भेजती नहीं और अकेले सभी शर्तें पूरी होने का प्रमाण नहीं है। इनकमिंग और आउटगोइंग amount_msat, payment_hash तथा cltv_expiry की तुलना करें; SHA-256 से preimage जाँचें। केवल एक fulfill/fail संदेश नहीं, commitment_signed, revoke_and_ack और अंतिम अवस्था भी देखें। ऑन-चेन प्रवर्तन में वास्तविक commitment लेनदेन डिकोड करें और आउटपुट की मौजूदगी, प्रयुक्त शाखा तथा HTLC-success/HTLC-timeout जाँचें। हस्ताक्षर, समय शर्तें और पुष्टि जाँचें; केवल decoding वैधता साबित नहीं करती। [1] [2]