प्रमुख मजकुराकडे जा
Change page

क्लायंट विविधता

पृष्ठ अखेरचे अद्यतन: २३ फेब्रुवारी, २०२६

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

पूर्वतयारी

तुम्हाला नोड्स आणि क्लायंट काय आहेत हे आधीच माहीत नसल्यास, नोड्स आणि क्लायंट तपासा. आणि स्तर शब्दकोशात परिभाषित केले आहेत.

एकापेक्षा जास्त क्लायंट का आहेत?

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

क्लायंट विविधता का महत्त्वाची आहे?

अनेक स्वतंत्रपणे विकसित आणि देखरेख केलेले क्लायंट असणे विकेंद्रित नेटवर्कच्या आरोग्यासाठी महत्त्वाचे आहे. चला त्यामागील कारणे जाणून घेऊया.

बग्स

एखाद्या वैयक्तिक क्लायंटमधील बग, जेव्हा ते Ethereum नोड्सच्या अल्पसंख्याकांचे प्रतिनिधित्व करते, तेव्हा नेटवर्कसाठी कमी धोकादायक असते. अनेक क्लायंटमध्ये नोड्सच्या अंदाजे समान वितरणासह, बहुतेक क्लायंटना सामायिक समस्येचा सामना करण्याची शक्यता कमी असते आणि परिणामी, नेटवर्क अधिक मजबूत होते.

हल्ल्यांना प्रतिरोधक क्षमता

क्लायंट विविधता हल्ल्यांना प्रतिरोधक क्षमता देखील प्रदान करते. उदाहरणार्थ, एखादा हल्ला जो एखाद्या विशिष्ट क्लायंटला फसवून (opens in a new tab) चेनच्या विशिष्ट शाखेवर आणतो, तो यशस्वी होण्याची शक्यता कमी असते कारण इतर क्लायंट त्याच प्रकारे शोषण करण्यायोग्य नसतात आणि कॅनॉनिकल चेन अबाधित राहते. कमी क्लायंट विविधता प्रबळ क्लायंटवरील हॅकशी संबंधित धोका वाढवते. क्लायंट विविधता ही नेटवर्कवरील दुर्भावनापूर्ण हल्ल्यांविरूद्ध एक महत्त्वपूर्ण संरक्षण असल्याचे आधीच सिद्ध झाले आहे, उदाहरणार्थ, 2016 मधील शांघाय डिनायल-ऑफ-सर्व्हिस हल्ला शक्य झाला कारण हल्लेखोर प्रबळ क्लायंटला (Geth) प्रति ब्लॉक हजारो वेळा हळू डिस्क i/o ऑपरेशन कार्यान्वित करण्यासाठी फसवू शकले. कारण पर्यायी क्लायंट देखील ऑनलाइन होते जे असुरक्षितता सामायिक करत नव्हते, Ethereum हल्ल्याचा प्रतिकार करण्यास आणि Geth मधील असुरक्षितता दुरुस्त होईपर्यंत कार्यरत राहण्यास सक्षम होते.

प्रूफ-ऑफ-स्टेक अंतिमता

Ethereum नोड्सपैकी 33% पेक्षा जास्त असलेल्या सहमती क्लायंटमधील बग सहमती स्तराला अंतिम होण्यापासून रोखू शकतो, याचा अर्थ वापरकर्ते असा विश्वास ठेवू शकत नाहीत की व्यवहार कधीतरी परत घेतले जाणार नाहीत किंवा बदलले जाणार नाहीत. हे Ethereum वर तयार केलेल्या अनेक ॲप्ससाठी, विशेषतः DeFi साठी खूप समस्याप्रधान असेल.

