इथेरियम कोअर प्रशासनाचे स्पष्टीकरण

ETHBoulder येथे इथेरियम फाउंडेशनच्या निक्सो रोकिश (Nixo Rokish) यांचे सादरीकरण, ज्यामध्ये इथेरियमचे कोअर प्रोटोकॉल प्रशासन, हार्ड फोर्क कसे समन्वित केले जातात, इथेरियमवर कोणाचे नियंत्रण आहे याबद्दलचे सामान्य गैरसमज आणि प्रशासन प्रक्रियेत कसे सहभागी व्हावे हे स्पष्ट केले आहे.

ही ट्रान्सक्रिप्ट EthBoulder द्वारे प्रकाशित केलेल्या मूळ व्हिडिओ ट्रान्सक्रिप्टची (opens in a new tab) एक सुलभ प्रत आहे. वाचनीयतेसाठी यात थोडे संपादन केले आहे.

परिचय (0:12)

उपस्थित राहिलेल्या माझ्या सर्व सहा मित्रांचे आभार. ठीक आहे. मी आज तुमच्याशी इथेरियम कोअर प्रशासनाबद्दल बोलत आहे. माझे नाव निक्सो आहे. मी EF (Ethereum Foundation) मध्ये प्रोटोकॉल सपोर्ट टीमचे नेतृत्व करतो. आमच्या सर्व जबाबदाऱ्यांपैकी एक जबाबदारी म्हणजे या गोष्टींमध्ये सहभागी होणाऱ्या इतर सर्वांसाठी प्रशासन प्रक्रिया अधिक स्पष्ट आणि समजण्यास सोपी बनवणे, कारण इथेरियममध्ये केवळ त्याच्या कोअर डेव्हलपर्सपेक्षा बरेच काही समाविष्ट आहे.

तर या चर्चेची रूपरेषा येथे आहे. आपण कोअर प्रशासन म्हणजे काय यावर बोलणार आहोत. आपण गैरसमज आणि सध्या इथेरियम प्रशासन कसे कार्य करते यावर बोलणार आहोत. आपण इतर विकेंद्रित (decentralized) प्रशासन प्रणालींशी याची तुलना कशी होते, बिल्डर्सना याची काळजी का असावी आणि सहभागासाठी कृती करण्यायोग्य मार्ग यावर चर्चा करणार आहोत.

तर, कोअर प्रोटोकॉल प्रशासन म्हणजे काय? मी एक नोड चालवतो. याचा अर्थ असा की माझ्याकडे एक हार्डवेअर आहे, माझ्या घरी एक संगणक आहे जिथे मी इथेरियम सॉफ्टवेअर चालवतो. जेव्हा मी हे इथेरियम सॉफ्टवेअर सेट केले, तेव्हा मला ते सॉफ्टवेअर चालवणारे क्लायंट्स निवडावे लागले. इथेरियम एक प्रकारे अद्वितीय आहे कारण क्लायंट विविधता (client diversity) राखण्यासाठी यात अनेक क्लायंट्स आहेत. याचा उद्देश असा आहे की जर एखादा क्लायंट बंद पडला, किंवा एखाद्या क्लायंटमध्ये बग असेल, तर संपूर्ण नेटवर्क बंद पडत नाही. इतर ब्लॉकचेन आहेत ज्यांचे इतर क्लायंट्स आहेत. तथापि, इथेरियम हे एकमेव असे आहे जे अशा प्रकारे सेट केले आहे जे प्रत्यक्षात आपल्याला बग्सपासून वाचवते. त्यामुळे, जर तुम्ही Solana सारख्या नेटवर्ककडे पाहिल्यास, Solana कडे दुसरा क्लायंट आहे, मला वाटते त्याला GTO म्हणतात, परंतु त्याचा वापर केवळ 20-21% आहे. त्यामुळे, जर बहुसंख्य क्लायंट बंद पडला, तर चेन बंद पडते. आणि आपण इतर नेटवर्क्स बंद पडताना पाहिले आहेत. आणि म्हणूनच इथेरियम ही सर्वात लवचिक, सुरक्षित ब्लॉकचेन आहे.

तर प्रश्न असा निर्माण होतो की जेव्हा तुम्हाला इतक्या वेगवेगळ्या क्लायंट्सशी समन्वय साधावा लागतो तेव्हा तुम्ही इथेरियममध्ये बदल कसे आणता. प्रथम आपण हार्ड फोर्क आणि सॉफ्ट फोर्क यातील फरक समजून घेऊ. सॉफ्ट फोर्कसाठी हार्ड फोर्कसारख्या समन्वयाची आवश्यकता नसते. इथेरियम प्रामुख्याने हार्ड फोर्कसह कार्य करते. तर हार्ड फोर्क म्हणजे काय, तर मुळात सर्व क्लायंट्स इथेरियमची नवीन आवृत्ती तयार करतात आणि काही पूर्व-निर्धारित वेळी इथेरियमची ही नवीन आवृत्ती लाँच करण्याचे ठरवतात. ते अजूनही इथेरियमच असते परंतु त्यात नवीन वैशिष्ट्ये असतात. त्यात भिन्न वैशिष्ट्ये असतात. आणि माझ्यासारख्या घरी नोड चालवणाऱ्या सर्व नोड ऑपरेटर्सना किंवा व्यावसायिक ऑपरेटर्सना इथेरियमच्या त्या नवीन आवृत्तीचा स्वीकार करावा लागतो. त्यांना नवीन सॉफ्टवेअर समाविष्ट करण्यासाठी त्यांचा नोड अपग्रेड किंवा अपडेट करणे आवश्यक असते.

