لا يمكن للعملات المشفرة أن تستمر على هذا النحو: مبادرة إنقاذ ذاتي للقطاع من ممارس في مجال البلوكتشين

الحادث لا يزيل الأصول فحسب، بل يزيل الثقة أيضًا. لا يمكن للعملات المشفرة أن تستمر على هذا النحو؛ يجب أن ننقذ أنفسنا.

المؤلف: روبرت ماو، المؤسس والرئيس التنفيذي لشركة ArcBlock

هذا المقال مصرح لأي شخص بإعادة إنتاجه ونقله بحرية، على أمل أن يرى المزيد من الناس هذه الدعوة للصناعة لإنقاذ نفسها.

لا يمكن أن يستمر الوضع في عالم العملات المشفرة على هذا النحو. مرارًا وتكرارًا، لا تسرق عمليات السرقة الضخمة الأصول فحسب، بل تسرق أيضًا ثقة المشاركين في الصناعة بأكملها. يجب علينا أن ننقذ أنفسنا.

في 29 أكتوبر 2026، وقع حادث أمني كبير في Binance. قدرت إعلاناتها الأولية أن حوالي 6.3 مليار دولار من الأصول تأثرت، وتم تجميد حوالي 3 مليارات دولار من الأصول المتأثرة؛ أشار التحقيق في البداية إلى حاسوب محمول لمهندس DevOps، ثم تم اكتشاف نقاط اختراق محتملة أخرى لاحقًا. كما صرحت Binance أنه لم يتم العثور على أي دليل على تسرب المفاتيح الخاصة للمحفظة. المبلغ المتأثر ليس صافي الخسارة النهائية، ولا يزال سلسلة الهجوم الكاملة قيد التحقيق. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

هذه المبادرة موجهة إلى بناة مشاريع البلوكتشين مثل Ethereum وSolana، وأيضًا إلى Binance وCoinbase وKraken وجميع البورصات والمحافظ والبروتوكولات وبناة الأمان المستعدين للمشاركة: دعونا نعيد بناء الأساس لحماية الأصول معًا. أنا مستعد للمشاركة، وآمل أن يتصرف المزيد من الناس معًا.

هذا ثقيل بما فيه الكفاية بالفعل. لكن ما يقلقني أكثر هو مقدار الثقة في العملات المشفرة التي سيدمرها هذا الحادث، وكم عدد المهاجمين الذين سيقودهم إلى اعتبار هذه الصناعة هدفًا لا يزال يستحق مواصلة الهجوم عليه. حتى لو تحمل شخص ما الخسائر في النهاية، فإن التعويض لا يمكنه إصلاح ثقة المستخدمين تلقائيًا، ولا يمكنه منع حدوث نفس نوع الدمار مرة أخرى.

Binance هي فقط نقطة الدخول التي تجبرنا على مواجهة المشكلة اليوم. بالنظر بعيدًا، تركت البورصات والجسور والبروتوكولات على السلسلة والمحافظ منذ فترة طويلة أثرًا طويلًا من الجروح. تظهر شبكات ومنتجات جديدة باستمرار، ومع ذلك تتكرر أنماط الفشل القديمة مرارًا وتكرارًا. لا يمكننا إصدار إعلان، والانتظار لفترة، ثم التعامل مع الحادث التالي كأمر روتيني.

يجب علينا أيضًا أن نعترف بأن عمليات الاحتيال وممارسة مجرد إنشاء المفاهيم دون تحمل مسؤولية البناء قد أضرت بهذه الصناعة لفترة طويلة جدًا. يجب على الفرق التي تبني التكنولوجيا والبنية التحتية بجدية أن تتحمل أيضًا عواقب الثقة المفقودة معًا. بحلول الوقت الذي يرى فيه الناس كل العملات المشفرة على أنها احتيال، قد يتم التخلي عن التكنولوجيا والاستكشاف الذي يستحق الحفاظ عليه حقًا معها.

بصفتي مؤسس ArcBlock وممارسًا في مجال العملات المشفرة والبلوكتشين، أنا غير مستعد لقبول مثل هذه النتيجة. أعتقد أن هذه الصناعة لها قيمة تستحق الحماية، وأعتقد أيضًا أنه يجب علينا تحمل المسؤولية عن أساس الأمان الخاص بنا. إذا استمررنا في الانتظار السلبي للحادث التالي، فقد يؤدي النزيف المتكرر في النهاية إلى تدمير كل ما بنيناه معًا.لذا، أريد أن أطلق هذه المبادرة: يجب على بناة المنصات والمحافظ والسلاسل الكتلية أن يعيدوا بناء أساس التحكم في الأصول والتحقق من الأمان بشكل مشترك، بحيث يكون نطاق الضرر الناجم عن اختراق واحد محدوداً. يشرح الجدول الزمني أدناه سبب ضرورة التغيير؛ والاقتراح التقني الذي يليه هو العمل الذي أعتقد أننا يمكن أن نبدأ في القيام به.

في عام 2008، اقترح ساتوشي ناكاموتو نظام نقد إلكتروني من نظير إلى نظير، محاولاً جعل المدفوعات أقل اعتماداً على الوسطاء الموثوقين. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) ومع ذلك، كشفت الحوادث الكبرى منذ ذلك الحين مراراً وتكراراً عن مشكلة تركيز الأموال والتفويض واعتماديات البرمجيات مرة أخرى.

فيما يلي قائمة زمنية بالحوادث التمثيلية في مجالات مثل المنصات المركزية (CEX)، والمنصات اللامركزية (DEX)، والجسور، والمحافظ. وهي ليست قاعدة بيانات كاملة للحوادث، ولا إحصائية خسائر سنة بسنة. حيثما ذُكرت المبالغ، فإنها تشير إلى الأثر الإجمالي التقريبي وقت وقوع الحادث؛ ويوصف السرقة والتجميد والاسترداد اللاحق بشكل منفصل ولا يمكن جمعها معاً كخسائر دائمة.

2008 · ورقة بيتكوين البيضاء

نقطة البداية

اقترحت ورقة بيتكوين البيضاء مدفوعات من نظير إلى نظير دون مؤسسات مالية كوسطاء.

المصدر

2011–2014 · سرقة Mt. Gox طويلة الأمد

CEX

تعرضت Mt. Gox لسرقة طويلة الأمد وتوقفت في النهاية عن العمل. زعم لائحة اتهام لاحقة من وزارة العدل الأمريكية أن ما يقرب من 647,000 BTC سُرقت بين عامي 2011 و2014. لم يكن هذا هجوماً في يوم واحد عام 2014.

