सुरक्षा आव्हाने विहंगावलोकन

ब्लॉकचेनचे एक परिभाषित वैशिष्ट्य म्हणजे व्यवहारांचे अणू (atomic) स्वरूप: एकदा ब्लॉकचेनमध्ये अपडेट नोंदवले गेले की, हस्तक्षेप किंवा उलटफेर करण्याची कोणतीही संधी नसते. हे सुसंगतता आणि प्रोटोकॉल स्तरावरील सुरक्षेची मजबूत हमी देते, परंतु वापरकर्त्यांना वाढीव ऑपरेशनल धोक्यात आणते: एकच चूक, तडजोड केलेली की, किंवा घाईघाईने दिलेली मंजुरी अपरिवर्तनीय नुकसानास कारणीभूत ठरू शकते.

परिणामी, सुरक्षेचा मोठा भार वापरकर्त्यावर पडतो. इथेरियम सुरक्षितपणे वापरण्यासाठी, व्यक्ती आणि संस्थांनी सुरक्षितपणे की धारण करणे आणि व्यवस्थापित करणे, ऑनचेन ॲप्लिकेशन्सशी संवाद साधणे आणि मालमत्ता हस्तांतरित करण्यासाठी किंवा इथेरियमची स्थिती अपडेट करण्यासाठी व्यवहारांवर स्वाक्षरी करण्यासाठी त्यांच्या की वापरणे आवश्यक आहे.

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

1.1 की व्यवस्थापन

अनेक वापरकर्ते क्रिप्टोग्राफिक की सुरक्षितपणे व्यवस्थापित करण्यासाठी सुसज्ज नाहीत.

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

हार्डवेअर वॉलेट्स हा एक पर्याय आहे, जो वापरकर्त्यांना विशेष उद्देशाच्या भौतिक उपकरणामध्ये साठवलेली क्रिप्टोग्राफिक की व्यवस्थापित करण्यास सक्षम करतो. तथापि, हार्डवेअर वॉलेट्सच्या स्वतःच्या त्रुटी आणि हल्ल्याचे पृष्ठभाग (attack surface) आहेत. हार्डवेअर वॉलेट्स हरवले, खराब झाले किंवा चोरीला जाऊ शकतात. अनेक हार्डवेअर वॉलेट्स मुक्त स्रोत नसतात आणि त्यांच्या पुरवठा साखळ्या अपारदर्शक असू शकतात, ज्यामुळे पुरवठा साखळी हल्ल्याचा धोका वाढतो जिथे तडजोड केलेली उपकरणे बाजारात विकली जातात.

की सॉफ्टवेअर किंवा हार्डवेअर वॉलेटमध्ये व्यवस्थापित केल्या जात असल्या तरी, जेव्हा भौतिक चोरी किंवा हल्ल्याद्वारे तडजोड केली जाऊ शकते तेव्हा अनेक वापरकर्ते सेल्फ कस्टडीबद्दल (स्वतःच्या ताब्याबद्दल) साहजिकच घाबरलेले असतात.

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

1.2 ब्लाइंड स्वाक्षरी करणे आणि व्यवहाराची अनिश्चितता

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

1.3 मंजुरी आणि परवानगी व्यवस्थापन

अनेक इथेरियम ॲप्लिकेशन्समध्ये, वापरकर्त्यांनी सामान्य वापराचा भाग म्हणून अंतर्निहित ॲप्लिकेशनला काही परवानग्या देणे सामान्य आहे. उदाहरणार्थ, एखादा वापरकर्ता युनिस्वॅप सारख्या विकेंद्रित एक्सचेंजला ETH साठी त्यांची अदलाबदल करण्यासाठी त्यांचे टोकन्स हलवण्याची परवानगी देऊ शकतो.

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

यामुळे वापरकर्ते दुर्भावनापूर्ण ॲप्स किंवा तडजोड केलेल्या फ्रंटएंड्सच्या संपर्कात येऊ शकतात, कारण अनेक वापरकर्त्यांसाठी डीफॉल्ट पॅटर्न अमर्यादित मंजुरी देण्याचा असतो ज्याचा वापर त्यांचा निधी काढून घेण्यासाठी केला जाऊ शकतो. जरी वापरकर्त्याने कायदेशीर स्मार्ट कॉन्ट्रॅक्टला मंजुरी दिली असली, तरी मंजुरी कायम असताना त्या कॉन्ट्रॅक्टशी नंतर तडजोड केली गेली, तर तडजोड केलेले कॉन्ट्रॅक्ट वापरकर्त्याचा निधी काढून घेऊ शकते.

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

