गोएर्ली/प्रेटर के मर्ज की घोषणा

• अंतिम टेस्टनेट प्रूफ़-ऑफ़-स्टेक ट्रांज़िशन के लिए, गोएर्ली का प्रेटर के साथ मर्ज हो जाएगा। मर्ज के बाद गोएर्ली/प्रेटर के संयुक्त नेटवर्क का नाम गोएर्ली होगा।
• बेलाट्रिक्स, जो मर्ज के लिए प्रेटर को तैयार करने वाला अपग्रेड है, ईपोक 112260 में होगा, ऐसा 4 अगस्त, 2022 को 12:24PM UTC पर हो सकता है।
• बेलाट्रिक्स के एक्टिवेट हो जाने के बाद, गोएर्ली/प्रेटर का मर्ज तभी होगा, जब गोएर्ली 10790000 की टोटल डिफ़िकल्टी तक पहुँच जाएगा, ऐसा 6-12 अगस्त, 2022 के बीच हो सकता है।
• मर्ज के बाद, गोएर्ली का सत्यापनकर्ता सेट, अलग-अलग स्टेकर्स के लिए टेस्टनेट सत्यापनकर्ता चलाने हेतु खुला रहेगा। जो स्टेकर, गोएर्ली/प्रेटर सत्यापनकर्ता शुरू करना चाहते हैं, वे प्रेटर लांच पैड पर जाकर ऐसा कर सकते हैं।

बैकग्राउंड

एथेरियम में प्रूफ़-ऑफ़-स्टेक को लाने के वर्षों के प्रयास के बाद, अब हम आखिरी टेस्टिंग स्टेज में प्रवेश कर रहे हैं: जो टेस्टनेट डिप्लॉयमेंट है!

बंद कर दिए गए टेस्टनेट पर कई डेवनेट, शैडो फ़ोर्क और मर्ज के बाद, सेपोलिया का ट्रांज़िशन हाल ही में प्रूफ़-ऑफ़-स्टेक में हुआ था। अब, केवल एक और टेस्टनेट बचा है: गोएर्ली और इससे जुड़ी बीकन चेन, प्रेटर।

यह मर्ज पिछले एथेरियम अपग्रेड से दो तरह से अलग है। पहला, नोड ऑपरेटर्स को अपने सहमति परत (CL) और निष्पादन परत (EL) क्लाइंट दोनों में से किसी एक के बजाय दोनों को एक साथ अपडेट करना होगा। दूसरा, अपग्रेड दो चरणों में एक्टिवेट होगा: पहला चरण बेलाट्रिक्स, बीकन चेन पर ईपोक हाइट पर एक्टिवेट होगा और दूसरा चरण पेरिस, निष्पादन परत पर टोटल डिफ़िकल्टी मान तक पहुँचने पर एक्टिवेट होगा।

जानकारी अपग्रेड करें

समय

मर्ज दो चरणों की प्रक्रिया है। यह प्रक्रिया सहमति परत पर बेलाट्रिक्स नाम के नेटवर्क अपग्रेड के साथ शुरू होती है, जो ईपोक हाइट पर एक्टिवेट होता है। इसके बाद निष्पादन परत का ट्रांज़िशन प्रूफ़-ऑफ़-वर्क से प्रूफ़-ऑफ़-स्टेक में होता है, जो एक निश्चित टोटल डिफ़िकल्टी सीमा पर पहुँचने पर एक्टिवेट होता है, जिसे टर्मिनल टोटल डिफ़िकल्टी (TTD) कहा जाता है।

बेलाट्रिक्स अपग्रेड, प्रेटर बीकन चेन पर ईपोक 112260 पर होगा, ऐसा 4 अगस्त, 2022 को 12:24 PM UTC पर हो सकता है। निष्पादन परत के हिस्से का ट्रांज़िशन, पेरिस, तब एक्टिवेट होगा जब निष्पादन परत गोएर्ली पर 10790000 की टर्मिनल टोटल डिफ़िकल्टी (TTD) तक पहुँच जाएगी, ऐसा 6-12 अगस्त, 2022 के बीच हो सकता है।

जब निष्पादन परत TTD को पार कर लेगी, तब अगला ब्लॉक सिर्फ़ बीकन चेन वैलिडेटर द्वारा ही बनाया जाएगा। हम मर्ज को तभी पूरा हुआ मानते हैं, जब बीकन चेन ने इस ब्लॉक को फ़ाइनलाइज़ कर दिया हो। नेटवर्क की सामान्य स्थितियों में, ऐसा फ़र्स्ट पोस्ट TTD ब्लॉक तक पहुँचने के बाद 2 ईपोक या लगभग 13 मिनट में हो जाना चाहिए!