याहूनही वाईट, दोन-तृतीयांश बहुमत असलेल्या क्लायंटमधील एक गंभीर बग चेनला चुकीच्या पद्धतीने विभाजित आणि अंतिम करण्यास कारणीभूत ठरू शकतो, ज्यामुळे व्हॅलिडेटर्सचा एक मोठा संच अवैध चेनवर अडकून पडू शकतो. जर त्यांना योग्य चेनमध्ये पुन्हा सामील व्हायचे असेल, तर या व्हॅलिडेटर्सना स्लॅशिंग किंवा हळू आणि महागड्या ऐच्छिक पैसे काढणे आणि पुन्हा सक्रिय करणे याचा सामना करावा लागतो. स्लॅशिंगचे प्रमाण दोषी नोड्सच्या संख्येनुसार वाढते, ज्यात दोन-तृतीयांश बहुमताला जास्तीत जास्त (32 ETH) स्लॅश केले जाते.

जरी हे अशक्यप्राय प्रसंग असले तरी, Ethereum इको-सिस्टम सक्रिय नोड्सवरील क्लायंटचे वितरण समान करून त्यांचा धोका कमी करू शकते. आदर्शपणे, कोणताही सहमती क्लायंट एकूण नोड्सच्या 33% वाटा कधीही गाठणार नाही.

सामायिक जबाबदारी

बहुसंख्य क्लायंट असण्याची मानवी किंमत देखील आहे. हे एका लहान विकास टीमवर अतिरिक्त ताण आणि जबाबदारी टाकते. क्लायंट विविधता जितकी कमी असेल, तितकीच बहुसंख्य क्लायंटची देखभाल करणाऱ्या विकासकांवर जबाबदारीचा भार जास्त असतो. ही जबाबदारी अनेक टीममध्ये विभागणे Ethereum च्या नोड्सच्या नेटवर्कच्या आणि त्याच्या लोकांच्या नेटवर्कच्या आरोग्यासाठी चांगले आहे.

सध्याची क्लायंट विविधता

अंमलबजावणी क्लायंट

सहमती क्लायंट

हा आकृती कदाचित जुना असेल — अद्ययावत माहितीसाठी ethernodes.org (opens in a new tab) आणि clientdiversity.org (opens in a new tab) वर जा.

वरील दोन पाय चार्ट अंमलबजावणी आणि सहमती स्तरांसाठी सध्याच्या क्लायंट विविधतेचे स्नॅपशॉट दर्शवतात (ऑक्टोबर 2025 मध्ये लिहिण्याच्या वेळी). गेल्या काही वर्षांत क्लायंट विविधता सुधारली आहे, आणि अंमलबजावणी स्तराने Geth (opens in a new tab) च्या वर्चस्वात घट पाहिली आहे, Nethermind (opens in a new tab) दुसऱ्या क्रमांकावर, Besu (opens in a new tab) तिसऱ्या आणि Erigon (opens in a new tab) चौथ्या क्रमांकावर आहे, आणि इतर क्लायंट नेटवर्कच्या 3% पेक्षा कमी आहेत. सहमती स्तरावरील सर्वात सामान्यपणे वापरला जाणारा क्लायंट—Lighthouse (opens in a new tab)—दुसऱ्या सर्वात जास्त वापरल्या जाणाऱ्या क्लायंटच्या अगदी जवळ आहे. Prysm (opens in a new tab) आणि Teku (opens in a new tab) अनुक्रमे ~31% आणि ~14% आहेत, आणि इतर क्लायंट क्वचितच वापरले जातात.

अंमलबजावणी स्तरावरील डेटा supermajority.info (opens in a new tab) वरून 26-Oct-2025 रोजी मिळवला होता. सहमती क्लायंटसाठी डेटा Michael Sproul (opens in a new tab) यांच्याकडून मिळवला होता. सहमती क्लायंट डेटा मिळवणे अधिक कठीण आहे कारण सहमती स्तरावरील क्लायंटमध्ये नेहमीच स्पष्ट ट्रेस नसतात ज्याचा वापर त्यांना ओळखण्यासाठी केला जाऊ शकतो. हा डेटा एका वर्गीकरण अल्गोरिदमचा वापर करून तयार केला गेला आहे जो कधीकधी काही अल्पसंख्य क्लायंटमध्ये गोंधळ घालतो (अधिक माहितीसाठी येथे (opens in a new tab) पहा). वरील आकृतीत, या संदिग्ध वर्गीकरणांना एक/किंवा लेबल (उदा. Nimbus/Teku) ने दर्शविले आहे. तरीही, हे स्पष्ट आहे की नेटवर्कचा बहुतांश भाग Prysm चालवत आहे. केवळ स्नॅपशॉट असूनही, आकृतीमधील मूल्ये क्लायंट विविधतेच्या सद्यस्थितीची एक चांगली सामान्य कल्पना देतात.