तर त्या हार्ड फोर्कमध्ये कोणती वैशिष्ट्ये समाविष्ट करायची हे ते कसे ठरवतात? त्यांना त्यांचा वेळ आणि संसाधने वाटप करण्यासाठी प्राधान्यक्रमांवर एकमत (consensus) करावे लागते कारण त्यांच्याकडे वाटप करण्यासाठी मर्यादित वेळ आणि संसाधने असतात. ते सुरक्षा त्रुटी किंवा सुरक्षा पॅचेस, UX सारख्या गोष्टींना प्राधान्य देतात — जर दुसरी एखादी ब्लॉकचेन आपल्याशी स्पर्धा करत असेल, तर आपल्याला त्या इतर ब्लॉकचेनशी स्पर्धात्मक बनण्याची आवश्यकता असते. त्यामुळे ते ज्या गोष्टींकडे लक्ष देतात त्यापैकी एक म्हणजे समाविष्ट होणारे कोणतेही वैशिष्ट्य संभाव्य आगामी रोडमॅप आयटम्सशी फॉरवर्ड कंपॅटिबल असले पाहिजे.

तर गेल्या वर्षी एक खरोखरच वादग्रस्त गोष्ट घडली. तुम्ही त्याबद्दल ऐकले असेल. त्याला EOF म्हटले गेले. ते म्हणजे EVM Object Format. तो वैशिष्ट्यांचा एक संच होता जो फुसाका हार्ड फोर्कमध्ये — पेक्ट्रा, फुसाका, मला वाटते दोन्हीमध्ये — समाविष्ट होणार होता, परंतु तो विभागला गेला. आणि तो त्या फोर्कमधून बाहेर काढला जाण्यामागील अनेक कारणांपैकी एक कारण म्हणजे विटालिकने इथेरियमद्वारे RISC-V स्वीकारण्याच्या संभाव्यतेबद्दल एक पोस्ट टाकली होती. जे लोक ते वाचत होते त्यापैकी बऱ्याच जणांनी त्याकडे पाहिले आणि विचार केला की, ठीक आहे, जर आपण RISC-V स्वीकारले तर आपण EOF मध्ये पाहत असलेली वैशिष्ट्ये RISC-V सोबत मूळ रूपात येतात. मग आपण प्रोटोकॉलमध्ये ही गुंतागुंत का वाढवावी? आपण या गोष्टीसाठी हे सर्व क्लायंट डेव्हलपर संसाधने का वापरावीत? जर आपण शेवटी RISC-V कडे वळलो तर हा एक निरर्थक मुद्दा ठरेल.

त्यामुळे EOF च्या बाबतीत ही गोष्ट म्हणजे सहनशीलतेचा अंत करणारी ठरली आणि शेवटी ते फोर्कमधून बाहेर काढले गेले. त्यांना विचारात घ्यावी लागणारी दुसरी गोष्ट म्हणजे ते सहा वेगवेगळ्या भाषांमध्ये लिहिले गेले पाहिजे आणि त्याची कठोरपणे चाचणी केली गेली पाहिजे कारण हे क्लायंट्स सहा वेगवेगळ्या भाषांमध्ये लिहिलेले आहेत. त्यामुळे त्यांच्यासाठी काम करण्यासाठी हा खरोखरच एक मोठा टेस्टिंग मॅट्रिक्स आहे. आणि त्यामुळे प्रत्येक लहान डिझाइन निवडीवर वादविवाद होतो आणि मतभेद सोडवण्यासाठी कोणताही अधिकार नसतो. त्यामुळे प्रश्न असा निर्माण होतो की कोण ठरवतो — जो प्रशासनाचा मुख्य गाभा आहे.

गैरसमज (5:23)

तर हे आपल्याला गैरसमजांकडे घेऊन जाते आणि आपण यापैकी काहींवर चर्चा करू. एक म्हणजे इथेरियम प्रोटोकॉलमध्ये काय समाविष्ट करायचे हे विटालिक ठरवतो. त्याचाच एक विस्तार म्हणजे EF सर्वकाही नियंत्रित करते. आणि तिसरा म्हणजे हे सर्व पडद्यामागील व्यवहार आहेत — आतील लोक, जुने जाणकार (OGs) हे निर्णय घेतात.