फ़ाइनलाइज़ किया गया, नया JSON-RPC ब्लॉक टैग, फ़ाइनलाइज़ किया गया सबसे नया ब्लॉक रिटर्न करता है या मर्ज के बाद ऐसा कोई ब्लॉक मौजूद नहीं होने पर त्रुटि दिखाता है। इस टैग का उपयोग एप्लीकेशन में यह चेक करने के लिए किया जा सकता है कि मर्ज पूरा हो गया है या नहीं। इसी तरह, स्मार्ट कॉन्ट्रैक्ट, डिफ़िकल्टी ऑप्टकोड (0x44) की क्वेरी कर सकते हैं, जिसका नाम मर्ज के बाद प्रीवरांडाओ कर दिया गया है, ताकि यह पता लगाया जा सके कि मर्ज हो गया है या नहीं। हमारा सुझाव है कि इंफ़्रास्ट्रक्चर प्रोवाइडर फ़ाइनलाइज़ेशन स्टेटस के अलावा नेटवर्क की पूरी स्टेबिलिटी पर भी नज़र रखें।

क्लाइंट रिलीज़

निम्नलिखित क्लाइंट गोएर्ली और प्रेटर टेस्टनेट में मर्ज का समर्थन जारी करती हैं। मर्ज के दौरान और बाद में नेटवर्क पर बने रहने के लिए नोड ऑपरेटर्स को निष्पादन और सहमति परत क्लाइंट दोनों को चलाना होगा।

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

सहमति परत

निष्पादन परत

अपग्रेड की विशेषताएँ

मर्ज के कॉन्सेंसस के लिए ज़रूरी बदलाव दो जगहों पर बताए गए हैं:

• सहमति परत में आने वाले बदलाव, कॉन्सेंसस-स्पेसिफ़िकेशन रिपॉज़िटरी की बेलाट्रिक्स डायरेक्टरी के तहत होते हैं
• निष्पादन परत में आने वाले बदलाव, एक्ज़ीक्यूशन-स्पेसिफ़िकेशन रिपॉज़िटरी के पेरिस स्पेसिफ़िकेशन के तहत होते हैं

इनके अलावा, दो अन्य स्पेसिफ़िकेशन यह बताते हैं कि सहमति और निष्पादन परत क्लाइंट आपस में किस तरह इंटरैक्ट करेंगे:

• एक्ज़ीक्यूशन-एपिस रिपॉज़िटरी में बताए गए इंजन API का इस्तेमाल, सहमति और निष्पादन परत के बीच बातचीत के लिए किया जाता है
• कॉन्सेंसस-स्पेसिफ़िकेशन रिपॉज़िटरी के सिंक फ़ोल्डर में बताए गए ऑप्टिमिस्टिक सिंक का उपयोग निष्पादन परत क्लाइंट के सिंक होते समय सहमति परत द्वारा ब्लॉक को इम्पोर्ट करने और पहले से लेकर बाद तक की हेड ऑफ़ द चेन का आंशिक दृश्य दिखाने के लिए किया जाता है

अक्सर पूछे जाने वाले प्रश्न

नोड ऑपरेटर के तौर पर, मुझे क्या करना चाहिए?

मर्ज के बाद, एथेरियम का एक फ़ुल नोड, प्रूफ़-ऑफ़-स्टेक बीकन चेन चलाने वाले सहमति परत (CL) क्लाइंट को यूज़र स्टेट मैनेज करने वाले और ट्रांज़ेक्शन से संबंधित कैलकुलेशन चलाने वाले निष्पादन परत क्लाइंट (EL) से जोड़ देगा। ये JSON RPC विधियों के एक नए सेट, इंजन API का उपयोग करके एक प्रमाणित पोर्ट पर बातचीत करते हैं। EL और CL क्लाइंट एक दूसरे को JWT सीक्रेट का उपयोग करके प्रमाणीकृत करते हैं। नोड ऑपरेटर को इन्हें जनरेट करने और कॉन्फ़िगर करने के निर्देश देखने के लिए अपने क्लाइंट के प्रलेखन देखने चाहिए।

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

यहाँ यह ध्यान दिया जाना चाहिए कि हालाँकि ये दोनों ही सहमति परत क्लाइंट रिलीज़ का हिस्सा हैं, लेकिन फिर भी बीकन नोड चलाना, सत्यापनकर्ता क्लाइंट चलाने से अलग होता है। स्टेकर को ये दोनों चलाने चाहिए, लेकिन नोड ऑपरेटर्स को केवल पहले वाले की ही ज़रूरत होती है। इस पोस्ट में दोनों तत्वों के बीच के अंतर को और अधिक विस्तार से समझाया गया है।

