26 / 736MRKL

Merkle Tree

मर्कल ट्री

लेनदेन को एक छाप में समेटने और पूरा ब्लॉक डाउनलोड किए बिना किसी भुगतान के शामिल होने की जाँच का तरीका।

Merkle Tree डेटा की क्रिप्टोग्राफिक छापों को चरण-दर-चरण जोड़कर एक परिणाम बनाता है। बिटकॉइन में इससे Merkle root बनता है, जो ब्लॉक हेडर में रहता है। कुछ अतिरिक्त छापों से जाँचा जा सकता है कि कोई लेनदेन इस रूट से मेल खाता है, बिना बाकी सभी लेनदेन मँगाए।

वॉलेट बताता है कि भुगतान ब्लॉक में शामिल हो गया। पूरा ब्लॉक डाउनलोड किए बिना इसे कैसे जाँचें? यहीं Merkle Tree मदद करता है। पहले लेनदेन को हैश, यानी छोटी क्रिप्टोग्राफिक छापों से दर्शाया जाता है। उन्हें क्रमशः मिलाकर एक संयुक्त छाप बनती है, जिसे रूट कहते हैं। हेडर में यह Merkle root रहता है और ब्लॉक को उसके लेनदेन से जोड़ता है। रूट ऐसा संग्रह नहीं जिससे सभी भुगतान वापस पढ़ लिए जाएँ; यह दिए गए डेटा की जाँच के काम आता है। [1] [2]

A, B, C और D नाम के चार लेनदेन सोचिए। A और B की छापों को जोड़ते हैं और नया हैश AB निकालते हैं। C और D से इसी तरह CD मिलता है। अंत में AB और CD की छाप जोड़कर रूट निकालते हैं। ये अक्षर केवल लेनदेन और बीच के परिणामों के नाम हैं, असली हैश नहीं। यह उलटे पेड़ जैसा है: कई पत्तियाँ शाखाओं से होकर एक जड़ तक आती हैं। लेनदेन बढ़ने पर स्तर बढ़ते हैं, लेकिन सिद्धांत वही रहता है। [3]

B को जाँचने के लिए आपके पास उसका डेटा होता है और आप उसकी छाप निकालते हैं। बस A की छाप, C और D की संयुक्त छाप CD, और उनका सही क्रम चाहिए। A और B से AB बनाइए, फिर AB और CD से रूट निकालकर हेडर के रूट से मिलाइए। इस सहायक रास्ते को Merkle proof कहते हैं। A, C या D की सामग्री जानना जरूरी नहीं। 1024 लेनदेन वाले संतुलित पेड़ में रास्ते पर 10 साथी हैश होते हैं। इसलिए ब्लॉक बढ़ने पर प्रमाण पूरी लेनदेन सूची से कहीं धीमे बढ़ता है। [2] [3]

प्रमाण का रूट से मेल खाना यह नहीं कहता कि दिए गए हेडर पर आँख बंद करके भरोसा करें। उसके Proof of Work की जाँच भी जरूरी है: क्या माइनिंग की गणना का परिणाम तय कठिनाई को पूरा करता है? साथ ही, हेडर का उचित श्रृंखला से जुड़ा होना भी जाँचना पड़ता है। तब भी Merkle proof ब्लॉक के हर लेनदेन के सभी हस्ताक्षर और नियम नहीं जाँचता। यह काम Full Node करता है। इसलिए whitepaper में वर्णित सरल भुगतान सत्यापन SPV की सुरक्षा संबंधी धारणाएँ पूर्ण जाँच से अलग हैं। पुनर्गठन में ब्लॉक सक्रिय शाखा से बाहर भी हो सकता है: उसकी सामग्री का प्रमाण रहता है, लेकिन वर्तमान इतिहास में भुगतान की जगह बदल सकती है। [2]

बिटकॉइन के सामान्य पेड़ में पत्तियाँ ब्लॉक के लेनदेन क्रम में txid पहचानकर्ता हैं; सबसे पहले Coinbase Transaction आती है, यानी वह खास लेनदेन जिससे माइनर ब्लॉक का इनाम प्राप्त करता है। जोड़े बाइट के रूप में मिलाकर SHA-256 से दो बार हैश किए जाते हैं। किसी स्तर पर आखिरी हैश बिना जोड़ीदार के बच जाए, तो उस गणना के लिए उसकी प्रति ली जाती है। इससे अतिरिक्त भुगतान नहीं बनता। केवल एक लेनदेन हो तो उसका txid ही रूट है। इस दोहराव के कारण कार्यान्वयन में डुप्लिकेट की सावधानी से जाँच जरूरी है। प्रोटोकॉल में किए गए सुधार SegWit से हस्ताक्षर जैसे witness डेटा भी अलग रखे जाते हैं। Coinbase Transaction में दर्ज एक और क्रिप्टोग्राफिक छाप इस डेटा को ब्लॉक से जोड़ती है। इस छाप को witness commitment कहते हैं। इसलिए सामान्य txid पेड़ और witness पेड़ को एक नहीं समझना चाहिए। [3] [4]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Block, लेनदेन, Block Header. इस प्रविष्टि का उल्लेख यहाँ भी है Block Header, Hash, SHA-256, पुष्टि.

DOC · 001Bitcoin Developer Guide — Merkle Treesदस्तावेज़ DOC · 002Bitcoin whitepaper — Simplified Payment Verificationप्राथमिक स्रोत DOC · 003Bitcoin Core — Merkle tree implementationप्राथमिक स्रोत DOC · 004BIP141: witness commitmentप्राथमिक स्रोत
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है