तर पहिला: विटालिक ठरवतो. मी फक्त विटालिकने लिहिलेल्या प्रलंबित EIPs चा एक उपसंच निवडला आहे. याचा अर्थ असा की विटालिक बसला, त्याने एक प्रस्ताव लिहिला आणि तो म्हणाला की मला या गोष्टी इथेरियममध्ये समाविष्ट करायच्या आहेत आणि कोणीही सहमत झाले नाही — या गोष्टी फक्त तशाच पडून आहेत. तो या गोष्टी प्रोटोकॉलमध्ये समाविष्ट करू शकला नाही. त्यामुळे तो जो काही प्रस्ताव देतो ते सर्व आपोआप समाविष्ट होत नाही.

त्याचाच एक विस्तार म्हणजे इथेरियम फाउंडेशन सर्वकाही नियंत्रित करते. मी अशा एका वेळेचे विशिष्ट उदाहरण घेणार आहे जे मला वाटते की याच्या विरोधाभासी आहे. 2024 मध्ये गॅस मर्यादेबद्दल बरीच चर्चा झाली. आणि त्याचे कारण असे की 2022 मध्ये द मर्ज दरम्यान आपण गॅस मर्यादा 30 दशलक्षपर्यंत वाढवली. ती एका ब्लॉकमध्ये अनुमत असलेली कमाल गणना (computation) आहे. आणि मग आपण काही काळ त्याला स्पर्श केला नाही कारण ती खरोखरच अशी कोणतीही अडचण नव्हती जिथे लोक म्हणत होते, "यामुळेच मी इथेरियमकडे वळत नाही" किंवा "हे माझ्या इथेरियमच्या सध्याच्या वापरास मर्यादित करत आहे."

आणि 2023 च्या शेवटी, 2024 च्या सुरुवातीला, अशी चर्चा होती की Solana येत आहे. ते इथेरियमला मागे टाकणार आहे. आणि त्यामुळे लोक विचार करत होते की वेग वाढवण्यासाठी इथेरियम काय करू शकते. आणि त्यापैकी एक गोष्ट म्हणजे आपण हे गॅस मेट्रिक वाढवूया. आणि त्यावेळी EF आणि क्लायंट डेव्हलपर्सची भूमिका अशी होती की, "आम्हाला काळजी करण्यासाठी इतर गोष्टी आहेत. तरीही धन्यवाद." पण एरिक कॉनर आणि मारियानो कॉन्टी हे दोन लोक आले आणि म्हणाले, "नाही, आपण गॅस मर्यादा वाढवत आहोत." गॅस मर्यादा हा प्रमाणक-नियंत्रित (validator-controlled) पॅरामीटर आहे. आणि त्यामुळे ते फक्त प्रमाणकांशी, व्यावसायिक ऑपरेटर्सशी बोलू शकले आणि म्हणू शकले, "अरे, तुमची गॅस मर्यादा वाढवा."

आणि एका टप्प्यावर इतका स्वीकार झाला की EF आणि क्लायंट्सना वाटले, "अरे आपल्याला याकडे लक्ष द्यावे लागेल. ते जे करत आहेत ते सुरक्षित आहे आणि ते ज्या मूल्यापर्यंत हे वाढवणार आहेत ते नेटवर्कसाठी सुरक्षित असणार आहे याची आपल्याला खात्री करावी लागेल." त्यामुळे, त्यांना त्यांच्या संसाधनांचे पुनर्वितरण करावे लागले. नेदरमाइंड (Nethermind) या टेस्टिंग फ्रेमवर्कसह पुढे आले. EF ने बर्लिनमध्ये बरेच काम केले. सर्व क्लायंट डेव्हलपर्स याचे बेंचमार्किंग करत होते. आणि त्यामुळे मला हे आवडते कारण याने कशाला प्राधान्य द्यायचे हे ठरवण्यासाठी EF ला भाग पाडले.

आणि मला हे मूर्खपणाचे ट्विट आवडते ज्याचा मी येथे स्क्रीनशॉट घेतला आहे कारण हे असे आहे की काही यादृच्छिक न्यूज आउटलेट एरिक कॉनर आणि मारियानो कॉन्टी यांना कोअर डेव्हलपर्स म्हणत आहेत. ते कोअर डेव्हलपर्स नाहीत. एरिक कॉनर एक स्टेकर आणि समुदाय सदस्य होता. मारियानो कॉन्टी हे माजी MakerDAO ॲप डेव्हलपर होते. पण त्यांना फक्त कोअर डेव्हलपर्स म्हटले गेले कारण इथेरियम डेव्हलपमेंट हे पारंपारिक सॉफ्टवेअर कसे कार्य करते या जगाच्या खरोखरच बाहेर आहे आणि त्यामुळे त्यांनी एक कोअर पॅरामीटर सुधारित होताना पाहिले आणि त्यांना वाटले, "अरे हे कोअर डेव्हलपर्स असले पाहिजेत." ते नव्हते. तर हे फक्त समुदाय सदस्य पुढे येऊन आम्हाला हा बदल पाहायचा आहे असे म्हणण्याचे आणि ते घडवून आणण्याचे एक उदाहरण आहे.