सहमती स्तरासाठी अद्ययावत क्लायंट विविधता डेटा आता clientdiversity.org (opens in a new tab) वर उपलब्ध आहे.

अंमलबजावणी स्तर

आतापर्यंत, क्लायंट विविधतेवरील संभाषण प्रामुख्याने सहमती स्तरावर केंद्रित होते. तथापि, अंमलबजावणी क्लायंट Geth (opens in a new tab) सध्या सर्व नोड्सपैकी सुमारे 85% आहे. ही टक्केवारी सहमती क्लायंटसाठी असलेल्या त्याच कारणांसाठी समस्याप्रधान आहे. उदाहरणार्थ, Geth मधील एक बग जो व्यवहार हाताळणी किंवा अंमलबजावणी पेलोड्स तयार करण्यावर परिणाम करतो, तो सहमती क्लायंटना समस्याप्रधान किंवा बगयुक्त व्यवहार अंतिम करण्यास प्रवृत्त करू शकतो. म्हणून, अंमलबजावणी क्लायंटच्या अधिक समान वितरणासह Ethereum अधिक निरोगी होईल, आदर्शपणे कोणताही क्लायंट नेटवर्कच्या 33% पेक्षा जास्त प्रतिनिधित्व करणार नाही.

अल्पसंख्य क्लायंट वापरा

क्लायंट विविधतेचे निराकरण करण्यासाठी केवळ वैयक्तिक वापरकर्त्यांनी अल्पसंख्य क्लायंट निवडणे पुरेसे नाही - त्यासाठी व्हॅलिडेटर पूल आणि प्रमुख dapps आणि एक्सचेंज सारख्या संस्थांना देखील क्लायंट बदलण्याची आवश्यकता आहे. तथापि, सर्व वापरकर्ते सध्याचा असमतोल दूर करण्यात आणि सर्व उपलब्ध Ethereum सॉफ्टवेअरचा वापर सामान्य करण्यात आपली भूमिका बजावू शकतात. The Merge नंतर, सर्व नोड ऑपरेटर्सना एक अंमलबजावणी क्लायंट आणि एक सहमती क्लायंट चालवणे आवश्यक असेल. खाली सुचवलेल्या क्लायंटचे संयोजन निवडल्यास क्लायंट विविधता वाढण्यास मदत होईल.

एक्झिक्युशन क्लायंट

कन्सेंसस क्लायंट

तांत्रिक वापरकर्ते अल्पसंख्य क्लायंटसाठी अधिक ट्युटोरियल्स आणि डॉक्युमेंटेशन लिहून आणि त्यांच्या नोड-ऑपरेटिंग सहकाऱ्यांना प्रबळ क्लायंटपासून दूर जाण्यासाठी प्रोत्साहित करून ही प्रक्रिया वेगवान करण्यास मदत करू शकतात. अल्पसंख्य सहमती क्लायंटवर स्विच करण्यासाठी मार्गदर्शक clientdiversity.org (opens in a new tab) वर उपलब्ध आहेत.

क्लायंट विविधता डॅशबोर्ड

अनेक डॅशबोर्ड अंमलबजावणी आणि सहमती स्तरासाठी रिअल-टाइम क्लायंट विविधता आकडेवारी देतात.

सहमती स्तर:

अंमलबजावणी स्तर:

पुढील वाचन

हा लेख उपयुक्त होता का?