المصدر

2012 · Bitcoinica وBitfloor

CEX / البنية التحتية للحفظ

تعرضت بيئة استضافة Linode الخاصة بـ Bitcoinica للاختراق؛ وفي العام نفسه، أصبحت النسخة الاحتياطية غير المشفرة لمحفظة Bitfloor نقطة دخول للهجوم. الخوادم والنسخ الاحتياطية وراء المنصة هي أيضاً جزء من حدود أمان الأصول.

المصدر

2015 · المحفظة الساخنة لـ Bitstamp

CEX

تعرضت المحفظة الساخنة لـ Bitstamp للاختراق، وأُعيد بناء بيئة التشغيل لاحقاً. أظهر التمييز الرسمي بين نطاق الحادث والاحتياطيات غير المتصلة بالإنترنت أن العزل يمكن أن يحد من نطاق التعرض.

المصدر

2016 · Bitfinex

CEX

سُرقت ما يقرب من 120,000 BTC من Bitfinex. لا تزال ترتيبات التوقيع المتعدد تتطلب تفويضاً وتحققاً مستقلين من البداية إلى النهاية.

المصدر 1 · المصدر 2

2016 · The DAO

بروتوكول على السلسلة

تعرض عقد The DAO لهجوم إعادة الدخول، ونُقل ما يقرب من 3.6 مليون ETH إلى DAO فرعي، مما أدى لاحقاً إلى إطلاق شوكة إيثريوم. يمكن لمسار تنفيذ مشروع أن ينتج نتائج تجارية كارثية.

المصدر 1 · المصدر 2

2017 · مكتبة المحفظة المشتركة Parity

محفظة عقد

دُمّرت مكتبة المحفظة المشتركة Parity، وجُمّد ما يقرب من 513,000 ETH. حتى لو لم تُنقل الأموال بعيداً، يمكن أن تصبح غير قابلة للاستخدام بسبب اعتماديات الكود المشترك.

المصدر

2018 · Coincheck

CEXتم سرقة محفظة NEM الساخنة الخاصة بـ Coincheck. أصبح الحد الفاصل بين الاحتياطيات غير المتصلة بالإنترنت وأذونات المحفظة الساخنة والاحتياجات التجارية مشكلة مرة أخرى.

المصدر

2019 · Binance

CEX

أعلنت Binance عن سحب 7,000 BTC في معاملة واحدة. يجب تقييد التدفقات الخارجية للأصول واسعة النطاق قبل التوقيع.

المصدر

2020 · KuCoin

CEX

حادثة المحفظة الساخنة لـ KuCoin، مع استرداد كمية كبيرة من الأصول لاحقًا من خلال تعاون متعدد الأطراف. المبلغ الإجمالي المسروق والخسارة النهائية ليسا الرقم نفسه.

المصدر

2021 · Poly Network

بروتوكول عبر السلاسل

تم تحويل ما يقرب من 612 مليون دولار من الأصول خارج Poly Network وأُعيدت لاحقًا على مراحل. لا يمكن للتفويض عبر السلاسل والتحكم في الأصول الاعتماد فقط على مسارات الأعمال العادية.

المصدر

2022 · جسر Ronin

جسر

تم اختراق أذونات المدققين في Ronin، وتم تحويل 173,600 ETH و25.5 مليون USDC خارجًا. يمكن أن تقع مفاتيح عدة مدققين أيضًا في سلسلة الهجوم نفسها.

المصدر

2022 · محفظة Slope

محفظة

حادثة محفظة Slope في نظام Solana البيئي. أعلنت Solana رسميًا أن معلومات المفتاح الخاص نُقلت عن طريق الخطأ إلى خدمة مراقبة تطبيقات؛ لم يكن اختراقًا لإجماع Solana.

المصدر

2023 · Euler

بروتوكول إقراض

تم تحويل ما يقرب من 197 مليون دولار من الأصول خارج Euler بسبب ثغرة في البروتوكول واستُردت لاحقًا. يمكن للتركيبات المعقدة في معاملة واحدة أن تضخم عيوب منطق الأعمال.

المصدر

2023 · Ledger Connect Kit

أداة ربط المحفظة

تعرض Ledger Connect Kit لهجوم سلسلة التوريد، ودخلت شيفرة خبيثة إلى واجهة التطبيق الأمامية. لا يمكن لأمان الجهاز المادي أن يحل محل التحقق من محتوى المعاملة.

المصدر

2024 · DMM Bitcoin

CEX

تمت سرقة ما يقرب من 308 ملايين دولار من DMM Bitcoin. كشفت FBI وجهات أخرى لاحقًا عن هجمات هندسة اجتماعية استهدفت الموظفين المعنيين وسلسلة التوقيع.

المصدر

2024 · Radiant Capital

بروتوكول إقراض / توقيع

تمت سرقة ما يقرب من 50 مليون دولار من Radiant Capital، وتم اختراق أجهزة مطورين متعددة. لا يزال التوقيع متعدد الأطراف يعتمد جماعيًا على معلومات معاملات ملوثة.

المصدر

2025 · Bybit / Safe

CEX / واجهة محفظة أمامية

شملت حادثة Bybit التي بلغت حوالي 1.5 مليار دولار بيئة مطوري Safe والواجهة الأمامية، ووافق الموقعون على معاملة غيرت منطق التحكم في المحفظة.

المصدر 1 · المصدر 2

2025 · Cetus DEX

DEXحادثة Cetus على Sui التي بلغت حوالي 223 مليون دولار، وأشار الباحثون إلى عيب في مكتبة رياضية. يجب على البيئات غير EVM أيضًا فحص شيفرتها ونطاق تعرض الأصول.

المصدر

2026-07 · عيب الأرقام العشوائية في COLDCARD

محفظة مادية / توليد البذرةضعف في البرنامج الثابت أضعف توليد البذور، ما سمح للمهاجمين بإعادة بناء المفاتيح الخاصة ذات الصلة بينما كان الجهاز غير متصل بالإنترنت. لا يمكن للترقية إصلاح البذور الضعيفة التي تم توليدها بالفعل؛ ولا يزال الترحيل وفقًا للتنبيه مطلوبًا.

المصدر

2026-10 · زرع عتاد Ledger

محفظة عتاد / هجوم على قناة التوزيع