हे सर्व पडद्यामागील व्यवहार आहेत, आतील लोक, जुने जाणकार (OGs) — हा गैरसमज का आहे हे मला थोडे अधिक समजते कारण तुम्ही मुळात या प्रशासन कॉल्समध्ये येता, या प्रशासन कॉल्समध्ये शंभर लोक असतात. असे दिसते की ते सर्व जे काही चालले आहे त्याबद्दल खूप सोयीस्कर आहेत. तुम्ही गोंधळलेले असता. हे निर्णय कसे घेतले जातात याची तुम्हाला कल्पना नसते. तुम्हाला वाटते, "अजून माझी बोलण्याची वेळ आली आहे का?" आणि असे वाटते की लोक हे निर्णय घेण्यासाठी त्याच 10 लोकांचे ऐकत आहेत.

गुणवत्ता आणि सहभागाची आकडेवारी (10:18)

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

तर मी फक्त एका वर्षापूर्वी EF मध्ये सामील झालो. मी ही आकडेवारी मिळवली. ती फक्त मार्च 2025 पर्यंतची आहे. म्हणजे एका वर्षापेक्षा कमी. सरासरी ऑल कोअर डेव्ह (All Core Dev) उपस्थिती — म्हणजेच प्रशासन कॉल्स — 98 आहे. त्यामुळे या कॉल्समध्ये सरासरी 98 लोक असतात. तेव्हापासून एका कॉलमध्ये जास्तीत जास्त उपस्थिती 153 होती. मला वाटते तो दिवस होता जेव्हा आम्ही पेक्ट्रा मुख्यनेटची तारीख ठरवत होतो. आणि फक्त गेल्या वर्षात एकूण अद्वितीय उपस्थिती 567 आहे. मला खरोखरच हे मेट्रिक आवडते कारण ते दर्शवते की प्रत्येक वेळी या कॉल्समध्ये तेच 100 लोक जात नाहीत. हे ॲप डेव्हलपर्स, संशोधक, कोणीतरी चर्चा होत असलेल्या एखाद्या वैशिष्ट्याबद्दल ऐकतो, ते त्याला विरोध करण्यासाठी किंवा पाठिंबा देण्यासाठी उपस्थित राहतात आणि मग ते दुसऱ्या कॉलला येत नाहीत.

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

तर ही थोडी कंटाळवाणी स्लाईड आहे पण मला वाटते की यातून जाणे महत्त्वाचे आहे — सध्या इथेरियमचे प्रशासन अशा प्रकारे कार्य करते. त्यामुळे जेव्हा यापैकी एका फोर्कवर चर्चा केली जात असते तेव्हा पहिली गोष्ट घडते ती म्हणजे या वाटप केलेल्या वेळेत लोक त्यांचा हेडलायनर प्रस्ताव सादर करू शकतात. हेडलायनर प्रस्ताव हे एक प्रमुख वैशिष्ट्य आहे ज्यासाठी लोकांनी या फोर्कसाठी एकत्र यावे अशी आमची इच्छा असते. हा समुदाय सदस्य, संशोधक, कोअर डेव्हलपर असू शकतो — खरोखरच कोणीही जो यापैकी एक हेडलायनर प्रस्ताव सादर करतो. मग ती वेळ संपते आणि प्रशासन कॉल्सवर आपण यापैकी कोणता अर्थपूर्ण आहे यावर चर्चा करतो. लोक त्यांची बाजू मांडतात, लोक युक्तिवाद करतात आणि आगामी फोर्कसाठी आपण कोणता निवडला पाहिजे यावर एकमत होते.

त्यानंतर ते किरकोळ वैशिष्ट्ये निवडतात. म्हणजे अशा लहान गोष्टी ज्यांना खरोखरच हे प्रमुख फोर्क-ड्रायव्हिंग वैशिष्ट्ये असण्याची आवश्यकता नसते. आणि या संपूर्ण काळात आमच्याकडे वैशिष्ट्य-विशिष्ट डेव्हनेट असतात. डेव्हनेट हे टेस्टनेटसारखे असते — डेव्हलपर्ससाठी या वैशिष्ट्यांची चाचणी करण्यासाठी आणि ते प्रत्यक्षात इथेरियमवर काम करत आहेत याची खात्री करण्यासाठी एक खाजगी चाचणी नेटवर्क. आणि मग एका टप्प्यावर फीचर फ्रीझ (feature freeze) होते. त्यामुळे आपण प्रमुख वैशिष्ट्यांवर चर्चा केली आहे, आपण किरकोळ वैशिष्ट्यांवर चर्चा केली आहे, आपण हे वैशिष्ट्य-विशिष्ट डेव्हनेट चालवले आहेत जे सहसा फोर्क हेडलायनर्स असतात. आणि ते एका अटीसह (asterisk) फीचर फ्रीझ असते कारण त्या टप्प्यावर आपण ठरवलेले असते की आपण या फोर्कमध्ये आणखी कोणतीही वैशिष्ट्ये जोडणार नाही. आपण सर्व वैशिष्ट्ये एकत्र चालवणार आहोत, सर्वकाही ठीक आहे याची खात्री करणार आहोत, काहीही खंडित होणार नाही याची खात्री करणार आहोत. पण जर एखाद्या गोष्टीमुळे प्रक्रियेचा वेग कमी होऊ लागला, जर फोर्कला उशीर झाला, जर ते खूप गुंतागुंतीचे असेल, तर त्या टप्प्यावरही गोष्टी बाहेर काढल्या जाऊ शकतात.

