मुख्य सामग्री पर जाएँ
Change page

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

पेज का अंतिम अपडेट: 26 फ़रवरी 2026

luniacllamal (opens in a new tab)
nijrn (opens in a new tab)
corwintinesc (opens in a new tab)
+17

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

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

हालांकि आंकड़े अलग-अलग हैं, यह अनुमान लगाया जाता है कि स्मार्ट अनुबंधों में सुरक्षा दोषों के कारण चोरी या खोए गए कुल मूल्य की राशि आसानी से 1 अरब डॉलर से अधिक है। इसमें डाओ हैक (opens in a new tab) (3.6M ETH चोरी हुआ, जिसकी कीमत आज की कीमतों में $1B से अधिक है), पैरिटी मल्टी-सिग वॉलेट हैक (opens in a new tab) (हैकर्स द्वारा $30M का नुकसान), और पैरिटी फ्रोजन वॉलेट समस्या (opens in a new tab) (ETH में $300M से अधिक हमेशा के लिए लॉक हो गए) जैसी हाई-प्रोफाइल घटनाएं शामिल हैं।

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

पूर्वापेक्षाएं

सुनिश्चित करें कि आप सुरक्षा से निपटने से पहले स्मार्ट अनुबंध विकास के मूल सिद्धांतों से परिचित हैं।

सुरक्षित एथेरियम स्मार्ट अनुबंध बनाने के लिए दिशानिर्देश

1. उचित एक्सेस नियंत्रण डिज़ाइन करें

स्मार्ट अनुबंधों में, public या external के रूप में चिह्नित फंक्शंस को किसी भी बाहरी स्वामित्व वाले खाते (EOAs) या अनुबंध खातों द्वारा कॉल किया जा सकता है। यदि आप चाहते हैं कि दूसरे आपके अनुबंध के साथ इंटरैक्ट करें तो फंक्शंस के लिए सार्वजनिक दृश्यता निर्दिष्ट करना आवश्यक है। हालांकि, private के रूप में चिह्नित फंक्शंस को केवल स्मार्ट अनुबंध के भीतर फंक्शंस द्वारा ही कॉल किया जा सकता है, बाहरी खातों द्वारा नहीं। हर नेटवर्क प्रतिभागी को अनुबंध फंक्शंस की एक्सेस देने से समस्याएं पैदा हो सकती हैं, खासकर अगर इसका मतलब है कि कोई भी संवेदनशील कार्य कर सकता है (जैसे, नए टोकन बनाना)।

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

स्वामित्व योग्य पैटर्न

स्वामित्व योग्य पैटर्न में, अनुबंध-निर्माण की प्रक्रिया के दौरान एक पता अनुबंध के “स्वामी” के रूप में सेट किया जाता है। संरक्षित फंक्शंस को OnlyOwner मॉडिफायर सौंपा जाता है, जो यह सुनिश्चित करता है कि फंक्शन को निष्पादित करने से पहले अनुबंध कॉल करने वाले पते की पहचान को प्रमाणित करे। अनुबंध स्वामी के अलावा अन्य पतों से संरक्षित फंक्शंस के लिए कॉल हमेशा वापस लौट जाते हैं, जिससे अवांछित एक्सेस रोकी जाती है।

भूमिका-आधारित एक्सेस नियंत्रण

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

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

मल्टी-सिग्नेचर वॉलेट का उपयोग करना

सुरक्षित एक्सेस नियंत्रण लागू करने का एक और तरीका अनुबंध को प्रबंधित करने के लिए मल्टी-सिग्नेचर खाते का उपयोग करना है। एक नियमित EOA के विपरीत, मल्टी-सिग्नेचर खाते कई संस्थाओं के स्वामित्व में होते हैं और लेनदेन को निष्पादित करने के लिए न्यूनतम संख्या में खातों—मान लीजिए 5 में से 3—से हस्ताक्षर की आवश्यकता होती है।

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

२. अनुबंध संचालन की सुरक्षा के लिए require(), assert(), और revert() स्टेटमेंट का उपयोग करें

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

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

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

revert(): revert() का उपयोग if-else स्टेटमेंट में किया जा सकता है जो आवश्यक शर्त पूरी न होने पर एक अपवाद ट्रिगर करता है। नीचे दिया गया नमूना अनुबंध फंक्शंस के निष्पादन की सुरक्षा के लिए revert() का उपयोग करता है:

1pragma solidity ^0.8.4;
2
3contract VendingMachine {
4    address owner;
5    error Unauthorized();
6    function buy(uint amount) public payable {
7        if (amount > msg.value / 2 ether)
8            revert("पर्याप्त ईथर प्रदान नहीं किया गया।");
9        // खरीद करें।
10    }
11    function withdraw() public {
12        if (msg.sender != owner)
13            revert Unauthorized();
14
15        payable(msg.sender).transfer(address(this).balance);
16    }
17}
सभी दिखाएँ

3. स्मार्ट अनुबंधों का परीक्षण करें और कोड की शुद्धता सत्यापित करें

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

सामान्य तरीका छोटे इकाई परीक्षण लिखना है जो उस मॉक डेटा का उपयोग करते हैं जिसे अनुबंध को उपयोगकर्ताओं से प्राप्त करने की उम्मीद है। यूनिट टेस्टिंग कुछ फंक्शंस की कार्यक्षमता का परीक्षण करने और यह सुनिश्चित करने के लिए अच्छा है कि एक स्मार्ट अनुबंध अपेक्षा के अनुरूप काम करता है।

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

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

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

4. अपने कोड की स्वतंत्र समीक्षा करवाएं

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

ऑडिट

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

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

बग बाउंटी