أكدت Ledger أن أجهزة أصلية تم تعديلها وتداولها عبر قنوات التوزيع في جنوب شرق آسيا، مع مكونات مزروعة تسرق عبارات الاسترداد أثناء التهيئة. وتقول الشركة إن رقائقها ونظام تشغيلها وخوادمها لم تُخترق.

المصدر

2026 · حادثة Binance متعددة السلاسل

CEX / متعدد السلاسل

قدّرت Binance في البداية أن ما يقرب من 6.3 مليار دولار من الأصول تأثرت، ولا تزال التحقيقات في نقاط اختراق محتملة أخرى جارية. يمكن لنظام تشغيل واحد أن يعرّض الأصول عبر شبكات متعددة في آنٍ واحد.

المصدر 1 · المصدر 2 · المصدر 3

هنا توجد منصات تداول مركزية (CEX)، ولكن أيضًا منصات تداول لامركزية وبروتوكولات إقراض وجسور؛ وهناك أصول مسروقة وأصول مجمّدة. تحدث الهجمات في طبقات مختلفة، وتختلف طرق المعالجة. أنا أعارض اختزال كل هذا في جملة واحدة: "فشل المستخدمون في حماية مفاتيحهم الخاصة." كيف يمكن للمستخدمين أن يعرفوا أن بيئة تطوير أداة معينة، أو مكتبة مشتركة معينة، أو تفويضًا غير مفهوم سيصبح نقطة الدخول إلى جميع أصولهم؟

لقد فعلت الشبكات الموزعة الكثير بالفعل، ومع ذلك فإن عزل الأعطال للتحكم في الأصول بعيد عن الكفاية. التنفيذ على السلسلة يكمل المعاملة بأمانة، لكنه لا يستطيع أن يجيب نيابة عنا عن سبب امتلاك تلك المعاملة للحق في تحريك هذا القدر.

مساهمة Ethereum كبيرة. فقد مكّنت المزيد من الناس من كتابة تطبيقات على السلسلة، وعززت مجموعة غنية من الأدوات وخبرة التطوير. لكن اليوم، تتعامل العديد من السلاسل الجديدة وشبكات L2 (شبكات التوسع من الطبقة الثانية) مع توافق EVM كهدفها الأساسي. إن EVM، الآلة الافتراضية التي تنفذ عقود Ethereum الذكية، أصبحت فرضية تقنية تُنسخ على نطاق واسع. التوافق يجعل ترحيل التطبيقات مريحًا بالفعل؛ وتستشهد وثائق مشاريع مثل Unichain صراحةً بإعادة استخدام أدوات Ethereum كقيمة لبيئة تنفيذ مكافئة. [[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) تدرس المسودة البحثية "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 Ledger، وكذلك البنّائين بما في ذلك ArcBlock، إلى المشاركة بجدية في بناء أساس أمني مشترك. لا تتطلب المشاركة في المعايير وقابلية التشغيل البيني أن يعيد المرء تشكيل نفسه أولًا ليصبح إيثيريوم. يجب تنفيذ التنوع في التحكم بالأصول وطرق التحقق وأن يكون مفتوحًا للتدقيق العام. لقد ذكّرتنا حادثتا Slope وCetus بالفعل بأن غير EVM لا يتمتع بإعفاء أمني أيضًا.

ما آمل أن يتبلور هو مواصفة أمنية يمكن لبيئات التنفيذ المختلفة أن تتبناها جميعًا: يمكن لـ EVM والمسارات الأخرى تنفيذ حدود الأصول ومتطلبات التحقق نفسها كلٌّ على حدة، ثم يمكن فحص ضمانات وتكاليف كل منها علنًا.

1. دع ضوابط المخاطر الأساسية تقيّد صلاحية التصرف بالأصول

ينبغي أن تتمكن المحافظ الكبيرة من إعداد قوائم بيضاء للمستلمين، وحدود إنفاق تراكمية، وفترات انتظار للمستلمين الجدد. النقطة الأساسية هي أن هذه القواعد لا يمكن إلغاؤها فورًا بواسطة مفتاح المعاملات اليومية نفسه. يتطلب تعديل القواعد تفويضًا مستقلًا ويجب أن يترك وقتًا للمراقبة والإلغاء.الحسابات الذكية القائمة لديها بالفعل أساس تنفيذي، فعلى سبيل المثال يمكن لـ Safe Guards إضافة قيود على المعاملات تتجاوز التوقيع المتعدد. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) نحتاج إلى جعل هذه قدرة أساسية أسهل في التبني تغطي جميع مسارات التحكم في الأصول. إذا تم تقييد التحويلات المباشرة فقط بينما سُمح بالتجاوز عبر الموافقات غير المحدودة أو الوحدات أو الترقيات، فستفشل الحماية. ويجب أيضاً أن يدخل نطاق التحقق كل من: ما إذا كان يمكن ترقية عقد القائمة البيضاء، وما إذا كانت صلاحيات المستلم قد تغيرت. يوفر قفل التنشيط من Apple مصدر إلهام من الحياة اليومية: فهو يقيّد إعادة تنشيط الأجهزة المسروقة ويحد من معايرة بعض الأجزاء المسروقة، بهدف تقليل القيمة التي يمكن استغلالها بعد السرقة. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) تستحق المحافظ أيضاً التصميم في هذا الاتجاه. إذا حصل المهاجم على مفتاح، يبقى نطاق الأصول التي يمكن تحويلها إلى نقد محدوداً، وقد ينخفض العائد المتوقع من الهجوم؛ ولا تزال المخاطر مثل تعطيل الخدمات بحاجة إلى معالجة منفصلة.

هذا ما أسميه "دستور" أمن الأصول: قد تتعرض الصلاحية التشغيلية للاختراق، لكن صلاحية تعديل الحدود يجب أن تبقى مستقلة. يجب أيضاً تقييد عمليات الاسترداد، لمنع إعداد خاطئ واحد من قفل الأصول بشكل دائم.

ثانياً. اجعل المحافظ تتحمل مسؤولية الأمن، بدلاً من مجرد تسليم العبارات الاستذكارية

