مرکزی مواد پر جائیں
Change page

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

صفحہ کی آخری اپ ڈیٹ: 26 فروری، 2026

corwintinesc (opens in a new tab)
MOSHKA-GOTM (opens in a new tab)
mdqstm (opens in a new tab)
+22

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

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

پیشگی شرائط

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

اسمارٹ کانٹریکٹ ٹیسٹنگ کیا ہے؟

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

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

اسمارٹ کانٹریکٹس کو ٹیسٹ کرنا کیوں ضروری ہے؟

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

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

اسمارٹ کانٹریکٹس کی ٹیسٹنگ کے طریقے

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

خودکار ٹیسٹنگ

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

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

دستی ٹیسٹنگ

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

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

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

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

یونٹ ٹیسٹنگ

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

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

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

1. اپنے کانٹریکٹ کی بزنس لاجک اور ورک فلو کو سمجھیں

یونٹ ٹیسٹ لکھنے سے پہلے، یہ جاننا مددگار ثابت ہوتا ہے کہ ایک اسمارٹ کانٹریکٹ کیا خصوصیات پیش کرتا ہے اور صارفین ان فنکشنز تک کیسے رسائی حاصل کریں گے اور انہیں کیسے استعمال کریں گے۔ یہ خاص طور پر ہیپی پاتھ ٹیسٹس (happy path tests) (opens in a new tab) چلانے کے لیے مفید ہے جو یہ طے کرتے ہیں کہ آیا کانٹریکٹ میں موجود فنکشنز درست صارف ان پٹس کے لیے صحیح آؤٹ پٹ واپس کرتے ہیں یا نہیں۔ ہم اس تصور کو ایک نیلامی کانٹریکٹ (auction contract) (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}
سب دکھائیں

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

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

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

2. کانٹریکٹ کی ایگزیکیوشن سے متعلق تمام مفروضوں کا جائزہ لیں

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

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

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

  • اگر بولی قابل قبول حد سے کم ہو تو نیلامی کا کانٹریکٹ ریورٹ (revert) ہو جاتا ہے۔

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اسٹیٹک اینالیسس

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

کانٹریکٹس پر اسٹیٹک اینالیسس چلانے کے لیے لنٹنگ (Linting) (opens in a new tab) اور اسٹیٹک ٹیسٹنگ (static testing) (opens in a new tab) عام طریقے ہیں۔ دونوں کے لیے کانٹریکٹ کی ایگزیکیوشن کی نچلی سطح کی نمائندگیوں کا تجزیہ کرنے کی ضرورت ہوتی ہے جیسے کہ کمپائلر کے ذریعے آؤٹ پٹ کیے گئے ایبسٹریکٹ سنٹیکس ٹریز (abstract syntax trees) (opens in a new tab) اور کنٹرول فلو گرافس (control flow graphs) (opens in a new tab)۔

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

ڈائنامک اینالیسس

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

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

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

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

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

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

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

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

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

اسمارٹ کانٹریکٹس کے لیے دستی ٹیسٹنگ

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

لوکل بلاک چین پر کانٹریکٹس کی ٹیسٹنگ

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

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

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

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

ٹیسٹ نیٹس پر کانٹریکٹس کی ٹیسٹنگ

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

دستی ٹیسٹنگ کی یہ شکل صارف کے نقطہ نظر سے آپ کی ایپلیکیشن کے اینڈ ٹو اینڈ فلو (end-to-end flow) کا جائزہ لینے کے لیے مفید ہے۔ یہاں، بیٹا ٹیسٹرز (beta testers) ٹرائل رنز بھی انجام دے سکتے ہیں اور کانٹریکٹ کی بزنس لاجک اور مجموعی فعالیت کے ساتھ کسی بھی مسئلے کی اطلاع دے سکتے ہیں۔

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

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

ٹیسٹنگ بمقابلہ فارمل ویریفیکیشن

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

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

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

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

