अलग-अलग गवाह को अद्यतन करने और बिटकॉइन में इसके गोद लेने के परिणामों पर विवरण

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

इस अद्यतन में सभी परिवर्तनों के विस्तृत विवरण पर आगे बढ़ने से पहले, हम सुझाव देते हैं कि आप सेग्रीगेशन गवाह के मुख्य विचार से परिचित हों। वास्तव में, अलग-अलग गवाह को अंग्रेजी से "अलग गवाह" के रूप में अनुवादित किया गया है। बिटकॉइन प्रतियोगिता का तात्पर्य है कि लेनदेन के मास्टर डेटा से सिक्कों के स्वामित्व के साक्ष्य को अलग से संग्रहीत किया जाएगा, जैसा कि आरेख में दर्शाया गया है।

यदि हम संपूर्ण प्रोटोकॉल अपडेट पर विचार करते हैं, तो इसमें कई अन्य सुधार शामिल हैं। SegWit आपको नेटवर्क बैंडविड्थ बढ़ाने, लेनदेन के बाकी डेटा से सिक्कों के स्वामित्व के सबूतों को अलग करने, प्रोटोकॉल के पिछले संस्करणों के दौरान पिछड़ी संगतता बनाए रखने के दौरान हस्ताक्षरित लेनदेन (लेनदेन मॉलबिलिटी) में डेटा को संशोधित करने की क्षमता के साथ जुड़े लेनदेन प्रारूप में खामियों को ठीक करने की अनुमति देता है। और इस अद्यतन का सबसे बड़ा मूल्य यह है कि यह आपको बिटकॉइन प्रोटोकॉल के शीर्ष पर कई बहुत महत्वपूर्ण ऑफ-चेन समाधानों को लागू करने की अनुमति देता है।

लेनदेन की विकृति समस्या और समाधान

लब्बोलुआब यह है कि बिटकॉइन में काम करते समय लेनदेन को बदलने का अवसर होता है ताकि सत्यापन के दौरान यह सही रहे। ये परिवर्तन बहुत मामूली हैं, वे प्रेषक और प्राप्तकर्ता के पते को प्रभावित नहीं करते हैं, लेकिन वे हैश के परिणाम को बदलने के लिए पर्याप्त हैं। दूसरे शब्दों में, लेन-देन सिक्कों को उनके पिछले पते पर स्थानांतरित कर देगा, लेकिन इसका बदला हुआ हैश मूल्य अब मूल लेनदेन के साथ संशोधित लेनदेन से मेल नहीं खाएगा।

जाहिर है, ऊपर वर्णित स्थिति केवल उन लेनदेन के साथ हो सकती है जिन्हें अभी तक पुष्टि नहीं मिली है। इसके समाधान के बिना, ऑफ-चेन प्रोटोकॉल के विश्वसनीय संचालन को प्राप्त करना असंभव है, जिसमें अपुष्ट लेनदेन की श्रृंखलाओं का निर्माण शामिल है। लेन-देन संकलित करने के बाद से, सभी डेटा पर हस्ताक्षर नहीं किए जाते हैं (उदाहरण के लिए, आप स्क्रिप्टसिग पर हस्ताक्षर नहीं कर सकते हैं), कई प्रकार के हमलों की संभावना है:

1. हस्ताक्षर प्रारूप बदलें । बिटकॉइन प्रोटोकॉल में, हस्ताक्षर प्रारूप को कड़ाई से अनुमोदित नहीं किया गया है और ओपनएसएसएल पुस्तकालय के कार्यान्वयन पर निर्भर करता है, जिसमें हस्ताक्षर के लिए सख्त प्रारूप भी परिभाषित नहीं है। एक तृतीय पक्ष इंटरसेप्टेड ट्रांजेक्शन को संशोधित कर सकता है, जो हैश वैल्यू में बदलाव लाएगा।
2. सीधे ScriptSig पर प्रभाव । जैसा कि पहले उल्लेख किया गया है, स्क्रिप्टसिग में साक्ष्य को सत्यापित करने के लिए संचालन का एक सेट होता है जो एक विशेष उपयोगकर्ता सिक्कों का मालिक होता है। लेकिन इन ऑपरेशनों के अलावा, आप इसमें दूसरों को भी जोड़ सकते हैं। कुछ हानिरहित संचालन जो कुछ भी प्रभावित नहीं करते हैं, लेन-देन के हैश मूल्य में बदलाव लाएंगे।
   

इस प्रकार, आप निजी कुंजी तक पहुंच के बिना लेनदेन के हैश मूल्य को बदल सकते हैं। एक हैश मूल्य इतना अवांछनीय क्यों बदल रहा है?

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

ऑफ-चेन प्रोटोकॉल ऊपर उल्लेख किया गया है। उनके कार्यान्वयन के लिए, लेनदेन की विकृति की समस्या का समाधान आवश्यक है। अपने काम के दिल में अपुष्ट लेनदेन की श्रृंखला का निर्माण कर रहा है। पहले लेन-देन के हैश मूल्य को बदलने से अपुष्ट लोगों की पूरी श्रृंखला की अमान्यता हो जाएगी।

