स्मार्ट कॉन्ट्रॅक्ट सुरक्षा

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

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

जरी आकडेवारी भिन्न असली तरी, असा अंदाज आहे की स्मार्ट कॉन्ट्रॅक्ट्समधील सुरक्षा दोषांमुळे चोरीला गेलेल्या किंवा गमावलेल्या मूल्याची एकूण रक्कम सहजपणे $1 अब्ज पेक्षा जास्त आहे. यामध्ये हाय-प्रोफाइल घटनांचा समावेश आहे, जसे की DAO हॅक (नवीन टॅबमध्ये उघडते) (3.6M ETH चोरीला गेले, ज्याची आजच्या किमतीनुसार किंमत $1B पेक्षा जास्त आहे), Parity मल्टीसिग वॉलेट हॅक (नवीन टॅबमध्ये उघडते) (हॅकर्समुळे $30M चे नुकसान), आणि Parity गोठवलेल्या वॉलेटची समस्या (नवीन टॅबमध्ये उघडते) ($300M पेक्षा जास्त किमतीचे ETH कायमचे लॉक झाले).

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

पूर्वापेक्षित गोष्टी

सुरक्षेचा विचार करण्यापूर्वी, तुम्ही स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंटच्या मूलभूत गोष्टींशी परिचित असल्याची खात्री करा.

सुरक्षित इथेरियम स्मार्ट कॉन्ट्रॅक्ट्स तयार करण्यासाठी मार्गदर्शक तत्त्वे

1. योग्य ॲक्सेस कंट्रोल्स डिझाइन करा

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

स्मार्ट कॉन्ट्रॅक्ट फंक्शन्सचा अनधिकृत वापर टाळण्यासाठी, सुरक्षित ॲक्सेस कंट्रोल्स लागू करणे आवश्यक आहे. ॲक्सेस कंट्रोल यंत्रणा स्मार्ट कॉन्ट्रॅक्टमधील विशिष्ट फंक्शन्स वापरण्याची क्षमता मंजूर संस्थांपुरती मर्यादित करतात, जसे की कॉन्ट्रॅक्ट व्यवस्थापित करण्यासाठी जबाबदार असलेली खाती. Ownable पॅटर्न आणि भूमिका-आधारित ॲक्सेस कंट्रोल (role-based control) हे दोन पॅटर्न स्मार्ट कॉन्ट्रॅक्ट्समध्ये ॲक्सेस कंट्रोल लागू करण्यासाठी उपयुक्त आहेत:

Ownable पॅटर्न

Ownable पॅटर्नमध्ये, कॉन्ट्रॅक्ट-निर्मिती प्रक्रियेदरम्यान एक पत्ता कॉन्ट्रॅक्टचा “मालक” म्हणून सेट केला जातो. संरक्षित फंक्शन्सना OnlyOwner मॉडिफायर नियुक्त केले जाते, जे फंक्शन कार्यान्वित करण्यापूर्वी कॉन्ट्रॅक्ट कॉल करणाऱ्या पत्त्याची ओळख प्रमाणित करते याची खात्री करते. कॉन्ट्रॅक्ट मालकाव्यतिरिक्त इतर पत्त्यांवरून संरक्षित फंक्शन्सना केलेले कॉल्स नेहमी पूर्ववत (revert) होतात, ज्यामुळे अवांछित ॲक्सेस टळतो.

भूमिका-आधारित ॲक्सेस कंट्रोल (Role-based access control)

स्मार्ट कॉन्ट्रॅक्टमध्ये एकच पत्ता Owner म्हणून नोंदणीकृत केल्याने केंद्रीकरणाचा धोका निर्माण होतो आणि ते सिंगल पॉइंट-ऑफ-फेल्युअर (single point-of-failure) दर्शवते. जर मालकाच्या खात्याच्या कीज (keys) तडजोड झाल्या, तर हल्लेखोर मालकीच्या कॉन्ट्रॅक्टवर हल्ला करू शकतात. म्हणूनच एकाधिक प्रशासकीय खात्यांसह भूमिका-आधारित ॲक्सेस कंट्रोल पॅटर्न वापरणे हा एक चांगला पर्याय असू शकतो.

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

बहु-स्वाक्षरी वॉलेट्स वापरणे

सुरक्षित ॲक्सेस कंट्रोल लागू करण्याचा दुसरा दृष्टीकोन म्हणजे कॉन्ट्रॅक्ट व्यवस्थापित करण्यासाठी बहु-स्वाक्षरी खाते वापरणे. नियमित EOA च्या विपरीत, बहु-स्वाक्षरी खाती एकाधिक संस्थांच्या मालकीची असतात आणि व्यवहार कार्यान्वित करण्यासाठी किमान खात्यांच्या स्वाक्षऱ्या आवश्यक असतात—उदा. 5 पैकी 3.

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

2. कॉन्ट्रॅक्ट ऑपरेशन्सचे रक्षण करण्यासाठी require(), assert(), आणि revert() स्टेटमेंट्स वापरा

नमूद केल्याप्रमाणे, एकदा ते ब्लॉकचेनवर प्रस्थापित (deployed) झाल्यानंतर कोणीही तुमच्या स्मार्ट कॉन्ट्रॅक्टमधील सार्वजनिक फंक्शन्स कॉल करू शकतो. बाह्य खाती कॉन्ट्रॅक्टशी कसा संवाद साधतील हे तुम्हाला आगाऊ माहीत नसल्यामुळे, प्रस्थापना करण्यापूर्वी समस्याप्रधान ऑपरेशन्सविरूद्ध अंतर्गत सुरक्षा उपाय लागू करणे आदर्श आहे. जर अंमलबजावणी विशिष्ट आवश्यकता पूर्ण करण्यात अयशस्वी ठरली तर अपवाद ट्रिगर करण्यासाठी आणि स्थिती बदल पूर्ववत करण्यासाठी तुम्ही require(), assert(), आणि revert() स्टेटमेंट्स वापरून स्मार्ट कॉन्ट्रॅक्ट्समध्ये योग्य वर्तन लागू करू शकता.

require(): require फंक्शन्सच्या सुरूवातीस परिभाषित केले जातात आणि कॉल केलेले फंक्शन कार्यान्वित होण्यापूर्वी पूर्वनिर्धारित अटी पूर्ण झाल्या आहेत याची खात्री करतात. फंक्शनसह पुढे जाण्यापूर्वी वापरकर्त्याचे इनपुट्स प्रमाणित करण्यासाठी, स्थिती व्हेरिएबल्स तपासण्यासाठी किंवा कॉल करणाऱ्या खात्याची ओळख प्रमाणित करण्यासाठी require स्टेटमेंट वापरले जाऊ शकते.

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

