विटालिक का नया लेख: एथेरियम (V) का संभावित भविष्य — द पर्ज

मूल शीर्षक: एथेरियम प्रोटोकॉल का संभावित भविष्य, भाग 5: पर्ज

विटालिक ब्यूटिरिन का मूल लेख

मूल अनुवाद: ओडेली प्लैनेट डेली हसबैंड हाउ

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

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

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

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

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

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

निम्नलिखित मूल सामग्री है, जिसका अनुवाद ओडेली प्लैनेट डेली द्वारा किया गया है।

जस्टिन ड्रेक, टिम बेइको, मैट गार्नेट, पाइपर मेरियम, मारियस वान डेर विज्डन और टॉमस स्टैनजैक को उनकी प्रतिक्रिया और समीक्षा के लिए विशेष धन्यवाद।

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

• ऐतिहासिक डेटा: इतिहास में किसी भी समय किए गए किसी भी लेन-देन और बनाए गए किसी भी खाते को सभी क्लाइंट द्वारा स्थायी रूप से संग्रहीत किया जाना चाहिए और नेटवर्क से पूरी तरह से सिंक्रनाइज़ होने के लिए किसी भी नए क्लाइंट द्वारा डाउनलोड किया जाना चाहिए। इससे क्लाइंट लोड और सिंक्रोनाइज़ेशन समय समय के साथ बढ़ता है, भले ही चेन की क्षमता स्थिर रहे।

• प्रोटोकॉल विशेषताएँ: पुरानी विशेषताओं को हटाने की तुलना में नई विशेषताएँ जोड़ना अधिक आसान होता है, जिसके कारण समय के साथ कोड की जटिलता बढ़ जाती है।

इथेरियम को लंबे समय तक टिकाऊ बनाए रखने के लिए, हमें इन दोनों प्रवृत्तियों पर मजबूत प्रति-दबाव डालने की ज़रूरत है, जिससे समय के साथ जटिलता और फूलावट कम हो। लेकिन साथ ही, हमें ब्लॉकचेन को महान बनाने वाले प्रमुख गुणों में से एक को संरक्षित करने की आवश्यकता है: स्थायित्व। आप एक NFT, एक प्रेम पत्र को लेन-देन कॉल डेटा में या चेन पर $1 मिलियन के साथ एक स्मार्ट अनुबंध डाल सकते हैं, दस साल के लिए एक गुफा में जा सकते हैं, और बाहर आने पर पा सकते हैं कि यह अभी भी आपके पढ़ने और उससे बातचीत करने का इंतज़ार कर रहा है। DApps को पूरी तरह से विकेंद्रीकृत करने और अपग्रेड कुंजियों को हटाने में सहज महसूस करने के लिए, उन्हें आश्वस्त होने की आवश्यकता है कि उनकी निर्भरता को इस तरह से अपग्रेड नहीं किया जाएगा जो उन्हें तोड़ दे - विशेष रूप से L1 खुद।

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

शुद्धिकरण: प्राथमिक लक्ष्य.

• कम क्लाइंट भंडारण आवश्यकताएँ प्रत्येक नोड के लिए समस्त इतिहास या यहां तक कि अंतिम स्थिति को स्थायी रूप से संग्रहीत करने की आवश्यकता को कम या समाप्त करके।

• अनावश्यक कार्यक्षमता को समाप्त करके प्रोटोकॉल जटिलता को कम करें।

लेख निर्देशिका:

• इतिहास समाप्ति

• राज्य समाप्ति

• सुविधा सफाई

इतिहास समाप्ति

इससे कौन सी समस्या हल होती है?

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

यह क्या है और यह कैसे काम करता है?

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

इससे हमारे पास इतिहास को संग्रहीत करने के लिए बहुत सारे विकल्प बचते हैं। एक स्वाभाविक विकल्प एक ऐसा नेटवर्क है जहाँ प्रत्येक नोड डेटा का केवल एक छोटा सा हिस्सा संग्रहीत करता है। इसी तरह से सीड नेटवर्क दशकों से संचालित होता रहा है: जबकि नेटवर्क कुल मिलाकर लाखों फ़ाइलों को संग्रहीत और वितरित करता है, प्रत्येक भागीदार उनमें से केवल कुछ को संग्रहीत और वितरित करता है। शायद विरोधाभासी रूप से, यह दृष्टिकोण डेटा की मजबूती को कम भी नहीं करता है। यदि, नोड्स को चलाना अधिक किफायती बनाकर, हम 100,000 नोड्स वाला एक नेटवर्क बना सकते हैं, जहाँ प्रत्येक नोड इतिहास का एक यादृच्छिक 10% संग्रहीत करता है, तो डेटा का प्रत्येक भाग 10,000 बार दोहराया जाएगा - बिल्कुल 10,000-नोड नेटवर्क के समान प्रतिकृति कारक, जहाँ प्रत्येक नोड सब कुछ संग्रहीत करता है।

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

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

