في 16 يناير 2026، قام شخص ما باختراق محفظة توقيع مرتبطة بخدمة جسر Dusk Network وبدأ في سحب الأموال. أعتقد أن الطريقة التي يتعامل بها مشروع مع لحظة كهذه تخبرك أكثر بكثير مما قد تقوله أي خارطة طريق.
وفقًا لمنشور ما بعد الحادث الذي نشرته Dusk نفسها، حصل المهاجم على وصول إلى المحفظة المسؤولة عن التعامل مع أحداث الترحيل بين Dusk وسلسلة متوافقة مع EVM عند الساعة 21:28 بتوقيت UTC، وسرق DUSK مباشرة ونقل جزءًا منها عبر الجسر قبل أن تُغلق الفريق الخدمة عند 23:12 بتوقيت UTC. وقد أدت هذه التدخلات إلى فشل محاولة جسر نهائية أكبر بكثير بشكل مباشر. أرقام Dusk الخاصة تُقدّر أن حوالي 10.9 مليون DUSK سُرقت عبر عدة معاملات، ولم يعبر عبر الجسر فعليًا سوى حوالي 1.9 مليون منها قبل أن يقطع إغلاق الخدمة المهاجم عن نقل الباقي. لم يكن ذلك فشلًا في الإجماع أو خللًا في بروتوكول Dusk الأساسي. بل كانت عملية اختراق لمسار توقيع واحد خفيف الوزن، كان يجمع التوقيع ومعالجة الأحداث واتصال الشبكة ضمن سطح تشغيل واحد. وهذا خيار تصميم اتُخذ في وقت مبكر بهدف السرعة، لكنه ركّز ثقةً مفرطة في مكان واحد. قامت Dusk بتقديم بلاغ للشرطة، وحفظت أثر المعاملات عبر السلسلتين، وأبلغت البورصات ذات الصلة فورًا.
لم تكن إعادة البناء التي تلت ذلك مجرد رقعة. تم فصل التوقيع عن معالجة الأحداث بالكامل؛ وأصبحت المعاملات تنتقل الآن عبر دورة حياة صريحة بدلًا من منطق الاسترداد الغامض؛ وتم تقييد تعرّض المحفظة الساخنة عبر تطبيق تحديثات يدوية للمحفظة الباردة؛ وتم تقوية بيئة الاستضافة عبر عزل خدمات صارم.
أعتقد أن الدرس الصادق هنا لا علاقة له بالتشفير على الإطلاق، بل كل ما يتعلق بتصميم التشغيل. لم تتوقف طبقة التسوية الأساسية لدى Dusk عن إنتاج الكتل بشكل صحيح طوال فترة الحادث بأكملها، وهذا أمر يستحق أن يُقال بوضوح بدل ترك الأمر يختلط على الناس.
شعر حاملو DUSK بهذا الخطر مباشرةً، وهذا بالضبط ما يجعل إعادة التصميم ضرورية وبالقدر الذي استلزمته.
@Dusk $DUSK #dusk
وفقًا لمنشور ما بعد الحادث الذي نشرته Dusk نفسها، حصل المهاجم على وصول إلى المحفظة المسؤولة عن التعامل مع أحداث الترحيل بين Dusk وسلسلة متوافقة مع EVM عند الساعة 21:28 بتوقيت UTC، وسرق DUSK مباشرة ونقل جزءًا منها عبر الجسر قبل أن تُغلق الفريق الخدمة عند 23:12 بتوقيت UTC. وقد أدت هذه التدخلات إلى فشل محاولة جسر نهائية أكبر بكثير بشكل مباشر. أرقام Dusk الخاصة تُقدّر أن حوالي 10.9 مليون DUSK سُرقت عبر عدة معاملات، ولم يعبر عبر الجسر فعليًا سوى حوالي 1.9 مليون منها قبل أن يقطع إغلاق الخدمة المهاجم عن نقل الباقي. لم يكن ذلك فشلًا في الإجماع أو خللًا في بروتوكول Dusk الأساسي. بل كانت عملية اختراق لمسار توقيع واحد خفيف الوزن، كان يجمع التوقيع ومعالجة الأحداث واتصال الشبكة ضمن سطح تشغيل واحد. وهذا خيار تصميم اتُخذ في وقت مبكر بهدف السرعة، لكنه ركّز ثقةً مفرطة في مكان واحد. قامت Dusk بتقديم بلاغ للشرطة، وحفظت أثر المعاملات عبر السلسلتين، وأبلغت البورصات ذات الصلة فورًا.
لم تكن إعادة البناء التي تلت ذلك مجرد رقعة. تم فصل التوقيع عن معالجة الأحداث بالكامل؛ وأصبحت المعاملات تنتقل الآن عبر دورة حياة صريحة بدلًا من منطق الاسترداد الغامض؛ وتم تقييد تعرّض المحفظة الساخنة عبر تطبيق تحديثات يدوية للمحفظة الباردة؛ وتم تقوية بيئة الاستضافة عبر عزل خدمات صارم.
أعتقد أن الدرس الصادق هنا لا علاقة له بالتشفير على الإطلاق، بل كل ما يتعلق بتصميم التشغيل. لم تتوقف طبقة التسوية الأساسية لدى Dusk عن إنتاج الكتل بشكل صحيح طوال فترة الحادث بأكملها، وهذا أمر يستحق أن يُقال بوضوح بدل ترك الأمر يختلط على الناس.
شعر حاملو DUSK بهذا الخطر مباشرةً، وهذا بالضبط ما يجعل إعادة التصميم ضرورية وبالقدر الذي استلزمته.
@Dusk $DUSK #dusk