سیکیورٹی چیلنجز کا جائزہ

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

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

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

1.1 کی (Key) مینجمنٹ

بہت سے صارفین کرپٹوگرافک کیز کو محفوظ طریقے سے منظم کرنے کے لیے لیس نہیں ہیں۔

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

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

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

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

1.2 بلائنڈ سائننگ اور ٹرانزیکشن کی غیر یقینی صورتحال

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

1.3 منظوری اور اجازت کا انتظام

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

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

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

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

1.4 سمجھوتہ شدہ ویب انٹرفیسز

زیادہ تر صارفین براہ راست اسمارٹ کانٹریکٹ کے ساتھ تعامل نہیں کرتے، بلکہ اپنے موبائل ڈیوائس یا ویب براؤزر کے ذریعے ویب انٹرفیس کے ذریعے کرتے ہیں۔

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

1.5 پرائیویسی

پرائیویسی ہر قسم کے صارفین کے لیے سیکیورٹی خطرات کو کم یا بڑھا سکتی ہے۔

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

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

1.6 فریگمنٹیشن

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

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

Ethereum کی تاریخ میں اسمارٹ کانٹریکٹ کی سیکیورٹی میں نمایاں بہتری آئی ہے۔ DAO ہیک جیسے ابتدائی سیکیورٹی واقعات نے ایکو سسٹم کو سافٹ ویئر لائف سائیکل میں حفاظتی اقدامات کو پیشہ ورانہ بنانے اور بہتر بنانے کی ترغیب دی جس کی وجہ سے کوڈ آن چین تعینات ہوتا ہے۔ اہم پیشرفتوں میں شامل ہیں:

• سیکیورٹی آڈیٹنگ ایک معیاری عمل بن گیا، جس میں کئی سیکیورٹی فرمز ایکو سسٹم میں داخل ہوئیں اور مہارت تیار کی۔
• ٹولنگ، ٹیسٹنگ، اور جامد تجزیہ (static analysis) کے سسٹمز پختہ ہوئے اور معیاری عمل بن گئے۔
• پہلے سے آڈٹ شدہ عام اجزاء کی لائبریریوں نے ڈیولپرز کو ڈیفالٹ کے لحاظ سے محفوظ بلڈنگ بلاکس دیے۔
• رسمی تصدیق (formal verification) کی تکنیکوں کو اپنایا گیا، خاص طور پر برجز، اسٹیکنگ سسٹمز، اور اعلیٰ مالیت کے کانٹریکٹس کے لیے۔
• ایکو سسٹم کے سیکیورٹی کلچر اور بہترین طریقوں میں بہتری آئی۔
• اہم باؤنٹی پروگرامز کی تخلیق جنہوں نے ایپ لیئر کو مضبوط کیا۔

تاہم، اس ڈومین میں اب بھی کمزوریاں اور بہتری کی گنجائش موجود ہے۔

2.1 کانٹریکٹ کی کمزوریاں

اسمارٹ کانٹریکٹ کی سیکیورٹی میں پیشرفت کے باوجود، اب بھی ایسی کمزوریاں موجود ہیں جو اہم سیکیورٹی مسائل کا باعث بن سکتی ہیں، بشمول:

