سمارٹ معاہدے اور ڈی اے او کا نفاذ

ناگزیر کیڑے اور ناقابل تغیر کوڈ کا المناک امتزاج

گزشتہ ہفتے Ethereum ماحولیاتی نظام میں ایک تباہ کن واقعہ کا مشاہدہ کیا، جب ڈی اے اودو ماہ سے بھی کم پرانا سمارٹ کنٹریکٹ، تیزی سے کسی نامعلوم پارٹی کو فنڈز لیک کرنے لگا۔ کی طرف دیکھ رہے ہیں۔ موجودہ سیٹ Ethereum کے معاہدوں کا، جو کیسینو اور خود اعلان کردہ Ponzi اسکیموں سے بھرا ہوا، یہ شاید کوئی بڑی بات نہ لگے۔ یعنی، جب تک آپ یہ نہیں جان لیتے کہ ایتھر کے 12 ملین سے زیادہ یونٹس، ایتھرئم کریپٹو کرنسی، تقریباً 20,000 لوگوں نے DAO میں سرمایہ کاری کی تھی۔ یہ وجود میں موجود تمام ایتھر کا تقریباً 15% ہے، جس کی قیمت 250 جون کو $17 ملین سے زیادہ ہے۔

دو دن بعد، DAO کے اثاثے $100 ملین سے کم ہو گئے۔ دو چیزوں نے اس تیزی سے زوال میں حصہ لیا۔ سب سے پہلے، اس کے فنڈز کا ایک تہائی حصہ (جیسا کہ ایتھر میں کہا جاتا ہے) پہلے ہی لے لیا گیا تھا۔ اور دوسرا، نتیجے میں پیدا ہونے والی گھبراہٹ نے ایتھر کی مارکیٹ قیمت $21 سے زیادہ کی بلندی سے گر کر مزید 10.67 ڈالر تک پہنچ گئی۔ (اشاعت کے وقت، قیمت تقریباً $14 تک پہنچ گئی تھی۔) یہ دوسرا اثر پہلے کا فطری نتیجہ تھا، کیونکہ ایتھر کی قدر میں حالیہ اضافہ کا زیادہ تر حصہ لوگوں نے اسے The DAO میں سرمایہ کاری کرنے کے لیے خریدا تھا۔

ڈی اے او نے کِک اسٹارٹر یا انڈیگوگو کی طرح ایک نئی قسم کی وکندریقرت کراؤڈ سورسنگ گاڑی کے طور پر کام کرنے کا وعدہ کیا تھا لیکن درمیانی اور ضابطے کے بغیر۔ اسے اس لیے ڈیزائن کیا گیا تھا کہ شرکاء کو اپنی کریپٹو کرنسی جمع کرنے دیں، فنڈنگ ​​کی تلاش میں منصوبوں پر اجتماعی طور پر ووٹ دیں، پھر سرمایہ کاری کریں اور مستقبل کے انعامات حاصل کریں۔ تباہی آنے سے پہلے، 100 سے زیادہ پروجیکٹس پہلے سے ہی تجویز کیا گیا تھا، جن میں سے زیادہ تر خود Ethereum سے متعلق تھے۔ اس کے علاوہ، DAO نے شرکاء کو اپنے غیر سرمایہ کاری شدہ فنڈز کو کسی بھی وقت نکالنے کی اجازت دی، خود کو کم خطرے والی سرمایہ کاری کے طور پر پوزیشن میں رکھا۔

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

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

ڈی اے او کو نکالنا

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

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

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

1. کسی صارف کے واپسی کی درخواست کرنے کا انتظار کریں۔
2. چیک کریں کہ آیا اس صارف کا بیلنس کافی ہے۔
3. اگر ایسا ہے تو، مطلوبہ مقدار صارف کے پتے پر بھیج دیں۔
4. چیک کریں کہ ادائیگی کامیاب تھی۔
5. اگر ایسا ہے تو، صارف کے بیلنس سے مقدار کاٹ لیں۔

یہ سب نمایاں طور پر سمجھدار نظر آتا ہے، بلکہ ایک ATM کی طرح جو آپ کو کچھ نقد رقم دیتا ہے اور آپ کے بینک بیلنس سے مناسب رقم کاٹتا ہے۔

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

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

اس کے مساوی ایک اے ٹی ایم ہوگا جو بینک نوٹ فراہم کرتا ہے جو اسکرین پر لہرانے پر مفت بار بار واپسی کو متحرک کرتا ہے۔ معلوم کرنے والا پہلا صارف اے ٹی ایم کو مکمل طور پر خالی کر سکتا ہے۔

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

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

