سمارٹ کنٹریکٹ کی سیکیورٹی

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

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

اگرچہ اعداد و شمار مختلف ہیں، لیکن اندازہ لگایا گیا ہے کہ سمارٹ کنٹریکٹس میں سیکیورٹی نقائص کی وجہ سے چوری ہونے والی یا ضائع ہونے والی کل مالیت باآسانی $1 بلین سے زیادہ ہے۔ اس میں ہائی پروفائل واقعات شامل ہیں، جیسے کہ DAO ہیک (opens in a new tab) (3.6M ETH چوری ہوئے، جن کی مالیت آج کی قیمتوں میں $1B سے زیادہ ہے)، Parity ملٹی سگ والیٹ ہیک (opens in a new tab) (ہیکرز کے ہاتھوں $30M کا نقصان)، اور Parity فروزن والیٹ کا مسئلہ (opens in a new tab) (ہمیشہ کے لیے لاک شدہ ETH میں $300M سے زیادہ)۔

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

پیشگی شرائط

سیکیورٹی کے معاملات پر کام کرنے سے پہلے، یقینی بنائیں کہ آپ سمارٹ کنٹریکٹ ڈیولپمنٹ کے بنیادی اصولوں سے واقف ہیں۔

محفوظ ایتھیریم سمارٹ کنٹریکٹس بنانے کے لیے رہنما خطوط

1. مناسب رسائی کے کنٹرولز ڈیزائن کریں

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

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

Ownable پیٹرن

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

کردار پر مبنی رسائی کنٹرول

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

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

کثیر دستخطی والیٹس کا استعمال

محفوظ رسائی کنٹرول کو نافذ کرنے کا ایک اور طریقہ کنٹریکٹ کا انتظام کرنے کے لیے کثیر دستخطی اکاؤنٹ کا استعمال ہے۔ ایک باقاعدہ EOA کے برعکس، کثیر دستخطی اکاؤنٹس متعدد اداروں کی ملکیت ہوتے ہیں اور ٹرانزیکشنز کو انجام دینے کے لیے کم از کم اکاؤنٹس—مثلاً 5 میں سے 3—کے دستخطوں کا تقاضا کرتے ہیں۔

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

2. کنٹریکٹ کی کارروائیوں کی حفاظت کے لیے 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. سمارٹ کنٹریکٹس کی جانچ کریں اور کوڈ کی درستگی کی تصدیق کریں

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

معمول کا طریقہ یہ ہے کہ فرضی ڈیٹا (mock data) کا استعمال کرتے ہوئے چھوٹے یونٹ ٹیسٹ لکھے جائیں جو کنٹریکٹ کو صارفین سے موصول ہونے کی توقع ہوتی ہے۔ یونٹ ٹیسٹنگ مخصوص فنکشنز کی فعالیت کو جانچنے اور اس بات کو یقینی بنانے کے لیے اچھی ہے کہ سمارٹ کنٹریکٹ توقع کے مطابق کام کرے۔

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

ایک بہتر طریقہ یہ ہے کہ یونٹ ٹیسٹنگ کو جامد اور متحرک تجزیہ (static and dynamic analysis) کا استعمال کرتے ہوئے کی جانے والی پراپرٹی پر مبنی ٹیسٹنگ کے ساتھ ملایا جائے۔ جامد تجزیہ قابل رسائی پروگرام کی حالتوں اور عمل درآمد کے راستوں کا تجزیہ کرنے کے لیے نچلی سطح کی نمائندگیوں پر انحصار کرتا ہے، جیسے کہ کنٹرول فلو گرافس (opens in a new tab) اور ایبسٹریکٹ سنٹیکس ٹریز (opens in a new tab)۔ دریں اثنا، متحرک تجزیہ کی تکنیکیں، جیسے کہ سمارٹ کنٹریکٹ فزنگ (fuzzing) (opens in a new tab)، سیکیورٹی خصوصیات کی خلاف ورزی کرنے والی کارروائیوں کا پتہ لگانے کے لیے بے ترتیب ان پٹ اقدار کے ساتھ کنٹریکٹ کوڈ کو چلاتی ہیں۔