त्यामुळे अनेक डेव्हनेट्सनंतर — ते दोन असू शकतात, ते 10 असू शकतात — सर्व क्लायंट्स एका टप्प्यावर ठरवतात की हे स्थिर आहे. सध्या जे काही चालले आहे त्यावर आमचा विश्वास आहे. आपण चांगल्या स्थितीत आहोत. हे इथेरियम मुख्यनेटवर आणण्याचा विचार सुरू करूया. ते क्लायंट रिलीझ कट करतात आणि मग 30 दिवसांचा कालावधी असतो जिथे EF सुरक्षा टीम बग बाउन्टी (bug bounty) जाहीर करते. ते सुरक्षा ऑडिट्सचे कंत्राट देतात. आणि मग त्या 30 दिवसांच्या कालावधीच्या शेवटी आपण टेस्टनेटवर फोर्क लाँच करतो. हे असे टेस्टनेट आहेत ज्याबद्दल तुम्ही ऐकले असेल — जसे की Holesky. येथे ॲप डेव्हलपर्स फोर्क लाईव्ह होण्यापूर्वी त्यांच्या गोष्टींची चाचणी करू शकतात. आणि सर्वकाही ठीक आहे याची खात्री करण्यासाठी हे साधारणपणे प्रत्येकी किमान 14 दिवसांचे असतात. आम्हाला कोणत्याही मोठ्या समस्यांची अपेक्षा नसते कारण ते यापूर्वी वैशिष्ट्य-विशिष्ट डेव्हनेट्स आणि सामान्यीकृत डेव्हनेट्समधून गेलेले असते, परंतु ऐतिहासिकदृष्ट्या याने यापैकी काही टेस्टनेट्स खंडित केले आहेत. आणि त्यामुळे हे सर्व बग्स शोधण्यासाठी आणि नष्ट करण्यासाठी एक प्रकारची शेवटची संधी असते.

आणि मग एकदा परवानगीमुक्त (permissionless) टेस्टनेट स्थिर झाले की, मुख्यनेटची तारीख निवडली जाते. त्यानंतर, 30 दिवसांचा बफर असतो. हा 30 दिवसांचा बफर अस्तित्वात आहे कारण L2s आणि प्रोटोकॉल्सनी फोर्कसाठी तयार होण्यासाठी याची विनंती केली आहे. त्यामुळे ते किमान 30 दिवस असतात आणि मग फोर्क होतो.

कॉल रचना आणि समन्वय (15:01)

या संपूर्ण काळात काही मुख्य कॉल मालिका सुरू असतात. हे सर्व सार्वजनिक कॉल्स YouTube वर लाईव्ह-स्ट्रीम केले जातात. प्रमुख म्हणजे ACDE आणि ACDC. E म्हणजे अंमलबजावणी स्तर (execution layer) — ज्यामध्ये व्यवहार, स्मार्ट कॉन्ट्रॅक्ट डिप्लॉयमेंट्स, मेमपूल व्यवस्थापन यासारख्या गोष्टी येतात. ACDC म्हणजे सहमती स्तर (consensus layer) — त्यामुळे त्यात प्रमाणक व्यवस्थापन, स्लॅशिंग यासारख्या प्रमाणक गोष्टी येतात. आणि ते गुरुवारी आळीपाळीने होतात. त्यामुळे दर गुरुवारी एक ACD असतो आणि त्यापैकी एक ACDE असतो आणि मग पुढचा ACDC असतो, अशा प्रकारे ते सुरू राहते.

ACDE आणि ACDC कॉल्स आपण सध्या बनवत असलेल्या फोर्कवर आणि भविष्यासाठी आपण ज्या फोर्क्सची व्याप्ती ठरवत आहोत त्यावर लक्ष केंद्रित करतात. ACDT कॉल्स अधिक तपशीलवार आणि तांत्रिक असतात. ते क्लायंट्स अशा बग्सबद्दल बोलत असतात ज्यांच्या पुढे ते जाऊ शकत नाहीत किंवा ते सध्या काम करत असलेल्या फोर्कबद्दल सोडवल्या जाणाऱ्या अंमलबजावणीच्या तपशीलांबद्दल बोलत असतात. त्यामुळे सध्या होणारा पुढचा फोर्क ग्लॅमस्टरडॅम आहे. त्यामुळे या ACDT कॉल्समध्ये ePBS आणि ब्लॉक-लेव्हल ॲक्सेस लिस्ट्सबद्दलच्या संभाषणाचे वर्चस्व असते ज्या गोष्टी ग्लॅमस्टरडॅममध्ये समाविष्ट होणार आहेत. आणि हे अत्यंत तांत्रिक कॉल्स असतात.