सेगविट अपडेट ने खेतों में भरने के लिए सख्त नियमों को परिभाषित किया है, इसलिए नए प्रारूप के लेनदेन के लिए लेन-देन की समस्या से जुड़ी समस्याओं को हल किया जा सकता है। इसने हमें डेटा निर्दिष्ट करने और उन्हें स्पष्ट रूप से दोहराए जाने को नष्ट करने के लिए क्रमबद्ध करने की अनुमति दी।

एक नेटवर्क पर एक ब्लॉक वितरित करते समय पिछड़े संगतता

पुराने नियमों के अनुसार, अधिकतम ब्लॉक आकार 1 एमबी है और इसमें अंतर्निहित सबूत के साथ लेनदेन शामिल है। जबकि नए नियम मानते हैं कि अधिकतम बेस ब्लॉक का आकार 1 एमबी है, लेकिन इसके अलावा साक्ष्य के साथ एक डेटा संरचना है। तदनुसार, नए ब्लॉक का कुल आकार 1 एमबी से अधिक है।

पिछड़ी संगतता के लिए, प्रोटोकॉल नियम पुराने नोड्स को नए ब्लॉकों के साथ काम करने की अनुमति देते हैं, लेकिन वे केवल 1 एमबी के अधिकतम आकार के साथ बुनियादी कॉन्फ़िगरेशन में ब्लॉक प्राप्त करेंगे। गवाह संरचना उनके लिए उपलब्ध नहीं है। नए नोड्स को लेनदेन और सबूत के साथ एक पूर्ण ब्लॉक मिलता है। निम्नलिखित आंकड़ा आपको इस प्रश्न से खुद को परिचित करने में मदद करेगा।



बाईं ओर, अलग-अलग गवाह की सक्रियता से पहले बिटकॉइन प्रोटोकॉल के संचालन का एक आरेख है। ब्लॉक में अधिकतम 1 एमबी का आकार था, और इसे विभिन्न नेटवर्क नोड्स के बीच एक रूप में वितरित किया गया था।

चूंकि ब्लॉक का आकार सीमित है, इसलिए इसमें लेन-देन की संख्या भी सीमित हो सकती है, और सिस्टम की क्षमता इस पर निर्भर करती है। बेशक, जब सवाल बढ़ते हुए विवाद से उठता है, तो पहली चीज जो वे देखना शुरू करते हैं, वह अधिकतम ब्लॉक आकार बढ़ाने के तरीके थे।

थ्रूपुट बढ़ाने के तरीके

बढ़ती प्रणाली थ्रूपुट की समस्या को हल करने के दो मुख्य तरीकों पर विचार करें। किसी भी प्रस्ताव को बिटकॉइन प्रोटोकॉल की विकास टीम द्वारा सावधानीपूर्वक जांचा और परखा गया है। यदि समुदाय ने समझौता किया है और प्रोटोकॉल में प्रस्ताव को लागू करने का निर्णय लिया है, तो एक अद्यतन जारी किया जाता है।

हार्डफॉर्क अपडेट। अपडेट का सबसे आम है ब्लॉक का आकार बढ़ाना। यह माना जाता है कि एक इकाई अधिक लेनदेन को समायोजित करेगी, जिससे थ्रूपुट बढ़ेगा। हालांकि, इस तरह की इकाई को पुराने प्रोटोकॉल के अनुसार काम करने वाले नोड्स द्वारा स्वीकार नहीं किया जाएगा, जिस नियम के अनुसार अधिकतम ब्लॉक आकार 1 लाख से अधिक नहीं हो सकता है। इस तरह के बदलाव के लिए हार्डफॉर्क की आवश्यकता होती है, जो सॉफ्टफॉर्क की तुलना में संगठनात्मक रूप से अधिक जटिल है।

सॉफ्टफोर्क अपडेट। अलग-अलग गवाह हमें सॉफ्टफ़ॉर्क के साथ इस समस्या को हल करने की अनुमति देते हैं। बिल्कुल कैसे? यह हमें ब्लॉक को दो भागों में विभाजित करने की अनुमति देता है, जिनमें से पहला लेनदेन को संग्रहीत करता है, और दूसरे में साक्ष्य होते हैं। उसी समय, नए नेटवर्क नोड्स दोनों भागों को प्राप्त करते हैं, जबकि पुराने केवल 1 एमबी लेनदेन ब्लॉक प्राप्त करते हैं। पुराने नोड्स सबूत के साथ ब्लॉक प्राप्त नहीं कर सकते हैं और तदनुसार, वे प्राप्त लेनदेन को मान्य नहीं कर सकते हैं, लेकिन यह उन्हें आम सहमति भवन में भाग लेने और हार्डकॉफ़ का सहारा लेने की अनुमति नहीं देता है, लेकिन धीरे-धीरे नए सॉफ्टवेयर पर स्विच करने के लिए।