رسمی تصدیق سمارٹ کنٹریکٹس میں سیکیورٹی خصوصیات کی تصدیق کے لیے ایک اور تکنیک ہے۔ باقاعدہ ٹیسٹنگ کے برعکس، رسمی تصدیق سمارٹ کنٹریکٹ میں خامیوں کی عدم موجودگی کو حتمی طور پر ثابت کر سکتی ہے۔ یہ ایک رسمی تصریح (formal specification) بنا کر حاصل کیا جاتا ہے جو مطلوبہ سیکیورٹی خصوصیات کو حاصل کرتی ہے اور یہ ثابت کرتی ہے کہ کنٹریکٹس کا ایک رسمی ماڈل اس تصریح کی پابندی کرتا ہے۔

4. اپنے کوڈ کے آزادانہ جائزے کے لیے کہیں

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

آڈٹس

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

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

• سمارٹ کنٹریکٹ آڈیٹنگ کی تجاویز اور ترکیبیں (opens in a new tab) - @tinchoabbate
• اپنے آڈٹ سے زیادہ سے زیادہ فائدہ اٹھائیں (opens in a new tab) - Inference

بگ باؤنٹیز

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

جب مناسب طریقے سے استعمال کیا جائے تو، بگ باؤنٹیز ہیکر کمیونٹی کے اراکین کو آپ کے کوڈ میں اہم خامیوں کا معائنہ کرنے کی ترغیب دیتی ہیں۔ ایک حقیقی زندگی کی مثال "لامحدود رقم کا بگ" ہے جو کسی حملہ آور کو ایتھیریم پر چلنے والے لیئر ۲ (l2) پروٹوکول، آپٹیمزم (opens in a new tab) پر لامحدود مقدار میں ایتھر بنانے کی اجازت دیتا۔ خوش قسمتی سے، ایک وائٹ ہیٹ ہیکر نے اس خامی کو دریافت کیا (opens in a new tab) اور ٹیم کو مطلع کیا، اس عمل میں ایک بڑی ادائیگی حاصل کی (opens in a new tab)۔

ایک مفید حکمت عملی یہ ہے کہ بگ باؤنٹی پروگرام کی ادائیگی کو داؤ پر لگے فنڈز کی مقدار کے تناسب سے مقرر کیا جائے۔ "اسکیلنگ بگ باؤنٹی (opens in a new tab)" کے طور پر بیان کیا گیا، یہ طریقہ افراد کو کمزوریوں کا استحصال کرنے کے بجائے ذمہ داری سے ان کا انکشاف کرنے کے لیے مالی ترغیبات فراہم کرتا ہے۔

5. سمارٹ کنٹریکٹ کی ترقی کے دوران بہترین طریقوں پر عمل کریں

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

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

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

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

• سمارٹ کنٹریکٹس کی جانچ، کمپائلنگ، اور تعیناتی کے لیے ایک ترقیاتی ماحول (development environment) کا استعمال کریں

• اپنے کوڈ کو بنیادی کوڈ تجزیہ ٹولز کے ذریعے چلائیں، جیسے کہ Cyfrin Aderyn (opens in a new tab)، Mythril اور سلدر۔ مثالی طور پر، آپ کو ہر پل ریکوئسٹ کے ضم ہونے سے پہلے ایسا کرنا چاہیے اور آؤٹ پٹ میں فرق کا موازنہ کرنا چاہیے

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

• اپنے کوڈ کو مناسب طریقے سے دستاویزی شکل دیں (NatSpec (opens in a new tab) کا استعمال کرتے ہوئے) اور کنٹریکٹ کے فن تعمیر کے بارے میں تفصیلات کو سمجھنے میں آسان زبان میں بیان کریں۔ اس سے دوسروں کے لیے آپ کے کوڈ کا آڈٹ اور جائزہ لینا آسان ہو جائے گا۔

6. تباہی سے بحالی کے مضبوط منصوبے نافذ کریں

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

کنٹریکٹ اپ گریڈز

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

کنٹریکٹ اپ گریڈ کے طریقہ کار مختلف طریقے سے کام کرتے ہیں، لیکن "پراکسی پیٹرن" سمارٹ کنٹریکٹس کو اپ گریڈ کرنے کے لیے زیادہ مقبول طریقوں میں سے ایک ہے۔ پراکسی پیٹرنز (opens in a new tab) کسی ایپلیکیشن کی حالت اور منطق کو دو کنٹریکٹس کے درمیان تقسیم کرتے ہیں۔ پہلا کنٹریکٹ (جسے 'پراکسی کنٹریکٹ' کہا جاتا ہے) حالت کے متغیرات (جیسے، صارف کے بیلنس) کو اسٹور کرتا ہے، جبکہ دوسرا کنٹریکٹ (جسے 'منطق کنٹریکٹ' کہا جاتا ہے) کنٹریکٹ فنکشنز کو انجام دینے کے لیے کوڈ رکھتا ہے۔