• کانٹریکٹ اپ گریڈ کا خطرہ. کچھ کانٹریکٹس کو تعیناتی کے بعد قابل ترمیم ہونے کے لیے ڈیزائن کیا گیا ہے، تاکہ ڈیولپمنٹ ٹیم کو ایپلیکیشن کو اپ ڈیٹ اور بہتر بنانے کے قابل بنایا جا سکے۔ تاہم، یہ خطرات متعارف کراتا ہے۔ اپ گریڈ کے نتیجے میں نئی کمزوریاں پیدا ہو سکتی ہیں، یا بدنیتی پر مبنی اپ گریڈ کی صورت میں صارف کے فنڈز کا مکمل نقصان ہو سکتا ہے۔
• ری-اینٹرنسی (Re-entrancy), جہاں کانٹریکٹ A اپنی اندرونی اسٹیٹ کو اپ ڈیٹ کرنے سے پہلے ایک بیرونی کانٹریکٹ B کو کال کرتا ہے، اور کانٹریکٹ B پہلی کال ختم ہونے سے پہلے اصل کانٹریکٹ A کو واپس کال کرتا ہے۔
• بیرونی لائبریریوں کا غیر محفوظ استعمال, جہاں ایک کانٹریکٹ کسی بیرونی لائبریری کو کال کرتا ہے جو غیر آڈٹ شدہ، بدنیتی پر مبنی، یا اپ گریڈ کے قابل ہو سکتی ہے۔
• غیر آڈٹ شدہ اجزاء. اگرچہ آڈیٹنگ اور معیاری لائبریریوں کے استعمال میں بہتری آئی ہے، ڈیولپرز بعض اوقات اپنی ایپلیکیشنز میں غیر آڈٹ شدہ اجزاء پر انحصار کرتے ہیں۔
• ایکسیس کنٹرول کی ناکامیاں, جہاں اجازتوں کو غلط کنفیگر کیا گیا ہو یا بہت وسیع پیمانے پر بیان کیا گیا ہو، جس سے حملہ آوروں کو بدنیتی پر مبنی کارروائیاں کرنے کی اجازت ملتی ہے۔
• غیر مجاز رسائی, جہاں ایک پرائیویٹ کی جو کانٹریکٹ کو کنٹرول کرنے کے قابل ہے، کسی بدنیتی پر مبنی ایکٹر کے ذریعے حاصل کر لی جاتی ہے۔
• برجز اور کراس چین تعاملات. برجز اور کراس چین پروٹوکولز اضافی پیچیدگی متعارف کراتے ہیں، اور حملہ آور کراس چین پیغامات کو پاس کرنے یا ان کی توثیق کرنے کے طریقے میں کمزوریوں کا فائدہ اٹھا سکتے ہیں۔
• Externally Owned Account (EOA) ڈیلیگیشن یا دستخط کا غلط استعمال. بدنیتی پر مبنی ایپلیکیشنز صارفین کو دھوکہ دے کر ان کے اکاؤنٹ کی مکمل ڈیلیگیشن کسی دوسری پارٹی کو دینے پر دستخط کروا سکتی ہیں، جس سے چوری ممکن ہو جاتی ہے۔ بدنیتی پر مبنی ایپلیکیشنز صارف کے دستخط شدہ پیغامات کو غیر متوقع طریقوں سے بھی استعمال کر سکتی ہیں، مثلاً، ری پلے اٹیک (replay attack) میں۔
• AI کوڈ جنریشن یا خودکار ری فیکٹرنگ ٹولز کے ذریعے متعارف کرائے گئے بگز کا ابھرتا ہوا خطرہ.

2.2 ڈیولپر کا تجربہ، ٹولنگ اور پروگرامنگ زبانیں

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

• مقبول فریم ورکس میں محفوظ ڈیفالٹس کی کمی. کچھ ٹولز حفاظت پر لچک یا رفتار کو ترجیح دیتے ہیں، غیر محفوظ ڈیفالٹس سیٹ کرتے ہیں جیسے approve() فنکشن میں لامحدود ٹوکن منظوریاں، یا ڈیفالٹ کے طور پر ایکسیس کنٹرول پیٹرنز کو شامل کرنے میں ناکام رہتے ہیں۔
• اعلیٰ آپریشنل کنٹرولز کے لیے کسٹم کوڈ. پیچیدہ آپریشنل ضروریات والے ادارہ جاتی صارفین کو اکثر شروع سے مطلوبہ خصوصیات بنانی پڑتی ہیں، جس سے کمزوریوں کا خطرہ بڑھ جاتا ہے۔ اعلیٰ سیکیورٹی ورک فلوز کے لیے معیاری محفوظ اجزاء یا فریم ورکس کی کمی ہے۔
• غیر مستقل ٹیسٹنگ کوریج ٹولنگ اسٹیکس میں، نیز فزنگ (fuzzing) یا انویرینٹ چیکنگ (invariant checking) جیسی ثابت شدہ تکنیکوں کے استعمال کے حوالے سے اصولوں کی کمی۔
• رسمی تصدیق کے طریقوں کو کم اپنانا. رسمی تصدیق کی تکنیکیں طاقتور ہیں، لیکن وہ پیچیدہ، مہنگی ہیں، انہیں خصوصی ڈومین کی مہارت کی ضرورت ہوتی ہے، اور وہ معیاری ڈیولپر ورک فلوز میں اچھی طرح سے مربوط نہیں ہیں، جہاں انہیں تصریح (specification) کے مرحلے پر حفاظت کی تصدیق کے لیے سافٹ ویئر کی تیاری میں بہت پہلے استعمال کیا جا سکتا ہے۔
• کانٹریکٹ کی تصدیق سے متعلق مسائل. صارفین اور ڈیولپرز آسانی سے تعینات شدہ کانٹریکٹس کی قابل اعتمادی، ان کی سیکیورٹی کی توثیق کی حد (مثلاً، کوڈ آڈٹ)، یا پوشیدہ خطرات کی موجودگی کا اندازہ نہیں لگا سکتے۔ اگرچہ اس مقصد کے لیے حل موجود ہیں، بہت سے مسائل باقی ہیں۔ ان مسائل کو حل کرنے والی ٹولنگ کو وسیع پیمانے پر نہیں اپنایا گیا ہے، وہ معیارات جو نقطہ نظر کو متحد کریں گے وہ بکھرے ہوئے ہیں، اور کچھ موجودہ سروسز خود سینٹرلائزڈ انحصار ہیں۔
• کمپائلر کے خطرات. کمپائلرز (وہ سافٹ ویئر جو Solidity جیسے انسانی پڑھنے کے قابل کوڈ کو خود EVM کے ذریعے استعمال ہونے والے بائٹ کوڈ میں تبدیل کرتا ہے) میں خامیاں ہو سکتی ہیں جو اسمارٹ کانٹریکٹس کے تعینات ہونے سے پہلے ان میں غلطیاں متعارف کراتی ہیں۔ آج Ethereum ایکو سسٹم زیادہ تر solc کمپائلر پر انحصار کرتا ہے، جس کا مطلب ہے کہ ایک بگ کے وسیع اثرات ہو سکتے ہیں۔
• پروگرامنگ زبان کا تنوع اور گہرائی. اگرچہ Solidity پر ایک گہرا ٹولنگ ایکو سسٹم بنایا گیا ہے، کچھ ڈیولپرز دیگر پروگرامنگ زبانوں میں پائی جانے والی زیادہ جدید حفاظتی خصوصیات چاہتے ہیں، جیسے میموری کی حفاظت۔

