Ralph C. Merkle एक क्रिप्टोग्राफर हैं जिनके काम ने आधुनिक क्रिप्टोग्राफी की नींव रखने में योगदान दिया। Merkle की पहेलियाँ ऐसे संचार पर साझा रहस्य बनाने की समस्या सुलझाती हैं जिसे कोई सुन रहा हो; Merkle Tree पूरी सूची डाउनलोड किए बिना किसी मद का उस सूची में शामिल होना प्रमाणित करता है। ये अलग काम हैं और इनमें से कोई अकेले Bitcoin लेनदेन की वैधता तय नहीं करता।
आप एक एन्क्रिप्ट किया हुआ संदेश भेजना चाहते हैं। उसे पढ़ने के लिए प्राप्तकर्ता को गुप्त कुंजी चाहिए। लेकिन कोई पूरा संवाद देख रहा हो तो कुंजी कैसे पहुँचाएँ? अपने 1978 के शोधपत्र में Ralph Merkle ने एक अनोखा तरीका बताया: भेजने वाला कई एन्क्रिप्ट की हुई पहेलियाँ तैयार करता है। प्राप्तकर्ता बेतरतीब ढंग से चुनी गई एक पहेली हल करके उसके भीतर छिपा पहचान-संकेत सार्वजनिक रूप से वापस भेजता है। अब दोनों साझा कुंजी जानते हैं। सुनने वाला भी संकेत देखता है, लेकिन नहीं जानता कि वह किस पहेली में था। बताए गए मॉडल में उसका काम समस्या के आकार के वर्ग के अनुपात में बढ़ता है, जबकि प्रतिभागियों का काम रैखिक रूप से बढ़ता है। यह वर्गानुपाती अंतर है, घातांकीय नहीं। ऐतिहासिक सफलता होने का अर्थ यह नहीं कि आज संदेश एन्क्रिप्ट करने के लिए यही तरीका सुझाया जाता है। [1]
1978 के शोधपत्र में विरोधी क्या कर सकता है, यह समझना ज़रूरी है। वह सुन सकता है, लेकिन संदेश में बदलाव और जालसाजी का पता लग सकने की धारणा बनी रहती है। किसी ऐसे व्यक्ति की कल्पना करें जो पत्र पढ़ता है, और फिर ऐसे व्यक्ति की जो उसे बदलकर आपके नाम से हस्ताक्षर भी करता है। दूसरे मामले में अतिरिक्त सुरक्षा चाहिए: आप वास्तव में किससे बात कर रहे हैं, इसकी पुष्टि। गणना के काम में अंतर इस सवाल को हल नहीं करता। इसलिए पहेलियाँ ऐसे सक्रिय मध्यस्थ से गुजरने वाले हर संवाद को सुरक्षित नहीं बनातीं। उनका योगदान यह दिखाना है कि बताई गई धारणाओं के अंतर्गत पहले से साझा गुप्त कुंजी के बिना भी सहमति संभव है। [1]
Merkle Tree दूसरी समस्या हल करता है। इस प्रमाणीकरण वृक्ष का वर्णन Merkle के 1979 के शोधप्रबंध में है। अनुबंधों के संग्रह की कल्पना करें: आप पूरा संग्रह डाउनलोड किए बिना एक अनुबंध जाँचना चाहते हैं। हर मद का hash निकाला जाता है, यानी एक छोटा डिजिटल पहचान-चिह्न। इन्हें जोड़ों में जोड़कर फिर hash निकाला जाता है, जब तक एक साझा root, यानी जड़, न बच जाए। Hashing सामग्री को एन्क्रिप्ट नहीं करती; वह मिलान जाँचने में मदद करती है। सार्थक जाँच के लिए पहले से प्रमाणित root चाहिए, जिसकी सही संग्रह से संबंधित होने की पुष्टि हो। यदि ठग अपना दस्तावेज़ और मनमाना root दोनों दे सके, तो उनका मेल मूल संग्रह के बारे में कुछ साबित नहीं करेगा। [2]
8 मदों वाला संतुलित द्विआधारी वृक्ष लें। चुने हुए पत्ते को जाँचने के लिए 3 पड़ोसी hash चाहिए: हर स्तर पर साथ वाली शाखा का निशान। अपने पत्ते और इन निशानों से आप root की गणना करके उसे प्रमाणित root से मिलाते हैं। पत्ता स्वयं और root इन सहायक hash की गिनती में शामिल नहीं हैं। वृक्ष की संरचना और जोड़ने का क्रम भी मालूम होना चाहिए: पड़ोसी मान बाईं ओर जाएगा या दाईं ओर? यह बचत छिपे डेटा का कोई जादू नहीं है। संग्रह के दूर के हिस्सों का प्रतिनिधित्व उनके निशान करते हैं, इसलिए इस विशेष जाँच के लिए उन दस्तावेज़ों की पूरी सामग्री आवश्यक नहीं होती। [2]
Merkle Tree किसी मद और एक निश्चित डेटा समूह के बीच संबंध साबित करता है। वह गलत जानकारी को सच नहीं बनाता। हमारे उदाहरण के संग्रह में गलत नाम वाला अनुबंध भी रखा जा सकता है; प्रमाण सही ढंग से उसका शामिल होना दिखा सकता है, बिना नाम की गलती पकड़े। इसी तरह डिजिटल निशान दस्तावेज़ बनाने वाले का अधिकार प्रमाणित नहीं करता। सवाल अलग रखें: क्या मद इस root से मेल खाती है, root कहाँ से मिला, और सामग्री किन नियमों पर स्वीकार की जाती है? इससे समझ आता है कि वही तकनीक Bitcoin में क्या कर सकती है और कौन से काम प्रणाली के अन्य हिस्सों को करने होंगे। [2]
Bitcoin लेनदेन को ब्लॉक के संक्षिप्त रिकॉर्ड, यानी block header, से जोड़ने के लिए Merkle Tree का उपयोग करता है। Root उस header का हिस्सा होता है; शामिल लेनदेन बदलने से उनका साझा निशान प्रभावित होता है। Satoshi Nakamoto whitepaper के खंड 7 में इस रचना को समझाते हैं और Merkle के काम को संदर्भों में रखते हैं। यह तकनीकी प्रभाव का प्रमाण है, Bitcoin का लेखक होने का नहीं। वृक्ष वैध इतिहास नहीं चुनता और नोड की जगह लेनदेन के हस्ताक्षर भी नहीं जाँचता। Bitcoin इसे लेनदेन सत्यापन तथा Proof of Work, यानी गणनात्मक काम के प्रमाण, जैसे अन्य नियमों के साथ जोड़ता है। एक घटक की भूमिका समझना बेहतर है, बजाय उसे पूरी प्रणाली की क्षमताएँ दे देने के। [3]
Whitepaper का खंड 8 SPV, यानी सरलीकृत भुगतान सत्यापन, बताता है। हल्का क्लाइंट ब्लॉक header और उस शाखा का उपयोग करता है जो लेनदेन को चुने हुए ब्लॉक से जोड़ती है। इससे डेटा बचता है, लेकिन सर्वाधिक संचित काम वाली चेन और माइनरों के व्यवहार से जुड़ी धारणाओं पर निर्भरता रहती है। शामिल होने का प्रमाण अकेले Full Node, यानी पूरी जाँच करने वाले नोड, की तरह लेनदेन के सारे नियम नहीं जाँचता। वह यह भी नहीं बताता कि कोई output बाद में खर्च हुआ या नहीं; इसके लिए आगे की गतिविधियाँ जाननी होंगी। नए पाठक के लिए ज़रूरी अंतर यह है कि “यह भुगतान इस ब्लॉक में है” अभी उपलब्ध धन की पूरी जाँच नहीं है। [3]
1979 का शोधप्रबंध प्रमाणीकरण वृक्ष को सीमित संख्या वाले एकबारगी डिजिटल हस्ताक्षरों के लिए भी इस्तेमाल करता है। डिजिटल हस्ताक्षर यह जाँचने देता है कि किसी खास गुप्त कुंजी के धारक ने संदेश स्वीकृत किया था; वह कागज़ी हस्ताक्षर की तस्वीर नहीं है। वृक्ष कई सत्यापन मानों को एक ज्ञात root से जोड़ सकता है। लेकिन इस रचना में हस्ताक्षरों की संख्या सीमित है और आखिरकार root बदलना पड़ता है। इसका अर्थ एक ही एकबारगी कुंजी का अनंत बार उपयोग करने की अनुमति नहीं है। Merkle के काम का यह उन्नत हिस्सा भी वही विचार दिखाता है: छोटे प्रमाण से ज़रूरी हिस्सा जाँचें और ठीक-ठीक समझें कि जाँच किन धारणाओं पर आधारित है। [2]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें David Chaum, Timothy May, Merkle Tree, Block Header. इस प्रविष्टि का उल्लेख यहाँ भी है David Chaum, Timothy May.