اسمارٹ معاہدوں کی جانچ

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

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

شرائط

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

اسمارٹ معاہدے کی جانچ کیا ہے؟

اسمارٹ معاہدے کی جانچ اس بات کی تصدیق کرنے کا عمل ہے کہ اسمارٹ معاہدے کا کوڈ توقع کے مطابق کام کرتا ہے۔ جانچ اس بات کی پڑتال کے لیے مفید ہے کہ آیا کوئی خاص اسمارٹ معاہدہ وشوسنییتا، استعمال پذیری، اور سیکورٹی کی ضروریات کو پورا کرتا ہے۔

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

اسمارٹ معاہدوں کی جانچ کرنا کیوں ضروری ہے؟

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

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

اسمارٹ معاہدوں کی جانچ کے طریقے

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

خودکار جانچ

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

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

دستی جانچ

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

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

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

اسمارٹ معاہدوں کے لیے خودکار جانچ

یونٹ ٹیسٹنگ

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

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

اسمارٹ معاہدوں کی یونٹ ٹیسٹنگ کے لیے رہنما خطوط

1۔ اپنے معاہدوں کی کاروباری منطق اور ورک فلو کو سمجھیں

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

1constructor(
2        uint biddingTime,
3        address payable beneficiaryAddress
4    ) {
5        beneficiary = beneficiaryAddress;
6        auctionEndTime = block.timestamp + biddingTime;
7    }
8
9function bid() external payable {
10
11      if (block.timestamp > auctionEndTime)
12            revert AuctionAlreadyEnded();
13
14      if (msg.value <= highestBid)
15            revert BidNotHighEnough(highestBid);
16
17 if (highestBid != 0) {
18    pendingReturns[highestBidder] += highestBid;
19        }
20        highestBidder = msg.sender;
21        highestBid = msg.value;
22        emit HighestBidIncreased(msg.sender, msg.value);
23    }
24
25 function withdraw() external returns (bool) {
26        uint amount = pendingReturns[msg.sender];
27        if (amount > 0) {
28           pendingReturns[msg.sender] = 0;
29
30        if (!payable(msg.sender).send(amount)) {
31                pendingReturns[msg.sender] = amount;
32                return false;
33            }
34        }
35        return true;
36    }
37
38function auctionEnd() external {
39       if (block.timestamp < auctionEndTime)
40            revert AuctionNotYetEnded();
41        if (ended)
42            revert AuctionEndAlreadyCalled();
43
44        ended = true;
45        emit AuctionEnded(highestBidder, highestBid);
46
47        beneficiary.transfer(highestBid);
48    }
49}
سب دکھائیں
کاپی کریں

یہ ایک سادہ نیلامی کا معاہدہ ہے جو بولی کی مدت کے دوران بولیاں وصول کرنے کے لیے ڈیزائن کیا گیا ہے۔ اگر highestBid بڑھ جاتی ہے، تو پچھلا سب سے زیادہ بولی لگانے والا اپنی رقم وصول کرتا ہے؛ بولی کی مدت ختم ہونے کے بعد، beneficiary اپنی رقم حاصل کرنے کے لیے معاہدے کو کال کرتا ہے۔

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

معاہدے کے آپریشنل ورک فلو کو سمجھنا بھی یونٹ ٹیسٹ لکھنے میں مدد کرتا ہے جو جانچتے ہیں کہ آیا عمل درآمد ضروریات کو پورا کرتا ہے۔ مثال کے طور پر، نیلامی کا معاہدہ یہ بتاتا ہے کہ جب نیلامی ختم ہو چکی ہو تو صارف بولیاں نہیں لگا سکتے (یعنی، جب auctionEndTime block.timestamp سے کم ہو)۔ اس طرح، ایک ڈیولپر ایک یونٹ ٹیسٹ چلا سکتا ہے جو جانچتا ہے کہ نیلامی ختم ہونے پر bid() فنکشن کی کالیں کامیاب ہوتی ہیں یا ناکام (یعنی، جب auctionEndTime > block.timestamp)۔

2۔ معاہدے کے عمل درآمد سے متعلق تمام مفروضوں کا جائزہ لیں

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

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

• صارفین نیلامی ختم ہونے یا شروع نہ ہونے پر بولیاں نہیں لگا سکتے۔

• اگر بولی قابل قبول حد سے کم ہو تو نیلامی کا معاہدہ واپس ہو جاتا ہے۔

