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

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

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

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

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

پیشگی شرائط

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

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

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

اسمارٹ کانٹریکٹس میں، public یا external کے طور پر نشان زدہ فنکشنز کو کسی بھی externally owned accounts (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) کو متحرک کیا جا سکے اور اگر عمل درآمد کچھ تقاضوں کو پورا کرنے میں ناکام رہتا ہے تو اسٹیٹ کی تبدیلیوں کو ریورٹ کیا جا سکے۔

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

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

revert(): revert() کو if-else اسٹیٹمنٹ میں استعمال کیا جا سکتا ہے جو ایک استثناء (exception) کو متحرک کرتا ہے اگر مطلوبہ شرط پوری نہیں ہوتی ہے۔ ذیل میں دیا گیا نمونہ کانٹریکٹ فنکشنز کے عمل درآمد کی حفاظت کے لیے revert() کا استعمال کرتا ہے:

1pragma solidity ^0.8.4;
2
3contract VendingMachine {
4    address owner;
5    error Unauthorized();
6    function buy(uint amount) public payable {
7        if (amount > msg.value / 2 ether)
8            revert("Not enough Ether provided.");
9        // Perform the purchase.
10    }
11    function withdraw() public {
12        if (msg.sender != owner)
13            revert Unauthorized();
14
15        payable(msg.sender).transfer(address(this).balance);
16    }
17}
سب دکھائیں

3. اسمارٹ کانٹریکٹس کی جانچ کریں اور کوڈ کی درستگی کی تصدیق کریں

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

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

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

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

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

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

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

آڈٹس

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

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

بگ باؤنٹیز

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

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

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

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

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

تمام کوڈ کو ورژن کنٹرول سسٹم میں اسٹور کریں، جیسے git
کوڈ کی تمام ترامیم پل ریکویسٹس (pull requests) کے ذریعے کریں
یقینی بنائیں کہ پل ریکویسٹس کا کم از کم ایک آزاد جائزہ لینے والا ہو—اگر آپ کسی پروجیکٹ پر اکیلے کام کر رہے ہیں، تو دوسرے ڈیولپرز کو تلاش کرنے اور کوڈ کے جائزوں کا تبادلہ کرنے پر غور کریں
اسمارٹ کانٹریکٹس کی ٹیسٹنگ، کمپائلنگ، اور ڈیپلائنگ کے لیے ایک ڈیولپمنٹ انوائرنمنٹ کا استعمال کریں
اپنے کوڈ کو بنیادی کوڈ تجزیہ ٹولز، جیسے Cyfrin Aderyn (opens in a new tab)، Mythril اور Slither کے ذریعے چلائیں۔ مثالی طور پر، آپ کو ہر پل ریکویسٹ کے ضم (merge) ہونے سے پہلے ایسا کرنا چاہیے اور آؤٹ پٹ میں فرق کا موازنہ کرنا چاہیے
یقینی بنائیں کہ آپ کا کوڈ بغیر کسی خامی کے کمپائل ہوتا ہے، اور Solidity کمپائلر کوئی وارننگ جاری نہیں کرتا ہے
اپنے کوڈ کو مناسب طریقے سے دستاویزی شکل دیں (NatSpec (opens in a new tab) کا استعمال کرتے ہوئے) اور کانٹریکٹ کے فن تعمیر کے بارے میں تفصیلات کو سمجھنے میں آسان زبان میں بیان کریں۔ اس سے دوسروں کے لیے آپ کے کوڈ کا آڈٹ اور جائزہ لینا آسان ہو جائے گا۔

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

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

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

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

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

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

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

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

ایمرجنسی اسٹاپس

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

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

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

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

1// اس کوڈ کا پیشہ ورانہ آڈٹ نہیں کیا گیا ہے اور یہ حفاظت یا درستگی کی کوئی ضمانت نہیں دیتا۔ اسے اپنے خطرے پر استعمال کریں۔
2
3contract EmergencyStop {
4
5    bool isStopped = false;
6
7    modifier stoppedInEmergency {
8        require(!isStopped);
9        _;
10    }
11
12    modifier onlyWhenStopped {
13        require(isStopped);
14        _;
15    }
16
17    modifier onlyAuthorized {
18        // یہاں msg.sender کے اختیار کی جانچ کریں۔
19        _;
20    }
21
22    function stopContract() public onlyAuthorized {
23        isStopped = true;
24    }
25
26    function resumeContract() public onlyAuthorized {
27        isStopped = false;
28    }
29
30    function deposit() public payable stoppedInEmergency {
31        // ڈپازٹ کی منطق یہاں عمل میں آ رہی ہے۔
32    }
33
34    function emergencyWithdraw() public onlyWhenStopped {
35        // ہنگامی انخلاء یہاں ہو رہا ہے۔
36    }
37}
سب دکھائیں

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

