کنٹریکٹ آڈٹس

سمارٹ کنٹریکٹس کا آڈٹ کیوں ہوتا ہے

زیادہ تر سافٹ ویئر خرابی ملنے کے بعد ٹھیک کیا جا سکتا ہے۔ عوامی چین پر سمارٹ کنٹریکٹ عموماً نہیں۔ ⁨ethereum.org⁩ نوٹ کرتی ہے کہ ڈیپلائے شدہ کنٹریکٹ کا کوڈ عموماً سیکیورٹی کی خامیاں دور کرنے کے لیے بدلا نہیں جا سکتا، اور اندازہ لگاتی ہے کہ سمارٹ کنٹریکٹس میں سیکیورٹی کی خامیوں سے چوری یا ضائع ہونے والی قدر آسانی سے ⁦$1⁩ ارب سے زیادہ ہے ⁦^[1]⁩۔ کوڈ اکثر براہِ راست رقم رکھتا ہے، ہر کسی کے مطالعے کے لیے عوامی ہے، اور حملہ آور کو صرف ایک غلطی ڈھونڈنی ہوتی ہے۔

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

آڈٹ کیا کرتا ہے

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

1. 01

   دائرہ کار

   آڈیٹرز طے کرتے ہیں کہ کون سے کنٹریکٹس، کس کمٹ پر، دائرے میں ہیں، اور آپ کی دستاویزات پڑھتے ہیں کہ سسٹم کو کیا کرنا ہے۔

2. 02

   دستی جائزہ

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

3. 03

   خودکار تجزیہ

   اسٹیٹک تجزیہ کار، فزرز اور کبھی باضابطہ ٹولز ایسے پیٹرنز اور کنارے کی صورتیں ڈھونڈتے ہیں جو کسی شخص سے چھوٹ سکیں۔

4. 04

   رپورٹ

   نتائج سنگینی کے لحاظ سے درج ہوتے ہیں، انتہائی سنگین سے معلوماتی تک، ہر ایک وضاحت اور تجویز کردہ حل کے ساتھ۔

5. 05

   درستی کا جائزہ

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

آڈیٹرز کو سب سے زیادہ ملنے والی خامیاں، سادہ زبان میں

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

آڈٹ کس کا احاطہ نہیں کرتا

⁨ethereum.org⁩ اس بارے میں صاف ہے: آڈٹس ہر خرابی نہیں پکڑیں گے، اور زیادہ تر جائزے کا ایک اضافی دور فراہم کرنے کے لیے ہیں ⁦^[1]⁩۔ اس کے علاوہ زیادہ تر آڈٹس کا دائرہ صرف کنٹریکٹ کے کوڈ تک ہوتا ہے۔ بہت سے نقصانات کہیں اور سے آتے ہیں۔

آڈٹ رپورٹ کیسے پڑھیں

1. 01

   کمٹ جانچیں

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

2. 02

   دائرہ کار اور مفروضے پڑھیں

   کون سے کنٹریکٹس شامل تھے، کون سے باہر، اور آڈیٹرز نے ایڈمنز، اوریکلز اور دیگر کنٹریکٹس کے بارے میں کیا فرض کیا۔

3. 03

   ہر نتیجے کی حیثیت دیکھیں

   حل شدہ، تسلیم شدہ یا کھلا۔ تسلیم شدہ انتہائی سنگین نتیجہ ایک کاروباری فیصلہ ہے جس کی کسی کو وضاحت دینی آنی چاہیے۔

4. 04

   معلوماتی نوٹس بھی پڑھیں

   یہ اکثر ایسے ڈیزائن کے انتخاب بیان کرتے ہیں جنہیں آڈیٹرز نے خطرناک مگر غلط نہیں سمجھا، جو آپ کے اگلے ورژن کے لیے مفید ہے۔

تیاری کیسے کریں، کہ آڈٹ اپنی قیمت کا ہو

آڈیٹرز کا وقت کم اور مہنگا ہے، اس لیے غیر واضح کوڈ سمجھنے یا ایسی خرابیاں ڈھونڈنے میں لگا ہر گھنٹہ جو آپ کے ٹیسٹس کو پکڑنی چاہیے تھیں، اُن باریک مسائل پر نہیں لگتا جن کی آپ انہیں ادائیگی کر رہے ہیں۔ ⁨OpenZeppelin⁩ کی تیاری کی گائیڈ بتاتی ہے کہ وہ آڈٹ سے پہلے کیا توقع رکھتا ہے۔