बग बाउंटी कार्यक्रम शुरू करना बाहरी कोड समीक्षा लागू करने का एक और तरीका है। बग बाउंटी एक आर्थिक इनाम है जो उन व्यक्तियों (आमतौर पर व्हाइटहैट हैकर्स) को दिया जाता है जो किसी एप्लिकेशन में कमजोरियों का पता लगाते हैं।

सही तरीके से उपयोग किए जाने पर, बग बाउंटी हैकर समुदाय के सदस्यों को आपके कोड में गंभीर खामियों की जांच करने के लिए प्रोत्साहित करते हैं। एक वास्तविक जीवन का उदाहरण "अनंत धन बग" है जो एक हमलावर को ऑप्टिमिज़्म (opens in a new tab) पर असीमित मात्रा में ईथर बनाने देता, जो एथेरियम पर चलने वाला एक लेयर 2 प्रोटोकॉल है। सौभाग्य से, एक व्हाइटहैट हैकर ने खामी की खोज की (opens in a new tab) और टीम को सूचित किया, प्रक्रिया में एक बड़ा भुगतान अर्जित करते हुए (opens in a new tab)।

एक उपयोगी रणनीति बग बाउंटी कार्यक्रम का भुगतान स्टेक पर लगी राशि के अनुपात में निर्धारित करना है। "स्केलिंग बग बाउंटी (opens in a new tab)" के रूप में वर्णित, यह दृष्टिकोण व्यक्तियों को कमजोरियों का फायदा उठाने के बजाय जिम्मेदारी से उनका खुलासा करने के लिए वित्तीय प्रोत्साहन प्रदान करता है।

5. स्मार्ट अनुबंध विकास के दौरान सर्वोत्तम प्रथाओं का पालन करें

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

  • सभी कोड को गिट जैसी संस्करण नियंत्रण प्रणाली में संग्रहीत करें

  • सभी कोड संशोधन को पुल अनुरोधों के माध्यम से करें

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

  • स्मार्ट अनुबंधों के परीक्षण, संकलन, परिनियोजन के लिए विकास परिवेश का उपयोग करें

  • अपने कोड को Cyfrin Aderyn (opens in a new tab), मिथ्रिल और स्लिदर जैसे बुनियादी कोड विश्लेषण उपकरणों से गुजारें। आदर्श रूप से, आपको यह हर पुल अनुरोध को मर्ज करने से पहले करना चाहिए और आउटपुट में अंतरों की तुलना करनी चाहिए

  • सुनिश्चित करें कि आपका कोड बिना किसी त्रुटि के संकलित होता है, और सॉलिडिटी कंपाइलर कोई चेतावनी नहीं देता

  • अपने कोड को ठीक से प्रलेखित करें (नैटस्पेक (opens in a new tab) का उपयोग करके) और अनुबंध आर्किटेक्चर के बारे में विवरण को आसानी से समझने योग्य भाषा में वर्णित करें। यह दूसरों के लिए आपके कोड का ऑडिट और समीक्षा करना आसान बना देगा।

6. मजबूत आपदा पुनर्प्राप्ति योजनाएं लागू करें

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

अनुबंध अपग्रेड

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

कॉन्ट्रैक्ट अपग्रेड तंत्र अलग-अलग तरीके से काम करते हैं, लेकिन "प्रॉक्सी पैटर्न" स्मार्ट कॉन्ट्रैक्ट्स को अपग्रेड करने के लिए अधिक लोकप्रिय दृष्टिकोणों में से एक है। प्रॉक्सी पैटर्न (opens in a new tab) एक एप्लिकेशन की स्थिति और तर्क को दो अनुबंधों के बीच विभाजित करते हैं। पहला अनुबंध (जिसे ‘प्रॉक्सी अनुबंध’ कहा जाता है) स्टेट वेरिएबल्स (जैसे, यूज़र शेष राशि) को संग्रहीत करता है, जबकि दूसरा अनुबंध (जिसे 'तर्क अनुबंध' कहा जाता है) अनुबंध फंक्शंस को निष्पादित करने के लिए कोड रखता है।

खाते प्रॉक्सी अनुबंध के साथ इंटरैक्ट करते हैं, जो delegatecall() (opens in a new tab) निम्न-स्तरीय कॉल का उपयोग करके सभी फ़ंक्शन कॉल को तर्क अनुबंध में भेजता है। एक नियमित संदेश कॉल के विपरीत, delegatecall() यह सुनिश्चित करता है कि तर्क अनुबंध के पते पर चल रहा कोड कॉलिंग अनुबंध के संदर्भ में निष्पादित हो। इसका मतलब है कि तर्क अनुबंध हमेशा प्रॉक्सी के भंडारण में लिखेगा (अपने स्वयं के भंडारण के बजाय) और msg.sender और msg.value के मूल मान संरक्षित रहते हैं।

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

अनुबंधों को अपग्रेड करने पर अधिक जानकारी।

आपातकालीन स्टॉप

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

परमाणु विकल्प एक “आपातकालीन रोक” फंक्शन लागू करना है जो एक अनुबंध में कमजोर फंक्शंस के लिए कॉल को ब्लॉक करता है। आपातकालीन रोक में आमतौर पर निम्नलिखित घटक शामिल होते हैं:

  1. एक वैश्विक बूलियन वेरिएबल जो इंगित करता है कि स्मार्ट अनुबंध रुकी हुई अवस्था में है या नहीं। अनुबंध सेट करते समय यह वेरिएबल false पर सेट किया जाता है, लेकिन अनुबंध रुकने पर true पर वापस आ जाएगा।

  2. ऐसे फंक्शन जो अपने निष्पादन में बूलियन वेरिएबल का संदर्भ देते हैं। ऐसे फंक्शन तब सुलभ होते हैं जब स्मार्ट अनुबंध नहीं रुका होता है और आपातकालीन रोक सुविधा ट्रिगर होने पर अगम्य हो जाते हैं।

  3. एक इकाई जिसके पास आपातकालीन स्टॉप फ़ंक्शन तक पहुंच है, जो बूलियन वैरिएबल को true पर सेट करती है। दुर्भावनापूर्ण कार्यों को रोकने के लिए, इस फंक्शन के लिए कॉल को एक विश्वसनीय पते (जैसे, अनुबंध स्वामी) तक सीमित किया जा सकता है।