isStopped ایک بولین ہے جو شروع میں false اور جب کانٹریکٹ ایمرجنسی موڈ میں داخل ہوتا ہے تو true کا جائزہ لیتا ہے۔
فنکشن موڈیفائرز onlyWhenStopped اور stoppedInEmergency isStopped ویری ایبل کو چیک کرتے ہیں۔ stoppedInEmergency کا استعمال ان فنکشنز کو کنٹرول کرنے کے لیے کیا جاتا ہے جو کانٹریکٹ کے کمزور ہونے پر ناقابل رسائی ہونے چاہئیں (جیسے deposit())۔ ان فنکشنز کی کالز آسانی سے ریورٹ ہو جائیں گی۔

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

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

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

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

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

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

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 ("keep it simple, stupid") اصول سے واقف ہیں، جو سافٹ ویئر ڈیزائن میں غیر ضروری پیچیدگی متعارف کرانے کے خلاف مشورہ دیتا ہے۔ یہ اس دیرینہ سوچ کی پیروی کرتا ہے کہ "پیچیدہ نظام پیچیدہ طریقوں سے ناکام ہوتے ہیں" اور مہنگی غلطیوں کے لیے زیادہ حساس ہوتے ہیں۔

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

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

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

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

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

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

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

1// یہ کنٹریکٹ غیر محفوظ ہے۔ اسے پروڈکشن میں استعمال نہ کریں۔
2
3contract Victim {
4    mapping (address => uint256) public balances;
5
6    function deposit() external payable {
7        balances[msg.sender] += msg.value;
8    }
9
10    function withdraw() external {
11        uint256 amount = balances[msg.sender];
12        (bool success, ) = msg.sender.call.value(amount)("");
13        require(success);
14        balances[msg.sender] = 0;
15    }
16}
سب دکھائیں

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

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

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

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

تصور کریں کہ یہ کانٹریکٹ ایڈریس پر ڈیپلائے کیا گیا کوڈ ہے:

1 contract Attacker {
2    function beginAttack() external payable {
3        Victim(victim_address).deposit.value(1 ether)();
4        Victim(victim_address).withdraw();
5    }
6
7    function() external payable {
8        if (gasleft() > 40000) {
9            Victim(victim_address).withdraw();
10        }
11    }
12}
سب دکھائیں

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

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

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

1- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH
2- `Attacker.beginAttack()` deposits 1 ETH into `Victim`
3- `Attacker` calls `withdraw() in `Victim`
4- `Victim` checks `Attacker`’s balance (1 ETH)
5- `Victim` sends 1 ETH to `Attacker` (which triggers the default function)
6- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal)
7- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call)
8- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function)
9- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals
10- `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) ظاہر کرتی ہیں۔

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

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

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

1contract NoLongerAVictim {
2    function withdraw() external {
3        uint256 amount = balances[msg.sender];
4        balances[msg.sender] = 0;
5        (bool success, ) = msg.sender.call.value(amount)("");
6        require(success);
7    }
8}

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

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

1pragma solidity ^0.7.0;
2
3contract MutexPattern {
4    bool locked = false;
5    mapping(address => uint256) public balances;
6
7    modifier noReentrancy() {
8        require(!locked, "Blocked from reentrancy.");
9        locked = true;
10        _;
11        locked = false;
12    }
13    // یہ فنکشن میوٹیکس (mutex) کے ذریعے محفوظ ہے، لہذا `msg.sender.call` کے اندر سے ری اینٹرینٹ (reentrant) کالز دوبارہ `withdraw` کو کال نہیں کر سکتیں۔
14    // `return` اسٹیٹمنٹ کا نتیجہ `true` نکلتا ہے لیکن یہ پھر بھی موڈیفائر میں `locked = false` اسٹیٹمنٹ کو ایویلیویٹ کرتی ہے۔
15    function withdraw(uint _amount) public payable noReentrancy returns(bool) {
16        require(balances[msg.sender] >= _amount, "No balance to withdraw.");
17
18        balances[msg.sender] -= _amount;
19        (bool success, ) = msg.sender.call{value: _amount}("");
20        require(success);
21
22        return true;
23    }
24}
سب دکھائیں

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

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

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

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

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