لدي استياء قوي من أنظمة المحافظ الحالية: إذا طلب منتج ما من شخص عادي نسخ مجموعة من الكلمات، واشترط ألا يسرّبها أو يفقدها أو يُخدع بها أبداً، ثم نسب كل الإخفاقات اللاحقة إلى مسؤولية المستخدم، فأنا أعتبر ذلك تصميماً غير مسؤول. يجب أن تمنح الحفظ الذاتي الناس السيطرة، ويجب أيضاً أن تمنحهم قدرات حماية واسترداد قابلة للاستخدام. لا ينبغي أن تتطلب من كل مستخدم أن يصبح خبيراً في الأمن أولاً. وهذا أيضاً عتبة يجب أن يتجاوزها Crypto للوصول إلى مزيد من المستخدمين العاديين.لقد وضعت الحوادث الأخيرة هذه المشكلة مباشرة على طاولة النقاش. في أكتوبر 2026، أكدت Ledger أن المهاجمين عدّلوا أجهزة أصلية ثم أعادوا إرسالها إلى السوق عبر قنوات التوزيع في جنوب شرق آسيا، مع مكوّنات مزروعة تسرق كلمات الاسترداد أثناء التهيئة. صنّفت Ledger ذلك كهجوم توزيع محلي بعد مغادرة الجهاز للمصنع، وليس اختراقاً لشريحته أو نظام تشغيله أو خوادمه. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) تضمّن حادث COLDCARD في يوليو إضعاف البرنامج الثابت لتوليد البذرة: لم يكن الجهاز بحاجة إلى تحكّم عن بُعد كي يعيد المهاجم بناء المفاتيح الخاصة ذات الصلة. إصلاح البرنامج الثابت يصحّح عملية التوليد مستقبلاً، لكن البذور الضعيفة التي جرى توليدها بالفعل لا تزال بحاجة إلى ترحيل. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)

هذان الحادثان ليسا من النوع نفسه من الثغرات، لكنهما معاً يُظهران: حتى لو نسخ المستخدمون الكلمات بعناية وأبقوا الجهاز دون اتصال، فإنهم لا يستطيعون التحقق من العشوائية وسلامة سلسلة التوريد نيابةً عن المُصنّع. عرض الجهاز لكلمات النسخ الاحتياطي له غرض الاسترداد دون اتصال، لكنه يتسبب أيضاً في مرور سرّ الاسترداد الكامل عبر مسار عرض ونسخ احتياطي يحتاج إلى حماية. أمن الشريحة لا يمكن أن يحل محل التحقق من الجهاز بأكمله وعملية التسليم.

ينبغي أن يكون هدف التحسين دورة حياة المحفظة الكاملة: كيف تُولَّد المفاتيح، وكيف تُشرح المعاملات، وكيف تُفصل الأذونات، وكيف يعمل الاسترداد بعد فقدان الجهاز. تجريد الحساب، أي السماح للحسابات بالتحقق من التفويض عبر قواعد قابلة للبرمجة، والنسخ الاحتياطي العتبي مثل SLIP-39، لكل منهما معايير وأسس تنفيذ، فلا يمكن القول إن لا أحد في الصناعة يعمل عليهما. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) لكننا بحاجة إلى جعل هذه القدرات حمايات مُختبَرة وسهلة الاستخدام، بدلاً من أن يركّب المستخدمون مخططات معقدة بأنفسهم.

التعتيم البسيط لكلمات الاستذكار ليس كافياً. تشمل الاتجاهات الأكثر موثوقية النسخ الاحتياطي المشفّر المُدقَّق، والاسترداد العتبي، والتفويض المستقل للجهاز، وإتمام المستخدمين تدريبات الاسترداد قبل إيداع كميات كبيرة من الأصول. شظايا النسخ الاحتياطي والتوقيع المتعدد طبقتان مختلفتان: الأولى قد تُعاد تركيبها إلى السر نفسه أثناء الاسترداد، بينما تتطلب الثانية موقّعين مستقلين متعددين للموافقة على معاملة. يجب ألا تتحول خدمات الاسترداد بهدوء إلى مفتاح رئيسي جديد، ولا ينبغي أن تتحول كلمة مرور إضافية إلى فخ آخر حيث يعني فقدانها خسارة غير قابلة للاسترداد.يمكن لمحافظ الأفراد وأنظمة محافظ المنصات أن تتشارك مواصفات أمنية لوصف المعاملات، وطلبات التوقيع، وقيود الأصول، وعمليات الاسترداد، مع اعتماد حدود وسياسات موافقة مختلفة. توفر PSBT في بيتكوين بالفعل تنسيقًا لتمرير المعاملات غير الموقعة بين الأدوات، وهذا الواجهة المشتركة جديرة بمواصلة بنائها. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) ما هو مشترك هو متطلبات الأمان القابلة للتحقق؛ ولا تزال كل سلسلة بحاجة إلى توضيح قواعد التكيّف الخاصة بها. ينبغي للمحافظ أن تعرض بوضوح ما ستنقله هذه التوقيعات ومقدار الصلاحية اللاحقة التي تمنحها ولمن، وينبغي للسياسات المستقلة أن ترفض العمليات الخارجة عن الحدود؛ فصفحة تأكيد أجمل ليست كافية.

ثالثًا. تحقيق القابلية للتحقق بأقل قدر ضروري من الإفصاح

لا ينبغي أن يتطلب إثبات تحقق شرط ما دائمًا من المستخدمين الإفصاح عن جميع البيانات الأساسية. ينبغي أن يصبح الإفصاح الانتقائي، وإثباتات المعرفة الصفرية، والوصول إلى التدقيق الممنوح عند الطلب خيارات طبيعية في البنية التحتية. ويرتبط هذا أيضًا بأمن الأصول: فقد توفر الهوية العامة وعلاقات الأصول أدلة على الخداع المستهدف؛ وينبغي كشف البيانات التي لا تحتاجها الأعمال بأقل قدر ممكن.

لدى نظام بيانات الاعتماد القابلة للتحقق التابع لـ W3C بالفعل مسار تقني للإفصاح الانتقائي؛ ومع ذلك، لا يزال إثبات أصالة المدخلات، واستمرار صلاحية بيانات الاعتماد، وكيفية إلغاء الحالة بحاجة إلى توضيح. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) إن اعتماد إثباتات المعرفة الصفرية (ZK) لا يخفي تلقائيًا مبالغ المعاملات وعلاقاتها؛ فإثباتات التوسع وحماية الخصوصية هدفان مختلفان.