नवाचारों के साक्षी बने

गौर कीजिए कि अलग-अलग गवाह के अपडेट में क्या शामिल है। अलग-थलग गवाह का पहला और सबसे महत्वपूर्ण नवाचार नया लेनदेन क्रमांकन प्रारूप है। पहले से ही ज्ञात क्षेत्रों के अलावा, नए लेनदेन में तीन नए क्षेत्र हैं: मार्कर, ध्वज, जो संस्करण के लिए उपयोग किए जाते हैं और इस मामले में वे कड़ाई से सेट होते हैं, लेकिन निम्नलिखित प्रोटोकॉल में वे बदल सकते हैं, साथ ही साथ साक्षी क्षेत्र भी। साक्षी (गवाह डेटा) वास्तव में उन सिक्कों के स्वामित्व के साक्ष्य का एक सेट है जो लेनदेन के मुख्य भाग से बाहर ले जाया जाता है। संरचनात्मक रूप से, यह इनपुट का एक सेट जैसा दिखता है, प्रत्येक गवाह डेटा तत्व में एक विशिष्ट संख्या के साथ इनपुट के अनुरूप होता है, जो आपको खर्च किए गए विशिष्ट सिक्कों के साथ साक्ष्य की तुलना करने की अनुमति देता है।

साक्षी लेन-देन आई.डी.

लेन-देन पहचानकर्ता (ट्रांजेक्शन आईडी, txid) प्राप्त करने के लिए, आपको लेन-देन को एक विशेष अनुक्रमिक प्रारूप में एक डेटा अनुक्रम में लाने की आवश्यकता है, और फिर इस डेटा अनुक्रम से हैश मान प्राप्त करें। अलग-अलग गवाह की शुरूआत के साथ, एक नया पहचानकर्ता, गवाह लेनदेन आईडी (wtxid), और एक नया क्रमांकन प्रारूप, क्रमशः दिखाई दिया। पुराने लेन-देन के लिए जो अलग-अलग गवाह का उपयोग किए बिना पैसे खर्च करते हैं, wtxid txid के समान होगा क्योंकि उनके पास अलग-अलग गवाहों के साथ जोड़े गए नए क्षेत्र नहीं होंगे।



सबूत के लिए वैकल्पिक मर्कल ट्री बनाने के लिए Wtxid की आवश्यकता होती है। यह उसी तरह बनाया गया है जैसे कि साधारण लेनदेन के लिए, लेन-देन हैश के बजाय केवल wtxid का उपयोग किया जाता है। तदनुसार, wtxid को जोड़ियों में हैशड किया जाता है और परिणामस्वरूप मर्कल रूट होता है।

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

सिक्के खर्च करने के लिए शर्तें निर्धारित करने के लिए साक्षी कार्यक्रम

आइए देखें कि अलग-अलग गवाह लेन-देन की लिपि कैसे बनाई जाती है और यह पुराने नेटवर्क नोड्स को यह समझने की अनुमति देता है कि अलग-अलग गवाह लेनदेन सही हैं, इस तथ्य के बावजूद कि उन्हें सिक्कों के स्वामित्व के प्रमाण नहीं मिलते हैं।

नए प्रारूप लेनदेन से सिक्के खर्च करने के नियमों का वर्णन करने वाली स्क्रिप्ट में दो भाग होते हैं। पहला भाग गवाह संस्करण बाइट (गवाह कार्यक्रम के संस्करण को निर्दिष्ट करने वाला बाइट) है। यह 0 से 16 (OP0-OP16) तक मान ले सकता है, अब यह OP0 का उपयोग करता है। भविष्य में, प्रोटोकॉल के नए संस्करण गवाह कार्यक्रम के अन्य संस्करणों के लिए समर्थन के साथ दिखाई दे सकते हैं। दूसरा भाग साक्षी कार्यक्रम है। इस भाग में 2 से 40 बाइट्स का आकार हो सकता है।

साक्षी कार्यक्रम साक्षी पटकथा हैशिंग का परिणाम है। गवाह लिपि में ही सिक्कों को खर्च करने की शर्तों का पूरा विवरण है। साक्षी डेटा में सिक्कों के स्वामित्व का प्रमाण होता है जिसे गवाह लिपि में शर्तों को पूरा करना चाहिए। तदनुसार, साक्षी डेटा में हमेशा दो भाग होते हैं: एक गवाह लिपि और सिक्कों के स्वामित्व का प्रमाण।