आणि मग ब्रेकआउट कॉल्स असतात. ब्रेकआउट कॉल्स म्हणजे समुदाय सदस्य, संशोधक, डेव्हलपर्स असे म्हणत असतात, "अरे, माझ्याकडे एक वैशिष्ट्य आहे जे मला आतापासून दोन फोर्क्सनंतर इथेरियममध्ये समाविष्ट करायचे आहे." आणि त्यामुळे ते हे साप्ताहिक, मासिक किंवा द्वैमासिक कॉल्स आयोजित करतात जिथे ते अंमलबजावणीच्या तपशीलांवर चर्चा करतात, स्पेसिफिकेशनमध्ये बदल आणि पुनरावृत्ती करतात आणि साधारणपणे लोकांच्या सर्व प्रश्नांची उत्तरे देतात, सर्व ज्ञात अज्ञातांना संबोधित करतात जेणेकरून ते आतापासून दोन फोर्क्सनंतर फोर्कमध्ये समाविष्ट करण्यासाठी सर्वोत्तम संभाव्य स्थितीत असेल याची खात्री करता येईल. आणि फॅसिलिटेटर ठरवेल तेव्हा ते शेड्यूल केले जाऊ शकतात.

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

तर एक गोष्ट जी मला सर्वांच्या मनावर बिंबवायची आहे ती म्हणजे ही प्रक्रिया अजिबात स्थिर नाही. मी तुम्हाला आत्ताच वर्णन केलेली ही प्रक्रिया एका वर्षापेक्षा कमी काळापासून लाईव्ह आहे. इथेरियम 10 वर्षांपासून लाईव्ह आहे. पण ते सतत बदलते आणि ते सतत बदलण्याचे कारण म्हणजे कोणीही प्रभारी नाही. आणि कार्य करण्याचा सर्वात कार्यक्षम मार्ग शोधण्यासाठी ही प्रक्रिया एक प्रकारे विकसित होते. आणि मी कार्यक्षम म्हणतो, पण इथेरियम प्रशासनाची प्रतिष्ठा खरोखरच संथ असण्याची, गोष्टी पूर्ण करणे कठीण असण्याची, गोंधळात टाकणारी अशी आहे — आणि त्याचे कारण असे की जेव्हा तुमच्याकडे 100 ते 500 लोक निर्णय घेत असतात, तेव्हा हे अजिबात काम करते याबद्दल मी प्रामाणिकपणे प्रभावित आहे.

त्यामुळे टिमने एप्रिल 2025 मध्ये "Reconfiguring All Core Devs" नावाची एक पोस्ट केली जी सध्या गोष्टी कशा कार्य करतात यासाठीचा प्रस्ताव ठरली. आणि त्याचे कारण असे की त्यापूर्वी आपल्याकडे इथेरियममध्ये आपण कशावर लक्ष केंद्रित केले पाहिजे याबद्दल एक प्रकारची सुसंगत कथा होती. द मर्ज होते जे एक मोठे काम होते. प्रत्येकजण खूप उत्साहित होता. बहुतेक लोक खूप उत्साहित होते. मायनर्स नव्हते. आणि मग द मर्जनंतर, तुमच्याकडे विथड्रॉवल्स (withdrawals) होते. त्यामुळे, लोकांचे ETH एका कॉन्ट्रॅक्टमध्ये लॉक व्हावे आणि त्यांना यातून कधीही ETH बाहेर काढता येणार नाही अशी भीती (FUD) निर्माण व्हावी असे आम्हाला वाटत नव्हते. त्यामुळे, आम्हाला ते शक्य तितक्या लवकर शिप करावे लागले. आणि मग प्रोटो-डँकशार्डिंग होते आणि मग पेक्ट्रा आले आणि पेक्ट्रा हे वेगवेगळ्या असंबंधित EIPs चे एक प्रकारचे मिश्रण होते आणि त्याला खरोखरच कोणतीही सुसंगत कथा नव्हती. आणि ते इतके मोठे झाले कारण सुसंगततेच्या अभावामुळे लोक फक्त गोष्टी आत ढकलत होते की ते दोन वेगवेगळ्या फोर्क्समध्ये विभागले जावे लागले कारण टेस्टिंग टीम्सची भूमिका अशी होती की, "व्याप्ती खूप मोठी आहे. आम्ही या सर्वांची चाचणी करू शकत नाही."

आणि त्यामुळे टिमचा हे करण्याचा उद्देश असा होता की, ठीक आहे, आपल्याला हे फोर्क्स शक्य तितके केंद्रित आणि सुसंगत ठेवण्याच्या मार्गाचा विचार करणे आवश्यक आहे. आणि हेडलायनर हे त्याचे एक प्रकारचे उत्तर होते. त्याचा उद्देश अशा प्रकारे शिप करणे हा होता ज्याने प्रत्येकाला फोर्क कशाबद्दल आहे हे माहित आहे असे वाटण्याला प्राधान्य दिले, जेणेकरून त्यांना 25 भिन्न EIPs आत ढकलावे लागणार नाहीत.