اکاؤنٹس پراکسی کنٹریکٹ کے ساتھ تعامل کرتے ہیں، جو delegatecall() (opens in a new tab) نچلی سطح کی کال کا استعمال کرتے ہوئے تمام فنکشن کالز کو منطق کنٹریکٹ پر بھیجتا ہے۔ ایک باقاعدہ پیغام کی کال کے برعکس، delegatecall() اس بات کو یقینی بناتا ہے کہ منطق کنٹریکٹ کے پتہ پر چلنے والا کوڈ کال کرنے والے کنٹریکٹ کے تناظر میں انجام دیا جائے۔ اس کا مطلب یہ ہے کہ منطق کنٹریکٹ ہمیشہ پراکسی کی اسٹوریج میں لکھے گا (اپنی اسٹوریج کے بجائے) اور msg.sender اور msg.value کی اصل اقدار محفوظ رہتی ہیں۔

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

کنٹریکٹس کو اپ گریڈ کرنے کے بارے میں مزید۔

ہنگامی اسٹاپس

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

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

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

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

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

ایک بار جب کنٹریکٹ ہنگامی اسٹاپ کو چالو کر دیتا ہے، تو کچھ فنکشنز کال کرنے کے قابل نہیں رہیں گے۔ یہ منتخب فنکشنز کو ایک موڈیفائر میں لپیٹ کر حاصل کیا جاتا ہے جو عالمی متغیر کا حوالہ دیتا ہے۔ ذیل میں کنٹریکٹس میں اس پیٹرن کے نفاذ کو بیان کرنے والی ایک مثال (opens in a new tab) ہے:

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

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) فراہم کرتا ہے۔ تاہم، یہ صارفین کے لیے ڈویلپرز پر بھروسہ کرنے کی ضرورت کو بڑھاتا ہے کہ وہ اسے ذاتی مفاد کی وجوہات کے لیے چالو نہیں کریں گے۔ اس مقصد کے لیے، ہنگامی اسٹاپ کے کنٹرول کو لامركزی بنانا یا تو اسے آن چین ووٹنگ کے طریقہ کار، ٹائم لاک، یا ملٹی سگ والیٹ سے منظوری کے تابع کر کے ممکنہ حل ہیں۔

ایونٹ کی نگرانی

ایونٹس (opens in a new tab) آپ کو سمارٹ کنٹریکٹ فنکشنز کی کالز کو ٹریک کرنے اور حالت کے متغیرات میں تبدیلیوں کی نگرانی کرنے کی اجازت دیتے ہیں۔ اپنے سمارٹ کنٹریکٹ کو اس طرح پروگرام کرنا مثالی ہے کہ جب بھی کوئی فریق حفاظت کے لحاظ سے اہم کارروائی کرے (جیسے، فنڈز کا انخلا) تو ایک ایونٹ خارج (emit) ہو۔

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

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

7. محفوظ گورننس سسٹمز ڈیزائن کریں

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

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

آن چین گورننس سے متعلق مسائل کو روکنے کا ایک طریقہ ٹائم لاک کا استعمال کرنا (opens in a new tab) ہے۔ ٹائم لاک سمارٹ کنٹریکٹ کو مخصوص کارروائیوں کو انجام دینے سے اس وقت تک روکتا ہے جب تک کہ ایک مخصوص وقت نہ گزر جائے۔ دیگر حکمت عملیوں میں ہر ٹوکن کو اس بنیاد پر "ووٹنگ کا وزن" تفویض کرنا شامل ہے کہ اسے کتنے عرصے سے لاک کیا گیا ہے، یا موجودہ بلاک کے بجائے کسی تاریخی دور (مثال کے طور پر، ماضی میں 2-3 بلاکس) میں کسی پتہ کی ووٹنگ کی طاقت کی پیمائش کرنا شامل ہے۔ دونوں طریقے آن چین ووٹس کو تبدیل کرنے کے لیے تیزی سے ووٹنگ کی طاقت جمع کرنے کے امکان کو کم کرتے ہیں۔