1.4 तडजोड केलेले वेब इंटरफेस

बहुतेक वापरकर्ते थेट स्मार्ट कॉन्ट्रॅक्टशी संवाद साधत नाहीत, तर त्यांच्या मोबाइल डिव्हाइस किंवा वेब ब्राउझरद्वारे वेब इंटरफेसच्या माध्यमातून संवाद साधतात.

हे फ्रंटएंड्स DNS हायजॅकिंग, दुर्भावनापूर्ण javascript इंजेक्शन, असुरक्षित होस्टिंग किंवा विविध तृतीय पक्ष अवलंबित्वांसारख्या परिचित माध्यमांद्वारे हल्ल्यास असुरक्षित असू शकतात. तडजोड केलेला ॲप UX सर्व प्रकारच्या वापरकर्त्यांना दुर्भावनापूर्ण स्मार्ट कॉन्ट्रॅक्ट्सकडे पुनर्निर्देशित करू शकतो किंवा त्यांना दिशाभूल करणाऱ्या व्यवहारांवर स्वाक्षरी करण्यास प्रवृत्त करू शकतो.

1.5 गोपनीयता

गोपनीयता सर्व प्रकारच्या वापरकर्त्यांसाठी सुरक्षा धोके कमी करू शकते किंवा वाढवू शकते.

कमकुवत गोपनीयता संरक्षणे वैयक्तिक वापरकर्त्यांना फिशिंग, शोषण, घोटाळे किंवा शारीरिक हल्ल्यांसारख्या विविध लक्ष्यित धोक्यांसमोर उघड करतात. अनेक सामान्य UX पॅटर्न वापरकर्त्यांना उघड करतात, उदा., पत्ता पुनर्वापर, KYC डेटा आणि इतर मेटाडेटा लीक.

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

1.6 विखंडन

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

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

इथेरियमच्या इतिहासामध्ये स्मार्ट कॉन्ट्रॅक्ट सुरक्षेत आमूलाग्र सुधारणा झाली आहे. DAO हॅक सारख्या सुरुवातीच्या सुरक्षा घटनांनी इकोसिस्टमला व्यावसायिक बनवण्यासाठी आणि सॉफ्टवेअर जीवनचक्रामध्ये सुरक्षेचे उपाय सुधारण्यासाठी प्रेरित केले ज्यामुळे कोड ऑनचेन प्रस्थापित केला जातो. प्रमुख प्रगतीमध्ये हे समाविष्ट आहे:

• सुरक्षा ऑडिटिंग ही एक मानक प्रथा बनली, ज्यामध्ये अनेक सुरक्षा कंपन्यांनी इकोसिस्टममध्ये प्रवेश केला आणि कौशल्य विकसित केले.
• टूलिंग, चाचणी आणि स्टॅटिक ॲनालिसिस प्रणाली परिपक्व झाल्या आणि मानक प्रथा बनल्या.
• पूर्व-ऑडिट केलेल्या सामान्य घटकांच्या लायब्ररींनी डेव्हलपर्सना डीफॉल्टनुसार सुरक्षित बिल्डिंग ब्लॉक्स दिले.
• औपचारिक पडताळणी तंत्रे स्वीकारली गेली, विशेषतः ब्रिजेस, स्टेकिंग प्रणाली आणि उच्च मूल्याच्या कॉन्ट्रॅक्ट्ससाठी.
• इकोसिस्टमची सुरक्षा संस्कृती आणि सर्वोत्तम पद्धती सुधारल्या.
• ॲप स्तर मजबूत करणाऱ्या महत्त्वपूर्ण बाउन्टी प्रोग्राम्सची निर्मिती.

तथापि, या क्षेत्रात अजूनही कमकुवतपणा आणि सुधारणेला वाव आहे.

2.1 कॉन्ट्रॅक्ट असुरक्षा

स्मार्ट कॉन्ट्रॅक्ट सुरक्षेतील प्रगती असूनही, अजूनही अशा असुरक्षा आहेत ज्यामुळे महत्त्वपूर्ण सुरक्षा समस्या उद्भवू शकतात, ज्यामध्ये हे समाविष्ट आहे:

• कॉन्ट्रॅक्ट अपग्रेडचा धोका. काही कॉन्ट्रॅक्ट्स प्रस्थापनेनंतर सुधारण्यायोग्य असण्यासाठी डिझाइन केलेले असतात, जेणेकरून डेव्हलपमेंट टीमला ॲप्लिकेशन अपडेट करणे आणि सुधारणे सुरू ठेवता येईल. तथापि, यामुळे धोके निर्माण होतात. अपग्रेड्समुळे नवीन असुरक्षा निर्माण होऊ शकतात, किंवा दुर्भावनापूर्ण अपग्रेडच्या बाबतीत वापरकर्त्याच्या निधीचे संपूर्ण नुकसान होऊ शकते.
• री-एन्ट्रन्सी, जिथे कॉन्ट्रॅक्ट A स्वतःची अंतर्गत स्थिती अपडेट करण्यापूर्वी बाह्य कॉन्ट्रॅक्ट B ला कॉल करते, आणि पहिला कॉल पूर्ण होण्यापूर्वी कॉन्ट्रॅक्ट B मूळ कॉन्ट्रॅक्ट A ला परत कॉल करते.
• बाह्य लायब्ररींचा असुरक्षित वापर, जिथे कॉन्ट्रॅक्ट अशा बाह्य लायब्ररीला कॉल करते जी ऑडिट न केलेली, दुर्भावनापूर्ण किंवा अपग्रेड करण्यायोग्य असू शकते.
• ऑडिट न केलेले घटक. ऑडिटिंग आणि मानक लायब्ररींचा वापर सुधारला असला तरी, डेव्हलपर कधीकधी त्यांच्या ॲप्लिकेशन्समध्ये ऑडिट न केलेल्या घटकांवर अवलंबून असतात.
• ॲक्सेस कंट्रोलमधील अपयश, जिथे परवानग्या चुकीच्या पद्धतीने कॉन्फिगर केल्या जातात किंवा खूप व्यापकपणे परिभाषित केल्या जातात, ज्यामुळे हल्लेखोरांना दुर्भावनापूर्ण कृती करण्याची परवानगी मिळते.
• अनधिकृत प्रवेश, जिथे कॉन्ट्रॅक्ट नियंत्रित करण्यास सक्षम असलेली खाजगी की एखाद्या दुर्भावनापूर्ण घटकाद्वारे मिळवली जाते.
• ब्रिजेस आणि क्रॉसचेन संवाद. ब्रिजेस आणि क्रॉसचेन प्रोटोकॉल्स अतिरिक्त गुंतागुंत निर्माण करतात, आणि क्रॉसचेन संदेश कसे पास केले जातात किंवा प्रमाणित केले जातात यामधील कमकुवतपणाचा हल्लेखोर फायदा घेऊ शकतात.
• बाह्य मालकीचे खाते (EOA) अधिकारप्रदान किंवा स्वाक्षरीचा गैरवापर. दुर्भावनापूर्ण ॲप्लिकेशन्स वापरकर्त्यांना त्यांच्या खात्याचे संपूर्ण अधिकारप्रदान दुसऱ्या पक्षाला देण्यावर स्वाक्षरी करण्यास फसवू शकतात, ज्यामुळे चोरी शक्य होते. दुर्भावनापूर्ण ॲप्लिकेशन्स वापरकर्त्याच्या स्वाक्षरी केलेल्या संदेशांचा अनपेक्षित मार्गांनी वापर करू शकतात, उदा., रिप्ले हल्ल्यामध्ये.
• AI कोड जनरेशन किंवा स्वयंचलित रिफॅक्टरिंग टूल्सद्वारे सादर केलेल्या बग्सचा उदयोन्मुख धोका.

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

डेव्हलपरच्या चुकीचा परिणाम म्हणून प्रस्थापित केलेल्या कोडमध्ये असुरक्षा निर्माण होतात. सुधारित डेव्हलपर टूलिंगमुळे सुरक्षित स्मार्ट कॉन्ट्रॅक्ट्स प्रस्थापित करणे लक्षणीयरीत्या सोपे झाले आहे. तथापि, समस्या कायम आहेत.

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

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

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

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

3.1 स्तर २ (l2) चेन्स

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