एक बार जब अनुबंध आपातकालीन रोक को सक्रिय करता है, तो कुछ फंक्शंस को कॉल नहीं किया जा सकेगा। यह चुनिंदा फंक्शंस को एक मॉडिफायर में लपेटकर प्राप्त किया जाता है जो वैश्विक वेरिएबल का संदर्भ देता है। नीचे एक उदाहरण (opens in a new tab) है जो अनुबंधों में इस पैटर्न के कार्यान्वयन का वर्णन करता है:

1// इस कोड का पेशेवर रूप से ऑडिट नहीं किया गया है और यह सुरक्षा या शुद्धता के बारे में कोई वादा नहीं करता है। अपने जोखिम पर उपयोग करें।
2
3contract EmergencyStop {
4
5    bool isStopped = false;
6
7    modifier stoppedInEmergency {
8        require(!isStopped);
9        _;
10    }
11
12    modifier onlyWhenStopped {
13        require(isStopped);
14        _;
15    }
16
17    modifier onlyAuthorized {
18        // यहां msg.sender के प्राधिकरण की जांच करें
19        _;
20    }
21
22    function stopContract() public onlyAuthorized {
23        isStopped = true;
24    }
25
26    function resumeContract() public onlyAuthorized {
27        isStopped = false;
28    }
29
30    function deposit() public payable stoppedInEmergency {
31        // जमा तर्क यहां होता है
32    }
33
34    function emergencyWithdraw() public onlyWhenStopped {
35        // आपातकालीन निकासी यहां होती है
36    }
37}
सभी दिखाएँ

यह उदाहरण आपातकालीन रोक की मूल विशेषताओं को दर्शाता है:

  • isStopped एक बूलियन है जो शुरुआत में false और अनुबंध के आपातकालीन मोड में प्रवेश करने पर true का मूल्यांकन करता है।

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

onlyWhenStopped का उपयोग उन फंक्शंस के लिए किया जाता है जो आपातकाल के दौरान कॉल करने योग्य होने चाहिए (उदाहरण के लिए, emergencyWithdraw())। ऐसे फंक्शन स्थिति को हल करने में मदद कर सकते हैं, इसलिए उन्हें “प्रतिबंधित फंक्शंस“ सूची से बाहर रखा गया है।

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

इवेंट निगरानी

इवेंट्स (opens in a new tab) आपको स्मार्ट अनुबंध फंक्शंस के कॉल्स को ट्रैक करने और स्टेट वेरिएबल्स में परिवर्तनों की निगरानी करने की अनुमति देते हैं। यह आदर्श है कि आप अपने स्मार्ट अनुबंध को इस तरह प्रोग्राम करें कि जब भी कोई पक्ष कोई सुरक्षा-महत्वपूर्ण कार्रवाई करता है (जैसे, फंड निकालना), तो वह एक इवेंट उत्सर्जित करे।

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

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

7. सुरक्षित शासन प्रणाली डिज़ाइन करें

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

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

ऑन-चेन शासन से संबंधित समस्याओं को रोकने का एक तरीका टाइमलॉक का उपयोग करना (opens in a new tab) है। टाइमलॉक एक स्मार्ट अनुबंध को कुछ निश्चित कार्यों को तब तक निष्पादित करने से रोकता है जब तक कि एक विशिष्ट समय न बीत जाए। अन्य रणनीतियों में प्रत्येक टोकन को एक “वोटिंग वेट” असाइन करना शामिल है, जो इस बात पर आधारित होता है कि वह कितने समय से लॉक किया गया है, या वर्तमान ब्लॉक के बजाय किसी पते की वोटिंग पावर को एक ऐतिहासिक अवधि (उदाहरण के लिए, पिछले 2-3 ब्लॉक्स) में मापना शामिल है। दोनों तरीके ऑन-चेन वोट को प्रभावित करने के लिए तेजी से वोटिंग पावर जमा करने की संभावना को कम करते हैं।

सुरक्षित शासन प्रणाली डिजाइन करने (opens in a new tab), डाओ में विभिन्न मतदान तंत्रों (opens in a new tab), और साझा लिंक में डीफाई का लाभ उठाने वाले सामान्य डाओ हमले वैक्टर (opens in a new tab) पर अधिक।

8. कोड में जटिलता को न्यूनतम तक कम करें

पारंपरिक सॉफ्टवेयर डेवलपर्स KISS (“इसे सरल रखो, बेवकूफ़“) सिद्धांत से परिचित हैं, जो सॉफ्टवेयर डिज़ाइन में अनावश्यक जटिलता लाने के खिलाफ सलाह देता है। यह लंबे समय से चली आ रही सोच का अनुसरण करता है कि “जटिल प्रणालियां जटिल तरीकों से विफल होती हैं” और महंगी त्रुटियों के प्रति अधिक संवेदनशील होते हैं।