اسمارٹ کانٹریکٹس کے لیے فارمل ویریفیکیشن کے بارے میں مزید۔

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

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

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

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

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

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

ٹیسٹنگ ٹولز اور لائبریریاں

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

  • solidity-coverage (opens in a new tab) - Solidity میں لکھے گئے اسمارٹ کانٹریکٹس کے لیے کوڈ کوریج ٹول۔

  • Waffle (opens in a new tab) - ایڈوانسڈ اسمارٹ کانٹریکٹ ڈیولپمنٹ اور ٹیسٹنگ کے لیے فریم ورک (ethers.js پر مبنی)۔

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

  • OpenZeppelin Test Helpers (opens in a new tab) - ایتھیریم اسمارٹ کانٹریکٹ ٹیسٹنگ کے لیے توثیق (Assertion) لائبریری۔ یقینی بنائیں کہ آپ کے کانٹریکٹس توقع کے مطابق برتاؤ کرتے ہیں!

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

  • Foundry Tests (opens in a new tab) - Foundry Forge پیش کرتا ہے، جو ایک تیز اور لچکدار ایتھیریم ٹیسٹنگ فریم ورک ہے جو سادہ یونٹ ٹیسٹ، گیس آپٹیمائزیشن چیکس، اور کانٹریکٹ فزنگ کو ایگزیکیوٹ کرنے کی صلاحیت رکھتا ہے۔

  • Hardhat Tests (opens in a new tab) - ethers.js، Mocha، اور Chai پر مبنی اسمارٹ کانٹریکٹس کی ٹیسٹنگ کے لیے فریم ورک۔

  • ApeWorx (opens in a new tab) - ایتھیریم ورچوئل مشین کو نشانہ بنانے والے اسمارٹ کانٹریکٹس کے لیے Python پر مبنی ڈیولپمنٹ اور ٹیسٹنگ فریم ورک۔

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

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

اسٹیٹک اینالیسس ٹولز

  • Slither (opens in a new tab) - کمزوریوں کو تلاش کرنے، کوڈ کی سمجھ کو بڑھانے، اور اسمارٹ کانٹریکٹس کے لیے کسٹم تجزیے لکھنے کے لیے Python پر مبنی Solidity اسٹیٹک اینالیسس فریم ورک۔

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

  • Cyfrin Aderyn (opens in a new tab) - Rust پر مبنی اسٹیٹک اینالائزر جو خاص طور پر Web3 اسمارٹ کانٹریکٹ سیکیورٹی اور ڈیولپمنٹ کے لیے ڈیزائن کیا گیا ہے۔

  • Wake (opens in a new tab) - کمزوری اور کوڈ کوالٹی ڈیٹیکٹرز، کوڈ سے مفید معلومات نکالنے کے لیے پرنٹرز اور کسٹم سب ماڈیولز لکھنے کے لیے سپورٹ کے ساتھ Python پر مبنی اسٹیٹک اینالیسس فریم ورک۔

  • Slippy (opens in a new tab) - Solidity کے لیے ایک سادہ اور طاقتور لنٹر۔

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

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

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

  • Manticore (opens in a new tab) - EVM بائٹ کوڈ کا تجزیہ کرنے کے لیے ڈائنامک سمبولک ایگزیکیوشن فریم ورک۔

  • Mythril (opens in a new tab) - ٹینٹ اینالیسس (taint analysis)، کونکولک اینالیسس (concolic analysis)، اور کنٹرول فلو چیکنگ کا استعمال کرتے ہوئے کانٹریکٹ کی کمزوریوں کا پتہ لگانے کے لیے EVM بائٹ کوڈ اسسمنٹ ٹول۔

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

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

مزید مطالعہ

ٹیوٹوریلز: ایتھیریم پر اسمارٹ کانٹریکٹ ٹیسٹنگ

کیا یہ مضمون مددگار تھا؟