Trending News

BTC
$23,113.79
+0.57
ETH
$1,675.05
+2.18
LTC
$100.60
+1.14
DASH
$64.77
-0.28
XMR
$168.25
+0.78
NXT
$0.01
+10.62
ETC
$23.04
+2.13

डीएपी डेवलपर्स के लिए लाइट क्लाइंट का परिचय

0


Light Ethereum Subprotocol (LES/1) का पहला संस्करण और Geth में इसका कार्यान्वयन अभी भी चल रहा है एक प्रायोगिक चरण, लेकिन उनके और अधिक पहुंचने की उम्मीद है प्रौढ़ कुछ महीनों में बताएं कि बुनियादी कार्य मज़बूती से कहाँ प्रदर्शन करेंगे। लाइट क्लाइंट को कमोबेश पूर्ण क्लाइंट के समान कार्य करने के लिए डिज़ाइन किया गया है, लेकिन “लाइटनेस” में कुछ अंतर्निहित सीमाएँ हैं जो डीएपी डेवलपर्स चाहिए समझो और उनके अनुप्रयोगों को डिजाइन करते समय विचार करें.

ज्यादातर मामलों में एक ठीक से डिज़ाइन किया गया एप्लिकेशन यह जाने बिना भी काम कर सकता है कि यह किस प्रकार के क्लाइंट से जुड़ा है, लेकिन हम फ्यूचर प्रूफ इंटरफ़ेस प्रदान करने के लिए विभिन्न क्लाइंट क्षमताओं को संप्रेषित करने के लिए एक एपीआई एक्सटेंशन जोड़ने पर विचार कर रहे हैं। जबकि एलईएस के मामूली विवरणों पर अभी भी काम किया जा रहा है, मेरा मानना ​​है कि एप्लिकेशन डेवलपर परिप्रेक्ष्य से पूर्ण और हल्के ग्राहकों के बीच सबसे महत्वपूर्ण अंतरों को स्पष्ट करने का समय आ गया है।

वर्तमान सीमाएँ

लम्बित लेन – देन

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

हैश द्वारा लेनदेन ढूँढना

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

प्रदर्शन संबंधी विचार

विलंबता का अनुरोध करें

लाइट क्लाइंट के डेटाबेस में हमेशा एक ही चीज होती है, वह है आखिरी कुछ हजार ब्लॉक हेडर। इसका मतलब यह है कि कुछ और प्राप्त करने के लिए क्लाइंट को अनुरोध भेजने और लाइट सर्वर से उत्तर प्राप्त करने की आवश्यकता होती है। लाइट क्लाइंट अनुरोध को अनुकूलित करने का प्रयास करता है वितरण और विलंबता को कम करने के लिए प्रत्येक सर्वर के सामान्य प्रतिक्रिया समय का सांख्यिकीय डेटा एकत्र करता है। लेटेंसी लाइट क्लाइंट का प्रमुख प्रदर्शन पैरामीटर है। यह आमतौर पर परिमाण के 100-200ms क्रम में होता है, और यह प्रत्येक राज्य/अनुबंध भंडारण रीड, ब्लॉक और रसीद सेट पुनर्प्राप्ति पर लागू होता है। यदि एक ऑपरेशन करने के लिए कई अनुरोध क्रमिक रूप से किए जाते हैं, तो इसका परिणाम उपयोगकर्ता के लिए धीमी प्रतिक्रिया समय हो सकता है। जब भी संभव हो, एपीआई कार्यों को समानांतर में चलाने से प्रदर्शन में काफी सुधार हो सकता है।

ब्लॉकों के एक लंबे इतिहास में घटनाओं की खोज करना

पूर्ण ग्राहक एक तथाकथित “MIP मैप्ड” ब्लूम फ़िल्टर का उपयोग करते हैं ताकि ब्लॉकों की एक लंबी सूची में घटनाओं को जल्दी से खोजा जा सके ताकि पूरे ब्लॉक इतिहास में कुछ घटनाओं की खोज करना उचित रूप से सस्ता हो। दुर्भाग्य से, एमआईपी-मैप किए गए फ़िल्टर का उपयोग करना आसान क्लाइंट के साथ करना आसान नहीं है, क्योंकि खोज केवल व्यक्तिगत हेडर में की जाती है, जो बहुत धीमी है। कुछ दिनों के ब्लॉक इतिहास की खोज आमतौर पर स्वीकार्य समय के बाद वापस आती है, लेकिन फिलहाल आपको पूरे इतिहास में कुछ भी नहीं खोजना चाहिए क्योंकि इसमें बहुत लंबा समय लगेगा।

