AssumeUTXO

पीटर अपना पहला Full Node शुरू कर रहा है, यानी ऐसा प्रोग्राम जो Bitcoin के नियम खुद जाँचता है। ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। सामान्य शुरुआत में पहले एक लंबा इतिहास पढ़ना और जाँचना पड़ता है। AssumeUTXO तैयार UTXO set से शुरू करने देता है: अभी खर्च न हुए लेनदेन आउटपुट का समूह, जिसमें हर आउटपुट रकम और उसे खर्च करने की शर्तें बताता है। स्नैपशॉट किसी खास ब्लॉक के बाद की स्थिति दिखाता है। वह सभी भुगतानों का संग्रह नहीं है, न प्रमाण कि पीटर का कंप्यूटर पूरा अतीत जाँच चुका है। [1] [3]

फाइल का नाम किसी स्नैपशॉट को सही नहीं बना देता। loadtxoutset से लोड करते समय Bitcoin Core v29.0 उसका प्रारूप, आधार ब्लॉक (जिस ब्लॉक की स्थिति स्नैपशॉट में है) और समर्थित पैरामीटर जाँचता है। वह UTXO सामग्री का hash, यानी क्रिप्टोग्राफिक निशान, भी निकालता है और सक्रिय करने से पहले अपेक्षित मान से मिलाता है। इसलिए बदली हुई सामग्री केवल भरोसेमंद दिखने वाले फाइल नाम के कारण जाँच पार नहीं कर सकती। [2] [3] [6]

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

साथ ही ऐतिहासिक ब्लॉक से एक दूसरी स्थिति बनती है, शुरुआत से स्नैपशॉट के आधार तक। यह इतिहास से की गई स्वतंत्र गणना है, डाउनलोड की सूची की एक और कॉपी नहीं। इसलिए प्रोग्राम कुछ समय अलग प्रगति वाली दो स्थितियाँ रखता है। तकनीकी कमांड getchainstates उन्हें दिखाता है। सक्रिय स्थिति का नवीनतम ब्लॉक तक पहुँच जाना अपने आप में पृष्ठभूमि का काम पूरा होने की पुष्टि नहीं है। [1] [8]

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

फाइल किसी दूसरे संचालक से मिल सकती है, लेकिन उससे उसे स्वीकार होने वाली स्थिति चुनने का अधिकार नहीं मिल जाता। अहम बात प्रोग्राम के समर्थित मान से मेल है, आपूर्तिकर्ता का वादा नहीं। किसी भी ब्लॉक का कोई भी स्नैपशॉट लोड नहीं किया जा सकता; समर्थन संस्करण और नेटवर्क पर निर्भर है। Hash की जाँच फाइल मिल जाने की गारंटी नहीं देती, न ही डाउनलोड और प्रसंस्करण में लगने वाले समय, डेटा ट्रैफिक और डिस्क स्थान की ज़रूरत खत्म करती है। [2] [4] [7]

जब पृष्ठभूमि का काम उसी आधार ब्लॉक तक पहुँचता है, तो नोड अपने बनाए UTXO set का hash निकालता है और उसे स्नैपशॉट के अपेक्षित hash से मिलाता है। यह आज की स्थिति और पुरानी तस्वीर का मिलान नहीं: दोनों इतिहास के एक ही बिंदु को दर्शाते हैं। अगर नतीजे अलग हों, तो यहाँ वर्णित कार्यान्वयन नोड बंद कर देता है और स्नैपशॉट से बनी स्थिति का इस्तेमाल रोकता है। वह अंतर छिपाता नहीं और जाँच सफल नहीं बताता। [1] [6]

AssumeUTXO मुख्य रूप से नोड के उपयोग योग्य होने तक का समय बदलता है। इतिहास डाउनलोड और उसकी जाँच जारी रहती है, और कुछ समय स्थिति के दो डेटाबेस रखने पड़ते हैं। इससे प्रोसेसर और डिस्क पर काम रहता है। Pruned Node पहले से जाँची जा चुकी पुरानी ब्लॉक फाइलें हटाकर जगह बचाता है; वह नियमों की जाँच नहीं छोड़ता। Pruned Node भी स्नैपशॉट इस्तेमाल कर सकता है, लेकिन जगह बचाने के अपने प्रतिबंध हैं। कुछ सहायक इंडेक्स को इतिहास शुरुआत से पढ़ना पड़ता है। इसलिए नोड जल्दी उपलब्ध होने का मतलब उससे जुड़े सभी ऐप तुरंत तैयार होना नहीं है। [5] [7]

UTXO set में बिना खर्च हुए आउटपुट की जानकारी होती है, खर्च की अनुमति देने वाली निजी कुंजियाँ नहीं। डिजिटल हस्ताक्षर निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का प्रमाण बनाता है, लेकिन उस कुंजी को उजागर नहीं करता। UTXO set वॉलेट का बैकअप नहीं और खोई Seed Phrase वापस नहीं देता। Seed Phrase उस व्यवस्था का उपयोग करने वाले वॉलेट के बहाली शब्द हैं। पुराने भुगतान भी तुरंत नहीं दिख सकते: उन्हें ढूँढ़ने के लिए स्नैपशॉट से पहले के ब्लॉक चाहिए हो सकते हैं। कुंजियों का बैकअप, अपने वॉलेट का इतिहास खोजना और नेटवर्क की स्थिति जाँचना अलग काम हैं। [1] [7]

मिलते-जुलते नाम भ्रम पैदा कर सकते हैं। AssumeUTXO लोड की गई स्थिति से शुरू करता है और पुराने इतिहास को पृष्ठभूमि में फिर बनाता है। इसके उलट assumevalid कुछ शर्तों पर पुरानी स्क्रिप्ट जाँच का हिस्सा छोड़ सकता है, यानी हस्ताक्षर सहित खर्च की शर्तों की जाँच। यह अलग अनुकूलन है जो इतिहास की जाँच पर भी असर डाल सकता है। केवल AssumeUTXO पूरा होने से यह साबित नहीं होता कि वह बंद था। निर्देश पढ़ते समय नोड की शुरुआत, असल जाँच और हर जाँच के पूरा होने का समय अलग समझें। [5] [6]