तर वरचा दुसरा स्क्रीनशॉट टिम या EIPs च्या समावेशाच्या टप्प्यांसाठी व्याख्या प्रस्तावित करत असल्याचा आहे. आणि मला यातून जो मुद्दा मांडायचा आहे तो असा की कधीकधी तुम्ही लोकांना असे म्हणताना ऐकता की ही प्रक्रिया खूप नोकरशाहीची (bureaucratic) आहे. पण प्रत्यक्षात काय घडत आहे की लोक या प्रशासन प्रक्रियेत येतात आणि ते विचारतात, "मी EIP कसा समाविष्ट करू?" आणि जे लोक 10 वर्षांपासून तिथे आहेत ते म्हणतात, "तुम्ही फक्त ते करता." आणि लोकांना वाटते, "हे भयंकर आहे." आणि त्यामुळे या गोष्टी काय करतात तर त्या काय घडत आहे याचे वर्णन करतात जेणेकरून बाहेरील लोकांसाठी या प्रक्रियेत सहभागी होणे सोपे होईल, कारण जर तुम्ही फक्त येथे येत असाल आणि तुम्हाला वाटत असेल, "माझ्याकडे एक EIP आहे, मला इथेरियम प्रशासनाची पर्वा नाही, मला फक्त हा एक EIP समाविष्ट करायचा आहे" — तुम्हाला एक रूब्रिक हवे असते, तुम्हाला एक चेकलिस्ट हवी असते, हा EIP कसा समाविष्ट करायचा यावर तुम्हाला अगदी स्पष्ट टप्प्याटप्प्याने माहिती हवी असते. त्यामुळे, यापैकी बहुतेक गोष्टी EIPs समाविष्ट करणे कठीण करण्यासाठी लोकांना पाळावे लागणारे नोकरशाहीचे नियम तयार करण्यापेक्षा प्रक्रिया कशी कार्य करते याचे वर्णन करण्याबद्दल अधिक आहेत.

तिसरी गोष्ट म्हणजे Forkcast वरील वेळेनुसार कमिट्स (commits). Forkcast हे माझ्या टीमचे, माझ्या टीममधील वोलफ्राम मार्क (Wolfram Mark) या व्यक्तीचे एक उत्पादन आहे, ज्याने गेल्या वर्षाच्या मध्यभागी हे तयार केले जेव्हा माझी टीम तिच्या सध्याच्या स्वरूपात तयार झाली होती. आणि लोकांसाठी फोर्कशी संवाद साधण्यासाठी, फोर्कमध्ये काय समाविष्ट होत आहे आणि त्याचा त्यांच्यावर कसा परिणाम होतो हे पाहण्यासाठी हे एक अतिशय प्रमाणित संसाधन बनले आहे. या सर्व गोष्टी दोन वर्षांपेक्षा कमी जुन्या आहेत. त्यामुळे मी फक्त हा मुद्दा मांडत आहे की ही प्रक्रिया खूप बदलते. ती अजिबात स्थिर नाही. ही काही गोठलेली नोकरशाही नाही जिथे प्रवेश मिळवणे कठीण आहे.

तुलनात्मक प्रशासन प्रणाली (20:21)

तर मला इथेरियम प्रशासनाशी सर्वात मिळत्याजुळत्या असलेल्या विकेंद्रित प्रशासन प्रणालींवर थोडक्यात चर्चा करायची आहे. आणि मला येथे जो मुद्दा मांडायचा आहे तो असा की हे शाश्वत आहे — जरी 100 ते 500 लोक निर्णय घेऊ शकतात हे आश्चर्यकारक असले तरी, ते वास्तविक जगात शाश्वत आहे. आपण हे काम करत असल्याची उदाहरणे पाहतो.

IETF म्हणजे इंटरनेट इंजिनिअरिंग टास्क फोर्स (Internet Engineering Task Force). ही स्वयंसेवकांद्वारे चालवली जाणारी मानक संस्था आहे जिने TCP/IP, HTTP तयार केले. आज आपल्याकडे मोफत इंटरनेट आहे या वस्तुस्थितीसाठी सर्वात जास्त जबाबदार असलेली ही संस्था आहे. लिनक्स कर्नल (Linux kernel) — हा लिनक्स ऑपरेटिंग सिस्टमचा गाभा आहे. तर ते ओपन-सोर्स सॉफ्टवेअर आहे जे इंटरनेट सर्व्हर्स, अँड्रॉइड फोन्स, सुपरकॉम्प्युटर्स चालवते. तेथील फरक असा आहे की त्यांच्याकडे लिनस टोरवाल्ड्स (Linus Torvalds) सोबत एक प्रकारचे परोपकारी हुकूमशहा (benevolent dictator) मॉडेल आहे. पण तरीही त्यांच्याकडे 17,000 हून अधिक योगदानकर्ते आहेत, जे थक्क करणारे आहे.