revert(): revert() चा वापर if-else स्टेटमेंटमध्ये केला जाऊ शकतो जो आवश्यक अट पूर्ण न झाल्यास अपवाद ट्रिगर करतो. खालील नमुना कॉन्ट्रॅक्ट फंक्शन्सच्या अंमलबजावणीचे रक्षण करण्यासाठी revert() वापरते:

pragma solidity ^0.8.4;

contract VendingMachine {
    address owner;
    error Unauthorized();
    function buy(uint amount) public payable {
        if (amount > msg.value / 2 ether)
            revert("Not enough Ether provided.");
        // खरेदी करा.
    }
    function withdraw() public {
        if (msg.sender != owner)
            revert Unauthorized();

        payable(msg.sender).transfer(address(this).balance);
    }
}

3. स्मार्ट कॉन्ट्रॅक्ट्सची चाचणी घ्या आणि कोडच्या अचूकतेची पडताळणी करा

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

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

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

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

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

4. तुमच्या कोडच्या स्वतंत्र पुनरावलोकनासाठी विचारा

तुमच्या कॉन्ट्रॅक्टची चाचणी घेतल्यानंतर, कोणत्याही सुरक्षा समस्यांसाठी इतरांना स्त्रोत कोड तपासण्यास सांगणे चांगले. चाचणीमुळे स्मार्ट कॉन्ट्रॅक्टमधील प्रत्येक त्रुटी उघड होणार नाही, परंतु स्वतंत्र पुनरावलोकन मिळवल्याने असुरक्षा शोधण्याची शक्यता वाढते.

ऑडिट्स

स्मार्ट कॉन्ट्रॅक्ट ऑडिट सुरू करणे हा स्वतंत्र कोड पुनरावलोकन करण्याचा एक मार्ग आहे. स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित आहेत आणि गुणवत्ता दोष आणि डिझाइन त्रुटींपासून मुक्त आहेत याची खात्री करण्यात ऑडिटर महत्त्वाची भूमिका बजावतात.

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

• स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग टिप्स आणि ट्रिक्स (नवीन टॅबमध्ये उघडते) - @tinchoabbate
• तुमच्या ऑडिटचा जास्तीत जास्त फायदा घ्या (नवीन टॅबमध्ये उघडते) - Inference

बग बाउन्टीज

बग बाउन्टी प्रोग्राम सेट करणे हा बाह्य कोड पुनरावलोकने लागू करण्याचा दुसरा दृष्टीकोन आहे. बग बाउन्टी हे ॲप्लिकेशनमधील असुरक्षा शोधणाऱ्या व्यक्तींना (सामान्यतः व्हाईटहॅट हॅकर्स) दिले जाणारे आर्थिक बक्षीस आहे.

जेव्हा योग्यरित्या वापरले जाते, तेव्हा बग बाउन्टीज हॅकर समुदायाच्या सदस्यांना गंभीर त्रुटींसाठी तुमच्या कोडची तपासणी करण्यासाठी प्रोत्साहन देतात. वास्तविक जीवनातील उदाहरण म्हणजे “अनंत पैशाचा बग” (infinite money bug) ज्यामुळे हल्लेखोराला इथेरियमवर चालणाऱ्या स्तर २ (l2) प्रोटोकॉल, ऑप्टिमिझम् (नवीन टॅबमध्ये उघडते) वर अमर्यादित प्रमाणात इथर तयार करता आले असते. सुदैवाने, एका व्हाईटहॅट हॅकरने ही त्रुटी शोधून काढली (नवीन टॅबमध्ये उघडते) आणि टीमला सूचित केले, या प्रक्रियेत मोठी रक्कम मिळवली (नवीन टॅबमध्ये उघडते).

एक उपयुक्त रणनीती म्हणजे बग बाउन्टी प्रोग्रामचे पेआउट धोक्यात असलेल्या निधीच्या प्रमाणात सेट करणे. “स्केलिंग बग बाउन्टी (नवीन टॅबमध्ये उघडते)” म्हणून वर्णन केलेला हा दृष्टीकोन व्यक्तींना असुरक्षांचे शोषण करण्याऐवजी जबाबदारीने उघड करण्यासाठी आर्थिक प्रोत्साहन देतो.

5. स्मार्ट कॉन्ट्रॅक्ट विकासादरम्यान सर्वोत्तम पद्धतींचे अनुसरण करा

ऑडिट्स आणि बग बाउन्टीजचे अस्तित्व तुम्हाला उच्च-गुणवत्तेचा कोड लिहिण्याच्या जबाबदारीतून मुक्त करत नाही. चांगली स्मार्ट कॉन्ट्रॅक्ट सुरक्षा योग्य डिझाइन आणि विकास प्रक्रियांचे अनुसरण करण्यापासून सुरू होते:

• सर्व कोड git सारख्या आवृत्ती नियंत्रण प्रणालीमध्ये (version control system) साठवा

• सर्व कोड बदल पुल विनंत्यांद्वारे (pull requests) करा

• पुल विनंत्यांमध्ये किमान एक स्वतंत्र पुनरावलोकनकर्ता असल्याची खात्री करा—जर तुम्ही एखाद्या प्रकल्पावर एकटे काम करत असाल, तर इतर विकासक शोधण्याचा आणि कोड पुनरावलोकनांची देवाणघेवाण करण्याचा विचार करा

• स्मार्ट कॉन्ट्रॅक्ट्सची चाचणी, संकलन, प्रस्थापना करण्यासाठी विकास वातावरण वापरा

• तुमचा कोड Cyfrin Aderyn (नवीन टॅबमध्ये उघडते), Mythril आणि स्लिदर सारख्या मूलभूत कोड विश्लेषण साधनांद्वारे चालवा. आदर्शपणे, तुम्ही प्रत्येक पुल विनंती विलीन होण्यापूर्वी हे केले पाहिजे आणि आउटपुटमधील फरकांची तुलना केली पाहिजे

• तुमचा कोड त्रुटींशिवाय संकलित होतो आणि Solidity कंपायलर कोणतीही चेतावणी देत नाही याची खात्री करा

• तुमच्या कोडचे योग्यरित्या दस्तऐवजीकरण करा (NatSpec (नवीन टॅबमध्ये उघडते) वापरून) आणि समजण्यास सोप्या भाषेत कॉन्ट्रॅक्ट आर्किटेक्चरबद्दल तपशील वर्णन करा. यामुळे इतरांना तुमच्या कोडचे ऑडिट आणि पुनरावलोकन करणे सोपे होईल.

6. मजबूत आपत्ती पुनर्प्राप्ती योजना लागू करा

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

कॉन्ट्रॅक्ट अपग्रेड्स

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