شیئر کیے گئے لنکس میں محفوظ گورننس سسٹمز ڈیزائن کرنے (opens in a new tab)، DAOs میں ووٹنگ کے مختلف طریقہ کار (opens in a new tab)، اور DeFi کا فائدہ اٹھانے والے عام DAO حملے کے ویکٹرز (opens in a new tab) کے بارے میں مزید جانیں۔

8. کوڈ میں پیچیدگی کو کم سے کم کریں

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

سمارٹ کنٹریکٹس لکھتے وقت چیزوں کو سادہ رکھنا خاص اہمیت کا حامل ہے، اس بات کو مدنظر رکھتے ہوئے کہ سمارٹ کنٹریکٹس ممکنہ طور پر بڑی مقدار میں قدر (value) کو کنٹرول کر رہے ہوتے ہیں۔ سمارٹ کنٹریکٹس لکھتے وقت سادگی حاصل کرنے کے لیے ایک ٹپ یہ ہے کہ جہاں ممکن ہو موجودہ لائبریریوں کو دوبارہ استعمال کیا جائے، جیسے کہ اوپن زیپلن کنٹریکٹس (opens in a new tab)۔ چونکہ ان لائبریریوں کا ڈویلپرز کے ذریعے وسیع پیمانے پر آڈٹ اور تجربہ کیا گیا ہے، اس لیے ان کا استعمال شروع سے نئی فعالیت لکھ کر بگز متعارف کرانے کے امکانات کو کم کرتا ہے۔

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

9. عام سمارٹ کنٹریکٹ کی کمزوریوں کے خلاف دفاع کریں

مکرر داخلہ

EVM ہم آہنگی (concurrency) کی اجازت نہیں دیتا، جس کا مطلب ہے کہ پیغام کی کال میں شامل دو کنٹریکٹس بیک وقت نہیں چل سکتے۔ ایک بیرونی کال کال کرنے والے کنٹریکٹ کے عمل اور میموری کو اس وقت تک روک دیتی ہے جب تک کہ کال واپس نہ آجائے، جس مقام پر عمل درآمد معمول کے مطابق آگے بڑھتا ہے۔ اس عمل کو باقاعدہ طور پر کنٹرول فلو (opens in a new tab) کو دوسرے کنٹریکٹ میں منتقل کرنے کے طور پر بیان کیا جا سکتا ہے۔

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

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

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

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

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

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

یہ کنٹریکٹ ایک 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() کا استعمال کرتے ہوئے فنڈز بھیجنے سے اس پتہ پر محفوظ کردہ کوڈ بھی چلنے کے لیے متحرک ہو جائے گا۔

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

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

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

یہ کنٹریکٹ تین کام کرنے کے لیے ڈیزائن کیا گیا ہے:

1. کسی دوسرے اکاؤنٹ سے ڈپازٹ قبول کرنا (ممکنہ طور پر حملہ آور کا EOA)
2. Victim کنٹریکٹ میں 1 ETH جمع کرنا
3. سمارٹ کنٹریکٹ میں محفوظ 1 ETH نکالنا

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

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

خلاصہ یہ ہے کہ چونکہ کال کرنے والے کا بیلنس اس وقت تک 0 پر سیٹ نہیں ہوتا جب تک کہ فنکشن کا عمل مکمل نہ ہو جائے، اس لیے بعد کی کالز کامیاب ہوں گی اور کال کرنے والے کو اپنا بیلنس متعدد بار نکالنے کی اجازت دیں گی۔ اس قسم کے حملے کا استعمال سمارٹ کنٹریکٹ کے فنڈز کو خالی کرنے کے لیے کیا جا سکتا ہے، جیسا کہ 2016 کے DAO ہیک (opens in a new tab) میں ہوا تھا۔ مکرر داخلہ کے حملے آج بھی سمارٹ کنٹریکٹس کے لیے ایک اہم مسئلہ ہیں جیسا کہ مکرر داخلہ کے استحصال کی عوامی فہرستیں (opens in a new tab) ظاہر کرتی ہیں۔

مکرر داخلہ کے حملوں کو کیسے روکا جائے

