Ethereum अपग्रेड के अंदर: Hegotá

Ethlabs Hegotá के लिए किन चीज़ों को प्राथमिकता दे रहा है और क्यों।

Ethereum की दिशा उन सभी के लिए मायने रखती है जो इस पर निर्माण करते हैं, इसका उपयोग करते हैं, ETH रखते हैं, या बस उस चीज़ में विश्वास करते हैं जो यह बन सकता है। जबकि यह भविष्य अंततः उन लोगों, अनुप्रयोगों और समुदायों द्वारा निर्धारित किया जाएगा जो हर दिन Ethereum पर निर्माण कर रहे हैं, नेटवर्क अपग्रेड उन प्राथमिक तरीकों में से एक हैं जिनसे प्रोटोकॉल उनकी ज़रूरतों को पूरा करने के लिए विकसित होता है। Hegotá, Glamsterdam के बाद अगला नियोजित Ethereum नेटवर्क अपग्रेड है, और यह दस्तावेज़ Ethlabs के दृष्टिकोण को साझा करता है कि हमारा मानना है कि Ethereum को इसके लिए क्या प्राथमिकता देनी चाहिए, और क्यों।

Ethlabs एक 8-सप्ताह पुरानी Ethereum और ETH के लिए गैर-लाभकारी R&D लैब है और हमारा मिशन Ethereum को वैश्विक अर्थव्यवस्था की सेटलमेंट लेयर बनाना है। हम वास्तविक दुनिया के Ethereum उपयोग और प्रोटोकॉल विकास के बीच बैठते हैं, और हम अपना समय उपयोगकर्ताओं, वॉलेट्स, अनुप्रयोगों, रोलअप्स, संस्थानों, ETH धारकों, शोधकर्ताओं और क्लाइंट टीमों को सुनने में बिताते हैं। कभी-कभी हम ऑनचेन भी बनाते हैं, क्योंकि आप इसमें भाग लिए बिना एक अखाड़ा नहीं बना सकते! हम मानते हैं कि महान प्रोटोकॉल इंजीनियरिंग को महान उत्पादों को संभव बनाना चाहिए, और महान उत्पादों को यह सूचित करने में मदद करनी चाहिए कि प्रोटोकॉल आगे कहाँ जाता है।

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

Hegotá अपग्रेड के लिए, सभी प्रस्तावित EIPs को देखते हुए, ये वे क्षेत्र हैं जिन्हें हम Ethereum के लिए सर्वोच्च प्राथमिकता के रूप में देखते हैं:

1. मजबूत सेंसरशिप प्रतिरोध: किसी को भी अपना लेन-देन शामिल करवाने में सक्षम होना चाहिए, चाहे वे कोई भी हों या Ethereum का उपयोग किस लिए करते हों।
2. तेज़ Ethereum: तेज़ ब्लॉक का मतलब है तेज़ पुष्टिकरण, ताज़ा ऑनचेन मूल्य और तेज़ अंतिमता।
3. नेटिव अकाउंट एब्स्ट्रैक्शन: अकाउंट को पासकी, प्रायोजित लेन-देन, टोकन में गैस भुगतान, बैचिंग और मजबूत गोपनीयता का समर्थन करना चाहिए, जिसमें पोस्ट-क्वांटम कुंजियों का मार्ग हो।
4. निरंतर L1 स्केलिंग: अनुप्रयोगों को ऐसी क्षमता की आवश्यकता है जो किफायती और पूर्वानुमानित बनी रहे, मांग बढ़ने पर भी।

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

पहली बात: EIP प्रक्रिया वास्तव में कैसे काम करती है?

प्रस्तावों में गोता लगाने से पहले, एक महत्वपूर्ण बिंदु: Hegotá की स्कोपिंग प्रक्रिया का दूसरा चरण अभी शुरू हुआ है। पहले चरण ने FOCIL को Hegotá के हेडलाइनर के रूप में चुना। 6 अगस्त को गैर-हेडलाइनर EIP प्रस्तावित करने की समय सीमा थी, और ACD प्रक्रिया अब समग्र रूप से Hegotá अपग्रेड का आकलन करने के लिए आगे बढ़ेगी।

नीचे दिए गए सभी EIP वर्तमान में PFI (Proposed for Inclusion) चरण में हैं, हेडलाइनर प्रक्रिया से गुज़रे EIPs के अपवाद के साथ। शामिल करने के लिए EIP प्रस्तावित करना अनुमति रहित है, और अधिकांश कभी भी अंतिम अपग्रेड में शामिल नहीं होते हैं।

विशेष रूप से, जैसे-जैसे कार्यान्वयन कार्य आगे बढ़ता है, प्रस्ताव समीक्षा और अंततः शिप करने के विश्वास के उत्तरोत्तर मजबूत चरणों से गुज़रते हैं:

• PFI (Proposed for Inclusion): अपग्रेड के लिए एक विचार प्रस्तावित किया गया है। यह चरण अनुमति रहित है और इसका अर्थ क्लाइंट समर्थन या अंतिम समावेश नहीं है।
• CFI (Considered for Inclusion): क्लाइंट टीमों ने प्रस्ताव की समीक्षा की है और प्रोटोटाइप और परीक्षण करने का इरादा रखती हैं।
• SFI (Scheduled for Inclusion): इसे शामिल करने का व्यापक इरादा है, यह मानते हुए कि कार्यान्वयन और परीक्षण अच्छा चलता रहे।

यह जानने के लिए कि यह प्रक्रिया कैसे काम करती है, हम Tim Beiko का त्वरित विवरण यहाँ देखने की सलाह देते हैं।

प्रबंधन: इस लेख को कैसे नेविगेट करें

हम Hegotá के लिए EIP प्राथमिकता के बारे में अपना दृष्टिकोण व्यक्त करने के लिए Forkcast की टियर सूची का पालन करते हैं। निर्णय को कम करने के लिए हम सभी समीक्षित EIPs को निम्नलिखित व्याख्याओं के साथ चार स्तरों में मैप करते हैं:

• [S-tier] शामिल करने की दृढ़ता से अनुशंसा करते हैं।
• [A-tier] शामिल करने की अनुशंसा करते हैं यदि शेष बाधाएं जैसे कार्यान्वयन जटिलता, प्रभाव विश्लेषण, या अपनाना हल हो जाते हैं।
• [B-tier] सार्थक, लेकिन इस अपग्रेड के लिए एक खिंचाव।
• [D-tier] अपने वर्तमान स्वरूप में Hegotá में शामिल करने की अनुशंसा नहीं करते हैं।
• [forming opinion] हम अभी भी इस EIP पर अपनी राय बना रहे हैं।

कृपया ध्यान दें कि ये Ethlabs की \सिफारिशें\ हैं। हम प्रत्येक प्रस्ताव का मूल्यांकन मुख्य रूप से उद्देश्य, विशिष्टता और व्यवहार्य कार्यान्वयन जटिलता की हमारी समझ के संदर्भ में करते हैं, सिवाय उन मामलों के जहां हमारे पास अधिक निश्चितता या प्रत्यक्ष भागीदारी है (जैसे Frames और Quick Slots), और प्रक्रिया में आगे बढ़ने पर ethPandaOps, परीक्षण टीमों और क्लाइंट्स के आकलन के आधार पर अपने दृष्टिकोण को अपडेट करेंगे।