على سبيل المثال، عندما تحتاج الأعمال فقط إلى التحقق من أهلية المشاركة، يمكن للمستخدم تقديم استنتاج أهلية صالح صادر عن مؤسسة موثوقة دون الإفصاح عن مواد مالية كاملة. وعندما يكون من الضروري إثبات أن قيمة مخفية تستوفي شرطًا ما، يمكن عندئذ استخدام آلية إثبات مناسبة. ولا يزال المصدر الموثوق لبيانات الاعتماد وحالة إلغائها بحاجة إلى التحقق.

مبادرتي هي توضيح "من يحتاج إلى التحقق من ماذا" أولًا، ثم تصميم البيانات التي يجب أن تُنشر علنًا. قد يحتاج أولئك الذين يتحققون من الأهلية فقط إلى استنتاج الأهلية؛ ويمكن لأولئك الذين يتحملون مسؤوليات تدقيق محددة الحصول على أدلة مقيدة. وينبغي للقيود القابلة للتحقق علنًا أن تقلل إلى أدنى حد من المعلومات الشخصية المكشوفة بشكل دائم للجميع.

رابعًا. جعل خدمات المعاملات خالية من الحفظ المركزي قدر الإمكانيجب تصميم مطابقة التداول وإيجاد المسار وتسوية الأصول بشكل منفصل. ينبغي للخدمة التي توفر نقطة دخول للتداول أن تحصل فقط على الأذونات اللازمة لإتمام التسوية الحالية قدر الإمكان، بحيث تبقى أصول المستخدمين تحت سيطرتهم respective في بقية الوقت. لقد استكشفت بروتوكولات المعاملات القائمة على النوايا جزءًا من المسار بالفعل، ويمكن للصناعة مواصلة إكماله. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

ما يوافق عليه المستخدمون يجب أن يكون شروط تسوية واضحة، تشمل ما يُدفع، وما يُستلم كحد أدنى، ومتى ينتهي، والرسوم المسموح بها. بعد اختراق خدمة تداول، قد يرفض المهاجم الخدمة، لكنه لا يستطيع تغيير هذه الشروط تعسفيًا. يجب على الشركات التي لا تزال تتطلب الحفظ المركزي أيضًا فصل أذونات الاحتياطي والتشغيل، وتقييد تعرض المحفظة الساخنة وحدود التزويد التلقائي.

IBIT هو منتج بيتكوين متداول في البورصة من iShares، وما يتم تداوله في السوق هو أسهمه. يوفر ترتيبه مثالًا على العزل الجزئي: تُسجل الأسهم والبيتكوين الأساسي بشكل منفصل، وتُوضع المفاتيح الخاصة ذات الصلة لرصيد الخزنة (رصيد الحفظ) في التخزين البارد. لا تتطلب التغييرات في سجل تداول الأسهم تحرك البيتكوين الأساسي مع كل معاملة. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) ما يمكن تعلمه من هذا هو فصل حقوق التداول وحقوق التصرف في الاحتياطي. رصيد التداول (رصيد خدمة التداول) له ترتيب مختلف، والحفظ نفسه يحمل مخاطر أيضًا؛ يجب أن يقترن التخزين البارد بالتحقق المستقل من التعليمات والتوقيع.

أقارن نقطة دخول التداول بموجه (router) على أمل أن يكون من الممكن استبداله دون حمل مفتاح رئيسي يتحكم في جميع أصول المستخدمين. التسوية أكثر تعقيدًا من إعادة توجيه الحزم، ولا يزال تسليم الأصول والتفويض بحاجة إلى تحقق مستقل. إن جعل خدمة غير حفظية ثم منحها حقوق سحب غير محدودة لن يعيد إلا المخاطر المركزية.

خامسًا. استخدام بنية طبقية لعزل الأعطال والحفاظ على قابلية الاستبدالنحتاج إلى واجهات للهوية والتفويض، وسياسات للأصول، وأساليب للتحقق من التسوية، قادرة على التطور بشكل مستقل. يمكن لسلاسل مختلفة الاحتفاظ بنماذج تنفيذها الخاصة والاتصال عبر واجهات واضحة. ينبغي أن تنص الواجهات على ضمانات الأمان وشروطها، لا أن تقول فقط "نجح الاستدعاء". تدعم تجربة الإنترنت هذا النهج. في RFC 9518، "المركزية واللامركزية ومعايير الإنترنت"، يناقش مارك نوتنغهام تحديدًا الحالات التي يمكن أن تكون فيها المركزية مفيدة، ويحلل أيضًا القوة والمخاطر التي تجلبها. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) هذا بالضبط الموقف الجدير بالتعلم: دع البنية تجيب عن أي المسؤوليات يمكن مركزتها، وإلى أي درجة، وكيفية منع تلك القوة من التوسع. يمكن السماح لخدمة ما بتحديد الحالات الشاذة مركزيًا مع تقييد إذنها للمس بالأصول؛ وينبغي أن يكون المستخدمون قادرين على تبديل الخدمات دون فقدان سياسات أصولهم وسجلات التحقق الخاصة بهم.

أهم سؤال قبول هو: بعد اختراق خدمة أعمال، أي طبقة مستقلة يمكنها still رفضها؟ إذا كانت جميع الطبقات تتشارك مفتاحًا إداريًا واحدًا، فإن ما يسمى بالتقسيم الطبقي ليس سوى تقسيم طبقي على مخطط نشر.

يمكن النظر إلى هذا الهدف على أنه خمس طبقات من المسؤولية: خدمة المعاملات تقدم الطلبات، والمحفظة تعبر عن نية المستخدم، والسياسة المستقلة تحد من السلطة على التصرف في الأصول، ومكوّن التحقق يفحص العمليات والأدلة، وطبقة التسوية تفرض القيود وتوفر سجلات قابلة للتحقق. يمكن أن تنفذها فرق مختلفة، ويجب أيضًا وصف تبعياتها وشروط فشلها بشكل منفصل.

البنية المستهدفة التي يدعو إليها هذا المقال. يجب أن تفرض طبقة التسوية سياسة الأصول؛ لا يمكن للمطالبات في المحفظة أن تحل محل هذا القيد. يحتاج التوقيع اليومي، وتغييرات القواعد، وسلطة الاسترداد إلى العزل والخضوع لاختبارات التجاوز.

6. دع المستخدمين يتحققون من أصولهم الخاصة بخفة

