سمارٹ کنٹریکٹ سیکیورٹی کے رہنما اصول

زیادہ محفوظ سمارٹ کنٹریکٹس بنانے کے لیے ان اعلیٰ سطحی سفارشات پر عمل کریں۔

ڈیزائن کے رہنما اصول

کوڈ کی کوئی بھی لائن لکھنے سے پہلے، کنٹریکٹ کے ڈیزائن پر پہلے سے تبادلہ خیال کیا جانا چاہیے۔

دستاویزات اور تخصیصات

دستاویزات مختلف سطحوں پر لکھی جا سکتی ہیں، اور کنٹریکٹس کو نافذ کرتے وقت انہیں اپ ڈیٹ کیا جانا چاہیے:

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

آن چین بمقابلہ آف چین کمپیوٹیشن

• جتنا ممکن ہو کوڈ کو آف چین رکھیں۔ آن چین پرت کو چھوٹا رکھیں۔ ڈیٹا کو آف چین کوڈ کے ساتھ اس طرح پری پروسیس کریں کہ آن چین تصدیق آسان ہو۔ کیا آپ کو ایک ترتیب شدہ فہرست کی ضرورت ہے؟ فہرست کو آف چین ترتیب دیں، پھر صرف آن چین اس کی ترتیب چیک کریں۔

اپ گریڈ کرنے کی صلاحیت

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

• اپ گریڈ کرنے کی صلاحیت پر کنٹریکٹ مائیگریشن (opens in a new tab) کو ترجیح دیں۔ مائیگریشن سسٹمز کے بہت سے وہی فوائد ہیں جو اپ گریڈ ایبل سسٹمز کے ہیں، لیکن ان کی خامیوں کے بغیر۔
• delegatecallproxy پیٹرن پر ڈیٹا علیحدگی (data separation) پیٹرن کا استعمال کریں۔ اگر آپ کے پروجیکٹ میں واضح تجریدی علیحدگی (abstraction separation) ہے، تو ڈیٹا علیحدگی کا استعمال کرتے ہوئے اپ گریڈ کرنے کی صلاحیت کے لیے صرف چند ایڈجسٹمنٹس کی ضرورت ہوگی۔ delegatecallproxy کے لیے EVM کی مہارت درکار ہوتی ہے اور اس میں غلطی کا امکان بہت زیادہ ہوتا ہے۔
• تعیناتی سے پہلے مائیگریشن/اپ گریڈ کے طریقہ کار کو دستاویزی شکل دیں۔ اگر آپ کو بغیر کسی رہنما اصول کے دباؤ میں ردعمل ظاہر کرنا پڑا، تو آپ غلطیاں کریں گے۔ عمل کرنے کا طریقہ کار پہلے سے لکھ لیں۔ اس میں شامل ہونا چاہیے:
  • وہ کالز جو نئے کنٹریکٹس شروع کرتی ہیں
  • کیز (keys) کہاں محفوظ ہیں اور ان تک کیسے رسائی حاصل کی جائے
  • تعیناتی کو کیسے چیک کریں! تعیناتی کے بعد کی سکرپٹ تیار کریں اور اس کا ٹیسٹ کریں۔

نفاذ کے رہنما اصول

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

فنکشن کی ترکیب

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

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

وراثت (Inheritance)

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

ایونٹس

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

معلوم خامیوں سے بچیں

• سب سے عام سیکیورٹی مسائل سے آگاہ رہیں۔ عام مسائل کے بارے میں جاننے کے لیے بہت سے آن لائن وسائل موجود ہیں، جیسے Ethernaut CTF (opens in a new tab)، Capture the Ether (opens in a new tab)، یا Not so smart contracts (opens in a new tab)۔
• Solidity کی دستاویزات (opens in a new tab) میں وارننگ سیکشنز سے آگاہ رہیں۔ وارننگ سیکشنز آپ کو زبان کے غیر واضح رویے کے بارے میں آگاہ کریں گے۔

انحصار (Dependencies)

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

ٹیسٹنگ اور تصدیق

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

Solidity

• Solidity 0.4 اور 0.6 کے مقابلے میں Solidity 0.5 کو ترجیح دیں۔ ہماری رائے میں، Solidity 0.5 زیادہ محفوظ ہے اور اس میں 0.4 کے مقابلے میں بہتر بلٹ ان پریکٹسز ہیں۔ Solidity 0.6 پروڈکشن کے لیے بہت غیر مستحکم ثابت ہوئی ہے اور اسے پختہ ہونے کے لیے وقت درکار ہے۔
• کمپائل کرنے کے لیے ایک مستحکم ریلیز استعمال کریں؛ وارننگز چیک کرنے کے لیے تازہ ترین ریلیز استعمال کریں۔ چیک کریں کہ آپ کے کوڈ میں تازہ ترین کمپائلر ورژن کے ساتھ کوئی رپورٹ شدہ مسائل نہیں ہیں۔ تاہم، Solidity کا ریلیز سائیکل تیز ہے اور اس میں کمپائلر بگز کی تاریخ رہی ہے، اس لیے ہم تعیناتی کے لیے تازہ ترین ورژن کی سفارش نہیں کرتے (سلدر کی solc ورژن کی سفارش (opens in a new tab) دیکھیں)۔
• ان لائن اسمبلی (inline assembly) استعمال نہ کریں۔ اسمبلی کے لیے EVM کی مہارت درکار ہوتی ہے۔ اگر آپ نے یلو پیپر پر عبور حاصل نہیں کیا ہے تو EVM کوڈ نہ لکھیں۔

تعیناتی کے رہنما اصول

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

• اپنے کنٹریکٹس کی نگرانی کریں۔ لاگز دیکھیں، اور کنٹریکٹ یا والیٹ کے سمجھوتے (compromise) کی صورت میں ردعمل ظاہر کرنے کے لیے تیار رہیں۔
• اپنی رابطہ کی معلومات blockchain-security-contacts (opens in a new tab) میں شامل کریں۔ اگر کوئی سیکیورٹی خامی دریافت ہوتی ہے تو یہ فہرست فریق ثالث کو آپ سے رابطہ کرنے میں مدد کرتی ہے۔
• مراعات یافتہ صارفین کے والیٹس کو محفوظ بنائیں۔ اگر آپ ہارڈویئر والیٹس میں کیز محفوظ کرتے ہیں تو ہماری بہترین پریکٹسز (opens in a new tab) پر عمل کریں۔
• واقعے پر ردعمل کا منصوبہ (response to incident plan) رکھیں۔ اس بات پر غور کریں کہ آپ کے سمارٹ کنٹریکٹس سے سمجھوتہ کیا جا سکتا ہے۔ یہاں تک کہ اگر آپ کے کنٹریکٹس بگز سے پاک ہیں، تب بھی ایک حملہ آور کنٹریکٹ کے مالک کی کیز کا کنٹرول سنبھال سکتا ہے۔