मुख्य सामग्री पर जाएं
एक भविष्यवादी दृश्य जो आपस में जुड़े ब्लॉकचेन नोड्स और सुरक्षा तत्वों को दिखाता है, जो डिजिटल संपत्ति क्षेत्र में ट्रिलियन डॉलर की सुरक्षा का प्रतिनिधित्व करता है

ट्रिलियन डॉलर सिक्योरिटी प्रोजेक्ट

सुरक्षा चुनौतियों का अवलोकन

इथेरियम सबसे सुरक्षित, लचीला और विश्वसनीय ब्लॉकचेन इकोसिस्टम है। पिछले 10 वर्षों में इथेरियम इकोसिस्टम ने ऐसी तकनीक, मानक और ज्ञान विकसित किया है जो आज लाखों लोगों द्वारा उपयोग किए जाने वाले इकोसिस्टम का समर्थन करता है और जिसमें $600 बिलियन से अधिक की पूंजी है।

लेकिन वैश्विक स्तर पर अपनाए जाने के अगले चरण में इथेरियम को सफल होने के लिए, अभी भी कई सुधार किए जाने बाकी हैं। हमारे समुदाय की महत्वाकांक्षाओं को प्राप्त करने के लिए, इथेरियम को एक ऐसे इकोसिस्टम के रूप में विकसित होना चाहिए जहां:

  • अरबों व्यक्ति ऑनचेन $1000 से अधिक रखने में सहज हों, जो सामूहिक रूप से इथेरियम पर सुरक्षित ट्रिलियन डॉलर की राशि हो।
  • कंपनियां, संस्थान और सरकारें एक ही अनुबंध या एप्लिकेशन के अंदर 1 ट्रिलियन डॉलर से अधिक का मूल्य संग्रहीत करने में सहज हों, और तुलनीय मात्रा में लेन-देन करने में सहज हों।

ट्रिलियन डॉलर सिक्योरिटी (1TS) (opens in a new tab) प्रोजेक्ट इथेरियम की सुरक्षा को अपग्रेड करने का एक इकोसिस्टम-व्यापी प्रयास है। यह रिपोर्ट 1TS प्रोजेक्ट का पहला परिणाम है। पिछले महीने में, हमने उपयोगकर्ताओं, डेवलपर्स, सुरक्षा विशेषज्ञों और संस्थानों से प्रतिक्रिया एकत्र की है कि वे सबसे बड़ी चुनौतियों और सुधार के क्षेत्रों को कहां देखते हैं। उन सैकड़ों लोगों और दर्जनों संगठनों को धन्यवाद जिन्होंने हमारे साथ अपनी अंतर्दृष्टि साझा करने के लिए समय निकाला।

यह रिपोर्ट 6 अलग-अलग क्षेत्रों को कवर करते हुए हमारे निष्कर्षों का सारांश देती है:

  1. उपयोगकर्ता अनुभव (UX)

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

  2. स्मार्ट अनुबंध सुरक्षा

    इथेरियम एप्लिकेशनों के स्मार्ट अनुबंध घटकों की सुरक्षा, और सॉफ्टवेयर उत्पादन का जीवनचक्र जो उन्हें आकार देता है।

  3. इन्फ्रास्ट्रक्चर और क्लाउड सुरक्षा

    इन्फ्रास्ट्रक्चर (क्रिप्टो-विशिष्ट और पारंपरिक दोनों) के साथ समस्याएं जिन पर इथेरियम ऐप्स निर्भर करते हैं, जैसे लेयर 2 (l2) चेन, RPC, क्लाउड होस्टिंग सेवाएं, और बहुत कुछ।

  4. सर्वसम्मति प्रोटोकॉल

    कोर प्रोटोकॉल के सुरक्षा गुण, जो इथेरियम ब्लॉकचेन को हमले या हेरफेर से सुरक्षित करते हैं।

  5. निगरानी, घटना प्रतिक्रिया और शमन

    सुरक्षा उल्लंघनों का जवाब देते समय उपयोगकर्ताओं और संगठनों को जिन चुनौतियों का सामना करना पड़ता है, विशेष रूप से धन की वसूली या बाद के प्रभावों के प्रबंधन में।

  6. सामाजिक लेयर और शासन

    इथेरियम का ओपन सोर्स शासन, समुदाय और संगठनों का इकोसिस्टम।