कॉन्ट्रॅक्ट अपग्रेड यंत्रणा वेगळ्या प्रकारे कार्य करतात, परंतु स्मार्ट कॉन्ट्रॅक्ट्स अपग्रेड करण्यासाठी “प्रॉक्सी पॅटर्न” हा अधिक लोकप्रिय दृष्टिकोनांपैकी एक आहे. प्रॉक्सी पॅटर्न (नवीन टॅबमध्ये उघडते) ॲप्लिकेशनची स्थिती आणि लॉजिक दोन कॉन्ट्रॅक्ट्समध्ये विभाजित करतात. पहिले कॉन्ट्रॅक्ट (‘प्रॉक्सी कॉन्ट्रॅक्ट’ म्हणतात) स्थिती व्हेरिएबल्स (उदा. वापरकर्ता शिल्लक) साठवते, तर दुसरे कॉन्ट्रॅक्ट (‘लॉजिक कॉन्ट्रॅक्ट’ म्हणतात) कॉन्ट्रॅक्ट फंक्शन्स कार्यान्वित करण्यासाठी कोड ठेवते.

खाती प्रॉक्सी कॉन्ट्रॅक्टशी संवाद साधतात, जे delegatecall() (नवीन टॅबमध्ये उघडते) लो-लेव्हल कॉल वापरून सर्व फंक्शन कॉल्स लॉजिक कॉन्ट्रॅक्टला पाठवते. नियमित संदेश कॉलच्या विपरीत, `delegatecall()हे सुनिश्चित करते की लॉजिक कॉन्ट्रॅक्टच्या पत्त्यावर चालणारा कोड कॉल करणाऱ्या कॉन्ट्रॅक्टच्या संदर्भात कार्यान्वित केला जातो. याचा अर्थ लॉजिक कॉन्ट्रॅक्ट नेहमी प्रॉक्सीच्या स्टोरेजमध्ये (स्वतःच्या स्टोरेजऐवजी) लिहेल आणिmsg.senderआणिmsg.value`` ची मूळ मूल्ये जतन केली जातील.

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

कॉन्ट्रॅक्ट्स अपग्रेड करण्याबद्दल अधिक.

आपत्कालीन थांबे (Emergency stops)

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

अंतिम पर्याय म्हणजे “आपत्कालीन थांबा” (emergency stop) फंक्शन लागू करणे जे कॉन्ट्रॅक्टमधील असुरक्षित फंक्शन्सचे कॉल्स अवरोधित करते. आपत्कालीन थांब्यांमध्ये सामान्यतः खालील घटकांचा समावेश असतो:

1. स्मार्ट कॉन्ट्रॅक्ट थांबलेल्या स्थितीत आहे की नाही हे दर्शवणारे ग्लोबल बुलियन व्हेरिएबल. कॉन्ट्रॅक्ट सेट करताना हे व्हेरिएबल false वर सेट केले जाते, परंतु एकदा कॉन्ट्रॅक्ट थांबले की ते true वर परत येईल.

2. फंक्शन्स जे त्यांच्या अंमलबजावणीमध्ये बुलियन व्हेरिएबलचा संदर्भ देतात. जेव्हा स्मार्ट कॉन्ट्रॅक्ट थांबलेले नसते तेव्हा अशी फंक्शन्स ॲक्सेस करण्यायोग्य असतात आणि जेव्हा आपत्कालीन थांबा वैशिष्ट्य ट्रिगर केले जाते तेव्हा ती ॲक्सेस करण्यायोग्य नसतात.

3. एक संस्था ज्याला आपत्कालीन थांबा फंक्शनचा ॲक्सेस आहे, जे बुलियन व्हेरिएबलला true वर सेट करते. दुर्भावनापूर्ण कृती टाळण्यासाठी, या फंक्शनचे कॉल्स विश्वसनीय पत्त्यापुरते (उदा. कॉन्ट्रॅक्ट मालक) मर्यादित केले जाऊ शकतात.

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

// या कोडचे व्यावसायिकरित्या परीक्षण केले गेले नाही आणि सुरक्षितता किंवा अचूकतेबद्दल कोणतेही आश्वासन दिले जात नाही. आपल्या स्वतःच्या जोखमीवर वापरा.

contract EmergencyStop {

    bool isStopped = false;

    modifier stoppedInEmergency {
        require(!isStopped);
        _;
    }

    modifier onlyWhenStopped {
        require(isStopped);
        _;
    }

    modifier onlyAuthorized {
        // येथे msg.sender च्या अधिकृततेची तपासणी करा
        _;
    }

    function stopContract() public onlyAuthorized {
        isStopped = true;
    }

    function resumeContract() public onlyAuthorized {
        isStopped = false;
    }

    function deposit() public payable stoppedInEmergency {
        // जमा करण्याचे लॉजिक येथे होत आहे
    }

    function emergencyWithdraw() public onlyWhenStopped {
        // आणीबाणीच्या वेळी पैसे काढण्याची प्रक्रिया येथे होत आहे
    }
}

हे उदाहरण आपत्कालीन थांब्यांची मूलभूत वैशिष्ट्ये दर्शवते:

• isStopped हे एक बुलियन आहे जे सुरुवातीला false आणि जेव्हा कॉन्ट्रॅक्ट आपत्कालीन मोडमध्ये प्रवेश करते तेव्हा true चे मूल्यांकन करते.

• फंक्शन मॉडिफायर्स onlyWhenStopped आणि stoppedInEmergency हे isStopped व्हेरिएबल तपासतात. जेव्हा कॉन्ट्रॅक्ट असुरक्षित असते तेव्हा ॲक्सेस करण्यायोग्य नसलेल्या फंक्शन्सना नियंत्रित करण्यासाठी stoppedInEmergency वापरले जाते (उदा. deposit()). या फंक्शन्सचे कॉल्स फक्त पूर्ववत होतील.

आणीबाणीच्या वेळी कॉल करण्यायोग्य असाव्यात अशा फंक्शन्ससाठी onlyWhenStopped वापरले जाते (उदा. emergencyWithdraw()). अशी फंक्शन्स परिस्थिती सोडवण्यास मदत करू शकतात, म्हणून त्यांना “प्रतिबंधित फंक्शन्स” सूचीमधून वगळले जाते.

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

घटना निरीक्षण (Event monitoring)

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

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

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

7. सुरक्षित प्रशासन प्रणाली डिझाइन करा

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

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

ऑनचेन प्रशासनाशी संबंधित समस्या टाळण्याचा एक मार्ग म्हणजे टाईमलॉक वापरणे (नवीन टॅबमध्ये उघडते). टाईमलॉक स्मार्ट कॉन्ट्रॅक्टला विशिष्ट वेळ संपेपर्यंत विशिष्ट कृती कार्यान्वित करण्यापासून प्रतिबंधित करते. इतर रणनीतींमध्ये प्रत्येक टोकनला ते किती काळ लॉक केले गेले आहे यावर आधारित “मतदान वजन” नियुक्त करणे किंवा वर्तमान ब्लॉकऐवजी ऐतिहासिक कालावधीत (उदाहरणार्थ, भूतकाळातील 2-3 ब्लॉक्स) पत्त्याची मतदान शक्ती मोजणे समाविष्ट आहे. दोन्ही पद्धती ऑनचेन मते वळवण्यासाठी त्वरीत मतदान शक्ती गोळा करण्याची शक्यता कमी करतात.

सामायिक केलेल्या लिंक्समध्ये सुरक्षित प्रशासन प्रणाली डिझाइन करणे (नवीन टॅबमध्ये उघडते), DAO मधील भिन्न मतदान यंत्रणा (नवीन टॅबमध्ये उघडते), आणि DeFi चा फायदा घेणारे सामान्य DAO हल्ला वेक्टर (नवीन टॅबमध्ये उघडते) याबद्दल अधिक.

8. कोडमधील गुंतागुंत कमीत कमी करा

पारंपारिक सॉफ्टवेअर विकासक KISS (“keep it simple, stupid”) तत्त्वाशी परिचित आहेत, जे सॉफ्टवेअर डिझाइनमध्ये अनावश्यक गुंतागुंत आणण्याविरुद्ध सल्ला देते. हे “गुंतागुंतीच्या प्रणाली गुंतागुंतीच्या मार्गांनी अयशस्वी होतात” आणि महागड्या त्रुटींना अधिक बळी पडतात या दीर्घकाळ चालत आलेल्या विचाराचे अनुसरण करते.

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

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

9. सामान्य स्मार्ट कॉन्ट्रॅक्ट असुरक्षांपासून बचाव करा

पुनर्प्रवेश (Reentrancy)

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

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

एका साध्या स्मार्ट कॉन्ट्रॅक्टचा (‘Victim’) विचार करा जे कोणालाही इथर जमा करण्यास आणि काढण्यास अनुमती देते:

// हे कॉन्ट्रॅक्ट असुरक्षित आहे. प्रोडक्शनमध्ये वापरू नका

contract Victim {
    mapping (address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        (bool success, ) = msg.sender.call.value(amount)("");
        require(success);
        balances[msg.sender] = 0;
    }
}

हे कॉन्ट्रॅक्ट वापरकर्त्यांना कॉन्ट्रॅक्टमध्ये पूर्वी जमा केलेले ETH काढण्याची अनुमती देण्यासाठी withdraw() फंक्शन उघड करते. रक्कम काढण्याची प्रक्रिया करताना, कॉन्ट्रॅक्ट खालील ऑपरेशन्स करते:

1. वापरकर्त्याची ETH शिल्लक तपासते
2. कॉल करणाऱ्या पत्त्यावर निधी पाठवते
3. त्यांची शिल्लक 0 वर रीसेट करते, वापरकर्त्याकडून अतिरिक्त रक्कम काढण्यास प्रतिबंध करते

Victim कॉन्ट्रॅक्टमधील withdraw() फंक्शन “checks-interactions-effects” पॅटर्नचे अनुसरण करते. ते अंमलबजावणीसाठी आवश्यक अटी पूर्ण झाल्या आहेत की नाही हे तपासते (म्हणजेच, वापरकर्त्याकडे सकारात्मक ETH शिल्लक आहे) आणि व्यवहाराचे परिणाम लागू करण्यापूर्वी (म्हणजेच, वापरकर्त्याची शिल्लक कमी करणे) कॉलरच्या पत्त्यावर ETH पाठवून संवाद करते.

जर withdraw() बाह्य मालकीच्या खात्यावरून (EOA) कॉल केले असेल, तर फंक्शन अपेक्षेप्रमाणे कार्यान्वित होते: msg.sender.call.value() कॉलरला ETH पाठवते. तथापि, जर msg.sender हे स्मार्ट कॉन्ट्रॅक्ट खाते असेल जे withdraw() ला कॉल करते, तर msg.sender.call.value() वापरून निधी पाठवल्याने त्या पत्त्यावर साठवलेला कोड देखील चालण्यासाठी ट्रिगर होईल.

कल्पना करा की हा कॉन्ट्रॅक्ट पत्त्यावर प्रस्थापित केलेला कोड आहे:

 contract Attacker {
    function beginAttack() external payable {
        Victim(victim_address).deposit.value(1 ether)();
        Victim(victim_address).withdraw();
    }

    function() external payable {
        if (gasleft() > 40000) {
            Victim(victim_address).withdraw();
        }
    }
}

हे कॉन्ट्रॅक्ट तीन गोष्टी करण्यासाठी डिझाइन केले आहे:

1. दुसऱ्या खात्यातून ठेव स्वीकारणे (बहुधा हल्लेखोराचे EOA)
2. Victim कॉन्ट्रॅक्टमध्ये 1 ETH जमा करणे
3. स्मार्ट कॉन्ट्रॅक्टमध्ये साठवलेले 1 ETH काढणे

येथे काहीही चुकीचे नाही, वगळता Attacker मध्ये आणखी एक फंक्शन आहे जे येणाऱ्या msg.sender.call.value मधून उरलेला गॅस 40,000 पेक्षा जास्त असल्यास Victim मधील withdraw() ला पुन्हा कॉल करते. यामुळे Attacker ला Victim मध्ये पुन्हा प्रवेश करण्याची आणि withdraw चे पहिले आवाहन पूर्ण होण्या_पूर्वी_ अधिक निधी काढण्याची क्षमता मिळते. हे चक्र असे दिसते:

- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH
- `Attacker.beginAttack()` deposits 1 ETH into `Victim`
- `Attacker` calls `withdraw() in `Victim`
- `Victim` checks `Attacker`’s balance (1 ETH)
- `Victim` sends 1 ETH to `Attacker` (which triggers the default function)
- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal)
- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call)
- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function)
- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals
- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0

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