لا ينبغي للأشخاص العاديين أن يضطروا إلى تخزين وتنفيذ التاريخ الكامل للسلسلة بأكملها من أجل التحقق من أرصدتهم وإيصالاتهم؛ ولا ينبغي لهم أن يضطروا إلى الوثوق بخادم واحد فقط خلف المحفظة. اقترح ساتوشي ناكاموتو بالفعل SPV، التحقق المبسط للمدفوعات، في القسم 8 من الورقة البيضاء. يواصل BIP-157 من بيتكوين استكشاف السماح للعملاء بتنزيل المرشحات والعثور على الكتل المتعلقة بهم؛ لدى إيثريوم أيضًا تصاميم عملاء خفيفين. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) لذا فإن المشكلة ليست أن أحدًا لم يفكر في ذلك من قبل، بل أننا ما زلنا بحاجة إلى بناء قدرة تحقق بشروط أمان واضحة في المحافظ التي يستخدمها المستخدمون كل يوم.خذ سلسلة تدعم إثباتات حالة الحساب كمثال: عند الاستعلام عن رصيد، يجب أن يعيد الخادم الرصيد والإثبات معًا. تتحقق المحفظة أولًا من ملخص كتلة قصير، أي رأس الكتلة، وفقًا لقواعد تلك السلسلة، ثم تتحقق مما إذا كان هذا الرصيد متسقًا مع البيانات التي التزم بها الملخص. يقدم الخادم الإجابة، ويمكن للمحفظة التحقق من الإجابة. يتحقق SPV في بيتكوين من الأدلة على تضمين المعاملات ذات الصلة؛ ولا يمكن نسخه مباشرة كإثبات رصيد. يجب أن تعرض المحفظة أيضًا بوضوح أين وصلت في المزامنة وأي المعلومات تم التحقق منها؛ وعندما تكون الإثباتات مفقودة، أو البيانات قديمة، أو المصادر متعارضة، يجب أن تحذر أو توقف العمليات عالية المخاطر التي تعتمد على هذه المعلومات، ويجب ألا تتراجع بصمت إلى الثقة العمياء.

لا يزال التحقق الخفيف مشروطًا. إثبات تضمين معاملة في كتلة ليس هو نفسه التحقق بنفسك من صحة جميع المعاملات في الكتلة. قد تعتمد مخططات مختلفة على أمان أغلبية قدرة التجزئة، أو على سجل أولي موثوق، أي نقطة تفتيش؛ ويجب أيضًا الحذر من احتجاز الخوادم للبيانات أو عزل المستخدمين على سجل سلسلة قديم. كما يجب معالجة ما إذا كان الاستعلام نفسه يكشف العناوين التي يهتم بها المستخدم. العقد الكاملة ومنتجو الكتل ليسوا الدور نفسه؛ تستخدم إيثريوم اليوم المدققين بدلًا من المعدنين لإنتاج الكتل.

الأهم من ذلك، إثبات أن "هذا التحويل حدث فعلًا على السلسلة" لا يمكنه إثبات أن "هذا هو بالضبط التحويل الذي أراده المستخدم". لا يمكن للعملاء الخفيفين استبدال حدود الأصول وفحوص التوقيع السابقة. إنهم يجعلون المستخدمين يعتمدون أقل على إجابة غير قابلة للتحقق، بينما تضمن سياسة الأصول أنه حتى التوقيع الصالح لا يمكنه التصرف في الأصول بلا حدود. فقط من خلال بناء الطبقتين معًا يمكن توزيع قدرة التحقق بين المشاركين.

7. بناء تحديد الحالات الشاذة والتحقق الأمني كبنية تحتية عامة

قبل المعاملة، يجب أن يتحقق شخص ما مما إذا كانت العملية تتوافق مع سياسة الأصول وما إذا كانت تغير فجأة السلوك التاريخي. يمكن للحالات الشاذة الواضحة أن تؤدي إلى إيقاف مؤقت أو مراجعة مصعدة؛ ويتطلب توسيع الأذونات مسارًا مستقلًا آخر. يمكن للذكاء الاصطناعي المشاركة في الحكم، لكن يجب ألا يحصل على تصريح يتجاوز القواعد الصارمة.

في الوقت نفسه، نحتاج إلى صيانة مشتركة لحالات الهجوم واختبارات الأذونات وأدوات التحقق القابلة للتشغيل المتكرر. فقط من خلال مشاركة المواصفات والحفاظ على تطبيقات مستقلة وتحقق مستقل يمكن تقليل حالات الفشل المشتركة. لدى المؤسسات والبورصات بالفعل استثمارات أمنية، مثل مبادرة الأمن التريليون دولاري لمؤسسة إيثريوم. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) السؤال التالي الذي يجب طرحه هو ما إذا كان يمكن تحويل الاستثمار إلى بنية تحتية عامة يمكن للفرق الأخرى أيضًا تبنيها وفحصها.لا يمكن لأي من بنود العمل السبعة هذه أن يضمن أمانًا مطلقًا. ما تحتاج إلى تحقيقه هو حدود قابلة للفحص: تحت أي ظروف من اختراق الصلاحيات، وما أقصى قدر من الأصول المكشوفة، ومدى سرعة اكتشاف الحالات الشاذة، وعلى من لا يزال التعافي يعتمد.

عند هذه النقطة، قد يقول البعض: يبدو الاتجاه صحيحًا، لكن الصناعة قد مضت لسنوات عديدة؛ كم من الأشخاص وكم من الوقت سيتطلب إعادة البناء؟ أليس هذا لا يزال مثالية؟

إذا قُدِّر وفقًا لنمط إنتاج البرمجيات السابق، فإن هذا الشك واقعي جدًا. لكن بحلول عام 2026، أعتقد أن وكلاء البرمجة والهندسة البرمجية الممكّنة بالذكاء الاصطناعي قد غيّرت بالفعل قدرة البناء التي يمكننا حشدها. وكلاء البرمجة المذكورون هنا هم مساعدو برمجة بالذكاء الاصطناعي يمكنهم قراءة وكتابة الشيفرة، واستدعاء الأدوات، وتشغيل الاختبارات، ومواصلة العمل بناءً على التغذية الراجعة في بيئة تطوير. يحدد البناؤون الأهداف، ويحددون حدود الأمان، ويستخدمون هذه الأدوات لتنفيذ الأنظمة وفحصها، ويتحملون مسؤولية النتائج.