यह पहली रिपोर्ट शेष समस्याओं और चुनौतियों की पहचान करने और उन्हें मैप करने पर केंद्रित है। अगला कदम सर्वोच्च प्राथमिकता वाले मुद्दों को चुनना, समाधानों की पहचान करना और उन्हें हल करने के लिए इकोसिस्टम के साथ काम करना होगा।

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

आप अपनी प्रतिक्रिया और विचार साझा करके 1TS सुरक्षा प्रोजेक्ट में योगदान कर सकते हैं:

  • क्या आपको इथेरियम सुरक्षा में ऐसी समस्याएं दिखाई देती हैं जो इस रिपोर्ट में शामिल नहीं हैं?
  • आपके अनुसार नीचे सर्वेक्षण किए गए मुद्दों में सर्वोच्च प्राथमिकताएं क्या हैं?
  • इन समस्याओं को कैसे हल किया जाए, इसके लिए आपके पास क्या विचार या समाधान हैं?

हम trilliondollarsecurity@ethereum.org पर आपसे सुनने के लिए उत्सुक हैं।

1. उपयोगकर्ता अनुभव (UX)

सुरक्षा उस इंटरफ़ेस से शुरू होती है जिसका उपयोग लोग इथेरियम के साथ इंटरैक्ट करने के लिए करते हैं। उपयोगकर्ताओं और ब्लॉकचेन के बीच की यह सीमा सुरक्षा चुनौतियों का एक निरंतर स्रोत है।

ब्लॉकचेन की एक परिभाषित विशेषता लेन-देन की परमाणु (atomic) प्रकृति है: एक बार जब कोई अपडेट ब्लॉकचेन में दर्ज हो जाता है, तो हस्तक्षेप या उलटफेर का कोई अवसर नहीं होता है। यह स्थिरता और प्रोटोकॉल स्तर की सुरक्षा की मजबूत गारंटी प्रदान करता है, लेकिन उपयोगकर्ताओं को बढ़े हुए परिचालन जोखिम में डालता है: एक भी गलती, समझौता की गई कुंजी, या जल्दबाजी में दी गई स्वीकृति अपरिवर्तनीय नुकसान का कारण बन सकती है।

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

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

1.1 कुंजी प्रबंधन

कई उपयोगकर्ता क्रिप्टोग्राफ़िक कुंजियों को सुरक्षित रूप से प्रबंधित करने के लिए सुसज्जित नहीं हैं।

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

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

चाहे कुंजियों को सॉफ़्टवेयर या हार्डवेयर वॉलेट में प्रबंधित किया जाए, कई उपयोगकर्ता स्वाभाविक रूप से स्व-कस्टडी (self custody) को लेकर घबराए हुए हैं जब इसे भौतिक चोरी या हमले के माध्यम से समझौता किया जा सकता है।

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

1.2 ब्लाइंड साइनिंग और लेन-देन की अनिश्चितता

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

1.3 स्वीकृति और अनुमति प्रबंधन

कई इथेरियम एप्लिकेशनों में, उपयोगकर्ताओं के लिए सामान्य उपयोग के हिस्से के रूप में अंतर्निहित एप्लिकेशन को कुछ अनुमतियां देना आम बात है। उदाहरण के लिए, एक उपयोगकर्ता यूनिस्वैप जैसे विकेंद्रीकृत एक्सचेंज को ETH के लिए स्वैप करने के लिए अपने टोकन को स्थानांतरित करने की अनुमति दे सकता है।

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