• جو صارف بولی جیتنے میں ناکام رہتے ہیں انہیں ان کے فنڈز واپس کر دیے جاتے ہیں

نوٹ: مفروضوں کی جانچ کا ایک اور طریقہ یہ ہے کہ ایسے ٹیسٹ لکھیں جو معاہدے میں فنکشن موڈیفائرزopens in a new tab کو متحرک کریں، خاص طور پر require، assert، اور if…else بیانات۔

3۔ کوڈ کوریج کی پیمائش کریں

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

4. اچھی طرح سے تیار کردہ جانچ کے فریم ورک استعمال کریں

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

Solidity اسمارٹ معاہدوں کے لیے یونٹ ٹیسٹنگ فریم ورک مختلف زبانوں (زیادہ تر JavaScript، Python، اور Rust) میں آتے ہیں۔ مختلف جانچ کے فریم ورک کے ساتھ یونٹ ٹیسٹ چلانا شروع کرنے کے طریقے کے بارے میں معلومات کے لیے ذیل میں کچھ گائیڈز دیکھیں:

• Brownie کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab
• Foundry کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab
• Waffle کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab
• Remix کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab
• Ape کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab
• Hardhat کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab
• Wake کے ساتھ یونٹ ٹیسٹ چلاناopens in a new tab

انٹیگریشن ٹیسٹنگ

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

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

فورک شدہ بلاک چین Mainnet کی طرح برتاؤ کرے گا اور اس میں متعلقہ ریاستوں اور بیلنس والے اکاؤنٹس ہوں گے۔ لیکن یہ صرف ایک سینڈ باکسڈ مقامی ترقیاتی ماحول کے طور پر کام کرتا ہے، یعنی آپ کو لین دین کے لیے حقیقی ETH کی ضرورت نہیں ہوگی، مثال کے طور پر، اور نہ ہی آپ کی تبدیلیاں حقیقی Ethereum پروٹوکول کو متاثر کریں گی۔

پراپرٹی پر مبنی ٹیسٹنگ

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

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

اسٹیٹک تجزیہ

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

Lintingopens in a new tab اور static testingopens in a new tab معاہدوں پر اسٹیٹک تجزیہ چلانے کے عام طریقے ہیں۔ دونوں کو معاہدے کے عمل درآمد کی نچلی سطح کی نمائندگیوں کا تجزیہ کرنے کی ضرورت ہوتی ہے جیسے کہ abstract syntax treesopens in a new tab اور control flow graphsopens in a new tab جو کمپائلر کے ذریعہ آؤٹ پٹ ہوتے ہیں۔

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

متحرک تجزیہ

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

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

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

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

2. آپ کا ٹیسٹ سویٹ پروگرام کے اندر تمام ممکنہ راستوں کا کافی حد تک احاطہ نہیں کر سکتا۔ یہاں تک کہ 100٪ کوریج کے ساتھ بھی، ایج کیسز سے محروم رہنا ممکن ہے۔

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

اسمارٹ معاہدوں کے لیے پراپرٹی پر مبنی ٹیسٹنگ چلانے کے لیے رہنما خطوط

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

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

• Slither کے ساتھ اسمارٹ معاہدوں کا اسٹیٹک تجزیہopens in a new tab
• Wake کے ساتھ اسمارٹ معاہدوں کا اسٹیٹک تجزیہopens in a new tab
• Brownie کے ساتھ پراپرٹی پر مبنی ٹیسٹنگopens in a new tab
• Foundry کے ساتھ معاہدوں کی فزنگopens in a new tab
• Echidna کے ساتھ معاہدوں کی فزنگopens in a new tab
• Wake کے ساتھ معاہدوں کی فزنگopens in a new tab
• Manticore کے ساتھ اسمارٹ معاہدوں کا علامتی عمل درآمدopens in a new tab
• Mythril کے ساتھ اسمارٹ معاہدوں کا علامتی عمل درآمدopens in a new tab

اسمارٹ معاہدوں کے لیے دستی جانچ

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

مقامی بلاک چین پر معاہدوں کی جانچ

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

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

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

ترقیاتی نیٹ ورکس کے بارے میں مزید۔

ٹیسٹ نیٹس پر معاہدوں کی جانچ