• मल्टी-हॉप ब्रिज्ड मालमत्तेची गुंतागुंत. जेव्हा मालमत्ता स्तर १ (l1) आणि एकाधिक स्तर २ (l2) दरम्यान प्रवास करते, तेव्हा ती कॉन्ट्रॅक्ट्सच्या अनेक संचांच्या संपर्कात येते जे सर्व सुरक्षित असणे आवश्यक आहे. स्तर २ (l2) चेन्समधील विसंगत अकाउंटिंग किंवा आउटेजमुळे असुरक्षा निर्माण होऊ शकतात ज्याचा फायदा हल्लेखोर घेऊ शकतात.
• स्थिती अद्यतनांची अचूकता लागू करण्यासाठी रोलअप स्तर २ (l2) सिद्ध प्रणालींवर अवलंबून असतात. या प्रणालींमधील बग किंवा चुकीच्या कॉन्फिगरेशनमुळे अंतिम प्रक्रियेत अडथळा येऊ शकतो किंवा ती रोखली जाऊ शकते, किंवा चुकीच्या स्थिती अद्यतनांना अंतिम रूप देण्याची परवानगी मिळू शकते ज्यामुळे वापरकर्त्यांच्या निधीचे नुकसान होऊ शकते.
• सुरक्षा परिषदा हे की धारकांचे गट आहेत जे स्तर २ (l2) सॉफ्टवेअर अपग्रेड करण्यासाठी किंवा विशिष्ट आणीबाणीला प्रतिसाद देण्यासाठी "बॅकअप" यंत्रणा म्हणून काम करतात. सुरक्षा परिषदा स्वतःच धोके निर्माण करतात, कारण सदस्यांमधील तडजोड किंवा संगनमतामुळे वापरकर्त्यांचा निधी धोक्यात येऊ शकतो किंवा मालमत्ता गोठवली जाऊ शकते.

स्तर २ (l2) कामगिरी आणि सुरक्षिततेचे मूल्यांकन आणि तुलना करणाऱ्या तपशीलवार फ्रेमवर्क आणि मॉनिटरिंग डॅशबोर्डसाठी L2BEAT (opens in a new tab) पहा.

3.2 RPC आणि नोड पायाभूत सुविधा

इथेरियम ॲप्लिकेशन्स RPC ॲक्सेस, APIs आणि नोड सेवांसाठी थोड्या संख्येने असलेल्या पायाभूत सुविधा प्रदात्यांवर अवलंबून असतात. यामध्ये क्रिप्टो-विशिष्ट पायाभूत सुविधा प्रदाते, तसेच नोड्स होस्ट करण्यासाठी सामान्यतः वापरल्या जाणाऱ्या पारंपारिक क्लाउड सेवांचा (उदा. AWS, Cloudflare, Hetzner) समावेश आहे.

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

3.3 DNS स्तरावरील असुरक्षा

डोमेन नेम सिस्टीम (DNS) हा इंटरनेटचा एक मूलभूत स्तर आहे, परंतु तो केंद्रीकृत देखील आहे आणि त्याच्याशी तडजोड केली जाऊ शकते. अनेक वापरकर्ते वेब डोमेन्सद्वारे ॲप्समध्ये प्रवेश करतात, जे खालील गोष्टींना बळी पडू शकतात:

• DNS हायजॅकिंग जिथे हल्लेखोर एक दुर्भावनापूर्ण खोटा फ्रंटएंड समाविष्ट करतो.
• डोमेन जप्ती, जिथे सरकार किंवा निबंधक डोमेन्स जप्त करू शकतात.
• सारख्या दिसणाऱ्या डोमेन्सद्वारे फिशिंग, जिथे हल्लेखोर वापरकर्त्यांना गोंधळात टाकण्यासाठी जवळजवळ एकसारखी नावे नोंदवतात.

3.4 सॉफ्टवेअर पुरवठा साखळी आणि लायब्ररी

इथेरियम डेव्हलपर्स ओपन-सोर्स लायब्ररीवर अवलंबून असतात, जे अनेकदा npm, crates.io किंवा GitHub सारख्या सेवांमधून थेट घेतले जातात. जर या लायब्ररीशी तडजोड केली गेली, तर ते खालीलसारख्या हल्ल्यांसाठी एक माध्यम बनू शकतात:

• दुर्भावनापूर्ण पॅकेज इंजेक्शन, जिथे हल्लेखोर मोठ्या प्रमाणावर वापरल्या जाणाऱ्या पॅकेजशी तडजोड करतात किंवा तत्सम नावाने एखादे प्रकाशित करतात
• हायजॅक केलेल्या डिपेंडन्सीज, जिथे देखभालकर्ते प्रकल्पावरील नियंत्रण गमावतात आणि एखादा दुर्भावनापूर्ण अभिनेता हानिकारक कोड समाविष्ट करतो
• डेव्हलपर तडजोड, जिथे स्थापित केलेल्या पॅकेजेसमध्ये असा कोड असतो जो हल्लेखोराला डेव्हलपरच्या संगणकावर नियंत्रण देतो.

3.5 फ्रंटएंड वितरण सेवा आणि संबंधित धोके

अनेक इथेरियम ॲप्लिकेशन्स त्यांचे फ्रंटएंड्स कंटेंट डिलिव्हरी नेटवर्क (CDN) किंवा क्लाउड-आधारित होस्टिंग प्लॅटफॉर्म (उदा. Vercel, Netlify, Cloudflare) द्वारे सर्व्ह करतात. जर या सेवांशी तडजोड केली गेली, तर ते दुर्भावनापूर्ण JavaScript इंजेक्शनसारख्या हल्ल्यांसाठी एक माध्यम बनू शकतात, जिथे हल्लेखोर वापरकर्त्यांना बदललेला फ्रंटएंड सर्व्ह करतात.

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

इंटरनेट सेवा प्रदाते (ISPs) किंवा राष्ट्रे इथेरियमचा ॲक्सेस सेन्सॉर करण्यासाठी अंतर्निहित इंटरनेट पायाभूत सुविधांच्या नियंत्रणाचा वापर करू शकतात. उदाहरणार्थ, या हल्ल्यांमध्ये खालील गोष्टींचा समावेश असू शकतो:

• सामान्य इथेरियम पोर्ट्सवरील ट्रॅफिक ब्लॉक करणे किंवा मर्यादित करणे
• इथेरियम संबंधित सेवांचे निराकरण करणाऱ्या DNS विनंत्या फिल्टर करणे
• ज्ञात इथेरियम नोड्स विरुद्ध जिओफेन्सिंग किंवा IP बंदी
• इथेरियम प्रोटोकॉल संबंधित ट्रॅफिक ओळखण्यासाठी आणि सेन्सॉर करण्यासाठी डीप पॅकेट इन्स्पेक्शन

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

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

4.1 एकमत ठिसूळपणा आणि पुनर्प्राप्तीचे धोके

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

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

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

4.3 स्टेकिंग केंद्रीकरण आणि पूल वर्चस्व

प्रमाणक वजनाचे लक्षणीय प्रमाण लिक्विड स्टेकिंग प्रोटोकॉल्स, कस्टोडियल सेवा आणि मोठ्या नोड ऑपरेटर्समध्ये केंद्रित आहे. या केंद्रीकरणामुळे खालीलसारखे धोके निर्माण होऊ शकतात:

• प्रशासन कॅप्चर किंवा प्रभाव. जर मोठ्या प्रमाणात स्टेक नियंत्रित करणाऱ्या संस्थांनी (किंवा त्या संस्थांवर प्रभाव टाकण्याची कायदेशीर शक्ती असलेल्या संस्थांनी) एकत्र समन्वय साधला, तर कोणते ब्लॉक्स प्रस्तावित आणि प्रमाणित केले जातात यावर त्यांचा मोठा प्रभाव असू शकतो, संभाव्यतः वापरकर्त्यांना सेन्सॉर करणे किंवा प्रोटोकॉल अपग्रेड्सवर प्रभाव टाकणे.
• क्लायंट निवड आणि पायाभूत सुविधा सेटअपमध्ये एकजिनसीपणा, ज्यामुळे परस्परसंबंधित अपयशाचे धोके वाढू शकतात.

4.4 अनिर्दिष्ट सामाजिक दंड आणि समन्वयातील तफावत

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

4.5 आर्थिक आणि गेम-थिओरेटिक हल्ला वेक्टर्स

अनेक संभाव्य आर्थिक हल्ला वेक्टर्सचा अभ्यास अपुरा राहिला आहे, ज्यामध्ये खालील गोष्टींचा समावेश आहे:

• ग्रीफिंग हल्ले किंवा स्लॅश ग्रीफिंग. प्रमाणकांना त्यांच्या स्वतःच्या चुकांमुळे नव्हे तर केवळ इतरांना हानी पोहोचवण्याच्या उद्देशाने केलेल्या विरोधी वर्तनामुळे खर्च किंवा स्लॅशिंग दंड सहन करावा लागू शकतो, ज्याचा निव्वळ खर्च हल्लेखोराला होतो.
• धोरणात्मक निर्गमन किंवा वेळेवर निष्क्रियता. नफा वाढवण्यासाठी किंवा कमीतकमी दंडासह एकमत विस्कळीत करण्यासाठी प्रमाणक जाणीवपूर्वक ऑफलाइन जाऊ शकतात किंवा गंभीर वेळी निर्गमन करू शकतात.
• प्रमाणक किंवा रिलेजमध्ये संगनमत. प्रमाणकांमध्ये किंवा रिलेज आणि प्रमाणकांमध्ये समन्वयात्मक वर्तनामुळे विकेंद्रीकरण कमी होऊ शकते किंवा MEV काढले जाऊ शकते.
• MEV, प्रस्तावक-निर्माता विभाजन (PBS), किंवा लिक्विड स्टेकिंग डिझाइनमधील एज-केस प्रोत्साहनांचे शोषण. अभिनेते मोठ्या प्रमाणावर बक्षिसे मिळवण्यासाठी दुर्मिळ प्रोटोकॉल परिस्थितींमध्ये फेरफार करू शकतात.

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

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

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

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

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

हे धोके अधिक दीर्घकालीन-देणारं असतात, आणि वैयक्तिक वापरकर्ते किंवा ॲप्लिकेशन्सच्या सुरक्षिततेऐवजी संपूर्ण इथेरियमशी संबंधित असतात.

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

मोठ्या प्रमाणातील स्टेकचे केंद्रीकरण संपूर्ण इथेरियमसाठी धोके निर्माण करू शकते जर तो स्टेक नियंत्रित करणाऱ्या संस्थांनी संगनमत करण्याचे ठरवले.
हे आर्थिक केंद्रीकरण सामाजिक प्रशासन कॅप्चरची क्षमता निर्माण करते. जर प्रमाणकांचा एक छोटा गट स्टेकच्या विशेष बहुमतावर नियंत्रण ठेवत असेल, तर ते:

• फोर्क्सवर समन्वय साधू शकतात किंवा विरोध करू शकतात.
• विशिष्ट व्यवहार किंवा कॉन्ट्रॅक्ट्स सेन्सॉर करू शकतात.
• निर्गमन किंवा विरोधाची धमकी देऊन समुदाय एकमत कमकुवत करू शकतात.

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

6.2 साखळीबाह्य मालमत्ता केंद्रीकरण

इथेरियम मोठ्या प्रमाणात वास्तविक जगातील मालमत्ता (RWA) होस्ट करते, जिथे मालमत्ता बँक खात्यांमध्ये किंवा इतर ठेवींमध्ये साखळीबाह्य ठेवली जाते, ज्याचा नंतर टोकन्सद्वारे ऑनचेन व्यापार केला जातो जे साखळीबाह्य मालमत्तेवरील दाव्याचे प्रतिनिधित्व करतात. उदाहरणार्थ, अनेक मोठे स्टेबलकॉइन्स या प्रकारे कार्य करतात.

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

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

सरकारे आणि नियामक इथेरियम स्टॅकच्या महत्त्वाच्या घटकांवर नियंत्रण ठेवणाऱ्या विविध संस्थांवर इथेरियम प्रोटोकॉल सेन्सॉर करण्यासाठी किंवा त्यात हस्तक्षेप करण्यासाठी दबाव आणू शकतात. इथेरियमच्या संस्थात्मक वापरकर्त्यांवरही या दबावांचा परिणाम होऊ शकतो, ज्याचे त्यांच्या वापरकर्त्यांसाठी पुढील परिणाम होतील (उदा. एखादी बँक जी नियामक बंदीमुळे काही विशिष्ट क्रिप्टो उत्पादने देऊ शकत नाही).

6.4 प्रशासनाचे संस्थात्मक कॅप्चर

इथेरियमचे ओपन सोर्स प्रशासन आणि विकास प्रक्रिया विविध आणि जागतिक स्तरावरील टीम्स आणि कंपन्यांच्या संचाद्वारे चालवल्या जातात जे मुख्य क्लायंट सॉफ्टवेअर, पायाभूत सुविधा आणि टूलिंगची देखभाल करतात.

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