स्मार्ट अनुबंध लिखते समय चीजों को सरल रखना विशेष रूप से महत्वपूर्ण है, क्योंकि स्मार्ट अनुबंध संभवतः बड़ी मात्रा में मूल्य को नियंत्रित कर रहे हैं। स्मार्ट अनुबंध लिखते समय सरलता प्राप्त करने के लिए एक सुझाव है कि जहां संभव हो, ओपनज़ेपेलिन Contracts (opens in a new tab) जैसी मौजूदा लाइब्रेरीज का पुन: उपयोग करें। चूंकि इन लाइब्रेरीज की डेवलपर्स द्वारा व्यापक रूप से ऑडिट और परीक्षण किया गया है, इनका उपयोग करने से नई कार्यक्षमता को शुरू से लिखने की तुलना में बग पेश करने की संभावना कम हो जाती है।

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

9. सामान्य स्मार्ट अनुबंध कमजोरियों से बचाव करें

रीएंट्रेंसी

EVM समवर्तिता की अनुमति नहीं देता है, जिसका अर्थ है कि एक संदेश कॉल में शामिल दो अनुबंध एक साथ नहीं चल सकते। एक बाहरी कॉल कॉलिंग अनुबंध के निष्पादन और मेमोरी को तब तक रोक देता है जब तक कि कॉल वापस नहीं आता, जिस बिंदु पर निष्पादन सामान्य रूप से आगे बढ़ता है। इस प्रक्रिया को औपचारिक रूप से दूसरे अनुबंध को नियंत्रण प्रवाह (opens in a new tab) स्थानांतरित करने के रूप में वर्णित किया जा सकता है।

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

एक सरल स्मार्ट अनुबंध (‘विक्टिम’) पर विचार करें जो किसी को भी ईथर जमा करने और निकालने की अनुमति देता है:

1// यह अनुबंध कमजोर है। उत्पादन में उपयोग न करें
2
3contract Victim {
4    mapping (address => uint256) public balances;
5
6    function deposit() external payable {
7        balances[msg.sender] += msg.value;
8    }
9
10    function withdraw() external {
11        uint256 amount = balances[msg.sender];
12        (bool success, ) = msg.sender.call.value(amount)("");
13        require(success);
14        balances[msg.sender] = 0;
15    }
16}
सभी दिखाएँ

यह अनुबंध एक withdraw() फंक्शन को एक्सपोज़ करता है जो उपयोगकर्ताओं को पहले अनुबंध में जमा किए गए ETH को निकालने की अनुमति देता है। निकासी को संसाधित करते समय, अनुबंध निम्नलिखित कार्य करता है:

  1. यूज़र के ETH बैलेंस की जांच करता है
  2. कॉलिंग एड्रेस को फंड भेजता है
  3. उस यूज़र से अतिरिक्त निकासी को रोकने के लिए उनके बैलेंस को 0 में रीसेट करता है

Victim अनुबंध में withdraw() फंक्शन “चेक-इंटरैक्शन-इफेक्ट्स” पैटर्न का पालन करता है। यह जांचता है कि निष्पादन के लिए आवश्यक शर्तें पूरी हुई हैं या नहीं (यानी, यूज़र के पास सकारात्मक ETH बैलेंस है) और लेन-देन के प्रभावों को लागू करने से पहले कॉलर के पते पर ETH भेजकर इंटरैक्शन करता है (यानी, यूज़र का बैलेंस कम करना)।

यदि बाहरी स्वामित्व वाले खाते (EOA) से withdraw() को कॉल किया जाता है, तो फंक्शन अपेक्षित रूप से निष्पादित होता है: msg.sender.call.value() कॉलर को ETH भेजता है। हालाँकि, यदि msg.sender एक स्मार्ट अनुबंध खाता है जो withdraw() को कॉल करता है, तो msg.sender.call.value() का उपयोग करके धन भेजना भी उस पते पर संग्रहीत कोड को चलाने के लिए ट्रिगर करेगा।

कल्पना कीजिए कि यह अनुबंध पते पर परिनियोजित कोड है:

1 contract Attacker {
2    function beginAttack() external payable {
3        Victim(victim_address).deposit.value(1 ether)();
4        Victim(victim_address).withdraw();
5    }
6
7    function() external payable {
8        if (gasleft() > 40000) {
9            Victim(victim_address).withdraw();
10        }
11    }
12}
सभी दिखाएँ

यह अनुबंध तीन काम करने के लिए डिज़ाइन किया गया है:

  1. किसी अन्य खाते से जमा स्वीकार करें (संभवतः हमलावर का EOA)
  2. विक्टिम कॉन्ट्रैक्ट में 1 ETH को जमा करें
  3. स्मार्ट अनुबंध में संग्रहित 1 ETH को निकालें

यहां कुछ भी गलत नहीं है, सिवाय इसके कि Attacker के पास एक और फंक्शन है जो Victim में फिर से withdraw() को कॉल करता है यदि आने वाले msg.sender.call.value से बची हुई गैस 40,000 से अधिक है। यह Attacker को Victim में फिर से प्रवेश करने और withdraw का पहला आह्वान पूरा होने से पहले अधिक धनराशि निकालने की क्षमता देता है। चक्र इस तरह दिखता है:

1- हमलावर का EOA 1 ETH के साथ `Attacker.beginAttack()` को कॉल करता है
2- `Attacker.beginAttack()` `Victim` में 1 ETH जमा करता है
3- `Attacker` `Victim` में `withdraw()` को कॉल करता है
4- `Victim` `Attacker` के बैलेंस (1 ETH) की जांच करता है
5- `Victim` `Attacker` को 1 ETH भेजता है (जो डिफॉल्ट फंक्शन को ट्रिगर करता है)
6- `Attacker` फिर से `Victim.withdraw()` को कॉल करता है (ध्यान दें कि `Victim` ने पहली निकासी से `Attacker` का बैलेंस कम नहीं किया है)
7- `Victim` `Attacker` के बैलेंस की जांच करता है (जो अभी भी 1 ETH है क्योंकि इसने पहले कॉल के प्रभावों को लागू नहीं किया है)
8- `Victim` `Attacker` को 1 ETH भेजता है (जो डिफॉल्ट फंक्शन को ट्रिगर करता है और `Attacker` को `withdraw` फंक्शन में फिर से प्रवेश करने की अनुमति देता है)
9- यह प्रक्रिया तब तक दोहराई जाती है जब तक कि `Attacker` की गैस खत्म नहीं हो जाती, जिस बिंदु पर `msg.sender.call.value` अतिरिक्त निकासी को ट्रिगर किए बिना वापस आ जाता है
10- `Victim` अंत में पहले ट्रांजैक्शन (और बाद के) के परिणामों को अपनी स्थिति पर लागू करता है, इसलिए `Attacker` का बैलेंस 0 पर सेट हो जाता है
सभी दिखाएँ

सारांश यह है कि क्योंकि फंक्शन निष्पादन पूरा होने तक कॉलर की शेष राशि 0 पर सेट नहीं होती है, बाद के प्रयास सफल होंगे और कॉलर को कई बार अपनी शेष राशि वापस लेने की अनुमति देंगे। इस तरह के हमले का उपयोग किसी स्मार्ट अनुबंध के धन को निकालने के लिए किया जा सकता है, जैसा कि 2016 के डाओ हैक (opens in a new tab) में हुआ था। रीएंट्रेंसी हमले आज भी स्मार्ट अनुबंधों के लिए एक महत्वपूर्ण मुद्दा हैं जैसा कि रीएंट्रेंसी कारनामों की सार्वजनिक सूची (opens in a new tab) दिखाती है।

रीएंट्रेंसी हमलों को कैसे रोकें

रीएंट्रेंसी से निपटने का एक तरीका चेक-इफेक्ट्स-इंटरैक्शन्स पैटर्न (opens in a new tab) का पालन करना है। यह पैटर्न इस तरह से कार्यों के निष्पादन का आदेश देता है कि निष्पादन से पहले आवश्यक जांच करने वाला कोड पहले आता है, उसके बाद अनुबंध स्थिति में हेरफेर करने वाला कोड आता है, और अन्य अनुबंधों या EOA के साथ इंटरैक्शन करने वाला कोड अंत में आता है।

चेक-इफेक्ट-इंटरैक्शन पैटर्न का उपयोग नीचे दिखाए गए Victim अनुबंध के संशोधित संस्करण में किया गया है:

1contract NoLongerAVictim {
2    function withdraw() external {
3        uint256 amount = balances[msg.sender];
4        balances[msg.sender] = 0;
5        (bool success, ) = msg.sender.call.value(amount)("");
6        require(success);
7    }
8}

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

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

1pragma solidity ^0.7.0;
2
3contract MutexPattern {
4    bool locked = false;
5    mapping(address => uint256) public balances;
6
7    modifier noReentrancy() {
8        require(!locked, "रीएंट्रेंसी से ब्लॉक किया गया।");
9        locked = true;
10        _;
11        locked = false;
12    }
13    // यह फ़ंक्शन एक म्यूटेक्स द्वारा सुरक्षित है, इसलिए `msg.sender.call` के भीतर से रीएंट्रेंट कॉल फिर से `withdraw` को कॉल नहीं कर सकते हैं।
14    //  `return` स्टेटमेंट `true` का मूल्यांकन करता है लेकिन फिर भी मॉडिफायर में `locked = false` स्टेटमेंट का मूल्यांकन करता है
15    function withdraw(uint _amount) public payable noReentrancy returns(bool) {
16        require(balances[msg.sender] >= _amount, "निकालने के लिए कोई बैलेंस नहीं।");
17
18        balances[msg.sender] -= _amount;
19        (bool success, ) = msg.sender.call{value: _amount}("");
20        require(success);
21
22        return true;
23    }
24}
सभी दिखाएँ

आप एक पुल भुगतान (opens in a new tab) प्रणाली का भी उपयोग कर सकते हैं जिसमें उपयोगकर्ताओं को "पुश भुगतान" प्रणाली के बजाय स्मार्ट अनुबंधों से धन निकालने की आवश्यकता होती है जो खातों में धनराशि भेजती है। यह अज्ञात पतों पर अनजाने में कोड ट्रिगर करने की संभावना को हटा देता है (और कुछ इनकार-की-सेवा हमलों को भी रोक सकता है)।

पूर्णांक अंडरफ्लो और ओवरफ्लो

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

इन्टिजर अंडरफ्लो समान कारणों से होता है: अंकगणितीय ऑपरेशन के परिणाम स्वीकार्य सीमा से नीचे आते हैं। मान लें कि आपने एक uint8 में 0 को घटाने का प्रयास किया, तो परिणाम केवल अधिकतम प्रतिनिधित्व योग्य मान (255) पर रोल ओवर हो जाएगा।

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