[CL] का अर्थ है कि एक EIP सर्वसम्मति-लेयर क्लाइंट्स को प्रभावित करता है और [EL] का अर्थ है कि यह निष्पादन-लेयर क्लाइंट्स को प्रभावित करता है।

ध्यान दें कि हम कई EIPs (FOCIL, Frame Transactions, और Quick Slots सहित) के सह-लेखक और इसमें शामिल हैं। जबकि हम अपनी भागीदारी या न होने से स्वतंत्र रूप से सभी EIPs का आकलन करने का प्रयास करते हैं, कृपया हमारी स्थिति का मूल्यांकन करते समय इसे ध्यान में रखें।

tl;dr

CL रैंकिंग

आप Forkcaster पर इस विशिष्ट [CL] रैंकिंग पर पुनरावृति कर सकते हैं यहाँ।

EL रैंकिंग

आप Forkcaster पर इस विशिष्ट [EL] रैंकिंग पर पुनरावृति कर सकते हैं यहाँ।

अब, और अधिक हलचल के बिना, यहाँ Hegota अपग्रेड पर हमारे विचार हैं जैसा कि वे आज हैं, अपनी संपूर्णता में:

Hegotá के लिए थीम

0. FOCIL: सेंसरशिप-प्रतिरोध को मजबूत करें

EIP-7805: FOCIL पहले से ही SFI'd है और Hegotá के हेडलाइनर के रूप में पुष्टि की गई है। Ethlabs टीम के तीन सदस्य (Francesco, Barnabé और Julian) इसके सह-लेखकों में से हैं, और हम इसके शामिल होने का दृढ़ता से समर्थन करते हैं। यह देखते हुए कि निर्णय पहले से ही लॉक है, हम इसे संक्षिप्त रखते हैं। केवल एक श्रृंखला जो सभी के प्रति तटस्थ है, वह सभी के लिए विश्वास की जड़ बन सकती है। यही Ethereum को वैश्विक अर्थव्यवस्था और उसके भीतर हर एक व्यक्ति के लिए सच्ची सेटलमेंट लेयर बनने के लिए स्केल करने देता है।

1. Quick Slots: तेज़ Ethereum

Ethereum का 12-सेकंड का स्लॉट एक विलंबता लागत है जो उपयोगकर्ता मूल्य को कम करता है। इसलिए हम Hegotá में [CL] EIP-8198: Quick Slots [S-tier] शामिल करने की दृढ़ता से अनुशंसा करते हैं, चार कारणों से:

1. तेज़ tx पुष्टिकरण के साथ L1 पर बेहतर UX।
2. L1 पर ऑनचेन बाजार ताज़ा कीमतों पर चलते हैं, जिससे स्प्रेड और LP अर्थशास्त्र में सुधार होता है।
3. अंतिमता और तेज़ पुष्टिकरण नियम स्लॉट समय को विरासत में लेते हैं, इसलिए तेज़ ब्लॉक के साथ दोनों तेज़ हो जाते हैं, Ethereum के साथ अंतरसंचालनीयता में सुधार करते हैं।
4. प्रति सेकंड अधिक ब्लॉक प्रस्तावकों का अर्थ है बढ़ी हुई सेंसरशिप-प्रतिरोध, जिसमें आर्थिक सेंसरशिप-प्रतिरोध भी शामिल है: कुछ समय के लिए ब्लॉक को खाली रखने के लिए आपको जो राशि चुकानी होगी।

Ethereum के अद्वितीय विकेंद्रीकरण को संरक्षित करते हुए तेज़ होना Ethereum ब्लॉकस्पेस को अधिक मूल्यवान बनाता है, और वह मूल्य नेटवर्क और ETH को जाता है। हर कमी हमारे उपयोगकर्ताओं को तुरंत अधिक मूल्य प्रदान करती है। अंत में, तेज़ ब्लॉक एप्लिकेशन डेवलपर्स से सबसे अधिक अनुरोधित परिवर्तनों में से एक हैं।

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

• एक बार का रीफैक्टर जो विशिष्टताओं और क्लाइंट कोड में स्लॉट समय को अपडेट करना आसान बनाता है।
• Hegotá में पहली कमी, उसके बाद बाद के फोर्क्स में और कमी, जैसे-जैसे रोडमैप आगे बढ़ता है और सुरक्षा के अनुभवजन्य साक्ष्य प्राप्त होते हैं।

Hegotá एक बार की लागत चुकाने के लिए सही फोर्क है। Glamsterdam में ePBS पहले से ही स्लॉट को पुनर्गठित करता है। Hegotá तब सर्वसम्मति परत के लिए एक अपेक्षाकृत हल्का फोर्क है, एक खिड़की जो I* में डिकपल्ड कंसेंसस के साथ बंद हो जाती है, इसलिए एक बार के रीफैक्टर के लिए CL बैंडविड्थ अब उपलब्ध है जिस तरह से यह कई फोर्क्स के लिए फिर से नहीं होगा।

अर्थ: हम या तो अगले दो वर्षों के लिए न्यूनतम 12 सेकंड पर रहने के लिए प्रतिबद्ध हैं, या Hegotá में ~एक वर्ष में 10 सेकंड, और संभवतः उसके बाद के वर्ष तक 10 सेकंड से कम लैंड करते हैं। ये दो कमी सैद्धांतिक सुधार नहीं हैं। वे सीधे बढ़े हुए उपयोगकर्ता मूल्य और बेहतर नेटवर्क अर्थशास्त्र प्राप्त करते हैं। हमें लगता है कि शुरू करने का समय आ गया है।

सबसे आम पुशबैक

हम यहाँ 4 महत्वपूर्ण बिंदुओं पर चर्चा करते हैं जो क्लाइंट डेवलपर्स और EF प्रोटोकॉल के साथ प्रारंभिक चर्चा के दौरान उठाए गए थे:

1. कार्यान्वयन जटिलता: मिलीसेकंड-सटीक स्लॉट टाइमिंग पहले से ही ePBS कार्य के माध्यम से सर्वसम्मति विशिष्टताओं में विलय कर दी गई है, और EIP-8198 के लिए ड्राफ्ट CL और EL विशिष्टताएं मौजूद हैं, जिनमें प्रति-सेकंड व्यवहार को संरक्षित करने के लिए बेस फीस, गैस लिमिट और ब्लॉब शेड्यूल को पुनर्स्केल किया गया है। शेष लागत क्लाइंट्स और टूलिंग में किनारे के मामलों की एक पूंछ है जो एक निश्चित स्लॉट समय मानते हैं, साथ ही परीक्षण भी। एक बार का रीफैक्टर ठीक इसी काम को आगे लाता है। उसके बाद प्रत्येक कमी एक पैरामीटर परिवर्तन है।

2. zkEVM प्रूविंग: दो मुख्य मुद्दे सापेक्ष प्रूविंग समय और स्थिर प्रूविंग ओवरहेड हैं।

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

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

