ہلموس کے ساتھ علامتی جانچ: رسمی تصدیق کے لیے موجودہ ٹیسٹوں کا فائدہ اٹھانا

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

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

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

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

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

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

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

تفصیلات اوور ہیڈ

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

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

علامتی جانچ اور ہالموس کے ساتھ جانچ اور رسمی تصدیق کے درمیان فرق کو ختم کرنا

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

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

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

مثال: جانچ کرنا isPowerOfTwo() تقریب

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

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

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

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

حد: پابند علامتی عمل درآمد

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

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

مثال کے طور پر، کے درج ذیل تکراری ورژن پر غور کریں۔ isPowerOfTwo() فنکشن، جس میں ایک ان باؤنڈڈ جبکہ لوپ کی خصوصیات ہوتی ہے، جہاں لوپ کی تکرار کی تعداد کا تعین ان پٹ نمبر کی نمائندگی کرنے کے لیے درکار بٹس کی کم از کم تعداد سے ہوتا ہے۔

ہلموس علامتی طور پر اس غیر پابند لوپ کو صرف ایک مخصوص حد تک دہراتا ہے۔ مثال کے طور پر، اگر باؤنڈ کو 3 پر سیٹ کیا جاتا ہے، تو ہالموس لوپ کو زیادہ سے زیادہ 3 بار اعادہ کرے گا اور ان پٹ ویلیوز پر غور نہیں کرے گا جس کی وجہ سے لوپ 3 بار سے زیادہ اعادہ کرے گا (یعنی، 2^3 سے زیادہ یا اس کے برابر کوئی بھی قدر )۔ اس خاص صورت میں، باؤنڈ کو 256 یا اس سے زیادہ پر سیٹ کرنے سے ہیلمس کو مکمل ہونے کا موقع ملے گا۔

ڈیمو: ہالموس کے ساتھ ERC721A کی باقاعدہ تصدیق

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

علامتی جانچ کی خصوصیات

چونکہ ERC721A کے لیے موجودہ ٹیسٹ جاوا اسکرپٹ میں Hardhat کے ساتھ لکھے گئے تھے (جو فی الحال Halmos کے ذریعے تعاون یافتہ نہیں ہے)، ہم نے مرکزی انٹری پوائنٹ کے افعال کے لیے سالیڈٹی میں نئے ٹیسٹ لکھے: mint(), burn()، اور transfer(). ان ٹیسٹوں نے جانچا کہ ہر فنکشن ٹوکن کی ملکیت اور بیلنس کو درست طریقے سے اپ ڈیٹ کرتا ہے، اور دوسرے صارفین کے بیلنس یا ملکیت کو تبدیل کیے بغیر صرف متعلقہ صارفین کو متاثر کرتا ہے۔ مؤخر الذکر ERC721A میں سست ڈیٹا ڈھانچہ الگورتھم کے استعمال کی وجہ سے ثابت کرنا غیر معمولی ہے۔ مثال کے طور پر، مندرجہ ذیل ٹیسٹ چیک کرتا ہے کہ transfer() فنکشن مخصوص ٹوکن کی ملکیت کو درست طریقے سے اپ ڈیٹ کرتا ہے:

ایک اور ٹیسٹ چیک کرتا ہے کہ transfer() فنکشن دوسرے پتوں کے توازن کو تبدیل نہیں کرتا ہے، جو ثابت کرنا مشکل ہے جیسا کہ پہلے ذکر کیا گیا ہے:

تصدیقی نتائج

ہم نے ERC721A سمارٹ کنٹریکٹ پر Halmos کا استعمال کرتے ہوئے ایک تصدیقی تجربہ کیا۔ 19،XNUMX ٹیسٹ. ٹیسٹ ہالموس کے ذریعے 3 کے لوپ انرولنگ باؤنڈ کے ساتھ چلائے گئے، جس کو مکمل ہونے میں 16 منٹ لگے۔ تصدیق کے وقت کی خرابی کو نیچے دیے گئے جدول میں دیکھا جا سکتا ہے۔ یہ تجربہ M1 Pro چپ اور 16 GB میموری کے ساتھ MacBook Pro پر کیا گیا۔

ٹیسٹ	وقت (وقت)
ٹیسٹ برن بیلنس اپ ڈیٹ	6.67
testBurnNextTokenIdUnchanged	1.40
testBurnOtherBalance Preservation	5.69
testBurnOtherOwnership Preservation	189.70
testBurnOwnership Update	3.81
ٹیسٹ برن کی ضروریات	71.95
testMintBalanceUpdate	0.20
testMintNextTokenIdUpdate	0.18
testMintOtherBalance Preservation	0.26
testMintOtherOwnership Preservation	5.74
testMintOwnership Update	1.38
ٹیسٹ منٹ کے تقاضے	0.09
testTransferBalanceUnchanged	9.03
testTransferBalance Update	53.53
testTransferNextTokenIdUnchanged	4.47
testTransferOtherBalance Preservation	19.57
testTransferOtherOwnership Preservation	430.61
testTransferOwnership Update	18.71
ٹیسٹ ٹرانسفر کے تقاضے	149.18

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

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