मौजूदा शोध के साथ इसका क्या संबंध है?

• ईआईपी-4444 ;

• टोरेंट और EIP-4444 ;

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

• पोर्टल नेटवर्क और EIP-4444 ;

• पोर्टल में SSZ ऑब्जेक्ट्स का वितरित भंडारण और पुनर्प्राप्ति ;

• गैस सीमा कैसे बढ़ाएँ (पैराडाइम) .

और क्या किया जाना चाहिए तथा क्या समझौते करने होंगे?

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

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

1. हम यह कैसे सुनिश्चित करें कि नोड्स का सबसे बड़ा समूह वास्तव में सारा डेटा संग्रहीत करता है?

2. हम प्रोटोकॉल में इतिहास भंडारण को कितनी गहराई से एकीकृत करते हैं?

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

(2) के लिए, मूल कार्यान्वयन में केवल वही कार्य शामिल है जो आज पहले से ही किया जा चुका है: पोर्टल पहले से ही एक ERA फ़ाइल संग्रहीत करता है जिसमें एथेरियम का संपूर्ण इतिहास होता है। अधिक गहन कार्यान्वयन में वास्तव में इसे सिंक प्रक्रिया से जोड़ना शामिल होगा, ताकि यदि कोई व्यक्ति पूर्ण इतिहास संग्रहण नोड या संग्रह नोड को सिंक करना चाहता है, तो वे पोर्टल नेटवर्क से सीधे सिंक करके ऐसा कर सकते हैं, भले ही कोई अन्य संग्रह नोड ऑनलाइन मौजूद न हो।

यह बाकी रोडमैप के साथ किस प्रकार से सहक्रिया करता है?

अगर हम नोड को चलाना या स्पिन अप करना बेहद आसान बनाना चाहते हैं, तो इतिहास संग्रहण आवश्यकताओं को कम करना स्टेटलेसनेस से ज़्यादा महत्वपूर्ण है: नोड के लिए आवश्यक 1.1 TB में से ~300 GB स्टेट है, और शेष ~800 GB इतिहास है। केवल स्टेटलेसनेस और EIP-4444 के साथ ही हम स्मार्टवॉच पर एथेरियम नोड चलाने और इसे कुछ ही मिनटों में सेट अप करने के लक्ष्य को प्राप्त कर सकते हैं।
ऐतिहासिक भंडारण को सीमित करने से नए एथेरियम नोड कार्यान्वयन के लिए प्रोटोकॉल के केवल नवीनतम संस्करण का समर्थन करना अधिक व्यवहार्य हो जाता है, जो उन्हें बहुत सरल बनाता है। उदाहरण के लिए, कोड की कई पंक्तियों को अब सुरक्षित रूप से हटाया जा सकता है क्योंकि 2016 के DoS हमले के दौरान बनाए गए खाली स्टोरेज स्लॉट सभी हटा दिए गए हैं। हटाए गए अब चूंकि प्रूफ-ऑफ-स्टेक की ओर कदम बढ़ाना इतिहास बन चुका है, इसलिए ग्राहक सुरक्षित रूप से प्रूफ-ऑफ-वर्क से संबंधित सभी कोड को हटा सकते हैं।

राज्य समाप्ति

इससे कौन सी समस्या हल होती है?

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

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

यह क्या है और यह कैसे काम करता है

आज, जब आप कोई नया स्टेट ऑब्जेक्ट बनाते हैं (जो तीन तरीकों में से किसी एक में हो सकता है: (i) ETH को नए अकाउंट में भेजना, (ii) कोड का उपयोग करके नया अकाउंट बनाना, (iii) पहले से अछूते स्टोरेज स्लॉट को सेट करना), तो वह स्टेट ऑब्जेक्ट हमेशा के लिए उसी स्टेट में रहता है। इसके बजाय, हम चाहते हैं कि ऑब्जेक्ट समय के साथ अपने आप एक्सपायर हो जाएँ। मुख्य चुनौती यह है कि इसे इस तरह से किया जाए कि तीन लक्ष्य प्राप्त हों:

