इथेरियम कोर शासन की व्याख्या

ETHBoulder में एथेरियम फाउंडेशन के निक्सो रोकिश (Nixo Rokish) द्वारा एक प्रस्तुति, जिसमें इथेरियम के कोर प्रोटोकॉल शासन, हार्ड फ़ोर्क का समन्वय कैसे किया जाता है, इथेरियम को कौन नियंत्रित करता है इसके बारे में आम गलतफहमियां, और शासन प्रक्रिया में कैसे भाग लें, इसके बारे में बताया गया है।

यह ट्रांसक्रिप्ट EthBoulder द्वारा प्रकाशित मूल वीडियो ट्रांसक्रिप्ट (opens in a new tab) की एक सुलभ प्रति है। इसे पढ़ने में आसानी के लिए थोड़ा संपादित किया गया है।

परिचय (0:12)

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

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

तो, कोर प्रोटोकॉल शासन क्या है? मैं एक नोड चलाता हूँ। तो इसका मतलब यह है कि मेरे पास एक हार्डवेयर है, मेरे घर पर एक कंप्यूटर है जहाँ मैं इथेरियम सॉफ़्टवेयर चलाता हूँ। जब मैंने यह इथेरियम सॉफ़्टवेयर सेट किया, तो मुझे उन क्लाइंट्स को चुनना था जो उस सॉफ़्टवेयर को चलाने वाले थे। इथेरियम इस मायने में थोड़ा अनूठा है कि इसमें क्लाइंट विविधता के लिए कई क्लाइंट हैं। इसका उद्देश्य यह है कि यदि एक क्लाइंट डाउन हो जाता है, यदि किसी क्लाइंट में कोई बग है, तो पूरा नेटवर्क डाउन नहीं होता है। अन्य ब्लॉकचेन हैं जिनके अन्य क्लाइंट हैं। हालाँकि, इथेरियम एकमात्र ऐसा है जिसे इस तरह से सेट किया गया है जो वास्तव में हमें बग से बचाता है। तो, यदि आप Solana जैसे नेटवर्क पर जाते हैं, तो Solana का एक और क्लाइंट है, मुझे लगता है कि इसे GTO कहा जाता है, लेकिन इसे केवल 20–21% ही अपनाया गया है। इसलिए, यदि बहुसंख्यक क्लाइंट डाउन हो जाता है, तो चेन डाउन हो जाती है। और हमने अन्य नेटवर्क को डाउन होते देखा है। और यही कारण है कि इथेरियम सबसे लचीला, सुरक्षित ब्लॉकचेन है।

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

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

तो पिछले साल एक बहुत ही विवादास्पद बात हुई थी। आपने इसके बारे में सुना होगा। इसे EOF कहा जाता था। वह EVM Object Format है। यह सुविधाओं का एक सेट था जिसे फुसाका हार्ड फ़ोर्क — पेक्ट्रा, फुसाका, मुझे लगता है कि दोनों — में जाने के लिए निर्धारित किया गया था, लेकिन यह विभाजित हो गया। और कई कारणों में से एक कारण जिसकी वजह से इसे उस फ़ोर्क से बाहर कर दिया गया, वह यह था कि विटालिक (Vitalik) ने इथेरियम द्वारा RISC-V को अपनाने की क्षमता के बारे में एक पोस्ट किया था। बहुत से लोग जो इसे पढ़ रहे थे, उन्होंने इसे देखा और कहा, ठीक है, अगर हम RISC-V को अपनाते हैं तो EOF में हम जिन सुविधाओं को देख रहे हैं वे RISC-V के साथ मूल रूप से आती हैं। तो हम प्रोटोकॉल में इस जटिलता को क्यों जोड़ेंगे? हम इन सभी क्लाइंट डेवलपर संसाधनों को इस चीज़ की ओर क्यों लगाएंगे? यदि हम अंततः RISC-V की ओर बढ़ते हैं तो यह एक व्यर्थ बात होगी।

