Trending News

BTC
$16,966.38
+0.15
ETH
$1,248.52
-0.62
LTC
$78.27
-2.09
DASH
$45.76
-1.97
XMR
$142.43
-0.84
NXT
$0.00
+6.04
ETC
$19.31
-0.16

गेथ के बारे में पूछें: स्नैपशॉट त्वरण

0


*यह एक का भाग #1 है श्रृंखला जहां कोई भी गेथ के बारे में प्रश्न पूछ सकता है और मैं एक मिनी राइटअप के साथ प्रत्येक सप्ताह सबसे अधिक वोट वाले व्यक्ति का उत्तर देने का प्रयास करूंगा। इस सप्ताह का सर्वाधिक मतदान वाला प्रश्न था: क्या आप साझा कर सकते हैं कि कैसे फ्लैट डीबी संरचना विरासती संरचना से अलग है?*

एथेरियम में राज्य

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

एथेरियम दो अलग-अलग प्रकार की स्थिति रखता है: खातों का सेट; और प्रत्येक अनुबंध खाते के लिए भंडारण स्लॉट का एक सेट। एक से विशुद्ध रूप से अमूर्त परिप्रेक्ष्य, ये दोनों सरल कुंजी/मान मैपिंग हैं। खातों का सेट उनके गैर, शेष राशि, आदि को संबोधित करता है। एकल अनुबंध का एक भंडारण क्षेत्र मनमाने ढंग से कुंजियों को मैप करता है – अनुबंध द्वारा परिभाषित और उपयोग किया जाता है – मनमाने मूल्यों के लिए।

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

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

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

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

दो विचारों को मिलाएं – एक पेट्रीसिया ट्री का ट्री लेआउट और एक मर्कल ट्री का हैशिंग एल्गोरिथम – और आप एक के साथ समाप्त होते हैं मर्कल पेट्रीसिया ट्री, एथेरियम में राज्य का प्रतिनिधित्व करने के लिए उपयोग की जाने वाली वास्तविक डेटा संरचना। संशोधनों, सम्मिलनों, विलोपनों और सत्यापन के लिए गारंटीशुदा लघुगणकीय जटिलता! एक छोटा अतिरिक्त यह है कि कोशिशों को संतुलित करने के लिए प्रविष्टि से पहले चाबियों को धोया जाता है।

एथेरियम में स्टेट स्टोरेज

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

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

[Of course all client implementations try their best to minimize this overhead. Geth uses large memory areas for caching trie nodes; and also uses in-memory pruning to avoid writing to disk nodes that get deleted anyway after a few blocks. That’s for a different blog post however.]

ये संख्या जितनी भयानक हैं, ये एक एथेरियम नोड के संचालन की लागतें हैं और हर समय क्रिप्टोग्राफिक रूप से सभी राज्यों को सत्यापित करने की क्षमता रखते हैं। लेकिन क्या हम बेहतर कर सकते हैं?

सभी एक्सेस समान नहीं बनाए गए हैं

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

हर बार जब हम इसे डिस्क से ऊपर खींचते हैं, तो हर राज्य वस्तु को सत्यापित और पुन: सत्यापित करने का कोई मतलब नहीं है। मर्कल पेट्रीसिया का पेड़ लिखने के लिए आवश्यक है, लेकिन यह पढ़ने के लिए एक उपरि है। हम इससे छुटकारा नहीं पा सकते, और हम इसे पतला नहीं कर सकते; लेकिन उस इसका मतलब यह नहीं है हमें अनिवार्य रूप से हर जगह इसका इस्तेमाल करना चाहिए।

एक इथेरियम नोड कुछ अलग स्थानों में राज्य तक पहुँचता है:

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

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

बेशक, हमेशा एक व्यापार बंद होता है। ट्राइ से छुटकारा पाने के बिना, कोई भी नई त्वरण संरचना अतिरिक्त ओवरहेड है। सवाल यह है कि क्या अतिरिक्त ओवरहेड इसकी गारंटी देने के लिए पर्याप्त मूल्य प्रदान करता है?

वापस जड़ों की ओर

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

जैसा कि इस पोस्ट की शुरुआत में बताया गया है, सैद्धांतिक आदर्श एथेरियम की स्थिति के लिए डेटा भंडारण एक साधारण कुंजी-मूल्य स्टोर (खातों और प्रत्येक अनुबंध के लिए अलग) है। हालांकि, मर्कल पेट्रीसिया पेड़ की बाधाओं के बिना, “कुछ भी नहीं” हमें वास्तव में आदर्श समाधान को लागू करने से रोक रहा है!

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

जब भी हम किसी खाते या स्टोरेज स्लॉट तक पहुंचना चाहते हैं, तो हम ट्राई के अनुसार 7-8 के बजाय केवल 1 LevelDB लुकअप का भुगतान करते हैं। स्नैपशॉट को अपडेट करना सिद्धांत रूप में भी सरल है, एक ब्लॉक को संसाधित करने के बाद हम प्रति अपडेटेड स्लॉट में 1 अतिरिक्त लेवलडीबी लिखते हैं।

स्नैपशॉट अनिवार्य रूप से ओ (लॉग एन) से ओ (1) (टाइम लेवलडीबी ओवरहेड) से ओ (लॉग एन) से ओ (1 + लॉग एन) तक लिखने की लागत पर ओ (लॉग एन) से पढ़ता है (टाइम डीबी ओवरहेड) और डिस्क स्टोरेज बढ़ाना ओ (एन लॉग एन) से ओ (एन + एन लॉग एन) तक।