ایک ٹیسٹ نیٹ ورک یا ٹیسٹ نیٹ بالکل Ethereum Mainnet کی طرح کام کرتا ہے، سوائے اس کے کہ یہ ایتھر (ETH) کا استعمال کرتا ہے جس کی کوئی حقیقی دنیا کی قیمت نہیں ہوتی۔ اپنے معاہدے کو ٹیسٹ نیٹ پر تعینات کرنے کا مطلب ہے کہ کوئی بھی اس کے ساتھ تعامل کر سکتا ہے (مثلاً، dApp کے فرنٹ اینڈ کے ذریعے) بغیر فنڈز کو خطرے میں ڈالے۔

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

مقامی بلاک چین پر جانچ کے بعد ٹیسٹ نیٹ پر تعینات کرنا مثالی ہے کیونکہ سابقہ Ethereum ورچوئل مشین کے رویے کے زیادہ قریب ہے۔ لہذا، بہت سے Ethereum-native پروجیکٹس کے لیے یہ عام ہے کہ وہ dapps کو ٹیسٹ نیٹس پر تعینات کریں تاکہ حقیقی دنیا کے حالات میں اسمارٹ معاہدے کے آپریشن کا جائزہ لیا جا سکے۔

Ethereum ٹیسٹ نیٹس کے بارے میں مزید۔

جانچ بمقابلہ رسمی تصدیق

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

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

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

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

اسمارٹ معاہدوں کے لیے رسمی تصدیق پر مزید۔

جانچ بمقابلہ آڈٹ اور بگ باؤنٹیز

جیسا کہ ذکر کیا گیا ہے، سخت جانچ شاذ و نادر ہی کسی معاہدے میں بگس کی عدم موجودگی کی ضمانت دے سکتی ہے؛ رسمی تصدیق کے طریقے درستگی کی مضبوط یقین دہانی فراہم کر سکتے ہیں لیکن فی الحال استعمال کرنا مشکل ہیں اور کافی اخراجات آتے ہیں۔

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

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

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

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

جانچ کے ٹولز اور لائبریریاں

یونٹ ٹیسٹنگ ٹولز

• solidity-coverageopens in a new tab - Solidity میں لکھے گئے اسمارٹ معاہدوں کے لیے کوڈ کوریج ٹول۔

• Waffleopens in a new tab - جدید اسمارٹ معاہدے کی ترقی اور جانچ کے لیے فریم ورک (ethers.js پر مبنی)۔

• Remix Testsopens in a new tab - Solidity اسمارٹ معاہدوں کی جانچ کے لیے ٹول۔ Remix IDE "Solidity Unit Testing" پلگ ان کے تحت کام کرتا ہے جو معاہدے کے لیے ٹیسٹ کیسز لکھنے اور چلانے کے لیے استعمال ہوتا ہے۔

• OpenZeppelin Test Helpersopens in a new tab - Ethereum اسمارٹ معاہدے کی جانچ کے لیے دعوے کی لائبریری۔ یقینی بنائیں کہ آپ کے معاہدے توقع کے مطابق برتاؤ کرتے ہیں!

• Brownie unit testing frameworkopens in a new tab - Brownie Pytest کا استعمال کرتا ہے، جو ایک خصوصیت سے بھرپور ٹیسٹ فریم ورک ہے جو آپ کو کم سے کم کوڈ کے ساتھ چھوٹے ٹیسٹ لکھنے دیتا ہے، بڑے پروجیکٹس کے لیے اچھی طرح سے اسکیل کرتا ہے، اور انتہائی قابل توسیع ہے۔

• Foundry Testsopens in a new tab - Foundry Forge پیش کرتا ہے، جو ایک تیز اور لچکدار Ethereum ٹیسٹنگ فریم ورک ہے جو سادہ یونٹ ٹیسٹ، گیس کی اصلاح کی جانچ، اور معاہدے کی فزنگ کو انجام دینے کی صلاحیت رکھتا ہے۔

• Hardhat Testsopens in a new tab - ethers.js, Mocha, اور Chai پر مبنی اسمارٹ معاہدوں کی جانچ کے لیے فریم ورک۔

• ApeWorxopens in a new tab - Ethereum ورچوئل مشین کو ہدف بنانے والے اسمارٹ معاہدوں کے لیے Python پر مبنی ترقی اور جانچ کا فریم ورک۔