यह भी ध्यान रखें कि हर लेयर, पियर्स का एक अलग सेट बनाए रखेगी और अपने API दिखाएगी। इस प्रकार बीकन और JSON RPC API दोनों सही ढंग से काम करना जारी रखेंगे।

स्टेकर के तौर पर, मुझे क्या करना होगा?

गोएर्ली/प्रेटर मर्ज आपके लिए यह सुनिश्चित करने का आखिरी मौका है कि मेननेट ट्रांजिशन से पहले आपके सत्यापनकर्ता सही तरीके से कॉन्फ़िगर हो गए हैं। मेननेट पर किसी भी अप्रत्याशित समस्या से बचने के लिए अब ट्रांज़िशन चलाने की पूरी अनुशंसा की जाती है।

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

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

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

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

प्रेटर स्टेकिंग लांच पैड में एक मर्ज रेडीनेस चेकलिस्ट है, जिसका उपयोग स्टेकर यह सुनिश्चित करने के लिए कर सकते हैं कि वे प्रक्रिया के प्रत्येक चरण से गुजर चुके हैं। EthStaker टीम 29 जुलाई को एक मर्ज वैलिडेटर प्रिपरेशन वर्कशॉप भी आयोजित कर रही है।

टर्मिनल टोटल डिफ़िकल्टी की तारीख का अनुमान सटीक क्यों नहीं है?

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

एप्लिकेशन या टूलिंग डेवलपर के तौर पर, मुझे क्या करना चाहिए?

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

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

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

एथेरियम यूज़र या ईथर धारक के तौर पर, क्या मुझे कुछ करना होगा?

नहीं। एथेरियम मेननेट इस टेस्टनेट से प्रभावित नहीं हुआ है। मेननेट के ट्रांज़िशन से पहले इस ब्लॉग पर आगे की कुछ घोषणाएँ की जाएँगी।

माईनर के तौर पर, क्या मुझे कुछ करना होगा?

नहीं। अगर आप एथेरियम मेननेट या रोपस्टेन पर माईनिंग कर रहे हैं, तो आपको पता होना चाहिए कि मर्ज के बाद प्रत्येक नेटवर्क पूरी तरह से प्रूफ़-ऑफ़-स्टेक के अंतर्गत काम करेगा। तब नेटवर्क पर माईनिंग करना संभव नहीं रह जाएगा।

सत्यापनकर्ता के तौर पर, क्या मैं अपनी स्टेक वापस ले सकता हूँ?

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

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

मेरे और भी प्रश्न हैं, मैं उन्हें कहाँ पूछ सकता/सकती हूं?

EthStaker कम्युनिटी ने स्टेकर्स और नोड ऑपरेटर्स के सवालों के जवाब देने के लिए एक डिस्कॉर्ड चैनल बनाया है। आप यहाँ से उनके डिस्कॉर्ड में शामिल हो सकते हैं और फिर सहायता पाने के लिए #goerli-prater चैनल का उपयोग कर सकते हैं। जैसा कि ऊपर बताया गया है, EthStaker 29 जुलाई को एक मर्ज वैलिडेटर प्रिपेरेशन वर्कशॉप भी आयोजित करेंगे।

इसके अलावा 12 जून, 14:00 UTC पर एक मर्ज कम्युनिटी कॉल शेड्यूल किया गया है। इसमें नोड ऑपरेटर्स, स्टैकर्स, इन्फ़्रास्ट्रक्चर और टूलिंग प्रोवाइडर्स और कम्युनिटी के सदस्यों के सवालों के जवाब देने के लिए क्लाइंट के डेवलपर और रिसर्चर उपलब्ध रहेंगे। ध्यान दें कि यह कम्युनिटी कॉल गोएर्ली/प्रेटर मर्ज के बाद होने की उम्मीद है।

मर्ज कब होगा?

इस पोस्ट के प्रकाशन के समय, एथेरियम मेननेट के प्रूफ़-ऑफ़-स्टेक ट्रांज़िशन की तारीख तय नहीं की गई है। इससे अलग कोई भी दावा करने वाला कोई भी स्रोत, स्कैम हो सकता है। अपडेट इस ब्लॉग पर पोस्ट किए जाएँगे। कृपया सुरक्षित रहें!

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

हालाँकि, अगर इस प्रक्रिया में कहीं पर भी कोई समस्या आती है या टेस्ट का कवरेज अपर्याप्त माना जाता है, तो डिप्लॉयमेंट प्रोसेस को जारी रखने से पहले इन समस्याओं का समाधान किया जाएगा।

इसके बाद ही मर्ज की सही तारीख का अनुमान लगाना संभव हो पाएगा।

दूसरे शब्दों में, 🔜।