शैतान विवरण में है

एथेरियम राज्य के प्रयोग करने योग्य स्नैपशॉट को बनाए रखना इसकी जटिलता है। जब तक ब्लॉक एक के बाद एक आ रहे हैं, हमेशा आखिरी के शीर्ष पर निर्माण करते हैं, स्नैपशॉट कार्यों में विलय करने का अनुभवहीन दृष्टिकोण काम करता है। हालांकि, अगर कोई मिनी रीऑर्ग है (यहां तक ​​कि एक ब्लॉक भी), तो हम मुश्किल में हैं, क्योंकि कोई पूर्ववत नहीं है। फ्लैट डेटा प्रतिनिधित्व के लिए लगातार लिखना एकतरफा संचालन है। मामलों को बदतर बनाने के लिए, पुराने राज्य तक पहुंचना (उदाहरण के लिए कुछ डीएपी के लिए 3 ब्लॉक पुराने या तेज/स्नैप सिंक के लिए 64+) असंभव है।

इस सीमा को पार करने के लिए, गेथ का स्नैपशॉट दो संस्थाओं से बना है: एक स्थायी डिस्क परत जो पुराने ब्लॉक का एक पूर्ण स्नैपशॉट है (उदाहरण के लिए HEAD-128); और इन-मेमोरी डिफरेंशियल लेयर्स का एक ट्री जो शीर्ष पर राइट्स को इकट्ठा करता है।

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

यह डेटा प्रतिनिधित्व बहुत शक्तिशाली है क्योंकि यह बहुत सारे मुद्दों को हल करता है। चूंकि इन-मेमोरी डिफरेंशियल लेयर्स को एक ट्री में इकठ्ठा किया जाता है, 128 ब्लॉक से अधिक उथले रीऑर्ग्स केवल पैरेंट ब्लॉक से संबंधित डिफरेंशियल लेयर को चुन सकते हैं और वहां से आगे का निर्माण कर सकते हैं। पुराने राज्य की आवश्यकता वाले डीएपी और रिमोट सिंकर्स के पास 128 हाल के लोगों तक पहुंच है। 128 मैप लुकअप की लागत में वृद्धि होती है, लेकिन 128 इन-मेमोरी लुकअप परिमाण के क्रम में 8 डिस्क की तुलना में तेजी से होते हैं, लेवलडीबी द्वारा 4x-5x प्रवर्धित किया जाता है।

बेशक, बहुत सारे और बहुत सारे गोचा और चेतावनी हैं। बहुत अधिक विवरण में जाने के बिना, बारीक बिंदुओं की एक त्वरित सूची है:

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

अच्छा, बुरा बदसूरत

गेथ की स्नैपशॉट त्वरण संरचना परिमाण के क्रम से राज्य की पठन जटिलता को कम करती है। इसका मतलब है कि रीड-आधारित DoS को परिमाण का एक क्रम प्राप्त करना कठिन होता है; तथा eth_call आमंत्रणों को तेजी से परिमाण का क्रम मिलता है (यदि सीपीयू बाध्य नहीं है)।

स्नैपशॉट सबसे हाल के ब्लॉकों के तेज राज्य पुनरावृत्ति को तेज करने में सक्षम बनाता है। यह वास्तव में स्नैपशॉट बनाने का मुख्य कारण थाक्योंकि इसने नए के निर्माण की अनुमति दी थी चटकाना सिंक एल्गोरिथम. यह बताते हुए कि यह एक पूरी तरह से नया ब्लॉग पोस्ट है, लेकिन रिंकीबी पर नवीनतम बेंचमार्क वॉल्यूम बोलते हैं:

बेशक, ट्रेड-ऑफ हमेशा मौजूद होते हैं। प्रारंभिक सिंक पूर्ण होने के बाद, प्रारंभिक स्नैपशॉट बनाने में मेननेट पर लगभग 9-10 घंटे लगते हैं (इसे बाद में लाइव रखा जाता है) और इसमें लगभग 15+GB अतिरिक्त डिस्क स्थान लगता है।

बदसूरत हिस्से के लिए? खैर, स्नैपशॉट को शिप करने के लिए पर्याप्त आत्मविश्वास महसूस करने में हमें 6 महीने से अधिक का समय लगा, लेकिन अब भी यह पीछे है –स्नैपशॉट ध्वज और स्मृति उपयोग और क्रैश पुनर्प्राप्ति के आसपास अभी भी ट्यूनिंग और पॉलिशिंग की जानी है।

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

उपसंहार

आशा है आपको की यह पहली पोस्ट अच्छी लगी होगी Getho के बारे में पूछें. मुझे इसे पूरा करने में जितना मैंने लक्ष्य रखा था, उससे लगभग दोगुना समय लगा, लेकिन मुझे लगा कि विषय अतिरिक्त समय का हकदार है। आपसे अगले हफ्ते मिलते हैं।

[PS: I deliberately didn’t link the asking/voting website into this post as I’m sure it’s a temporary thing and I don’t want to leave broken links for posterity; nor have someone buy the name and host something malicious in the future. You can find it among my Twitter posts.]





Source link

Leave A Reply

Your email address will not be published.

Shares