الساعة الواحدة صباحًا أنهيت إعادة فحص حادثة جسر Dusk وتحليل AEGIS معًا حتى آخر لحظة، وقبل أن أغلق الصفحة شعرت فجأة بشيء من الخوف: قبل أيام قليلة كدت أقبل خيارين “سهليْن جدًا” — “ليس ثغرة L1 لذلك لا شيء” أو “بما أن الجسر حدثت له مشكلة، إذن فالسلسلة كاملة غير آمنة”.
الواقع أعقد بكثير من الشعارات. في 16 يناير 2026، حصل المهاجمون على صلاحيات محفظة التوقيع المستخدمة لخدمة جسر Dusk إلى EVM.
تذكر إعادة الفحص الرسمية بوضوح أن الأمر ليس فشلًا في الإجماع، ولا أن بروتوكول طبقة Dusk الأساسية تم اختراقه، بل أن مسار التوقيع الخاص بالجسر تم اختراقه. كان التصميم القديم يضغط مسار التشغيل الذي يضم محفظة التوقيع ومعالجة الأحداث والاتصال بالشبكة في “خط واحد” — بمجرد أن تُسلب السيطرة على المفتاح، يصبح نطاق ما يمكن للمهاجمين الوصول إليه كبيرًا جدًا.
والأمر المثير للاهتمام أن نقطة الإصلاح ليست مجرد “استبدال مفتاح”. فالتصميم الجديد يفصل استقبال الأحداث، والاحتفاظ بالمهام بشكل دائم، وإطلاق الأموال، وجهاز التوقيع المخصص. تتم إدارة المعاملات عبر آلة حالات مثل seen وsubmitted وcompleted وfailed وstuck؛ وتحتفظ المحفظة الساخنة فقط برصيد يلزم مؤقتًا، وعندما لا تكفي الأموال يتم الإيقاف، ثم يَقوم صندوق بارد بالإمداد يدويًا.
سأضرب مثالًا بسيطًا: تحويل شاحنة نقل أموال مملوءة بالكامل إلى نظام مقصورات وحصص وحدود وتصاريح تدريجية.
أما AEGIS فهو قصة أخرى: دفعت عملية التدقيق الداخلي 39 إجراء إصلاح، تم تصنيف 7 منها على أنها “مستوى حرج”، وتشمل الأسباب الجذرية مثل عزل VM وإلغاء التسلسل (anti-deserialization) وربط رسوم Phoenix بالاسترداد، وقيام BLS بتزوير. وتقول الجهة الرسمية إنه لم يتم العثور حتى الآن على أدلة على استغلال هذه المشكلات الحرجة سابقًا. لا يمكن خلط حدث الجسر وAEGIS في نفس الثغرة، ولا يمكن اعتبار أن المخاطر انعدمت فقط لأنهما تم إصلاحهما.
لذلك حُكمي الآن هو: ليست ثغرة إجماع، لا يعني ذلك أنها ليست مشكلة أمان للمستخدم؛ إعادة الفحص العامة تستحق الإشادة، لكنها لا تغني عن الاستقرار طويل الأمد والتحقق من طرف ثالث.
عندما تقيّمون سلسلة ما، هل تحسبون الجسر والعمليات التشغيلية ضمن درجة أمان البروتوكول؟
#dusk $DUSK @Dusk
الواقع أعقد بكثير من الشعارات. في 16 يناير 2026، حصل المهاجمون على صلاحيات محفظة التوقيع المستخدمة لخدمة جسر Dusk إلى EVM.
تذكر إعادة الفحص الرسمية بوضوح أن الأمر ليس فشلًا في الإجماع، ولا أن بروتوكول طبقة Dusk الأساسية تم اختراقه، بل أن مسار التوقيع الخاص بالجسر تم اختراقه. كان التصميم القديم يضغط مسار التشغيل الذي يضم محفظة التوقيع ومعالجة الأحداث والاتصال بالشبكة في “خط واحد” — بمجرد أن تُسلب السيطرة على المفتاح، يصبح نطاق ما يمكن للمهاجمين الوصول إليه كبيرًا جدًا.
والأمر المثير للاهتمام أن نقطة الإصلاح ليست مجرد “استبدال مفتاح”. فالتصميم الجديد يفصل استقبال الأحداث، والاحتفاظ بالمهام بشكل دائم، وإطلاق الأموال، وجهاز التوقيع المخصص. تتم إدارة المعاملات عبر آلة حالات مثل seen وsubmitted وcompleted وfailed وstuck؛ وتحتفظ المحفظة الساخنة فقط برصيد يلزم مؤقتًا، وعندما لا تكفي الأموال يتم الإيقاف، ثم يَقوم صندوق بارد بالإمداد يدويًا.
سأضرب مثالًا بسيطًا: تحويل شاحنة نقل أموال مملوءة بالكامل إلى نظام مقصورات وحصص وحدود وتصاريح تدريجية.
أما AEGIS فهو قصة أخرى: دفعت عملية التدقيق الداخلي 39 إجراء إصلاح، تم تصنيف 7 منها على أنها “مستوى حرج”، وتشمل الأسباب الجذرية مثل عزل VM وإلغاء التسلسل (anti-deserialization) وربط رسوم Phoenix بالاسترداد، وقيام BLS بتزوير. وتقول الجهة الرسمية إنه لم يتم العثور حتى الآن على أدلة على استغلال هذه المشكلات الحرجة سابقًا. لا يمكن خلط حدث الجسر وAEGIS في نفس الثغرة، ولا يمكن اعتبار أن المخاطر انعدمت فقط لأنهما تم إصلاحهما.
لذلك حُكمي الآن هو: ليست ثغرة إجماع، لا يعني ذلك أنها ليست مشكلة أمان للمستخدم؛ إعادة الفحص العامة تستحق الإشادة، لكنها لا تغني عن الاستقرار طويل الأمد والتحقق من طرف ثالث.
عندما تقيّمون سلسلة ما، هل تحسبون الجسر والعمليات التشغيلية ضمن درجة أمان البروتوكول؟
#dusk $DUSK @Dusk