2.3 آن چین کوڈ کے خطرے کا اندازہ

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

یہ سسٹمز والیٹ اور ایپلیکیشن لیئر (مثلاً، والیٹس کے لیے RPC اینڈ پوائنٹس) اور خود Ethereum پروٹوکول (مثلاً، بہت سے ویلیڈیٹرز کلاؤڈ انفراسٹرکچر پر ہوسٹ کیے جاتے ہیں) دونوں کے لیے حملے کی سطح ہیں۔ پرائیویٹ کی کا سمجھوتہ، فشنگ، اور دانے دار (granular) ایکسیس کنٹرولز کی کمی بڑے پیمانے پر بندش، چوری، یا غیر مجاز تبدیلیوں کا باعث بن سکتی ہے، یہاں تک کہ اگر بنیادی بلاک چین پروٹوکول محفوظ رہے۔

3.1 Layer 2 چینز

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

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

ایک تفصیلی فریم ورک اور مانیٹرنگ ڈیش بورڈ کے لیے L2Beat (opens in a new tab) دیکھیں جو L2 کی کارکردگی اور سیکیورٹی کا جائزہ لیتا ہے اور اس کا موازنہ کرتا ہے۔

3.2 RPC اور نوڈ انفراسٹرکچر

Ethereum ایپلیکیشنز RPC رسائی، APIs اور نوڈ سروسز کے لیے انفراسٹرکچر فراہم کنندگان کی ایک چھوٹی تعداد پر انحصار کرتی ہیں۔ اس میں کرپٹو کے لیے مخصوص انفراسٹرکچر فراہم کنندگان کے ساتھ ساتھ روایتی کلاؤڈ سروسز شامل ہیں جو عام طور پر نوڈز کو ہوسٹ کرنے کے لیے استعمال ہوتی ہیں (مثلاً، AWS، Cloudflare، Hetzner)۔

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

3.3 DNS سطح کی کمزوریاں

ڈومین نیم سسٹم (DNS) انٹرنیٹ کی ایک بنیادی تہہ ہے، لیکن یہ سینٹرلائزڈ بھی ہے اور اس سے سمجھوتہ کیا جا سکتا ہے۔ بہت سے صارفین ویب ڈومینز کے ذریعے ایپس تک رسائی حاصل کرتے ہیں، جو ان کے لیے حساس ہیں:

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

3.4 سافٹ ویئر سپلائی چین اور لائبریریاں

Ethereum ڈیولپرز اوپن سورس لائبریریوں پر انحصار کرتے ہیں، جو اکثر براہ راست npm، crates.io، یا GitHub جیسی سروسز سے لی جاتی ہیں۔ اگر ان لائبریریوں سے سمجھوتہ کیا جاتا ہے، تو وہ حملوں کے لیے ایک ویکٹر ہو سکتی ہیں جیسے:

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

3.5 فرنٹ اینڈ ڈیلیوری سروسز اور متعلقہ خطرات