पुनर्प्रवेश हल्ले कसे टाळावे

पुनर्प्रवेश हाताळण्याचा एक दृष्टीकोन म्हणजे checks-effects-interactions पॅटर्न (नवीन टॅबमध्ये उघडते) चे अनुसरण करणे. हा पॅटर्न फंक्शन्सच्या अंमलबजावणीची अशा प्रकारे क्रमवारी लावतो की अंमलबजावणीसह पुढे जाण्यापूर्वी आवश्यक तपासणी करणारा कोड प्रथम येतो, त्यानंतर कॉन्ट्रॅक्ट स्थितीत फेरफार करणारा कोड येतो आणि इतर कॉन्ट्रॅक्ट्स किंवा EOAs शी संवाद साधणारा कोड शेवटी येतो.

checks-effect-interaction पॅटर्न खाली दर्शविलेल्या Victim कॉन्ट्रॅक्टच्या सुधारित आवृत्तीमध्ये वापरला जातो:

contract NoLongerAVictim {
    function withdraw() external {
        uint256 amount = balances[msg.sender];
        balances[msg.sender] = 0;
        (bool success, ) = msg.sender.call.value(amount)("");
        require(success);
    }
}

हे कॉन्ट्रॅक्ट वापरकर्त्याच्या शिल्लक रकमेवर तपासणी करते, withdraw() फंक्शनचे परिणाम लागू करते (वापरकर्त्याची शिल्लक 0 वर रीसेट करून), आणि संवाद करण्यासाठी पुढे जाते (वापरकर्त्याच्या पत्त्यावर ETH पाठवणे). हे सुनिश्चित करते की कॉन्ट्रॅक्ट बाह्य कॉलपूर्वी त्याचे स्टोरेज अद्यतनित करते, ज्यामुळे पहिला हल्ला सक्षम करणारी पुनर्प्रवेश स्थिती दूर होते. Attacker कॉन्ट्रॅक्ट अद्याप NoLongerAVictim मध्ये परत कॉल करू शकते, परंतु balances[msg.sender] 0 वर सेट केले असल्याने, अतिरिक्त रक्कम काढल्यास त्रुटी येईल.

