मुख्य सामग्री पर जाएं

वर्कल ट्रीज़

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

अवस्थाहीनता

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

इथेरियम क्लाइंट वर्तमान में अपने स्थिति डेटा को संग्रहीत करने के लिए पेट्रीसिया मर्कल ट्राई (Patricia Merkle Trie) नामक डेटा संरचना का उपयोग करते हैं। व्यक्तिगत खातों के बारे में जानकारी ट्राई पर पत्तियों के रूप में संग्रहीत की जाती है और पत्तियों के जोड़े को बार-बार हैश किया जाता है जब तक कि केवल एक हैश न रह जाए। इस अंतिम हैश को "रूट" के रूप में जाना जाता है। ब्लॉकों को सत्यापित करने के लिए, इथेरियम क्लाइंट एक ब्लॉक में सभी लेनदेन निष्पादित करते हैं और अपने स्थानीय स्टेट ट्राई को अपडेट करते हैं। ब्लॉक को वैध माना जाता है यदि स्थानीय ट्री का रूट ब्लॉक प्रस्तावक द्वारा प्रदान किए गए रूट के समान है, क्योंकि ब्लॉक प्रस्तावक और मान्य करने वाले नोड द्वारा की गई गणना में कोई भी अंतर रूट हैश को पूरी तरह से अलग कर देगा। इसके साथ समस्या यह है कि ब्लॉकचेन को सत्यापित करने के लिए प्रत्येक क्लाइंट को हेड ब्लॉक और कई ऐतिहासिक ब्लॉकों के लिए संपूर्ण स्टेट ट्राई को संग्रहीत करने की आवश्यकता होती है (Geth में डिफ़ॉल्ट हेड के पीछे 128 ब्लॉकों के लिए स्थिति डेटा रखना है)। इसके लिए क्लाइंट के पास बड़ी मात्रा में डिस्क स्थान तक पहुंच होना आवश्यक है, जो सस्ते, कम शक्ति वाले हार्डवेयर पर पूर्ण नोड चलाने में एक बाधा है। इसका एक समाधान स्टेट ट्राई को अधिक कुशल संरचना (वर्कल ट्री) में अपडेट करना है जिसे डेटा के लिए एक छोटे "साक्षी" का उपयोग करके संक्षेपित किया जा सकता है जिसे पूर्ण स्थिति डेटा के बजाय साझा किया जा सकता है। स्थिति डेटा को वर्कल ट्री में सुधारना अवस्थाहीन क्लाइंट की ओर बढ़ने के लिए एक महत्वपूर्ण कदम है।

साक्षी क्या है और हमें उनकी आवश्यकता क्यों है?

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

वर्कल ट्रीज़ छोटे साक्षियों को सक्षम क्यों करते हैं?

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

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

साक्षी का आकार इसमें शामिल पत्तियों की संख्या के आधार पर भिन्न होता है। यह मानते हुए कि साक्षी 1000 पत्तियों को कवर करता है, मर्कल ट्राई के लिए एक साक्षी लगभग 3.5MB होगा (ट्राई में 7 स्तर मानकर)। वर्कल ट्री में समान डेटा के लिए एक साक्षी (ट्री में 4 स्तर मानकर) लगभग 150 kB होगा - लगभग 23 गुना छोटा। साक्षी के आकार में यह कमी अवस्थाहीन क्लाइंट साक्षियों को स्वीकार्य रूप से छोटा होने देगी। उपयोग की जाने वाली विशिष्ट बहुपद प्रतिबद्धता के आधार पर बहुपद साक्षी 0.128 - 1 kB होते हैं।

वर्कल ट्री की संरचना क्या है?

वर्कल ट्रीज़ (key,value) जोड़े हैं जहाँ कुंजियाँ 32-बाइट तत्व हैं जो 31-बाइट स्टेम और सिंगल बाइट प्रत्यय से बनी हैं। इन कुंजियों को एक्सटेंशन नोड और इनर नोड में व्यवस्थित किया जाता है। एक्सटेंशन नोड अलग-अलग प्रत्ययों वाले 256 बच्चों के लिए एक एकल स्टेम का प्रतिनिधित्व करते हैं। इनर नोड में भी 256 बच्चे होते हैं, लेकिन वे अन्य एक्सटेंशन नोड हो सकते हैं। वर्कल ट्री और मर्कल ट्री संरचना के बीच मुख्य अंतर यह है कि वर्कल ट्री बहुत अधिक समतल है, जिसका अर्थ है कि एक पत्ती को रूट से जोड़ने वाले मध्यवर्ती नोड कम हैं, और इसलिए प्रमाण उत्पन्न करने के लिए कम डेटा की आवश्यकता होती है।

Diagram of a Verkle tree data structure

वर्कल ट्रीज़ की संरचना के बारे में और पढ़ें (opens in a new tab)

वर्तमान प्रगति

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

गिलाउम बैले को कॉन्ड्रियू वर्कल टेस्टनेट के बारे में समझाते हुए देखें (opens in a new tab) (ध्यान दें कि कॉन्ड्रियू टेस्टनेट प्रूफ-ऑफ-वर्क (PoW) था और अब इसे वर्कल जेन डेवनेट 6 टेस्टनेट द्वारा प्रतिस्थापित कर दिया गया है)।

आगे की सामग्री