पोर्टल नेटवर्क

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

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

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

नोड्स और क्लाइंट्स पर और अधिक

हमें पोर्टल नेटवर्क की आवश्यकता क्यों है

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

ब्लॉकचेन और संबंधित स्टेट और रसीद डेटा की यह स्थानीय कॉपी नोड की हार्ड डिस्क पर बहुत अधिक जगह लेती है। उदाहरण के लिए, गेथ (opens in a new tab) का उपयोग करके एक नोड चलाने के लिए 2TB हार्ड डिस्क की सिफारिश की जाती है, जिसे एक सहमति क्लाइंट के साथ जोड़ा जाता है। स्नैप सिंक का उपयोग करते हुए, जो केवल ब्लोकों के अपेक्षाकृत हाल के सेट से चेन डेटा संग्रहीत करता है, गेथ आमतौर पर लगभग 650GB डिस्क स्थान घेरता है, लेकिन लगभग 14GB/सप्ताह की दर से बढ़ता है (आप समय-समय पर नोड को वापस 650GB तक छाँट सकते हैं)।

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

पोर्टल नेटवर्क का उद्देश्य लाइट नोड्स को अपना डेटा प्राप्त करने के लिए एक वैकल्पिक तरीका प्रदान करना है जिसमें फुल नोड्स द्वारा किए जाने वाले काम पर भरोसा करने या महत्वपूर्ण रूप से जोड़ने की आवश्यकता नहीं होती है। यह करने का तरीका यह है कि एथेरियम नोड्स के लिए नेटवर्क पर डेटा साझा करने का एक नया तरीका पेश किया जाए।

पोर्टल नेटवर्क कैसे काम करता है?

एथेरियम नोड्स में सख्त प्रोटोकॉल होते हैं जो यह परिभाषित करते हैं कि वे एक-दूसरे के साथ कैसे संवाद करते हैं। निष्पादन क्लाइंट DevP2P के रूप में जाने जाने वाले सबप्रोटोकॉल के एक सेट का उपयोग करके संवाद करते हैं, जबकि सहमति क्लाइंट libP2P नामक सबप्रोटोकॉल के एक अलग स्टैक का उपयोग करते हैं। ये उन डेटा के प्रकारों को परिभाषित करते हैं जिन्हें नोड्स के बीच पारित किया जा सकता है।

नोड्स JSON-RPC API के माध्यम से विशिष्ट डेटा भी परोस सकते हैं, जो कि ऐप्स और वॉलेट्स एथेरियम नोड्स के साथ जानकारी स्वैप करते हैं। हालांकि, इनमें से कोई भी लाइट क्लाइंट्स को डेटा परोसने के लिए आदर्श प्रोटोकॉल नहीं है।

लाइट क्लाइंट्स वर्तमान में DevP2P या libP2p पर चेन डेटा के विशिष्ट टुकड़ों का अनुरोध नहीं कर सकते हैं क्योंकि वे प्रोटोकॉल केवल चेन सिंक्रोनाइज़ेशन और ब्लोकों और लेन-देन की गपशप को सक्षम करने के लिए डिज़ाइन किए गए हैं। लाइट क्लाइंट्स इस जानकारी को डाउनलोड नहीं करना चाहते हैं क्योंकि यह उन्हें "लाइट" होने से रोक देगा।

JSON-RPC API भी लाइट क्लाइंट डेटा अनुरोधों के लिए एक आदर्श विकल्प नहीं है, क्योंकि यह एक विशिष्ट फुल नोड या केंद्रीकृत RPC प्रदाता के कनेक्शन पर निर्भर करता है जो डेटा परोस सकता है। इसका मतलब है कि लाइट क्लाइंट को ईमानदार होने के लिए उस विशिष्ट नोड/प्रदाता पर भरोसा करना पड़ता है, और फुल नोड को कई लाइट क्लाइंट्स से बहुत सारे अनुरोधों को संभालना पड़ सकता है, जिससे उनकी बैंडविड्थ आवश्यकताएं बढ़ जाती हैं।

पोर्टल नेटवर्क का उद्देश्य मौजूदा एथेरियम क्लाइंट्स की डिज़ाइन बाधाओं के बाहर, विशेष रूप से हल्केपन के लिए निर्माण करते हुए, पूरे डिज़ाइन पर पुनर्विचार करना है।