2.2 zkEVM प्रूविंग मुख्य रूप से ब्लॉक आकार के साथ रैखिक रूप से स्केल होती है, कुछ निश्चित ओवरहेड को छोड़कर। तेज़ स्लॉट का मतलब है कि निश्चित ओवरहेड अधिक बार भुगतान किया जाता है, जो समान थ्रूपुट के लिए अधिक विलंबता जोड़ता है। विलंबता का एक निश्चित बजट देखते हुए, किसी को यह सुनिश्चित करना होगा कि अभी भी अच्छा थ्रूपुट प्राप्त किया जा सके। यहाँ हम दो अवसर देखते हैं: पहला, इंजीनियरिंग प्रगति इन निश्चित संचालनों की विलंबता को कम करती रहेगी। दूसरा, EIP-7862 द्वारा वर्णित स्टेट रूट गणना में देरी करना, प्रूविंग के अधिक हिस्से को महत्वपूर्ण पथ से बाहर ले जाता है, जिसका अर्थ है कि हम असम्पीडित संचालन के लिए अपना विलंबता बजट बढ़ा सकते हैं। इन दो अवसरों का अभिसरण हमें बताता है कि तेज़ स्लॉट भविष्य में पर्याप्त थ्रूपुट वृद्धि में बाधा नहीं डालेंगे।

3. पोस्ट-क्वांटम संक्रमण: डिकपल्ड कंसेंसस दृष्टिकोण को भविष्य की सर्वसम्मति वास्तुकला के संबंध में स्थिर माने जाने के लिए पर्याप्त समर्थन प्राप्त हुआ है। डिकपलिंग का अर्थ है अंतिमता मतदान को ब्लॉक उत्पादन के महत्वपूर्ण पथ से बाहर ले जाना। विशेष रूप से, PQ हस्ताक्षरों का बड़े पैमाने पर एकत्रीकरण, और सभी संबंधित पुनरावर्ती STARK मशीनरी, महत्वपूर्ण पथ से बाहर होगी। ब्लॉक उत्पादन के लिए, और परिणामी श्रृंखला के शीर्ष को ट्रैक करने के लिए फोर्क चॉइस नियम प्राप्त करने के लिए जो कुछ बचा है, वह एक उपसमिति है जिसमें वर्तमान में 512 वैलिडेटर शामिल होने की उम्मीद है, और संभवतः 256। पोस्ट-क्वांटम हस्ताक्षर आकार बड़े होते हैं, लेकिन प्रस्तावित 10 सेकंड के स्लॉट समय और संभवतः भविष्य में कम समय में प्रचार करने में सहज होते हैं।

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

2. अकाउंट एब्स्ट्रैक्शन: UX, सुरक्षा और गोपनीयता में सुधार

Ethereum और इसका व्यापक पारिस्थितिकी तंत्र लंबे समय से नेटिव AA के लिए अतिदेय है, जो पासकी वॉलेट, प्रायोजित लेन-देन, ERC20 गैस भुगतान, लेन-देन बैचिंग और बहुत कुछ जैसे UX लाभ लाएगा।

हालाँकि, नेटिव AA का रास्ता विशेष रूप से उबड़-खाबड़ रहा है क्योंकि AA Ethereum स्टैक के हर हिस्से को छूता है, जिसमें क्लाइंट, L2s, वॉलेट, RPCs, डेव टूलिंग आदि शामिल हैं, इसलिए इसे हितधारकों की एक विशाल विविधता से खरीद-फरोख्त की आवश्यकता होती है। यह किसी भी AA EIP के लिए Ethereum की सर्वसम्मति-संचालित विकास प्रक्रिया के माध्यम से आगे बढ़ना मुश्किल बनाता है, लेकिन EIP शिप होने के बाद व्यावहारिक अपनाने को प्राप्त करना भी मुश्किल बनाता है।

इसलिए हम Hegotá के नेटिव AA प्रस्ताव, Frame Transactions को A-tier में रखते हैं, इसलिए नहीं कि यह तकनीकी रूप से S के लिए पर्याप्त अच्छा नहीं है, बल्कि इसलिए कि हम व्यावहारिक अपनाने के जोखिमों को ध्यान में रखना चाहते हैं जिन्हें हल करने के लिए भारी मात्रा में समन्वय की आवश्यकता होगी। AA में अपनी टीम की पृष्ठभूमि को देखते हुए, Ethlabs का इरादा L2s और वॉलेट जैसे हितधारकों के साथ काम करके नेटिव AA के लिए एक सफल रोलआउट देने के लिए Frame Transactions को बाजार में लाने में एक प्रमुख भूमिका निभाने का है।

अब Hegotá के लिए विशिष्ट AA प्रस्तावों पर।

[EL] EIP-8141: Frame Transactions [A-tier]

हमारा मानना है कि EIP-8141: Frame Transactions Ethereum की नेटिव AA प्रणाली के लिए सबसे अच्छा उम्मीदवार है। अन्य नेटिव AA प्रस्तावों की तुलना में, Frames में कई वांछनीय गुण हैं जो इसे Ethereum के CROPS जनादेश के साथ विशिष्ट रूप से संरेखित करते हैं:

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

Frame Transactions की मुख्य कमजोरी इसकी सबसे बड़ी ताकत से भी उपजी है: क्योंकि सत्यापन EVM कोड द्वारा नियंत्रित होता है, सत्यापन अब एक निश्चित लागत के बजाय एक गतिशील लागत प्रेरित करता है, जो उच्च-TPS श्रृंखलाओं जैसे L2s के लिए चुनौतियां पेश कर सकता है। हम आशावादी हैं कि इस मुद्दे को फ्रेम लेन-देन के शीर्ष पर आगे EIPs या ERCs जैसे EIP-7819 के माध्यम से संबोधित किया जा सकता है, जहां लेन-देन स्थिर रूप से अपने सत्यापन तर्क को इंगित कर सकते हैं ताकि सीक्वेंसर आवश्यकता पड़ने पर नेटिव कोड के साथ सत्यापन को "शॉर्टकट" कर सकें। हम फ्रेम लेन-देन पर बेंचमार्क आयोजित करने के लिए L2s और EF के साथ काम करने का भी इरादा रखते हैं ताकि हम किसी भी प्रदर्शन बाधा की पहचान कर सकें और उसका समाधान कर सकें।

[CL][EL] Frame Transactions ऐड-ऑन

ऐसे कई EIPs हैं जिन्हें Frame txs के विस्तार के रूप में देखा जा सकता है, जो इसकी क्षमताओं पर निर्माण करते हैं।

[EL] EIP-8250: Frame Transactions के लिए Keyed Nonces [A-tier]

• हम इस EIP को अवधारणात्मक रूप से EIP-8141: Frame Transactions का हिस्सा मानते हैं, और मानते हैं कि इसे इसके साथ शिप किया जाना चाहिए।
• यह EIP फ्रेम लेन-देन में 2D नॉन्स पेश करता है। 2D नॉन्स अकाउंट को मेमपूल में समानांतर लेन-देन भेजने में सक्षम बनाते हैं, साथ ही गोपनीयता प्रोटोकॉल को नलिफायर्स को 2D नॉन्स के रूप में संग्रहीत करने की अनुमति देते हैं। यह महत्वपूर्ण है क्योंकि 2D नॉन्स विशेष स्टोरेज हैं जिन्हें पढ़ने और संग्रहीत करने में बहुत कम लागत आती है, इसलिए गोपनीयता लेन-देन आज की तरह नियमित डायनेमिक स्टोरेज में नलिफायर्स को संग्रहीत करने की तुलना में गैस पर महत्वपूर्ण बचत करने में सक्षम होते हैं। Glamsterdam के स्टोरेज रिप्राइसिंग (EIP-8037: स्टेट क्रिएशन गैस कॉस्ट इन्क्रीज़) के संदर्भ में यह विशेष रूप से महत्वपूर्ण है।