مکرر داخلہ سے نمٹنے کا ایک طریقہ چیکس-ایفیکٹس-انٹرایکشنز پیٹرن (opens in a new tab) کی پیروی کرنا ہے۔ یہ پیٹرن فنکشنز کے عمل کو اس طرح ترتیب دیتا ہے کہ وہ کوڈ جو عمل درآمد کے ساتھ آگے بڑھنے سے پہلے ضروری چیکس انجام دیتا ہے وہ پہلے آتا ہے، اس کے بعد وہ کوڈ آتا ہے جو کنٹریکٹ کی حالت میں ہیرا پھیری کرتا ہے، اور وہ کوڈ جو دوسرے کنٹریکٹس یا EOAs کے ساتھ تعامل کرتا ہے وہ آخر میں آتا ہے۔

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

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

یہ کنٹریکٹ صارف کے بیلنس پر ایک چیک انجام دیتا ہے، withdraw() فنکشن کے اثرات کو لاگو کرتا ہے (صارف کے بیلنس کو 0 پر ری سیٹ کر کے)، اور تعامل انجام دینے کے لیے آگے بڑھتا ہے (صارف کے پتہ پر ETH بھیجنا)۔ یہ اس بات کو یقینی بناتا ہے کہ کنٹریکٹ بیرونی کال سے پہلے اپنی اسٹوریج کو اپ ڈیٹ کرے، جس سے مکرر داخلہ کی وہ شرط ختم ہو جاتی ہے جس نے پہلے حملے کو ممکن بنایا تھا۔ Attacker کنٹریکٹ اب بھی NoLongerAVictim میں واپس کال کر سکتا ہے، لیکن چونکہ balances[msg.sender] کو 0 پر سیٹ کر دیا گیا ہے، اس لیے اضافی انخلا ایک خامی (error) ظاہر کرے گا۔

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

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) (opens in a new tab) سسٹم بھی استعمال کر سکتے ہیں جو صارفین سے سمارٹ کنٹریکٹس سے فنڈز نکالنے کا تقاضا کرتا ہے، بجائے اس کے کہ "پش پیمنٹس (push payments)" سسٹم جو اکاؤنٹس میں فنڈز بھیجتا ہے۔ یہ نامعلوم پتوں پر نادانستہ طور پر کوڈ کو متحرک کرنے کے امکان کو ختم کرتا ہے (اور کچھ ڈینائل آف سروس (denial-of-service) حملوں کو بھی روک سکتا ہے)۔

انٹیجر انڈر فلوز اور اوور فلوز

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

انٹیجر انڈر فلوز اور اوور فلوز کو کیسے روکا جائے

ورژن 0.8.0 کے مطابق، Solidity کمپائلر اس کوڈ کو مسترد کر دیتا ہے جس کے نتیجے میں انٹیجر انڈر فلوز اور اوور فلوز ہوتے ہیں۔ تاہم، کم کمپائلر ورژن کے ساتھ مرتب کیے گئے کنٹریکٹس کو یا تو ریاضیاتی کارروائیوں پر مشتمل فنکشنز پر چیکس انجام دینے چاہئیں یا ایسی لائبریری (جیسے، SafeMath (opens in a new tab)) استعمال کرنی چاہیے جو انڈر فلو/اوور فلو کو چیک کرتی ہو۔

اوریکل میں ہیرا پھیری

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

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

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

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

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

اوریکل میں ہیرا پھیری کو کیسے روکا جائے

اوریکل میں ہیرا پھیری سے بچنے (opens in a new tab) کے لیے کم از کم ضرورت ایک لامركزی اوریکل نیٹ ورک کا استعمال کرنا ہے جو ناکامی کے واحد نکات سے بچنے کے لیے متعدد ذرائع سے معلومات طلب کرتا ہے۔ زیادہ تر معاملات میں، لامركزی اوریکلز میں اوریکل نوڈس کو درست معلومات کی اطلاع دینے کی ترغیب دینے کے لیے بلٹ ان کرپٹو اکنامک ترغیبات ہوتی ہیں، جو انہیں مرکزی اوریکلز سے زیادہ محفوظ بناتی ہیں۔