1. दक्षता: समाप्ति प्रक्रिया को चलाने के लिए किसी अतिरिक्त गणना की आवश्यकता नहीं होती।

2. उपयोगकर्ता-मित्रता: यदि कोई व्यक्ति पांच साल के लिए गुफा में चला जाता है और वापस आता है, तो उसे अपने ETH, ERC 20, NFT, CDP पदों तक पहुंच नहीं खोनी चाहिए...

3. डेवलपर-मित्रता: डेवलपर्स को पूरी तरह से अपरिचित मानसिक मॉडल पर स्विच करने की ज़रूरत नहीं है। साथ ही, वर्तमान में अस्थिर और अपडेट न किए गए एप्लिकेशन को ठीक से काम करना जारी रखना चाहिए।

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

ये ऐसे मुद्दे हैं जिन पर एथेरियम कोर डेवलपमेंट समुदाय वर्षों से काम कर रहा है, जिसमें "जैसे प्रस्ताव शामिल हैं ब्लॉकचेन किराया " और " उत्थान अंततः, हमने प्रस्तावों के सर्वोत्तम भागों को संयोजित किया और "सबसे कम ज्ञात समाधानों" की दो श्रेणियों पर ध्यान केंद्रित किया:

• आंशिक स्थिति समाप्ति समाधान

• पता चक्रों के आधार पर समाप्ति की सिफारिशें बताएं।

आंशिक राज्य समाप्ति

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

इन प्रस्तावों के बीच मुख्य अंतर ये हैं: (i) हम कैसे defiहाल ही में, और (ii) हम "ब्लॉक" को कैसे परिभाषित करते हैं? एक विशिष्ट प्रस्ताव है ईआईपी-7736 , जो “स्टेम-एंड-लीफ” डिज़ाइन पर आधारित है वर्क्ले वृक्षों के लिए शुरू किया गया (हालाँकि बाइनरी ट्री जैसे स्टेटलेस स्टेट के किसी भी रूप के साथ संगत है)। इस डिज़ाइन में, हेडर, कोड और स्टोरेज स्लॉट जो एक दूसरे से सटे होते हैं, उन्हें एक ही "ट्रंक" के अंतर्गत संग्रहीत किया जाता है। स्टेम के अंतर्गत संग्रहीत डेटा 256 * 31 = 7,936 बाइट्स तक हो सकता है। कई मामलों में, एक खाते का पूरा हेडर और कोड, साथ ही कई प्रमुख स्टोरेज स्लॉट, एक ही ट्रंक के अंतर्गत संग्रहीत किए जाएँगे। यदि किसी दिए गए ट्रंक के अंतर्गत डेटा को 6 महीने तक पढ़ा या लिखा नहीं गया है, तो डेटा अब संग्रहीत नहीं है, और उस डेटा के लिए केवल 32-बाइट प्रतिबद्धता ("स्टब") संग्रहीत है। भविष्य के लेनदेन जो उस डेटा तक पहुँचते हैं, उन्हें डेटा को "पुनर्जीवित" करने और एक प्रमाण प्रदान करने की आवश्यकता होगी कि यह स्टब के विरुद्ध जाँच करता है।

इसी तरह के विचारों को लागू करने के अन्य तरीके भी हैं। उदाहरण के लिए, अगर खाता स्तर पर विस्तृत जानकारी पर्याप्त नहीं है, तो हम एक ऐसी योजना बना सकते हैं जिसमें पेड़ के प्रत्येक 1/2 32 भाग को एक समान स्टेम-एंड-लीफ तंत्र द्वारा नियंत्रित किया जाता है।

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

पता चक्र आधारित राज्य समाप्ति अनुशंसाएँ

