---
title: "स्मार्ट कॉन्ट्रॅक्ट सुरक्षा मार्गदर्शक तत्त्वे"
description: "तुमचे डॅप (dapp) तयार करताना विचारात घेण्यासारख्या सुरक्षा मार्गदर्शक तत्त्वांची चेकलिस्ट"
author: "Trailofbits"
tags: ["Solidity", "स्मार्ट कॉन्ट्रॅक्ट्स", "सुरक्षा"]
skill: intermediate
breadcrumb: "सुरक्षा मार्गदर्शक तत्त्वे"
lang: mr
published: 2020-09-06
source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---

अधिक सुरक्षित स्मार्ट कॉन्ट्रॅक्ट्स तयार करण्यासाठी या उच्च-स्तरीय शिफारसींचे अनुसरण करा.

## डिझाइन मार्गदर्शक तत्त्वे {#design-guidelines}

कोडची कोणतीही ओळ लिहिण्यापूर्वी, कॉन्ट्रॅक्टच्या डिझाइनवर आधीच चर्चा केली पाहिजे.

### दस्तऐवजीकरण आणि तपशील {#documentation-and-specifications}

दस्तऐवजीकरण वेगवेगळ्या स्तरांवर लिहिले जाऊ शकते आणि कॉन्ट्रॅक्ट्सची अंमलबजावणी करताना ते अद्ययावत केले पाहिजे:

- **सिस्टमचे साध्या भाषेतील वर्णन**, ज्यामध्ये कॉन्ट्रॅक्ट्स काय करतात आणि कोडबेसमधील कोणत्याही गृहितकांचे वर्णन केलेले असते.
- **स्कीमा आणि आर्किटेक्चरल आकृत्या**, ज्यामध्ये कॉन्ट्रॅक्टमधील परस्परसंवाद आणि सिस्टमच्या स्थिती (state) मशीनचा समावेश असतो. [स्लिदर प्रिंटर्स](https://github.com/crytic/slither/wiki/Printer-documentation) हे स्कीमा तयार करण्यात मदत करू शकतात.
- **सखोल कोड दस्तऐवजीकरण**, Solidity साठी [NatSpec फॉरमॅट](https://docs.soliditylang.org/en/develop/natspec-format.html) वापरला जाऊ शकतो.

### ऑनचेन विरुद्ध साखळीबाह्य संगणन {#onchain-vs-offchain-computation}

- **शक्य तितका कोड साखळीबाह्य ठेवा.** ऑनचेन स्तर लहान ठेवा. साखळीबाह्य कोडसह डेटावर अशा प्रकारे पूर्व-प्रक्रिया करा की ऑनचेन पडताळणी सोपी होईल. तुम्हाला क्रमवारी लावलेली यादी हवी आहे का? यादीची साखळीबाह्य क्रमवारी लावा, आणि नंतर फक्त ऑनचेन तिचा क्रम तपासा.

### अपग्रेड करण्याची क्षमता {#upgradeability}

आम्ही [आमच्या ब्लॉगपोस्टमध्ये](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) अपग्रेड करण्याच्या विविध उपायांवर चर्चा केली आहे. कोणताही कोड लिहिण्यापूर्वी अपग्रेड करण्याच्या क्षमतेला समर्थन द्यायचे की नाही याचा जाणीवपूर्वक निर्णय घ्या. या निर्णयाचा तुमच्या कोडच्या रचनेवर प्रभाव पडेल. सर्वसाधारणपणे, आम्ही खालील शिफारस करतो:

- **अपग्रेड करण्याच्या क्षमतेपेक्षा [कॉन्ट्रॅक्ट स्थलांतराला (migration)](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) प्राधान्य देणे.** स्थलांतर प्रणालींमध्ये अपग्रेड करण्यायोग्य प्रणालींसारखेच अनेक फायदे असतात, परंतु त्यांच्यातील त्रुटी नसतात.
- **delegatecallproxy पॅटर्नपेक्षा डेटा सेपरेशन पॅटर्न वापरणे.** जर तुमच्या प्रोजेक्टमध्ये स्पष्ट ॲब्स्ट्रॅक्शन सेपरेशन असेल, तर डेटा सेपरेशन वापरून अपग्रेड करण्यासाठी फक्त काही बदलांची आवश्यकता असेल. delegatecallproxy साठी EVM चे तज्ञ असणे आवश्यक आहे आणि त्यात चुका होण्याची शक्यता खूप जास्त असते.
- **प्रस्थापना करण्यापूर्वी स्थलांतर/अपग्रेड प्रक्रियेचे दस्तऐवजीकरण करा.** जर तुम्हाला कोणत्याही मार्गदर्शक तत्त्वांशिवाय तणावाखाली प्रतिक्रिया द्यावी लागली, तर तुमच्याकडून चुका होतील. अनुसरण करण्याची प्रक्रिया आधीच लिहून ठेवा. यामध्ये खालील गोष्टींचा समावेश असावा:
  - नवीन कॉन्ट्रॅक्ट्स सुरू करणारे कॉल्स
  - कीज (keys) कुठे साठवल्या आहेत आणि त्या कशा ॲक्सेस करायच्या
  - प्रस्थापना कशी तपासायची! प्रस्थापनेनंतरची स्क्रिप्ट विकसित करा आणि तिची चाचणी घ्या.

## अंमलबजावणी मार्गदर्शक तत्त्वे {#implementation-guidelines}

**साधेपणासाठी प्रयत्न करा.** नेहमी तुमच्या उद्देशाला साजेसा सर्वात सोपा उपाय वापरा. तुमच्या टीममधील कोणत्याही सदस्याला तुमचा उपाय समजला पाहिजे.

### फंक्शन रचना {#function-composition}

तुमच्या कोडबेसचे आर्किटेक्चर असे असावे की ज्यामुळे तुमच्या कोडचे पुनरावलोकन करणे सोपे होईल. असे आर्किटेक्चरल पर्याय टाळा जे त्याच्या अचूकतेबद्दल तर्क करण्याची क्षमता कमी करतात.

- **तुमच्या सिस्टमचे लॉजिक विभाजित करा**, एकतर अनेक कॉन्ट्रॅक्ट्सद्वारे किंवा समान फंक्शन्स एकत्र करून (उदा. प्रमाणीकरण, अंकगणित, ...).
- **स्पष्ट उद्देश असलेली लहान फंक्शन्स लिहा.** यामुळे पुनरावलोकन करणे सोपे होईल आणि वैयक्तिक घटकांची चाचणी घेता येईल.

### इनहेरिटन्स {#inheritance}

- **इनहेरिटन्स आटोपशीर ठेवा.** लॉजिक विभाजित करण्यासाठी इनहेरिटन्सचा वापर केला पाहिजे, तथापि, तुमच्या प्रोजेक्टचे उद्दिष्ट इनहेरिटन्स ट्रीची खोली आणि रुंदी कमीत कमी ठेवणे हे असले पाहिजे.
- **कॉन्ट्रॅक्ट्सची पदानुक्रम (hierarchy) तपासण्यासाठी स्लिदरच्या [इनहेरिटन्स प्रिंटरचा](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) वापर करा.** इनहेरिटन्स प्रिंटर तुम्हाला पदानुक्रमाच्या आकाराचे पुनरावलोकन करण्यास मदत करेल.

### घटना {#events}

- **सर्व महत्त्वपूर्ण ऑपरेशन्सची नोंद ठेवा.** घटना विकास प्रक्रियेदरम्यान कॉन्ट्रॅक्ट डीबग करण्यास आणि प्रस्थापनेनंतर त्यावर लक्ष ठेवण्यास मदत करतील.

### ज्ञात धोके टाळा {#avoid-known-pitfalls}

- **सर्वात सामान्य सुरक्षा समस्यांबद्दल जागरूक रहा.** सामान्य समस्यांबद्दल जाणून घेण्यासाठी अनेक ऑनलाइन संसाधने आहेत, जसे की [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/), किंवा [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/).
- **[Solidity दस्तऐवजीकरणातील](https://docs.soliditylang.org/en/latest/) चेतावणी विभागांबद्दल जागरूक रहा.** चेतावणी विभाग तुम्हाला भाषेच्या अस्पष्ट वर्तनाबद्दल माहिती देतील.

### अवलंबित्व {#dependencies}

- **चांगली चाचणी केलेल्या लायब्ररी वापरा.** चांगली चाचणी केलेल्या लायब्ररींमधून कोड आयात केल्याने तुम्ही सदोष कोड लिहिण्याची शक्यता कमी होईल. जर तुम्हाला ERC-20 कॉन्ट्रॅक्ट लिहायचे असेल, तर [ओपनझेपलिन](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20) वापरा.
- **डिपेंडन्सी मॅनेजर वापरा; कोड कॉपी-पेस्ट करणे टाळा.** जर तुम्ही बाह्य स्रोतावर अवलंबून असाल, तर तुम्ही तो मूळ स्रोतासोबत अद्ययावत ठेवला पाहिजे.

### चाचणी आणि पडताळणी {#testing-and-verification}

- **सखोल युनिट-टेस्ट्स लिहा.** उच्च-गुणवत्तेचे सॉफ्टवेअर तयार करण्यासाठी एक विस्तृत चाचणी संच (test suite) महत्त्वपूर्ण आहे.
- **[स्लिदर](https://github.com/crytic/slither), [एकिडना](https://github.com/crytic/echidna) आणि [मॅन्टिकोर](https://github.com/trailofbits/manticore) कस्टम चेक्स आणि प्रॉपर्टीज लिहा.** स्वयंचलित साधने तुमचे कॉन्ट्रॅक्ट सुरक्षित असल्याची खात्री करण्यास मदत करतील. कार्यक्षम चेक्स आणि प्रॉपर्टीज कशा लिहायच्या हे जाणून घेण्यासाठी या मार्गदर्शकाचा उर्वरित भाग वाचा.
- **[crytic.io](https://crytic.io/) वापरा.** Crytic हे GitHub सोबत जोडले जाते, खाजगी स्लिदर डिटेक्टर्सचा ॲक्सेस प्रदान करते आणि एकिडनामधून कस्टम प्रॉपर्टी चेक्स चालवते.

### Solidity {#solidity}

- **0.4 आणि 0.6 पेक्षा Solidity 0.5 ला प्राधान्य द्या.** आमच्या मते, Solidity 0.5 हे 0.4 पेक्षा अधिक सुरक्षित आहे आणि त्यात अधिक चांगल्या अंगभूत पद्धती आहेत. Solidity 0.6 हे उत्पादनासाठी खूप अस्थिर सिद्ध झाले आहे आणि त्याला परिपक्व होण्यासाठी वेळ हवा आहे.
- **कंपाइल करण्यासाठी स्थिर आवृत्ती वापरा; चेतावणी तपासण्यासाठी नवीनतम आवृत्ती वापरा.** नवीनतम कंपायलर आवृत्तीसह तुमच्या कोडमध्ये कोणतीही नोंदवलेली समस्या नाही हे तपासा. तथापि, Solidity चे रिलीज सायकल वेगवान आहे आणि त्यात कंपायलर बग्सचा इतिहास आहे, त्यामुळे आम्ही प्रस्थापनेसाठी नवीनतम आवृत्तीची शिफारस करत नाही (स्लिदरची [solc आवृत्ती शिफारस](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) पहा).
- **इनलाइन असेंब्ली वापरू नका.** असेंब्लीसाठी EVM चे तज्ञ असणे आवश्यक आहे. जर तुम्ही येलो पेपरमध्ये _प्राविण्य_ मिळवले नसेल तर EVM कोड लिहू नका.

## प्रस्थापना मार्गदर्शक तत्त्वे {#deployment-guidelines}

एकदा कॉन्ट्रॅक्ट विकसित आणि प्रस्थापित झाल्यानंतर:

- **तुमच्या कॉन्ट्रॅक्ट्सवर लक्ष ठेवा.** नोंदी (logs) पहा, आणि कॉन्ट्रॅक्ट किंवा वॉलेट धोक्यात आल्यास प्रतिक्रिया देण्यासाठी तयार रहा.
- **तुमची संपर्क माहिती [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts) मध्ये जोडा.** जर एखादी सुरक्षा त्रुटी आढळली तर ही यादी तृतीय-पक्षांना तुमच्याशी संपर्क साधण्यास मदत करते.
- **विशेषाधिकार प्राप्त वापरकर्त्यांचे वॉलेट्स सुरक्षित करा.** जर तुम्ही हार्डवेअर वॉलेट्समध्ये कीज साठवत असाल तर आमच्या [सर्वोत्तम पद्धतींचे](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) अनुसरण करा.
- **घटनेला प्रतिसाद देण्याची योजना तयार ठेवा.** तुमचे स्मार्ट कॉन्ट्रॅक्ट्स धोक्यात येऊ शकतात याचा विचार करा. जरी तुमचे कॉन्ट्रॅक्ट्स बग-मुक्त असले, तरीही एखादा हल्लेखोर कॉन्ट्रॅक्ट मालकाच्या कीजवर नियंत्रण मिळवू शकतो.