اگر آپ اثاثوں کی قیمتوں کے لیے آن چین اوریکل سے استفسار کرنے کا ارادہ رکھتے ہیں، تو ایسے اوریکل کو استعمال کرنے پر غور کریں جو وقت کے لحاظ سے اوسط قیمت (TWAP) کے طریقہ کار کو نافذ کرتا ہو۔ ایک TWAP اوریکل (opens in a new tab) وقت کے دو مختلف مقامات پر کسی اثاثے کی قیمت طلب کرتا ہے (جسے آپ تبدیل کر سکتے ہیں) اور حاصل کردہ اوسط کی بنیاد پر اسپاٹ قیمت کا حساب لگاتا ہے۔ طویل مدت کا انتخاب آپ کے پروٹوکول کو قیمتوں میں ہیرا پھیری سے بچاتا ہے کیونکہ حال ہی میں انجام دیے گئے بڑے آرڈرز اثاثوں کی قیمتوں کو متاثر نہیں کر سکتے۔

ڈیولپرز کے لیے سمارٹ کنٹریکٹ سیکیورٹی کے وسائل

سمارٹ کنٹریکٹس کا تجزیہ کرنے اور کوڈ کی درستگی کی تصدیق کرنے کے ٹولز

• ٹیسٹنگ ٹولز اور لائبریریاں - سمارٹ کنٹریکٹس پر یونٹ ٹیسٹس، جامد تجزیہ (static analysis)، اور متحرک تجزیہ (dynamic analysis) انجام دینے کے لیے انڈسٹری کے معیاری ٹولز اور لائبریریوں کا مجموعہ۔

• رسمی تصدیق کے ٹولز - سمارٹ کنٹریکٹس میں فنکشنل درستگی کی تصدیق کرنے اور انویرینٹس (invariants) کو چیک کرنے کے ٹولز۔

• سمارٹ کنٹریکٹ آڈیٹنگ سروسز - ایتھیریم ڈیولپمنٹ پروجیکٹس کے لیے سمارٹ کنٹریکٹ آڈیٹنگ سروسز فراہم کرنے والی تنظیموں کی فہرست۔

• بگ باؤنٹی پلیٹ فارمز - بگ باؤنٹیز کو مربوط کرنے اور سمارٹ کنٹریکٹس میں اہم کمزوریوں کے ذمہ دارانہ انکشاف پر انعام دینے کے پلیٹ فارمز۔

• Fork Checker (opens in a new tab) - فورک (fork) کیے گئے کنٹریکٹ کے حوالے سے تمام دستیاب معلومات چیک کرنے کے لیے ایک مفت آن لائن ٹول۔

• ABI Encoder (opens in a new tab) - آپ کے Solidity کنٹریکٹ کے فنکشنز اور کنسٹرکٹر آرگیومنٹس کو انکوڈ کرنے کے لیے ایک مفت آن لائن سروس۔

• Aderyn (opens in a new tab) - Solidity کا جامد تجزیہ کار (Static Analyzer)، جو مشتبہ کمزوریوں کی نشاندہی کرنے کے لیے Abstract Syntax Trees (AST) کو ٹریورس کرتا ہے اور مسائل کو آسانی سے پڑھے جانے والے مارک ڈاؤن فارمیٹ میں پرنٹ کرتا ہے۔

سمارٹ کنٹریکٹس کی نگرانی کے ٹولز

• Tenderly ریئل ٹائم الرٹنگ (opens in a new tab) - جب آپ کے سمارٹ کنٹریکٹس یا والیٹس پر غیر معمولی یا غیر متوقع ایونٹس رونما ہوں تو ریئل ٹائم اطلاعات حاصل کرنے کا ایک ٹول۔

سمارٹ کنٹریکٹس کے محفوظ انتظام کے ٹولز

• Safe (opens in a new tab) - ایتھیریم پر چلنے والا سمارٹ کنٹریکٹ والیٹ جس میں ٹرانزیکشن کے ہونے سے پہلے اسے منظور کرنے کے لیے کم از کم افراد کی ضرورت ہوتی ہے (M-of-N)۔

• اوپن زیپلن کنٹریکٹس (opens in a new tab) - انتظامی خصوصیات کو نافذ کرنے کے لیے کنٹریکٹ لائبریریاں، جن میں کنٹریکٹ کی ملکیت، اپ گریڈز، رسائی کے کنٹرولز، گورننس، توقف کی صلاحیت (pauseability)، اور بہت کچھ شامل ہے۔

سمارٹ کنٹریکٹ آڈیٹنگ سروسز