क्या होगा अगर हम किसी भी स्थायी स्थिति वृद्धि से बचना चाहते हैं, यहां तक कि 32-बाइट स्टब भी? यह एक कठिन समस्या है क्योंकि पुनरुत्थान संघर्ष : क्या होगा यदि कोई स्टेट ऑब्जेक्ट हटा दिया जाता है, और बाद में EVM निष्पादन उसी स्थान पर कोई अन्य स्टेट ऑब्जेक्ट डालता है, लेकिन फिर कोई व्यक्ति जो मूल स्टेट ऑब्जेक्ट की परवाह करता है, वापस आता है और उसे पुनर्स्थापित करने का प्रयास करता है? जब स्टेट का कुछ भाग समाप्त हो जाता है, तो स्टब नए डेटा को बनने से रोकता है। स्टेट पूरी तरह समाप्त हो जाने पर, हम स्टब को स्टोर भी नहीं कर सकते।

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

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

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

पता स्थान एक्सटेंशन

एक प्रस्ताव एक नया 32-बाइट पता प्रारूप शुरू करने का है जिसमें संस्करण संख्या, पता चक्र संख्या और विस्तारित हैश शामिल हो।

0x 01 (लाल) 0000 (नारंगी) 000001 (हरा) 57 ऐ 408398 डीएफ 7 इ 5 एफ 4552091 ए 69125 डी5 एफडब्ल्यूएफ 7 बी 8 सी 2659029395 बीडीएफ (नीला).

लाल वाला संस्करण संख्या है। यहाँ चार नारंगी शून्य रिक्त स्थान हैं जो भविष्य में शार्ड संख्याओं को समायोजित कर सकते हैं। हरा वाला पता चक्र संख्या है। नीला वाला 26-बाइट हैश मान है।

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

पता स्थान सिकुड़ना

एक अन्य दृष्टिकोण विपरीत दिशा में जाता है: हम तुरंत आकार 2 128 की कुछ उप-सीमा पर प्रतिबंध लगाते हैं (उदाहरण के लिए, 0x ffffffff से शुरू होने वाले सभी पते), और फिर उस सीमा का उपयोग पता चक्र और 14-बाइट हैश मान वाले पतों को पेश करने के लिए करते हैं।

0x फ़फ़फ़फ़फ़ 000169125 डी5 एफडब्ल्यूएफ 7 बी 8 C2659029395bdF

इस दृष्टिकोण द्वारा किया गया मुख्य बलिदान है प्रतितथ्यात्मक पते प्रस्तुत करने का सुरक्षा जोखिम : ऐसे पते जो संपत्ति या अनुमतियाँ रखते हैं लेकिन जिनका कोड अभी तक चेन में प्रकाशित नहीं हुआ है। जोखिम में कोई ऐसा पता बनाना शामिल है जो दावा करता है कि उसके पास (अभी तक अप्रकाशित) कोड का एक टुकड़ा है, लेकिन उसके पास कोड का एक और वैध टुकड़ा भी है जो उसी पते पर हैश करता है। आज इस तरह के टकराव की गणना करने के लिए 2 80 हैश की आवश्यकता होती है; पता स्थान सिकुड़ने से यह संख्या आसानी से सुलभ 2 56 हैश तक कम हो जाएगी।

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

मौजूदा शोध के साथ इसका क्या संबंध है?

प्रारंभिक प्रस्ताव

• ब्लॉकचेन की सफाई ;

• उत्थान ;

• एथेरियम राज्य आकार प्रबंधन सिद्धांत ;

• राज्यविहीनता और राज्य समाप्ति के लिए कुछ संभावित रास्ते ;

आंशिक स्थिति समाप्ति प्रस्ताव

• ईआईपी-7736 ;

पता स्थान एक्सटेंशन दस्तावेज़ीकरण

• मूल प्रस्ताव ;

• इप्सिलॉन समीक्षा ;

• ब्लॉग पोस्ट टिप्पणियाँ ;

• यदि हम टक्कर प्रतिरोध खो दें तो क्या टूटेगा .

और क्या किया जाना चाहिए तथा क्या समझौते करने होंगे?

मैं आगे बढ़ने के लिए चार संभावित रास्ते देखता हूँ:

• हम इसे स्टेटलेस बनाते हैं, और कभी भी स्टेट एक्सपायरी नहीं करते। स्टेट बढ़ रहा है (हालांकि धीरे-धीरे: हम शायद इसे दशकों तक 8 टीबी से आगे नहीं देखेंगे), लेकिन केवल उपयोगकर्ताओं के एक अपेक्षाकृत विशेष वर्ग द्वारा: यहां तक कि PoS वैलिडेटर को भी स्टेट की आवश्यकता नहीं है।
  एक विशेषता जिसके लिए राज्य के हिस्से तक पहुंच की आवश्यकता होती है वह है समावेश सूची निर्माण, लेकिन हम इसे विकेंद्रीकृत तरीके से कर सकते हैं: प्रत्येक उपयोगकर्ता राज्य ट्राई के उस हिस्से को बनाए रखने के लिए जिम्मेदार है जिसमें उनका अपना खाता होता है। जब वे किसी लेन-देन को प्रसारित करते हैं, तो वे सत्यापन चरण के दौरान एक्सेस किए गए राज्य ऑब्जेक्ट के प्रमाण के साथ इसे प्रसारित करते हैं (यह EOA और ERC-4337 दोनों खातों के लिए काम करता है)। स्टेटलेस वैलिडेटर फिर इन प्रमाणों को संपूर्ण समावेश सूची के प्रमाण में जोड़ सकता है।

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

• हम एड्रेस स्पेस एक्सटेंशन के माध्यम से स्टेट एक्सपायरी कर रहे हैं। इसमें एक बहु-वर्षीय प्रक्रिया शामिल होगी ताकि यह सुनिश्चित किया जा सके कि एड्रेस फॉर्मेट रूपांतरण विधि प्रभावी और सुरक्षित है, जिसमें मौजूदा एप्लिकेशन भी शामिल हैं।

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

महत्वपूर्ण बात यह है कि पता प्रारूप परिवर्तनों पर निर्भर करने वाली राज्य समाप्ति योजना लागू की गई है या नहीं, पता स्थान विस्तार और संकुचन की कठिन समस्या को अंततः हल किया जाना चाहिए। आज, पता टकराव उत्पन्न करने के लिए लगभग 2 80 हैश की आवश्यकता होती है, और यह कम्प्यूटेशनल लोड पहले से ही अत्यंत संसाधन संपन्न अभिनेताओं के लिए संभव है: एक GPU लगभग 2 27 हैश का प्रदर्शन कर सकता है, इसलिए यह एक वर्ष में 2 52 की गणना कर सकता है, इसलिए सभी दुनिया में लगभग 2 30 GPU हैं लगभग 1/4 वर्ष में टकराव की गणना की जा सकती है, और FPGAs और ASIC इस प्रक्रिया को और तेज़ कर सकते हैं। भविष्य में, इस तरह के हमले अधिक से अधिक लोगों के लिए खुले होंगे। इसलिए, पूर्ण राज्य समाप्ति को लागू करने की वास्तविक लागत उतनी अधिक नहीं हो सकती जितनी लगती है, क्योंकि हमें इस बहुत ही चुनौतीपूर्ण पते की समस्या को वैसे भी हल करना है।

यह बाकी रोडमैप के साथ किस प्रकार से सहक्रिया करता है?

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

सुविधा सफाई

इससे कौन सी समस्या हल होती है?

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

यह क्या है और यह कैसे काम करता है?

ऐसा कोई बड़ा एकल समाधान नहीं है जो प्रोटोकॉल की जटिलता को कम कर सके; समस्या की प्रकृति यह है कि इसमें कई छोटे-छोटे समाधान हैं।

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

आज तक पहचाने गए प्रोटोकॉल सरलीकरण अवसरों के कुछ प्रमुख उदाहरणों में निम्नलिखित शामिल हैं। सबसे पहले, ईवीएम के बाहर के कुछ उदाहरण; ये अपेक्षाकृत गैर-आक्रामक हैं और इसलिए इन पर आम सहमति बनाना और कम समय में लागू करना आसान है।

• आरएलपी → एसएसजेड रूपांतरण: मूल रूप से, एथेरियम ऑब्जेक्ट्स को नामक एन्कोडिंग का उपयोग करके क्रमबद्ध किया गया था आरएलपी . RLP अलिखित और अनावश्यक रूप से जटिल है। आज, बीकन चेन का उपयोग करता है एसएसजेड , जो कई मायनों में काफी बेहतर है, जिसमें न केवल सीरियलाइज़ेशन बल्कि हैशिंग का समर्थन करना भी शामिल है। अंततः, हम RLP से पूरी तरह से छुटकारा पाने और सभी डेटा प्रकारों को SSZ संरचनाओं में स्थानांतरित करने की उम्मीद करते हैं, जो बदले में अपग्रेड को बहुत आसान बना देगा। वर्तमान EIP में शामिल हैं [1] [2] [3] .