بہت سی Ethereum ایپلیکیشنز اپنے فرنٹ اینڈز کو کنٹینٹ ڈیلیوری نیٹ ورک (CDN) یا کلاؤڈ بیسڈ ہوسٹنگ پلیٹ فارم (مثلاً، Vercel، Netlify، Cloudflare) کے ذریعے پیش کرتی ہیں۔ اگر ان سروسز سے سمجھوتہ کیا جاتا ہے، تو وہ بدنیتی پر مبنی جاوا اسکرپٹ انجیکشن جیسے حملوں کے لیے ایک ویکٹر ہو سکتی ہیں، جہاں حملہ آور صارفین کو تبدیل شدہ فرنٹ اینڈ پیش کرتے ہیں۔

3.6 انٹرنیٹ سروس پرووائیڈر کی سطح کی سنسرشپ

انٹرنیٹ سروس پرووائیڈرز (ISPs) یا قومی ریاستیں Ethereum تک رسائی کو سنسر کرنے کے لیے بنیادی انٹرنیٹ انفراسٹرکچر کے کنٹرول کا استعمال کر سکتی ہیں۔ مثال کے طور پر، ان حملوں میں شامل ہو سکتے ہیں:

• عام Ethereum پورٹس پر ٹریفک کو مسدود کرنا یا روکنا
• DNS درخواستوں کو فلٹر کرنا جو Ethereum سے متعلقہ سروسز کو حل کرتی ہیں
• معلوم Ethereum نوڈز کے خلاف جیو فینسنگ یا IP پابندیاں
• Ethereum پروٹوکول سے متعلقہ ٹریفک کی شناخت اور سنسر کرنے کے لیے ڈیپ پیکٹ انسپیکشن

ان میں سے بہت سی بنیادی تکنیکیں آج دنیا بھر میں آمرانہ حکومتوں کے ذریعے معلومات، احتجاجی ٹولز، یا کرپٹو کرنسیوں تک رسائی کو دبانے کے لیے پہلے ہی استعمال کی جا رہی ہیں۔

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

4.1 کنسینسس کی نزاکت اور بحالی کے خطرات

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

4.2 کلائنٹ کا تنوع

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

4.3 اسٹیکنگ سینٹرلائزیشن اور پول کا غلبہ

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

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

4.4 غیر متعین سوشل سلیشنگ اور کوآرڈینیشن کے خلا

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

4.5 اقتصادی اور گیم تھیوریٹک حملے کے ویکٹرز

بہت سے ممکنہ اقتصادی حملے کے ویکٹرز کا مطالعہ کم کیا گیا ہے، بشمول:

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

4.6 کوانٹم کا خطرہ

Ethereum کی بنیادی کرپٹوگرافی (مثلاً، secp256k1 جیسے ایلیپٹک کریو دستخط) کو ایک دن کوانٹم کمپیوٹرز کے ذریعے توڑا جا سکتا ہے۔ اگرچہ یہ کوئی فوری خطرہ نہیں ہے، لیکن ایک قابل اعتبار خطرہ فوری طور پر موجودہ والیٹس، کانٹریکٹس، اور اسٹیکنگ کیز کو کمزور بنا سکتا ہے۔ یہ مستقبل کا چیلنج صارفین کے لیے Ethereum کی طویل مدتی ضمانتوں کو کمزور کرتا ہے۔

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

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

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

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

6.1 اسٹیک سینٹرلائزیشن

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

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

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

6.2 آف چین اثاثہ سینٹرلائزیشن

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

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

6.3 ریگولیٹری حملہ یا دباؤ

حکومتیں اور ریگولیٹرز مختلف اداروں پر دباؤ ڈال سکتے ہیں جو Ethereum اسٹیک کے اہم اجزاء کو کنٹرول کرتے ہیں تاکہ وہ Ethereum پروٹوکول کو سنسر کریں یا بصورت دیگر اس میں مداخلت کریں۔ Ethereum کے ادارہ جاتی صارفین بھی ان دباؤ سے متاثر ہو سکتے ہیں، جس کے ان کے صارفین کے لیے مزید نتائج ہوں گے (مثلاً، ایک بینک جو ریگولیٹری پابندیوں کی وجہ سے اب کچھ کرپٹو پروڈکٹس پیش نہیں کر سکتا)۔

6.4 گورننس پر تنظیمی قبضہ

Ethereum کی اوپن سورس گورننس اور ڈیولپمنٹ کے عمل ٹیموں اور کمپنیوں کے ایک متنوع اور عالمی سیٹ کے ذریعے چلائے جاتے ہیں جو بنیادی کلائنٹ سافٹ ویئر، انفراسٹرکچر، اور ٹولنگ کو برقرار رکھتے ہیں۔

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