पोर्टल नेटवर्क का मूल विचार DHT (opens in a new tab) (Bittorrent के समान) का उपयोग करके एक हल्के DevP2P स्टाइल पीयर-टू-पीयर विकेंद्रीकृत नेटवर्क के माध्यम से परोसे जाने वाले ऐतिहासिक डेटा और चेन के वर्तमान हेड की पहचान जैसी लाइट क्लाइंट्स द्वारा आवश्यक जानकारी को सक्षम करके वर्तमान नेटवर्किंग स्टैक के सर्वोत्तम बिट्स लेना है।

विचार यह है कि प्रत्येक नोड में कुल ऐतिहासिक एथेरियम डेटा के छोटे हिस्से और कुछ विशिष्ट नोड जिम्मेदारियों को जोड़ा जाए। फिर, अनुरोधित विशिष्ट डेटा को संग्रहीत करने वाले नोड्स को खोजकर और उनसे इसे पुनः प्राप्त करके अनुरोधों को पूरा किया जाता है।

यह लाइट नोड्स के सामान्य मॉडल को उलट देता है जो एक एकल नोड ढूंढते हैं और उनसे बड़ी मात्रा में डेटा को फ़िल्टर करने और परोसने का अनुरोध करते हैं; इसके बजाय, वे जल्दी से नोड्स के एक बड़े नेटवर्क को फ़िल्टर करते हैं जो प्रत्येक छोटी मात्रा में डेटा संभालते हैं।

लक्ष्य लाइटवेट पोर्टल क्लाइंट्स के एक विकेंद्रीकृत नेटवर्क को अनुमति देना है:

• चेन के हेड को ट्रैक करना
• हाल के और ऐतिहासिक चेन डेटा को सिंक करना
• स्टेट डेटा पुनः प्राप्त करना
• लेन-देन प्रसारित करना
• EVM का उपयोग करके लेन-देन निष्पादित करना

इस नेटवर्क डिज़ाइन के लाभ हैं:

• केंद्रीकृत प्रदाताओं पर निर्भरता कम करना
• इंटरनेट बैंडविड्थ उपयोग कम करना
• न्यूनतम या शून्य सिंकिंग
• संसाधन-विवश उपकरणों के लिए सुलभ (<1 GB RAM, <100 MB डिस्क स्थान, 1 CPU)

नीचे दी गई तालिका मौजूदा क्लाइंट्स के कार्यों को दिखाती है जिन्हें पोर्टल नेटवर्क द्वारा वितरित किया जा सकता है, जो यूज़र्स को बहुत कम-संसाधन वाले उपकरणों पर इन कार्यों तक पहुंचने में सक्षम बनाता है।

पोर्टल नेटवर्क्स

डिफ़ॉल्ट रूप से क्लाइंट विविधता

पोर्टल नेटवर्क डेवलपर्स ने पहले दिन से चार अलग-अलग पोर्टल नेटवर्क क्लाइंट बनाने का डिज़ाइन विकल्प भी चुना।

पोर्टल नेटवर्क क्लाइंट्स हैं:

• Trin (opens in a new tab): रस्ट में लिखा गया
• Fluffy (opens in a new tab): निम में लिखा गया
• Ultralight (opens in a new tab): Typescript में लिखा गया
• Shisui (opens in a new tab): Go में लिखा गया

कई स्वतंत्र क्लाइंट कार्यान्वयन होने से एथेरियम नेटवर्क के लचीलेपन और विकेंद्रीकरण में वृद्धि होती है।

यदि किसी एक क्लाइंट में कोई समस्या या भेद्यता आती है, तो अन्य क्लाइंट सुचारू रूप से काम करना जारी रख सकते हैं, जिससे विफलता का एक भी बिंदु रोका जा सकता है। इसके अतिरिक्त, विविध क्लाइंट कार्यान्वयन नवाचार और प्रतिस्पर्धा को बढ़ावा देते हैं, सुधारों को बढ़ावा देते हैं और इकोसिस्टम के भीतर मोनोकल्चर जोखिम को कम करते हैं।

आगे की रीडिंग

• पोर्टल नेटवर्क (पाइपर मेरियम देवकॉन बोगोटा में) (opens in a new tab)।
• पोर्टल नेटवर्क डिस्कॉर्ड (opens in a new tab)
• पोर्टल नेटवर्क वेबसाइट (opens in a new tab)