---
title: "سمارٹ کنٹریکٹ سیکیورٹی کے رہنما اصول"
description: "اپنی ⁦dapp⁩ بناتے وقت غور کرنے کے لیے سیکیورٹی رہنما اصولوں کی ایک چیک لسٹ"
author: Trailofbits
tags:
  - solidity
  - سمارٹ کنٹریکٹس
  - سیکیورٹی
skill: intermediate
breadcrumb: "سیکیورٹی کے رہنما اصول"
lang: ur
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) مشین۔ [سلدر (Slither) پرنٹرز](https://github.com/crytic/slither/wiki/Printer-documentation) ان سکیموں کو بنانے میں مدد کر سکتے ہیں۔
- **کوڈ کی مکمل دستاویزات**، <span dir="ltr">Solidity</span> کے لیے [<span dir="ltr">NatSpec</span> فارمیٹ](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/) میں اپ گریڈ کرنے کے مختلف حلوں پر تبادلہ خیال کیا ہے۔ کوئی بھی کوڈ لکھنے سے پہلے اپ گریڈ کرنے کی صلاحیت کو سپورٹ کرنے یا نہ کرنے کا شعوری انتخاب کریں۔ یہ فیصلہ اس بات پر اثر انداز ہوگا کہ آپ اپنے کوڈ کی ساخت کیسے بناتے ہیں۔ عام طور پر، ہم تجویز کرتے ہیں:

- **اپ گریڈ کرنے کی صلاحیت پر [کنٹریکٹ مائیگریشن](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) کو ترجیح دیں۔** مائیگریشن سسٹمز کے بہت سے وہی فوائد ہیں جو اپ گریڈ ایبل سسٹمز کے ہیں، لیکن ان کی خامیوں کے بغیر۔
- **<span dir="ltr">delegatecallproxy</span> پیٹرن پر ڈیٹا علیحدگی (data separation) پیٹرن کا استعمال کریں۔** اگر آپ کے پروجیکٹ میں واضح تجریدی علیحدگی (abstraction separation) ہے، تو ڈیٹا علیحدگی کا استعمال کرتے ہوئے اپ گریڈ کرنے کی صلاحیت کے لیے صرف چند ایڈجسٹمنٹس کی ضرورت ہوگی۔ <span dir="ltr">delegatecallproxy</span> کے لیے <span dir="ltr">EVM</span> کی مہارت درکار ہوتی ہے اور اس میں غلطی کا امکان بہت زیادہ ہوتا ہے۔
- **تعیناتی سے پہلے مائیگریشن/اپ گریڈ کے طریقہ کار کو دستاویزی شکل دیں۔** اگر آپ کو بغیر کسی رہنما اصول کے دباؤ میں ردعمل ظاہر کرنا پڑا، تو آپ غلطیاں کریں گے۔ عمل کرنے کا طریقہ کار پہلے سے لکھ لیں۔ اس میں شامل ہونا چاہیے:
  - وہ کالز جو نئے کنٹریکٹس شروع کرتی ہیں
  - کیز (keys) کہاں محفوظ ہیں اور ان تک کیسے رسائی حاصل کی جائے
  - تعیناتی کو کیسے چیک کریں! تعیناتی کے بعد کی سکرپٹ تیار کریں اور اس کا ٹیسٹ کریں۔

## نفاذ کے رہنما اصول {#implementation-guidelines}

**سادگی کے لیے کوشش کریں۔** ہمیشہ وہ آسان ترین حل استعمال کریں جو آپ کے مقصد کے مطابق ہو۔ آپ کی ٹیم کے کسی بھی رکن کو آپ کا حل سمجھنے کے قابل ہونا چاہیے۔

### فنکشن کی ترکیب {#function-composition}

آپ کے کوڈ بیس کا آرکیٹیکچر ایسا ہونا چاہیے کہ آپ کے کوڈ کا جائزہ لینا آسان ہو۔ ایسے آرکیٹیکچرل انتخاب سے گریز کریں جو اس کی درستگی کے بارے میں استدلال کرنے کی صلاحیت کو کم کرتے ہیں۔

- **اپنے سسٹم کی منطق (logic) کو تقسیم کریں**، یا تو متعدد کنٹریکٹس کے ذریعے یا ملتے جلتے فنکشنز کو ایک ساتھ گروپ کر کے (مثال کے طور پر، تصدیق، ریاضی، ...)۔
- **واضح مقصد کے ساتھ چھوٹے فنکشنز لکھیں۔** اس سے جائزے میں آسانی ہوگی اور انفرادی اجزاء کی ٹیسٹنگ ممکن ہو سکے گی۔

### وراثت (Inheritance) {#inheritance}

- **وراثت کو قابل انتظام رکھیں۔** وراثت کا استعمال منطق کو تقسیم کرنے کے لیے کیا جانا چاہیے، تاہم، آپ کے پروجیکٹ کا مقصد وراثت کے درخت (inheritance tree) کی گہرائی اور چوڑائی کو کم سے کم کرنا ہونا چاہیے۔
- **کنٹریکٹس کی درجہ بندی (hierarchy) چیک کرنے کے لیے سلدر کے [انہیرٹنس پرنٹر](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) کا استعمال کریں۔** انہیرٹنس پرنٹر آپ کو درجہ بندی کے سائز کا جائزہ لینے میں مدد کرے گا۔

### ایونٹس {#events}

- **تمام اہم کاموں کو لاگ کریں۔** ایونٹس ڈیولپمنٹ کے دوران کنٹریکٹ کو ڈیبگ کرنے اور تعیناتی کے بعد اس کی نگرانی کرنے میں مدد کریں گے۔

### معلوم خامیوں سے بچیں {#avoid-known-pitfalls}

- **سب سے عام سیکیورٹی مسائل سے آگاہ رہیں۔** عام مسائل کے بارے میں جاننے کے لیے بہت سے آن لائن وسائل موجود ہیں، جیسے [<span dir="ltr">Ethernaut CTF</span>](https://ethernaut.openzeppelin.com/)، [<span dir="ltr">Capture the Ether</span>](https://capturetheether.com/)، یا [<span dir="ltr">Not so smart contracts</span>](https://github.com/crytic/not-so-smart-contracts/)۔
- **[<span dir="ltr">Solidity</span> کی دستاویزات](https://docs.soliditylang.org/en/latest/) میں وارننگ سیکشنز سے آگاہ رہیں۔** وارننگ سیکشنز آپ کو زبان کے غیر واضح رویے کے بارے میں آگاہ کریں گے۔

### انحصار (Dependencies) {#dependencies}

- **اچھی طرح سے ٹیسٹ کی گئی لائبریریاں استعمال کریں۔** اچھی طرح سے ٹیسٹ کی گئی لائبریریوں سے کوڈ امپورٹ کرنے سے اس بات کا امکان کم ہو جائے گا کہ آپ بگز والا کوڈ لکھیں۔ اگر آپ <span dir="ltr">ERC-20</span> کنٹریکٹ لکھنا چاہتے ہیں، تو [اوپن زیپلن](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20) استعمال کریں۔
- **ڈیپینڈنسی مینیجر استعمال کریں؛ کوڈ کو کاپی پیسٹ کرنے سے گریز کریں۔** اگر آپ کسی بیرونی ذریعہ پر انحصار کرتے ہیں، تو آپ کو اسے اصل ذریعہ کے ساتھ اپ ٹو ڈیٹ رکھنا چاہیے۔

### ٹیسٹنگ اور تصدیق {#testing-and-verification}

- **مکمل یونٹ ٹیسٹ لکھیں۔** اعلیٰ معیار کا سافٹ ویئر بنانے کے لیے ایک وسیع ٹیسٹ سویٹ بہت ضروری ہے۔
- **[سلدر](https://github.com/crytic/slither)، [ایکڈنا](https://github.com/crytic/echidna) اور [مینٹیکور](https://github.com/trailofbits/manticore) کی کسٹم چیکس اور پراپرٹیز لکھیں۔** خودکار ٹولز یہ یقینی بنانے میں مدد کریں گے کہ آپ کا کنٹریکٹ محفوظ ہے۔ موثر چیکس اور پراپرٹیز لکھنے کا طریقہ سیکھنے کے لیے اس گائیڈ کے باقی حصے کا جائزہ لیں۔
- **[<span dir="ltr">crytic.io</span>](https://crytic.io/) استعمال کریں۔** <span dir="ltr">Crytic</span> <span dir="ltr">GitHub</span> کے ساتھ مربوط ہوتا ہے، نجی سلدر ڈیٹیکٹرز تک رسائی فراہم کرتا ہے، اور ایکڈنا سے کسٹم پراپرٹی چیکس چلاتا ہے۔

### Solidity {#solidity}

- **<span dir="ltr">Solidity 0.4</span> اور <span dir="ltr">0.6</span> کے مقابلے میں <span dir="ltr">Solidity 0.5</span> کو ترجیح دیں۔** ہماری رائے میں، <span dir="ltr">Solidity 0.5</span> زیادہ محفوظ ہے اور اس میں <span dir="ltr">0.4</span> کے مقابلے میں بہتر بلٹ ان پریکٹسز ہیں۔ <span dir="ltr">Solidity 0.6</span> پروڈکشن کے لیے بہت غیر مستحکم ثابت ہوئی ہے اور اسے پختہ ہونے کے لیے وقت درکار ہے۔
- **کمپائل کرنے کے لیے ایک مستحکم ریلیز استعمال کریں؛ وارننگز چیک کرنے کے لیے تازہ ترین ریلیز استعمال کریں۔** چیک کریں کہ آپ کے کوڈ میں تازہ ترین کمپائلر ورژن کے ساتھ کوئی رپورٹ شدہ مسائل نہیں ہیں۔ تاہم، <span dir="ltr">Solidity</span> کا ریلیز سائیکل تیز ہے اور اس میں کمپائلر بگز کی تاریخ رہی ہے، اس لیے ہم تعیناتی کے لیے تازہ ترین ورژن کی سفارش نہیں کرتے (سلدر کی [<span dir="ltr">solc</span> ورژن کی سفارش](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) دیکھیں)۔
- **ان لائن اسمبلی (inline assembly) استعمال نہ کریں۔** اسمبلی کے لیے <span dir="ltr">EVM</span> کی مہارت درکار ہوتی ہے۔ اگر آپ نے یلو پیپر پر _عبور_ حاصل نہیں کیا ہے تو <span dir="ltr">EVM</span> کوڈ نہ لکھیں۔

## تعیناتی کے رہنما اصول {#deployment-guidelines}

ایک بار جب کنٹریکٹ تیار اور تعینات ہو جائے:

- **اپنے کنٹریکٹس کی نگرانی کریں۔** لاگز دیکھیں، اور کنٹریکٹ یا والیٹ کے سمجھوتے (compromise) کی صورت میں ردعمل ظاہر کرنے کے لیے تیار رہیں۔
- **اپنی رابطہ کی معلومات [<span dir="ltr">blockchain-security-contacts</span>](https://github.com/crytic/blockchain-security-contacts) میں شامل کریں۔** اگر کوئی سیکیورٹی خامی دریافت ہوتی ہے تو یہ فہرست فریق ثالث کو آپ سے رابطہ کرنے میں مدد کرتی ہے۔
- **مراعات یافتہ صارفین کے والیٹس کو محفوظ بنائیں۔** اگر آپ ہارڈویئر والیٹس میں کیز محفوظ کرتے ہیں تو ہماری [بہترین پریکٹسز](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) پر عمل کریں۔
- **واقعے پر ردعمل کا منصوبہ (response to incident plan) رکھیں۔** اس بات پر غور کریں کہ آپ کے سمارٹ کنٹریکٹس سے سمجھوتہ کیا جا سکتا ہے۔ یہاں تک کہ اگر آپ کے کنٹریکٹس بگز سے پاک ہیں، تب بھی ایک حملہ آور کنٹریکٹ کے مالک کی کیز کا کنٹرول سنبھال سکتا ہے۔