यह उपयोगकर्ताओं को दुर्भावनापूर्ण ऐप्स या समझौता किए गए फ्रंटएंड के संपर्क में ला सकता है, क्योंकि कई उपयोगकर्ताओं के लिए डिफ़ॉल्ट पैटर्न असीमित स्वीकृति देना है जिसका उपयोग उनके धन को निकालने के लिए किया जा सकता है। भले ही कोई उपयोगकर्ता किसी वैध स्मार्ट अनुबंध को स्वीकृति देता है, यदि बाद में उस अनुबंध से समझौता किया जाता है जबकि स्वीकृति बनी रहती है, तो समझौता किया गया अनुबंध उपयोगकर्ता के धन को निकाल सकता है।

यह संगठनात्मक उपयोगकर्ताओं के लिए भी समान रूप से एक जोखिम है। उदाहरण के लिए, एक संगठन परिचालन सुविधा के लिए DEX राउटर को असीमित USDC व्यय सीमा देने का विकल्प चुन सकता है, जो राउटर अनुबंध के अपग्रेड होने पर उन्हें जोखिम में डालता है।

1.4 समझौता किए गए वेब इंटरफेस

अधिकांश उपयोगकर्ता सीधे स्मार्ट अनुबंध के साथ इंटरैक्ट नहीं करते हैं, बल्कि अपने मोबाइल डिवाइस या वेब ब्राउज़र के माध्यम से वेब इंटरफ़ेस के जरिए करते हैं।

ये फ्रंटएंड DNS हाईजैकिंग, दुर्भावनापूर्ण जावास्क्रिप्ट इंजेक्शन, असुरक्षित होस्टिंग, या विभिन्न तृतीय-पक्ष निर्भरताओं जैसे परिचित माध्यमों से हमले के प्रति संवेदनशील हो सकते हैं। एक समझौता किया गया ऐप UX सभी प्रकार के उपयोगकर्ताओं को दुर्भावनापूर्ण स्मार्ट अनुबंधों पर पुनर्निर्देशित कर सकता है या उन्हें भ्रामक लेन-देन पर हस्ताक्षर करने के लिए प्रेरित कर सकता है।

1.5 गोपनीयता

गोपनीयता सभी प्रकार के उपयोगकर्ताओं के लिए सुरक्षा जोखिमों को कम या बढ़ा सकती है।

कमजोर गोपनीयता सुरक्षा व्यक्तिगत उपयोगकर्ताओं को फ़िशिंग, शोषण, घोटालों या भौतिक हमलों जैसे विभिन्न लक्षित खतरों के संपर्क में लाती है। कई सामान्य UX पैटर्न उपयोगकर्ताओं को उजागर करते हैं, उदा., पते का पुन: उपयोग, KYC डेटा, और अन्य मेटाडेटा लीक।

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

1.6 विखंडन

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

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

2. स्मार्ट अनुबंध सुरक्षा

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

इथेरियम के इतिहास में स्मार्ट अनुबंध सुरक्षा में मौलिक रूप से सुधार हुआ है। DAO हैक जैसी शुरुआती सुरक्षा घटनाओं ने इकोसिस्टम को पेशेवर बनाने और सॉफ़्टवेयर जीवनचक्र में सुरक्षा उपायों में सुधार करने के लिए प्रेरित किया जो कोड को ऑनचेन तैनात करने की ओर ले जाता है। प्रमुख प्रगतियों में शामिल हैं:

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

हालांकि, इस क्षेत्र में अभी भी कमजोरियां और सुधार की गुंजाइश है।

2.1 अनुबंध कमजोरियां

