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

سمارٹ کنٹریکٹس انتہائی لچکدار ہوتے ہیں، اور بلاک چین پر تعینات کوڈ پر مبنی ناقابل تغیر (immutable) لاجک چلاتے ہوئے بڑی مقدار میں قدر (value) اور ڈیٹا کو کنٹرول کرنے کی صلاحیت رکھتے ہیں۔ اس نے ٹرسٹ لیس (trustless) اور ڈی سینٹرلائزڈ ایپلی کیشنز کا ایک متحرک ایکو سسٹم بنایا ہے جو روایتی سسٹمز کے مقابلے میں بہت سے فوائد فراہم کرتا ہے۔ یہ ان حملہ آوروں کے لیے مواقع بھی پیش کرتے ہیں جو سمارٹ کنٹریکٹس میں موجود کمزوریوں کا فائدہ اٹھا کر منافع کمانا چاہتے ہیں۔

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

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

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

پیشگی شرائط

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

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

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

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

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

Ownable پیٹرن

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

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

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

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

ملٹی سگنیچر والٹس کا استعمال

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

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

2. کنٹریکٹ آپریشنز کی حفاظت کے لیے require()، assert()، اور revert() سٹیٹمنٹس کا استعمال کریں

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

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

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

revert(): revert() کو if-else سٹیٹمنٹ میں استعمال کیا جا سکتا ہے جو مطلوبہ شرط پوری نہ ہونے پر ایکسیپشن کو متحرک کرتا ہے۔ ذیل میں دیا گیا نمونہ کنٹریکٹ فنکشنز کی ایگزیکیوشن کی حفاظت کے لیے 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 میں چلنے والے کوڈ کی غیر تغیر پذیری (immutability) کا مطلب ہے کہ سمارٹ کنٹریکٹس کو ڈیولپمنٹ کے مرحلے کے دوران اعلیٰ سطح کے معیار کی جانچ کی ضرورت ہوتی ہے۔ اپنے کنٹریکٹ کی وسیع پیمانے پر جانچ کرنا اور کسی بھی غیر متوقع نتائج کے لیے اس کا مشاہدہ کرنا سیکیورٹی کو کافی حد تک بہتر بنائے گا اور طویل مدت میں آپ کے صارفین کی حفاظت کرے گا۔

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

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

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

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

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

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

آڈٹس

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

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

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

بگ باؤنٹیز

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

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

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

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

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

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

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

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

• سمارٹ کنٹریکٹس کی ٹیسٹنگ، کمپائلنگ، اور ڈیپلائنگ کے لیے ایک ڈیولپمنٹ انوائرنمنٹ استعمال کریں

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

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

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

6. مضبوط ڈیزاسٹر ریکوری پلانز نافذ کریں

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

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

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

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

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

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

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

ہنگامی رکاوٹیں (Emergency stops)

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

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

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

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

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

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

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

contract EmergencyStop {

    bool isStopped = false;

    modifier stoppedInEmergency {
        require(!isStopped);
        _;
    }

    modifier onlyWhenStopped {
        require(isStopped);
        _;
    }

    modifier onlyAuthorized {
        // یہاں msg.sender کی اجازت (authorization) چیک کریں
        _;
    }

    function stopContract() public onlyAuthorized {
        isStopped = true;
    }

    function resumeContract() public onlyAuthorized {
        isStopped = false;
    }

    function deposit() public payable stoppedInEmergency {
        // ڈپازٹ کی لاجک یہاں چل رہی ہے
    }

    function emergencyWithdraw() public onlyWhenStopped {
        // ایمرجنسی withdraw یہاں ہو رہا ہے
    }
}

یہ مثال ایمرجنسی سٹاپس کی بنیادی خصوصیات کو ظاہر کرتی ہے:

• isStopped ایک بولین ہے جو شروع میں false اور جب کنٹریکٹ ایمرجنسی موڈ میں داخل ہوتا ہے تو true کا جائزہ لیتا ہے۔