दुसरा पर्याय म्हणजे म्युच्युअल एक्सक्लूजन लॉक (सामान्यतः "म्युटेक्स" म्हणून वर्णन केलेले) वापरणे जे फंक्शनचे आवाहन पूर्ण होईपर्यंत कॉन्ट्रॅक्टच्या स्थितीचा काही भाग लॉक करते. हे बुलियन व्हेरिएबल वापरून लागू केले जाते जे फंक्शन कार्यान्वित होण्यापूर्वी true वर सेट केले जाते आणि आवाहन पूर्ण झाल्यानंतर false वर परत येते. खालील उदाहरणात पाहिल्याप्रमाणे, म्युटेक्स वापरल्याने मूळ आवाहनावर प्रक्रिया सुरू असताना फंक्शनचे रिकर्सिव्ह कॉल्सपासून संरक्षण होते, ज्यामुळे पुनर्प्रवेश प्रभावीपणे थांबतो.

pragma solidity ^0.7.0;

contract MutexPattern {
    bool locked = false;
    mapping(address => uint256) public balances;

    modifier noReentrancy() {
        require(!locked, "Blocked from reentrancy.");
        locked = true;
        _;
        locked = false;
    }
    // हे फंक्शन म्युटेक्सद्वारे संरक्षित आहे, त्यामुळे `msg.sender.call` मधील पुनर्प्रवेश कॉल्स पुन्हा `withdraw` ला कॉल करू शकत नाहीत.
    //  `return` विधान `true` चे मूल्यांकन करते परंतु तरीही मॉडिफायरमधील `locked = false` विधानाचे मूल्यांकन करते
    function withdraw(uint _amount) public payable noReentrancy returns(bool) {
        require(balances[msg.sender] >= _amount, "No balance to withdraw.");

        balances[msg.sender] -= _amount;
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success);

        return true;
    }
}

तुम्ही खात्यांमध्ये निधी पाठवणाऱ्या "पुश पेमेंट्स" प्रणालीऐवजी पुल पेमेंट्स (नवीन टॅबमध्ये उघडते) प्रणाली देखील वापरू शकता ज्यासाठी वापरकर्त्यांना स्मार्ट कॉन्ट्रॅक्ट्समधून निधी काढण्याची आवश्यकता असते. यामुळे अज्ञात पत्त्यांवर अनावधानाने कोड ट्रिगर होण्याची शक्यता दूर होते (आणि काही डिनायल-ऑफ-सर्व्हिस हल्ले देखील टाळता येतात).

इंटिजर अंडरफ्लो आणि ओव्हरफ्लो

जेव्हा अंकगणितीय ऑपरेशनचे परिणाम मूल्यांच्या स्वीकार्य श्रेणीच्या बाहेर येतात तेव्हा इंटिजर ओव्हरफ्लो होतो, ज्यामुळे ते सर्वात कमी प्रस्तुत करण्यायोग्य मूल्यावर "रोल ओव्हर" होते. उदाहरणार्थ, uint8 केवळ 2^8-1=255 पर्यंतची मूल्ये साठवू शकते. 255 पेक्षा जास्त मूल्ये देणारी अंकगणितीय ऑपरेशन्स ओव्हरफ्लो होतील आणि uint ला 0 वर रीसेट करतील, जसे कारवरील ओडोमीटर जास्तीत जास्त मायलेज (999999) गाठल्यावर 0 वर रीसेट होतो.

इंटिजर अंडरफ्लो समान कारणांसाठी होतात: अंकगणितीय ऑपरेशनचे परिणाम स्वीकार्य श्रेणीच्या खाली येतात. समजा तुम्ही uint8 मध्ये 0 कमी करण्याचा प्रयत्न केला, तर परिणाम फक्त जास्तीत जास्त प्रस्तुत करण्यायोग्य मूल्यावर (255) रोल ओव्हर होईल.

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

pragma solidity ^0.7.6;

// हे कॉन्ट्रॅक्ट टाइम व्हॉल्ट म्हणून काम करण्यासाठी डिझाइन केले आहे.
// वापरकर्ता या कॉन्ट्रॅक्टमध्ये जमा करू शकतो परंतु किमान एका आठवड्यासाठी काढू शकत नाही.
// वापरकर्ता 1 आठवड्याच्या प्रतीक्षा कालावधीच्या पलीकडे प्रतीक्षा वेळ वाढवू शकतो.

/*
1. TimeLock प्रस्थापित करा
2. TimeLock च्या पत्त्यासह Attack प्रस्थापित करा
3. 1 इथर पाठवून Attack.attack कॉल करा. तुम्ही लगेच तुमचे
   इथर काढू शकाल.

काय झाले?
Attack मुळे TimeLock.lockTime ओव्हरफ्लो झाले आणि 1 आठवड्याच्या
प्रतीक्षा कालावधीपूर्वी काढता आले.
*/

contract TimeLock {
    mapping(address => uint) public balances;
    mapping(address => uint) public lockTime;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] = block.timestamp + 1 weeks;
    }

    function increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    function withdraw() public {
        require(balances[msg.sender] > 0, "Insufficient funds");
        require(block.timestamp > lockTime[msg.sender], "Lock time not expired");

        uint amount = balances[msg.sender];
        balances[msg.sender] = 0;

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Failed to send Ether");
    }
}