• विरासती लेनदेन प्रकारों को हटाना: आज बहुत सारे लेनदेन प्रकार हैं, और उनमें से कई को संभावित रूप से हटाया जा सकता है। पूर्ण निष्कासन का एक अधिक विनम्र विकल्प एक खाता अमूर्तन सुविधा है, जिसके द्वारा स्मार्ट खातों में विरासती लेनदेन को संभालने और मान्य करने के लिए कोड हो सकता है यदि वे ऐसा करना चाहते हैं।

• लॉग सुधार: लॉग निर्माण ब्लूम फ़िल्टर और अन्य तर्क प्रोटोकॉल में जटिलता जोड़ते हैं, लेकिन वास्तव में क्लाइंट द्वारा उपयोग नहीं किए जाते हैं क्योंकि यह बहुत धीमा है। हम कर सकते हैं इन सुविधाओं को हटाएँ और विकल्पों पर काम करना, जैसे कि SNARKs जैसी आधुनिक तकनीकों का उपयोग करके प्रोटोकॉल से बाहर विकेन्द्रीकृत लॉग रीडिंग टूल।

• अंततः बीकन चेन सिंक समिति तंत्र को हटा दें: सिंक समिति तंत्र मूल रूप से एथेरियम के लिए लाइट क्लाइंट सत्यापन को सक्षम करने के लिए पेश किया गया था। हालाँकि, यह प्रोटोकॉल की जटिलता को काफी हद तक बढ़ा देता है। अंततः, हम सक्षम हो जाएँगे SNARKs का उपयोग करके सीधे Ethereum सहमति परत को सत्यापित करें , जो एक समर्पित लाइट क्लाइंट सत्यापन प्रोटोकॉल की आवश्यकता को समाप्त कर देगा। संभावित रूप से, सर्वसम्मति परिवर्तन हमें एक अधिक मूल लाइट क्लाइंट प्रोटोकॉल बनाकर सिंक कमेटी को पहले ही हटाने में सक्षम कर सकता है जिसमें एथेरियम सर्वसम्मति सत्यापनकर्ताओं के एक यादृच्छिक उपसमूह से हस्ताक्षरों को सत्यापित करना शामिल है।

• डेटा प्रारूप एकीकरण: आज, निष्पादन स्थिति मर्कल पेट्रीसिया पेड़ों में संग्रहीत है, आम सहमति स्थिति में संग्रहीत है एसएसजेड पेड़ , और ब्लॉब्स के माध्यम से प्रतिबद्ध हैं केजेडजी प्रतिबद्धताएं भविष्य में, ब्लॉक डेटा के लिए एक एकीकृत प्रारूप और स्टेट के लिए एक एकीकृत प्रारूप होना समझदारी होगी। ये प्रारूप सभी महत्वपूर्ण आवश्यकताओं को पूरा करेंगे: (i) स्टेटलेस क्लाइंट के लिए सरल प्रमाण, (ii) डेटा की क्रमिकता और इरेज़र कोडिंग, और (iii) मानकीकृत डेटा संरचनाएँ।

• बीकन चेन समिति को हटाना: यह तंत्र मूल रूप से समर्थन करने के लिए पेश किया गया था निष्पादन शार्डिंग का एक विशिष्ट संस्करण . इसके बजाय, हमने शार्डिंग का काम पूरा कर लिया L2 और ब्लॉब्स के माध्यम से इस प्रकार, समिति अनावश्यक है, इसलिए इसे ख़त्म करने की दिशा में कदम उठाया जा रहा है .

• मिश्रित एंडीयननेस को हटाएँ: EVM बड़ा एंडीयन है, सहमति परत छोटी एंडीयन है। सामंजस्य बिठाना और सब कुछ एक या दूसरे तरीके से बनाना समझदारी हो सकती है (संभवतः बड़ा एंडीयन, क्योंकि EVM को बदलना कठिन है)

अब, ई.वी.एम. के कुछ उदाहरण:

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