انجکشن والے کیڑے کے ساتھ تجربہ کریں۔

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

متعلقہ کام

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

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

• K ایک طاقتور رسمی توثیق کا فریم ورک ہے جو کٹوتی توثیق اور متعامل نظریہ کو ثابت کرنے کے قابل بناتا ہے۔ اس کا بنیادی نظریہ اور عمل درآمد ایک اعلی سطحی اظہار فراہم کرتا ہے، جو اسے پیچیدہ پروگراموں اور الگورتھم کی تصدیق کے لیے موزوں بناتا ہے۔ تاہم، یہ واضح رہے کہ K کو خودکار تصدیق پر زیادہ زور دینے کے ساتھ ڈیزائن نہیں کیا گیا ہے اور اس میں کچھ آٹومیشن خصوصیات کی کمی ہے جس کے لیے تصدیق کے عمل کے دوران مزید دستی کوشش کی ضرورت پڑ سکتی ہے۔ K فریم ورک کو استعمال کرنے کے لیے، رسمی وضاحتیں K زبان میں لکھی جاتی ہیں، جنہیں استعمال کرنے سے پہلے سیکھنا ضروری ہے۔ اس کی طاقت خاص طور پر پیچیدہ نظاموں کی تصدیق میں مفید ہے، جو خودکار استدلال کا استعمال کرتے ہوئے تجزیہ کرنا مشکل ہو سکتا ہے۔
• سرٹورا سمارٹ معاہدوں کے لیے تصدیق کا ایک باضابطہ ٹول ہے جو خودکار تصدیق پر توجہ مرکوز کرتا ہے اور باؤنڈڈ ماڈل چیکنگ کو سپورٹ کرتا ہے، جیسا کہ ہالموس۔ Certora استعمال کرنے کے لیے، ڈویلپرز کو اپنی نئی زبان سیکھنی چاہیے، CVL، وضاحتیں لکھنے کے لیے۔ یہ زبان کنٹریکٹ انویریئنٹس کے ذریعے بہت سی اہم خصوصیات کی جامع وضاحت کی اجازت دیتی ہے، ایک ایسی خصوصیت جس کا حلموس فی الحال تعاون نہیں کرتا ہے۔ ایک بند ذریعہ، ملکیتی ٹول ہونے کے باوجود، Certora مسلسل ترقی اور اچھے صارف کی مدد کے ساتھ، مضبوط رسمی تصدیقی ٹولنگ فراہم کرتا ہے۔
  
  دوسری طرف، ہالموس ایک اوپن سورس ٹول ہے جو پیمانے میں چھوٹا ہے اور اس میں فی الحال Certora کی طرف سے فراہم کردہ کچھ خصوصیات کا فقدان ہے، لیکن اس کا مقصد عوامی بھلائی کے طور پر کام کرنا ہے اور اس کا مقصد بغیر کسی سمارٹ معاہدوں کی فوری تصدیق کے لیے ایک بہترین حل ہے۔ وسیع پیمانے پر سیٹ اپ اور دیکھ بھال کی ضرورت۔
• ایچ ای وی ایم ایک اور باضابطہ تصدیقی ٹول ہے جو ہلموس سے ملتا جلتا ہے۔ یہ پہلے ڈیپ ٹولز کا حصہ تھا، جو فاؤنڈری کا پیش خیمہ ہے۔ HEVM اور Halmos دونوں میں یہ خصوصیت ہے کہ الگ الگ تصریح کی ضرورت نہیں ہے اور علامتی طور پر موجودہ ٹیسٹوں کو دعوے کی خلاف ورزیوں کی شناخت کے لیے انجام دے سکتے ہیں۔ یہ صارفین کو دونوں ٹولز کو ایک دوسرے کے ساتھ استعمال کرنے یا انہیں ایک ہی ٹیسٹ کے لیے متوازی طور پر چلانے کی اجازت دیتا ہے، انہیں علامتی جانچ کے لیے متعدد اختیارات فراہم کرتا ہے۔
  
  یہ بات قابل غور ہے کہ، ان کی مماثلتوں کے باوجود، HEVM اور Halmos کو آزادانہ طور پر تیار کیا گیا ہے اور ان کے نفاذ کی تفصیلات میں فرق ہے۔ خاص طور پر اصلاح اور علامتی استدلال کی حکمت عملی کے لحاظ سے۔ مزید برآں، HEVM کو ہاسکل میں لکھا جاتا ہے، جب کہ ہلموس کو Python میں لکھا جاتا ہے، جو Python کے بھرپور ماحولیاتی نظام کو ظاہر کرتا ہے۔ دونوں ٹولز استعمال کرنے کی اہلیت صارفین کو زیادہ لچک اور اختیارات فراہم کرتی ہے تاکہ سمارٹ معاہدوں کی حفاظت اور درستگی کو یقینی بنایا جا سکے۔

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