यह ध्यान देने योग्य है कि गवाह कार्यक्रम में कोई भी संचालन नहीं होता है (हैश मान मिलान, इलेक्ट्रॉनिक हस्ताक्षर का सत्यापन), और स्क्रिप्ट स्वयं ओपी कोड के साथ शुरू होती है, इसलिए, यह सभी पुराने नोड्स के लिए मान्य है। इसके अलावा, नोड्स जिन्हें सेगविट में अपडेट नहीं किया गया है वे नए प्रारूप आउटपुट के लिए सिक्कों के स्वामित्व के साक्ष्य की जांच नहीं करते हैं; वे इस तरह के कचरे को किसी भी मामले में सही मानते हैं। कड़ाई से बोलने पर, पुराने नोड्स एक नए प्रारूप के लेनदेन को स्वीकार करेंगे भले ही इसका प्रेषक वास्तव में संबंधित सिक्कों का मालिक न हो। यही कारण है कि SegWit की आवश्यकता है कि अधिकांश बिटकॉइन खनन शक्ति के मालिक इस अपडेट को स्वीकार करते हैं। एक और विशेषता यह है कि नए प्रारूप के आउटपुट से सिक्के खर्च करने वाले लेनदेन का स्क्रिप्टसिग खाली होगा।

सिक्के खर्च करने के लिए शर्तें निर्धारित करने के लिए नए विकल्प

SegWit की शुरुआत के साथ, scriptPubKey के लिए दो मानक प्रारूप प्रस्तावित किए गए थे, जो इस अद्यतन के सामने आने से पहले सिक्का खर्च करने के नियमों को स्थापित करने के लिए दो सबसे सामान्य प्रारूपों के लिए एक विकल्प बन गया। आइए उन पर विचार करें।

सार्वजनिक कुंजी हैश (P2WPKH) को देखने के लिए भुगतान सार्वजनिक कुंजी हैश के लिए मानक वेतन का एक एनालॉग है। इसका अंतर क्या है? जैसा कि पहले उल्लेख किया गया है, स्क्रिप्टसिग आबाद नहीं है और खाली रहता है। सिक्कों के स्वामित्व के सभी साक्ष्य साक्षी डेटा संरचना में स्थानांतरित किए जाते हैं।

इस मामले में, पहले जो स्क्रिप्ट पर विचार किया गया था, सार्वजनिक कुंजी का संस्करण और हैश, जो कि गवाह कार्यक्रम है, स्क्रिप्ट स्क्रिप्ट में डाला जाता है। नेटवर्क पर एक नोड इस तरह के खर्च की स्क्रिप्ट को इस तथ्य के कारण दूसरों से अलग करता है कि इसमें एक संस्करण और 20 बाइट्स का डेटा आकार है। एक और संस्करण और एक अलग आकार अलग-अलग खर्च करने के नियम ले जाता है।



इस स्थिति में, ScriptPubKey में दो भाग होते हैं: साक्षी संस्करण संख्या शून्य है और प्राप्तकर्ता की सार्वजनिक कुंजी का हैश मान है। ScriptSig खाली होगा, और साक्षी डेटा में एक इलेक्ट्रॉनिक हस्ताक्षर और इसे सत्यापित करने के लिए एक सार्वजनिक कुंजी होगी।

पे टू गवाह स्क्रिप्ट हैश (P2WSH) स्क्रिप्ट हैश के लिए मानक वेतन का एक एनालॉग है। इस मामले में, सिक्कों को खर्च करने के नियमों को निर्धारित करने के लिए एक कस्टम स्क्रिप्ट का उपयोग किया जा सकता है। एक मेजबान इस तरह की स्क्रिप्ट को पिछले एक से कैसे अलग करता है? इस स्थिति में, संस्करण में अभी भी एक का मूल्य है, और गवाह कार्यक्रम 32 बाइट्स लेता है और गवाह स्क्रिप्ट से एक हैश मान है। यदि किसी प्रकार की स्क्रिप्ट वाली लेन-देन होस्ट में आती है, जिसका पहला संस्करण होगा, लेकिन इसका आकार 20 या 32 बाइट्स के मूल्यों से भिन्न होगा, तो होस्ट इस लेनदेन को अस्वीकार कर देगा क्योंकि यह नहीं जानता कि इसके साथ कैसे काम करना है।

यहां साक्षी डेटा को दो भागों में विभाजित किया गया है। पहले में सिक्कों के स्वामित्व के साक्ष्य का एक सेट होता है, यानी हस्ताक्षर का एक सेट। दूसरे भाग में, एक गवाह स्क्रिप्ट रखी जाती है, जिसकी सामग्री सिर्फ सिक्के खर्च करने के नियम निर्धारित करती है, लेकिन इस मामले में खर्च के समय इसे इंगित किया जाता है, और सिक्कों को भेजने के समय इसके हैश मूल्य का संकेत दिया जाता है।

इस स्थिति में, scriptPubKey में दो भाग होते हैं: संस्करण की साक्षी संख्या शून्य है और बहु-हस्ताक्षर 1-2 के मामले के लिए गवाह स्क्रिप्ट का हैश मान। ScriptSig खाली होगा, और साक्षी डेटा में इलेक्ट्रॉनिक हस्ताक्षर और स्पष्ट पाठ में मूल गवाह स्क्रिप्ट होगी।

P2SH आवरण