[EL] EIP-8272: Frame Transactions के लिए Recent Roots [B-tier]

• यह एक और EIP है जो Frame लेन-देन के साथ गोपनीयता प्रोटोकॉल का उपयोग करने के अनुभव को बढ़ाता है। गोपनीयता प्रोटोकॉल को सत्यापन के दौरान हाल की प्रतिबद्धता जड़ों तक पहुंच की आवश्यकता होती है, जो यदि नियमित स्टोरेज में संग्रहीत की जाती हैं, तो न केवल महंगी हो सकती हैं बल्कि Frames के सार्वजनिक मेमपूल नियमों के साथ भी संघर्ष कर सकती हैं। EIP-8272 एक सिस्टम कॉन्ट्रैक्ट को उजागर करके इन मुद्दों को हल करता है जो इन जड़ों को एक रिंग बफर में संग्रहीत करता है जो स्वचालित रूप से पुरानी जड़ों को शुद्ध करता है।
• हम इसे B-tier में रखते हैं क्योंकि यह EIP एक विशिष्ट उपयोग के मामले के लिए फ्रेम्स में महत्वपूर्ण जटिलता जोड़ता है, और हम अनिश्चित हैं कि समान लक्ष्य प्राप्त करने का कोई अधिक सामान्य/सुरुचिपूर्ण तरीका हो सकता है या नहीं।

[CL] EIP-8369: FOCIL पात्रता के लिए VOPS प्रोफाइल [B-tier]

• यह EIP Frames और VOPS (वैलिडिटी-ओनली पार्शियल स्टेटलेसनेस) के बीच बातचीत को संबोधित करता है, जो मेमपूल नोड्स को लेन-देन को मान्य करने के लिए पर्याप्त स्थिति संग्रहीत करने देने का एक प्रस्ताव है, ताकि स्टेटलेसनेस (zkEVM के कारण) की दुनिया में भी मेमपूल सेंसरशिप-प्रतिरोधी बना रह सके।
• हम इसे B-tier में रखते हैं क्योंकि यह EIP स्टेटलेसनेस के एक विशेष दृष्टिकोण से दृढ़ता से जुड़ा हुआ है जिस पर समुदाय ने अभी तक पूरी तरह से सहमति नहीं बनाई है।

[EL] EIP-7906: स्टेट डिफ ओपकोड के माध्यम से लेन-देन अभिकथन [B-tier]

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

[EL] EOA माइग्रेशन [B-tier]

[EL] EIP-7851: कोड-नियंत्रित EOA प्रतिनिधिमंडल [B-tier] और [EL] EIP-8151: अकाउंट कोड प्रतिबंधित ecRecover [B-tier] को सबसे अच्छी तरह से युग्मित मानकों के रूप में देखा जाता है जो एक साथ एक कहानी प्रस्तुत करते हैं कि कैसे EOA स्मार्ट अकाउंट में संक्रमण कर सकते हैं। इस कहानी में, एक EOA पहले EIP-7702 के माध्यम से एक स्मार्ट अकाउंट को प्रतिनिधि सौंपेगा। फिर, EIP-7851 द्वारा पेश किया गया ओपकोड 7702 प्रतिनिधिमंडल को स्थायी बना देगा, रूट ECDSA कुंजी को अक्षम कर देगा। दूसरी ओर, EIP-8151 ecrecover को निष्क्रियता के बारे में जागरूक करेगा, ताकि पुरानी कुंजी Permit-शैली प्रवाह के माध्यम से धन निकाल न सके।

हम इस जोड़ी को B-tier में रेट करते हैं क्योंकि यह EOA को स्मार्ट अकाउंट में माइग्रेट करने के कई दृष्टिकोणों में से केवल एक है, और इस विशेष दृष्टिकोण को व्यापक समीक्षा या खरीद-फरोख्त नहीं मिली है। विशेष रूप से, हम चिंतित हैं कि यह दृष्टिकोण मल्टी-चेन प्रश्न का उत्तर नहीं देता है: वही EOA L2s पर कैसे माइग्रेट होता है? उपयोगकर्ता को सभी श्रृंखलाओं पर एक ही कार्रवाई करनी होगी, जिसमें वे श्रृंखलाएं भी शामिल हैं जो अभी तक मौजूद नहीं हैं, जो खराब UX का कारण बनेगी। हमें संदेह है कि एक बेहतर दृष्टिकोण हो सकता है जहां L2s EOA माइग्रेशन के लिए L1 का उपयोग "विश्वास की जड़" के रूप में कर सकते हैं, इसलिए हम उन दृष्टिकोणों के लिए A/S-टियर आरक्षित करते हैं जो उपयोगकर्ताओं को सभी EVM श्रृंखलाओं के लिए एक बार माइग्रेट करने में सक्षम बनाएंगे।

[EL] PQ हस्ताक्षर योजना [A-tier]

Hegotá को पोस्ट-क्वांटम हस्ताक्षरों के लिए एक विश्वसनीय मार्ग स्थापित करना चाहिए, लेकिन हमें प्रतिबद्ध होने से पहले सही तंत्र की पुष्टि करनी चाहिए।

• EIP-8355: ML-DSA सत्यापन जोड़ें प्रीकंपाइल्स, Frame Transactions के साथ पोस्ट-क्वांटम अकाउंट सुरक्षा को ठोस बनाता है।
• विकल्प: PQ समर्थन को सक्रिय किए बिना पूर्व-पंजीकृत करें, या एक व्युत्पत्ति प्रारूप परिभाषित करें जो बाद में PQ कुंजियों को समायोजित कर सके।

[EL] EIP-7819: SETDELEGATE निर्देश [A-tier]

• Hegota में नेटिव AA के उतरने की संभावना के साथ, यह महत्वपूर्ण है कि नए स्मार्ट अकाउंट तैनात करने की लागत कम हो, लेकिन EIP-8037 के कारण Glamsterdam में अकाउंट तैनात करना वास्तव में अधिक महंगा हो जाएगा। EIP-7819 के साथ, नए अकाउंट प्रॉक्सी कॉन्ट्रैक्ट के बजाय सरल डेलिगेट पॉइंटर्स का उपयोग करेंगे, जिससे बनाई जाने वाली नई स्थिति की मात्रा में काफी कमी आएगी, जिससे तैनाती की लागत कम होगी।
• हम इस EIP को A-tier में रखते हैं क्योंकि हमारा मानना है कि कम अकाउंट तैनाती लागत AA अपनाने के लिए घर्षण को काफी कम करेगी।

3. प्रदर्शन इंजीनियरिंग: निरंतर L1 स्केलिंग