• کنسینسس ڈیلیجنس (opens in a new tab) - سمارٹ کنٹریکٹ آڈیٹنگ سروس جو بلاک چین ایکو سسٹم میں پروجیکٹس کی مدد کرتی ہے تاکہ یہ یقینی بنایا جا سکے کہ ان کے پروٹوکول لانچ کے لیے تیار ہیں اور صارفین کی حفاظت کے لیے بنائے گئے ہیں۔

• CertiK (opens in a new tab) - بلاک چین سیکیورٹی فرم جو سمارٹ کنٹریکٹس اور بلاک چین نیٹ ورکس پر جدید ترین رسمی تصدیق کی ٹیکنالوجی کے استعمال میں پیش پیش ہے۔

• Trail of Bits (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) - سمارٹ کنٹریکٹ آڈٹ اور بلاک چین سیکیورٹی سروسز جو کرپٹو فرمز اور غیر مرکزی مالیات (DeFi) پروجیکٹس کے لیے EVM، Solidity، ZK، اور کراس چین ٹیکنالوجی میں مہارت رکھتی ہیں۔

• Inference (opens in a new tab) - سیکیورٹی آڈیٹنگ کمپنی، جو EVM پر مبنی بلاک چینز کے لیے سمارٹ کنٹریکٹ آڈیٹنگ میں مہارت رکھتی ہے۔ اپنے ماہر آڈیٹرز کی بدولت وہ ممکنہ مسائل کی نشاندہی کرتے ہیں اور تعیناتی سے پہلے انہیں ٹھیک کرنے کے لیے قابل عمل حل تجویز کرتے ہیں۔

بگ باؤنٹی پلیٹ فارمز

• Immunefi (opens in a new tab) - سمارٹ کنٹریکٹس اور DeFi پروجیکٹس کے لیے بگ باؤنٹی پلیٹ فارم، جہاں سیکیورٹی محققین کوڈ کا جائزہ لیتے ہیں، کمزوریوں کا انکشاف کرتے ہیں، معاوضہ حاصل کرتے ہیں، اور کرپٹو کو مزید محفوظ بناتے ہیں۔

• HackerOne (opens in a new tab) - کمزوریوں کو مربوط کرنے اور بگ باؤنٹی کا پلیٹ فارم جو کاروباروں کو پینیٹریشن ٹیسٹرز اور سائبر سیکیورٹی محققین سے جوڑتا ہے۔

• HackenProof (opens in a new tab) - کرپٹو پروجیکٹس (DeFi، سمارٹ کنٹریکٹس، والیٹس، CEX اور مزید) کے لیے ماہر بگ باؤنٹی پلیٹ فارم، جہاں سیکیورٹی پروفیشنلز ٹرائیج (triage) سروسز فراہم کرتے ہیں اور محققین کو متعلقہ، تصدیق شدہ بگ رپورٹس کے لیے معاوضہ ملتا ہے۔

• Sherlock (opens in a new tab) - سمارٹ کنٹریکٹ سیکیورٹی کے لیے Web3 میں انڈر رائٹر، جس میں آڈیٹرز کی ادائیگیوں کا انتظام سمارٹ کنٹریکٹس کے ذریعے کیا جاتا ہے تاکہ یہ یقینی بنایا جا سکے کہ متعلقہ بگز کی منصفانہ ادائیگی کی گئی ہے۔

• CodeHawks (opens in a new tab) - مسابقتی بگ باؤنٹی پلیٹ فارم جہاں آڈیٹرز سیکیورٹی مقابلوں اور چیلنجز میں حصہ لیتے ہیں، اور (جلد ہی) اپنے نجی آڈٹ میں بھی۔

معلوم سمارٹ کنٹریکٹ کی کمزوریوں اور استحصال (exploits) کی اشاعتیں

• کنسینسس: سمارٹ کنٹریکٹ کے معلوم حملے (opens in a new tab) - کنٹریکٹ کی سب سے اہم کمزوریوں کی ابتدائی افراد کے لیے آسان وضاحت، جس میں زیادہ تر معاملات کے لیے نمونہ کوڈ شامل ہے۔

• SWC Registry (opens in a new tab) - Common Weakness Enumeration (CWE) آئٹمز کی مرتب کردہ فہرست جو ایتھیریم سمارٹ کنٹریکٹس پر لاگو ہوتی ہے۔

• Rekt (opens in a new tab) - ہائی پروفائل کرپٹو ہیکس اور استحصال (exploits) کی باقاعدگی سے اپ ڈیٹ ہونے والی اشاعت، جس کے ساتھ تفصیلی پوسٹ مارٹم رپورٹس بھی شامل ہیں۔