• فنکشن موڈیفائرز onlyWhenStopped اور stoppedInEmergency isStopped ویری ایبل کو چیک کرتے ہیں۔ stoppedInEmergency کا استعمال ان فنکشنز کو کنٹرول کرنے کے لیے کیا جاتا ہے جو کنٹریکٹ کے غیر محفوظ ہونے پر ناقابل رسائی ہونے چاہئیں (جیسے، deposit())۔ ان فنکشنز کی کالز آسانی سے ریورٹ ہو جائیں گی۔

onlyWhenStopped ان فنکشنز کے لیے استعمال کیا جاتا ہے جو ایمرجنسی کے دوران کال کے قابل ہونے چاہئیں (جیسے، emergencyWithdraw())۔ ایسے فنکشنز صورتحال کو حل کرنے میں مدد کر سکتے ہیں، اس لیے انہیں "محدود فنکشنز" کی فہرست سے خارج کر دیا گیا ہے۔

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

ایونٹ مانیٹرنگ

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

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

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

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

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

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

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

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

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

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

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

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

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

ری اینٹرنسی (Reentrancy)

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

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

ایک سادہ سمارٹ کنٹریکٹ ('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() فنکشن "checks-interactions-effects" پیٹرن کی پیروی کرتا ہے۔ یہ چیک کرتا ہے کہ آیا ایگزیکیوشن کے لیے ضروری شرائط پوری ہو گئی ہیں (یعنی، صارف کا ETH بیلنس مثبت ہے) اور ٹرانزیکشن کے اثرات (یعنی، صارف کا بیلنس کم کرنا) لاگو کرنے سے پہلے، کالر کے ایڈریس پر ETH بھیج کر تعامل (interaction) انجام دیتا ہے۔

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

ری اینٹرنسی حملوں کو کیسے روکا جائے

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

checks-effect-interaction پیٹرن کو ذیل میں دکھائے گئے 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 پر ریورٹ ہو جاتا ہے۔ جیسا کہ ذیل کی مثال میں دیکھا گیا ہے، میوٹیکس کا استعمال کسی فنکشن کو ریکرسیو کالز (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;
    }
    // یہ فنکشن ایک mutex کے ذریعے محفوظ ہے، لہذا `msg.sender.call` کے اندر سے reentrant کالز دوبارہ `withdraw` کو کال نہیں کر سکتیں۔
    //  `return` اسٹیٹمنٹ `true` کا نتیجہ دیتی ہے لیکن پھر بھی موڈیفائر میں `locked = false` اسٹیٹمنٹ کو evaluate کرتی ہے
    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) (نئے ٹیب میں کھلتا ہے) سسٹم بھی استعمال کر سکتے ہیں جس میں صارفین کو سمارٹ کنٹریکٹس سے فنڈز نکالنے کی ضرورت ہوتی ہے، بجائے اس کے کہ "پش پیمنٹس" (push payments) سسٹم جو اکاؤنٹس میں فنڈز بھیجتا ہے۔ یہ نامعلوم ایڈریسز پر نادانستہ طور پر کوڈ کو متحرک کرنے کے امکان کو ختم کرتا ہے (اور کچھ ڈینائل آف سروس (denial-of-service) حملوں کو بھی روک سکتا ہے)۔

انٹیجر انڈر فلوز اور اوور فلوز (Integer underflows and overflows)

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

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

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

pragma solidity ^0.7.6;

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

/*
1. TimeLock ڈیپلائے کریں
2. TimeLock کے ایڈریس کے ساتھ Attack ڈیپلائے کریں
3. 1 ether بھیج کر Attack.attack کو کال کریں۔ آپ فوری طور پر اپنا ether نکال سکیں گے۔

کیا ہوا؟
Attack نے TimeLock.lockTime کو overflow کر دیا اور 1 ہفتے کے انتظار کی مدت سے پہلے ہی withdraw کرنے کے قابل ہو گیا۔
*/

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

اوریکل مینیپولیشن (Oracle manipulation)

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

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

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

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

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

اوریکل مینیپولیشن کو کیسے روکا جائے

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

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

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

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

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

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

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

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