Glamsterdam ने Ethereum के R&D के दृष्टिकोण में एक बदलाव को चिह्नित किया है, जिसमें प्रोटोकॉल डिज़ाइन और क्लाइंट कार्य दोनों में प्रदर्शन को प्रथम श्रेणी की R&D बाधा के रूप में माना जाता है। विलंबित निष्पादन, संसाधन पुनर्मूल्यांकन और बहुत सारे क्लाइंट ऑप्टिमाइज़ेशन कार्य ने पिछले दो वर्षों में 30M से (कम से कम) 200M तक स्केलिंग की अनुमति दी है। सामान्य तौर पर, प्रदर्शन कार्य हमें विकल्प देता है: हम जो हेडरूम प्राप्त करते हैं, उसका उपयोग स्केलिंग के लिए, स्लॉट को छोटा करने के लिए, नोड आवश्यकताओं को कम करने के लिए, या उपरोक्त सभी के लिए किया जा सकता है।

आज, हम अभी भी निरंतर स्केलिंग को एक आवश्यकता के रूप में देखते हैं। एप्लिकेशन यह तय करते हैं कि कहाँ निर्माण करना है, न केवल वर्तमान कीमतों के आधार पर, बल्कि इस आधार पर भी कि क्या Ethereum समय के साथ पूर्वानुमानित रूप से ब्लॉकस्पेस आपूर्ति का विस्तार कर सकता है। लगातार वृद्धि प्रदान करना अकेले रोडमैप प्रतिबद्धताओं की तुलना में अधिक निश्चितता प्रदान करता है। मेननेट क्षमता अभी भी मांग स्पाइक्स को संभालने में सक्षम होने से काफी दूर है: Ethereum के ग्यारहवें जन्मदिन पर, दैनिक औसत बेस फीस केवल ~0.1 gwei थी, फिर भी एक NFT मिंट ने इसे कुछ समय के लिए 10 gwei से ऊपर धकेल दिया, जिसमें औसत लेन-देन लागत लगभग $1 और 90वां प्रतिशत $5 से अधिक तक पहुंच गया। Glamsterdam के स्केलिंग प्रयास को इसलिए Hegotá में जारी रहना चाहिए।

एक साथ लिए गए, निम्नलिखित EIPs Glamsterdam की स्केलिंग गति को जारी रखते हैं, साथ ही इसके पीछे व्यापक सिद्धांत को मजबूत करते हैं: प्रदर्शन क्लाइंट कार्य और प्रोटोकॉल डिज़ाइन दोनों में प्रथम श्रेणी की चिंता बनी रहनी चाहिए।

[EL] EIP-8131 और EIP-8279 [S-tier]: डेटा रिप्राइसिंग बंडल

**ग्लैम्सटर्डम के बाद, अगली बाध्यकारी बाधा पेलोड प्रसार है, आंशिक रूप से क्योंकि पेलोड बाइट्स के विभिन्न स्रोत गैस लेखांकन में असंगत रूप से, या बिल्कुल भी, प्रतिबिंबित नहीं होते हैं। EIP-8131: यूनिफाइड ट्रांज़ेक्शन कंटेंट फ्लोर मौजूदा ट्रांज़ेक्शन फ्लोर को निष्पादन से पहले ज्ञात सामग्री तक विस्तारित करता है, जबकि EIP-8279: ब्लॉक एक्सेस लिस्ट बाइट फ्लोर निष्पादन के दौरान गतिशील रूप से बनाए गए BAL बाइट्स को कवर करता है।

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

[CL][EL] EIP-8146: ब्लॉक एक्सेस लिस्ट साइडकार्स [A-टियर]

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

अन्य संबंधित EIPs

[EL] CPSB रीकैलिब्रेशन [A-टियर]

• बहुत ही सरल परिवर्तन, हम उन्हें पाइपलाइन में रखने और यदि नियोजित गैस सीमा वृद्धि और स्टेट और निष्पादन गैस के देखे गए उपयोग के आधार पर आवश्यक समझा जाए तो दोनों में से एक को शामिल करने की सलाह देते हैं।
• EIP-8368: नई गैस सीमा के लिए CPSB रीकैलिब्रेशन: EIP-8037 के लिए पूर्व-नियोजित अनुवर्ती, इस तथ्य की भरपाई करते हुए कि प्रति स्टेट बाइट (CSPB) की लागत को गैस सीमा के एक फलन के बजाय स्थिर बना दिया गया है, विशुद्ध रूप से कार्यान्वयन और परीक्षण सरलीकरण के रूप में। विचार यह था कि ब्लॉक-दर-ब्लॉक समायोजन को फोर्क्स पर एकमुश्त समायोजन से बदल दिया जाए, जैसा कि गैस सीमा बढ़ने पर स्टेट ग्रोथ को लक्ष्य पर रखने के लिए आवश्यक हो। चूंकि वर्तमान CPSB को 150M गैस सीमा पर कैलिब्रेट किया गया था, इसलिए संभावना है कि Hegotá में एक समायोजन उचित होगा।
• EIP-8372: सामान्यीकृत स्टेट गैस सीमा: अभी भी EIP-8368 का काफी न्यूनतम सुपरसेट, केवल CPSB की तुलना में अधिक सूक्ष्म समायोजन की अनुमति देता है, या तो स्टेट ग्रोथ लक्ष्य या सापेक्ष मूल्य निर्धारण के कारण नियमित गैस लक्ष्य के कम होने की भरपाई करता है।

[EL] EIP-7862: विलंबित स्टेट रूट [B-टियर]

• स्पेक के लिए सरल, लेकिन क्लाइंट कार्यान्वयन की जटिलता जहां तक हम जानते हैं, बहुत अच्छी तरह से समझ में नहीं आती है। स्टेट रूट कोडबेस में व्यापक है।
• जबकि प्रतिस्पर्धी बिल्डिंग (तेज़ स्टेट रूट गणना) तक पहुंच की बाधा को कम करने में कुछ लाभ है, हमारी राय में EIP का सबसे बड़ा लाभ भविष्य में है (स्टेट रूट गणना को साबित करने के लिए अधिक समय)।
• EL पहले से ही Hegotá का भारी पक्ष है।

[CL] EIP-8341: आंशिक निष्पादन पेलोड प्रतिबद्धताएं [D-टियर]

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

अन्य EIPs

अब हम शेष EIPs को कवर करते हैं, मोटे तौर पर विषयों के अनुसार समूहित। कुछ EIPs पर हम अभी भी अपनी राय बना रहे हैं। हम इस दस्तावेज़ को अपडेट करते रहेंगे क्योंकि हम आने वाले दिनों और हफ्तों में क्लाइंट टीमों और EIP लेखकों से और अधिक सीखते हैं।

चूंकि Hegotá एक EL-झुकाव वाला हार्ड फोर्क होने वाला है, हम अनुशासित रहने और किसी भी EL-पक्ष EIP को मंजूरी देने के लिए एक उच्च बार बनाए रखने का सुझाव देते हैं। हम सोचते हैं कि FOCIL और क्विक स्लॉट्स से परे Hegotá को अपेक्षाकृत CL-लाइट रखना वांछनीय है: एक संकीर्ण दायरा क्लाइंट टीमों को बड़े आर्किटेक्चरल ट्रांज़िशन की तैयारी के लिए जगह देने के लिए बैंडविड्थ को संरक्षित करता है।