1pragma solidity ^0.7.6;
2
3// This contract is designed to act as a time vault.
4// User can deposit into this contract but cannot withdraw for at least a week.
5// User can also extend the wait time beyond the 1 week waiting period.
6
7/*
81. Deploy TimeLock
92. Deploy Attack with address of TimeLock
103. Call Attack.attack sending 1 ether. You will immediately be able to
11   withdraw your ether.
12
13What happened?
14Attack caused the TimeLock.lockTime to overflow and was able to withdraw
15before the 1 week waiting period.
16*/
17
18contract TimeLock {
19    mapping(address => uint) public balances;
20    mapping(address => uint) public lockTime;
21
22    function deposit() external payable {
23        balances[msg.sender] += msg.value;
24        lockTime[msg.sender] = block.timestamp + 1 weeks;
25    }
26
27    function increaseLockTime(uint _secondsToIncrease) public {
28        lockTime[msg.sender] += _secondsToIncrease;
29    }
30
31    function withdraw() public {
32        require(balances[msg.sender] > 0, "Insufficient funds");
33        require(block.timestamp > lockTime[msg.sender], "Lock time not expired");
34
35        uint amount = balances[msg.sender];
36        balances[msg.sender] = 0;
37
38        (bool sent, ) = msg.sender.call{value: amount}("");
39        require(sent, "Failed to send Ether");
40    }
41}
42
43contract Attack {
44    TimeLock timeLock;
45
46    constructor(TimeLock _timeLock) {
47        timeLock = TimeLock(_timeLock);
48    }
49
50    fallback() external payable {}
51
52    function attack() public payable {
53        timeLock.deposit{value: msg.value}();
54        /*
55        if t = current lock time then we need to find x such that
56        x + t = 2**256 = 0
57        so x = -t
58        2**256 = type(uint).max + 1
59        so x = type(uint).max + 1 - t
60        */
61        timeLock.increaseLockTime(
62            type(uint).max + 1 - timeLock.lockTime(address(this))
63        );
64        timeLock.withdraw();
65    }
66}
سب دکھائیں

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

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

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

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

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

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

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

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

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

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

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

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

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

ٹیسٹنگ ٹولز اور لائبریریاں - اسمارٹ کانٹریکٹس پر یونٹ ٹیسٹ، جامد تجزیہ (static analysis)، اور متحرک تجزیہ (dynamic analysis) انجام دینے کے لیے انڈسٹری کے معیاری ٹولز اور لائبریریوں کا مجموعہ۔
رسمی تصدیق کے ٹولز (Formal verification tools) - اسمارٹ کانٹریکٹس میں فنکشنل درستگی کی تصدیق کرنے اور انویرینٹس (invariants) کو چیک کرنے کے ٹولز۔
اسمارٹ کانٹریکٹ آڈیٹنگ سروسز - Ethereum ڈیولپمنٹ پروجیکٹس کے لیے اسمارٹ کانٹریکٹ آڈیٹنگ سروسز فراہم کرنے والی تنظیموں کی فہرست۔
بگ باؤنٹی پلیٹ فارمز - بگ باؤنٹیز کو مربوط کرنے اور اسمارٹ کانٹریکٹس میں اہم کمزوریوں کے ذمہ دارانہ انکشاف پر انعام دینے کے پلیٹ فارمز۔
Fork Checker (opens in a new tab) - فورک شدہ کانٹریکٹ کے حوالے سے تمام دستیاب معلومات چیک کرنے کے لیے ایک مفت آن لائن ٹول۔
ABI Encoder (opens in a new tab) - آپ کے Solidity کانٹریکٹ کے فنکشنز اور کنسٹرکٹر آرگیومنٹس کو انکوڈ کرنے کے لیے ایک مفت آن لائن سروس۔
Aderyn (opens in a new tab) - Solidity Static Analyzer، جو مشتبہ کمزوریوں کی نشاندہی کرنے کے لیے Abstract Syntax Trees (AST) کو ٹریورس کرتا ہے اور مسائل کو آسانی سے پڑھے جانے والے مارک ڈاؤن فارمیٹ میں پرنٹ کرتا ہے۔

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

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

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

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

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