नया स्क्रिप्ट प्रारूप पुराने से अलग है। तदनुसार, पुरानी सेवाओं और पर्स को यह नहीं पता होगा कि इस स्क्रिप्ट प्रारूप के साथ कैसे काम करना है और इसे कैसे लिखना है। पिछड़े संगतता के लिए, P2SH का उपयोग करके अलग-अलग गवाह लेनदेन एक विशेष "आवरण" का उपयोग करते हैं, जो आपको एक लेनदेन बनाने की अनुमति देता है जिसमें एक अलग-अलग गवाह लेनदेन के गुण होते हैं, लेकिन बाहरी दुनिया के लिए सामान्य P2SH से भिन्न नहीं होता है।

P2SH का उपयोग प्रेषक के काम को सरल बनाने के लिए किया जाता है और उसे रिसीवर के रिडीम स्क्रिप्ट के कार्यान्वयन के विवरण के साथ बोझ नहीं करता है। इस मामले में, प्राप्तकर्ता प्रेषक को केवल रिडीम स्क्रिप्ट हैश मूल्य देता है, और स्क्रिप्ट स्वयं सबूत के साथ स्क्रिप्टसिग के पास जाती है।



इस स्थिति में, scriptPubKey में एक हैश ऑपरेशन, एक रिडीम डिफरेंश हैश मान और एक तुलना ऑपरेशन (P2SH के पुराने संस्करण के लिए) होता है। यहां ScriptSig में सार्वजनिक कुंजी का हैश मान होगा, और गवाह डेटा में इलेक्ट्रॉनिक हस्ताक्षर और सार्वजनिक कुंजी होगी।

यह दृष्टिकोण गैर-अपडेट किए गए डिजिटल पर्स को सिक्कों को खर्च करने की शर्तों को निर्धारित करने के नए तरीकों के बारे में कुछ भी जाने बिना, अलग-अलग गवाह के पते पर लेनदेन भेजने की अनुमति देता है।

नई Bech32 पता प्रारूप

यह अलग-अलग Bech32 पतों का उल्लेख करने योग्य है, जिन्हें मूल SegWit पते माना जाता है। अपने अधिकांश इतिहास के लिए, बिटकॉइन ने एक चेकसम के अलावा के पते के लिए बेस 58 एनकोडिंग का उपयोग किया है, जो SHA-256 हैश फ़ंक्शन का उपयोग करके डबल हैशिंग का एक छोटा परिणाम है। वे मूल सॉफ़्टवेयर का हिस्सा थे और P2SH के लिए BIP13 में उनका दायरा बढ़ाया गया था। लेकिन दोनों वर्ण सेट और चेकसम एल्गोरिथ्म की सीमाएँ हैं:

• बेस 58 में पता क्यूआर कोड में अधिक मेमोरी लेता है, क्योंकि यह अल्फ़ान्यूमेरिक प्रतिनिधित्व मोड का उपयोग नहीं कर सकता है;
• base58 विश्वसनीय लेखन के लिए कागज के लिए बहुत असुविधाजनक है, एक मोबाइल कीबोर्ड से टाइप करना या जोर से पढ़ना;
• डबल चेकसम हैशिंग धीमी है;
• आधार 58 डिकोडिंग जटिल और अपेक्षाकृत धीमी है।

सेगविट अपडेट में एक्ज़िट (गवाह कार्यक्रमों) का एक नया वर्ग और इसके दो मामले शामिल हैं: पी 2 डब्ल्यूपीकेएच और पी 2 डब्ल्यूएसएच। पी 2 एस के उपयोग के माध्यम से पुराने नोड्स के लिए उनकी कार्यक्षमता अप्रत्यक्ष रूप से उपलब्ध है, लेकिन यह सीधे उपयोग करने के लिए अधिक इष्टतम और सुरक्षित होगा, इसके लिए एक नया पता प्रारूप पेश करना आवश्यक है।

Bech32 पता विशिष्टता

Bech32 पते की लंबाई 90 से अधिक वर्ण नहीं है और इसमें शामिल हैं:

1. एक हिस्सा जो मानव पठनीय है। इसमें ऐसे डेटा शामिल हैं जिन्हें प्रेषित करने की आवश्यकता हो सकती है या जिनके पास पते के स्वामी के साथ कम से कम 1 वर्ण लंबा होना चाहिए। उदाहरण के लिए, मेननेट पते के लिए डिफ़ॉल्ट रूप से अक्षर "bc" हैं, और टेस्टनेट के लिए वर्ण "tb" हैं।
2. एक परिसीमन जो हमेशा 1 होता है। यदि मानव पठनीय भाग के अंदर "1" की अनुमति है, तो विभाजक "1" वर्णों में से अंतिम है।
   