स्मार्ट अनुबंध सुरक्षा में प्रगति के बावजूद, अभी भी ऐसी कमजोरियां हैं जो महत्वपूर्ण सुरक्षा समस्याओं का कारण बन सकती हैं, जिनमें शामिल हैं:

  • अनुबंध अपग्रेड जोखिम. कुछ अनुबंधों को तैनाती के बाद संशोधित करने योग्य बनाया गया है, ताकि विकास टीम किसी एप्लिकेशन को अपडेट और बेहतर बनाना जारी रख सके। हालांकि, यह जोखिम पेश करता है। अपग्रेड के परिणामस्वरूप नई कमजोरियां हो सकती हैं, या दुर्भावनापूर्ण अपग्रेड के मामले में उपयोगकर्ता के धन का कुल नुकसान हो सकता है।
  • री-एंट्रेंसी (Re-entrancy), जहां अनुबंध A अपनी आंतरिक स्थिति को अपडेट करने से पहले बाहरी अनुबंध B को कॉल करता है, और अनुबंध B पहली कॉल समाप्त होने से पहले मूल अनुबंध A को वापस कॉल करता है।
  • बाहरी लाइब्रेरी का असुरक्षित उपयोग, जहां एक अनुबंध एक बाहरी लाइब्रेरी को कॉल करता है जो बिना ऑडिट की गई, दुर्भावनापूर्ण या अपग्रेड करने योग्य हो सकती है।
  • बिना ऑडिट किए गए घटक. हालांकि ऑडिटिंग और मानक लाइब्रेरी के उपयोग में सुधार हुआ है, डेवलपर्स कभी-कभी अपने एप्लिकेशनों में बिना ऑडिट किए गए घटकों पर निर्भर करते हैं।
  • एक्सेस नियंत्रण विफलताएं, जहां अनुमतियों को गलत तरीके से कॉन्फ़िगर किया गया है या बहुत व्यापक रूप से परिभाषित किया गया है, जिससे हमलावरों को दुर्भावनापूर्ण कार्रवाई करने की अनुमति मिलती है।
  • अनधिकृत एक्सेस, जहां अनुबंध को नियंत्रित करने में सक्षम एक निजी कुंजी किसी दुर्भावनापूर्ण अभिनेता द्वारा प्राप्त की जाती है।
  • ब्रिज और क्रॉसचेन इंटरैक्शन. ब्रिज और क्रॉसचेन प्रोटोकॉल अतिरिक्त जटिलता पेश करते हैं, और हमलावर क्रॉसचेन संदेशों को कैसे पारित या मान्य किया जाता है, इसमें कमजोरियों का फायदा उठा सकते हैं।
  • बाहरी रूप से स्वामित्व वाले खाते (EOA) का प्रत्यायोजन या हस्ताक्षर का दुरुपयोग. दुर्भावनापूर्ण एप्लिकेशन उपयोगकर्ताओं को अपने खाते का पूर्ण प्रत्यायोजन किसी अन्य पार्टी को सौंपने के लिए हस्ताक्षर करने के लिए धोखा दे सकते हैं, जिससे चोरी संभव हो जाती है। दुर्भावनापूर्ण एप्लिकेशन उपयोगकर्ता के हस्ताक्षरित संदेशों का अप्रत्याशित तरीकों से भी उपयोग कर सकते हैं, उदा., रीप्ले हमले में।
  • AI कोड जनरेशन या स्वचालित रीफैक्टरिंग टूल द्वारा पेश किए गए बग का उभरता हुआ जोखिम.

2.2 डेवलपर अनुभव, टूलिंग और प्रोग्रामिंग भाषाएं