1pragma solidity ^0.7.6;
2
3// यह अनुबंध एक टाइम वॉल्ट के रूप में कार्य करने के लिए डिज़ाइन किया गया है।
4// यूज़र इस अनुबंध में जमा कर सकता है लेकिन कम से कम एक सप्ताह तक निकाल नहीं सकता।
5// यूज़र 1 सप्ताह की प्रतीक्षा अवधि से अधिक प्रतीक्षा समय भी बढ़ा सकता है।
6
7/*
81. TimeLock को तैनात करें
92. TimeLock के पते के साथ अटैक को तैनात करें
103. 1 ईथर भेजकर Attack.attack को कॉल करें। आप तुरंत अपना ईथर
11   निकाल सकेंगे।
12
13क्या हुआ?
14अटैक के कारण TimeLock.lockTime ओवरफ्लो हो गया और वह 1 सप्ताह की प्रतीक्षा अवधि
15से पहले निकालने में सक्षम हो गया।
16*/
17
18contract TimeLock {
19    mapping(address => uint) public balances;
20    mapping(address => uint) public lockTime;
21
22    function deposit() external payable {
23        balances[msg.sender] += msg.value;
24        lockTime[msg.sender] = block.timestamp + 1 weeks;
25    }
26
27    function increaseLockTime(uint _secondsToIncrease) public {
28        lockTime[msg.sender] += _secondsToIncrease;
29    }
30
31    function withdraw() public {
32        require(balances[msg.sender] > 0, "अपर्याप्त धन");
33        require(block.timestamp > lockTime[msg.sender], "लॉक समय समाप्त नहीं हुआ है");
34
35        uint amount = balances[msg.sender];
36        balances[msg.sender] = 0;
37
38        (bool sent, ) = msg.sender.call{value: amount}("");
39        require(sent, "ईथर भेजने में विफल");
40    }
41}
42
43contract Attack {
44    TimeLock timeLock;
45
46    constructor(TimeLock _timeLock) {
47        timeLock = TimeLock(_timeLock);
48    }
49
50    fallback() external payable {}
51
52    function attack() public payable {
53        timeLock.deposit{value: msg.value}();
54        /*
55        यदि t = वर्तमान लॉक समय है तो हमें x ऐसा खोजना होगा
56        x + t = 2**256 = 0
57        इसलिए x = -t
58        2**256 = type(uint).max + 1
59        इसलिए x = type(uint).max + 1 - t
60        */
61        timeLock.increaseLockTime(
62            type(uint).max + 1 - timeLock.lockTime(address(this))
63        );
64        timeLock.withdraw();
65    }
66}
सभी दिखाएँ
इन्टिजर अंडरफ्लो और ओवरफ्लो को कैसे रोकें

संस्करण 0.8.0 के रूप में, सॉलिडिटी कंपाइलर कोड को अस्वीकार करता है जिसके परिणामस्वरूप इन्टिजर अंडरफ्लो और ओवरफ्लो होता है। हालांकि, निचले कंपाइलर संस्करण के साथ संकलित अनुबंधों को या तो अंकगणितीय संचालन से जुड़े फंक्शंस पर जांच करनी चाहिए या एक लाइब्रेरी (उदाहरण के लिए, SafeMath (opens in a new tab)) का उपयोग करना चाहिए जो अंडरफ्लो/ओवरफ्लो की जांच करती है।

ओरेकल हेरफेर

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

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

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

DEX की कीमतें अक्सर सटीक होती हैं, मुख्यतः मध्यस्थों द्वारा बाजारों में समानता बहाल करने के कारण। हालांकि, वे हेरफेर के लिए खुले हैं, खासकर अगर ऑन-चेन ओरेकल ऐतिहासिक ट्रेडिंग पैटर्न के आधार पर संपत्ति की कीमतों की गणना करता है (जैसा कि आमतौर पर होता है)।

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

ओरेकल हेरफेर को कैसे रोकें

ओरेकल हेरफेर से बचने (opens in a new tab) की न्यूनतम आवश्यकता एक विकेन्द्रीकृत ओरेकल नेटवर्क का उपयोग करना है, जो विफलता के एकल बिंदुओं से बचने के लिए कई स्रोतों से जानकारी लेता है। ज्यादातर मामलों में, विकेन्द्रीकृत ओरेकल्स में ओरेकल नोड्स को सही जानकारी की रिपोर्ट करने के लिए प्रोत्साहित करने के लिए बिल्ट-इन क्रिप्टोइकॉनॉमिक प्रोत्साहन होते हैं, जिससे वे केंद्रीकृत ओरेकल्स की तुलना में अधिक सुरक्षित हो जाते हैं।

यदि आप संपत्ति की कीमतों के लिए ऑन-चेन ओरेकल को क्वेरी करने की योजना बनाते हैं, तो समय-भारित औसत मूल्य (TWAP) तंत्र को लागू करने वाले का उपयोग करने पर विचार करें। एक TWAP ओरेकल (opens in a new tab) समय में दो अलग-अलग बिंदुओं पर एक संपत्ति की कीमत पूछता है (जिसे आप संशोधित कर सकते हैं) और प्राप्त औसत के आधार पर स्पॉट मूल्य की गणना करता है। लंबी समयावधि चुनना आपके प्रोटोकॉल को मूल्य हेरफेर से बचाता है क्योंकि हाल ही में निष्पादित बड़े ऑर्डर परिसंपत्ति की कीमतों को प्रभावित नहीं कर सकते हैं।

डेवलपर्स के लिए स्मार्ट अनुबंध सुरक्षा संसाधन

