لائٹننگ بگ کا استحصال کرنا اخلاقی انتخاب تھا۔

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

تقریباً ایک مہینے میں دوسری بار، btcd/LND میں ایک بگ کا استحصال ہوا ہے جس کی وجہ سے وہ Bitcoin Core سے اتفاق رائے سے ہٹ گئے۔ ایک بار پھر، Burak وہ ڈویلپر تھا جس نے اس خطرے کو متحرک کیا - اس بار یہ واضح طور پر جان بوجھ کر تھا - اور ایک بار پھر، یہ اتفاقی پرت کے اوپر بٹ کوائن ٹرانزیکشنز کو پارس کرنے کے لیے کوڈ کا مسئلہ تھا۔ جیسا کہ میں نے اپنے میں بحث کی۔ پہلے کیڑے پر ٹکڑا کہ Burak نے متحرک کیا، Taproot سے پہلے اس بات کی حدیں تھیں کہ لین دین میں اسکرپٹ اور گواہ کا ڈیٹا کتنا بڑا ہو سکتا ہے۔ Taproot کے ایکٹیویشن کے ساتھ، ان حدود کو ہٹا دیا گیا تھا اور انفرادی لین دین کے ان حصوں کو محدود کرنے کے لیے صرف بلاک سائز کی حد پر ہی پابندیاں رہ گئی تھیں۔ آخری بگ کے ساتھ مسئلہ یہ تھا کہ اس حقیقت کے باوجود کہ btcd میں متفقہ کوڈ کو اس تبدیلی کی عکاسی کرنے کے لیے مناسب طریقے سے اپ گریڈ کیا گیا تھا، کوڈ کو ہینڈلنگ پیئر ٹو پیئر ٹرانسمیشن - بشمول بھیجنے یا وصول کرنے سے پہلے ڈیٹا کو پارس کرنا - مناسب طریقے سے اپ گریڈ نہیں ہوا۔ لہذا کوڈ پروسیسنگ بلاکس اور ٹرانزیکشنز اس سے پہلے کہ اس کو اتفاق رائے کی توثیق کرنے کے لیے منظور کیا جائے، ڈیٹا کو ناکام کیا، اسے کبھی بھی اتفاق رائے کی توثیق کی منطق تک نہیں پہنچایا اور زیر بحث بلاک کی توثیق کرنے میں ناکام رہا۔

اس بار بھی کچھ ایسا ہی ہوا۔ کوڈبیس کے پیئر ٹو پیئر سیکشن میں ایک اور حد گواہی کے اعداد و شمار پر غلط طریقے سے پابندی کا نفاذ کر رہی تھی، اسے بلاک سائز کے زیادہ سے زیادہ 1/8 تک محدود کرنا تھا جیسا کہ فل بلاک سائز کے برخلاف تھا۔ Burak crafted a ٹرانزیکشن گواہوں کے اعداد و شمار کے ساتھ سخت حد سے زیادہ صرف ایک وزنی یونٹ اور ایک بار پھر اس بلاک اونچائی پر بی ٹی سی ڈی اور ایل این ڈی نوڈس کو روک دیا۔ یہ ٹرانزیکشن ایک غیر معیاری لین دین تھا، جس کا مطلب یہ ہے کہ اگرچہ یہ اتفاق رائے سے بالکل درست ہے، یہ ڈیفالٹ میمپول پالیسی کے مطابق درست نہیں ہے اور اس لیے نوڈس اسے پورے نیٹ ورک پر نہیں بھیجیں گے۔ یہ بالکل ممکن ہے کہ اسے ایک بلاک میں نکالا جائے، لیکن ایسا کرنے کا واحد طریقہ یہ ہے کہ اسے براہ راست کسی کان کن کو فراہم کیا جائے، جو کہ بورک نے F2Pool کی مدد سے کیا۔

یہ واقعی اس نقطہ کو آگے بڑھاتا ہے کہ کوڈ کے کسی بھی ٹکڑے کا جس کا مقصد بٹ کوائن ڈیٹا کو پارس کرنا اور اس کی توثیق کرنا ہے اس کا بہت زیادہ آڈٹ ہونا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ یہ بٹ کوائن کور کے کام کے مطابق ہے۔ اس سے کوئی فرق نہیں پڑتا کہ آیا وہ کوڈ نوڈ کے نفاذ کے لیے متفقہ انجن ہے یا لائٹننگ نوڈ کے لیے لین دین کو منتقل کرنے والے کوڈ کا صرف ایک ٹکڑا ہے۔ یہ دوسرا بگ تھا۔ لفظی طور پر پچھلے مہینے سے اوپر کوڈ بیس میں اسے لائٹننگ لیبز میں بھی کسی نے دریافت نہیں کیا۔ AJ Towns نے 11 اکتوبر کو اس کی اطلاع دی، اصل بگ کے برک کے 998-of-999 ملٹی سیگ ٹرانزیکشن سے شروع ہونے کے دو دن بعد۔ اسے حذف کرنے سے پہلے 10 گھنٹے تک Github پر عوامی طور پر پوسٹ کیا گیا تھا۔ اس کے بعد ایل این ڈی کی اگلی ریلیز میں اس مسئلے کو خاموشی سے پیچ کرنے کے ارادے سے ایک حل کیا گیا، لیکن جاری نہیں کیا گیا۔

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

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

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

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

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

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

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

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

یہ شنوبی کی ایک مہمان پوسٹ ہے۔ بیان کردہ آراء مکمل طور پر ان کی اپنی ہیں اور ضروری نہیں کہ وہ BTC Inc یا Bitcoin میگزین کی عکاسی کریں۔