• ایسی دستاویزات جو ارادہ، ڈیزائن کے انتخاب اور مفروضے سمجھائیں، ⁨README⁩ اور آرکیٹیکچر کے نوٹس سے لے کر ہر فنکشن پر تبصروں تک ⁦^[2]⁩۔
• ایسے ٹیسٹس جو کنارے کی صورتوں اور دوسرے کنٹریکٹس سے انضمام کا احاطہ کریں، کم از کم ⁦90%⁩ کوڈ کوریج کے ہدف کے ساتھ، اور جہاں مددگار ہو فزنگ ⁦^[2]⁩۔
• صاف، پڑھنے کے قابل کوڈ جو یکساں انداز اپنائے، ⁨checks-effects-interactions⁩ جیسے مسلمہ پیٹرنز استعمال کرے، اور انحصاری پیکیجز نقل کرنے کے بجائے پیکیج مینیجر سے درآمد کرے ⁦^[2]⁩۔
• پختہ کوڈ: جانچا ہوا، دستاویزی اور ڈیپلائمنٹ کے لیے تیار، ابھی بدلتا ہوا نہیں ⁦^[2]⁩۔

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

چیک لسٹس اور معیارات، اور ان کی حدیں

چیک لسٹس دونوں فریقوں کو اس پر متفق ہونے میں مدد دیتی ہیں کہ کیا جانچا گیا۔ یہ پرانی بھی ہو جاتی ہیں۔ ⁨Smart Contract Weakness Classification⁩ رجسٹری، جو طویل عرصے تک عام حوالہ رہی، کہتی ہے کہ اس کا مواد 2020 کے بعد سے مکمل طور پر اپ ڈیٹ نہیں ہوا اور نامکمل ہو سکتا ہے، اور قارئین کو اس کے بجائے ⁨EEA EthTrust Security Levels⁩ کی تفصیل اور ⁨Smart Contract Security Verification Standard⁩ کی طرف بھیجتی ہے ⁦^[3]⁩۔ کسی بھی آڈیٹر سے پوچھیں کہ وہ کس معیار کے مقابل جانچتا ہے، اور صرف کسی پرانی رجسٹری سے جوڑی گئی نتائج کی فہرست کو کچھ احتیاط سے لیں۔

کوئی چیک لسٹ سمجھ کی جگہ نہیں لیتی۔ ⁨Consensys Diligence⁩ کی رہنمائی اس بنیاد سے شروع ہوتی ہے کہ معلوم کمزوریوں سے بچاؤ کافی نہیں، اور کنٹریکٹ کی تیاری کو مالیاتی نظاموں جیسے شعبوں کا نظم چاہیے، ناکامی کی تیاری اور احتیاط سے اجرا ⁦^[4]⁩۔

آڈٹ سے آگے سیکیورٹی

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

• پراپرٹی پر مبنی ٹیسٹس اور فزنگ جو کوڈ بدلنے کے ساتھ چلتے رہیں، یونٹ ٹیسٹس کے ساتھ ⁦^[1]⁩۔
• سب سے اہم غیر متغیر شرائط کے لیے باضابطہ تصدیق، جہاں لاگت کا جواز ہو ⁦^[1]⁩۔
• لانچ کے بعد بگ باؤنٹی، تاکہ مسئلہ ڈھونڈنے والوں کو اس کا ناجائز فائدہ اٹھانے کے بجائے رپورٹ کرنے پر ادائیگی ملے ⁦^[1]⁩۔
• بتدریج اجرا: شروع میں جمع شدہ رقوم یا صارفین پر حدیں، جو سسٹم کے خود کو ثابت کرنے کے ساتھ بڑھائی جائیں ⁦^[4]⁩۔
• ہنگامی وقفہ اور اپ گریڈ کا راستہ، اگر ڈیزائن اجازت دے، ٹائم لاک والے ملٹی سگنیچر والیٹ کے اختیار میں تاکہ تبدیلیاں نافذ ہونے سے پہلے نظر آئیں۔
• چین پر سرگرمی کی نگرانی اور غیر معمولی ٹرانزیکشنز پر الرٹس، اس تحریری منصوبے کے ساتھ کہ کچھ غلط ہو تو کون کیا کرے۔

دو ⁨web3⁩ منصوبے، ہمارے نرخ نامے سے قیمت

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

آڈیٹر کا انتخاب

1. 01

   ان کی عوامی رپورٹیں پڑھیں

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

2. 02

   پوچھیں کام کون کرے گا

   آپ کے کام پر جائزہ کاروں کے نام اور تجربہ برانڈ سے زیادہ اہم ہیں۔

3. 03

   دائرہ کار تحریری طور پر طے کریں

   کون سے کنٹریکٹس، کون سا کمٹ، کون سے مفروضے، اور کیا درستی کا جائزہ شامل ہے۔

4. 04

   محنت کو خطرے کے مطابق رکھیں

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

5. 05

   جلد بک کریں

   اچھے آڈیٹرز ہفتوں پہلے بک ہوتے ہیں۔ آڈٹ کا شیڈول بنانا شروع کرتے وقت طے کریں، ختم کرتے وقت نہیں۔

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