• प्रीकंपाइल को हटाना: एथेरियम के पास वर्तमान में मौजूद कई प्रीकंपाइल अनावश्यक रूप से जटिल और अपेक्षाकृत अप्रयुक्त हैं, और किसी भी एप्लिकेशन द्वारा बमुश्किल उपयोग किए जाने पर सहमति विफलताओं के एक बड़े हिस्से के लिए जिम्मेदार हैं। इससे निपटने के दो तरीके हैं (i) बस प्रीकंपाइल को हटाना, और (ii) इसे (अनिवार्य रूप से अधिक महंगे) EVM कोड के एक टुकड़े से बदलना जो समान तर्क को लागू करता है। इस मसौदा ईआईपी में प्रस्ताव किया गया है पहले चरण के रूप में पहचान पूर्व संकलन के लिए ऐसा करना; बाद में, RIPEMD 160, MODEXP, और BLAKE को हटाया जा सकता है।

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

• स्थैतिक विश्लेषण में सुधार: आज EVM कोड का स्थैतिक विश्लेषण करना मुश्किल है, खासकर इसलिए क्योंकि जंप गतिशील हो सकते हैं। इससे EVM कार्यान्वयन को अनुकूलित करना भी कठिन हो जाता है (EVM कोड को अन्य भाषाओं में प्रीकंपाइल करना)। हम इसे इस तरह से ठीक कर सकते हैं गतिशील छलांग हटाना (या उन्हें अधिक महंगा बनाना, उदाहरण के लिए, किसी अनुबंध में JUMPDEST की कुल संख्या की गैस लागत में रैखिक)। EOF बस यही करता है, हालांकि प्रोटोकॉल सरलीकरण लाभ प्राप्त करने के लिए EOF को लागू करना आवश्यक है।

मौजूदा शोध के साथ इसका क्या संबंध है?

• हटाने के लिए अगले चरण ;

• आत्म-विनाश

• एसएसजेड-आधारित ईआईपीएस: [1] [2] [3] ;

• राज्यविहीन गैस लागत में परिवर्तन ;

• रैखिक स्मृति मूल्य निर्धारण ;

• पूर्व संकलित विलोपन ;

• ब्लूम फ़िल्टर हटाया गया ;

• वृद्धिशील सत्यापन योग्य संगणना का उपयोग करके ऑफ-चेन सुरक्षित लॉग पुनर्प्राप्ति के लिए एक विधि (पढ़ें: पुनरावर्ती स्टार्क्स);

और क्या किया जाना चाहिए तथा क्या समझौते करने होंगे?

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

व्यापक सामाजिक समस्या गैर-जरूरी, पिछड़ी-संगतता-तोड़ने वाले परिवर्तन करने के लिए एक मानकीकृत पाइपलाइन बनाना है। इसे संबोधित करने का एक तरीका मौजूदा मिसालों की जांच करना और उनका विस्तार करना है, जैसे कि आत्म-विनाश प्रक्रिया। पाइपलाइन कुछ इस तरह दिखेगी:

1. फ़ीचर एक्स को हटाने के बारे में बात करना शुरू करें;

2. आवेदन पर एक्स को हटाने के प्रभाव को निर्धारित करने के लिए एक विश्लेषण का संचालन करें, और परिणाम के आधार पर: (i) विचार को छोड़ दें, (ii) योजना के अनुसार आगे बढ़ें, या (iii) एक्स को हटाने और आगे बढ़ने के लिए एक संशोधित "सबसे कम विघटनकारी" दृष्टिकोण निर्धारित करें;

3. X को अप्रचलित करने के लिए एक औपचारिक EIP बनाएं। सुनिश्चित करें कि लोकप्रिय उच्च-स्तरीय बुनियादी ढांचे (जैसे प्रोग्रामिंग भाषाएं, वॉलेट) इसका सम्मान करते हैं और सुविधा का उपयोग करना बंद कर देते हैं।

4. अंत में, वास्तव में X को हटा दें;

चरण 1 और 4 के बीच एक बहु-वर्षीय पाइपलाइन होनी चाहिए, जिसमें स्पष्ट रूप से बताया जाना चाहिए कि कौन सी परियोजनाएँ किस चरण में हैं। इस बिंदु पर, फीचर हटाने की प्रक्रिया की तीव्रता और गति बनाम अधिक रूढ़िवादी होने और प्रोटोकॉल विकास के अन्य क्षेत्रों में अधिक संसाधनों का निवेश करने के बीच एक समझौता है, लेकिन हम पेरेटो सीमा से बहुत दूर हैं।