3. डेटा भाग की लंबाई कम से कम 6 वर्ण होती है और इसमें केवल "1", "b", "i" और "o" को छोड़कर अल्फ़ान्यूमेरिक वर्ण होते हैं। यहां गवाह कार्यक्रम के संस्करण और गवाह कार्यक्रम के डेटा को स्वयं (2 से 40 बाइट्स) मुख्य डेटा के रूप में यहां उपयोग किया जाता है।
   

पतों में एक विभाजक क्यों शामिल है? यह आपको उप-योग का उपयोग करने वाले अन्य मानव-पठनीय भागों के साथ संभावित टकरावों से बचने के लिए मानव-पठनीय भाग को डेटा-पठनीय भाग से स्पष्ट रूप से अलग करने की अनुमति देता है। यह मानव-पठनीय भाग के लिए वर्ण सेट प्रतिबंधों से भी बचता है। विभाजक 1 है क्योंकि गैर-अल्फ़ान्यूमेरिक वर्ण का उपयोग करने से पते (कई अनुप्रयोगों में डबल-क्लिक किए बिना) को कॉपी करना मुश्किल हो जाता है। इसलिए, मुख्य वर्ण सेट के बाहर एक अल्फ़ान्यूमेरिक वर्ण चुना गया था। साथ ही, आधार 32 नंबर सिस्टम का उपयोग आधार 58 नंबर सिस्टम की तुलना में पते की लंबाई में 15% की वृद्धि के साथ होता है, लेकिन पते की नकल करते समय यह कोई फर्क नहीं पड़ता।

चेकसम Be3232 पते

पते के अंतिम 6 अक्षर एक चेकसम हैं। चेकसम BCH कोड के आधार पर बनाया गया है, जो 4 से अधिक वर्णों को प्रभावित करने वाले किसी भी त्रुटि का पता लगाने की गारंटी देता है, और यह मौका कि 4 से अधिक त्रुटियां होने पर चेकसम अभिसरण करेगा 109 में से एक है।

BCH कोड का उपयोग करने का एक लाभ यह है कि उनका उपयोग त्रुटियों को ठीक करने के लिए किया जा सकता है। यदि पते में 4 त्रुटियां की गईं, तो वे अपने आप सही हो जाएंगे। और यदि अधिक त्रुटियां होती हैं, तो उन्हें उच्च संभावना के साथ पता लगाया जाएगा, लेकिन उनके स्वत: सुधार की संभावना के बिना।

पते में ऊपरी और निचले मामले

लोअर केस का उपयोग तब किया जाता है जब चेकसम के लिए कैरेक्टर वैल्यू की आवश्यकता होती है।

सॉफ्टवेयर हमेशा पूरे Bech32 एड्रेस स्ट्रिंग को लोअर केस में प्रदर्शित करता है।यदि एक अपरकेस संस्करण की आवश्यकता होती है (उदाहरण के लिए, क्यूआर कोड में प्रस्तुति या उपयोग के लिए), तो यह वैकल्पिक रूप से उपलब्ध है। इसके अलावा, सॉफ्टवेयर उन पतों को स्वीकार नहीं करेगा जिनमें कुछ अक्षर ऊपरी स्थिति में हैं और कुछ निचले मामले में हैं। लोअर केस आमतौर पर प्रदर्शन के लिए बेहतर होता है, लेकिन क्यूआर कोड के लिए ऊपरी मामले का उपयोग किया जाना चाहिए क्योंकि यह एक अल्फ़ान्यूमेरिक प्रतिनिधित्व की अनुमति देता है जो बाइट प्रतिनिधित्व की तुलना में 45% अधिक कॉम्पैक्ट होता है।

वजन और ब्लॉक आकार की अवधारणाओं

अलग-अलग गवाह अपडेट द्वारा शुरू किया गया एक और बड़ा बदलाव लेन-देन वजन और ब्लॉक वजन जैसी अवधारणाओं का परिचय है। अलग-अलग गवाहों से पहले, वे आमतौर पर लेन-देन के आकार और ब्लॉक आकार के बारे में बात करते थे। हालांकि, ब्लॉक का आकार 1 एमबी तक सीमित था। अपडेट को सक्रिय करने के बाद, दो लेनदेन प्रारूप हैं। तदनुसार, दोनों को और अधिक समर्थन की आवश्यकता है।

इस समस्या को हल करने के लिए, लेनदेन के वजन और इसी वजन इकाइयों की अवधारणा को पेश किया गया था। लेन-देन के मुख्य भाग का आकार अब 3 के गुणांक के साथ ध्यान में रखा जाता है, और 1. के गुणांक के साथ गवाह डेटा का आकार। जैसा कि आप अनुमान लगा सकते हैं, किसी भी डेटा को गवाह डेटा में शामिल किया गया था जो लेनदेन के मुख्य डेटा की तुलना में 3 गुना कम कमीशन की आवश्यकता है। इस तरह का दृष्टिकोण सत्यापनकर्ताओं को ब्लॉक में रखे गए स्थान और प्राप्त इनाम के संबंध में अधिक लाभदायक लेनदेन निर्धारित करने की अनुमति देता है। वजन की गणना एक विशेष सूत्र का उपयोग करके की जाती है।

