کرپٹو اس طرح جاری نہیں رہ سکتا: بلاک چین پریکٹیشنر کی جانب سے صنعت کی خود بچاؤ پہل

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

مصنف: رابرٹ ماؤ، آرک بلاک کے بانی اور سی ای او

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

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

29 اکتوبر 2026 کو بائننس میں ایک بڑا سیکیورٹی واقعہ پیش آیا۔ اس کے ابتدائی اعلان میں اندازہ لگایا گیا کہ تقریباً 6.3 بلین ڈالر کے اثاثے متاثر ہوئے، اور متاثرہ اثاثوں میں سے تقریباً 3 بلین ڈالر منجمد کر دیے گئے تھے؛ تحقیقات نے ابتدائی طور پر ایک ڈیو اوپس انجینئر کے لیپ ٹاپ کی طرف اشارہ کیا، اور بعد میں ممکنہ دراندازی کے دیگر مقامات بھی دریافت ہوئے۔ بائننس نے یہ بھی کہا کہ والٹ کی نجی کلید کے لیک ہونے کا کوئی ثبوت نہیں ملا۔ متاثرہ رقم حتمی خالص نقصان نہیں ہے، اور مکمل حملے کا سلسلہ ابھی زیرِ تحقیق ہے۔ [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

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

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

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

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

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

2008 میں، ساتوشی ناکاموتو نے ایک ہم مرتبہ سے ہم مرتبہ الیکٹرانک کیش سسٹم تجویز کیا، جس میں ادائیگیوں کو قابل اعتماد intermediaries پر کم انحصار بنانے کی کوشش کی گئی۔ [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) تاہم، اس کے بعد کے بڑے واقعات نے بار بار یہ مسئلہ بے نقاب کیا کہ فنڈز، اجازت اور سافٹ ویئر انحصار دوبارہ مرکوز ہو رہے ہیں۔

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

2008 · بٹ کوائن وائٹ پیپر

نقطۂ آغاز

بٹ کوائن وائٹ پیپر نے مالیاتی اداروں کو intermediaries کے طور پر استعمال کیے بغیر ہم مرتبہ سے ہم مرتبہ ادائیگیاں تجویز کیں۔

ماخذ

2011–2014 · Mt. Gox طویل مدتی چوری

CEX

Mt. Gox کو طویل مدتی چوری کا سامنا کرنا پڑا اور بالآخر اس نے کام بند کر دیا۔ بعد میں امریکی محکمہ انصاف کی فردِ جرم میں الزام لگایا گیا کہ 2011 اور 2014 کے درمیان تقریباً 647,000 BTC چوری ہوئے۔ یہ 2014 میں ایک دن کا حملہ نہیں تھا۔

ماخذ

2012 · Bitcoinica اور Bitfloor

CEX / custodial infrastructure

Bitcoinica کے Linode ہوسٹنگ ماحول کو نقصان پہنچا؛ اسی سال، Bitfloor کے غیر خفیہ کردہ والٹ بیک اپ حملے کا نقطۂ داخل بن گیا۔ پلیٹ فارم کے پیچھے موجود سرورز اور بیک اپ بھی اثاثہ سیکیورٹی کی حد کا حصہ ہیں۔

ماخذ

2015 · Bitstamp ہاٹ والٹ

CEX

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

ماخذ

2016 · Bitfinex

CEX

Bitfinex سے تقریباً 120,000 BTC چوری ہوئے۔ ملٹی سگنیچر انتظامات کو پھر بھی اختتام سے اختتام تک آزاد اجازت اور تصدیق کی ضرورت ہے۔

ماخذ 1 · ماخذ 2

2016 · The DAO

آن چین پروٹوکول

The DAO کنٹریکٹ کو reentrancy حملے کا سامنا کرنا پڑا، اور تقریباً 3.6 ملین ETH ایک ذیلی DAO میں منتقل کیے گئے، جس نے بعد میں ایتھیریم فورک کو متحرک کیا۔ ایک جائز عمل درآمد کا راستہ تباہ کن کاروباری نتائج پیدا کر سکتا ہے۔

ماخذ 1 · ماخذ 2

2017 · Parity مشترکہ والٹ لائبریری

کنٹریکٹ والٹ

Parity مشترکہ والٹ لائبریری تباہ ہو گئی، اور تقریباً 513,000 ETH منجمد ہو گئے۔ اگرچہ منتقل نہ کیے گئے ہوں، مشترکہ کوڈ انحصار کی وجہ سے فنڈز ناقابل استعمال ہو سکتے ہیں۔

ماخذ

2018 · Coincheck

CEXCoincheck کا NEM ہاٹ والٹ چوری ہو گیا۔ آف لائن ذخائر، ہاٹ والٹ اجازتوں اور کاروباری ضروریات کے درمیان حد ایک بار پھر مسئلہ بن گئی۔

ماخذ

2019 · Binance

CEX

Binance نے اعلان کیا کہ ایک ہی لین دین میں 7,000 BTC نکالے گئے۔ بڑے پیمانے پر اثاثوں کے اخراج کو دستخط سے پہلے محدود کرنے کی ضرورت ہے۔

ماخذ

2020 · KuCoin

CEX

KuCoin ہاٹ والٹ واقعہ، جس کے بعد کثیر فریقی تعاون کے ذریعے بڑی مقدار میں اثاثے بازیاب کیے گئے۔ مجموعی چوری شدہ رقم اور حتمی نقصان ایک ہی عدد نہیں ہیں۔

ماخذ

2021 · Poly Network

کراس چین پروٹوکول

تقریباً 612 ملین ڈالر کے اثاثے Poly Network سے منتقل کیے گئے اور بعد میں مرحلہ وار واپس کیے گئے۔ کراس چین اجازت اور اثاثہ کنٹرول صرف معمول کے کاروباری راستوں سے قائم نہیں رہ سکتے۔

ماخذ

2022 · Ronin bridge

برج

Ronin ویلیڈیٹر اجازتیں متاثر ہوئیں، اور 173,600 ETH اور 25.5 ملین USDC منتقل کیے گئے۔ متعدد ویلیڈیٹرز کی کلیدیں بھی ایک ہی حملے کے سلسلے میں پڑ سکتی ہیں۔

ماخذ

2022 · Slope wallet

والٹ

Solana ایکو سسٹم میں Slope wallet کا واقعہ۔ Solana نے سرکاری طور پر کہا کہ نجی کلید کی معلومات نادانستہ طور پر ایک ایپلیکیشن مانیٹرنگ سروس کو منتقل ہوئیں؛ یہ Solana کے اتفاق رائے کی خلاف ورزی نہیں تھی۔

ماخذ

2023 · Euler

قرض دینے والا پروٹوکول

پروٹوکول کی کمزوری کی وجہ سے تقریباً 197 ملین ڈالر کے اثاثے Euler سے منتقل کیے گئے اور بعد میں بازیاب کیے گئے۔ ایک ہی لین دین میں پیچیدہ امتزاج کاروباری منطق کی خامیوں کو بڑھا سکتے ہیں۔

ماخذ

2023 · Ledger Connect Kit

والٹ کنکشن ٹول

Ledger Connect Kit کو سپلائی چین حملے کا سامنا کرنا پڑا، اور نقصان دہ کوڈ ایپلیکیشن فرنٹ اینڈ میں داخل ہو گیا۔ ہارڈ ویئر ڈیوائس کی سیکیورٹی لین دین کے مواد کی تصدیق کا متبادل نہیں بن سکتی۔

ماخذ

2024 · DMM Bitcoin

CEX

DMM Bitcoin سے تقریباً 308 ملین ڈالر چوری ہوئے۔ FBI اور دیگر ایجنسیوں نے بعد میں متعلقہ اہلکاروں اور دستخطی سلسلے کو نشانہ بنانے والے سوشل انجینئرنگ حملوں کا انکشاف کیا۔

ماخذ

2024 · Radiant Capital

قرض دینے والا پروٹوکول / دستخط

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

ماخذ

2025 · Bybit / Safe

CEX / والٹ فرنٹ اینڈ

تقریباً 1.5 بلین ڈالر کا Bybit واقعہ Safe ڈویلپر ماحول اور فرنٹ اینڈ سے متعلق تھا، اور دستخط کنندگان نے ایسے لین دین کی منظوری دی جس نے والٹ کنٹرول منطق کو تبدیل کر دیا۔

ماخذ 1 · ماخذ 2

2025 · Cetus DEX

DEXSui پر Cetus کا تقریباً 223 ملین ڈالر کا واقعہ، محققین نے ایک ریاضی لائبریری میں خامی کی نشاندہی کی۔ غیر-EVM ماحول کو بھی اسی طرح اپنے کوڈ اور اثاثوں کی نمائش کے دائرہ کار کی جانچ کرنی چاہیے۔

ماخذ

2026-07 · COLDCARD بے ترتیب نمبر کی خامی

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

ماخذ

2026-10 · لیجر ہارڈ ویئر امپلانٹ

ہارڈ ویئر والٹ / ڈسٹری بیوشن اٹیک

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

ماخذ

2026 · بائننس ملٹی چین واقعہ

CEX / ملٹی چین

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

ماخذ 1 · ماخذ 2 · ماخذ 3

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

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

ایتھیریم کی شراکت اہم ہے۔ اس نے مزید لوگوں کو آن چین ایپلیکیشنز لکھنے کے قابل بنایا اور ٹولز اور ڈیولپمنٹ تجربے کا ایک بھرپور مجموعہ فروغ دیا۔ لیکن آج، بہت سی نئی چینز اور L2s (لیئر-2 اسکیلنگ نیٹ ورکس) EVM مطابقت کو اپنا بنیادی ہدف سمجھتی ہیں۔ EVM، وہ ورچوئل مشین جو ایتھیریم سمارٹ کنٹریکٹس کو ایگزیکیوٹ کرتی ہے، ایک وسیع پیمانے پر نقل کی جانے والی تکنیکی بنیاد بن رہی ہے۔ مطابقت ایپلیکیشن مائیگریشن کو آسان بناتی ہے؛ Unichain جیسے پروجیکٹس کی دستاویزات واضح طور پر ایتھیریم ٹولنگ کے دوبارہ استعمال کو مساوی ایگزیکیوشن ماحول کی قدر کے طور پر حوالہ دیتی ہیں۔ [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)

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

EIP-7702 اس مسئلے کو بالکل واضح کر دیتا ہے۔ ایک عام ٹرانسفر یہ ہوتا ہے کہ "اس بار کتنی رقم کس کو"؛ ایک ڈیلیگیشن اجازت یہ ہو سکتی ہے کہ "اب سے، یہ کوڈ کا ٹکڑا میرے اکاؤنٹ کی جانب سے آپریشنز انجام دے"۔ اس کے اہداف صارف کے تجربے کو بہتر بنانا اور اجازتوں کو باریک بنانا ہیں، لیکن ڈیلیگیشن قائم کرنا بذاتِ خود وسیع ایگزیکیوشن صلاحیت فراہم کرتا ہے، اور باریک بین اجازتیں پھر بھی ڈیلیگیٹ شدہ کوڈ کو درست طور پر نافذ کرنا ہوں گی۔ [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Minfeng Qi وغیرہ کا پری پرنٹ "EIP-7702 Phishing Attack" ایسی اجازتوں پر دستخط کرنے پر آمادہ کرنے کے بعد اکاؤنٹ کو مستقل طور پر کنٹرول کرنے کے راستے کا مطالعہ کرتا ہے۔ [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) سہولت بڑھنے کے ساتھ ساتھ سیکیورٹی کی ذمہ داری بھی بڑھتی ہے؛ سابقہ کو محض صارفین کے حوالے نہیں کیا جا سکتا۔

یہ Binance واقعہ متعدد چینز پر محیط ہے، اور تفتیش ابھی مکمل نہیں ہوئی، لہٰذا پورے اثرات کو براہِ راست EIP-7702 یا EVM سے منسوب نہیں کیا جا سکتا۔ ری اینٹرنسی، سائننگ سروسز کی کمپرومائز، اور فرنٹ اینڈ ٹیمپرنگ بھی ایک ہی کمزوری نہیں ہیں۔ لیکن ایسی تفریقوں کو آرکیٹیکچر پر سوال اٹھانے سے رکنے کا بہانہ نہیں بننا چاہیے: بالائی تہوں کی غلطیوں کی جانب سے بنیادی تہہ کیوں زیادہ ایسی پابندیاں برقرار نہیں رکھتی جنہیں آسانی سے بائی پاس نہ کیا جا سکے؟

MEV بھی مجھے مطمئن نہیں کرتا۔ اس سے مراد وہ گنجائش ہے جس میں شرکاء ٹرانزیکشنز کی شمولیت، اخراج، اور ترتیب کے ذریعے اضافی قدر حاصل کرتے ہیں۔ میرے نزدیک، ترتیب کی طاقت استعمال کر کے صارف کی ٹرانزیکشنز کو سینڈوچ کرنا اور ان کے ایگزیکیوشن نتائج کو خراب کرنا ایک بگ کے طور پر دیکھا جانا چاہیے جسے ٹھیک کرنے کی ضرورت ہے، نہ کہ اسے ایک ایسی خصوصیت کے طور پر پیش کیا جائے جسے محض اس لیے محفوظ رکھنے کے قابل سمجھا جائے کہ کوئی اس سے منافع کما سکتا ہے۔ ایتھیریم کی اپنی دستاویزات بھی صارفین پر ٹرانزیکشن سینڈوچنگ کے نقصان اور نیٹ ورک کے استحکام کے لیے MEV کے خطرے کو واضح طور پر تسلیم کرتی ہیں۔ [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV صرف ایتھیریم تک محدود نہیں اور اس میں آربیٹریج اور لیکویڈیشن جیسی مختلف سرگرمیاں بھی شامل ہیں؛ صنعت میں پہلے سے تخفیفی تحقیق موجود ہے۔ میری تنقید یہ ہے کہ نیٹ ورک کو برقرار رکھنے کی ترغیب صارفین کی ٹرانزیکشن شرائط کو قربان کرنے کی وجہ نہیں بن سکتی۔ ایک بہتر ٹرانزیکشن نظام کو کم از کم ڈیلیوری نتیجہ اور قابلِ اجازت فیسوں کو اجازت میں لکھنا چاہیے، اور آرڈر دینے والوں کے لیے غیر پُر شدہ معلومات استعمال کر کے صارفین کو نقصان پہنچانے کی گنجائش کو محدود کرنا چاہیے۔میں نے ہمیشہ محسوس کیا ہے کہ ایتھیریم کا کرپٹو پر اثر کچھ حد تک PHP کے انٹرنیٹ پر اثر کی طرح ہے: اس نے بہت سے لوگوں کو چیزیں بنانے کے قابل بنایا، اور اس نے انجینئرنگ قرض بھی چھوڑا جس کی ادائیگی میں طویل وقت لگے گا۔ PHP کو اب بھی اکتوبر 2026 میں ریموٹ کوڈ ایگزیکیوشن کی ایک سنگین کمزوری ٹھیک کرنی پڑی۔ پختگی اور مقبولیت مسلسل مضبوطی کی جگہ نہیں لے سکتیں۔ [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) انٹرنیٹ میں جو قابلِ قدر ہے وہ یہ ہے کہ زبانیں، فریم ورکس اور کلاؤڈ سروسز الگ الگ ترقی کر سکتے ہیں۔ ہمیں مختلف اثاثہ ماڈلز اور ایگزیکیوشن طریقوں کو بھی مسلسل ترقی کرنے دینا چاہیے، بجائے اس کے کہ "ایک ہی ورچوئل مشین کے ساتھ مطابقت" کو ماحولیاتی نظام میں شرکت کا ٹکٹ سمجھا جائے۔

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

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

1. بنیادی خطرے کے کنٹرول کو اثاثوں کو ضائع کرنے کے اختیار کو محدود کرنے دیں

بڑے والٹس کو وصول کنندہ وائٹ لسٹس، مجموعی اخراجات کی حد، اور نئے وصول کنندگان کے لیے انتظار کی مدت مقرر کرنے کے قابل ہونا چاہیے۔ اہم بات یہ ہے کہ یہ قواعد اسی روزمرہ ٹرانزیکشن کلید کے ذریعے فوری طور پر منسوخ نہیں کیے جا سکتے۔ قواعد میں تبدیلی کے لیے آزاد اجازت درکار ہے اور نگرانی اور منسوخی کے لیے وقت چھوڑنا ضروری ہے۔موجودہ اسمارٹ اکاؤنٹس کے پاس پہلے سے ہی نفاذ کی بنیاد موجود ہے، مثال کے طور پر Safe Guards ملٹی سگ کے علاوہ ٹرانزیکشن پر پابندیاں شامل کر سکتے ہیں۔ [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) ہمیں اسے ایک آسانی سے اپنانے والی بنیادی صلاحیت بنانا ہے جو اثاثہ کنٹرول کے تمام راستوں کا احاطہ کرے۔ اگر صرف براہ راست منتقلیوں کو محدود کیا جائے جبکہ لامحدود منظوریوں، ماڈیولز، یا اپ گریڈز کے ذریعے بائی پاس کی اجازت ہو، تو تحفظ ناکام ہو جائے گا۔ وائٹ لسٹ کنٹریکٹ کو اپ گریڈ کیا جا سکتا ہے یا نہیں اور وصول کنندہ کی اجازتوں میں تبدیلی آئی ہے یا نہیں، یہ بھی تصدیق کے دائرے میں آنا چاہیے۔ ایپل کا ایکٹیویشن لاک روزمرہ زندگی سے تحریک فراہم کرتا ہے: یہ چوری شدہ آلات کی دوبارہ ایکٹیویشن کو محدود کرتا ہے اور بعض چوری شدہ پرزوں کی کیلیبریشن کو محدود کرتا ہے، جس کا مقصد چوری کے بعد استعمال ہو سکنے والی قدر کو کم کرنا ہے۔ [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) والٹس کو بھی اسی سمت میں ڈیزائن کرنے کے قابل ہے۔ اگر حملہ آور کوئی کلید حاصل کر لے، تو کیش آؤٹ ہو سکنے والے اثاثوں کی حد محدود رہتی ہے، اور حملے سے متوقع منافع کم ہو سکتا ہے؛ خدمات میں خلل جیسے خطرات کو پھر بھی الگ سے نمٹانا ہوگا۔

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

II. والٹس کو سیکیورٹی کی ذمہ داری اٹھانے دیں، بجائے محض منیمونک الفاظ حوالے کرنے کے

آج کے والٹ سسٹمز سے میری شدید عدم اطمینان ہے: اگر کوئی پروڈکٹ ایک عام شخص سے الفاظ کا ایک مجموعہ نقل کرنے کو کہے، تقاضا کرے کہ وہ اسے کبھی لیک نہ کرے، نہ کھوئے، اور نہ ہی دھوکے سے حاصل ہونے دے، اور پھر بعد کی تمام ناکامیوں کی ذمہ داری صارف پر ڈال دے، تو میں اسے غیر ذمہ دارانہ ڈیزائن سمجھتا ہوں۔ سیلف کسٹڈی لوگوں کو کنٹرول دینی چاہیے، اور انہیں قابل استعمال تحفظ اور ریکوری کی صلاحیتیں بھی دینی چاہیے۔ اس کا مطلب یہ نہیں ہونا چاہیے کہ ہر صارف کو پہلے سیکیورٹی ماہر بننا پڑے۔ یہ بھی ایک حد ہے جسے Crypto کو زیادہ عام صارفین تک پہنچنے کے لیے عبور کرنا ہے۔حالیہ واقعات نے اس مسئلے کو براہِ راست میز پر رکھ دیا ہے۔ اکتوبر 2026 میں، Ledger نے تصدیق کی کہ حملہ آوروں نے اصل ڈیوائسز میں تبدیلی کی اور پھر انہیں جنوب مشرقی ایشیا کے تقسیمی چینلز کے ذریعے مارکیٹ میں واپس بھیجا، جہاں نصب شدہ اجزاء initialization کے دوران recovery words چرا رہے تھے۔ Ledger نے اسے فیکٹری سے نکلنے کے بعد ڈیوائس پر مقامی تقسیمی حملہ قرار دیا، نہ کہ اس کے چپ، آپریٹنگ سسٹم یا سرورز پر حملہ۔ [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARD کے جولائی کے واقعے میں فرم ویئر نے seed generation کو کمزور کیا: حملہ آور کو متعلقہ private keys دوبارہ بنانے کے لیے ڈیوائس کو ریموٹ کنٹرول کرنے کی ضرورت نہیں تھی۔ فرم ویئر اپ ڈیٹ کرنے سے آئندہ کے لیے generation کا عمل ٹھیک ہو جاتا ہے، لیکن پہلے سے بنائے گئے کمزور seeds کو اب بھی migrate کرنے کی ضرورت ہے۔ [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)

یہ دو واقعات ایک ہی قسم کی کمزوری نہیں ہیں، پھر بھی مل کر یہ دکھاتے ہیں: چاہے صارفین احتیاط سے words کاپی کر لیں اور ڈیوائس کو آف لائن رکھیں، وہ مینوفیکچرر کی جانب سے randomness اور supply chain کی integrity کی تصدیق نہیں کر سکتے۔ ڈیوائس پر backup words دکھانے کا مقصد آف لائن recovery ہے، لیکن اس سے یہ بھی ہوتا ہے کہ مکمل recovery secret ایک ایسے display اور backup راستے سے گزرتا ہے جسے تحفظ کی ضرورت ہے۔ Chip security پوری ڈیوائس اور delivery process کی تصدیق کا متبادل نہیں بن سکتی۔

بہتری کا ہدف مکمل wallet lifecycle ہونا چاہیے: keys کیسے generate ہوتی ہیں، transactions کیسے بیان ہوتی ہیں، permissions کیسے الگ کی جاتی ہیں، اور ڈیوائس گم ہونے کے بعد recovery کیسے کام کرتی ہے۔ Account abstraction، یعنی اکاؤنٹس کو قابلِ پروگرام قواعد کے ذریعے authorization کی تصدیق کی اجازت دینا، اور threshold backups جیسے SLIP-39، دونوں کے پاس پہلے سے standards اور implementation foundations موجود ہیں، اس لیے یہ نہیں کہا جا سکتا کہ صنعت میں کوئی ان پر کام نہیں کر رہا۔ [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) لیکن ہمیں ان صلاحیتوں کو آزمودہ، آسان استعمال protections بنانا ہوگا، بجائے اس کے کہ صارفین خود پیچیدہ schemes assemble کریں۔

Mnemonic words کی سادہ obfuscation کافی نہیں ہے۔ زیادہ قابلِ بھروسا سمتوں میں reviewed encrypted backups، threshold recovery، اور independent device authorization شامل ہیں، اور یہ کہ صارفین بڑی مقدار میں assets جمع کرنے سے پہلے recovery drills مکمل کریں۔ Backup shards اور multisig مختلف layers ہیں: former recovery کے دوران دوبارہ ایک ہی secret میں combine ہو سکتے ہیں، جبکہ latter کے لیے transaction کی منظوری کے لیے متعدد independent signers درکار ہوتے ہیں۔ Recovery services کو خاموشی سے ایک نیا master key نہیں بننا چاہیے، اور نہ ہی ایک اضافی password ایک اور trap بننا چاہیے جہاں اسے کھو دینا ناقابلِ recovery نقصان کا باعث ہو۔ذاتی والٹس اور ایکسچینج والٹ سسٹمز ٹرانزیکشن تفصیلات، دستخطی درخواستوں، اثاثہ جات کی پابندیوں اور ریکوری کے عمل کے لیے سیکیورٹی تفصیلات شیئر کر سکتے ہیں، جبکہ مختلف حدود اور منظوری کی پالیسیاں اپنا سکتے ہیں۔ بٹ کوائن کا PSBT پہلے ہی ٹولز کے درمیان غیر دستخط شدہ ٹرانزیکشنز منتقل کرنے کے لیے ایک فارمیٹ فراہم کرتا ہے، اور یہ مشترکہ انٹرفیس مزید ترقی کے قابل ہے۔ [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) جو مشترک ہے وہ قابلِ جانچ سیکیورٹی تقاضے ہیں؛ ہر چین کو اب بھی اپنے موافقت کے قواعد واضح کرنے کی ضرورت ہے۔ والٹس کو واضح طور پر پیش کرنا چاہیے کہ یہ دستخط کیا منتقل کریں گے اور اس کے بعد کس کو کتنا اختیار دیا جائے گا، اور آزاد پالیسیوں کو حد سے باہر کارروائیوں کو مسترد کرنا چاہیے؛ ایک خوبصورت تصدیقی صفحہ کافی نہیں ہے۔

III. کم سے کم ضروری افشا کے ساتھ قابلِ تصدیق صلاحیت حاصل کرنا

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

W3C کا قابلِ تصدیق اسناد کا نظام پہلے ہی انتخابی افشا کے لیے تکنیکی راستہ رکھتا ہے؛ تاہم، یہ ثابت کرنا کہ ان پٹس مستند ہیں، کہ اسناد درست رہتی ہیں، اور حیثیت کیسے منسوخ کی جاتی ہے، اب بھی واضح کرنے کی ضرورت ہے۔ [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) صفر علم کے ثبوت (ZK) اپنانا خود بخود ٹرانزیکشن کی رقوم اور تعلقات کو نہیں چھپاتا؛ اسکیلنگ کے ثبوت اور رازداری کا تحفظ مختلف اہداف ہیں۔

مثال کے طور پر، جب کسی کاروبار کو صرف شرکت کی اہلیت کی تصدیق کی ضرورت ہو، تو صارف کسی قابلِ اعتماد ادارے کی جانب سے جاری کردہ درست اہلیت کا نتیجہ پیش کر سکتا ہے بغیر مکمل مالیاتی مواد افشا کیے۔ جب یہ ثابت کرنا ضروری ہو کہ کوئی پوشیدہ قدر کسی شرط کو پوری کرتی ہے، تو اس وقت مناسب ثبوت کا طریقہ کار استعمال کیا جا سکتا ہے۔ اسناد کے قابلِ اعتماد ماخذ اور اس کی منسوخی کی حیثیت کی اب بھی تصدیق کرنے کی ضرورت ہے۔

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

IV. ٹرانزیکشن خدمات کو زیادہ سے زیادہ مرکزی تحویل سے پاک بناناٹریڈ میچنگ، پاتھ فائنڈنگ، اور اثاثہ تصفیہ کو الگ الگ ڈیزائن کیا جانا چاہیے۔ ٹریڈنگ انٹری پوائنٹ فراہم کرنے والی سروس کو صرف وہی اجازتیں حاصل کرنی چاہئیں جو موجودہ تصفیہ مکمل کرنے کے لیے ضروری ہوں، تاکہ باقی وقت میں صارف کے اثاثے ان کے اپنے کنٹرول میں رہیں۔ موجودہ نیت پر مبنی ٹرانزیکشن پروٹوکولز نے پہلے ہی اس راستے کا کچھ حصہ تلاش کر لیا ہے، اور صنعت اسے مکمل کرنا جاری رکھ سکتی ہے۔ [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

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

IBIT iShares کی بٹ کوائن ایکسچینج ٹریڈڈ پروڈکٹ ہے، اور مارکیٹ میں جو چیز ٹریڈ ہوتی ہے وہ اس کے شیئرز ہیں۔ اس کا انتظام جزوی تنہائی کی ایک مثال پیش کرتا ہے: شیئرز اور بنیادی بٹ کوائن الگ الگ ریکارڈ کیے جاتے ہیں، اور Vault Balance (تحویل بیلنس) کے متعلقہ پرائیویٹ کیز کولڈ اسٹوریج میں رکھی جاتی ہیں۔ شیئر ٹریڈنگ ریکارڈ میں تبدیلی کے لیے ضروری نہیں کہ بنیادی بٹ کوائن ہر ٹرانزیکشن کے ساتھ منتقل ہو۔ [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) اس سے جو سیکھا جا سکتا ہے وہ ٹریڈنگ حقوق اور ریزرو ڈسپوزل حقوق کی علیحدگی ہے۔ اس کے Trading Balance (ٹریڈنگ سروس بیلنس) کا انتظام مختلف ہے، اور تحویل خود بھی خطرات رکھتی ہے؛ کولڈ اسٹوریج کو آزاد ہدایات اور دستخط کی تصدیق کے ساتھ جوڑا جانا چاہیے۔

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

V. ناکامیوں کو الگ تھلگ کرنے اور تبدیلی کی صلاحیت کو برقرار رکھنے کے لیے پرتوں والا آرکیٹیکچر استعمال کریںہمیں شناخت اور اجازت کے انٹرفیسز، اثاثہ جات کی پالیسیوں، اور تصفیے کی تصدیق کے ایسے طریقے درکار ہیں جو آزادانہ طور پر ترقی کر سکیں۔ مختلف چینز اپنے اپنے ایگزیکیوشن ماڈلز برقرار رکھ سکتی ہیں اور واضح انٹرفیسز کے ذریعے جڑ سکتی ہیں۔ انٹرفیسز کو سیکیورٹی گارنٹیز اور ان کی شرائط بیان کرنی چاہئیں، نہ کہ محض یہ کہنا کہ "کال کامیاب رہی۔" انٹرنیٹ کا تجربہ اس نقطہ نظر کی تائید کرتا ہے۔ RFC 9518، "Centralization, Decentralization, and Internet Standards" میں، مارک ناٹنگھم خاص طور پر ان صورتوں پر بحث کرتے ہیں جن میں مرکزیت مفید ثابت ہو سکتی ہے، اور اس طاقت اور خطرات کا بھی تجزیہ کرتے ہیں جو یہ ساتھ لاتی ہے۔ [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) یہ بالکل وہی رویہ ہے جس سے سیکھنا قابلِ قدر ہے: آرکیٹیکچر کو یہ جواب دینے دیں کہ کون سی ذمہ داریاں مرکزی کی جا سکتی ہیں، کس حد تک، اور اس طاقت کو پھیلنے سے کیسے روکا جائے۔ کسی سروس کو اجازت دی جا سکتی ہے کہ وہ غیر معمولی حالات کی مرکزی طور پر شناخت کرے جبکہ اثاثہ جات کو چھونے کی اس کی اجازت محدود ہو؛ صارفین کو اپنی اثاثہ پالیسیوں اور تصدیقی ریکارڈز کھوئے بغیر سروسز تبدیل کرنے کے قابل ہونا چاہیے۔

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

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

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

6. صارفین کو اپنے اثاثہ جات کی ہلکی تصدیق کرنے دیں

عام لوگوں کو اپنے بیلنس اور رسیدیں تصدیق کرنے کے لیے پوری چین کی تمام تاریخ محفوظ کرنے اور چلانے کی ضرورت نہیں ہونی چاہیے؛ اور نہ ہی انہیں والٹ کے پیچھے صرف ایک سرور پر بھروسہ کرنا چاہیے۔ ساتوشی ناکاموتو نے پہلے ہی وائٹ پیپر کے سیکشن 8 میں SPV، سادہ شدہ ادائیگی تصدیق، تجویز کی تھی۔ بٹ کوائن کا BIP-157 کلائنٹس کو فلٹرز ڈاؤن لوڈ کرنے اور اپنے سے متعلق بلاکس تلاش کرنے دینے کی کوشش جاری رکھے ہوئے ہے؛ ایتھیریم میں بھی لائٹ کلائنٹ ڈیزائن موجود ہیں۔ [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) تو مسئلہ یہ نہیں کہ کسی نے کبھی اس کے بارے میں سوچا ہی نہیں، بلکہ یہ ہے کہ ہمیں اب بھی واضح سیکیورٹی شرائط کے ساتھ تصدیقی صلاحیت کو ان والٹس میں تعمیر کرنے کی ضرورت ہے جو صارفین روزانہ استعمال کرتے ہیں۔ایک ایسی چین کو مثال کے طور پر لیں جو اکاؤنٹ اسٹیٹ پروفز کی حمایت کرتی ہے: بیلنس کے استفسار کے وقت، سرور کو بیلنس اور ایک پروف دونوں واپس کرنے چاہئیں۔ والٹ پہلے اس چین کے قواعد کے مطابق ایک مختصر بلاک ڈائجسٹ، یعنی بلاک ہیڈر، کی تصدیق کرتا ہے، اور پھر جانچتا ہے کہ آیا یہ بیلنس اس ڈیٹا سے مطابقت رکھتا ہے جس کا ڈائجسٹ نے عہد کیا ہے۔ سرور جواب فراہم کرتا ہے، اور والٹ جواب کی تصدیق کر سکتا ہے۔ بٹ کوائن کا SPV اس ثبوت کی تصدیق کرتا ہے کہ متعلقہ ٹرانزیکشنز شامل کی گئی تھیں؛ اسے براہ راست بیلنس پروف کے طور پر نقل نہیں کیا جا سکتا۔ والٹ کو واضح طور پر یہ بھی دکھانا چاہیے کہ وہ کہاں تک ہم آہنگ ہوا ہے اور کون سی معلومات کی تصدیق ہو چکی ہے؛ جب پروفز غائب ہوں، ڈیٹا پرانا ہو، یا ذرائع متصادم ہوں، تو اسے انتباہ کرنا چاہیے یا اس معلومات پر منحصر اعلیٰ خطرے والے آپریشنز روک دینے چاہئیں، اور خاموشی سے اندھے اعتماد پر واپس نہیں جانا چاہیے۔

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

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

7. بے ضابطگی کی شناخت اور سیکیورٹی تصدیق کو عوامی بنیادی ڈھانچے کے طور پر تعمیر کریں

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

ساتھ ہی، ہمیں حملہ کیسز، اجازت کے ٹیسٹ، اور تصدیقی ٹولز کو مشترکہ طور پر برقرار رکھنے کی ضرورت ہے جو بار بار چلائے جا سکیں۔ صرف تفصیلات کا اشتراک اور آزاد implementations اور آزاد تصدیق کو محفوظ رکھنے سے ہی کامن موڈ کی ناکامیاں کم کی جا سکتی ہیں۔ فاؤنڈیشنز اور ایکسچینجز پہلے ہی سیکیورٹی سرمایہ کاری رکھتے ہیں، جیسے ایتھیریم فاؤنڈیشن کا Trillion Dollar Security Initiative۔ [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) اگلا سوال یہ پوچھنا ہے کہ آیا اس سرمایہ کاری کو عوامی بنیادی ڈھانچے میں تبدیل کیا جا سکتا ہے جسے دیگر ٹیمیں بھی اپنا اور معائنہ کر سکیں۔ان سات کاموں میں سے کوئی بھی مطلق سلامتی کی ضمانت نہیں دے سکتا۔ انہیں جو فراہم کرنا ہے وہ قابلِ معائنہ حدود ہیں: اجازت کے کس نقصان کی صورت میں، زیادہ سے زیادہ کتنے اثاثے بے نقاب ہوتے ہیں، بے ضابطگیوں کو کتنی تیزی سے دریافت کیا جا سکتا ہے، اور بحالی اب بھی کس پر منحصر ہے۔

اس مقام پر، کچھ لوگ کہہ سکتے ہیں: سمت درست لگتی ہے، لیکن صنعت پہلے ہی کئی سالوں سے چل رہی ہے؛ تعمیرِ نو میں کتنے لوگ اور کتنا وقت درکار ہوگا؟ کیا یہ اب بھی آئیڈیلزم نہیں ہے؟

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

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

Anthropic اور PNNL کی تحقیق ایک ٹھوس مثال دیتی ہے: ایک محدود اہم بنیادی ڈھانچے کے نقلی ماحول میں، محققین نے رپورٹ کیا کہ حملے کی تعمیرِ نو ممکنہ طور پر کئی ہفتوں سے کم ہو کر تقریباً تین گھنٹے رہ گئی۔ [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) یہ ثابت نہیں کر سکتا کہ ایک چھوٹی ٹیم پہلے ہی پوری صنعت کو محفوظ طریقے سے دوبارہ لکھ سکتی ہے، لیکن یہ ظاہر کرتا ہے کہ پہلے مہنگی تصدیق اور حملہ و دفاع کے کاموں کے لیے نئی لاگت کے حالات پیدا ہو سکتے ہیں۔

ایک تنظیمی طریقہ جو ابھی شروع کیا جا سکتا ہے وہ ہے مشترکہ طور پر ایک Build in Public AI Factory تعمیر کرنا۔ صنعت کے ماہرین، اسکالرز، اور پریکٹیشنرز کھلے عام تقاضے اور قبولیت کی تفصیلات (spec) لکھیں، وضاحت کریں کہ کیا تحفظ دینا ہے، کون سی کارروائیاں اجازت یافتہ ہیں، اور کون سی حدود کس اجازت کے نقصان کے بعد بھی برقرار رہنی چاہئیں، اور پھر ان تقاضوں کو قبولیت کے ٹیسٹوں میں تبدیل کریں۔ کوڈنگ ایجنٹس کے گروہ بنیادی کوڈنگ، ٹیسٹنگ، اور ڈیبگنگ کا کام سنبھالیں؛ مختلف ٹیمیں ڈیزائن اور نتائج کا معائنہ کریں، اور انسان فیصلے اور قبولیت کی ذمہ داری اٹھائیں۔شرکاء خیالات، مشینیں، کمپیوٹنگ پاور، اور ماڈل انووکیشن کوٹے، یعنی AI ٹوکنز، فراہم کر سکتے ہیں۔ AI اور کلاؤڈ کمپیوٹنگ کمپنیاں بھی ماڈل کوٹے، کمپیوٹنگ وسائل، اور ٹولز کے ذریعے اس عوامی تعمیر کی مدد کر سکتی ہیں۔ اسپیکس، پروٹوٹائپ کوڈ، ایجنٹ ورک فلو، ٹیسٹ ماحول، اور تصدیقی نتائج سب مشترکہ طور پر برقرار رکھے جانے والے بنیادی ڈھانچے کا حصہ بن سکتے ہیں، جس سے اگلی ٹیم براہ راست وہیں سے آگے بڑھ سکے۔ مقصد یہ ہے کہ ترقیاتی صلاحیت کو دوبارہ استعمال کے قابل عوامی سہولیات میں بدلا جائے اور کسی ایک شخص کے وقت یا کسی ایک ٹیم پر انحصار کم کیا جائے۔

حملہ آور بھی AI استعمال کر رہے ہیں، اور اب ہمارے پاس دفاع کو ماضی کے پیداواری طریقوں میں چھوڑنے کی کوئی وجہ نہیں۔ [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) لیکن کوڈ جنریشن کا تیز ہونا صرف نقطۂ آغاز ہے۔ صرف پابندیوں کو واضح طور پر لکھ کر، ٹیسٹوں کو بار بار قابلِ عمل بنانے، اور کسی کمپوننٹ کو قابلِ معائنہ اور قابلِ تبدیلی بنانے سے ہی AI صلاحیت کو بنیادی ڈھانچے کی بہتری میں تبدیل کیا جا سکتا ہے۔

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

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

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

ہمیں مل کر اس قسم کا بنیادی ڈھانچہ تعمیر کرنا چاہیے جہاں، اگرچہ کوئی حصہ متاثر ہو چکا ہو، پھر بھی اثاثوں کی حدود برقرار رہیں، دوسرے نظام غلطیوں کو مسترد کر سکیں، اور صارفین کے پاس بحالی اور اخراج کے راستے موجود رہیں۔ اسٹار وارز سے نام مستعار لے کر، یہ ہماری A New Hope ہے۔ [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) امید عام بلڈرز سے آتی ہے جو عمل کرنے کو تیار ہیں، اور اس لمحے سے بھی جب کوڈنگ ایجنٹس اور نئے انجینئرنگ طریقے انہیں زیادہ تعمیری کام سنبھالنے کے قابل بناتے ہیں۔میں Ethereum، Solana، Bitcoin اور XRP Ledger جیسے پروجیکٹس کے بنانے والوں، Binance، Coinbase اور Kraken جیسے ایکسچینجز، اور والٹ، پروٹوکول، سیکیورٹی ریسرچ، AI اور کلاؤڈ کمپیوٹنگ ٹیموں کو دعوت دینا چاہتا ہوں: واضح دائرہ کار کے ساتھ ایک پائلٹ سے شروع کریں اور مل کر ایسی بہتریاں پیدا کریں جنہیں دیگر ٹیمیں اپنا اور آزماسکیں۔

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

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

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

میں اس مضمون میں درج اثاثہ محدودیت اور بازیابی کی ضروریات کو پہلی عوامی spec میں ترتیب دینے میں شرکت کے لیے تیار ہوں، اور اس پائلٹ کے لیے دیگر شرکاء کے ساتھ مل کر ایک عوامی AI Factory بنانے کے لیے متعلقہ تکنیکی اور انجینئرنگ طریقوں کا حصہ ڈالنے کو بھی تیار ہوں۔ پہلے ایک بہت مخصوص مسئلہ منتخب کریں: روزمرہ کے لین دین کی کلید کے سمجھوتے میں آجانے کے بعد، حملہ آور کو ایک ہی بار میں والٹ خالی کرنے سے کیسے روکا جا سکتا ہے؟ قابلِ قبول نقصان کی حد، قواعد میں ترمیم کا اختیار، اور بازیابی کی شرائط کو acceptance tests میں لکھیں، پھر ڈویلپمنٹ ایجنٹس سے ایک پروٹوٹائپ نافذ کروائیں، اور ایجنٹس کے ایک اور گروہ اور آزاد محققین سے بائی پاس کے راستے تلاش کروائیں۔ غلط بیلنس واپس کرنے والے ڈیٹا سرورز، اور ڈیوائس گم ہونے کے بعد بازیابی، کو بھی بتدریج ٹیسٹوں میں شامل کیا جا سکتا ہے۔ پروٹوٹائپ کیا حاصل کرتا ہے، کہاں ناکام ہوتا ہے، اور کون سی انحصاریاں باقی رہتی ہیں، سب عوامی طور پر بیان کیا جانا چاہیے، اور اگلا قدم شواہد کی بنیاد پر طے کیا جانا چاہیے۔

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

Crypto اس طرح جاری نہیں رہ سکتا۔ جو لوگ مل کر کام کرنے کو تیار ہیں، آئیے ابھی عمل کریں، ایک ایسی بہتری سے شروع کریں جو بنائی جا سکے اور جانچ کا مقابلہ کر سکے۔Binance، ابتدائی اعلان کی سرکاری پوسٹ اور بعد ازاں تحقیقاتی سرکاری اپ ڈیٹ، 2026-10-30؛ TRM ملٹی چین تجزیہ۔ یہ مسودہ 2026-10-30 تک تصدیق شدہ تھا؛ تحقیقات اور بازیابی کی صورتحال تبدیل ہو سکتی ہے۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)

Satoshi Nakamoto، Bitcoin: A Peer-to-Peer Electronic Cash System، 2008۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)

Uniswap، Unichain EVM Equivalence۔ مشترکہ انحصار کی خطرے کی مرکزیت اس مضمون میں مصنف کا فیصلہ ہے، اس دستاویز کا نتیجہ نہیں۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)

Vitalik Buterin، Sam Wilson، Ansgar Dietrichs، lightclient، EIP-7702: Set Code for EOAs، تخلیق 2024-05-07۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)

Minfeng Qi، Qin Wang، Ruiqiang Li، Tianqing Zhu، Shiping Chen، EIP-7702 Phishing Attack، 2025-12-13، arXiv v1 پیشگی اشاعت؛ یہ اس Binance واقعے کی شناخت نہیں ہے۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)