डेवलपर की त्रुटि के परिणामस्वरूप तैनात कोड में कमजोरियां आ जाती हैं। बेहतर डेवलपर टूलिंग ने सुरक्षित स्मार्ट अनुबंधों को तैनात करना काफी आसान बना दिया है। हालांकि, समस्याएं बनी हुई हैं।

  • लोकप्रिय फ्रेमवर्क में सुरक्षित डिफ़ॉल्ट की कमी. कुछ टूल सुरक्षा पर लचीलेपन या गति को प्राथमिकता देते हैं, approve() फ़ंक्शन में असीमित टोकन स्वीकृति जैसे असुरक्षित डिफ़ॉल्ट सेट करते हैं, या डिफ़ॉल्ट रूप से एक्सेस नियंत्रण पैटर्न शामिल करने में विफल रहते हैं।
  • उन्नत परिचालन नियंत्रणों के लिए कस्टम कोड. जटिल परिचालन आवश्यकताओं वाले संस्थागत उपयोगकर्ताओं को अक्सर खरोंच से आवश्यक सुविधाओं का निर्माण करना पड़ता है, जिससे कमजोरियों का जोखिम बढ़ जाता है। उन्नत सुरक्षा वर्कफ़्लो के लिए मानकीकृत सुरक्षित घटकों या फ्रेमवर्क की कमी है।
  • असंगत परीक्षण कवरेज टूलिंग स्टैक में, साथ ही फ़ज़िंग या इनवेरिएंट चेकिंग जैसी सिद्ध तकनीकों का उपयोग करने के आसपास मानदंडों की कमी।
  • औपचारिक सत्यापन विधियों को कम अपनाना. औपचारिक सत्यापन तकनीकें शक्तिशाली हैं, लेकिन वे जटिल, महंगी हैं, विशेष डोमेन विशेषज्ञता की आवश्यकता होती है, और मानक डेवलपर वर्कफ़्लो में अच्छी तरह से एकीकृत नहीं होती हैं, जहां उनका उपयोग विनिर्देश चरण में सुरक्षा को सत्यापित करने के लिए सॉफ़्टवेयर के उत्पादन में बहुत पहले किया जा सकता है।
  • अनुबंध सत्यापन से संबंधित समस्याएं. उपयोगकर्ता और डेवलपर आसानी से तैनात अनुबंधों की विश्वसनीयता, उनके सुरक्षा सत्यापन की सीमा (उदा., कोड ऑडिट), या अव्यक्त जोखिमों की उपस्थिति का आकलन नहीं कर सकते हैं। हालांकि इस उद्देश्य के लिए समाधान मौजूद हैं, कई समस्याएं बनी हुई हैं। इन मुद्दों को संबोधित करने वाले टूलिंग को व्यापक रूप से नहीं अपनाया गया है, दृष्टिकोणों को एकीकृत करने वाले मानक खंडित बने हुए हैं, और कुछ मौजूदा सेवाएं स्वयं केंद्रीकृत निर्भरताएं हैं।
  • कंपाइलर जोखिम. कंपाइलर (वह सॉफ़्टवेयर जो Solidity जैसे मानव-पठनीय कोड को EVM द्वारा उपयोग किए जाने वाले बाइटकोड में परिवर्तित करता है) में खामियां हो सकती हैं जो स्मार्ट अनुबंधों के तैनात होने से पहले उनमें त्रुटियां ला सकती हैं। आज इथेरियम इकोसिस्टम मुख्य रूप से solc कंपाइलर पर निर्भर करता है, जिसका अर्थ है कि एक बग का व्यापक प्रभाव हो सकता है।
  • प्रोग्रामिंग भाषा विविधता और गहराई. हालांकि Solidity पर एक गहरा टूलिंग इकोसिस्टम बनाया गया है, कुछ डेवलपर अन्य प्रोग्रामिंग भाषाओं में पाई जाने वाली अधिक आधुनिक सुरक्षा सुविधाओं, जैसे मेमोरी सुरक्षा, को चाहते हैं।

2.3 ऑनचेन कोड का जोखिम मूल्यांकन

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

3. इन्फ्रास्ट्रक्चर और क्लाउड सुरक्षा

इथेरियम के कई उपयोग विभिन्न प्रकार के बुनियादी ढांचा प्रदाताओं पर निर्भर करते हैं, जिनमें क्रिप्टो-विशिष्ट बुनियादी ढांचा (जैसे, लेयर 2 (l2) चेन, RPC प्रदाता) और पारंपरिक क्लाउड और इंटरनेट इंफ्रा (जैसे, AWS, CDN, DNS) दोनों शामिल हैं।

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