**

یہاں بیان کردہ خیالات انفرادی AH Capital Management, LLC ("a16z") کے اہلکاروں کے ہیں جن کا حوالہ دیا گیا ہے اور یہ a16z یا اس سے وابستہ افراد کے خیالات نہیں ہیں۔ یہاں پر موجود کچھ معلومات فریق ثالث کے ذرائع سے حاصل کی گئی ہیں، بشمول a16z کے زیر انتظام فنڈز کی پورٹ فولیو کمپنیوں سے۔ اگرچہ قابل اعتماد مانے جانے والے ذرائع سے لیا گیا ہے، a16z نے آزادانہ طور پر ایسی معلومات کی تصدیق نہیں کی ہے اور معلومات کی موجودہ یا پائیدار درستگی یا کسی دی گئی صورتحال کے لیے اس کی مناسبیت کے بارے میں کوئی نمائندگی نہیں کی ہے۔ اس کے علاوہ، اس مواد میں فریق ثالث کے اشتہارات شامل ہو سکتے ہیں۔ a16z نے اس طرح کے اشتہارات کا جائزہ نہیں لیا ہے اور اس میں موجود کسی بھی اشتہاری مواد کی توثیق نہیں کرتا ہے۔

یہ مواد صرف معلوماتی مقاصد کے لیے فراہم کیا گیا ہے، اور قانونی، کاروبار، سرمایہ کاری، یا ٹیکس کے مشورے کے طور پر اس پر انحصار نہیں کیا جانا چاہیے۔ آپ کو ان معاملات کے بارے میں اپنے مشیروں سے مشورہ کرنا چاہئے۔ کسی بھی سیکیورٹیز یا ڈیجیٹل اثاثوں کے حوالے صرف مثالی مقاصد کے لیے ہیں، اور سرمایہ کاری کی سفارش یا پیشکش کی تشکیل نہیں کرتے ہیں کہ سرمایہ کاری کی مشاورتی خدمات فراہم کریں۔ مزید برآں، یہ مواد کسی سرمایہ کار یا ممکنہ سرمایہ کاروں کی طرف سے استعمال کرنے کے لیے نہیں ہے اور نہ ہی اس کا مقصد ہے، اور کسی بھی صورت میں a16z کے زیر انتظام کسی بھی فنڈ میں سرمایہ کاری کرنے کا فیصلہ کرتے وقت اس پر انحصار نہیں کیا جا سکتا ہے۔ (a16z فنڈ میں سرمایہ کاری کرنے کی پیشکش صرف پرائیویٹ پلیسمنٹ میمورنڈم، سبسکرپشن ایگریمنٹ، اور اس طرح کے کسی بھی فنڈ کی دیگر متعلقہ دستاویزات کے ذریعے کی جائے گی اور ان کو مکمل طور پر پڑھا جانا چاہیے۔) کوئی بھی سرمایہ کاری یا پورٹ فولیو کمپنیوں کا ذکر کیا گیا، حوالہ دیا گیا، یا بیان کردہ A16z کے زیر انتظام گاڑیوں میں ہونے والی تمام سرمایہ کاری کے نمائندے نہیں ہیں، اور اس بات کی کوئی یقین دہانی نہیں ہو سکتی کہ سرمایہ کاری منافع بخش ہو گی یا مستقبل میں کی جانے والی دیگر سرمایہ کاری میں بھی ایسی ہی خصوصیات یا نتائج ہوں گے۔ Andreessen Horowitz کے زیر انتظام فنڈز کے ذریعے کی گئی سرمایہ کاری کی فہرست (ان سرمایہ کاری کو چھوڑ کر جن کے لیے جاری کنندہ نے a16z کو عوامی طور پر ظاہر کرنے کے ساتھ ساتھ عوامی طور پر تجارت کیے جانے والے ڈیجیٹل اثاثوں میں غیر اعلانیہ سرمایہ کاری کی اجازت فراہم نہیں کی ہے) https://a16z.com/investments پر دستیاب ہے۔ /.

اندر فراہم کردہ چارٹس اور گراف صرف معلوماتی مقاصد کے لیے ہیں اور سرمایہ کاری کا کوئی فیصلہ کرتے وقت ان پر انحصار نہیں کیا جانا چاہیے۔ ماضی کی کارکردگی مستقبل کے نتائج کا اشارہ نہیں ہے۔ مواد صرف اشارہ کردہ تاریخ کے مطابق بولتا ہے۔ کوئی بھی تخمینہ، تخمینہ، پیشن گوئی، اہداف، امکانات، اور/یا ان مواد میں بیان کیے گئے خیالات بغیر اطلاع کے تبدیل کیے جا سکتے ہیں اور دوسروں کی رائے سے مختلف یا اس کے برعکس ہو سکتے ہیں۔ اضافی اہم معلومات کے لیے براہ کرم https://a16z.com/disclosures دیکھیں۔