ब्लॉक वजन = आधार आकार * 3 + कुल आकार

ब्लॉक वजन - ब्लॉक वजन (वजन इकाइयों में मापा जाता है)
आधार आकार - आधार ब्लॉक आकार (बाइट्स में मापा जाता है)
कुल आकार- कुल ब्लॉक आकार (बाइट्स में मापा जाता है)

इस सूत्र में, आधार लेनदेन आकार का मतलब है कि पुराने नियमों के अनुसार क्रमबद्ध होने पर लेनदेन का आकार तीन से गुणा किया जाता है और परिणाम नए नियमों के अनुसार क्रमबद्ध लेनदेन के आकार के साथ अभिव्यक्त किया जाता है। नतीजतन, हम लेनदेन का वजन प्राप्त करते हैं।

भले ही पुराने-शैली के लेनदेन को नए या पुराने नियमों के अनुसार क्रमबद्ध किया गया हो, आकार हमेशा एक जैसा होगा, वजन क्रमशः 4 गुना बड़ा होगा। और एक अलग गवाह लेनदेन के लिए, वजन थोड़ा कम होगा, क्योंकि लेनदेन के आकार में सिक्कों के स्वामित्व के प्रमाण शामिल नहीं होंगे।

वजन के साथ-साथ, आभासी आकार की अवधारणा को पेश किया गया था, जिसकी गणना वजन को चार से विभाजित करके की जाती है। आभासी आकार का उपयोग लेनदेन के लिए कमीशन की गणना करने के लिए किया जाता है और ताकि सत्यापनकर्ता यह समझ सकें कि सामान्य रिकॉर्ड मूल्य का उपयोग करके ब्लॉक में एक निश्चित लेनदेन को शामिल करना उनके लिए कितना फायदेमंद है, जिसे spb इकाइयों में मापा जाता है (satoshi per byte)।

आभासी आकार = भार इकाइयों / 4

चूंकि गैर-अलग-अलग गवाह के लिए लेनदेन का वजन आकार से 4 गुना अधिक होगा, इसलिए आभासी लेनदेन का आकार सामान्य आकार के बराबर होगा। तदनुसार, पुराने लेनदेन के लिए, आयोग की गणना नहीं बदलेगी। नए लेनदेन के लिए, यह थोड़ा छोटा होगा, क्योंकि हस्ताक्षर एक अलग संरचना में प्रस्तुत किए जाते हैं। इस प्रकार, उनके लिए कम शुल्क का भुगतान किया जा सकता है, लेकिन खानों में शामिल होने पर खनिकों की समान प्राथमिकता है। इसी समय, गवाह डेटा (आधार आकार) के बिना अधिकतम ब्लॉक आकार 1 एमबी है, और अधिकतम ब्लॉक वजन 4 एमबी है।

यहां एक तार्किक सवाल उठ सकता है: "साक्षी डेटा के साथ वास्तविक ब्लॉक आकार क्या होगा?"। इसका उत्तर देना बिल्कुल असंभव है। जाहिर है, यह मूल्य 1 एमबी से 4 एमबी तक होगा। लेकिन अधिक सटीक सैद्धांतिक मूल्यांकन किया जा सकता है। 1.8 एमबी के बारे में जाओ। यह मूल्य कहां से आता है? एक विशिष्ट लेनदेन ब्लॉक में वर्तमान में लगभग 60% खुले डेटा होते हैं। यदि हम 1 एमबी ब्लॉक के वजन की गणना करते हैं, जिसमें सिक्कों के स्वामित्व के 40% सबूत होते हैं, तो हमें निम्नलिखित डेटा मिलता है।

400,000 बाइट्स * 4 = 1,600,000 पारंपरिक इकाइयों का वजन
600,000 बाइट्स * 1 = 600,000 पारंपरिक इकाइयों का वजन
1,600,000 + 600,000 = 2,200,000 पारंपरिक इकाइयों का वजन
4,000,000 / 2,200,000 = 1.81 एमबी

यही है, यह माना जा सकता है कि प्रभावी ब्लॉक का आकार लगभग 1.8 एमबी होगा। लेकिन यह स्पष्ट है कि व्यवहार में यह मूल्य पूरी तरह से इस ब्लॉक में लेनदेन की संरचना पर निर्भर करेगा।

अनुकूलन आँकड़े अद्यतन करें

जुलाई 2018 तक, SegWit लेनदेन की संख्या बिटकॉइन नेटवर्क में कुल संख्या के 35% से अधिक हो गई है। इसी समय, बिटकॉइन और डिजिटल पर्स के साथ काम करने की मुख्य सेवाओं ने हाल ही में अलग-अलग गवाहों के लिए समर्थन लागू किया है (उदाहरण के लिए, इलेक्ट्रम और बिटएक्सफी)।


आरेख बिटमेक्स रिसर्च अध्ययन से लिया गया है ।