तो यह EOF के लिए आखिरी तिनका (straw that broke the camel's back) था और अंततः इसे फ़ोर्क से बाहर कर दिया गया। एक और बात जिस पर उन्हें विचार करना है वह यह है कि इसे छह अलग-अलग भाषाओं में लिखा जाना चाहिए और कड़ाई से परीक्षण किया जाना चाहिए क्योंकि ये क्लाइंट छह अलग-अलग भाषाओं में लिखे गए हैं। तो यह उनके काम करने के लिए एक बहुत बड़ा परीक्षण मैट्रिक्स है। और इस वजह से हर छोटे डिज़ाइन विकल्प पर बहस होती है और असहमति को सुलझाने के लिए कोई अधिकार नहीं होता है। तो जो सवाल उठता है वह यह है कि कौन फैसला करता है — जो कि शासन का मूल है।

गलतफहमियां (5:23)

तो यह हमें गलतफहमियों की ओर ले जाता है और हम इनमें से कुछ को संबोधित करेंगे। एक यह है कि विटालिक तय करता है कि इथेरियम प्रोटोकॉल में क्या जाता है। इसका एक विस्तार यह है कि EF सब कुछ नियंत्रित करता है। और तीसरा यह है कि यह सब गुप्त सौदे (backroom deals) हैं — अंदरूनी सूत्र, OG (पुराने दिग्गज) ये निर्णय ले रहे हैं।

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

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

और 2023 के अंत में, 2024 की शुरुआत में, यह कथा चल रही थी कि Solana आ रहा है। यह इथेरियम को पछाड़ने वाला था। और इसलिए लोग सोच रहे थे कि इथेरियम गति बढ़ाने के लिए क्या कर सकता है। और उनमें से एक बात यह थी कि चलो इस गैस मीट्रिक को बढ़ाते हैं। और उस समय EF और क्लाइंट डेव्स कुछ इस तरह थे, "हमारे पास चिंता करने के लिए अन्य चीजें हैं। वैसे धन्यवाद।" लेकिन ये दो लोग, एरिक कॉनर (Eric Connor) और मारियानो कोंटी (Mariano Conti), आए और बोले, "नहीं, हम गैस सीमा बढ़ा रहे हैं।" गैस सीमा एक सत्यापक-नियंत्रित पैरामीटर है। और इसलिए वे बस सत्यापकों, पेशेवर ऑपरेटरों से बात करना शुरू कर सकते थे, और कह सकते थे, "अरे, अपनी गैस सीमा बढ़ाएं।"

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

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

यह सब गुप्त सौदे, अंदरूनी सूत्र, OG हैं — मैं थोड़ा और समझता हूँ कि यह एक गलतफहमी क्यों है क्योंकि आप मूल रूप से इन शासन कॉलों में आते हैं, इन शासन कॉलों में सौ लोग होते हैं। ऐसा लगता है कि वे सभी जो हो रहा है उसके साथ बहुत सहज हैं। आप खो गए हैं। आपको कोई अंदाज़ा नहीं है कि ये निर्णय कैसे लिए जाते हैं। आप सोचते हैं, "क्या अभी मेरी बात करने की बारी है?" और ऐसा लगता है कि लोग इन निर्णयों को लेने के लिए उन्हीं 10 लोगों की बात सुन रहे हैं।

योग्यता-तंत्र और भागीदारी के आँकड़े (10:18)

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

तो मैं केवल एक साल से थोड़ा अधिक समय पहले EF में शामिल हुआ था। मैंने ये आँकड़े लिए। वे केवल मार्च 2025 तक वापस जाते हैं। तो एक साल से भी कम। औसत ऑल कोर डेव (All Core Dev) उपस्थित लोग — जो कि शासन कॉल हैं — 98 हैं। तो औसतन इन कॉलों में 98 लोग होते हैं। तब से एक कॉल में अधिकतम उपस्थित लोग 153 थे। मुझे लगता है कि वह दिन था जब हम पेक्ट्रा मेननेट की तारीख तय कर रहे थे। और केवल पिछले वर्ष में कुल अद्वितीय उपस्थित लोग 567 हैं। मुझे वास्तव में वह मीट्रिक पसंद है क्योंकि यह दर्शाता है कि हर बार इन कॉलों में जाने वाले वही 100 लोग नहीं होते हैं। ये ऐप डेवलपर्स, शोधकर्ता, कोई किसी ऐसी सुविधा के बारे में सुनता है जिस पर चर्चा की जा रही है, वे इसके विरोध या इसके समर्थन में अपनी आवाज़ उठाने के लिए आते हैं और फिर वे किसी अन्य कॉल में नहीं आते हैं।

शासन प्रक्रिया कैसे काम करती है (11:52)

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

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

तो कई डेवनेट के बाद — दो हो सकते हैं, 10 हो सकते हैं — सभी क्लाइंट किसी बिंदु पर यह तय करते हैं कि यह स्थिर है। हम अभी जो हो रहा है उस पर भरोसा करते हैं। हम एक अच्छी जगह पर हैं। आइए इसे इथेरियम मेननेट पर लाने के बारे में सोचना शुरू करें। वे क्लाइंट रिलीज़ में कटौती करते हैं और फिर 30 दिन की अवधि होती है जहाँ EF सुरक्षा टीम एक बग बाउंटी निकालती है। वे सुरक्षा ऑडिट का अनुबंध करते हैं। और फिर उस 30 दिन की अवधि के अंत में हम टेस्टनेट पर फ़ोर्क लॉन्च करते हैं। ये वे टेस्टनेट हैं जिनके बारे में आपने सुना होगा — जैसे Holesky। ये वे जगहें हैं जहाँ ऐप डेवलपर्स फ़ोर्क के लाइव होने से पहले अपनी चीज़ों का परीक्षण कर सकते हैं। और ये आम तौर पर यह सुनिश्चित करने के लिए कम से कम 14 दिन के होते हैं कि सब कुछ ठीक है। हम किसी बड़ी समस्या की उम्मीद नहीं करते हैं क्योंकि यह पहले सुविधा-विशिष्ट डेवनेट और सामान्यीकृत डेवनेट से गुज़र चुका है, लेकिन ऐतिहासिक रूप से इसने इनमें से कुछ टेस्टनेट को तोड़ दिया है। और इसलिए यह इन सभी बग्स को खोजने और खत्म करने का एक तरह का अंतिम अवसर है।

और फिर एक बार जब अनुमति-रहित टेस्टनेट स्थिर हो जाता है, तो मेननेट की तारीख चुनी जाती है। इसके बाद, 30 दिन का बफर होता है। यह 30 दिन का बफर इसलिए मौजूद है क्योंकि L2s और प्रोटोकॉल ने फ़ोर्क के लिए तैयार होने के लिए इसका अनुरोध किया है। तो यह कम से कम 30 दिन का है और फिर फ़ोर्क होता है।

कॉल संरचना और समन्वय (15:01)

इस पूरे समय के दौरान कुछ मुख्य कॉल श्रृंखलाएं हो रही हैं। ये सभी सार्वजनिक कॉल हैं जिन्हें YouTube पर लाइव-स्ट्रीम किया जाता है। प्रमुख ACDE और ACDC हैं। E निष्पादन परत के लिए है — वह लेनदेन, स्मार्ट अनुबंध परिनियोजन, मेमपूल प्रबंधन जैसी चीजें हैं। ACDC सर्वसम्मति परत है — तो वह सत्यापक प्रबंधन, कटौती जैसी सत्यापक चीजें हैं। और वे गुरुवार को बारी-बारी से होते हैं। तो हर गुरुवार को एक ACD होता है और उनमें से एक ACDE होता है और फिर अगला ACDC होता है, जो इसी तरह जारी रहता है।

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

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

एक विकसित होती प्रक्रिया (15:29)

तो एक बात जो मैं सभी को बताना चाहता हूँ वह यह है कि यह प्रक्रिया स्थिर के अलावा कुछ भी है। यह प्रक्रिया जिसका मैंने अभी आपके सामने वर्णन किया है, एक वर्ष से भी कम समय से लाइव है। इथेरियम 10 वर्षों से लाइव है। लेकिन यह लगातार बदलता रहता है और इसके लगातार बदलने का कारण यह है कि कोई भी प्रभारी नहीं है। और यह प्रक्रिया संचालित करने के सबसे कुशल तरीके का पता लगाने के लिए एक तरह से विकसित होती है। और जैसे मैं कुशल कहता हूँ, लेकिन इथेरियम शासन की जो प्रतिष्ठा है वह वास्तव में स्थिर होने, चीजों को पूरा करने में कठिन, भ्रमित करने वाली है — और ऐसा इसलिए है क्योंकि जब आपके पास निर्णय लेने वाले 100 से 500 लोग होते हैं, तो मैं ईमानदारी से प्रभावित हूँ कि यह बिल्कुल काम करता है।

तो टिम ने अप्रैल 2025 में "Reconfiguring All Core Devs" नामक एक पोस्ट किया जो अंततः इस बात का प्रस्ताव बन गया कि चीजें अभी कैसे काम करती हैं। और इसका कारण यह है कि इससे पहले हमारे पास इस बारे में एक तरह की एकजुट कथा थी कि हमें इथेरियम में किस पर ध्यान केंद्रित करना चाहिए। द मर्ज था जो एक बहुत बड़ा उपक्रम था। हर कोई बहुत उत्साहित था। ज्यादातर लोग बहुत उत्साहित थे। खनिक नहीं थे। और फिर द मर्ज के बाद, आपके पास निकासी थी। इसलिए, हम नहीं चाहते थे कि लोगों का ETH एक अनुबंध में लॉक हो जाए और यह FUD (डर, अनिश्चितता और संदेह) ऐसा हो कि वे इससे कभी भी ETH बाहर नहीं निकाल पाएंगे। इसलिए, हमें इसे जल्द से जल्द शिप करना था। और फिर प्रोटो-डैंकशार्डिंग था और फिर पेक्ट्रा आया और पेक्ट्रा विभिन्न असंबंधित EIPs का एक तरह का मिश्रण था और वास्तव में इसकी कोई एकजुट कथा नहीं थी। और यह इतना बड़ा हो गया क्योंकि लोग सामंजस्य की कमी के कारण बस चीजों को धकेल रहे थे कि इसे दो अलग-अलग फ़ोर्क में विभाजित करना पड़ा क्योंकि परीक्षण टीमें कुछ इस तरह थीं, "दायरा बहुत बड़ा है। हम इस सब का परीक्षण नहीं कर सकते।"

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

तो शीर्ष पर दूसरा स्क्रीनशॉट टिम का है जो इन EIPs को शामिल करने के चरणों के लिए परिभाषाएं प्रस्तावित कर रहा है। और मैं इसके साथ जो बात कहना चाहता हूँ वह यह है कि कभी-कभी आप लोगों को यह कहते हुए सुनते हैं कि यह प्रक्रिया बहुत नौकरशाही है। लेकिन वास्तव में जो हो रहा है वह यह है कि लोग इस शासन प्रक्रिया में आते हैं और वे कहते हैं, "मैं एक EIP कैसे शामिल करूँ?" और जो लोग 10 साल से वहां हैं वे कहते हैं, "आप बस एक तरह से कर देते हैं।" और लोग कहते हैं, "यह भयानक है।" और इसलिए ये चीजें जो करती हैं वह यह है कि वे वर्णन करती हैं कि बाहरी लोगों के लिए इस प्रक्रिया में भाग लेना आसान बनाने के लिए क्या हो रहा है, क्योंकि यदि आप बस यहाँ आ रहे हैं और आप कह रहे हैं, "मेरे पास एक EIP है, मुझे इथेरियम शासन की परवाह नहीं है, मैं बस इस एक EIP को शामिल करना चाहता हूँ" — आप एक रूब्रिक चाहते हैं, आप एक चेकलिस्ट चाहते हैं, आप इस EIP को शामिल करने के तरीके पर एक बहुत स्पष्ट चरण-दर-चरण चाहते हैं। इसलिए, इनमें से अधिकांश चीजें यह वर्णन करने के बारे में अधिक हैं कि प्रक्रिया कैसे काम करती है, बजाय इसके कि नौकरशाही नियम बनाए जाएं जिनका लोगों को पालन करना पड़े ताकि EIPs को शामिल करना मुश्किल हो जाए।

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

तुलनीय शासन प्रणालियाँ (20:21)

तो बस जल्दी से मैं शासन की सबसे समान विकेंद्रीकृत प्रणालियों पर चर्चा करना चाहता था जो मैं इथेरियम शासन के लिए देख सकता हूँ। और मैं यहाँ जो बात कहने की कोशिश कर रहा हूँ वह यह है कि यह टिकाऊ है — भले ही यह आश्चर्यजनक है कि 100 से 500 लोग निर्णय ले सकते हैं, यह वास्तविक दुनिया में टिकाऊ है। हम इसके काम करने के उदाहरण देखते हैं।

IETF इंटरनेट इंजीनियरिंग टास्क फोर्स है। यह स्वयंसेवकों द्वारा संचालित मानक निकाय है जिसने TCP/IP, HTTP बनाया। यह वह संगठन है जो इस तथ्य के लिए सबसे अधिक जिम्मेदार है कि आज हमारे पास मुफ्त इंटरनेट है। लिनक्स कर्नेल — यह लिनक्स ऑपरेटिंग सिस्टम का कोर है। तो वह ओपन-सोर्स सॉफ़्टवेयर है जो इंटरनेट सर्वर, एंड्रॉइड फोन, सुपर कंप्यूटर को शक्ति प्रदान करता है। वहाँ अंतर यह है कि उनके पास लिनुस टोरवाल्ड्स के साथ एक तरह का परोपकारी तानाशाह मॉडल है। लेकिन फिर भी उनके पास 17,000 से अधिक योगदानकर्ता हैं, जो आश्चर्यजनक है।

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

बिल्डर्स परवाह क्यों करते हैं (22:38)

तो बिल्डर्स शासन की परवाह क्यों करते हैं? क्योंकि बिल्डर्स सचमुच वे हैं जिनके लिए इथेरियम बनाया गया है। इथेरियम कोर डेव्स के लिए नहीं बनाया गया है। यह सत्यापकों के लिए नहीं बनाया गया है। कभी-कभी ये लोग इस बारे में भ्रमित हो जाते हैं। इथेरियम कोर डेव्स और सत्यापक इथेरियम की सेवा करते हैं जो बिल्डर्स और उपयोगकर्ताओं की सेवा करता है।

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

कैसे भाग लें (24:40)

तो आप कैसे भाग लेते हैं या अपनी सुविधा को कैसे शामिल करते हैं? यह एक तरह की सामान्य सलाह है, लेकिन मुझे लगता है कि यह सबसे अच्छी है। अपने दर्द बिंदुओं के बारे में मुखर रहें। ट्विटर पर जाएं, ब्लॉग पोस्ट लिखें, अपने दर्द बिंदुओं के समाधान की पहचान करें। उन चीजों पर अनुमान लगाएं जो आपकी मदद कर सकती हैं। यदि आप अन्य लोगों को पाते हैं जिनके पास समान दर्द बिंदु हैं, तो आम तौर पर आप एक EIP पा सकते हैं जो उस दर्द बिंदु को संबोधित करने के लिए मौजूद है या किसी को एक EIP लिखने में आपकी मदद करने के लिए कह सकते हैं जो ऐसा करता है।

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

मैं बस आपके लिए कुछ संसाधन छोड़ दूँगा। Forkcast.org — वहाँ आप जा सकते हैं और देख सकते हैं कि फ़ोर्क में क्या जा रहा है, यह कुछ हितधारकों को कैसे प्रभावित करता है। तो, यदि आप एक ऐप डेवलपर हैं, तो ऐप डेवलपर्स के लिए एक अनुभाग है। यदि आप एक वॉलेट डेवलपर हैं, एक सर्वसम्मति परत क्लाइंट डेवलपर हैं, तो इस पर अनुभाग हैं कि वे सभी आपको कैसे प्रभावित करते हैं। YouTube वह जगह है जहाँ वे सभी कॉल वीडियो अपलोड किए जाते हैं। वे forkcast.org/calls पेज में भी एम्बेडेड हैं जहाँ सारांश, स्पीकर एट्रिब्यूशन हैं, इसलिए उन कॉलों को नेविगेट करना आसान है। EIPs निर्देशिका, Ethereum Magicians फ़ोरम जहाँ आप संभावित समाधानों या EIPs के बारे में अन्य लोगों से बात कर सकते हैं जिन्हें आप लिखना चाहते हैं। और बहुत जल्द मेरी टीम के पास एक प्रोटोकॉल सपोर्ट साइट होगी। यह बहुत बढ़िया दिखती है। यह साझा करने के लिए तैयार नहीं है। मेरा ईमेल भी वहाँ है — nixo@ethereum.org (opens email client)। बस इतना ही।