العمل الذي كان يتطلب سابقًا فرقًا كبيرة لتنفيذه وتكييفه وصيانته بشكل متكرر، يمكن الآن لفرق صغيرة أن تحاوله بهذا النهج الهندسي الجديد. فريق واحد يتولى طبقة واحدة، ويسلّم مكونات حول واجهات واضحة، ثم تفحصها فرق أخرى وتدمجها. إن تنظيم الحكم المعماري البشري، وقدرة التنفيذ لدى وكلاء البرمجة، والتحقق الأمني المستقل هو، في رأيي، مسار البناء الذي يستحق إعادة تقييم جادة.

يقدم بحث من Anthropic وPNNL مثالًا ملموسًا: في بيئة محاكاة محدودة للبنية التحتية الحرجة، أفاد الباحثون بأن إعادة بناء الهجوم قُصِّرت من ما قد يكون عدة أسابيع إلى نحو ثلاث ساعات. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) لا يمكنه إثبات أن فريقًا صغيرًا يمكنه بالفعل إعادة كتابة الصناعة بأكملها بأمان، لكنه يُظهر أن أعمال التحقق والهجوم والدفاع المكلفة سابقًا يمكن أن تحظى بظروف تكلفة جديدة.

أحد الأساليب التنظيمية التي يمكن البدء بها الآن هو البناء المشترك لمصنع ذكاء اصطناعي Build in Public. يكتب خبراء الصناعة والأكاديميون والممارسون علنًا المتطلبات ومواصفات القبول (spec)، موضحين ما الذي يجب حمايته، وأي العمليات مسموح بها، وما الحدود التي يجب أن تصمد بعد اختراق أي صلاحيات، ثم يحوّلون هذه المتطلبات إلى اختبارات قبول. تتولى مجموعات من وكلاء البرمجة أعمال البرمجة والاختبار وتصحيح الأخطاء الرئيسية؛ وتفحص فرق مختلفة التصاميم والنتائج، ويتحمل البشر مسؤولية الحكم والقبول.يمكن للمشاركين المساهمة بالأفكار والآلات وقوة الحوسبة وحصص استدعاء النماذج، أي رموز الذكاء الاصطناعي (AI tokens). يمكن لشركات الذكاء الاصطناعي والحوسبة السحابية أيضاً دعم هذا البناء العام عبر حصص النماذج وموارد الحوسبة والأدوات. يمكن للمواصفات وشيفرة النماذج الأولية وسير عمل الوكلاء (agent workflows) وبيئات الاختبار ونتائج التحقق أن تصبح جميعها بنية تحتية مشتركة الصيانة، مما يتيح للفريق التالي المتابعة مباشرة من هناك. الهدف هو بناء قدرة تطويرية ضمن مرافق عامة قابلة لإعادة الاستخدام وتقليل الاعتماد على وقت أي شخص أو أي فريق بعينه.

المهاجمون يستخدمون الذكاء الاصطناعي أيضاً، ولم يعد لدينا سبب لترك الدفاع في أساليب الإنتاج القديمة. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) لكن سرعة توليد الشيفرة ليست سوى نقطة البداية. فقط من خلال كتابة القيود بوضوح، وجعل الاختبارات قابلة للتشغيل مراراً وتكراراً، وجعل المكوّن قابلاً للفحص والاستبدال، يمكن تحويل قدرة الذكاء الاصطناعي إلى تحسين في البنية التحتية.

يعمل البنّاؤون المستقلون معاً بمساعدة وكلاء البرمجة وأدوات الذكاء الاصطناعي. ورشة الفضاء هي استعارة للبناء العام. أريد بشكل خاص أن أوجه هذا النداء إلى أولئك الذين ما زالوا يحبون البناء. "الهاكر" هنا يشير إلى شخص مستعد لاكتشاف كيفية عمل النظام، ومستعد لمشاركة ما يجده، ومستعد للسماح للآخرين باختبار عمله. تلك الروح دفعت الإنترنت إلى الأمام يوماً ما، واليوم يمكنها أن تدفع Crypto إلى الأمام أيضاً.

لا أعتقد أن هذه الصناعة تفتقر إلى الأذكياء، ولا أعتقد أن صناعتي Crypto والذكاء الاصطناعي لا تستطيعان إيجاد الموارد لدعم هذا العمل. الأصعب هو تنظيم المواهب والتمويل والمسؤولية المستدامة معاً. ينبغي أن تكون المؤسسات والشركات القادرة مستعدة لتحمل التكلفة طويلة الأجل للعمل الأساسي الذي لا يدر إيرادات مباشرة لكنه يفيد الجميع.

آمل أن يعمل الجميع معاً لبناء بنية تحتية تشفيرية مشتركة عالمياً. يمكن لشبكات وفرق مختلفة التعاون ضمن قيود أمنية مشتركة، كلٌّ ينفذ حلوله الخاصة ويختبر حلول الآخرين، ويمكن للمستخدمين الاختيار والترحيل. يمكن البدء بمكوّن واحد، لكن الاتجاه يجب أن يكون كبيراً بما يكفي لاستيعاب الصناعة بأكملها تبني معاً. يجب على جميع المشاركين، بما في ذلك ArcBlock، المساهمة بعمل قابل للتحقق.

ينبغي أن نبني معاً نوعاً من البنية التحتية حيث، حتى لو تم اختراق جزء ما، تظل للأصول حدودها، ويمكن للأنظمة الأخرى رفض الأخطاء، ولا يزال لدى المستخدمين مسارات للاسترداد والخروج. مستعيرين الاسم من Star Wars، هذا هو "أمل جديد" (A New Hope) الخاص بنا. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) يأتي الأمل من البنّائين العاديين المستعدين للتحرك، وأيضاً من هذه اللحظة التي تمكّن فيها وكلاء البرمجة وأساليب الهندسة الجديدة من تحمل المزيد من أعمال البناء.أود أن أوجه دعوة إلى بناة مشاريع مثل إيثيريوم، سولانا، بيتكوين، وXRP Ledger، وإلى منصات التداول مثل باينانس، كوين بيس، وكريكن، وكذلك إلى فرق المحافظ، البروتوكولات، أبحاث الأمن، الذكاء الاصطناعي، والحوسبة السحابية: ابدأوا بمشروع تجريبي محدد النطاق بوضوح، وأنتجوا بشكل مشترك تحسينات يمكن لفرق أخرى تبنّيها واختبارها.