मेमोरी, डिस्क और बैंडविड्थ आवश्यकताएं

यहाँ अच्छी खबर है: एक हल्के ग्राहक को एक बड़े डेटाबेस की आवश्यकता नहीं होती है क्योंकि यह मांग पर कुछ भी प्राप्त कर सकता है। कचरा संग्रह सक्षम होने के साथ (जो लागू होने के लिए निर्धारित है), डेटाबेस a की तरह अधिक कार्य करेगा कैश, और एक लाइट क्लाइंट के साथ चलने में सक्षम होगा कम से कम 10 एमबी स्टोरेज स्पेस. ध्यान दें कि वर्तमान गेथ कार्यान्वयन चारों ओर उपयोग करता है 200 एमबी मेमोरीहै, जिसे और कम किया जा सकता है। जब क्लाइंट का अत्यधिक उपयोग नहीं किया जाता है तो बैंडविड्थ की आवश्यकताएं भी कम होती हैं। उपयोग की जाने वाली बैंडविड्थ आमतौर पर कम होती है 1Mb/घंटा निष्क्रिय होने पर, औसत स्थिति/संग्रहण अनुरोध के लिए अतिरिक्त 2-3kb के साथ.

भविष्य में सुधार

दूरस्थ निष्पादन द्वारा समग्र विलंबता को कम करना

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

अप्रत्यक्ष रूप से जटिल गणनाओं का सत्यापन

मुख्य सीमाओं में से एक जिसे हम सुधारने के लिए काम कर रहे हैं लॉग इतिहास की धीमी खोज गति है। एमआईपी-मैप्ड ब्लूम फिल्टर प्राप्त करने की कठिनाई सहित ऊपर उल्लिखित कई सीमाएं समान पैटर्न का पालन करती हैं: सर्वर (जो एक पूर्ण नोड है) आसानी से एक निश्चित जानकारी की गणना कर सकता है, जिसे हल्के ग्राहकों के साथ साझा किया जा सकता है। लेकिन प्रकाश ग्राहकों के पास वर्तमान में उस जानकारी की वैधता की जांच करने का कोई व्यावहारिक तरीका नहीं है, क्योंकि परिणामों की संपूर्ण गणना को सीधे सत्यापित करने के लिए इतनी अधिक प्रसंस्करण शक्ति और बैंडविड्थ की आवश्यकता होगी, जो एक हल्के ग्राहक का उपयोग करना व्यर्थ कर देगा।

सौभाग्य से सामान्य के लिए एक सुरक्षित और भरोसेमंद समाधान है काम एक इनपुट डेटासेट के आधार पर अप्रत्यक्ष रूप से दूरस्थ गणनाओं को मान्य करना, जिसे दोनों पक्ष उपलब्ध मानते हैं, भले ही प्राप्त करने वाले पक्ष के पास वास्तविक डेटा न हो, केवल उसका हैश। ठीक यही मामला है हमारे परिदृश्य में जहां एथेरियम ब्लॉकचैन को ऐसी सत्यापित गणना के लिए एक इनपुट के रूप में इस्तेमाल किया जा सकता है। इसका मतलब यह है कि हल्के ग्राहकों के पास पूर्ण नोड्स के करीब क्षमताएं हो सकती हैं क्योंकि वे एक हल्के सर्वर से दूरस्थ रूप से उनके लिए एक ऑपरेशन का मूल्यांकन करने के लिए कह सकते हैं कि वे अन्यथा स्वयं को निष्पादित करने में सक्षम नहीं होंगे। इस सुविधा के विवरण पर अभी भी काम किया जा रहा है और यह इस दस्तावेज़ के दायरे से बाहर है, लेकिन सत्यापन पद्धति का सामान्य विचार डॉ. क्रिश्चियन रीटविसनर द्वारा इसमें समझाया गया है देवकॉन 2 टॉक.

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



Source link

Leave A Reply

Your email address will not be published.

Shares