[CL] जारी करना

हम जानबूझकर EIP-8363: टेपर्ड इश्यू बर्न को एक टियर नहीं सौंपते हैं। हम सोचते हैं कि जारी करना एक ऐसा निर्णय नहीं है जो कोर डेवलपर्स को अपने दम पर लेना चाहिए, और एक टियर सूची कोर डेवलपर्स के लिए एक स्पष्ट सिफारिश है। अधिकांश EIPs के लिए ACD प्रक्रिया अच्छी तरह से काम करती है क्योंकि निर्णय मुख्य रूप से तकनीकी होते हैं, और समुदाय ने उन्हें प्रभावी ढंग से कोर डेवलपर्स को सौंप दिया है। जारी करना इस मायने में अलग है कि यह एक मौद्रिक नीति प्रश्न है जिस पर समुदाय को स्वयं मोटी सहमति बनानी होती है। कोर डेवलपर्स की राय मायने रखती है, लेकिन उस सार्वजनिक चर्चा के इनपुट के रूप में। EIP-8363 को अन्य EIPs के साथ रैंक करना इसे एक सामान्य ACD निर्णय के रूप में मानेगा, जो हमें नहीं लगता कि ऐसा होना चाहिए।

तकनीकी रूप से हम EIP-8363 के अनुरूप जारी करने में बदलाव में योग्यता देखते हैं। यह जिन समस्याओं का समाधान करता है वे वास्तविक हैं: जैसे-जैसे अधिक ETH स्टेक किया जाता है, स्लैशिंग की विश्वसनीयता कम होती जाती है, उच्च स्टेकिंग अनुपात का मतलब है कि पुरस्कार ज्यादातर कमजोर पड़ने की भरपाई करते हैं, और पैमाने की अर्थव्यवस्थाएं बड़े ऑपरेटरों और एकल स्टेकर्स के बीच की खाई को चौड़ा करती रहती हैं। एक बदलाव में जोखिम भी हैं, प्रभावों की अनिश्चितता से लेकर स्टेक वितरण और मौद्रिक नीति ओसिफिकेशन घड़ी को रीसेट करने तक। Ansgar का थ्रेड दोनों पक्षों को रखता है और हमारी स्थिति को दर्शाता है। हममें से कुछ ने अतीत में जारी करने में बदलाव के लिए तर्क दिया है और उस रास्ते में विश्वास बनाए हुए हैं।

हम अन्य सभी Hegotá स्कोपिंग निर्णयों के बाद जारी करने का निर्णय लेने की सलाह देते हैं। यह सामुदायिक चर्चा को वह समय देता है जिसकी उसे आवश्यकता है और स्कोपिंग प्रक्रिया से ध्यान भटकाने से बचाता है।

[CL] स्टेकिंग सुविधाएं

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

[CL] EIP-8015: डिपॉजिट और eth1data फ़ील्ड हटाएं [A-टियर]

• तकनीकी ऋण की बहुत ही सरल सफाई। EIP-7688: फॉरवर्ड संगत सर्वसम्मति डेटा संरचनाओं के लिए धन्यवाद, असंबंधित फ़ील्ड के Merkle प्रमाण अप्रभावित हैं, इसलिए श्रृंखला उपभोक्ताओं पर कोई प्रभाव नहीं पड़ता है।

[EL][CL] EIP-8237: स्वतंत्र CL/EL सिंक [B-टियर]

• ePBS द्वारा शुरू किए गए बीकन ब्लॉक और पेलोड के पृथक्करण पर निर्माण करता है, ताकि EL और CL को स्वतंत्र रूप से सिंक करने की अनुमति मिल सके। हमें लगता है कि इसमें Ethereum क्लाइंट के एक जटिल हिस्से को सरल बनाने की क्षमता है।

[CL] EIP-8205: निकासी क्रेडेंशियल्स प्री-रजिस्ट्रेशन [D-टियर]

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

[CL] EIP-8148: वैलिडेटर्स के लिए कस्टम स्वीप थ्रेशोल्ड [D-टियर]

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

[CL] EIP-8375: ePBS अनिवार्य बर्न ऑफ़ एक्ज़ीक्यूशन रिवॉर्ड्स [D-टियर]

• हम अस्वीकार करने की सलाह देते हैं। हम सोचते हैं कि यह संभवतः केवल अधिक साइड-चैनलिंग की ओर ले जाएगा। इसके अलावा, MEV बर्न रणनीतियों पर वर्षों की चर्चा किसी भी प्रस्ताव की ओर नहीं ले गई जो व्यापक शोध सहमति तक पहुंची।

[CL] EIP-7716: एंटी-सहसंबंध प्रमाणन दंड [D-टियर]

• हम अस्वीकार करने की सलाह देते हैं। हमें नहीं लगता कि इस बात के पर्याप्त स्पष्ट प्रमाण हैं कि स्टेकिंग प्रोत्साहनों में इतना बड़ा बदलाव उचित है। इसके अलावा, डिकपल्ड कंसेंसस के हिस्से के रूप में स्टेकिंग प्रोत्साहनों पर संभवतः फिर से काम किया जाएगा।

[CL] EIP-8333: चेकपॉइंट को एपॉक बाउंड्री ब्लॉक के साथ संरेखित करें [D-टियर]

• हम अस्वीकार करने की सलाह देते हैं। एक अच्छी सफाई होने के बावजूद, हम सोचते हैं कि इसे बड़े आगामी डिकपल्ड कंसेंसस ट्रांज़िशन के लिए स्थगित करना उचित है।

[CL] EIP-8359: बीकन ब्लॉक रिपोर्टिंग फ़ील्ड [राय बन रही है]

[CL] आगे PQ-तैयारी

ये प्रस्ताव भविष्य के पोस्ट-क्वांटम ट्रांज़िशन से पहले शेष BLS निर्भरता को कम करते हैं।

[CL] EIP-8365: BLS निकासी क्रेडेंशियल सेवानिवृत्ति [A-टियर]

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

[CL] EIP-8367: सेवानिवृत्त BLS वैलिडेटर्स के लिए बैलेंस सनसेट [D-टियर]

• हम अस्वीकार करने की सलाह देते हैं। हम सोचते हैं कि यह संभावना है कि अधिकांश 0x0 वैलिडेटर EIP-8365: BLS निकासी क्रेडेंशियल सेवानिवृत्ति के सक्रिय होने से पहले या बाद में एक क्रेडेंशियल परिवर्तन (BLSToExecutionChange) करेंगे, या तो अपने फंड निकालने के लिए या स्टेकिंग जारी रखने में सक्षम होने के लिए। हमें नहीं लगता कि शेष 0x0 स्टेक से निपटने के लिए एक तंत्र शुरू करने की कोई बड़ी तात्कालिकता है। हम केवल EIP-8365 को शामिल करने और अगले कदमों पर निर्णय लेने से पहले उसके परिणाम को देखने की सलाह देते हैं।

[CL] EIP-8321: हैश-चेन RANDAO [D-टियर]

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

[EL][CL] zkEVM तैयारी