ईओएफ

ईवीएम में प्रस्तावित मुख्य परिवर्तन इस प्रकार हैं: ईवीएम ऑब्जेक्ट फॉर्मेट (ईओएफ) EOF बहुत सारे बदलाव लाता है, जैसे कि गैस अवलोकनीयता को अक्षम करना, कोड अवलोकनीयता (यानी कोई CODECOPY नहीं), और केवल स्थिर जंप की अनुमति देना। लक्ष्य EVM को इस तरह से और अधिक उन्नत करने की अनुमति देना है कि इसमें मजबूत गुण हों और साथ ही पिछड़ी संगतता बनी रहे (क्योंकि EOF से पहले का EVM अभी भी मौजूद है)।

इसका लाभ यह है कि यह नई EVM सुविधाओं को जोड़ने के लिए एक स्वाभाविक मार्ग बनाता है और मजबूत गारंटी के साथ एक सख्त EVM में माइग्रेशन को प्रोत्साहित करता है। नुकसान यह है कि यह प्रोटोकॉल की जटिलता को काफी हद तक बढ़ा देता है जब तक कि हम अंततः पुराने EVM को हटाने और हटाने का कोई तरीका नहीं खोज लेते। एक बड़ा सवाल यह है: EVM सरलीकरण प्रस्ताव में EOF क्या भूमिका निभाता है, खासकर अगर लक्ष्य पूरे EVM की जटिलता को कम करना है?

यह बाकी रोडमैप के साथ किस प्रकार से सहक्रिया करता है?

बाकी रोडमैप में सुधार के लिए दिए गए कई सुझाव पुरानी सुविधाओं को सरल बनाने के अवसर भी हैं। ऊपर दिए गए कुछ उदाहरणों को दोहराते हैं:

• एकल-स्लॉट अंतिमता पर स्विच करने से हमें समितियों को हटाने, अर्थशास्त्र को पुनः डिजाइन करने, तथा प्रूफ-ऑफ-स्टेक से संबंधित अन्य सरलीकरण करने का अवसर मिलता है।

• खाता अमूर्तता को पूर्ण रूप से क्रियान्वित करने से हम बहुत सारे मौजूदा लेनदेन प्रसंस्करण तर्क को हटा सकेंगे और इसे "डिफ़ॉल्ट खाता EVM कोड" में स्थानांतरित कर सकेंगे, जिसे सभी EOA प्रतिस्थापित कर सकते हैं।

• यदि हम इथेरियम अवस्था को बाइनरी हैश वृक्ष में स्थानांतरित करते हैं, तो इसे SSZ के नए संस्करण के साथ समन्वित किया जा सकता है, ताकि सभी इथेरियम डेटा संरचनाओं को उसी तरह हैश किया जा सके।

एक अधिक क्रांतिकारी दृष्टिकोण: प्रोटोकॉल के बड़े हिस्से को अनुबंध कोड में परिवर्तित करना

एथेरियम को सरल बनाने के लिए एक अधिक क्रांतिकारी रणनीति यह होगी कि प्रोटोकॉल को बरकरार रखा जाए, लेकिन इसके अधिकांश भाग को प्रोटोकॉल कार्यक्षमता से हटाकर अनुबंध कोड में स्थानांतरित कर दिया जाए।

सबसे चरम संस्करण एथेरियम L1 को “तकनीकी रूप से” केवल बीकन श्रृंखला बनाना होगा, और एक न्यूनतम वर्चुअल मशीन (जैसे RISC-वी , काहिरा , या कुछ और भी न्यूनतम विशेष रूप से प्रूफ सिस्टम के लिए) जो दूसरों को अपने स्वयं के रोलअप बनाने की अनुमति देता है। तब ईवीएम इन रोलअप में से पहला बन जाएगा। विडंबना यह है कि यह बिल्कुल वैसा ही परिणाम है जैसा कि 2019-20 निष्पादन पर्यावरण प्रस्ताव , हालांकि SNARKs इसे वास्तव में लागू करने के लिए अधिक व्यवहार्य बनाता है।

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

यह लेख इंटरनेट से लिया गया है: विटालिक का नया लेख: एथेरियम (V) का संभावित भविष्य - द पर्ज