3.1 लेयर 2 (l2) चेन

लेयर 2 (l2) चेन (L2s) इथेरियम के विस्तार के रूप में काम करती हैं, जो इथेरियम मेननेट की कुछ विशिष्ट सुरक्षा गारंटियों (उनके विशिष्ट डिज़ाइन के आधार पर) को बनाए रखते हुए तेज़ और कम शुल्क वाले वातावरण को सक्षम करती हैं। हालांकि, उनके पास अपनी अलग हमले की सतहें भी हैं जिनमें शामिल हैं:

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

L2 के प्रदर्शन और सुरक्षा का मूल्यांकन और तुलना करने वाले विस्तृत फ्रेमवर्क और मॉनिटरिंग डैशबोर्ड के लिए L2BEAT (opens in a new tab) देखें।

3.2 RPC और नोड बुनियादी ढांचा

इथेरियम एप्लिकेशन RPC एक्सेस, API और नोड सेवाओं के लिए कम संख्या में इंफ्रा प्रदाताओं पर निर्भर करते हैं। इसमें क्रिप्टो-विशिष्ट इंफ्रा प्रदाता, साथ ही पारंपरिक क्लाउड सेवाएं शामिल हैं जिनका उपयोग आमतौर पर नोड्स को होस्ट करने के लिए किया जाता है (जैसे, AWS, Cloudflare, Hetzner)।

यदि ये इंफ्रा प्रदाता ऑफ़लाइन हो जाते हैं या एक्सेस को सेंसर या धीमा करने का प्रयास करते हैं, तो कई उपयोगकर्ताओं को उनके वॉलेट या एप्लिकेशन के माध्यम से इथेरियम तक पहुंचने से रोका जा सकता है, जब तक कि वे एक नए RPC या अन्य इंफ्रा प्रदाता पर माइग्रेट करने में सक्षम न हों। इनमें से कुछ प्रदाताओं ने पहले ब्लॉकचेन गतिविधि से जुड़े खातों को निलंबित या बंद कर दिया है, जिससे विकेंद्रीकृत एप्लिकेशनों के लिए उनकी दीर्घकालिक विश्वसनीयता के बारे में चिंताएं पैदा हुई हैं।

3.3 DNS स्तर की कमजोरियां

डोमेन नेम सिस्टम (DNS) इंटरनेट की एक मूलभूत लेयर है, लेकिन यह केंद्रीकृत भी है और इससे समझौता किया जा सकता है। कई उपयोगकर्ता वेब डोमेन के माध्यम से ऐप एक्सेस करते हैं, जो निम्न के प्रति संवेदनशील हैं:

  • DNS हाईजैकिंग जहां एक हमलावर दुर्भावनापूर्ण गलत फ्रंटएंड डालता है।
  • डोमेन जब्ती, जहां कोई सरकार या रजिस्ट्रार डोमेन को जब्त कर सकता है।
  • मिलते-जुलते डोमेन के माध्यम से फ़िशिंग, जहां हमलावर उपयोगकर्ताओं को भ्रमित करने के लिए लगभग समान नाम पंजीकृत करते हैं।

3.4 सॉफ़्टवेयर आपूर्ति श्रृंखला और लाइब्रेरी

इथेरियम डेवलपर ओपन-सोर्स लाइब्रेरी पर निर्भर करते हैं, जिन्हें अक्सर सीधे npm, crates.io, या GitHub जैसी सेवाओं से लिया जाता है। यदि इन लाइब्रेरी से समझौता किया जाता है, तो वे निम्न जैसे हमलों के लिए एक माध्यम बन सकती हैं:

  • दुर्भावनापूर्ण पैकेज इंजेक्शन, जहां हमलावर व्यापक रूप से उपयोग किए जाने वाले पैकेज से समझौता करते हैं या समान नाम से कोई पैकेज प्रकाशित करते हैं
  • हाईजैक की गई निर्भरताएं (Dependencies), जहां मेंटेनर किसी प्रोजेक्ट से नियंत्रण खो देते हैं और एक दुर्भावनापूर्ण कर्ता हानिकारक कोड डाल देता है
  • डेवलपर समझौता, जहां इंस्टॉल किए गए पैकेज में ऐसा कोड होता है जो हमलावर को डेवलपर के कंप्यूटर पर नियंत्रण देता है।