ConsenSys Diligence (opens in a new tab) - اسمارٹ کانٹریکٹ آڈیٹنگ سروس جو بلاک چین ایکو سسٹم میں پروجیکٹس کی مدد کرتی ہے تاکہ یہ یقینی بنایا جا سکے کہ ان کے پروٹوکولز لانچ کے لیے تیار ہیں اور صارفین کی حفاظت کے لیے بنائے گئے ہیں۔
CertiK (opens in a new tab) - بلاک چین سیکیورٹی فرم جو اسمارٹ کانٹریکٹس اور بلاک چین نیٹ ورکس پر جدید ترین رسمی تصدیق (formal Verification) ٹیکنالوجی کے استعمال میں پیش پیش ہے۔
Trail of Bits (opens in a new tab) - سائبر سیکیورٹی کمپنی جو خطرے کو کم کرنے اور کوڈ کو مضبوط بنانے کے لیے سیکیورٹی ریسرچ کو حملہ آور کی ذہنیت کے ساتھ جوڑتی ہے۔
PeckShield (opens in a new tab) - بلاک چین سیکیورٹی کمپنی جو پورے بلاک چین ایکو سسٹم کی سیکیورٹی، پرائیویسی، اور استعمال کے قابل ہونے کے لیے پروڈکٹس اور سروسز پیش کرتی ہے۔
QuantStamp (opens in a new tab) - آڈیٹنگ سروس جو سیکیورٹی اور رسک اسیسمنٹ سروسز کے ذریعے بلاک چین ٹیکنالوجی کو مرکزی دھارے میں اپنانے میں سہولت فراہم کرتی ہے۔
OpenZeppelin (opens in a new tab) - اسمارٹ کانٹریکٹ سیکیورٹی کمپنی جو ڈسٹری بیوٹڈ سسٹمز کے لیے سیکیورٹی آڈٹ فراہم کرتی ہے۔
Runtime Verification (opens in a new tab) - سیکیورٹی کمپنی جو اسمارٹ کانٹریکٹس کی رسمی ماڈلنگ اور تصدیق میں مہارت رکھتی ہے۔
Hacken (opens in a new tab) - Web3 سائبر سیکیورٹی آڈیٹر جو بلاک چین سیکیورٹی کے لیے 360 ڈگری اپروچ لاتا ہے۔
Nethermind (opens in a new tab) - Solidity اور Cairo آڈیٹنگ سروسز، جو Ethereum اور Starknet پر اسمارٹ کانٹریکٹس کی سالمیت اور صارفین کی حفاظت کو یقینی بناتی ہیں۔
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) کی اشاعتیں

ConsenSys: Smart Contract Known Attacks (opens in a new tab) - سب سے اہم کانٹریکٹ کی کمزوریوں کی ابتدائی افراد کے لیے آسان وضاحت، جس میں زیادہ تر معاملات کے لیے نمونہ کوڈ شامل ہے۔
SWC Registry (opens in a new tab) - Common Weakness Enumeration (CWE) آئٹمز کی مرتب کردہ فہرست جو Ethereum اسمارٹ کانٹریکٹس پر لاگو ہوتی ہے۔
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 اسمارٹ کانٹریکٹس کی جارحانہ سیکیورٹی (offensive security) سیکھنے اور بگ ہنٹنگ اور سیکیورٹی آڈیٹنگ میں مہارت پیدا کرنے کے لیے وار گیم۔
Ethernaut (opens in a new tab) - Web3/Solidity پر مبنی وار گیم جہاں ہر لیول ایک اسمارٹ کانٹریکٹ ہے جسے 'ہیک' کرنے کی ضرورت ہوتی ہے۔
HackenProof x HackTheBox (opens in a new tab) - اسمارٹ کانٹریکٹ ہیکنگ چیلنج، جو ایک فینٹسی ایڈونچر میں ترتیب دیا گیا ہے۔ چیلنج کی کامیاب تکمیل ایک نجی بگ باؤنٹی پروگرام تک رسائی بھی دیتی ہے۔

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

ConsenSys: Ethereum Smart Contract Security Best Practices (opens in a new tab) - Ethereum اسمارٹ کانٹریکٹس کو محفوظ بنانے کے لیے رہنما خطوط کی جامع فہرست۔
Nascent: Simple Security Toolkit (opens in a new tab) - اسمارٹ کانٹریکٹ ڈیولپمنٹ کے لیے عملی سیکیورٹی پر مرکوز گائیڈز اور چیک لسٹس کا مجموعہ۔
Solidity Patterns (opens in a new tab) - اسمارٹ کانٹریکٹ پروگرامنگ زبان Solidity کے لیے محفوظ پیٹرنز اور بہترین طریقوں کا مفید مجموعہ۔
Solidity Docs: Security Considerations (opens in a new tab) - Solidity کے ساتھ محفوظ اسمارٹ کانٹریکٹس لکھنے کے لیے رہنما خطوط۔
Smart Contract Security Verification Standard (opens in a new tab) - ڈیولپرز، آرکیٹیکٹس، سیکیورٹی جائزہ لینے والوں اور وینڈرز کے لیے اسمارٹ کانٹریکٹس کی سیکیورٹی کو معیاری بنانے کے لیے بنائی گئی چودہ حصوں پر مشتمل چیک لسٹ۔
Learn Smart Contract Security and Auditing (opens in a new tab) - اسمارٹ کانٹریکٹ سیکیورٹی اور آڈیٹنگ کا حتمی کورس، جو ان اسمارٹ کانٹریکٹ ڈیولپرز کے لیے بنایا گیا ہے جو اپنے سیکیورٹی کے بہترین طریقوں کو بہتر بنانا اور سیکیورٹی محققین بننا چاہتے ہیں۔