#dusk $DUSK حادث أمني يخبرك بشيء لا يمكن لخارطة طريق أن تخبرك به: كيف تتصرف إحدى الفرق عندما ينكسر النظام فعليًا.
في 16 يناير، تمكن مهاجم من الحصول على وصول غير مصرح به إلى محفظة توقيع تُستخدم بواسطة خدمة الجسر الخاصة بـ Dusk. والأهم أن ما ذكره Dusk في تقرير ما بعد الحادث يقول إن هذا كان اختراقًا لمحفظة الجسر، وليس فشلًا في الإجماع أو استغلالًا لبروتوكول النواة.
لم يلفت انتباهي الحادث نفسه. بل ما جاء بعده.
بدلًا من مجرد استبدال المحفظة المخترَقة، أعاد Dusk تصميم بنية الجسر. تم فصل عملية التوقيع عن معالجة الأحداث. وتم فصل إطلاق الأموال عن إدخال الأحداث. يستخدم النظام الجديد دورة حياة معاملات صريحة، مع تقليل تعرّض محفظة ساخنة وتعزيز صلابة مضيف الجسر.
هذه استجابة أكثر إثارة من "لقد أصلحنا الخلل".
الدرس هنا أكبر من $DUSK . كانت الجسور لسنوات هي أكثر أجزاء بنية التشفير تعرضًا للاستغلال، تحديدًا لأنها تجمع قدرًا كبيرًا من السلطة الاقتصادية في مكان واحد.
للجسر سلطة اقتصادية، لذا يصبح التصميم التشغيلي جزءًا من نموذج الأمان. إذا استطاع مفتاح واحد مخترق أن يصل إلى أبعد مما ينبغي، فالمشكلة ليست في المفتاح وحده. بل في مقدار السلطة التي منحها له التصميم المعماري من الأساس.
وبالنسبة لمشروع يستهدف تمويلًا على السلسلة مُنظّمًا، فهذا الأمر مهم بشكل خاص. لن تسأل المؤسسات فقط ما إذا كانت البنية التحتية تعمل في الظروف العادية. سيسألن في النهاية ماذا يحدث عندما يسوء الأمر.
وهنا أعتقد أن إعادة تصميم Dusk تستحق الاهتمام.
ادعاءات الأمان سهلة النشر. أما تغيير البنية المعمارية بعد وقوع الفشل فهو أصعب.
هل ستمنح وزنًا أكبر لكيف يستجيب بلوكتشين بعد حادث، مقارنة بكل ما وعد به قبل وقوعه؟
@Dusk $DUSK #dusk
$EDEN