3.5 फ्रंटएंड डिलीवरी सेवाएं और संबंधित जोखिम

कई इथेरियम एप्लिकेशन कंटेंट डिलीवरी नेटवर्क (CDN) या क्लाउड-आधारित होस्टिंग प्लेटफ़ॉर्म (जैसे, Vercel, Netlify, Cloudflare) के माध्यम से अपने फ्रंटएंड प्रदान करते हैं। यदि इन सेवाओं से समझौता किया जाता है, तो वे दुर्भावनापूर्ण JavaScript इंजेक्शन जैसे हमलों के लिए एक माध्यम बन सकती हैं, जहां हमलावर उपयोगकर्ताओं को एक बदला हुआ फ्रंटएंड प्रदान करते हैं।

3.6 इंटरनेट सेवा प्रदाता स्तर की सेंसरशिप

इंटरनेट सेवा प्रदाता (ISP) या राष्ट्र राज्य इथेरियम तक पहुंच को सेंसर करने के लिए अंतर्निहित इंटरनेट बुनियादी ढांचे के नियंत्रण का उपयोग कर सकते हैं। उदाहरण के लिए, इन हमलों में शामिल हो सकते हैं:

  • सामान्य इथेरियम पोर्ट पर ट्रैफ़िक को ब्लॉक करना या धीमा करना
  • इथेरियम से संबंधित सेवाओं को रिज़ॉल्व करने वाले DNS अनुरोधों को फ़िल्टर करना
  • ज्ञात इथेरियम नोड्स के खिलाफ जियोफेंसिंग या IP प्रतिबंध
  • इथेरियम प्रोटोकॉल से संबंधित ट्रैफ़िक की पहचान करने और उसे सेंसर करने के लिए डीप पैकेट इंस्पेक्शन

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

4. सर्वसम्मति प्रोटोकॉल

इथेरियम का सर्वसम्मति प्रोटोकॉल यह परिभाषित करता है कि नेटवर्क इथेरियम ब्लॉकचेन की स्थिति को कैसे अपडेट करता है और समझौते पर कैसे पहुंचता है। यह प्रोटोकॉल इस बात की नींव है कि इथेरियम को धन, वित्त, पहचान, शासन, वास्तविक दुनिया की संपत्तियां (RWA), और बहुत कुछ के लिए एक भरोसेमंद प्लेटफ़ॉर्म क्या बनाता है।

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

4.1 सर्वसम्मति की नाजुकता और रिकवरी जोखिम

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

4.2 क्लाइंट विविधता

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

4.3 स्टेकिंग केंद्रीकरण और पूल प्रभुत्व

सत्यापक भार का एक महत्वपूर्ण हिस्सा लिक्विड स्टेकिंग प्रोटोकॉल, कस्टोडियल सेवाओं और बड़े नोड ऑपरेटरों में केंद्रित है। यह एकाग्रता निम्न जैसे जोखिमों को जन्म दे सकती है:

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

4.4 अपरिभाषित सामाजिक कटौती और समन्वय अंतराल

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

4.5 आर्थिक और गेम-थियोरेटिक हमले के वैक्टर

कई संभावित आर्थिक हमले के वैक्टरों का अभी भी कम अध्ययन किया गया है, जिनमें शामिल हैं:

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

4.6 क्वांटम जोखिम

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