سمارٹ کنٹریکٹ سیکیورٹی سیکھنے کے چیلنجز

• Awesome BlockSec CTF (opens in a new tab) - بلاک چین سیکیورٹی وار گیمز، چیلنجز، اور Capture The Flag (opens in a new tab) مقابلوں اور ان کے حل کی تحریروں کی مرتب کردہ فہرست۔

• Damn Vulnerable DeFi (opens in a new tab) - DeFi سمارٹ کنٹریکٹس کی جارحانہ سیکیورٹی سیکھنے اور بگ ہنٹنگ اور سیکیورٹی آڈیٹنگ میں مہارت پیدا کرنے کے لیے وار گیم۔

• Ethernaut (opens in a new tab) - Web3/Solidity پر مبنی وار گیم جہاں ہر لیول ایک سمارٹ کنٹریکٹ ہے جسے 'ہیک' کرنے کی ضرورت ہوتی ہے۔

• HackenProof x HackTheBox (opens in a new tab) - سمارٹ کنٹریکٹ ہیکنگ چیلنج، جو ایک خیالی مہم جوئی پر مبنی ہے۔ چیلنج کی کامیابی سے تکمیل ایک نجی بگ باؤنٹی پروگرام تک رسائی بھی فراہم کرتی ہے۔

سمارٹ کنٹریکٹس کو محفوظ بنانے کے بہترین طریقے

• کنسینسس: ایتھیریم سمارٹ کنٹریکٹ سیکیورٹی کے بہترین طریقے (opens in a new tab) - ایتھیریم سمارٹ کنٹریکٹس کو محفوظ بنانے کے لیے رہنما خطوط کی جامع فہرست۔

• Nascent: سادہ سیکیورٹی ٹول کٹ (opens in a new tab) - سمارٹ کنٹریکٹ ڈیولپمنٹ کے لیے عملی سیکیورٹی پر مرکوز گائیڈز اور چیک لسٹس کا مجموعہ۔

• Solidity پیٹرنز (opens in a new tab) - سمارٹ کنٹریکٹ پروگرامنگ زبان Solidity کے لیے محفوظ پیٹرنز اور بہترین طریقوں کا مفید مجموعہ۔

• Solidity دستاویزات: سیکیورٹی کے تحفظات (opens in a new tab) - Solidity کے ساتھ محفوظ سمارٹ کنٹریکٹس لکھنے کے لیے رہنما خطوط۔

• سمارٹ کنٹریکٹ سیکیورٹی کی تصدیق کا معیار (opens in a new tab) - ڈیولپرز، آرکیٹیکٹس، سیکیورٹی کا جائزہ لینے والوں اور وینڈرز کے لیے سمارٹ کنٹریکٹس کی سیکیورٹی کو معیاری بنانے کے لیے بنائی گئی چودہ حصوں پر مشتمل چیک لسٹ۔

• سمارٹ کنٹریکٹ سیکیورٹی اور آڈیٹنگ سیکھیں (opens in a new tab) - سمارٹ کنٹریکٹ سیکیورٹی اور آڈیٹنگ کا حتمی کورس، جو ان سمارٹ کنٹریکٹ ڈیولپرز کے لیے بنایا گیا ہے جو اپنے سیکیورٹی کے بہترین طریقوں کو بہتر بنانا اور سیکیورٹی محققین بننا چاہتے ہیں۔

سمارٹ کنٹریکٹ سیکیورٹی پر ٹیوٹوریلز

• محفوظ سمارٹ کنٹریکٹس کیسے لکھیں

• سمارٹ کنٹریکٹ کے بگز تلاش کرنے کے لیے سلدر کا استعمال کیسے کریں

• سمارٹ کنٹریکٹ کے بگز تلاش کرنے کے لیے مینٹیکور کا استعمال کیسے کریں

• سمارٹ کنٹریکٹ سیکیورٹی کے رہنما خطوط

• اپنے ٹوکن کنٹریکٹ کو صوابدیدی ٹوکنز کے ساتھ محفوظ طریقے سے کیسے مربوط کریں

• Cyfrin Updraft - سمارٹ کنٹریکٹس سیکیورٹی اور آڈیٹنگ کا مکمل کورس (opens in a new tab)