सुरक्षा आव्हानांचा आढावा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5 गोपनीयता

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

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

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

1.6 विखंडन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 लेयर 2 चेन्स

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

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

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

3.2 RPC आणि नोड इन्फ्रास्ट्रक्चर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4 अपरिभाषित सामाजिक स्लॅशिंग आणि समन्वय अंतर

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

4.5 आर्थिक आणि गेम-सिद्धांतिक हल्ला वेक्टर

अनेक संभाव्य आर्थिक हल्ला वेक्टर कमी अभ्यासलेले आहेत, यासह:

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

4.6 क्वांटम धोका

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

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

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

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

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

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

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

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

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

6.2 ऑफचेन मालमत्ता केंद्रीकरण

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

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

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

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

6.4 शासनावर संस्थात्मक पकड

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

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