Package Relay

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

पहली ट्रांज़ैक्शन को parent और उसके आउटपुट को खर्च करने वाली को child कहते हैं। आउटपुट एक निश्चित रकम है जिसे तय शर्तें पूरी करके खर्च किया जा सकता है। अन्ना parent के किसी आउटपुट की शर्तें पूरी कर सके, तो child बना सकती है। उदाहरण के लिए, वह मिले सिक्कों को अपने दूसरे पते पर भेजकर कुछ हिस्सा शुल्क में दे सकती है। यही CPFP (Child Pays for Parent) है: child का ज़्यादा शुल्क दोनों की पुष्टि में मदद कर सकता है। Package Relay भेजने और परखने में मदद करता है; वह शुल्क नहीं भरता, हस्ताक्षर नहीं करता और दूसरे के सिक्के खर्च करने का अधिकार नहीं देता। [1] [5]

मान लें parent का आकार 200 vB और शुल्क 200 sat है, जबकि child का आकार 100 vB और शुल्क 1300 sat है। vByte (vB) ट्रांज़ैक्शन के आभासी आकार की इकाई है, जिससे आमतौर पर शुल्क निकाला जाता है; sat बिटकॉइन की एक छोटी इकाई है। कुल 300 vB के लिए 1500 sat, यानी 5 sat/vB दिए गए। यह अलग-अलग दरों 1 और 13 sat/vB का साधारण औसत नहीं है। यहाँ केवल इन दो ट्रांज़ैक्शन को मान रहे हैं जिन्हें नोड ने अभी स्वीकार नहीं किया है; कोई और अपुष्ट पूर्वज या स्थानीय शुल्क समायोजन नहीं है। वास्तविक नोड पहले से स्वीकार ट्रांज़ैक्शन को दोबारा नहीं गिनता, इसलिए सही निर्भरता-समूह पहचानना ज़रूरी है। [5] [3]

Child का इनपुट parent के आउटपुट की ओर इशारा करता है। दोनों को साथ परखना उपयोगी हो सकता है, लेकिन इससे सिक्कों के गायब इतिहास को नज़रअंदाज़ नहीं किया जा सकता। सूची में शामिल हर parent अपने child से पहले आता है; इसे टोपोलॉजिकल क्रम कहते हैं। हस्ताक्षर और वैधता के दूसरे नियम फिर भी जाँचे जाते हैं। डिजिटल हस्ताक्षर निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का प्रमाण बनाता है, लेकिन उस कुंजी को उजागर नहीं करता। एक ही सिक्के खर्च करने वाली दो ट्रांज़ैक्शन, शुल्क जोड़ने से साथ वैध नहीं हो जातीं। पैकेज की संख्या, आकार और बनावट की सीमाएँ नोड का काम भी सीमित रखती हैं; मनचाही लंबी शृंखला भेजने की अनुमति नहीं देतीं। [5] [3] [7]

वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। पहुँचने का मतलब नोड को डेटा मिल गया। स्वीकार करने का मतलब उसने अपने नियमों के अनुसार ट्रांज़ैक्शन को mempool में रखा। पुष्टि के लिए ब्लॉक में शामिल होना ज़रूरी है। हर नोड का अपना mempool है; एक पर सफलता से पड़ोसी का फैसला नहीं पता चलता। Bitcoin Core 28.0 में संयुक्त दर भरे हुए mempool की बदलती न्यूनतम दर पार करने में मदद कर सकती है, लेकिन आम तौर पर अलग न्यूनतम रिले दर नहीं हटाती। उस संस्करण में विशेष प्रतिबंधों वाली TRUC Transactions के लिए अपवाद है। इसलिए बहुत ज़्यादा शुल्क देने वाला child भी हर parent को नहीं बचा सकता। [2] [5] [8]

Gloria Zhao का BIP 331 समर्थन तय करने और पूर्वजों की जानकारी तथा ट्रांज़ैक्शन माँगने वाले संदेशों का वर्णन करता है। यह अधिक व्यापक प्रस्ताव है। Bitcoin Core 28.0 ने मौजूदा नेटवर्क प्रोटोकॉल से एक parent और एक child को जोड़ने की सीमित सुविधा दर्ज की थी। स्थानीय प्रोग्रामिंग इंटरफ़ेस RPC कई स्वतंत्र parents वाले child को भी स्वीकार कर सकता था, लेकिन इससे नोडों के बीच भेजने की समान क्षमता सिद्ध नहीं होती थी। ये विवरण उसी संस्करण के हैं; दूसरे संस्करण के लिए उसके दस्तावेज़ और सामने वाले नोड का समर्थन जाँचना होगा। [1] [2]

Bitcoin Core 28.0 का submitpackage आदेश तैयार पैकेज स्थानीय नोड को देता है। इसमें child और उसके अपुष्ट parents होने चाहिए, parents एक-दूसरे पर निर्भर न हों और child अंत में हो। package_msg को अलग-अलग tx-results के साथ पढ़ें। नोड पैकेज का कुछ हिस्सा स्वीकार कर सकता है: गलती आने पर पहले से स्वीकार सब कुछ अपने-आप वापस नहीं होता। पूरी सफलता भी नेटवर्क में फैलने या पुष्टि का प्रमाण नहीं है। यह सामान्य भुगतान-त्वरक सेवा नहीं; इसके लिए सही तरह बनाई गई ट्रांज़ैक्शन चाहिए, केवल पते नहीं। [3]

अलग परीक्षण परिवेश में testmempoolaccept बिना प्रसारण किए स्वीकार्यता जाँचता है। कोई दूसरी ट्रांज़ैक्शन विफल हो तो allowed न मिले, क्योंकि संबंधित ट्रांज़ैक्शन की पूरी जाँच नहीं हुई। परीक्षण और submitpackage की शर्तें भी बिल्कुल समान नहीं हैं। संस्करण, सेटिंग, निर्भरताएँ, आकार और शुल्क दर्ज करें, और दूसरे नोड की स्वीकृति अलग से देखें। समय-सीमा वाली Lightning Network ट्रांज़ैक्शन पर समय रहते कार्रवाई अभी भी ज़रूरी है। Package Relay अकेले भीड़, ब्लॉक आने के अनियमित अंतराल या pinning को नहीं मिटाता। pinning में शुल्क बढ़ाना कठिन बनाने के लिए mempool के नियमों का जानबूझकर इस्तेमाल होता है। [4] [2] [1]