• Wakeopens in a new tab - بہترین صارف کے تجربے اور کارکردگی کے لیے pytest اور Anvil کا استعمال کرتے ہوئے، مضبوط ڈیبگنگ صلاحیتوں اور کراس چین ٹیسٹنگ سپورٹ کے ساتھ یونٹ ٹیسٹنگ اور فزنگ کے لیے Python پر مبنی فریم ورک۔

پراپرٹی پر مبنی ٹیسٹنگ ٹولز

اسٹیٹک تجزیہ ٹولز

• Slitheropens in a new tab - کمزوریوں کو تلاش کرنے، کوڈ کی تفہیم کو بڑھانے، اور اسمارٹ معاہدوں کے لیے اپنی مرضی کے مطابق تجزیے لکھنے کے لیے Python پر مبنی Solidity اسٹیٹک تجزیہ فریم ورک۔

• Ethlintopens in a new tab - Solidity اسمارٹ معاہدے کی پروگرامنگ زبان کے لیے اسٹائل اور سیکورٹی کے بہترین طریقوں کو نافذ کرنے کے لیے Linter۔

• Cyfrin Aderynopens in a new tab - Rust پر مبنی اسٹیٹک اینالائزر خاص طور پر Web3 اسمارٹ معاہدے کی سیکورٹی اور ترقی کے لیے ڈیزائن کیا گیا ہے۔

• Wakeopens in a new tab - کمزوری اور کوڈ کے معیار کے ڈیٹیکٹرز کے ساتھ Python پر مبنی اسٹیٹک تجزیہ فریم ورک، کوڈ سے مفید معلومات نکالنے کے لیے پرنٹرز اور اپنی مرضی کے مطابق سب ماڈیولز لکھنے کے لیے سپورٹ۔

• Slippyopens in a new tab - Solidity کے لیے ایک سادہ اور طاقتور linter۔

متحرک تجزیہ ٹولز

• Echidnaopens in a new tab - پراپرٹی پر مبنی ٹیسٹنگ کے ذریعے اسمارٹ معاہدوں میں کمزوریوں کا پتہ لگانے کے لیے تیز معاہدہ فزر۔

• Diligence Fuzzingopens in a new tab - اسمارٹ معاہدے کے کوڈ میں پراپرٹی کی خلاف ورزیوں کا پتہ لگانے کے لیے مفید خودکار فزنگ ٹول۔

• Manticoreopens in a new tab - EVM بائٹ کوڈ کا تجزیہ کرنے کے لیے متحرک علامتی عمل درآمد کا فریم ورک۔

• Mythrilopens in a new tab - ٹینٹ تجزیہ، کونکولک تجزیہ، اور کنٹرول فلو چیکنگ کا استعمال کرتے ہوئے معاہدے کی کمزوریوں کا پتہ لگانے کے لیے EVM بائٹ کوڈ کی تشخیص کا ٹول۔

• Diligence Scribbleopens in a new tab - Scribble ایک تفصیلات کی زبان اور رن ٹائم تصدیق کا ٹول ہے جو آپ کو اسمارٹ معاہدوں کو ایسی خصوصیات کے ساتھ تشریح کرنے کی اجازت دیتا ہے جو آپ کو Diligence Fuzzing یا MythX جیسے ٹولز کے ساتھ معاہدوں کی خود بخود جانچ کرنے کی اجازت دیتی ہیں۔

متعلقہ ٹیوٹوریلز

• مختلف جانچ کی مصنوعات کا ایک جائزہ اور موازنہ _
• اسمارٹ معاہدوں کی جانچ کے لیے Echidna کا استعمال کیسے کریں
• اسمارٹ کنٹریکٹ بگز تلاش کرنے کے لیے Manticore کا استعمال کیسے کریں
• اسمارٹ کنٹریکٹ بگز تلاش کرنے کے لیے Slither کا استعمال کیسے کریں
• جانچ کے لیے Solidity معاہدوں کو کیسے موک کریں
• Foundry کا استعمال کرتے ہوئے Solidity میں یونٹ ٹیسٹ کیسے چلائیںopens in a new tab

مزید پڑھیں

• ایتھیریم اسمارٹ معاہدوں کی جانچ کے لیے ایک گہرا گائیڈopens in a new tab
• ایتھیریم اسمارٹ معاہدوں کی جانچ کیسے کریںopens in a new tab
• ڈیولپرز کے لیے MolochDAO کا یونٹ ٹیسٹنگ گائیڈopens in a new tab
• اسمارٹ معاہدوں کو ایک راک اسٹار کی طرح کیسے جانچیںopens in a new tab