كنت أرى سابقًا أن مشكلة أمان @Dusk Dusk مجرد ثغرة نقطة واحدة، لكن بعد قراءة تحليل AEGIS اتضح لي أن المخاطر تمتد عبر أربع طبقات حدود. تم الإفصاح عن Dusk في مارس 2026، وقام AEGIS بإصلاح 39 مشكلة في التدقيق الداخلي، منها 7 مسائل بتصنيف Critical؛ أما الأسباب الجذرية فكانت موزعة بين أسماء مستعارة لآلة Piecrust الافتراضية، وإلغاء تسلسل على جانب المضيف، كما شملت ربط استرداد رسوم Phoenix وبناء توقيع BLS، مما أثر على حتمية التنفيذ وذاكرة العقد وسلامة سلسلة الإمداد ومصادقة الإجماع.

قسمتها إلى أربع بوابات تحكم في المخاطر تخص جهة المعاملات: عزل الحالة أثناء وقت التشغيل، والتحقق من البيانات الخارجية قبل التحليل، وربط استرداد الرسوم بالمستندات الأصلية، واعتماد توقيعات الإجماع مع تعيين منحنيات موثوق. أعاد AEGIS تصميم إدارة الجلسات وملكية المثيلات، كما تم فحص اتساق الرسوم في mempool وفي فحص VM معًا، وتم تغيير المسار الآمن لـ BLS إلى نمط RFC 9380 الخاص بـ hash-to-curve مع فصل المجالات.

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

#dusk $DUSK