• Fork Checker (نئے ٹیب میں کھلتا ہے) - فورک شدہ کنٹریکٹ کے حوالے سے تمام دستیاب معلومات چیک کرنے کے لیے ایک مفت آن لائن ٹول۔

• ABI Encoder (نئے ٹیب میں کھلتا ہے) - آپ کے Solidity کنٹریکٹ فنکشنز اور کنسٹرکٹر آرگیومنٹس کو انکوڈ کرنے کے لیے ایک مفت آن لائن سروس۔

• Aderyn (نئے ٹیب میں کھلتا ہے) - Solidity کا جامد تجزیہ کار (Static Analyzer)، جو مشتبہ کمزوریوں کی نشاندہی کرنے کے لیے ایبسٹریکٹ سنٹیکس ٹریز (AST) کو عبور کرتا ہے اور مسائل کو آسانی سے سمجھ میں آنے والے مارک ڈاؤن فارمیٹ میں پرنٹ کرتا ہے۔

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

• Tenderly Real-Time Alerting (نئے ٹیب میں کھلتا ہے) - جب آپ کے سمارٹ کنٹریکٹس یا والیٹس پر غیر معمولی یا غیر متوقع واقعات پیش آئیں تو ریئل ٹائم اطلاعات حاصل کرنے کا ایک ٹول۔

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

• Safe (نئے ٹیب میں کھلتا ہے) - ایتھیریم پر چلنے والا سمارٹ کنٹریکٹ والیٹ جس میں کسی ٹرانزیکشن کے ہونے سے پہلے اسے منظور کرنے کے لیے کم از کم لوگوں کی ضرورت ہوتی ہے (M-of-N)۔

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

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

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

• CertiK (نئے ٹیب میں کھلتا ہے) - بلاک چین سیکیورٹی فرم جو سمارٹ کنٹریکٹس اور بلاک چین نیٹ ورکس پر جدید ترین رسمی تصدیق (formal Verification) ٹیکنالوجی کے استعمال میں پیش پیش ہے۔

• Trail of Bits (نئے ٹیب میں کھلتا ہے) - سائبر سیکیورٹی کمپنی جو خطرے کو کم کرنے اور کوڈ کو مضبوط بنانے کے لیے سیکیورٹی ریسرچ کو حملہ آور کی ذہنیت کے ساتھ جوڑتی ہے۔

• PeckShield (نئے ٹیب میں کھلتا ہے) - بلاک چین سیکیورٹی کمپنی جو پورے بلاک چین ایکو سسٹم کی سیکیورٹی، پرائیویسی، اور افادیت کے لیے پروڈکٹس اور سروسز پیش کرتی ہے۔

• QuantStamp (نئے ٹیب میں کھلتا ہے) - آڈیٹنگ سروس جو سیکیورٹی اور رسک اسسمنٹ سروسز کے ذریعے بلاک چین ٹیکنالوجی کو مرکزی دھارے میں اپنانے میں سہولت فراہم کرتی ہے۔

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

• Runtime Verification (نئے ٹیب میں کھلتا ہے) - سیکیورٹی کمپنی جو سمارٹ کنٹریکٹس کی رسمی ماڈلنگ اور تصدیق میں مہارت رکھتی ہے۔

• Hacken (نئے ٹیب میں کھلتا ہے) - Web3 سائبر سیکیورٹی آڈیٹر جو بلاک چین سیکیورٹی کے لیے 360 ڈگری اپروچ لاتا ہے۔

• Nethermind (نئے ٹیب میں کھلتا ہے) - Solidity اور Cairo آڈیٹنگ سروسز، جو ایتھیریم اور Starknet پر سمارٹ کنٹریکٹس کی سالمیت اور صارفین کی حفاظت کو یقینی بناتی ہیں۔

• HashEx (نئے ٹیب میں کھلتا ہے) - HashEx کرپٹو کرنسیوں کی سیکیورٹی کو یقینی بنانے کے لیے بلاک چین اور سمارٹ کنٹریکٹ آڈیٹنگ پر توجہ مرکوز کرتا ہے، اور سمارٹ کنٹریکٹ ڈیولپمنٹ، پینیٹریشن ٹیسٹنگ، اور بلاک چین کنسلٹنگ جیسی سروسز فراہم کرتا ہے۔