Ethereum، Maximal extractable value (MEV)، ترتیب کے میکانزم، مختلف اقسام، اور منفی اثرات؛ "اسے بگ کے طور پر ٹھیک کیا جانا چاہیے" صارفین کو نقصان پہنچانے والے رویے کے بارے میں مصنف کا انجینئرنگ موقف ہے۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)

PHP سرکاری 2026 خبروں کا آرکائیو؛ CISA 2026-10-26 Known Exploited Vulnerabilities اپ ڈیٹ، CVE-2026-109618، CVE-2026-109619۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)

Safe، Guards and Modules، فعالیت اور اجازت کے خطرات کی وضاحت۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)

Apple، Apple to expand repair options with support for used genuine parts، 2024-04-11؛ موجودہ parts pairing سپورٹ کی وضاحت۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger، Ledger's Response to the Hardware Implant Attack، 2026-10، تقسیم کی زنجیر میں حملے کے بارے میں وینڈر کا بیان؛ Joe Grand، ہارڈویئر امپلانٹس پر ریورس انجینئرنگ تحقیق۔ غیر تصدیق شدہ نیٹ ورک نقصان کے تخمینوں کو حتمی نتائج کے طور پر پیش نہ کریں۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)

Coinkite، Current COLDCARD Security Status، رسائی 2026-10-30، جولائی 2026 کے واقعے اور تدارک کا مسلسل اپ ڈیٹ شدہ ریکارڈ؛ اپ گریڈ کرنا اور seed migration دو الگ الگ کارروائیاں ہیں۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)

