Security Challenges Overview

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

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

ان سب تقاضوں میں رسک شامل ہے جیسے key compromise یا loss، جلد بازی یا ناواقف approvals، یا اس والٹ سافٹ ویئر کا کمپرو مائز ہونا جس پر یوزرز بھروسہ کرتے ہیں۔

1.1 کی مینیجمنٹ

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

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

Hardware wallets ایک متبادل ہیں، جو یوزرز کو خاص فزیکل ڈیوائس میں محفوظ کی رکھنے کی سہولت دیتے ہیں۔ لیکن hardware wallets کے بھی اپنے نقصانات اور حملے کے امکانات ہیں۔ یہ کھو سکتے ہیں، خراب یا چوری ہو سکتے ہیں۔ بہت سے hardware wallets اوپن سورس نہیں ہوتے اور ان کی سپلائی چین بھی شفاف نہیں ہوتی، جس سے supply chain attack کا خطرہ بڑھ جاتا ہے۔

چاہے کیز سافٹ ویئر والٹ میں ہوں یا ہارڈویئر والٹ میں، self-custody یوزرز کے لیے تشویش کا باعث رہتا ہے کیونکہ اسے جسمانی چوری یا زبردستی سے بھی کمپرو مائز کیا جا سکتا ہے۔

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

1.2 Blind signing & transaction uncertainty

یوزرز اکثر "اندھا دھند" ٹرانزیکشنز approve کر دیتے ہیں بغیر یہ سمجھے کہ وہ کیا کر رہے ہیں۔ والٹس عام طور پر raw hexadecimal data، truncated contract address یا ایسی معلومات دکھاتے ہیں جو یوزر کو ٹرانزیکشن کے نتائج سمجھنے کے لیے کافی نہیں۔ اس سے یوزرز malicious smart contracts، phishing، scams، spoofed interfaces، front-end compromises اور عام user errors کا شکار ہو جاتے ہیں۔

1.3 Approval and permission management

کئی Ethereum ایپس میں یوزرز کو عام استعمال کے دوران مخصوص permissions دینی پڑتی ہیں۔ مثلاً کوئی یوزر Uniswap جیسے DEX کو اپنے tokens موو کرنے کی اجازت دیتا ہے تاکہ وہ انہیں ETH کے ساتھ سوَاپ کر سکے۔

یہ approvals اماؤنٹ کی حد کے ساتھ ہو سکتی ہیں، لیکن کئی والٹس ڈیفالٹ میں unlimited approvals بغیر کسی expiry کے دے دیتے ہیں۔ زیادہ تر والٹس میں یوزرز کے پاس اپنی outstanding approvals کو دیکھنے یا منیج کرنے کا کوئی طریقہ نہیں۔

یہ malicious apps یا compromised frontends کے لیے خطرہ بن جاتا ہے، کیونکہ زیادہ تر یوزرز default میں unlimited approvals دیتے ہیں جنہیں ان کے فنڈز drain کرنے کے لیے استعمال کیا جا سکتا ہے۔ اگر کسی legitimate smart contract کو approval دی جائے، اور وہ بعد میں compromise ہو جائے، تب بھی approval برقرار رہنے کی وجہ سے فنڈز خطرے میں آ سکتے ہیں۔

یہ اداروں کے لیے بھی خطرہ ہے۔ مثال کے طور پر، کوئی ادارہ operational convenience کے لیے کسی DEX router کو unlimited USDC allowance دے سکتا ہے، لیکن اگر router contract اپ گریڈ ہو یا compromise ہو جائے تو وہ ادارے کے فنڈز خطرے میں ڈال سکتا ہے۔

1.4 Compromised web interfaces

زیادہ تر یوزرز براہِ راست smart contract کے ساتھ انٹریکٹ نہیں کرتے بلکہ web interface کے ذریعے، اپنے موبائل یا ویب براؤزر سے کرتے ہیں۔

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

1.5 رازداری

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

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

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

1.6 ٹکڑے ٹکڑے ہونا

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

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

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

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

تاہم، اس ڈومین میں کمزوریاں اور بہتری کے شعبے باقی ہیں۔

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

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

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

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

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

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

2.3 آن چین کوڈ کا رسک اسیسمنٹ

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

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

3.1 Layer 2 چینز

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

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

ایک تفصیلی فریم ورک اور مانیٹرنگ ڈیش بورڈ کے لیے L2Beatopens 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 پورٹس پر ٹریفک کو بلاک کرنا یا تھروٹل کرنا
• Ethereum سے متعلقہ خدمات کو حل کرنے والی DNS درخواستوں کو فلٹر کرنا
• معروف Ethereum نوڈز کے خلاف جیوفینسنگ یا IP پابندیاں
• Ethereum پروٹوکول سے متعلقہ ٹریفک کی شناخت اور سنسر کرنے کے لیے گہرا پیکٹ معائنہ

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

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

4.1 اتفاق رائے کی کمزوری اور بحالی کے خطرات

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

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

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

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

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

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

4.4 غیر متعینہ سماجی سلیشنگ اور کوآرڈینیشن کے فرق

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

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

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

• گریفنگ حملے یا سلیش گریفنگ۔ ویلیڈیٹرز کو اپنی غلطیوں کی وجہ سے نہیں بلکہ حملہ آور کو خالص قیمت پر دوسروں کو نقصان پہنچانے کے ارادے سے مخالفانہ رویے کی وجہ سے اخراجات یا سلیشنگ جرمانے کا سامنا کرنا پڑ سکتا ہے۔
• اسٹریٹجک ایگزٹ یا وقتی غیرفعالیت۔ ویلیڈیٹرز جان بوجھ کر آف لائن جا سکتے ہیں یا منافع کو زیادہ سے زیادہ کرنے یا کم سے کم جرمانے کے ساتھ اتفاق رائے میں خلل ڈالنے کے لیے اہم وقتوں پر باہر نکل سکتے ہیں۔
• ویلیڈیٹرز یا ریلے کے درمیان ملی بھگت۔ ویلیڈیٹرز کے درمیان یا ریلے اور ویلیڈیٹرز کے درمیان مربوط رویہ وکندریقرت کو کم کر سکتا ہے، یا 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 کی غیر جانبداری اور لچک کو کمزور کرتے ہیں۔