स्मार्ट अनुबंधों का विश्लेषण करने और कोड की शुद्धता सत्यापित करने के लिए उपकरण

  • परीक्षण उपकरण और लाइब्रेरी - स्मार्ट अनुबंधों पर यूनिट परीक्षण, स्टेटिक विश्लेषण और डायनामिक विश्लेषण करने के लिए उद्योग-मानक उपकरणों और लाइब्रेरी का संग्रह।

  • औपचारिक सत्यापन उपकरण - स्मार्ट अनुबंधों में कार्यात्मक शुद्धता को सत्यापित करने और इनवेरिएंट्स की जांच करने के लिए उपकरण।

  • स्मार्ट अनुबंध ऑडिटिंग सेवाएं - Ethereum विकास परियोजनाओं के लिए स्मार्ट अनुबंध ऑडिटिंग सेवाएं प्रदान करने वाले संगठनों की सूची।

  • बग बाउंटी प्लेटफॉर्म - बग बाउंटी के समन्वय और स्मार्ट अनुबंधों में महत्वपूर्ण कमजोरियों के जिम्मेदार प्रकटीकरण को पुरस्कृत करने के लिए प्लेटफॉर्म।

  • Fork Checker (opens in a new tab) - एक फोर्क किए गए अनुबंध के बारे में सभी उपलब्ध जानकारी की जांच करने के लिए एक मुफ्त ऑनलाइन उपकरण।

  • ABI Encoder (opens in a new tab) - आपके सॉलिडिटी अनुबंध फंक्शंस और कंस्ट्रक्टर आर्ग्यूमेंट्स को एन्कोड करने के लिए एक मुफ्त ऑनलाइन सेवा।

  • Aderyn (opens in a new tab) - Solidity स्टैटिक एनालाइज़र, जो संदिग्ध कमजोरियों की पहचान करने के लिए एब्सट्रैक्ट सिंटैक्स ट्री (AST) को पार करता है और आसानी से उपभोग्य मार्कडाउन प्रारूप में मुद्दों को प्रिंट करता है।

स्मार्ट अनुबंधों की निगरानी के लिए उपकरण

स्मार्ट अनुबंधों के सुरक्षित प्रशासन के लिए उपकरण

  • Safe (opens in a new tab) - Ethereum पर चलने वाला स्मार्ट अनुबंध वॉलेट जिसके लिए लेनदेन होने से पहले न्यूनतम संख्या में लोगों द्वारा अनुमोदित करने की आवश्यकता होती है (M-ऑफ-N)।

  • ओपनज़ेपेलिन Contracts (opens in a new tab) - अनुबंध स्वामित्व, अपग्रेड, एक्सेस कंट्रोल, शासन, पॉज़ेबिलिटी आदि सहित प्रशासनिक सुविधाओं को लागू करने के लिए अनुबंध लाइब्रेरी।

स्मार्ट अनुबंध ऑडिटिंग सेवाएं

  • कंसेंसिस Diligence (opens in a new tab) - स्मार्ट अनुबंध ऑडिटिंग सेवा जो ब्लॉकचेन पारिस्थितिकी तंत्र में प्रोजेक्ट्स की मदद करती है, जिससे यह सुनिश्चित होता है कि उनके प्रोटोकॉल लॉन्च के लिए तैयार हैं और उपयोगकर्ताओं की सुरक्षा के लिए बनाए गए हैं।

  • CertiK (opens in a new tab) - ब्लॉकचेन सुरक्षा फर्म जो स्मार्ट अनुबंधों और ब्लॉकचेन नेटवर्क पर अत्याधुनिक औपचारिक सत्यापन प्रौद्योगिकी के उपयोग में अग्रणी है।

  • ट्रेल ऑफ बिट्स (opens in a new tab) - साइबर सुरक्षा कंपनी जो जोखिम को कम करने और कोड को मजबूत करने के लिए सुरक्षा अनुसंधान को एक हमलावर मानसिकता के साथ जोड़ती है।

  • PeckShield (opens in a new tab) - ब्लॉकचेन सुरक्षा कंपनी जो संपूर्ण ब्लॉकचेन पारिस्थितिकी तंत्र की सुरक्षा, निजता और उपयोगिता के लिए उत्पाद और सेवाएँ प्रदान करती है।

  • QuantStamp (opens in a new tab) - ऑडिटिंग सेवा जो सुरक्षा और जोखिम मूल्यांकन सेवाओं के माध्यम से ब्लॉकचेन प्रौद्योगिकी के मुख्यधारा अपनाने की सुविधा प्रदान करती है।

  • ओपनज़ेपेलिन (opens in a new tab) - स्मार्ट अनुबंध सुरक्षा कंपनी जो वितरित प्रणालियों के लिए सुरक्षा ऑडिट प्रदान करती है।

  • Runtime Verification (opens in a new tab) - स्मार्ट अनुबंधों के औपचारिक मॉडलिंग और सत्यापन में विशेषज्ञता वाली सुरक्षा कंपनी।

  • Hacken (opens in a new tab) - Web3 साइबर सुरक्षा ऑडिटर जो ब्लॉकचेन सुरक्षा में 360-डिग्री दृष्टिकोण लाता है।

  • नेदरमाइंड (opens in a new tab) - Solidity और Cairo ऑडिटिंग सेवाएँ, जो एथेरियम और स्टार्कनेट पर स्मार्ट अनुबंधों की अखंडता और उपयोगकर्ताओं की सुरक्षा सुनिश्चित करती हैं।

  • HashEx (opens in a new tab) - HashEx क्रिप्टोकरेंसी की सुरक्षा सुनिश्चित करने के लिए ब्लॉकचेन और स्मार्ट अनुबंध ऑडिटिंग पर ध्यान केंद्रित करता है, जो स्मार्ट अनुबंध विकास, प्रवेश परीक्षण, ब्लॉकचेन परामर्श जैसी सेवाएँ प्रदान करता है।

  • Code4rena (opens in a new tab) - प्रतिस्पर्धी ऑडिट प्लेटफॉर्म जो स्मार्ट अनुबंध सुरक्षा विशेषज्ञों को कमजोरियाँ खोजने और web3 को अधिक सुरक्षित बनाने में मदद करने के लिए प्रोत्साहित करता है।

  • CodeHawks (opens in a new tab) - प्रतिस्पर्धी ऑडिट प्लेटफॉर्म जो सुरक्षा शोधकर्ताओं के लिए स्मार्ट अनुबंध ऑडिटिंग प्रतियोगिताओं की मेजबानी करता है।

  • Cyfrin (opens in a new tab) - Web3 सुरक्षा पावरहाउस, उत्पादों और स्मार्ट अनुबंध ऑडिटिंग सेवाओं के माध्यम से क्रिप्टो सुरक्षा को विकसित कर रहा है।

  • ImmuneBytes (opens in a new tab) - Web3 सुरक्षा फर्म जो अनुभवी लेखा परीक्षकों और सर्वोत्तम श्रेणी के उपकरणों की एक टीम के माध्यम से ब्लॉकचेन प्रणालियों के लिए सुरक्षा ऑडिट प्रदान करती है।

  • Oxorio (opens in a new tab) - स्मार्ट अनुबंध ऑडिट और ब्लॉकचेन सुरक्षा सेवाएँ जो क्रिप्टो फर्मों और डीफाई प्रोजेक्ट्स के लिए EVM, सॉलिडिटी, ZK, क्रॉस-चेन तकनीक में विशेषज्ञता रखती हैं।

  • Inference (opens in a new tab) - सुरक्षा ऑडिटिंग कंपनी, जो EVM-आधारित ब्लॉकचेन के लिए स्मार्ट अनुबंध ऑडिटिंग में विशेषज्ञता रखती है। अपने विशेषज्ञ लेखा परीक्षकों के कारण वे संभावित मुद्दों की पहचान करते हैं और परिनियोजित करने से पहले उन्हें ठीक करने के लिए कार्रवाई योग्य समाधान सुझाते हैं।