کوڈ کے ساتھ پریشانی

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

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

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

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

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

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

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

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

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

ناقابل تغیر کوڈ پر

تو یہاں ہم سمارٹ معاہدوں کے ساتھ بنیادی مسئلہ کی طرف آتے ہیں، جیسا کہ DAO کے ذریعہ زبردستی سے ظاہر کیا گیا ہے:

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

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

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

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

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

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

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

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

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

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

ایتھریم کا آگے کا راستہ

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

بہر حال، ایک ڈویلپر ماحولیاتی نظام کے طور پر، Ethereum بنیادی طور پر ٹوٹا ہوا دکھائی دیتا ہے۔ جبکہ DAO اس کی سب سے مہنگی اور ہائی پروفائل ناکامی ہے، بہت سے دوسرے معاہدے ہیں۔ اسی طرح کے مسائل میں مبتلا ہیں. تو Ethereum اپنے عمل کو کیسے صاف کر سکتا ہے؟

• ایک واضح پیغام بھیجیں کہ، کم از کم اگلے دو سالوں کے لیے، کوئی بھی کسی سمارٹ کنٹریکٹ کے لیے کوئی فنڈز نہیں بھیجے گا جب تک کہ وہ خود تعلیم کے نام پر انھیں کھونے پر خوش نہ ہوں۔
• ایتھرئم ورچوئل مشین ("EVM") کے ساتھ کچھ واضح مسائل کو حل کریں، یعنی: (a) کال اسٹیک کی حد کو ہٹانا، (b) کوڈ کو متحرک کیے بغیر ایتھر بھیجنے کا طریقہ فراہم کرنا، اور (c) معاہدوں کو بطور نشان زد کرنے کی اجازت دینا۔ non-reentrant"، مطلب یہ ہے کہ ان کے افعال کو اس وقت نہیں بلایا جا سکتا جب وہ پہلے ہی کسی چیز کے بیچ میں ہوں۔
• سمارٹ معاہدوں کے لیے ایک نئی پروگرامنگ لینگویج تیار کریں، جو کہ حساب کے اظہار کے لیے زیادہ پابندی والا طریقہ استعمال کرتی ہے جو درستگی کے رسمی ثبوت. اس شعبے میں کئی دہائیوں کی تحقیق پہلے ہی سرمایہ کاری کی جا چکی ہے، اس لیے اس سے فائدہ اٹھانے کے لیے بہت کچھ موجودہ کام ہے۔ (اس کے لیے خود EVM میں تبدیلی کی ضرورت نہیں ہوگی، کیونکہ منتخب کردہ زبان کو اب بھی باقاعدہ "بائٹ کوڈ" میں مرتب کیا جا سکتا ہے۔)
• محفوظ سمارٹ کنٹریکٹس اور فنکشنز کا ایک آفیشل سیٹ تیار کریں، جن کا ہم مرتبہ جائزہ لیا گیا ہے اور بہت سے مختلف حالات میں خود کو قابل اعتماد ثابت کیا گیا ہے۔ یہ اس کے مشابہ ہے۔ معیاری لائبریریاں جو کئی بالغ پروگرامنگ زبانوں کے لیے دستیاب ہیں۔ (اگرچہ اس وقت یہ پوچھنا پرکشش ہے: کیوں نہ صرف ان لائبریریوں کی فعالیت کو EVM میں ہارڈ کوڈ کیا جائے، اور اس کے نتیجے میں بہت بہتر کارکردگی کا لطف اٹھایا جائے؟ جواب: کیونکہ Ethereum کو خاص طور پر سخت کوڈ والے بلاک چینز سے دور جانے کے لیے ڈیزائن کیا گیا تھا۔ فیچر سیٹ۔ لیکن پھر بھی، یہ آپ کو حیران کر دیتا ہے۔)

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

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

اس دوران، پرائیویٹ بلاک چینز کے صارفین کے لیے، میں صرف وہی دہرا سکتا ہوں جو میں نے پہلے کہا ہے:

اگر آپ کی درخواست کو سمارٹ کنٹریکٹس کی ضرورت نہیں ہے، تو پھر ایک آسان بلاکچین فن تعمیر استعمال کریں۔

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

براہ کرم کوئی تبصرہ پوسٹ کریں۔ لنکڈ پر.