Orphan Block

पिछले ब्लॉक को कभी-कभी parent, यानी जनक ब्लॉक कहते हैं। वास्तविक Orphan Block में याना का नोड उसे नहीं जानता, इसलिए जुड़ाव की जाँच पूरी नहीं कर सकता। Stale Block का जनक ज्ञात हो सकता है और पूरा ब्लॉक वैध हो सकता है; नोड बस दूसरी शाखा को सक्रिय इतिहास मानता है। Bitcoin Developer Guide इन अर्थों को स्पष्ट रूप से अलग करता है। इसलिए ब्लॉक एक्सप्लोरर में orphan देखकर याना पहले पूछती है: पिछला ब्लॉक गायब है या यह ब्लॉक मुख्य चेन में टिक नहीं पाया? [1]

यह फर्क Bitcoin Core में भी दिखता है। यह नोड चलाने वाला सॉफ्टवेयर है, जो Bitcoin के नियमों के अनुसार ब्लॉक और लेनदेन की जाँच करता है। Bitcoin Core 29 में AcceptBlockHeader, hashPrevBlock के जरिए पिछले ब्लॉक को ढूँढ़ता है; यह उसके पहचान वाले फ़िंगरप्रिंट का संदर्भ है। सूचकांक में रिकॉर्ड न मिले तो prev-blk-not-found लौटता है। जनक ज्ञात हो और अवैध चिह्नित हो तो bad-prevblk मिलता है। पहला कहता है “संदर्भ नहीं है”, दूसरा “तुम अवैध ब्लॉक पर आगे बढ़ रहे हो”। गायब पिछला ब्लॉक मिलने से अगली जाँच हो सकती है, लेकिन पूरे ब्लॉक का स्वीकार होना अपने आप सुनिश्चित नहीं हो जाता। [2]

ब्लॉक में हेडर होता है, पहचान और जुड़ाव की छोटी जानकारी, और लेनदेन वाला मुख्य भाग होता है। Bitcoin Core 0.10.0 ने headers-first सिंक्रोनाइज़ेशन शुरू किया: पहले हेडर प्राप्त करके जाँचे जाते हैं, फिर ब्लॉक समानांतर डाउनलोड किए जा सकते हैं। इसलिए याना का नोड पिछले ब्लॉक का हेडर जान सकता है, जबकि पूरा ब्लॉक अभी डिस्क पर न हो। मुख्य भाग का गायब होना और पिछले ब्लॉक का अज्ञात होना अलग बातें हैं; इन्हें मिलाने से सामान्य डाउनलोड भी रहस्य लग सकता है। [3]

Bitcoin Core 29 का getchaintips आदेश याना को दिखाता है कि नोड किन शाखाओं के सिरों को जानता है। active सक्रिय चेन है; valid-fork पूरी तरह जाँची गई निष्क्रिय शाखा है। valid-headers बताता है कि ब्लॉक मौजूद हैं लेकिन पूरी जाँच नहीं हुई; headers-only का मतलब कुछ ब्लॉक नहीं हैं। invalid ऐसी शाखा है जिसमें अवैध ब्लॉक है। इसलिए यह एक जैसे दोषों की सूची नहीं है। सहायता में लिखा orphaned branches भी इन अंतरों को खत्म नहीं करता। [4]

मान लें कि अलग ब्लॉक A और B ऊँचाई 900000 पर हैं। यह हमारा समझाने वाला उदाहरण है, किसी खास घटना का विवरण नहीं। ऊँचाई चेन में स्थान है, इसलिए प्रतिस्पर्धी ब्लॉक एक ही ऊँचाई पर हो सकते हैं। याना उन्हें hash, ब्लॉक की पहचान का फ़िंगरप्रिंट, और previousblockhash, पिछले ब्लॉक के संदर्भ, से अलग करती है। वैध शाखाओं के बीच चुनाव में संचित काम निर्णायक है, केवल ऊँचाई नहीं। कार्यक्रम को आदेश देने वाला RPC इंटरफ़ेस इसे chainwork कहता है: ब्लॉकों की कठिनाइयों के अनुरूप कुल अपेक्षित काम। [1] [5]

जब याना getblock से मुख्य चेन के बाहर के ब्लॉक के बारे में पूछती है, Bitcoin Core 29 confirmations = -1 दिखा सकता है। यह स्थिति का खास संकेत है, सामान्य पुष्टि-गणना नहीं। यह उलटी गिनती या चेन पुनर्गठन की ऋणात्मक गहराई नहीं है। इससे पिछले ब्लॉक का गायब होना भी साबित नहीं होता। याना को इसे ब्लॉक की पहचान और शाखा की स्थिति के साथ पढ़ना होगा; यह भी ज़रूरी नहीं कि उसके नोड के पास वे सभी ब्लॉक हों जिन्हें दूसरे प्रतिभागियों ने कभी देखा है। [5]

ब्लॉक का इनाम coinbase नाम के विशेष पहले लेनदेन से बनता है; इसका उसी नाम के एक्सचेंज से संबंध नहीं है। लेनदेन का आउटपुट बिटकॉइन की एक रकम और उसे खर्च करने के लिए पूरी की जाने वाली शर्तों का रिकॉर्ड होता है। Bitcoin Core 29 में COINBASE_MATURITY का मान 100 है: ऊँचाई H पर बना आउटपुट पहली बार H+100 की ऊँचाई वाले वैध ब्लॉक में खर्च किया जा सकता है। ऊँचाइयों का अंतर मायने रखता है, बीते मिनट नहीं। लेकिन यह प्रतीक्षा सक्रिय चेन में शामिल होने की जगह नहीं लेती। जब तक इनाम वाला ब्लॉक निष्क्रिय शाखा में है, उसका आउटपुट सक्रिय UTXO सेट, यानी अब तक न खर्च किए गए आउटपुटों के रिकॉर्ड, में नहीं है। कहीं और ब्लॉक बढ़ने से पैसा अपने आप वापस नहीं आता। [6] [7] [1] [8]

याना ब्लॉक का hash, पिछला ब्लॉक, शाखा की स्थिति और कार्यक्रम का संस्करण लिखती है। वह getchaintips और getblock के जवाब तथा उन्हें प्राप्त करने का समय भी जोड़ती है। यह समय हेडर के time फ़ील्ड से अलग रखा जाता है: ब्लॉक का टाइमस्टैम्प वह क्षण नहीं है जब उसके कंप्यूटर ने उसे देखा। रिकॉर्ड आगे के अवलोकनों की तुलना में मदद करता है, लेकिन अपने आप हमला, खास नेटवर्क खराबी या दुनिया भर की orphan दर साबित नहीं करता। सबसे पहले यह किसी एक नोड की किसी खास क्षण की स्थिति बताता है। [4] [5]