अधिकांश zkEVM तैयारी उपयोगकर्ताओं के एक संकीर्ण सेट के लिए पूर्ण-नोड संचालन को आसान बनाने से परे सीमित अल्पकालिक लाभ प्रदान करती है, जबकि कार्यान्वयन बैंडविड्थ की खपत करती है और संभावित रूप से EVM को अधिक महंगा बनाती है। हमें केवल उन्हीं परिवर्तनों को शामिल करना चाहिए जिनका दीर्घकालिक मूल्य स्पष्ट रूप से उन तत्काल लागतों को उचित ठहराता है।

[CL] EIP-8025: वैकल्पिक निष्पादन प्रमाण [D-टियर]

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

[EL] EIP-7666: आइडेंटिटी प्रीकंपाइल को EVM-ify करें [A-टियर]

• उपयोगी, छोटा बदलाव

[EL] EIP-8200: EVMification [B-टियर]

• EIP-8200 तीन देशी प्रीकंपाइल्स को समतुल्य EVM बाइटकोड से बदल देता है। दो का उपयोग बहुत कम देखा जाता है और सीधे माइग्रेट करने योग्य प्रतीत होते हैं। तीसरे का व्यापक रूप से SNARK सत्यापन में उपयोग किया जाता है, इसलिए हम इसके हटाने का समर्थन करने से पहले एक प्रभाव मूल्यांकन चाहेंगे।
• यदि प्रभाव विश्लेषण प्रभावित उपयोगकर्ताओं के लिए कम माइग्रेशन लागत पाता है, या यदि तीसरे प्रीकंपाइल को दायरे से हटा दिया जाता है, तो हम EIP-8200 को [A-टियर] में ले जाएंगे।

[EL] EIP-7709: स्टोरेज से BLOCKHASH पढ़ें और लागत अपडेट करें [D-टियर]

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

[EL] EIP-8268: ब्लॉक एक्सेस सूचियों में स्टोरेज रूट्स [B-टियर]

• BAL आकारों पर ठोस प्रभाव के विश्लेषण की आवश्यकता हो सकती है, और tx लागतों पर संबंधित प्रभाव (EIP-8279 BAL बाइट्स के लिए शुल्क लेने का प्रस्ताव कर रहा है), क्योंकि प्रत्येक स्पर्श किए गए खाते के लिए BAL प्रविष्टि को एक अतिरिक्त स्टोरेज ट्री रूट मिलता है।

[EL] EVM सुविधाएं

Hegotá को अभी भी कुछ तदर्थ EVM निर्णयों की आवश्यकता होगी। हम मानते हैं कि Hegotá के बाद Ethereum को व्यापक EVM पारिस्थितिकी तंत्र द्वारा आकारित दीर्घकालिक EVM रोडमैप की दिशा में काम करना चाहिए। Ethlabs इसमें योगदान देगा।

[EL] EIP-5920: PAY opcode [A-टियर]

• बहुत सरल, और हम सोचते हैं कि यह EVM के लिए एक अच्छा प्रिमिटिव है
• ठोस उपयोग के मामलों को बेहतर ढंग से समझना महत्वपूर्ण होगा

[EL] EIP-8163: रिज़र्व EXTENSION (0xae) opcode [A-टियर]

• L2s के लिए बहुत उपयोगी, L1 के लिए कोई वास्तविक लागत नहीं (केवल सूचनात्मक)

[EL] कोड पुन: उपयोग / डिडुप्लीकेशन [B-टियर]

• EIP-8058: कॉन्ट्रैक्ट बाइटकोड डिडुप्लीकेशन डिस्काउंट और EIP-8298: SETCODEFROM कोड पुन: उपयोग निर्देश दोनों इस तथ्य का लाभ उठाने का प्रयास करते हैं कि कॉन्ट्रैक्ट कोड क्लाइंट में संबंधित खाते से अलग संग्रहीत किया जाता है, जिसमें कोड हैश उनके बीच पॉइंटर के रूप में होता है। तो समान साझा कोड को डिडुप्लीकेटेड संग्रहीत किया जा सकता है। दोनों EIPs कहीं और मौजूद कोड के हैश के लिए सस्ते में खाता कोडहैश सेट करने का एक तरीका प्रदान करते हैं।
• हम इसे एक आकर्षक सामान्य विचार मानते हैं, लेकिन बाइनरी ट्री के लिए निहितार्थ और आगे की संगतता को समझना महत्वपूर्ण होगा। अभी के लिए दोनों के बीच कोई प्राथमिकता नहीं है।

[EL] मेमोरी मूल्य निर्धारण सुधार [B-टियर]

• हमें यह तय करने की आवश्यकता है कि क्या हम Hegota में मेमोरी सुधार बिल्कुल करना चाहते हैं। यह हमारे लिए स्पष्ट नहीं है कि वर्तमान में हमारे पास इस आकलन के लिए डिज़ाइन स्पेस की पर्याप्त समझ है या नहीं।

EIP-7686: रैखिक EVM मेमोरी सीमाएं

• छोटा बदलाव, बस क्वाड्रिक मेमोरी विस्तार लागत से छुटकारा दिलाता है।

EIP-7923: रैखिक, पेज-आधारित मेमोरी लागत

• गहरा, अधिक सैद्धांतिक रीवर्क, लेकिन अधिक जटिल।

[EL] EIP-8219: चेक्ड अरिथमेटिक Opcodes [B-टियर]

• कुल मिलाकर EVM में सुरक्षित गणित जोड़ना उपयोगी प्रतीत होता है।
• मूल्य निर्धारण की पुष्टि बेंचमार्क के साथ करने की आवश्यकता होगी, यह कितना जटिल है?
• बेंचमार्क और एक प्रभाव विश्लेषण (कितने txs लाभान्वित हो सकते हैं, कितना, कौन से कंपाइलर समर्थन जोड़ेंगे?) के साथ यह A-टियर हो सकता है।

[EL] EIP-8360: TCREATE Opcode [B-टियर]

• EIP लेन-देन-स्कोप्ड अस्थायी अनुबंध बनाने की क्षमता प्रस्तुत करता है। यह सामान्य रूप से एक अच्छा प्रिमिटिव है।
• EIP महत्वपूर्ण जटिलता जोड़ता है। अधिक गहन कार्यान्वयन और परीक्षण जटिलता मूल्यांकन के साथ, यह A-टियर हो सकता है।

[EL] EIP-7645: ORIGIN को SENDER का उपनाम दें [D-टियर]

• हम अस्वीकार करने की सलाह देते हैं: ब्रेकिंग चेंज, ORIGIN का अनुचित उपयोग।

[EL] EIP-8182: प्राइवेट ETH और ERC-20 ट्रांसफर [D-टियर]

• हम अस्वीकार करने की सलाह देते हैं: बहुत बड़ा बदलाव, zk निर्भरता जोड़ता है। यदि कभी शुरू किया जाता है, तो हम सोचते हैं कि यह एक हेडलाइनर होना चाहिए।

[EL] EIP-2488: CALLCODE opcode को हटाएं [राय बन रही है]

[EL] EIP-4758: SELFDESTRUCT को निष्क्रिय करें [राय बन रही है]

[EL] EIP-7979: EVM के लिए कॉल और रिटर्न Opcodes [राय बन रही है]

