تابعتُ كيف تمت إزالة مُدقق DUSK من المجموعة النشطة على شبكة الاختبار (testnet). لم يتم اختراقه. لم يتم خصمه. فقط تمت إزالته. كان السبب هو قابلية الإتاحة (liveness): فقد فاتته الكثير من أصوات الجـاهزية النهائية (finality) ضمن نافذة مدتها 28 ساعة.

لقد عمل النظام تمامًا كما صُمّم. هذا ما أقلقني.

لم يفقد المُدقق رصيده المرهون. لم تكن هناك عقوبة تشفيرية. ولا مفتاح خاص مكشوف. فقط خروجٌ هادئ من جولة الإجماع. وهذه هي النقطة التي علقت في ذهني: نافذة الحبس (jailing) تُقاس بالنسبة إلى قيمة StartHeight التي تتم إعادة ضبطها كل مرة يعود فيها المُقدّم (provider) للانضمام. غادر لفترة قصيرة، عد، أعد ضبط الساعة، كرر. يمكن للمشغل غير الموثوق المزمن أن يتفادى الإزالة الدائمة إلى الأبد عبر عدم البقاء دون اتصال مدة كافية لتفعيل العقوبة الكاملة. مسار الإنفاذ (enforcement) الناعم هو المسار الذي فيه الثغرة.

كنتُ أفكر في تلك الثغرة بينما كانت جماعة DUSK تناقش ما إذا كان يجب التعامل مع مُقدمي الجاهزية النهائية (finality providers) كـبنية تحتية أم كشركاء. قال أحدهم في الدردشة: "إذا كانت العقوبة على عدم الاعتمادية هي مهلة (timeout)، فإن عدم الاعتمادية ليست إلا استراتيجية مع خطوات إضافية." لم يضحك أحد. لأن الجميع يعرفون أن مُدققًا يعيد ضبط ساعة حبسه الخاصة لا يخرق القواعد. إنه يُراوغ إيقاع الإنفاذ.

هنا الفجوة بين الأمن التقني والأمن العملي. الزناد التشفيري لإعادة التوقيع المزدوج (double-signing) مطلق، ولا هوادة فيه، وآلي. الزناد الاجتماعي للتكاسل هو آلة حالات (state machine) مع زر إعادة ضبط. أحدهما يحمي الشبكة من الخبث. والآخر يحميها من الإهمال. وفي الوقت الحالي، فإن زر إعادة الضبط في يد المشغل نفسه الذي يُفترض أن يُقيَّده.

#dusk $DUSK @Dusk $EDEN $AKE