ज्या गोष्टींशी हे समान नाही: इतर ब्लॉकचेन्स ज्यांच्याकडे ऑनचेन टोकन व्होटिंग आहे. इथेरियम विशेषतः कोणत्याही प्रकारची मतदान यंत्रणा टाळते कारण माझ्या मते त्यामुळे कॅप्चर (नियंत्रण मिळवण्याचे) मार्ग खुले होतात आणि ते एक प्रकारे गोष्टींना गुणवत्तेवर आधारित बनवण्याचे प्रोत्साहन नष्ट करते जिथे लोक फक्त सर्वोत्तम कोड लिहिणाऱ्या लोकांवर विश्वास ठेवतात. आणि मग L2s आहेत. त्यांच्याकडे मल्टी-सिग्स (multi-sigs) आहेत. त्यांच्याकडे सुरक्षा परिषदा (security councils) आहेत. हे निर्णय घेणाऱ्या नियुक्त पदांसारखे अधिक आहेत. आणि त्याचे स्वतःचे फायदे-तोटे आहेत. ते अधिक केंद्रित (centralized) आहे. तरीही ते वेगाने पुढे जाते.

बिल्डर्सना काळजी का असते (22:38)

तर बिल्डर्सना प्रशासनाची काळजी का असते? कारण इथेरियम अक्षरशः बिल्डर्ससाठीच तयार केले गेले आहे. इथेरियम कोअर डेव्हलपर्ससाठी तयार केलेले नाही. ते प्रमाणकांसाठी तयार केलेले नाही. कधीकधी या लोकांचा त्याबद्दल गोंधळ उडतो. इथेरियम कोअर डेव्हलपर्स आणि प्रमाणक इथेरियमची सेवा करतात जे बिल्डर्स आणि वापरकर्त्यांची सेवा करते.

आणि प्रत्येकाने AI सोबत असा क्षण अनुभवला असेल जिथे तुम्ही खूप खोलात जाता आणि ते ही छोटीशी गोष्ट दुरुस्त करण्याचा प्रयत्न करत असते आणि ते झूम आउट करून प्रकल्पाच्या संपूर्ण उद्देशाकडे पाहण्यात अपयशी ठरते. आणि कोअर डेव्हलपर्स असे असू शकतात जिथे ते कोअर डेव्हलपमेंट प्रक्रिया परिपूर्ण करण्याचा प्रयत्न करत असतात. आणि अशा परिस्थितीत बिल्डर्सनी पुढे येणे अत्यंत महत्त्वाचे आहे कारण कोअर डेव्हलपमेंट इतके वेळखाऊ असते की ते बहुतेक वेळा इथेरियमवर बिल्डिंग करत नसतात. ते कोअर डेव्हलपमेंटमध्ये खूप गुंतलेले असतात. त्यात त्यांचा सर्व वेळ जातो. आणि त्यामुळे ॲप बिल्डर्सना खरोखरच पुढे येऊन असे म्हणण्याचा प्रयत्न करावा लागतो की, "अरे, आम्हाला याची गरज आहे. हे इथेरियमसाठी महत्त्वपूर्ण आहे." फक्त तो दृष्टिकोन तिथे आहे आणि ते फक्त कोअर डेव्हलपर्ससाठी काम करण्यात अडकून पडत नाहीत याची खात्री करण्यासाठी.

कसे सहभागी व्हावे (24:40)

तर तुम्ही कसे सहभागी व्हाल किंवा तुमचे वैशिष्ट्य कसे समाविष्ट कराल? हा एक प्रकारचा सामान्य सल्ला आहे, पण मला वाटते की तो सर्वोत्तम आहे. तुमच्या समस्यांबद्दल (pain points) उघडपणे बोला. Twitter वर जा, ब्लॉग पोस्ट लिहा, तुमच्या समस्यांसाठी उपाय शोधा. तुम्हाला मदत करू शकणाऱ्या गोष्टींचा अंदाज लावा. जर तुम्हाला त्याच समस्या असलेले इतर लोक सापडले, तर साधारणपणे तुम्हाला ती समस्या सोडवण्यासाठी अस्तित्वात असलेला एखादा EIP सापडू शकतो किंवा तसे करणारा EIP लिहिण्यासाठी तुम्हाला कोणाची तरी मदत मिळू शकते.

ओपन-सोर्स सॉफ्टवेअरबद्दल मला एक गोष्ट आवडते ती म्हणजे साधारणपणे चांगल्या भांडवल असलेल्या कंपन्या त्यांचा डेव्हलपमेंटचा वेळ आणि संसाधने ते वापरत असलेल्या ओपन-सोर्स टूलिंगची देखभाल करण्यासाठी वाटप करतील. आणि शेवटी अनेक वेगवेगळ्या कंपन्या या गोष्टीची देखभाल करण्यासाठी सहयोग करतात आणि इथेरियममध्येही ते असेच कार्य करू शकते. त्यामुळे जर तुम्ही एखादी समस्या ओळखली असेल तर तुम्हाला असा एखादा Base डेव्हलपर सापडू शकतो ज्याला अशीच समस्या आहे, आणि Base ही एक चांगली भांडवल असलेली संस्था आहे आणि त्यामुळे ते कदाचित एखादे वैशिष्ट्य शिप करण्यासाठी किंवा इथेरियम हार्ड फोर्कद्वारे एखाद्या वैशिष्ट्याचे व्यवस्थापन करण्यासाठी काही संसाधने वाटप करण्यास तयार असतील.

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