[EL] EIP-8173: EVM नियंत्रण प्रवाह की नींव [राय बन रही है]

[EL] EIP-8253: शून्य-नॉन्स स्टोरेज खातों का नॉन्स बढ़ाएं [राय बन रही है]

[EL] EIP-8030: P256 एल्गोरिथम समर्थन [राय बन रही है]

[EL] EVM मूल्य निर्धारण

ग्लैम्सटर्डम ने कम कीमत वाले संचालन के लिए कीमतें बढ़ाईं जो समग्र थ्रूपुट को बाधित करते थे। Hegotá के EVM-मूल्य निर्धारण प्रस्ताव ज्यादातर दूसरे पक्ष को संबोधित करते हैं: व्यक्तिगत संचालन के लिए कीमतें कम करना जिनकी वर्तमान लागत उनके उपयोग को सीमित करती है, लेकिन नेटवर्क स्केलेबिलिटी को नहीं। इसलिए ये प्रति-EIP कम प्रभाव वाले होने के लिए अच्छे हैं। हम लक्षित रीप्राइसिंग के लिए तैयार हैं, लेकिन नए मीटरिंग तंत्र पेश करने वाले प्रस्तावों को केवल तभी शामिल किया जाना चाहिए यदि उनका डिज़ाइन सुदृढ़ हो और एक प्रतिबद्ध चैंपियन द्वारा पर्याप्त रूप से डी-रिस्क किया गया हो।

[EL] EIP-8358: खाता परिवर्तनों के लिए नेट गैस मीटरिंग [B-टियर]

• प्रभाव के बारे में आश्वस्त नहीं हैं। 900 नमूना मेननेट ब्लॉकों में, ~400k txs: सभी लेन-देन का 2.07% गैस बचाएगा और ब्लॉक गैस का 1.14% बचाया जाएगा

[EL] EIP-7973: वार्म अकाउंट राइट मीटरिंग [राय बन रही है]

[EL] EIP-7609: TLOAD/TSTORE की आधार लागत घटाएं [राय बन रही है]

[EL] EIP-7971: क्षणिक भंडारण के लिए कठोर सीमाएं [राय बन रही है]

[EL] EIP-3298: रिफंड को हटाना [राय बन रही है]

[EL] EIP-8374: रिवर्ट्स में वार्म एक्सेस सेट को बनाए रखें [राय बन रही है]

[EL] EIP-8115: ब्लॉक के अंत में बैच प्राथमिकता शुल्क [राय बन रही है]

[EL] EIP-8188: खातों और स्लॉट्स के लिए अंतिम-लिखित ब्लॉक [राय बन रही है]

[EL][CL] निष्पादन डेटा और अनुक्रमण

[EL][CL] EIP-7668: ब्लूम फ़िल्टर हटाएं [राय बन रही है]

[EL][CL] EIP-7807: SSZ निष्पादन ब्लॉक [राय बन रही है]

[EL] EIP-8116: संचयी रसीद फ़ील्ड बदलें [राय बन रही है]

[EL] EIP-8304: ट्रस्टलेस लॉग और ट्रांज़ेक्शन इंडेक्स [राय बन रही है]

[EL][CL] नेटवर्किंग

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

[CL] EIP-8371: RowDAS - वितरित ब्लॉब पुनर्निर्माण [A-टियर]

• आम तौर पर ब्लॉब गिनती बढ़ाने की दिशा में एक बाधा के रूप में पूर्ण पुनर्निर्माण और पूर्ण कस्टडी नोड प्रदर्शन को रोकता है।
• मूल्यवान, अंततः वितरित पुनर्निर्माण के किसी न किसी रूप को निश्चित रूप से प्रोटोकॉल में अपना रास्ता बनाना चाहिए। यह हमें वैलिडेटर कस्टडी को हटाने की अनुमति दे सकता है
• जटिलता को बेहतर ढंग से समझने की आवश्यकता है

[CL] EIP-8142: ब्लॉक-इन-ब्लॉब्स (BiB) [D-टियर]

• समय से पहले, कोई मजबूत तात्कालिकता नहीं, काफी अंतिम समय, बहुत सारे प्रश्न शेष (KZG या नहीं? नए गॉसिप विषय या नहीं?)।
• ब्लॉक उत्पादन के क्रिटिकल पथ में KZG को पेश नहीं करना चाहते, विकल्प अस्पष्ट हैं और आगे जटिलता जोड़ेंगे।

[CL] EIP-8243: स्रोत पर बैचिंग अटेस्टेशन [D-टियर]

• यह स्पष्ट नहीं है कि क्या हम समय-से-अंतिमता कम करने के लिए इस पर भरोसा कर सकते हैं, यह लोड पर स्पष्ट सीमा नहीं लगाता है।
• तंत्र का DoS-प्रतिरोध पूरी तरह से स्पष्ट नहीं है।

[EL] EIP-8077: eth/XX - नॉन्स के साथ लेन-देन की घोषणा करें [राय बन रही है]

[EL] EIP-8094: eth/vhash - ब्लॉब-अवेयर मेमपूल [राय बन रही है]

[CL] EIP-8334: बंडल्ड अटेस्टेशन प्रसार [राय बन रही है]

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

कुछ (और) शब्द...

Ethereum अपग्रेड जटिल हैं क्योंकि दांव ऊंचे हैं। दुनिया भर में हजारों नोड एक ही स्लॉट पर नए नियमों पर स्विच करते हैं, और जब वे ऐसा करते हैं तो नेटवर्क एक सेकंड के लिए भी नहीं रुकता है। उस कठोरता ने Ethereum द्वारा शिप किए गए हर अपग्रेड को आगे बढ़ाया है, जिसके परिणामस्वरूप एक विकेन्द्रीकृत नेटवर्क है जिसने 11 वर्षों के 100% अपटाइम का जश्न मनाया है।

Hegotá पर हमारी स्थिति आज तक के हमारे सर्वोत्तम आकलन हैं, लेकिन जब भी चर्चाओं या कार्यान्वयन कार्यों से नए सबूत हमारे दृष्टिकोण को बदलते हैं, तो हम अपनी सोच को अपडेट करेंगे।

इनमें से कुछ EIPs Ethlabs के सदस्यों द्वारा लिखे या आगे बढ़ाए गए थे, अन्य Ethereum में अविश्वसनीय रूप से विशाल, प्रतिभाशाली और सदाशयी शोधकर्ताओं, क्लाइंट डेवलपर्स और व्यक्तिगत योगदानकर्ताओं से आते हैं। हालांकि, सभी को सफल होने के लिए क्लाइंट टीमों, वॉलेट्स, एप्लिकेशन, L2s, इंफ्रा प्रदाताओं, संस्थानों, नोड ऑपरेटरों और अंततः उपयोगकर्ताओं के बीच सहयोग की आवश्यकता होगी। Ethereum दुनिया की साझा परियोजना है, और सार्थक नेटवर्क प्रगति कभी भी एक संगठन का काम नहीं है।

हम इस पारिस्थितिकी तंत्र का एक छोटा सा हिस्सा होने के लिए आभारी हैं, और हम Ethereum को इसकी क्षमता का एहसास कराने में मदद करने के लिए तत्पर हैं।

– Ethlabs