क्वांटम-प्रतिरोधी क्रिप्टोग्राफी (जैसे, पोस्ट-क्वांटम हस्ताक्षर योजनाओं के माध्यम से) के लिए माइग्रेशन पथों को डिज़ाइन, परीक्षण और संभवतः उनकी आवश्यकता होने से वर्षों पहले प्रोटोकॉल में एम्बेड करने की आवश्यकता है। एथेरियम फाउंडेशन सहित इथेरियम इकोसिस्टम के संगठन सक्रिय रूप से इन विकल्पों की खोज कर रहे हैं और जोखिमों की निगरानी कर रहे हैं।

5. निगरानी, घटना प्रतिक्रिया और शमन

यहां तक कि एक आदर्श ब्लॉकचेन इकोसिस्टम में भी जोखिम, हमले और कमजोरियां होंगी। जब चीजें गलत हो जाती हैं, तो कम करने, पता लगाने और प्रतिक्रिया देने के लिए प्रभावी सिस्टम होने चाहिए। यहां चुनौतियों में शामिल हैं:

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

6. सामाजिक लेयर और शासन

इथेरियम की "सोशल लेयर" लोगों, संगठनों, कंपनियों, शासन प्रक्रियाओं और सांस्कृतिक मानदंडों के उस समूह को संदर्भित करती है जो इथेरियम इकोसिस्टम के व्यवहार को प्रभावित करते हैं। यह सोशल लेयर स्वयं कुछ हमलों या जोखिमों के प्रति संवेदनशील है, जो बाद में इथेरियम की सुरक्षा और विश्वसनीयता को प्रभावित कर सकते हैं।

ये जोखिम अधिक दीर्घकालिक उन्मुख होते हैं, और व्यक्तिगत उपयोगकर्ताओं या एप्लिकेशनों की सुरक्षा के बजाय समग्र रूप से इथेरियम से संबंधित होते हैं।

6.1 स्टेक केंद्रीकरण

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

  • फ़ोर्क पर समन्वय या उनका विरोध कर सकते हैं।
  • कुछ लेन-देन या अनुबंधों को सेंसर कर सकते हैं।
  • निकास या विरोध की धमकी देकर सामुदायिक सर्वसम्मति को कमजोर कर सकते हैं।

यदि यह चरम परिदृश्य होता है, तो इथेरियम समुदाय ने सुझाव दिया है कि "सामाजिक कटौती" इसका उत्तर हो सकता है। सामाजिक कटौती, दुर्व्यवहार करने वाले सत्यापकों की शक्ति पर नियंत्रण के रूप में, उनकी कटौती करने का निर्णय लेने के लिए ऑफचेन सामाजिक सर्वसम्मति का उपयोग है। लेकिन ऐसे उपायों को लागू करने के लिए कोई स्पष्ट मानदंड, प्रक्रियाएं या टूलिंग मौजूद नहीं हैं (अनुभाग 4.4 देखें)।

6.2 ऑफचेन संपत्ति केंद्रीकरण

इथेरियम बड़ी मात्रा में वास्तविक दुनिया की संपत्तियां (RWA) होस्ट करता है, जहां संपत्तियों को बैंक खातों या अन्य जमाओं में ऑफचेन रखा जाता है, जिनका फिर उन टोकन के माध्यम से ऑनचेन कारोबार किया जाता है जो ऑफचेन संपत्तियों पर दावे का प्रतिनिधित्व करते हैं। उदाहरण के लिए, कई बड़े स्टेबलकॉइन इसी तरह काम करते हैं।

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

6.3 विनियामक हमला या दबाव

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

6.4 शासन पर संगठनात्मक कब्ज़ा

इथेरियम की ओपन सोर्स शासन और विकास प्रक्रियाएं टीमों और कंपनियों के एक विविध और वैश्विक समूह द्वारा संचालित होती हैं जो कोर क्लाइंट सॉफ़्टवेयर, बुनियादी ढांचे और टूलिंग को बनाए रखते हैं।

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