बग बाउंटी प्लेटफॉर्म

  • Immunefi (opens in a new tab) - स्मार्ट अनुबंधों और डीफाई प्रोजेक्ट्स के लिए बग बाउंटी प्लेटफॉर्म, जहाँ सुरक्षा शोधकर्ता कोड की समीक्षा करते हैं, कमजोरियों का खुलासा करते हैं, भुगतान प्राप्त करते हैं, और क्रिप्टो को अधिक सुरक्षित बनाते हैं।

  • HackerOne (opens in a new tab) - कमजोरी समन्वय और बग बाउंटी प्लेटफॉर्म जो व्यवसायों को प्रवेश परीक्षकों और साइबर सुरक्षा शोधकर्ताओं से जोड़ता है।

  • HackenProof (opens in a new tab) - क्रिप्टो प्रोजेक्ट्स (डीफाई, स्मार्ट अनुबंध, वॉलेट, CEX आदि) के लिए विशेषज्ञ बग बाउंटी प्लेटफॉर्म, जहाँ सुरक्षा पेशेवर ट्राइएज सेवाएँ प्रदान करते हैं और शोधकर्ताओं को प्रासंगिक, सत्यापित बग रिपोर्ट के लिए भुगतान किया जाता है।

  • Sherlock (opens in a new tab) - Web3 में स्मार्ट अनुबंध सुरक्षा के लिए अंडरराइटर, जहाँ लेखा परीक्षकों के लिए भुगतान स्मार्ट अनुबंधों के माध्यम से प्रबंधित किया जाता है ताकि यह सुनिश्चित हो सके कि प्रासंगिक बग्स का निष्पक्ष रूप से भुगतान किया जाए।

  • CodeHawks (opens in a new tab) - प्रतिस्पर्धी बग बाउंटी प्लेटफॉर्म जहाँ लेखा परीक्षक सुरक्षा प्रतियोगिताओं और चुनौतियों, और (जल्द ही) अपने निजी लेखा परीक्षण में भाग लेते हैं।

ज्ञात स्मार्ट अनुबंध कमजोरियों और कारनामों का प्रकाशन

  • कंसेंसिस: स्मार्ट अनुबंध ज्ञात हमले (opens in a new tab) - सबसे महत्वपूर्ण अनुबंध कमजोरियों की शुरुआती-अनुकूल व्याख्या, अधिकांश मामलों के लिए नमूना कोड के साथ।

  • SWC रजिस्ट्री (opens in a new tab) - सामान्य कमजोरी गणना (CWE) आइटम्स की संग्रहित सूची जो एथेरियम स्मार्ट अनुबंधों पर लागू होती है।

  • Rekt (opens in a new tab) - उच्च-प्रोफाइल क्रिप्टो हैक और शोषण का नियमित रूप से अपडेट किया गया प्रकाशन, विस्तृत पोस्ट-मॉर्टम रिपोर्ट के साथ।

स्मार्ट अनुबंध सुरक्षा सीखने के लिए चुनौतियां

  • Awesome BlockSec CTF (opens in a new tab) - ब्लॉकचेन सुरक्षा वॉरगेम्स, चुनौतियों, और कैप्चर द फ्लैग (opens in a new tab) प्रतियोगिताओं और समाधान राइटअप्स की संग्रहित सूची।

  • Damn Vulnerable डीफाई (opens in a new tab) - DeFi स्मार्ट अनुबंधों की आक्रामक सुरक्षा सीखने और बग-शिकार और सुरक्षा ऑडिटिंग में कौशल विकसित करने के लिए वॉरगेम।

  • Ethernaut (opens in a new tab) - Web3/सॉलिडिटी-आधारित वॉरगेम जहाँ प्रत्येक स्तर एक स्मार्ट अनुबंध है जिसे 'हैक' करने की आवश्यकता होती है।

  • HackenProof x HackTheBox (opens in a new tab) - स्मार्ट अनुबंध हैकिंग चुनौती, एक फंतासी साहसिक में सेट। चुनौती को सफलतापूर्वक पूरा करने पर एक निजी बग बाउंटी कार्यक्रम की एक्सेस भी मिलती है।

स्मार्ट अनुबंधों को सुरक्षित करने के लिए सर्वोत्तम प्रथाएं

स्मार्ट अनुबंध सुरक्षा पर ट्यूटोरियल

क्या यह लेख सहायक था?