---
title: "سمارٹ کنٹریکٹ کی سیکیورٹی"
description: "محفوظ ایتھیریم سمارٹ کنٹریکٹس بنانے کے لیے رہنما خطوط کا جائزہ"
lang: ur
---

سمارٹ کنٹریکٹس انتہائی لچکدار ہوتے ہیں، اور بڑی مقدار میں مالیت اور ڈیٹا کو کنٹرول کرنے کی صلاحیت رکھتے ہیں، جبکہ بلاک چین پر تعینات کوڈ پر مبنی ناقابلِ تبدیلی منطق چلاتے ہیں۔ اس نے بلا اعتماد اور لامركزی ایپلی کیشنز کا ایک متحرک ایکو سسٹم بنایا ہے جو روایتی سسٹمز کے مقابلے میں کئی فوائد فراہم کرتا ہے۔ یہ ان حملہ آوروں کے لیے مواقع بھی پیش کرتے ہیں جو سمارٹ کنٹریکٹس میں موجود خامیوں کا فائدہ اٹھا کر منافع کمانا چاہتے ہیں۔

پبلک بلاک چینز، جیسے [ایتھیریم](/)، سمارٹ کنٹریکٹس کو محفوظ بنانے کے مسئلے کو مزید پیچیدہ کر دیتی ہیں۔ تعینات شدہ کنٹریکٹ کوڈ کو _عام طور پر_ سیکیورٹی خامیوں کو دور کرنے کے لیے تبدیل نہیں کیا جا سکتا، جبکہ سمارٹ کنٹریکٹس سے چوری ہونے والے اثاثوں کو ٹریک کرنا انتہائی مشکل ہوتا ہے اور ناقابلیتِ تبدیلی کی وجہ سے زیادہ تر ناقابلِ واپسی ہوتے ہیں۔