الأسماء المذكورة هي أمثلة فقط، وبدون ترتيب معين. بغض النظر عن الحجم أو المسار التقني الذي تختارونه، أنتم مدعوون للمشاركة. تشمل هذه الدعوة أيضًا بناة المسارات التقنية التي انتُقدت في هذا المقال؛ إن تحسين أمان الأصول بشكل مشترك يستحق تجاوز حدود منظوماتنا البيئية respective.

أنا شخصيًا مستعد للمشاركة والمساهمة بممارساتنا الحالية في البنية التحتية، هندسة البرمجيات، والتعاون بالذكاء الاصطناعي. نحن مجرد فريق صغير في الصناعة، وما يمكننا فعله محدود. آمل أن نبدأ بنموذج أولي ومجموعة من الاختبارات القابلة للتكرار.

يمكن للأشخاص ذوي الخبرة التشغيلية العملية تقديم سيناريوهات هجوم منزوعة الحساسية، ويمكن لفرق المحافظ والبروتوكولات تنفيذ الحمايات، ويمكن للباحثين المستقلين محاولة تجاوزها. يتولى كل فريق الجزء الذي يستطيع التعامل معه، ويختبرون الحل بشكل مشترك ويقررون الخطوة التالية.

أنا مستعد للمشاركة في تنظيم متطلبات تقييد الأصول والاسترداد الواردة في هذا المقال في أول مواصفة عامة، وأنا مستعد أيضًا للمساهمة بالممارسات التقنية والهندسية ذات الصلة لبناء، مع المشاركين الآخرين، مصنع ذكاء اصطناعي عام لهذا المشروع التجريبي. لنختر أولًا مشكلة محددة جدًا: بمجرد اختراق مفتاح المعاملات اليومية، كيف يمكن still منع المهاجم من استنزاف المحفظة دفعة واحدة؟ اكتبوا نطاق الخسارة المسموح به، وصلاحية تعديل القواعد، وشروط الاسترداد في اختبارات القبول، ثم اجعلوا وكلاء التطوير ينفذون نموذجًا أوليًا، واجعلوا مجموعة أخرى من الوكلاء والباحثين المستقلين يبحثون عن مسارات تجاوز. يمكن أيضًا إضافة خوادم البيانات التي تعيد أرصدة غير صحيحة، والاسترداد بعد فقدان الجهاز، تدريجيًا إلى الاختبارات. ما يحققه النموذج الأولي، وأين يفشل، وما التبعيات المتبقية، يجب شرحها جميعًا بشكل عام، ويجب تحديد الخطوة التالية بناءً على الأدلة.

من يرغب في المشاركة مدعو لإعادة نشر أو اقتباس هذه المبادرة علنًا على X و@mave99a، والتحدث عن المشكلة التي يريد حلها، أو حالات هجوم منزوعة الحساسية، أو الموارد التي يمكنه المساهمة بها. آمل أن تجري المناقشة علنًا، حتى يراها المزيد من البناة وينضموا إليها.

لا يمكن أن يستمر الوضع في العملات المشفرة على هذا النحو. من هم مستعدون للعمل معًا، دعونا نتحرك الآن، بدءًا من تحسين واحد يمكن بناؤه ويصمد أمام الاختبار.بينانس، المنشور الرسمي للإعلان الأولي والتحديث الرسمي للتحقيق اللاحق، 2026-10-30؛ تحليل TRM متعدد السلاسل. تم التحقق من هذه المسودة اعتبارًا من 2026-10-30؛ قد تتغير حالة التحقيق والاسترداد. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)

ساتوشي ناكاموتو، بيتكوين: نظام نقد إلكتروني من نظير إلى نظير، 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)

يونيسواب، التكافؤ مع EVM في يونيتشين. تركّز المخاطر في التبعيات المشتركة هو حكم المؤلف في هذه المقالة، وليس استنتاجًا من ذلك المستند. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)

فيتاليك بوترين، سام ويلسون، أنسغار ديتريشس، لايت كلاينت، EIP-7702: تعيين الكود لحسابات EOA، أُنشئ في 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)

مينفنغ تشي، تشين وانغ، روي تشيانغ لي، تيان تشينغ تشو، شي بينغ تشن، هجوم التصيد EIP-7702، 2025-12-13، نسخة arXiv v1 الأولية؛ وليس تحديدًا لهذا الحادث الخاص ببينانس. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)

إيثيريوم، القيمة القصوى القابلة للاستخراج (MEV)، آليات الترتيب، الأنواع المختلفة، والآثار السلبية؛ عبارة "ينبغي إصلاحه كخطأ برمجي" هي موقف هندسي للمؤلف تجاه السلوك الذي يضر بالمستخدمين. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)

أرشيف أخبار PHP الرسمي لعام 2026؛ تحديث CISA بتاريخ 2026-10-26 لقائمة الثغرات المعروفة المستغلة، CVE-2026-109618، CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)

Safe، الحراس والوحدات، وصف الوظائف ومخاطر الأذونات. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)

Apple، Apple توسع خيارات الإصلاح بدعم الأجزاء الأصلية المستعملة، 2024-04-11؛ الوصف الحالي لدعم اقتران الأجزاء. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger، رد Ledger على هجوم الزرع العتادي، 2026-10، بيان البائع حول هجوم في سلسلة التوزيع؛ جو غراند، بحث الهندسة العكسية حول الزرع العتادي. لا تقدّم تقديرات الخسائر الشبكية غير المتحقق منها كاستنتاجات نهائية. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)

Coinkite، الحالة الأمنية الحالية لـ COLDCARD، تم الوصول إليه في 2026-10-30، سجل يُحدَّث باستمرار لحادث يوليو 2026 والمعالجة؛ الترقية وترحيل البذرة عمليتان منفصلتان. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)

ERC-4337: تجريد الحساب باستخدام Alt Mempool؛ Trezor، أسئلة شائعة حول SLIP39، الاسترداد العتبي، التوافق، ومخاطر عبارة المرور الإضافية. الآليات القائمة هي أساس للبناء، ولا تعني أن كل عملية نشر موثوقة. [↩](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، الذكاء الاصطناعي للدفاع عن البنية التحتية الحرجة، 2026-01-08، بحث في بيئة محدودة بالتعاون مع PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)

Anthropic، رسم خرائط التهديدات السيبرانية الممكّنة بالذكاء الاصطناعي، بحث على عينات إساءة فعلية. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)

Lucasfilm، حرب النجوم: أمل جديد (الحلقة الرابعة)، 1977؛ تستعير هذه المقالة العنوان وصورة الإنقاذ الذاتي المشترك. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)