• Code4rena (نئے ٹیب میں کھلتا ہے) - مسابقتی آڈٹ پلیٹ فارم جو سمارٹ کنٹریکٹ سیکیورٹی کے ماہرین کو کمزوریاں تلاش کرنے اور Web3 کو مزید محفوظ بنانے میں مدد کرنے کی ترغیب دیتا ہے۔

• CodeHawks (نئے ٹیب میں کھلتا ہے) - مسابقتی آڈٹ پلیٹ فارم جو سیکیورٹی محققین کے لیے سمارٹ کنٹریکٹس آڈیٹنگ کے مقابلوں کی میزبانی کرتا ہے۔

• Cyfrin (نئے ٹیب میں کھلتا ہے) - Web3 سیکیورٹی پاور ہاؤس، جو پروڈکٹس اور سمارٹ کنٹریکٹ آڈیٹنگ سروسز کے ذریعے کرپٹو سیکیورٹی کو فروغ دیتا ہے۔

• ImmuneBytes (نئے ٹیب میں کھلتا ہے) - Web3 سیکیورٹی فرم جو تجربہ کار آڈیٹرز کی ٹیم اور بہترین ٹولز کے ذریعے بلاک چین سسٹمز کے لیے سیکیورٹی آڈٹ پیش کرتی ہے۔

• Oxorio (نئے ٹیب میں کھلتا ہے) - سمارٹ کنٹریکٹ آڈٹ اور بلاک چین سیکیورٹی سروسز جو کرپٹو فرمز اور ڈی فائی (DeFi) پروجیکٹس کے لیے EVM، Solidity، ZK، اور کراس چین ٹیکنالوجی میں مہارت رکھتی ہیں۔

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

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

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

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

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

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

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

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

• کنسینسس: سمارٹ کنٹریکٹ کے معلوم حملے (نئے ٹیب میں کھلتا ہے) - زیادہ تر معاملات کے لیے نمونہ کوڈ کے ساتھ، سب سے اہم کنٹریکٹ کی کمزوریوں کی ابتدائی افراد کے لیے آسان وضاحت۔

• SWC Registry (نئے ٹیب میں کھلتا ہے) - کامن ویکنس اینیومریشن (CWE) آئٹمز کی مرتب کردہ فہرست جو ایتھیریم سمارٹ کنٹریکٹس پر لاگو ہوتی ہے۔

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

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

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

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

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

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

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

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

• Nascent: Simple Security Toolkit (نئے ٹیب میں کھلتا ہے) - سمارٹ کنٹریکٹ ڈیولپمنٹ کے لیے عملی سیکیورٹی پر مرکوز گائیڈز اور چیک لسٹس کا مجموعہ۔

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

• Solidity Docs: Security Considerations (نئے ٹیب میں کھلتا ہے) - Solidity کے ساتھ محفوظ سمارٹ کنٹریکٹس لکھنے کے لیے رہنما خطوط۔

• Smart Contract Security Verification Standard (نئے ٹیب میں کھلتا ہے) - ڈیولپرز، آرکیٹیکٹس، سیکیورٹی جائزہ لینے والوں اور وینڈرز کے لیے سمارٹ کنٹریکٹس کی سیکیورٹی کو معیاری بنانے کے لیے بنائی گئی چودہ حصوں پر مشتمل چیک لسٹ۔

• Learn Smart Contract Security and Auditing (نئے ٹیب میں کھلتا ہے) - سمارٹ کنٹریکٹ سیکیورٹی اور آڈیٹنگ کا حتمی کورس، جو ان سمارٹ کنٹریکٹ ڈیولپرز کے لیے بنایا گیا ہے جو اپنے سیکیورٹی کے بہترین طریقوں کو بہتر بنانا اور سیکیورٹی محققین بننا چاہتے ہیں۔

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

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

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

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

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

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

• Cyfrin Updraft - سمارٹ کنٹریکٹس سیکیورٹی اور آڈیٹنگ کا مکمل کورس (نئے ٹیب میں کھلتا ہے)