اگرچہ اعداد و شمار مختلف ہیں، لیکن اندازہ لگایا گیا ہے کہ سمارٹ کنٹریکٹس میں سیکیورٹی نقائص کی وجہ سے چوری ہونے والی یا ضائع ہونے والی کل مالیت باآسانی <span dir="ltr">$1</span> بلین سے زیادہ ہے۔ اس میں ہائی پروفائل واقعات شامل ہیں، جیسے کہ [DAO ہیک](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (<span dir="ltr">3.6M ETH</span> چوری ہوئے، جن کی مالیت آج کی قیمتوں میں <span dir="ltr">$1B</span> سے زیادہ ہے)، [Parity ملٹی سگ والیٹ ہیک](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) (ہیکرز کے ہاتھوں <span dir="ltr">$30M</span> کا نقصان)، اور [Parity فروزن والیٹ کا مسئلہ](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (ہمیشہ کے لیے لاک شدہ <span dir="ltr">ETH</span> میں <span dir="ltr">$300M</span> سے زیادہ)۔

مذکورہ بالا مسائل ڈیولپرز کے لیے یہ ناگزیر بناتے ہیں کہ وہ محفوظ، مضبوط اور لچکدار سمارٹ کنٹریکٹس بنانے میں اپنی کوششیں صرف کریں۔ سمارٹ کنٹریکٹ کی سیکیورٹی ایک سنجیدہ معاملہ ہے، اور ہر ڈیولپر کے لیے اسے سیکھنا بہتر ہوگا۔ یہ گائیڈ ایتھیریم ڈیولپرز کے لیے سیکیورٹی کے حوالے سے غور طلب امور کا احاطہ کرے گی اور سمارٹ کنٹریکٹ کی سیکیورٹی کو بہتر بنانے کے وسائل کا جائزہ لے گی۔

## پیشگی شرائط {#prerequisites}

سیکیورٹی کے معاملات پر کام کرنے سے پہلے، یقینی بنائیں کہ آپ [سمارٹ کنٹریکٹ ڈیولپمنٹ کے بنیادی اصولوں](/developers/docs/smart-contracts/) سے واقف ہیں۔

## محفوظ ایتھیریم سمارٹ کنٹریکٹس بنانے کے لیے رہنما خطوط {#smart-contract-security-guidelines}

### 1. مناسب رسائی کے کنٹرولز ڈیزائن کریں {#design-proper-access-controls}

سمارٹ کنٹریکٹس میں، `public` یا `external` کے طور پر نشان زدہ فنکشنز کو کسی بھی بیرونی ملکیت والے اکاؤنٹس (EOAs) یا کنٹریکٹ اکاؤنٹس کے ذریعے کال کیا جا سکتا ہے۔ اگر آپ چاہتے ہیں کہ دوسرے آپ کے کنٹریکٹ کے ساتھ تعامل کریں تو فنکشنز کے لیے عوامی مرئیت (public visibility) کی وضاحت کرنا ضروری ہے۔ تاہم `private` کے طور پر نشان زدہ فنکشنز کو صرف سمارٹ کنٹریکٹ کے اندر موجود فنکشنز کے ذریعے کال کیا جا سکتا ہے، اور بیرونی اکاؤنٹس کے ذریعے نہیں۔ ہر نیٹ ورک شریک کو کنٹریکٹ فنکشنز تک رسائی دینا مسائل کا سبب بن سکتا ہے، خاص طور پر اگر اس کا مطلب یہ ہو کہ کوئی بھی حساس کارروائیاں انجام دے سکتا ہے (جیسے، نئے ٹوکنز کی ڈھلائی)۔

سمارٹ کنٹریکٹ فنکشنز کے غیر مجاز استعمال کو روکنے کے لیے، محفوظ رسائی کے کنٹرولز کو نافذ کرنا ضروری ہے۔ رسائی کنٹرول کے طریقہ کار سمارٹ کنٹریکٹ میں مخصوص فنکشنز استعمال کرنے کی صلاحیت کو منظور شدہ اداروں تک محدود کرتے ہیں، جیسے کہ کنٹریکٹ کے انتظام کے ذمہ دار اکاؤنٹس۔ **Ownable پیٹرن** اور **کردار پر مبنی کنٹرول** دو ایسے پیٹرنز ہیں جو سمارٹ کنٹریکٹس میں رسائی کنٹرول کو نافذ کرنے کے لیے مفید ہیں:

#### Ownable پیٹرن {#ownable-pattern}

Ownable پیٹرن میں، کنٹریکٹ بنانے کے عمل کے دوران ایک پتہ کو کنٹریکٹ کے "مالک" کے طور پر سیٹ کیا جاتا ہے۔ محفوظ فنکشنز کو ایک `OnlyOwner` موڈیفائر تفویض کیا جاتا ہے، جو اس بات کو یقینی بناتا ہے کہ کنٹریکٹ فنکشن کو انجام دینے سے پہلے کال کرنے والے پتہ کی شناخت کی تصدیق کرے۔ کنٹریکٹ کے مالک کے علاوہ دیگر پتوں سے محفوظ فنکشنز کی کالز ہمیشہ ریورٹ ہو جاتی ہیں، جس سے ناپسندیدہ رسائی کو روکا جاتا ہے۔

#### کردار پر مبنی رسائی کنٹرول {#role-based-access-control}

سمارٹ کنٹریکٹ میں ایک واحد پتہ کو `Owner` کے طور پر رجسٹر کرنا مرکزیت کا خطرہ پیدا کرتا ہے اور یہ ناکامی کے واحد نقطہ (single point-of-failure) کی نمائندگی کرتا ہے۔ اگر مالک کے اکاؤنٹ کی کیز (keys) سمجھوتہ کر لی جائیں، تو حملہ آور ملکیتی کنٹریکٹ پر حملہ کر سکتے ہیں۔ یہی وجہ ہے کہ متعدد انتظامی اکاؤنٹس کے ساتھ کردار پر مبنی رسائی کنٹرول پیٹرن کا استعمال ایک بہتر آپشن ہو سکتا ہے۔

کردار پر مبنی رسائی کنٹرول میں، حساس فنکشنز تک رسائی کو قابل اعتماد شرکاء کے ایک سیٹ کے درمیان تقسیم کیا جاتا ہے۔ مثال کے طور پر، ایک اکاؤنٹ ٹوکنز کی ڈھلائی کا ذمہ دار ہو سکتا ہے، جبکہ دوسرا اکاؤنٹ اپ گریڈز انجام دیتا ہے یا کنٹریکٹ کو روکتا ہے۔ اس طرح رسائی کنٹرول کو لامركزی بنانا ناکامی کے واحد نکات کو ختم کرتا ہے اور صارفین کے لیے اعتماد کے مفروضے کو کم کرتا ہے۔

##### کثیر دستخطی والیٹس کا استعمال
محفوظ رسائی کنٹرول کو نافذ کرنے کا ایک اور طریقہ کنٹریکٹ کا انتظام کرنے کے لیے [کثیر دستخطی اکاؤنٹ](/developers/docs/smart-contracts/#multisig) کا استعمال ہے۔ ایک باقاعدہ EOA کے برعکس، کثیر دستخطی اکاؤنٹس متعدد اداروں کی ملکیت ہوتے ہیں اور ٹرانزیکشنز کو انجام دینے کے لیے کم از کم اکاؤنٹس—مثلاً <span dir="ltr">5</span> میں سے <span dir="ltr">3</span>—کے دستخطوں کا تقاضا کرتے ہیں۔

رسائی کنٹرول کے لیے ملٹی سگ کا استعمال سیکیورٹی کی ایک اضافی تہہ متعارف کراتا ہے کیونکہ ہدف کنٹریکٹ پر کارروائیوں کے لیے متعدد فریقوں کی رضامندی درکار ہوتی ہے۔ یہ خاص طور پر مفید ہے اگر Ownable پیٹرن کا استعمال ضروری ہو، کیونکہ یہ کسی حملہ آور یا بدمعاش اندرونی شخص کے لیے بدنیتی پر مبنی مقاصد کے لیے حساس کنٹریکٹ فنکشنز میں ہیرا پھیری کرنا زیادہ مشکل بنا دیتا ہے۔

### 2. کنٹریکٹ کی کارروائیوں کی حفاظت کے لیے require()، assert()، اور revert() اسٹیٹمنٹس کا استعمال کریں {#use-require-assert-revert}

جیسا کہ ذکر کیا گیا ہے، ایک بار جب آپ کا سمارٹ کنٹریکٹ بلاک چین پر تعینات ہو جاتا ہے تو کوئی بھی اس میں عوامی فنکشنز کو کال کر سکتا ہے۔ چونکہ آپ پہلے سے نہیں جان سکتے کہ بیرونی اکاؤنٹس کنٹریکٹ کے ساتھ کیسے تعامل کریں گے، اس لیے تعیناتی سے پہلے مسئلہ پیدا کرنے والی کارروائیوں کے خلاف اندرونی حفاظتی اقدامات کو نافذ کرنا مثالی ہے۔ آپ `require()`، `assert()`، اور `revert()` اسٹیٹمنٹس کا استعمال کر کے سمارٹ کنٹریکٹس میں درست رویے کو نافذ کر سکتے ہیں تاکہ مستثنیات (exceptions) کو متحرک کیا جا سکے اور اگر عمل درآمد کچھ تقاضوں کو پورا کرنے میں ناکام رہتا ہے تو حالت کی تبدیلیوں کو ریورٹ کیا جا سکے۔

**`require()`**: `require` کو فنکشنز کے آغاز میں بیان کیا جاتا ہے اور یہ یقینی بناتا ہے کہ کال کیے گئے فنکشن کے عمل میں آنے سے پہلے پہلے سے طے شدہ شرائط پوری ہوں۔ ایک `require` اسٹیٹمنٹ کا استعمال صارف کے ان پٹس کی توثیق کرنے، حالت کے متغیرات کو چیک کرنے، یا فنکشن کے ساتھ آگے بڑھنے سے پہلے کال کرنے والے اکاؤنٹ کی شناخت کی تصدیق کرنے کے لیے کیا جا سکتا ہے۔

**`assert()`**: `assert()` کا استعمال اندرونی خامیوں کا پتہ لگانے اور آپ کے کوڈ میں "invariants" کی خلاف ورزیوں کو چیک کرنے کے لیے کیا جاتا ہے۔ ایک invariant کنٹریکٹ کی حالت کے بارے میں ایک منطقی دعویٰ ہے جو تمام فنکشن کے عمل کے لیے درست ہونا چاہیے۔ ایک مثال invariant کسی ٹوکن کنٹریکٹ کی زیادہ سے زیادہ کل سپلائی یا بیلنس ہے۔ `assert()` کا استعمال اس بات کو یقینی بناتا ہے کہ آپ کا کنٹریکٹ کبھی بھی کمزور حالت میں نہ پہنچے، اور اگر ایسا ہوتا ہے، تو حالت کے متغیرات میں کی گئی تمام تبدیلیاں واپس (roll back) کر دی جاتی ہیں۔

**`revert()`**: `revert()` کو if-else اسٹیٹمنٹ میں استعمال کیا جا سکتا ہے جو مطلوبہ شرط پوری نہ ہونے پر ایک استثنیٰ (exception) کو متحرک کرتا ہے۔ ذیل میں دیا گیا نمونہ کنٹریکٹ فنکشنز کے عمل درآمد کی حفاظت کے لیے `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. سمارٹ کنٹریکٹس کی جانچ کریں اور کوڈ کی درستگی کی تصدیق کریں {#test-smart-contracts-and-verify-code-correctness}

[Ethereum Virtual Machine](/developers/docs/evm/) میں چلنے والے کوڈ کی ناقابلیتِ تبدیلی کا مطلب یہ ہے کہ سمارٹ کنٹریکٹس ترقی کے مرحلے کے دوران اعلیٰ سطح کے معیار کی تشخیص کا تقاضا کرتے ہیں۔ آپ کے کنٹریکٹ کی وسیع پیمانے پر جانچ کرنا اور کسی بھی غیر متوقع نتائج کے لیے اس کا مشاہدہ کرنا سیکیورٹی کو کافی حد تک بہتر بنائے گا اور طویل مدت میں آپ کے صارفین کی حفاظت کرے گا۔

معمول کا طریقہ یہ ہے کہ فرضی ڈیٹا (mock data) کا استعمال کرتے ہوئے چھوٹے یونٹ ٹیسٹ لکھے جائیں جو کنٹریکٹ کو صارفین سے موصول ہونے کی توقع ہوتی ہے۔ [یونٹ ٹیسٹنگ](/developers/docs/smart-contracts/testing/#unit-testing) مخصوص فنکشنز کی فعالیت کو جانچنے اور اس بات کو یقینی بنانے کے لیے اچھی ہے کہ سمارٹ کنٹریکٹ توقع کے مطابق کام کرے۔

بدقسمتی سے، جب یونٹ ٹیسٹنگ کو تنہائی میں استعمال کیا جاتا ہے تو یہ سمارٹ کنٹریکٹ کی سیکیورٹی کو بہتر بنانے کے لیے کم از کم موثر ہوتی ہے۔ ایک یونٹ ٹیسٹ یہ ثابت کر سکتا ہے کہ کوئی فنکشن فرضی ڈیٹا کے لیے مناسب طریقے سے کام کرتا ہے، لیکن یونٹ ٹیسٹ صرف اتنے ہی موثر ہوتے ہیں جتنے کہ لکھے گئے ٹیسٹ۔ اس سے ان ایج کیسز (edge cases) اور کمزوریوں کا پتہ لگانا مشکل ہو جاتا ہے جو آپ کے سمارٹ کنٹریکٹ کی حفاظت کو توڑ سکتے ہیں۔

ایک بہتر طریقہ یہ ہے کہ یونٹ ٹیسٹنگ کو [جامد اور متحرک تجزیہ (static and dynamic analysis)](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) کا استعمال کرتے ہوئے کی جانے والی پراپرٹی پر مبنی ٹیسٹنگ کے ساتھ ملایا جائے۔ جامد تجزیہ قابل رسائی پروگرام کی حالتوں اور عمل درآمد کے راستوں کا تجزیہ کرنے کے لیے نچلی سطح کی نمائندگیوں پر انحصار کرتا ہے، جیسے کہ [کنٹرول فلو گرافس](https://en.wikipedia.org/wiki/Control-flow_graph) اور [ایبسٹریکٹ سنٹیکس ٹریز](https://deepsource.io/glossary/ast/)۔ دریں اثنا، متحرک تجزیہ کی تکنیکیں، جیسے کہ [سمارٹ کنٹریکٹ فزنگ (fuzzing)](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)، سیکیورٹی خصوصیات کی خلاف ورزی کرنے والی کارروائیوں کا پتہ لگانے کے لیے بے ترتیب ان پٹ اقدار کے ساتھ کنٹریکٹ کوڈ کو چلاتی ہیں۔

[رسمی تصدیق](/developers/docs/smart-contracts/formal-verification) سمارٹ کنٹریکٹس میں سیکیورٹی خصوصیات کی تصدیق کے لیے ایک اور تکنیک ہے۔ باقاعدہ ٹیسٹنگ کے برعکس، رسمی تصدیق سمارٹ کنٹریکٹ میں خامیوں کی عدم موجودگی کو حتمی طور پر ثابت کر سکتی ہے۔ یہ ایک رسمی تصریح (formal specification) بنا کر حاصل کیا جاتا ہے جو مطلوبہ سیکیورٹی خصوصیات کو حاصل کرتی ہے اور یہ ثابت کرتی ہے کہ کنٹریکٹس کا ایک رسمی ماڈل اس تصریح کی پابندی کرتا ہے۔

### 4. اپنے کوڈ کے آزادانہ جائزے کے لیے کہیں {#get-independent-code-reviews}

اپنے کنٹریکٹ کی جانچ کرنے کے بعد، دوسروں سے سورس کوڈ کو کسی بھی سیکیورٹی مسائل کے لیے چیک کرنے کا کہنا اچھا ہے۔ ٹیسٹنگ سمارٹ کنٹریکٹ میں ہر خامی کو بے نقاب نہیں کرے گی، لیکن ایک آزادانہ جائزہ لینے سے کمزوریوں کو تلاش کرنے کا امکان بڑھ جاتا ہے۔

#### آڈٹس {#audits}

سمارٹ کنٹریکٹ آڈٹ کا کمیشن دینا ایک آزادانہ کوڈ کا جائزہ لینے کا ایک طریقہ ہے۔ آڈیٹرز اس بات کو یقینی بنانے میں اہم کردار ادا کرتے ہیں کہ سمارٹ کنٹریکٹس محفوظ ہیں اور معیار کے نقائص اور ڈیزائن کی خامیوں سے پاک ہیں۔

اس کے باوجود، آپ کو آڈٹس کو ہر مسئلے کا حتمی حل (silver bullet) سمجھنے سے گریز کرنا چاہیے۔ سمارٹ کنٹریکٹ آڈٹس ہر بگ کو نہیں پکڑیں گے اور زیادہ تر جائزوں کا ایک اضافی دور فراہم کرنے کے لیے بنائے گئے ہیں، جو ابتدائی ترقی اور جانچ کے دوران ڈویلپرز سے چھوٹ جانے والے مسائل کا پتہ لگانے میں مدد کر سکتے ہیں۔ آپ کو آڈیٹرز کے ساتھ کام کرنے کے لیے بہترین طریقوں پر بھی عمل کرنا چاہیے، جیسے کہ کوڈ کو مناسب طریقے سے دستاویزی شکل دینا اور ان لائن تبصرے شامل کرنا، تاکہ سمارٹ کنٹریکٹ آڈٹ کے فائدے کو زیادہ سے زیادہ کیا جا سکے۔

- [سمارٹ کنٹریکٹ آڈیٹنگ کی تجاویز اور ترکیبیں](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_
- [اپنے آڈٹ سے زیادہ سے زیادہ فائدہ اٹھائیں](https://inference.ag/blog/2023-08-14-tips/) - _Inference_

#### بگ باؤنٹیز {#bug-bounties}

بگ باؤنٹی پروگرام ترتیب دینا بیرونی کوڈ کے جائزوں کو نافذ کرنے کا ایک اور طریقہ ہے۔ بگ باؤنٹی ایک مالی انعام ہے جو ان افراد (عام طور پر وائٹ ہیٹ ہیکرز) کو دیا جاتا ہے جو کسی ایپلیکیشن میں کمزوریاں دریافت کرتے ہیں۔

جب مناسب طریقے سے استعمال کیا جائے تو، بگ باؤنٹیز ہیکر کمیونٹی کے اراکین کو آپ کے کوڈ میں اہم خامیوں کا معائنہ کرنے کی ترغیب دیتی ہیں۔ ایک حقیقی زندگی کی مثال "لامحدود رقم کا بگ" ہے جو کسی حملہ آور کو ایتھیریم پر چلنے والے [لیئر ۲ (l2)](/layer-2/) پروٹوکول، [آپٹیمزم](https://www.optimism.io/) پر لامحدود مقدار میں ایتھر بنانے کی اجازت دیتا۔ خوش قسمتی سے، ایک وائٹ ہیٹ ہیکر نے [اس خامی کو دریافت کیا](https://www.saurik.com/optimism.html) اور ٹیم کو مطلع کیا، [اس عمل میں ایک بڑی ادائیگی حاصل کی](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/)۔

ایک مفید حکمت عملی یہ ہے کہ بگ باؤنٹی پروگرام کی ادائیگی کو داؤ پر لگے فنڈز کی مقدار کے تناسب سے مقرر کیا جائے۔ "[اسکیلنگ بگ باؤنٹی](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)" کے طور پر بیان کیا گیا، یہ طریقہ افراد کو کمزوریوں کا استحصال کرنے کے بجائے ذمہ داری سے ان کا انکشاف کرنے کے لیے مالی ترغیبات فراہم کرتا ہے۔

### 5. سمارٹ کنٹریکٹ کی ترقی کے دوران بہترین طریقوں پر عمل کریں {#follow-smart-contract-development-best-practices}

آڈٹس اور بگ باؤنٹیز کی موجودگی آپ کو اعلیٰ معیار کا کوڈ لکھنے کی ذمہ داری سے بری نہیں کرتی۔ اچھی سمارٹ کنٹریکٹ سیکیورٹی مناسب ڈیزائن اور ترقی کے عمل کی پیروی سے شروع ہوتی ہے:

- تمام کوڈ کو ورژن کنٹرول سسٹم میں اسٹور کریں، جیسے کہ git

- کوڈ کی تمام ترامیم پل ریکوئسٹس (pull requests) کے ذریعے کریں

- یقینی بنائیں کہ پل ریکوئسٹس کا کم از کم ایک آزاد جائزہ لینے والا ہو—اگر آپ کسی پروجیکٹ پر اکیلے کام کر رہے ہیں، تو دوسرے ڈویلپرز کو تلاش کرنے اور کوڈ کے جائزوں کا تبادلہ کرنے پر غور کریں

- سمارٹ کنٹریکٹس کی جانچ، کمپائلنگ، اور تعیناتی کے لیے ایک [ترقیاتی ماحول (development environment)](/developers/docs/frameworks/) کا استعمال کریں

- اپنے کوڈ کو بنیادی کوڈ تجزیہ ٹولز کے ذریعے چلائیں، جیسے کہ [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn)، Mythril اور سلدر۔ مثالی طور پر، آپ کو ہر پل ریکوئسٹ کے ضم ہونے سے پہلے ایسا کرنا چاہیے اور آؤٹ پٹ میں فرق کا موازنہ کرنا چاہیے

- یقینی بنائیں کہ آپ کا کوڈ بغیر کسی خامی کے مرتب (compile) ہوتا ہے، اور Solidity کمپائلر کوئی وارننگ جاری نہیں کرتا ہے

- اپنے کوڈ کو مناسب طریقے سے دستاویزی شکل دیں ([NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html) کا استعمال کرتے ہوئے) اور کنٹریکٹ کے فن تعمیر کے بارے میں تفصیلات کو سمجھنے میں آسان زبان میں بیان کریں۔ اس سے دوسروں کے لیے آپ کے کوڈ کا آڈٹ اور جائزہ لینا آسان ہو جائے گا۔

### 6. تباہی سے بحالی کے مضبوط منصوبے نافذ کریں {#implement-disaster-recovery-plans}

محفوظ رسائی کنٹرولز کو ڈیزائن کرنا، فنکشن موڈیفائرز کو نافذ کرنا، اور دیگر تجاویز سمارٹ کنٹریکٹ کی سیکیورٹی کو بہتر بنا سکتی ہیں، لیکن وہ بدنیتی پر مبنی استحصال کے امکان کو مسترد نہیں کر سکتیں۔ محفوظ سمارٹ کنٹریکٹس بنانے کے لیے "ناکامی کی تیاری" اور حملوں کا مؤثر طریقے سے جواب دینے کے لیے ایک فال بیک پلان (fallback plan) کی ضرورت ہوتی ہے۔ تباہی سے بحالی کے ایک مناسب منصوبے میں درج ذیل میں سے کچھ یا تمام اجزاء شامل ہوں گے:

#### کنٹریکٹ اپ گریڈز {#contract-upgrades}

اگرچہ ایتھیریم سمارٹ کنٹریکٹس پہلے سے طے شدہ طور پر ناقابلِ تبدیلی ہوتے ہیں، لیکن اپ گریڈ پیٹرنز کا استعمال کر کے کچھ حد تک تبدیلی کی صلاحیت حاصل کرنا ممکن ہے۔ کنٹریکٹس کو اپ گریڈ کرنا ان صورتوں میں ضروری ہے جہاں کوئی اہم خامی آپ کے پرانے کنٹریکٹ کو ناقابل استعمال بنا دیتی ہے اور نئی منطق کی تعیناتی سب سے زیادہ قابل عمل آپشن ہے۔

کنٹریکٹ اپ گریڈ کے طریقہ کار مختلف طریقے سے کام کرتے ہیں، لیکن "پراکسی پیٹرن" سمارٹ کنٹریکٹس کو اپ گریڈ کرنے کے لیے زیادہ مقبول طریقوں میں سے ایک ہے۔ [پراکسی پیٹرنز](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) کسی ایپلیکیشن کی حالت اور منطق کو _دو_ کنٹریکٹس کے درمیان تقسیم کرتے ہیں۔ پہلا کنٹریکٹ (جسے 'پراکسی کنٹریکٹ' کہا جاتا ہے) حالت کے متغیرات (جیسے، صارف کے بیلنس) کو اسٹور کرتا ہے، جبکہ دوسرا کنٹریکٹ (جسے 'منطق کنٹریکٹ' کہا جاتا ہے) کنٹریکٹ فنکشنز کو انجام دینے کے لیے کوڈ رکھتا ہے۔

اکاؤنٹس پراکسی کنٹریکٹ کے ساتھ تعامل کرتے ہیں، جو [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) نچلی سطح کی کال کا استعمال کرتے ہوئے تمام فنکشن کالز کو منطق کنٹریکٹ پر بھیجتا ہے۔ ایک باقاعدہ پیغام کی کال کے برعکس، `delegatecall()` اس بات کو یقینی بناتا ہے کہ منطق کنٹریکٹ کے پتہ پر چلنے والا کوڈ کال کرنے والے کنٹریکٹ کے تناظر میں انجام دیا جائے۔ اس کا مطلب یہ ہے کہ منطق کنٹریکٹ ہمیشہ پراکسی کی اسٹوریج میں لکھے گا (اپنی اسٹوریج کے بجائے) اور `msg.sender` اور `msg.value` کی اصل اقدار محفوظ رہتی ہیں۔

منطق کنٹریکٹ کو کالز تفویض کرنے کے لیے اس کا پتہ پراکسی کنٹریکٹ کی اسٹوریج میں اسٹور کرنے کی ضرورت ہوتی ہے۔ لہذا، کنٹریکٹ کی منطق کو اپ گریڈ کرنا صرف ایک اور منطق کنٹریکٹ کی تعیناتی اور پراکسی کنٹریکٹ میں نیا پتہ اسٹور کرنے کا معاملہ ہے۔ چونکہ پراکسی کنٹریکٹ کی بعد کی کالز خود بخود نئے منطق کنٹریکٹ کی طرف بھیج دی جاتی ہیں، اس لیے آپ نے دراصل کوڈ میں ترمیم کیے بغیر کنٹریکٹ کو "اپ گریڈ" کر لیا ہوگا۔

[کنٹریکٹس کو اپ گریڈ کرنے کے بارے میں مزید](/developers/docs/smart-contracts/upgrading/)۔

#### ہنگامی اسٹاپس {#emergency-stops}

جیسا کہ ذکر کیا گیا ہے، وسیع آڈیٹنگ اور ٹیسٹنگ ممکنہ طور پر سمارٹ کنٹریکٹ میں تمام بگز کو دریافت نہیں کر سکتی۔ اگر تعیناتی کے بعد آپ کے کوڈ میں کوئی کمزوری ظاہر ہوتی ہے، تو اسے پیچ (patch) کرنا ناممکن ہے کیونکہ آپ کنٹریکٹ کے پتہ پر چلنے والے کوڈ کو تبدیل نہیں کر سکتے۔ اس کے علاوہ، اپ گریڈ کے طریقہ کار (جیسے، پراکسی پیٹرنز) کو نافذ کرنے میں وقت لگ سکتا ہے (انہیں اکثر مختلف فریقوں سے منظوری درکار ہوتی ہے)، جو حملہ آوروں کو مزید نقصان پہنچانے کے لیے صرف مزید وقت دیتا ہے۔

انتہائی آپشن (nuclear option) ایک "ہنگامی اسٹاپ" فنکشن کو نافذ کرنا ہے جو کنٹریکٹ میں کمزور فنکشنز کی کالز کو روکتا ہے۔ ہنگامی اسٹاپس عام طور پر درج ذیل اجزاء پر مشتمل ہوتے ہیں:

1. ایک عالمی بولین (Boolean) متغیر جو یہ ظاہر کرتا ہے کہ آیا سمارٹ کنٹریکٹ رکی ہوئی حالت میں ہے یا نہیں۔ یہ متغیر کنٹریکٹ ترتیب دیتے وقت `false` پر سیٹ کیا جاتا ہے، لیکن ایک بار کنٹریکٹ رک جانے کے بعد `true` پر واپس آ جائے گا۔

2. وہ فنکشنز جو اپنے عمل میں بولین متغیر کا حوالہ دیتے ہیں۔ ایسے فنکشنز اس وقت قابل رسائی ہوتے ہیں جب سمارٹ کنٹریکٹ رکا ہوا نہ ہو، اور جب ہنگامی اسٹاپ کی خصوصیت متحرک ہو جاتی ہے تو ناقابل رسائی ہو جاتے ہیں۔

3. ایک ادارہ جس کی ہنگامی اسٹاپ فنکشن تک رسائی ہے، جو بولین متغیر کو `true` پر سیٹ کرتا ہے۔ بدنیتی پر مبنی کارروائیوں کو روکنے کے لیے، اس فنکشن کی کالز کو ایک قابل اعتماد پتہ (جیسے، کنٹریکٹ کے مالک) تک محدود کیا جا سکتا ہے۔

ایک بار جب کنٹریکٹ ہنگامی اسٹاپ کو چالو کر دیتا ہے، تو کچھ فنکشنز کال کرنے کے قابل نہیں رہیں گے۔ یہ منتخب فنکشنز کو ایک موڈیفائر میں لپیٹ کر حاصل کیا جاتا ہے جو عالمی متغیر کا حوالہ دیتا ہے۔ ذیل میں کنٹریکٹس میں اس پیٹرن کے نفاذ کو بیان کرنے والی [ایک مثال](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) ہے:

```solidity
// اس کوڈ کا پیشہ ورانہ آڈٹ نہیں کیا گیا ہے اور یہ حفاظت یا درستگی کے بارے میں کوئی وعدہ نہیں کرتا ہے۔ اپنے خطرے پر استعمال کریں۔

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()`)۔ ایسے فنکشنز صورتحال کو حل کرنے میں مدد کر سکتے ہیں، اس لیے انہیں "محدود فنکشنز" کی فہرست سے خارج کر دیا گیا ہے۔

ہنگامی اسٹاپ کی فعالیت کا استعمال آپ کے سمارٹ کنٹریکٹ میں سنگین کمزوریوں سے نمٹنے کے لیے ایک مؤثر عارضی حل (stopgap) فراہم کرتا ہے۔ تاہم، یہ صارفین کے لیے ڈویلپرز پر بھروسہ کرنے کی ضرورت کو بڑھاتا ہے کہ وہ اسے ذاتی مفاد کی وجوہات کے لیے چالو نہیں کریں گے۔ اس مقصد کے لیے، ہنگامی اسٹاپ کے کنٹرول کو لامركزی بنانا یا تو اسے آن چین ووٹنگ کے طریقہ کار، ٹائم لاک، یا ملٹی سگ والیٹ سے منظوری کے تابع کر کے ممکنہ حل ہیں۔

#### ایونٹ کی نگرانی {#event-monitoring}

[ایونٹس](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) آپ کو سمارٹ کنٹریکٹ فنکشنز کی کالز کو ٹریک کرنے اور حالت کے متغیرات میں تبدیلیوں کی نگرانی کرنے کی اجازت دیتے ہیں۔ اپنے سمارٹ کنٹریکٹ کو اس طرح پروگرام کرنا مثالی ہے کہ جب بھی کوئی فریق حفاظت کے لحاظ سے اہم کارروائی کرے (جیسے، فنڈز کا انخلا) تو ایک ایونٹ خارج (emit) ہو۔

ایونٹس کو لاگ کرنا اور آف چین ان کی نگرانی کرنا کنٹریکٹ کی کارروائیوں کے بارے میں بصیرت فراہم کرتا ہے اور بدنیتی پر مبنی کارروائیوں کی تیز تر دریافت میں مدد کرتا ہے۔ اس کا مطلب یہ ہے کہ آپ کی ٹیم ہیکس کا تیزی سے جواب دے سکتی ہے اور صارفین پر پڑنے والے اثرات کو کم کرنے کے لیے کارروائی کر سکتی ہے، جیسے فنکشنز کو روکنا یا اپ گریڈ انجام دینا۔

آپ ایک تیار شدہ (off-the-shelf) نگرانی کے ٹول کا انتخاب بھی کر سکتے ہیں جو جب بھی کوئی آپ کے کنٹریکٹس کے ساتھ تعامل کرتا ہے تو خود بخود الرٹس بھیجتا ہے۔ یہ ٹولز آپ کو مختلف محرکات (triggers) کی بنیاد پر حسب ضرورت الرٹس بنانے کی اجازت دیں گے، جیسے ٹرانزیکشن کا حجم، فنکشن کالز کی فریکوئنسی، یا شامل مخصوص فنکشنز۔ مثال کے طور پر، آپ ایک ایسا الرٹ پروگرام کر سکتے ہیں جو اس وقت آتا ہے جب ایک ہی ٹرانزیکشن میں نکالی گئی رقم کسی خاص حد کو عبور کر لیتی ہے۔

### 7. محفوظ گورننس سسٹمز ڈیزائن کریں {#design-secure-governance-systems}

آپ بنیادی سمارٹ کنٹریکٹس کا کنٹرول کمیونٹی کے اراکین کے حوالے کر کے اپنی ایپلیکیشن کو لامركزی بنانا چاہ سکتے ہیں۔ اس صورت میں، سمارٹ کنٹریکٹ سسٹم میں ایک گورننس ماڈیول شامل ہوگا—ایک ایسا طریقہ کار جو کمیونٹی کے اراکین کو آن چین گورننس سسٹم کے ذریعے انتظامی کارروائیوں کو منظور کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، پراکسی کنٹریکٹ کو نئے نفاذ میں اپ گریڈ کرنے کی تجویز پر ٹوکن ہولڈرز کے ذریعے ووٹ دیا جا سکتا ہے۔

لامركزی گورننس فائدہ مند ہو سکتی ہے، خاص طور پر اس لیے کہ یہ ڈویلپرز اور آخری صارفین کے مفادات کو ہم آہنگ کرتی ہے۔ اس کے باوجود، اگر سمارٹ کنٹریکٹ گورننس کے طریقہ کار کو غلط طریقے سے نافذ کیا جائے تو وہ نئے خطرات متعارف کرا سکتے ہیں۔ ایک ممکنہ منظر نامہ یہ ہے کہ اگر کوئی حملہ آور [فلیش لون](/defi/#flash-loans) لے کر ووٹنگ کی بے پناہ طاقت (رکھے گئے ٹوکنز کی تعداد میں ماپا جاتا ہے) حاصل کر لیتا ہے اور ایک بدنیتی پر مبنی تجویز کو منظور کروا لیتا ہے۔

آن چین گورننس سے متعلق مسائل کو روکنے کا ایک طریقہ [ٹائم لاک کا استعمال کرنا](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/) ہے۔ ٹائم لاک سمارٹ کنٹریکٹ کو مخصوص کارروائیوں کو انجام دینے سے اس وقت تک روکتا ہے جب تک کہ ایک مخصوص وقت نہ گزر جائے۔ دیگر حکمت عملیوں میں ہر ٹوکن کو اس بنیاد پر "ووٹنگ کا وزن" تفویض کرنا شامل ہے کہ اسے کتنے عرصے سے لاک کیا گیا ہے، یا موجودہ بلاک کے بجائے کسی تاریخی دور (مثال کے طور پر، ماضی میں <span dir="ltr">2-3</span> بلاکس) میں کسی پتہ کی ووٹنگ کی طاقت کی پیمائش کرنا شامل ہے۔ دونوں طریقے آن چین ووٹس کو تبدیل کرنے کے لیے تیزی سے ووٹنگ کی طاقت جمع کرنے کے امکان کو کم کرتے ہیں۔

شیئر کیے گئے لنکس میں [محفوظ گورننس سسٹمز ڈیزائن کرنے](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)، [DAOs میں ووٹنگ کے مختلف طریقہ کار](https://hackernoon.com/governance-is-the-holy-grail-for-daos)، اور [DeFi کا فائدہ اٹھانے والے عام DAO حملے کے ویکٹرز](https://dacian.me/dao-governance-defi-attacks) کے بارے میں مزید جانیں۔

### 8. کوڈ میں پیچیدگی کو کم سے کم کریں {#reduce-code-complexity}

روایتی سافٹ ویئر ڈویلپرز KISS ("اسے سادہ رکھیں، بیوقوف") اصول سے واقف ہیں، جو سافٹ ویئر ڈیزائن میں غیر ضروری پیچیدگی متعارف کرانے کے خلاف مشورہ دیتا ہے۔ یہ اس دیرینہ سوچ کی پیروی کرتا ہے کہ "پیچیدہ نظام پیچیدہ طریقوں سے ناکام ہوتے ہیں" اور مہنگی غلطیوں کا زیادہ شکار ہوتے ہیں۔

سمارٹ کنٹریکٹس لکھتے وقت چیزوں کو سادہ رکھنا خاص اہمیت کا حامل ہے، اس بات کو مدنظر رکھتے ہوئے کہ سمارٹ کنٹریکٹس ممکنہ طور پر بڑی مقدار میں قدر (value) کو کنٹرول کر رہے ہوتے ہیں۔ سمارٹ کنٹریکٹس لکھتے وقت سادگی حاصل کرنے کے لیے ایک ٹپ یہ ہے کہ جہاں ممکن ہو موجودہ لائبریریوں کو دوبارہ استعمال کیا جائے، جیسے کہ [اوپن زیپلن کنٹریکٹس](https://docs.openzeppelin.com/contracts/5.x/)۔ چونکہ ان لائبریریوں کا ڈویلپرز کے ذریعے وسیع پیمانے پر آڈٹ اور تجربہ کیا گیا ہے، اس لیے ان کا استعمال شروع سے نئی فعالیت لکھ کر بگز متعارف کرانے کے امکانات کو کم کرتا ہے۔

ایک اور عام مشورہ یہ ہے کہ چھوٹے فنکشنز لکھیں اور کاروباری منطق کو متعدد کنٹریکٹس میں تقسیم کر کے کنٹریکٹس کو ماڈیولر رکھیں۔ آسان کوڈ لکھنا نہ صرف سمارٹ کنٹریکٹ میں حملے کی سطح کو کم کرتا ہے، بلکہ یہ مجموعی نظام کی درستگی کے بارے میں استدلال کرنا اور ممکنہ ڈیزائن کی خامیوں کا جلد پتہ لگانا بھی آسان بناتا ہے۔

### 9. عام سمارٹ کنٹریکٹ کی کمزوریوں کے خلاف دفاع کریں {#mitigate-common-smart-contract-vulnerabilities}

#### مکرر داخلہ {#reentrancy}

EVM ہم آہنگی (concurrency) کی اجازت نہیں دیتا، جس کا مطلب ہے کہ پیغام کی کال میں شامل دو کنٹریکٹس بیک وقت نہیں چل سکتے۔ ایک بیرونی کال کال کرنے والے کنٹریکٹ کے عمل اور میموری کو اس وقت تک روک دیتی ہے جب تک کہ کال واپس نہ آجائے، جس مقام پر عمل درآمد معمول کے مطابق آگے بڑھتا ہے۔ اس عمل کو باقاعدہ طور پر [کنٹرول فلو](https://www.computerhope.com/jargon/c/contflow.htm) کو دوسرے کنٹریکٹ میں منتقل کرنے کے طور پر بیان کیا جا سکتا ہے۔

اگرچہ زیادہ تر بے ضرر ہے، لیکن غیر بھروسہ مند کنٹریکٹس میں کنٹرول فلو کو منتقل کرنا مسائل کا سبب بن سکتا ہے، جیسے کہ مکرر داخلہ۔ مکرر داخلہ کا حملہ اس وقت ہوتا ہے جب کوئی بدنیتی پر مبنی کنٹریکٹ اصل فنکشن کی کال مکمل ہونے سے پہلے کسی کمزور کنٹریکٹ میں واپس کال کرتا ہے۔ اس قسم کے حملے کو ایک مثال کے ساتھ بہترین طریقے سے سمجھایا جا سکتا ہے۔

ایک سادہ سمارٹ کنٹریکٹ ('Victim') پر غور کریں جو کسی کو بھی ایتھر جمع کرنے اور نکالنے کی اجازت دیتا ہے:

```solidity
// یہ کنٹریکٹ غیر محفوظ ہے۔ پروڈکشن میں استعمال نہ کریں

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;
    }
}
```

یہ کنٹریکٹ ایک `withdraw()` فنکشن کو بے نقاب کرتا ہے تاکہ صارفین کو کنٹریکٹ میں پہلے جمع کرائے گئے ETH کو نکالنے کی اجازت مل سکے۔ انخلا پر کارروائی کرتے وقت، کنٹریکٹ درج ذیل کارروائیاں انجام دیتا ہے:

1. صارف کا ETH بیلنس چیک کرتا ہے
2. کال کرنے والے پتہ پر فنڈز بھیجتا ہے
3. ان کا بیلنس 0 پر ری سیٹ کرتا ہے، جس سے صارف کی جانب سے اضافی انخلا کو روکا جاتا ہے

`Victim` کنٹریکٹ میں `withdraw()` فنکشن "چیکس-انٹرایکشنز-ایفیکٹس" پیٹرن کی پیروی کرتا ہے۔ یہ _چیک_ کرتا ہے کہ آیا عمل درآمد کے لیے ضروری شرائط پوری ہو گئی ہیں (یعنی، صارف کا ETH بیلنس مثبت ہے) اور ٹرانزیکشن کے _اثرات_ کو لاگو کرنے سے پہلے (یعنی، صارف کا بیلنس کم کرنا)، کال کرنے والے کے پتہ پر ETH بھیج کر _تعامل_ انجام دیتا ہے۔

اگر `withdraw()` کو بیرونی ملکیت والے اکاؤنٹ (EOA) سے کال کیا جاتا ہے، تو فنکشن توقع کے مطابق کام کرتا ہے: `msg.sender.call.value()` کال کرنے والے کو ETH بھیجتا ہے۔ تاہم، اگر `msg.sender` ایک سمارٹ کنٹریکٹ اکاؤنٹ ہے جو `withdraw()` کو کال کرتا ہے، تو `msg.sender.call.value()` کا استعمال کرتے ہوئے فنڈز بھیجنے سے اس پتہ پر محفوظ کردہ کوڈ بھی چلنے کے لیے متحرک ہو جائے گا۔

تصور کریں کہ یہ کنٹریکٹ کے پتہ پر تعینات کردہ کوڈ ہے:

```solidity
 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 کنٹریکٹ میں <span dir="ltr">1 ETH</span> جمع کرنا
3. سمارٹ کنٹریکٹ میں محفوظ <span dir="ltr">1 ETH</span> نکالنا

یہاں کچھ بھی غلط نہیں ہے، سوائے اس کے کہ `Attacker` میں ایک اور فنکشن ہے جو `Victim` میں `withdraw()` کو دوبارہ کال کرتا ہے اگر آنے والے `msg.sender.call.value` سے بچ جانے والی گیس <span dir="ltr">40,000</span> سے زیادہ ہو۔ یہ `Attacker` کو `Victim` میں دوبارہ داخل ہونے اور `withdraw` کی پہلی کال مکمل ہونے سے _پہلے_ مزید فنڈز نکالنے کی صلاحیت دیتا ہے۔ یہ چکر کچھ اس طرح لگتا ہے:

```solidity
- 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 ہیک](https://www.coindesk.com/learn/understanding-the-dao-attack) میں ہوا تھا۔ مکرر داخلہ کے حملے آج بھی سمارٹ کنٹریکٹس کے لیے ایک اہم مسئلہ ہیں جیسا کہ [مکرر داخلہ کے استحصال کی عوامی فہرستیں](https://github.com/pcaversaccio/reentrancy-attacks) ظاہر کرتی ہیں۔

##### مکرر داخلہ کے حملوں کو کیسے روکا جائے
مکرر داخلہ سے نمٹنے کا ایک طریقہ [چیکس-ایفیکٹس-انٹرایکشنز پیٹرن](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) کی پیروی کرنا ہے۔ یہ پیٹرن فنکشنز کے عمل کو اس طرح ترتیب دیتا ہے کہ وہ کوڈ جو عمل درآمد کے ساتھ آگے بڑھنے سے پہلے ضروری چیکس انجام دیتا ہے وہ پہلے آتا ہے، اس کے بعد وہ کوڈ آتا ہے جو کنٹریکٹ کی حالت میں ہیرا پھیری کرتا ہے، اور وہ کوڈ جو دوسرے کنٹریکٹس یا EOAs کے ساتھ تعامل کرتا ہے وہ آخر میں آتا ہے۔

چیکس-ایفیکٹ-انٹرایکشن پیٹرن ذیل میں دکھائے گئے `Victim` کنٹریکٹ کے نظر ثانی شدہ ورژن میں استعمال کیا گیا ہے:

```solidity
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 پر سیٹ کر دیا گیا ہے، اس لیے اضافی انخلا ایک خامی (error) ظاہر کرے گا۔

ایک اور آپشن باہمی اخراج کے لاک (mutual exclusion lock) کا استعمال کرنا ہے (جسے عام طور پر "mutex" کے طور پر بیان کیا جاتا ہے) جو کنٹریکٹ کی حالت کے ایک حصے کو اس وقت تک لاک کر دیتا ہے جب تک کہ فنکشن کی کال مکمل نہ ہو جائے۔ اسے ایک بولین متغیر کا استعمال کرتے ہوئے نافذ کیا جاتا ہے جو فنکشن کے عمل میں آنے سے پہلے `true` پر سیٹ کیا جاتا ہے اور کال مکمل ہونے کے بعد `false` پر واپس آ جاتا ہے۔ جیسا کہ ذیل کی مثال میں دیکھا گیا ہے، میوٹیکس (mutex) کا استعمال کسی فنکشن کو تکراری کالز (recursive calls) سے بچاتا ہے جبکہ اصل کال پر ابھی کارروائی ہو رہی ہوتی ہے، جو مؤثر طریقے سے مکرر داخلہ کو روکتا ہے۔

```solidity
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;
    }
}
```

آپ [پل پیمنٹس (pull payments)](https://docs.openzeppelin.com/contracts/5.x/api/utils#security#PullPayment) سسٹم بھی استعمال کر سکتے ہیں جو صارفین سے سمارٹ کنٹریکٹس سے فنڈز نکالنے کا تقاضا کرتا ہے، بجائے اس کے کہ "پش پیمنٹس (push payments)" سسٹم جو اکاؤنٹس میں فنڈز بھیجتا ہے۔ یہ نامعلوم پتوں پر نادانستہ طور پر کوڈ کو متحرک کرنے کے امکان کو ختم کرتا ہے (اور کچھ ڈینائل آف سروس (denial-of-service) حملوں کو بھی روک سکتا ہے)۔

#### انٹیجر انڈر فلوز اور اوور فلوز {#integer-underflows-and-overflows}

ایک انٹیجر اوور فلو اس وقت ہوتا ہے جب کسی ریاضیاتی عمل کے نتائج اقدار کی قابل قبول حد سے باہر ہو جاتے ہیں، جس کی وجہ سے یہ سب سے کم نمائندگی والی قدر پر "رول اوور (roll over)" ہو جاتا ہے۔ مثال کے طور پر، ایک `uint8` صرف <span dir="ltr">2^8-1=255</span> تک کی اقدار کو اسٹور کر سکتا ہے۔ ریاضیاتی کارروائیاں جن کے نتیجے میں اقدار `255` سے زیادہ ہوتی ہیں وہ اوور فلو ہو جائیں گی اور `uint` کو `0` پر ری سیٹ کر دیں گی، بالکل اسی طرح جیسے کار کا اوڈومیٹر زیادہ سے زیادہ مائلیج (<span dir="ltr">999999</span>) تک پہنچنے کے بعد 0 پر ری سیٹ ہو جاتا ہے۔

انٹیجر انڈر فلوز بھی اسی طرح کی وجوہات کی بنا پر ہوتے ہیں: ریاضیاتی عمل کے نتائج قابل قبول حد سے نیچے آ جاتے ہیں۔ فرض کریں کہ آپ نے `uint8` میں `0` کو کم کرنے کی کوشش کی، تو نتیجہ آسانی سے زیادہ سے زیادہ نمائندگی والی قدر (`255`) پر رول اوور ہو جائے گا۔

انٹیجر اوور فلوز اور انڈر فلوز دونوں کنٹریکٹ کی حالت کے متغیرات میں غیر متوقع تبدیلیوں کا باعث بن سکتے ہیں اور غیر منصوبہ بند عمل درآمد کا نتیجہ ہو سکتے ہیں۔ ذیل میں ایک مثال دی گئی ہے جو یہ ظاہر کرتی ہے کہ کس طرح ایک حملہ آور سمارٹ کنٹریکٹ میں ریاضیاتی اوور فلو کا استحصال کر کے ایک غلط کارروائی انجام دے سکتا ہے:

```
pragma solidity ^0.7.6;

// یہ کنٹریکٹ ٹائم والٹ (time vault) کے طور پر کام کرنے کے لیے ڈیزائن کیا گیا ہے۔
// صارف اس کنٹریکٹ میں جمع کر سکتا ہے لیکن کم از کم ایک ہفتے تک نکال نہیں سکتا۔
// صارف 1 ہفتے کی انتظار کی مدت سے آگے بھی انتظار کا وقت بڑھا سکتا ہے۔

/*
1. TimeLock تعینات کریں
2. TimeLock کے پتہ کے ساتھ Attack تعینات کریں
3. 1 ایتھر بھیج کر 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();
    }
}
```

##### انٹیجر انڈر فلوز اور اوور فلوز کو کیسے روکا جائے
ورژن <span dir="ltr">0.8.0</span> کے مطابق، Solidity کمپائلر اس کوڈ کو مسترد کر دیتا ہے جس کے نتیجے میں انٹیجر انڈر فلوز اور اوور فلوز ہوتے ہیں۔ تاہم، کم کمپائلر ورژن کے ساتھ مرتب کیے گئے کنٹریکٹس کو یا تو ریاضیاتی کارروائیوں پر مشتمل فنکشنز پر چیکس انجام دینے چاہئیں یا ایسی لائبریری (جیسے، [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) استعمال کرنی چاہیے جو انڈر فلو/اوور فلو کو چیک کرتی ہو۔

#### اوریکل میں ہیرا پھیری {#oracle-manipulation}

[اوریکلز](/developers/docs/oracles/) آف چین معلومات حاصل کرتے ہیں اور اسے سمارٹ کنٹریکٹس کے استعمال کے لیے آن چین بھیجتے ہیں۔ اوریکلز کے ساتھ، آپ ایسے سمارٹ کنٹریکٹس ڈیزائن کر سکتے ہیں جو آف چین سسٹمز، جیسے کیپٹل مارکیٹس کے ساتھ مل کر کام کرتے ہیں، جس سے ان کے اطلاق میں بہت زیادہ وسعت آتی ہے۔

لیکن اگر اوریکل خراب ہو جاتا ہے اور آن چین غلط معلومات بھیجتا ہے، تو سمارٹ کنٹریکٹس غلط ان پٹس کی بنیاد پر کام کریں گے، جو مسائل کا سبب بن سکتا ہے۔ یہ "اوریکل کا مسئلہ" کی بنیاد ہے، جس کا تعلق اس بات کو یقینی بنانے کے کام سے ہے کہ بلاک چین اوریکل سے ملنے والی معلومات درست، تازہ ترین اور بروقت ہوں۔

ایک متعلقہ سیکیورٹی تشویش کسی اثاثے کی اسپاٹ قیمت (spot price) حاصل کرنے کے لیے آن چین اوریکل، جیسے کہ لامركزی ایکسچینج کا استعمال کرنا ہے۔ [غیر مرکزی مالیات (DeFi)](/defi/) انڈسٹری میں قرض دینے والے پلیٹ فارمز اکثر صارف کی ضمانت کی قدر کا تعین کرنے کے لیے ایسا کرتے ہیں تاکہ یہ طے کیا جا سکے کہ وہ کتنا قرض لے سکتے ہیں۔

DEX کی قیمتیں اکثر درست ہوتی ہیں، جس کی بڑی وجہ ثالثوں (arbitrageurs) کا مارکیٹوں میں برابری بحال کرنا ہے۔ تاہم، وہ ہیرا پھیری کے لیے کھلے ہیں، خاص طور پر اگر آن چین اوریکل تاریخی تجارتی نمونوں کی بنیاد پر اثاثوں کی قیمتوں کا حساب لگاتا ہے (جیسا کہ عام طور پر ہوتا ہے)۔

مثال کے طور پر، ایک حملہ آور آپ کے قرض دینے والے کنٹریکٹ کے ساتھ تعامل کرنے سے ٹھیک پہلے فلیش لون لے کر کسی اثاثے کی اسپاٹ قیمت کو مصنوعی طور پر بڑھا سکتا ہے۔ اثاثے کی قیمت کے لیے DEX سے استفسار کرنے پر معمول سے زیادہ قدر واپس آئے گی (حملہ آور کے بڑے "خریداری کے آرڈر" کی وجہ سے اثاثے کی مانگ میں بگاڑ پیدا ہونے کی وجہ سے)، جس سے وہ اپنی استطاعت سے زیادہ قرض لے سکیں گے۔ اس طرح کے "فلیش لون حملوں" کا استعمال DeFi ایپلی کیشنز کے درمیان قیمت کے اوریکلز پر انحصار کا استحصال کرنے کے لیے کیا گیا ہے، جس سے پروٹوکولز کو لاکھوں کے ضائع شدہ فنڈز کا نقصان اٹھانا پڑا ہے۔

##### اوریکل میں ہیرا پھیری کو کیسے روکا جائے
[اوریکل میں ہیرا پھیری سے بچنے](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) کے لیے کم از کم ضرورت ایک لامركزی اوریکل نیٹ ورک کا استعمال کرنا ہے جو ناکامی کے واحد نکات سے بچنے کے لیے متعدد ذرائع سے معلومات طلب کرتا ہے۔ زیادہ تر معاملات میں، لامركزی اوریکلز میں اوریکل نوڈس کو درست معلومات کی اطلاع دینے کی ترغیب دینے کے لیے بلٹ ان کرپٹو اکنامک ترغیبات ہوتی ہیں، جو انہیں مرکزی اوریکلز سے زیادہ محفوظ بناتی ہیں۔

اگر آپ اثاثوں کی قیمتوں کے لیے آن چین اوریکل سے استفسار کرنے کا ارادہ رکھتے ہیں، تو ایسے اوریکل کو استعمال کرنے پر غور کریں جو وقت کے لحاظ سے اوسط قیمت (TWAP) کے طریقہ کار کو نافذ کرتا ہو۔ ایک [TWAP اوریکل](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) وقت کے دو مختلف مقامات پر کسی اثاثے کی قیمت طلب کرتا ہے (جسے آپ تبدیل کر سکتے ہیں) اور حاصل کردہ اوسط کی بنیاد پر اسپاٹ قیمت کا حساب لگاتا ہے۔ طویل مدت کا انتخاب آپ کے پروٹوکول کو قیمتوں میں ہیرا پھیری سے بچاتا ہے کیونکہ حال ہی میں انجام دیے گئے بڑے آرڈرز اثاثوں کی قیمتوں کو متاثر نہیں کر سکتے۔

## ڈیولپرز کے لیے سمارٹ کنٹریکٹ سیکیورٹی کے وسائل {#smart-contract-security-resources-for-developers}

### سمارٹ کنٹریکٹس کا تجزیہ کرنے اور کوڈ کی درستگی کی تصدیق کرنے کے ٹولز {#code-analysis-tools}

- **[ٹیسٹنگ ٹولز اور لائبریریاں](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _سمارٹ کنٹریکٹس پر یونٹ ٹیسٹس، جامد تجزیہ (static analysis)، اور متحرک تجزیہ (dynamic analysis) انجام دینے کے لیے انڈسٹری کے معیاری ٹولز اور لائبریریوں کا مجموعہ۔_

- **[رسمی تصدیق کے ٹولز](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _سمارٹ کنٹریکٹس میں فنکشنل درستگی کی تصدیق کرنے اور انویرینٹس (invariants) کو چیک کرنے کے ٹولز۔_

- **[سمارٹ کنٹریکٹ آڈیٹنگ سروسز](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _ایتھیریم ڈیولپمنٹ پروجیکٹس کے لیے سمارٹ کنٹریکٹ آڈیٹنگ سروسز فراہم کرنے والی تنظیموں کی فہرست۔_

- **[بگ باؤنٹی پلیٹ فارمز](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _بگ باؤنٹیز کو مربوط کرنے اور سمارٹ کنٹریکٹس میں اہم کمزوریوں کے ذمہ دارانہ انکشاف پر انعام دینے کے پلیٹ فارمز۔_

- **[Fork Checker](https://forkchecker.hashex.org/)** - _فورک (fork) کیے گئے کنٹریکٹ کے حوالے سے تمام دستیاب معلومات چیک کرنے کے لیے ایک مفت آن لائن ٹول۔_

- **[ABI Encoder](https://abi.hashex.org/)** - _آپ کے <span dir="ltr">Solidity</span> کنٹریکٹ کے فنکشنز اور کنسٹرکٹر آرگیومنٹس کو انکوڈ کرنے کے لیے ایک مفت آن لائن سروس۔_

- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _<span dir="ltr">Solidity</span> کا جامد تجزیہ کار (Static Analyzer)، جو مشتبہ کمزوریوں کی نشاندہی کرنے کے لیے <span dir="ltr">Abstract Syntax Trees (AST)</span> کو ٹریورس کرتا ہے اور مسائل کو آسانی سے پڑھے جانے والے مارک ڈاؤن فارمیٹ میں پرنٹ کرتا ہے۔_

### سمارٹ کنٹریکٹس کی نگرانی کے ٹولز {#smart-contract-monitoring-tools}

- **[Tenderly ریئل ٹائم الرٹنگ](https://tenderly.co/monitoring)** - _جب آپ کے سمارٹ کنٹریکٹس یا والیٹس پر غیر معمولی یا غیر متوقع ایونٹس رونما ہوں تو ریئل ٹائم اطلاعات حاصل کرنے کا ایک ٹول۔_

### سمارٹ کنٹریکٹس کے محفوظ انتظام کے ٹولز {#smart-contract-administration-tools}

- **[Safe](https://safe.global/)** - _ایتھیریم پر چلنے والا سمارٹ کنٹریکٹ والیٹ جس میں ٹرانزیکشن کے ہونے سے پہلے اسے منظور کرنے کے لیے کم از کم افراد کی ضرورت ہوتی ہے (<span dir="ltr">M-of-N</span>)۔_

- **[اوپن زیپلن کنٹریکٹس](https://docs.openzeppelin.com/contracts/5.x/)** - _انتظامی خصوصیات کو نافذ کرنے کے لیے کنٹریکٹ لائبریریاں، جن میں کنٹریکٹ کی ملکیت، اپ گریڈز، رسائی کے کنٹرولز، گورننس، توقف کی صلاحیت (pauseability)، اور بہت کچھ شامل ہے۔_

### سمارٹ کنٹریکٹ آڈیٹنگ سروسز {#smart-contract-auditing-services}

- **[کنسینسس ڈیلیجنس](https://diligence.consensys.io/)** - _سمارٹ کنٹریکٹ آڈیٹنگ سروس جو بلاک چین ایکو سسٹم میں پروجیکٹس کی مدد کرتی ہے تاکہ یہ یقینی بنایا جا سکے کہ ان کے پروٹوکول لانچ کے لیے تیار ہیں اور صارفین کی حفاظت کے لیے بنائے گئے ہیں۔_

- **[CertiK](https://www.certik.com/)** - _بلاک چین سیکیورٹی فرم جو سمارٹ کنٹریکٹس اور بلاک چین نیٹ ورکس پر جدید ترین رسمی تصدیق کی ٹیکنالوجی کے استعمال میں پیش پیش ہے۔_

- **[Trail of Bits](https://www.trailofbits.com/)** - _سائبر سیکیورٹی کمپنی جو خطرے کو کم کرنے اور کوڈ کو مضبوط بنانے کے لیے سیکیورٹی ریسرچ کو حملہ آور کی ذہنیت کے ساتھ جوڑتی ہے۔_

- **[PeckShield](https://peckshield.com/)** - _بلاک چین سیکیورٹی کمپنی جو پورے بلاک چین ایکو سسٹم کی سیکیورٹی، رازداری، اور افادیت کے لیے مصنوعات اور خدمات پیش کرتی ہے۔_

- **[QuantStamp](https://quantstamp.com/)** - _آڈیٹنگ سروس جو سیکیورٹی اور رسک اسیسمنٹ سروسز کے ذریعے بلاک چین ٹیکنالوجی کو مرکزی دھارے میں اپنانے میں سہولت فراہم کرتی ہے۔_

- **[اوپن زیپلن](https://www.openzeppelin.com/security-audits)** - _سمارٹ کنٹریکٹ سیکیورٹی کمپنی جو تقسیم شدہ سسٹمز کے لیے سیکیورٹی آڈٹ فراہم کرتی ہے۔_

- **[Runtime Verification](https://runtimeverification.com/)** - _سیکیورٹی کمپنی جو سمارٹ کنٹریکٹس کی رسمی ماڈلنگ اور تصدیق میں مہارت رکھتی ہے۔_

- **[Hacken](https://hacken.io)** - _<span dir="ltr">Web3</span> سائبر سیکیورٹی آڈیٹر جو بلاک چین سیکیورٹی کے لیے 360 ڈگری نقطہ نظر لاتا ہے۔_

- **[نیدر مائنڈ](https://www.nethermind.io/smart-contract-audits)** - _<span dir="ltr">Solidity</span> اور <span dir="ltr">Cairo</span> آڈیٹنگ سروسز، جو ایتھیریم اور سٹارک نیٹ پر سمارٹ کنٹریکٹس کی سالمیت اور صارفین کی حفاظت کو یقینی بناتی ہیں۔_

- **[HashEx](https://hashex.org/)** - _<span dir="ltr">HashEx</span> کرپٹو کرنسیوں کی سیکیورٹی کو یقینی بنانے کے لیے بلاک چین اور سمارٹ کنٹریکٹ آڈیٹنگ پر توجہ مرکوز کرتا ہے، اور سمارٹ کنٹریکٹ ڈیولپمنٹ، پینیٹریشن ٹیسٹنگ، اور بلاک چین کنسلٹنگ جیسی خدمات فراہم کرتا ہے۔_

- **[Code4rena](https://code4rena.com/)** - _مسابقتی آڈٹ پلیٹ فارم جو سمارٹ کنٹریکٹ سیکیورٹی کے ماہرین کو کمزوریاں تلاش کرنے اور <span dir="ltr">Web3</span> کو مزید محفوظ بنانے میں مدد کرنے کی ترغیب دیتا ہے۔_

- **[CodeHawks](https://codehawks.com/)** - _مسابقتی آڈٹ پلیٹ فارم جو سیکیورٹی محققین کے لیے سمارٹ کنٹریکٹس آڈیٹنگ کے مقابلوں کی میزبانی کرتا ہے۔_

- **[Cyfrin](https://cyfrin.io)** - _<span dir="ltr">Web3</span> سیکیورٹی پاور ہاؤس، جو مصنوعات اور سمارٹ کنٹریکٹ آڈیٹنگ سروسز کے ذریعے کرپٹو سیکیورٹی کو فروغ دیتا ہے۔_

- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _<span dir="ltr">Web3</span> سیکیورٹی فرم جو تجربہ کار آڈیٹرز کی ٹیم اور بہترین ٹولز کے ذریعے بلاک چین سسٹمز کے لیے سیکیورٹی آڈٹ پیش کرتی ہے۔_

- **[Oxorio](https://oxor.io/)** - _سمارٹ کنٹریکٹ آڈٹ اور بلاک چین سیکیورٹی سروسز جو کرپٹو فرمز اور غیر مرکزی مالیات (DeFi) پروجیکٹس کے لیے <span dir="ltr">EVM</span>، <span dir="ltr">Solidity</span>، <span dir="ltr">ZK</span>، اور کراس چین ٹیکنالوجی میں مہارت رکھتی ہیں۔_

- **[Inference](https://inference.ag/)** - _سیکیورٹی آڈیٹنگ کمپنی، جو <span dir="ltr">EVM</span> پر مبنی بلاک چینز کے لیے سمارٹ کنٹریکٹ آڈیٹنگ میں مہارت رکھتی ہے۔ اپنے ماہر آڈیٹرز کی بدولت وہ ممکنہ مسائل کی نشاندہی کرتے ہیں اور تعیناتی سے پہلے انہیں ٹھیک کرنے کے لیے قابل عمل حل تجویز کرتے ہیں۔_

### بگ باؤنٹی پلیٹ فارمز {#bug-bounty-platforms}

- **[Immunefi](https://immunefi.com/)** - _سمارٹ کنٹریکٹس اور <span dir="ltr">DeFi</span> پروجیکٹس کے لیے بگ باؤنٹی پلیٹ فارم، جہاں سیکیورٹی محققین کوڈ کا جائزہ لیتے ہیں، کمزوریوں کا انکشاف کرتے ہیں، معاوضہ حاصل کرتے ہیں، اور کرپٹو کو مزید محفوظ بناتے ہیں۔_

- **[HackerOne](https://www.hackerone.com/)** - _کمزوریوں کو مربوط کرنے اور بگ باؤنٹی کا پلیٹ فارم جو کاروباروں کو پینیٹریشن ٹیسٹرز اور سائبر سیکیورٹی محققین سے جوڑتا ہے۔_

- **[HackenProof](https://hackenproof.com/)** - _کرپٹو پروجیکٹس (<span dir="ltr">DeFi</span>، سمارٹ کنٹریکٹس، والیٹس، <span dir="ltr">CEX</span> اور مزید) کے لیے ماہر بگ باؤنٹی پلیٹ فارم، جہاں سیکیورٹی پروفیشنلز ٹرائیج (triage) سروسز فراہم کرتے ہیں اور محققین کو متعلقہ، تصدیق شدہ بگ رپورٹس کے لیے معاوضہ ملتا ہے۔_

-  **[Sherlock](https://www.sherlock.xyz/)** - _سمارٹ کنٹریکٹ سیکیورٹی کے لیے <span dir="ltr">Web3</span> میں انڈر رائٹر، جس میں آڈیٹرز کی ادائیگیوں کا انتظام سمارٹ کنٹریکٹس کے ذریعے کیا جاتا ہے تاکہ یہ یقینی بنایا جا سکے کہ متعلقہ بگز کی منصفانہ ادائیگی کی گئی ہے۔_

-  **[CodeHawks](https://www.codehawks.com/)** - _مسابقتی بگ باؤنٹی پلیٹ فارم جہاں آڈیٹرز سیکیورٹی مقابلوں اور چیلنجز میں حصہ لیتے ہیں، اور (جلد ہی) اپنے نجی آڈٹ میں بھی۔_

### معلوم سمارٹ کنٹریکٹ کی کمزوریوں اور استحصال (exploits) کی اشاعتیں {#common-smart-contract-vulnerabilities-and-exploits}

- **[کنسینسس: سمارٹ کنٹریکٹ کے معلوم حملے](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _کنٹریکٹ کی سب سے اہم کمزوریوں کی ابتدائی افراد کے لیے آسان وضاحت، جس میں زیادہ تر معاملات کے لیے نمونہ کوڈ شامل ہے۔_

- **[SWC Registry](https://swcregistry.io/)** - _<span dir="ltr">Common Weakness Enumeration (CWE)</span> آئٹمز کی مرتب کردہ فہرست جو ایتھیریم سمارٹ کنٹریکٹس پر لاگو ہوتی ہے۔_

- **[Rekt](https://rekt.news/)** - _ہائی پروفائل کرپٹو ہیکس اور استحصال (exploits) کی باقاعدگی سے اپ ڈیٹ ہونے والی اشاعت، جس کے ساتھ تفصیلی پوسٹ مارٹم رپورٹس بھی شامل ہیں۔_

### سمارٹ کنٹریکٹ سیکیورٹی سیکھنے کے چیلنجز {#challenges-for-learning-smart-contract-security}

- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _بلاک چین سیکیورٹی وار گیمز، چیلنجز، اور [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) مقابلوں اور ان کے حل کی تحریروں کی مرتب کردہ فہرست۔_

- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _<span dir="ltr">DeFi</span> سمارٹ کنٹریکٹس کی جارحانہ سیکیورٹی سیکھنے اور بگ ہنٹنگ اور سیکیورٹی آڈیٹنگ میں مہارت پیدا کرنے کے لیے وار گیم۔_

- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _<span dir="ltr">Web3/Solidity</span> پر مبنی وار گیم جہاں ہر لیول ایک سمارٹ کنٹریکٹ ہے جسے 'ہیک' کرنے کی ضرورت ہوتی ہے۔_

- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _سمارٹ کنٹریکٹ ہیکنگ چیلنج، جو ایک خیالی مہم جوئی پر مبنی ہے۔ چیلنج کی کامیابی سے تکمیل ایک نجی بگ باؤنٹی پروگرام تک رسائی بھی فراہم کرتی ہے۔_

### سمارٹ کنٹریکٹس کو محفوظ بنانے کے بہترین طریقے {#smart-contract-security-best-practices}

- **[کنسینسس: ایتھیریم سمارٹ کنٹریکٹ سیکیورٹی کے بہترین طریقے](https://consensys.github.io/smart-contract-best-practices/)** - _ایتھیریم سمارٹ کنٹریکٹس کو محفوظ بنانے کے لیے رہنما خطوط کی جامع فہرست۔_

- **[Nascent: سادہ سیکیورٹی ٹول کٹ](https://github.com/nascentxyz/simple-security-toolkit)** - _سمارٹ کنٹریکٹ ڈیولپمنٹ کے لیے عملی سیکیورٹی پر مرکوز گائیڈز اور چیک لسٹس کا مجموعہ۔_

- **[Solidity پیٹرنز](https://fravoll.github.io/solidity-patterns/)** - _سمارٹ کنٹریکٹ پروگرامنگ زبان <span dir="ltr">Solidity</span> کے لیے محفوظ پیٹرنز اور بہترین طریقوں کا مفید مجموعہ۔_

- **[Solidity دستاویزات: سیکیورٹی کے تحفظات](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _<span dir="ltr">Solidity</span> کے ساتھ محفوظ سمارٹ کنٹریکٹس لکھنے کے لیے رہنما خطوط۔_

- **[سمارٹ کنٹریکٹ سیکیورٹی کی تصدیق کا معیار](https://github.com/securing/SCSVS)** - _ڈیولپرز، آرکیٹیکٹس، سیکیورٹی کا جائزہ لینے والوں اور وینڈرز کے لیے سمارٹ کنٹریکٹس کی سیکیورٹی کو معیاری بنانے کے لیے بنائی گئی چودہ حصوں پر مشتمل چیک لسٹ۔_

- **[سمارٹ کنٹریکٹ سیکیورٹی اور آڈیٹنگ سیکھیں](https://updraft.cyfrin.io/courses/security)** - _سمارٹ کنٹریکٹ سیکیورٹی اور آڈیٹنگ کا حتمی کورس، جو ان سمارٹ کنٹریکٹ ڈیولپرز کے لیے بنایا گیا ہے جو اپنے سیکیورٹی کے بہترین طریقوں کو بہتر بنانا اور سیکیورٹی محققین بننا چاہتے ہیں۔_

### سمارٹ کنٹریکٹ سیکیورٹی پر ٹیوٹوریلز {#tutorials-on-smart-contract-security}

- [محفوظ سمارٹ کنٹریکٹس کیسے لکھیں](/developers/tutorials/secure-development-workflow/)

- [سمارٹ کنٹریکٹ کے بگز تلاش کرنے کے لیے سلدر کا استعمال کیسے کریں](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)

- [سمارٹ کنٹریکٹ کے بگز تلاش کرنے کے لیے مینٹیکور کا استعمال کیسے کریں](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)

- [سمارٹ کنٹریکٹ سیکیورٹی کے رہنما خطوط](/developers/tutorials/smart-contract-security-guidelines/)

- [اپنے ٹوکن کنٹریکٹ کو صوابدیدی ٹوکنز کے ساتھ محفوظ طریقے سے کیسے مربوط کریں](/developers/tutorials/token-integration-checklist/)

- [Cyfrin Updraft - سمارٹ کنٹریکٹس سیکیورٹی اور آڈیٹنگ کا مکمل کورس](https://updraft.cyfrin.io/courses/security)