ERC-4337: Account Abstraction Using Alt Mempool؛ Trezor، SLIP39 FAQs، threshold recovery، مطابقت، اور اضافی passphrase کے خطرات۔ موجودہ میکانزم تعمیر کی بنیاد ہیں، اور اس کا مطلب یہ نہیں کہ ہر تعیناتی قابل اعتماد ہے۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: جزوی طور پر دستخط شدہ بٹ کوائن ٹرانزیکشن فارمیٹ، غیر دستخط شدہ ٹرانزیکشنز کے لیے ایک تبادلہ فارمیٹ، نہ کہ کراس چین عمومی اثاثہ حکمت عملی کی تفصیل۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)

W3C، قابل تصدیق اسناد کا جائزہ v1.0، 2026-07-30 گروپ نوٹ؛ ایتھیریم پرائیویسی نوٹس۔ جائزے میں بیان کردہ ٹیکنالوجیز کی معیاری حیثیت ہر معاملے میں آزاد ہے۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)

CoW Protocol دستاویزات، ٹرانزیکشن ارادے اور سالور میکانزم؛ یہ مضمون کسی مخصوص تعیناتی کے لیے جامع سیکیورٹی توثیق فراہم نہیں کرتا۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)

iShares، IBIT 2025 سالانہ رپورٹ، PDF صفحات 8–10 تحویل کے انتظامات اور صفحہ 45 خطرے کے انکشافات۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)