अद्यतन को सक्रिय करने के बाद अंतिम ब्लॉक आकार की गतिशीलता में, महत्वपूर्ण परिवर्तन भी देखे जा सकते हैं। नए लेनदेन के प्रवाह में वृद्धि के क्षणों में, लगभग सभी ब्लॉक 1 एमबी से अधिक हो जाते हैं, और कभी-कभी 2 एमबी से भी अधिक। इसके अलावा, यह काफी स्पष्ट है कि SegWit को सक्रिय करने के बाद, कम बैंडविड्थ की समस्या के तत्काल समाधान की आवश्यकता का सवाल इतना तीव्र नहीं लगता है।


एनालिटिक्स BitMex रिसर्च के अनुसार

यदि आप एक नए प्रारूप में लेन-देन की संख्या पर औसत लेनदेन शुल्क की निर्भरता को देखते हैं, तो आप इन मूल्यों में बदलावों में एक बहुत मजबूत संबंध भी देख सकते हैं।

और यह मत भूलो कि अलग-अलग गवाह ने बिटकॉइन प्रोटोकॉल के शीर्ष पर ऑफ-चेन समाधान विकसित करना संभव बना दिया है। बेशक, बिजली के नेटवर्क को अपनाना सेगविट की तुलना में बहुत मुश्किल काम है, हालांकि, इस संबंध में काम पूरे जोरों पर है और पहले से ही महत्वपूर्ण उपलब्धियां हैं।

अक्सर पूछे जाने वाले प्रश्न

- क्या यह कहना सही है कि RBF (रिप्लेस-बाय-फी) Segregated Witness ट्रांजेक्शन के लिए काम नहीं करेगा?

नहीं, शुल्क द्वारा प्रतिस्थापित अलग-अलग गवाह लेनदेन के लिए काम करेगा, क्योंकि यह आपके खर्च करने के नियमों पर आधारित नहीं है, लेकिन इस तथ्य पर कि आप एक ही सिक्कों का उपयोग करते हैं और लेनदेन प्रविष्टि के अनुक्रम संख्या का संकेत देते हैं। यदि आप समान सिक्कों का उपयोग करते हुए इनपुट पर मूल्य बढ़ाते हैं और इन सिक्कों के स्वामी होने के सही प्रमाणों का संकेत देते हैं, तो आप पिछले लेनदेन को उसी तरह से बदल सकते हैं।

- मैं एक अपुष्ट लेनदेन के हैश को कैसे बदल सकता हूं?

लेन-देन हैश सभी डेटा के हैश फ़ंक्शन की गणना करने का परिणाम है जो लेनदेन में संग्रहीत होता है। लेन-देन में निहित ScriptSig हैश की गणना में शामिल है, लेकिन हस्ताक्षर नहीं किया जा सकता है। इस क्षेत्र में मामूली परिवर्तन जो हस्ताक्षर सत्यापन नियमों में परिवर्तन नहीं करते हैं, लेनदेन के हैश मूल्य में परिवर्तन का कारण बनेंगे। इसका मतलब है कि हस्ताक्षर वैध है, लेनदेन वैध है, लेकिन इसका हैश मूल्य बदल जाएगा।

- लेन-देन में साक्षी डेटा कैसे संग्रहीत किया जाता है?

जैसा कि कहा गया है, अलग-अलग गवाहों के लेन-देन ने एक नया क्रमांकन प्रारूप पेश किया है। इस तथ्य के अलावा कि हमारे पास इनपुट और आउटपुट का एक सेट है, अन्य बाइट्स जोड़े जाते हैं जहां सबूत संग्रहीत होते हैं। तदनुसार, यह डेटा वहां संग्रहीत है। यह इस तरह से कल्पना करना जितना आसान है: बस एक डेटा सेट है जहां लिखा है कि दो लेनदेन इनपुट (पहले इनपुट बाइट्स और दूसरे इनपुट बाइट्स) हैं, दो आउटपुट हैं, और उनके बाद दो और गवाह डेटा सेट हैं, जो बाइट्स के समान ही लिखे गए हैं। । वास्तव में, सिक्के के स्वामित्व के साक्ष्य को क्रमांकन के दौरान किसी अन्य स्थान पर स्थानांतरित कर दिया जाता है।

- Bech32 पतों के लिए मौजूदा वर्ण सेट, जैसे RFC3548 या z-base-32 का उपयोग क्यों न करें?

चरित्र सेट को इसलिए चुना जाता है ताकि उनकी दृश्य समानता के साथ जुड़ी अस्पष्टता को कम किया जा सके। एक से कम डेटा बिट में भिन्न होने वाले वर्ण जोड़े की संख्या को कम करने के लिए आदेश का चयन किया जाता है। छोटी संख्या की त्रुटियों का पता लगाने की संभावना को अधिकतम करने के लिए चेकसम को चुना जाता है, जो विशिष्ट त्रुटियों के लिए इसकी दक्षता में सुधार करता है।