contract Attack {
    TimeLock timeLock;

    constructor(TimeLock _timeLock) {
        timeLock = TimeLock(_timeLock);
    }

    fallback() external payable {}

    function attack() public payable {
        timeLock.deposit{value: msg.value}();
        /*
        जर t = वर्तमान लॉक वेळ असेल तर आपल्याला x असा शोधण्याची आवश्यकता आहे की
        x + t = 2**256 = 0
        म्हणून x = -t
        2**256 = type(uint).max + 1
        म्हणून x = type(uint).max + 1 - t
        */
        timeLock.increaseLockTime(
            type(uint).max + 1 - timeLock.lockTime(address(this))
        );
        timeLock.withdraw();
    }
}

इंटिजर अंडरफ्लो आणि ओव्हरफ्लो कसे टाळावे

आवृत्ती 0.8.0 नुसार, Solidity कंपायलर इंटिजर अंडरफ्लो आणि ओव्हरफ्लो होणारा कोड नाकारतो. तथापि, कमी कंपायलर आवृत्तीसह संकलित केलेल्या कॉन्ट्रॅक्ट्सनी एकतर अंकगणितीय ऑपरेशन्स समाविष्ट असलेल्या फंक्शन्सवर तपासणी केली पाहिजे किंवा अंडरफ्लो/ओव्हरफ्लो तपासणारी लायब्ररी (उदा. SafeMath (नवीन टॅबमध्ये उघडते)) वापरली पाहिजे.

ओरॅकल फेरफार (Oracle manipulation)

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

परंतु जर ओरॅकल दूषित असेल आणि ऑनचेन चुकीची माहिती पाठवत असेल, तर स्मार्ट कॉन्ट्रॅक्ट्स चुकीच्या इनपुट्सवर आधारित कार्यान्वित होतील, ज्यामुळे समस्या उद्भवू शकतात. हा “ओरॅकल समस्या” चा आधार आहे, जो ब्लॉकचेन ओरॅकलमधील माहिती अचूक, अद्ययावत आणि वेळेवर असल्याची खात्री करण्याच्या कार्याशी संबंधित आहे.

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

DEX किमती अनेकदा अचूक असतात, मुख्यत्वे आर्बिट्रेजर्स बाजारात समानता पुनर्संचयित करत असल्यामुळे. तथापि, ते फेरफार करण्यासाठी खुले आहेत, विशेषतः जर ऑनचेन ओरॅकल ऐतिहासिक व्यापार पद्धतींवर आधारित मालमत्तेच्या किमती मोजत असेल (जसे सहसा घडते).

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

ओरॅकल फेरफार कसे टाळावे

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

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

डेव्हलपर्ससाठी स्मार्ट कॉन्ट्रॅक्ट सुरक्षा संसाधने

स्मार्ट कॉन्ट्रॅक्ट्सचे विश्लेषण करण्यासाठी आणि कोडच्या अचूकतेची पडताळणी करण्यासाठी टूल्स

• टेस्टिंग टूल्स आणि लायब्ररी - स्मार्ट कॉन्ट्रॅक्ट्सवर युनिट टेस्ट्स, स्थिर विश्लेषण (static analysis) आणि गतिशील विश्लेषण (dynamic analysis) करण्यासाठी उद्योग-मानक टूल्स आणि लायब्ररींचा संग्रह.

• औपचारिक पडताळणी टूल्स - स्मार्ट कॉन्ट्रॅक्ट्समधील कार्यात्मक अचूकतेची पडताळणी करण्यासाठी आणि इनव्हेरियंट्स (invariants) तपासण्यासाठी टूल्स.

• स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा - इथेरियम डेव्हलपमेंट प्रोजेक्ट्ससाठी स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा प्रदान करणाऱ्या संस्थांची यादी.

• बग बाउन्टी प्लॅटफॉर्म्स - बग बाउन्टीजचे समन्वय साधण्यासाठी आणि स्मार्ट कॉन्ट्रॅक्ट्समधील गंभीर भेद्यता जबाबदारीने उघड केल्याबद्दल बक्षीस देण्यासाठी प्लॅटफॉर्म्स.

• फोर्क चेकर (Fork Checker) (नवीन टॅबमध्ये उघडते) - फोर्क केलेल्या कॉन्ट्रॅक्टसंबंधी सर्व उपलब्ध माहिती तपासण्यासाठी एक मोफत ऑनलाइन टूल.

• ABI एन्कोडर (नवीन टॅबमध्ये उघडते) - तुमच्या Solidity कॉन्ट्रॅक्ट फंक्शन्स आणि कन्स्ट्रक्टर आर्ग्युमेंट्स एन्कोड करण्यासाठी एक मोफत ऑनलाइन सेवा.

• Aderyn (नवीन टॅबमध्ये उघडते) - Solidity स्टॅटिक ॲनालायझर, जे संशयित भेद्यता शोधण्यासाठी ॲब्स्ट्रॅक्ट सिंटॅक्स ट्रीज (AST) मधून जाते आणि वाचायला सोप्या असलेल्या मार्कडाउन फॉरमॅटमध्ये समस्या प्रिंट करते.

स्मार्ट कॉन्ट्रॅक्ट्सचे निरीक्षण करण्यासाठी टूल्स

• Tenderly रिअल-टाइम अलर्टिंग (नवीन टॅबमध्ये उघडते) - तुमच्या स्मार्ट कॉन्ट्रॅक्ट्स किंवा वॉलेट्सवर असामान्य किंवा अनपेक्षित घटना घडल्यास रिअल-टाइम नोटिफिकेशन्स मिळवण्यासाठी एक टूल.

स्मार्ट कॉन्ट्रॅक्ट्सच्या सुरक्षित प्रशासनासाठी टूल्स

• Safe (नवीन टॅबमध्ये उघडते) - इथेरियमवर चालणारे स्मार्ट कॉन्ट्रॅक्ट वॉलेट, ज्यामध्ये व्यवहार होण्यापूर्वी तो मंजूर करण्यासाठी किमान काही लोकांची आवश्यकता असते (M-of-N).

• ओपनझेपलिन कॉन्ट्रॅक्ट्स (नवीन टॅबमध्ये उघडते) - कॉन्ट्रॅक्ट मालकी, अपग्रेड्स, ॲक्सेस कंट्रोल्स, प्रशासन, पॉझेबिलिटी आणि बरेच काही यासह प्रशासकीय वैशिष्ट्ये लागू करण्यासाठी कॉन्ट्रॅक्ट लायब्ररी.

स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा

• कॉन्सेन्सिस् डिलिजन्स (ConsenSys Diligence) (नवीन टॅबमध्ये उघडते) - ब्लॉकचेन इकोसिस्टममधील प्रोजेक्ट्सना त्यांचे प्रोटोकॉल लाँचसाठी तयार आहेत आणि वापरकर्त्यांचे संरक्षण करण्यासाठी तयार केले आहेत याची खात्री करण्यास मदत करणारी स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवा.

• CertiK (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट्स आणि ब्लॉकचेन नेटवर्क्सवर अत्याधुनिक औपचारिक पडताळणी तंत्रज्ञानाचा वापर करण्यात अग्रेसर असलेली ब्लॉकचेन सुरक्षा कंपनी.

• Trail of Bits (नवीन टॅबमध्ये उघडते) - सायबर सुरक्षा कंपनी जी धोका कमी करण्यासाठी आणि कोड मजबूत करण्यासाठी सुरक्षा संशोधनाची हल्लेखोराच्या मानसिकतेशी सांगड घालते.

• PeckShield (नवीन टॅबमध्ये उघडते) - संपूर्ण ब्लॉकचेन इकोसिस्टमची सुरक्षा, गोपनीयता आणि उपयोगितेसाठी उत्पादने आणि सेवा देणारी ब्लॉकचेन सुरक्षा कंपनी.

• QuantStamp (नवीन टॅबमध्ये उघडते) - सुरक्षा आणि जोखीम मूल्यांकन सेवांद्वारे ब्लॉकचेन तंत्रज्ञानाचा मुख्य प्रवाहात अवलंब सुलभ करणारी ऑडिटिंग सेवा.

• ओपनझेपलिन (नवीन टॅबमध्ये उघडते) - वितरित सिस्टीम्ससाठी सुरक्षा ऑडिट्स प्रदान करणारी स्मार्ट कॉन्ट्रॅक्ट सुरक्षा कंपनी.

• Runtime Verification (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट्सचे औपचारिक मॉडेलिंग आणि पडताळणी करण्यात तज्ञ असलेली सुरक्षा कंपनी.

• Hacken (नवीन टॅबमध्ये उघडते) - ब्लॉकचेन सुरक्षेसाठी 360-अंश दृष्टिकोन आणणारे Web3 सायबर सुरक्षा ऑडिटर.

• नेदरमाइंड (नवीन टॅबमध्ये उघडते) - Solidity आणि Cairo ऑडिटिंग सेवा, ज्या इथेरियम आणि स्टार्कनेट् वर स्मार्ट कॉन्ट्रॅक्ट्सची अखंडता आणि वापरकर्त्यांची सुरक्षितता सुनिश्चित करतात.

• HashEx (नवीन टॅबमध्ये उघडते) - HashEx क्रिप्टोकरन्सीची सुरक्षा सुनिश्चित करण्यासाठी ब्लॉकचेन आणि स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंगवर लक्ष केंद्रित करते, तसेच स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंट, पेनिट्रेशन टेस्टिंग, ब्लॉकचेन कन्सल्टिंग यांसारख्या सेवा प्रदान करते.

• Code4rena (नवीन टॅबमध्ये उघडते) - स्पर्धात्मक ऑडिट प्लॅटफॉर्म जे स्मार्ट कॉन्ट्रॅक्ट सुरक्षा तज्ञांना भेद्यता शोधण्यासाठी आणि Web3 अधिक सुरक्षित करण्यात मदत करण्यासाठी प्रोत्साहित करते.

• CodeHawks (नवीन टॅबमध्ये उघडते) - सुरक्षा संशोधकांसाठी स्मार्ट कॉन्ट्रॅक्ट्स ऑडिटिंग स्पर्धा आयोजित करणारे स्पर्धात्मक ऑडिट्स प्लॅटफॉर्म.

• Cyfrin (नवीन टॅबमध्ये उघडते) - Web3 सुरक्षा पॉवरहाऊस, जे उत्पादने आणि स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंग सेवांद्वारे क्रिप्टो सुरक्षेला चालना देते.

• ImmuneBytes (नवीन टॅबमध्ये उघडते) - अनुभवी ऑडिटर्सची टीम आणि सर्वोत्तम टूल्सच्या माध्यमातून ब्लॉकचेन सिस्टीम्ससाठी सुरक्षा ऑडिट्स देणारी Web3 सुरक्षा कंपनी.

• Oxorio (नवीन टॅबमध्ये उघडते) - क्रिप्टो कंपन्या आणि विकेंद्रित वित्त (DeFi) प्रोजेक्ट्ससाठी EVM, Solidity, ZK, क्रॉस-चेन तंत्रज्ञानामध्ये तज्ञ असलेल्या स्मार्ट कॉन्ट्रॅक्ट ऑडिट्स आणि ब्लॉकचेन सुरक्षा सेवा.

• Inference (नवीन टॅबमध्ये उघडते) - EVM-आधारित ब्लॉकचेन्ससाठी स्मार्ट कॉन्ट्रॅक्ट ऑडिटिंगमध्ये तज्ञ असलेली सुरक्षा ऑडिटिंग कंपनी. त्यांच्या तज्ञ ऑडिटर्समुळे ते संभाव्य समस्या ओळखतात आणि प्रस्थापनेपूर्वी (deployment) त्या सोडवण्यासाठी कृती करण्यायोग्य उपायांची शिफारस करतात.

बग बाउन्टी प्लॅटफॉर्म्स

• Immunefi (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट्स आणि विकेंद्रित वित्त (DeFi) प्रोजेक्ट्ससाठी बग बाउन्टी प्लॅटफॉर्म, जिथे सुरक्षा संशोधक कोडचे पुनरावलोकन करतात, भेद्यता उघड करतात, मोबदला मिळवतात आणि क्रिप्टो अधिक सुरक्षित बनवतात.

• HackerOne (नवीन टॅबमध्ये उघडते) - भेद्यता समन्वय आणि बग बाउन्टी प्लॅटफॉर्म जे व्यवसायांना पेनिट्रेशन टेस्टर्स आणि सायबर सुरक्षा संशोधकांशी जोडते.

• HackenProof (नवीन टॅबमध्ये उघडते) - क्रिप्टो प्रोजेक्ट्ससाठी (DeFi, स्मार्ट कॉन्ट्रॅक्ट्स, वॉलेट्स, CEX आणि बरेच काही) तज्ञ बग बाउन्टी प्लॅटफॉर्म, जिथे सुरक्षा व्यावसायिक ट्रायज (triage) सेवा प्रदान करतात आणि संशोधकांना संबंधित, सत्यापित बग रिपोर्ट्ससाठी मोबदला मिळतो.

• Sherlock (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट सुरक्षेसाठी Web3 मधील अंडररायटर, ज्यामध्ये संबंधित बग्जसाठी योग्य मोबदला दिला जावा हे सुनिश्चित करण्यासाठी ऑडिटर्सचे पेआउट्स स्मार्ट कॉन्ट्रॅक्ट्सद्वारे व्यवस्थापित केले जातात.

• CodeHawks (नवीन टॅबमध्ये उघडते) - स्पर्धात्मक बग बाउन्टी प्लॅटफॉर्म जिथे ऑडिटर्स सुरक्षा स्पर्धा आणि आव्हानांमध्ये भाग घेतात आणि (लवकरच) त्यांच्या स्वतःच्या खाजगी ऑडिट्समध्येही सहभागी होतील.

ज्ञात स्मार्ट कॉन्ट्रॅक्ट भेद्यता आणि एक्सप्लॉइट्सची प्रकाशने

• कॉन्सेन्सिस्: स्मार्ट कॉन्ट्रॅक्ट नोन अटॅक्स (नवीन टॅबमध्ये उघडते) - सर्वात महत्त्वपूर्ण कॉन्ट्रॅक्ट भेद्यतांचे नवशिक्यांसाठी अनुकूल स्पष्टीकरण, बहुतांश प्रकरणांसाठी नमुना कोडसह.

• SWC रजिस्ट्री (नवीन टॅबमध्ये उघडते) - इथेरियम स्मार्ट कॉन्ट्रॅक्ट्सना लागू होणाऱ्या कॉमन वीकनेस एन्युमरेशन (CWE) आयटम्सची क्युरेट केलेली यादी.

• Rekt (नवीन टॅबमध्ये उघडते) - हाय-प्रोफाइल क्रिप्टो हॅक्स आणि एक्सप्लॉइट्सचे नियमितपणे अपडेट केलेले प्रकाशन, सोबतच सविस्तर पोस्ट-मॉर्टम रिपोर्ट्स.

स्मार्ट कॉन्ट्रॅक्ट सुरक्षा शिकण्यासाठी आव्हाने

• Awesome BlockSec CTF (नवीन टॅबमध्ये उघडते) - ब्लॉकचेन सुरक्षा वॉरगेम्स, आव्हाने आणि कॅप्चर द फ्लॅग (Capture The Flag) (नवीन टॅबमध्ये उघडते) स्पर्धा आणि त्यांच्या उपायांच्या राइटअप्सची क्युरेट केलेली यादी.

• Damn Vulnerable DeFi (नवीन टॅबमध्ये उघडते) - विकेंद्रित वित्त (DeFi) स्मार्ट कॉन्ट्रॅक्ट्सची आक्रमक सुरक्षा शिकण्यासाठी आणि बग-हंटिंग व सुरक्षा ऑडिटिंगमध्ये कौशल्ये निर्माण करण्यासाठी वॉरगेम.

• Ethernaut (नवीन टॅबमध्ये उघडते) - Web3/Solidity-आधारित वॉरगेम जिथे प्रत्येक लेव्हल एक स्मार्ट कॉन्ट्रॅक्ट असते ज्याला 'हॅक' करणे आवश्यक असते.

• HackenProof x HackTheBox (नवीन टॅबमध्ये उघडते) - फँटसी ॲडव्हेंचरवर आधारित स्मार्ट कॉन्ट्रॅक्ट हॅकिंग आव्हान. हे आव्हान यशस्वीरित्या पूर्ण केल्यास खाजगी बग बाउन्टी प्रोग्रामचा ॲक्सेस देखील मिळतो.

स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित करण्यासाठी सर्वोत्तम पद्धती

• कॉन्सेन्सिस्: इथेरियम स्मार्ट कॉन्ट्रॅक्ट सिक्युरिटी बेस्ट प्रॅक्टिसेस (नवीन टॅबमध्ये उघडते) - इथेरियम स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षित करण्यासाठी मार्गदर्शक तत्त्वांची सर्वसमावेशक यादी.

• Nascent: सिम्पल सिक्युरिटी टूलकिट (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट डेव्हलपमेंटसाठी व्यावहारिक सुरक्षा-केंद्रित मार्गदर्शक आणि चेकलिस्ट्सचा संग्रह.

• Solidity पॅटर्न्स (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट प्रोग्रामिंग भाषा Solidity साठी सुरक्षित पॅटर्न्स आणि सर्वोत्तम पद्धतींचे उपयुक्त संकलन.

• Solidity डॉक्स: सिक्युरिटी कन्सिडरेशन्स (नवीन टॅबमध्ये उघडते) - Solidity सह सुरक्षित स्मार्ट कॉन्ट्रॅक्ट्स लिहिण्यासाठी मार्गदर्शक तत्त्वे.

• स्मार्ट कॉन्ट्रॅक्ट सिक्युरिटी व्हेरिफिकेशन स्टँडर्ड (नवीन टॅबमध्ये उघडते) - डेव्हलपर्स, आर्किटेक्ट्स, सुरक्षा समीक्षक आणि व्हेंडर्ससाठी स्मार्ट कॉन्ट्रॅक्ट्सची सुरक्षा प्रमाणित करण्यासाठी तयार केलेली चौदा-भागांची चेकलिस्ट.

• लर्न स्मार्ट कॉन्ट्रॅक्ट सिक्युरिटी अँड ऑडिटिंग (नवीन टॅबमध्ये उघडते) - स्मार्ट कॉन्ट्रॅक्ट सुरक्षा आणि ऑडिटिंगचा सर्वोत्तम कोर्स, जो त्यांच्या सुरक्षेच्या सर्वोत्तम पद्धती सुधारू पाहणाऱ्या आणि सुरक्षा संशोधक बनू इच्छिणाऱ्या स्मार्ट कॉन्ट्रॅक्ट डेव्हलपर्ससाठी तयार केला आहे.

स्मार्ट कॉन्ट्रॅक्ट सुरक्षेवरील ट्युटोरियल्स

• सुरक्षित स्मार्ट कॉन्ट्रॅक्ट्स कसे लिहावे

• स्मार्ट कॉन्ट्रॅक्टमधील बग्ज शोधण्यासाठी स्लिदर (Slither) चा वापर कसा करावा

• स्मार्ट कॉन्ट्रॅक्टमधील बग्ज शोधण्यासाठी मॅन्टिकोर (Manticore) चा वापर कसा करावा

• स्मार्ट कॉन्ट्रॅक्ट सुरक्षा मार्गदर्शक तत्त्वे

• तुमचे टोकन कॉन्ट्रॅक्ट अनियंत्रित (arbitrary) टोकन्ससोबत सुरक्षितपणे कसे इंटिग्रेट करावे

• Cyfrin Updraft - स्मार्ट कॉन्ट्रॅक्ट्स सुरक्षा आणि ऑडिटिंगचा संपूर्ण कोर्स (नवीन टॅबमध्ये उघडते)