Mark Nottingham، RFC 9518: مرکزیت، غیر مرکزیت، اور انٹرنیٹ معیارات، 2023-12، آزادانہ طور پر جمع کرایا گیا، معلوماتی RFC، معیاری ٹریک کی تفصیل نہیں۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)

بٹ کوائن وائٹ پیپر سیکشن 8 آسان ادائیگی کی تصدیق؛ BIP-157: کلائنٹ سائیڈ بلاک فلٹرنگ؛ ایتھیریم، لائٹ کلائنٹس۔ مختلف لائٹ کلائنٹس کی تصدیق کے دائرے اور اعتماد کی شرائط مختلف ہیں۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)

ایتھیریم فاؤنڈیشن، ٹریلین ڈالر سیکیورٹی اقدام کا اعلان، 2025-05-14۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)

Anthropic، اہم بنیادی ڈھانچے کے دفاع کے لیے AI، 2026-01-08، PNNL کے تعاون سے محدود ماحول میں تحقیق۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)

Anthropic، AI سے چلنے والے سائبر خطرات کی نقشہ سازی، حقیقی غلط استعمال کے نمونوں پر تحقیق۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)

Lucasfilm، Star Wars: A New Hope (Episode IV)، 1977؛ یہ مضمون عنوان اور مشترکہ خود بچاؤ کی تصویر کشی مستعار لیتا ہے۔ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)