#dusk لقد أعدتُ تفكيك آلية العقوبات في Dusk، ووجدتُ أن الأمر الذي يُساء فهمه بسهولة ليس شدة العقوبة، بل أن "العقوبة اللينة" و"العقوبة الصارمة" ليسا الشيء نفسه إطلاقًا. يوضح المستند الرسمي هذا الفرق بجلاء: فالعقوبة اللينة تستهدف فشل المشاركة في الإجماع، مثل عدم قيام الـProvisioner بإنتاج كتلة أو التصويت ضمن الوقت المحدد؛ أما العقوبة الصارمة فتستهدف السلوك الخبيث القابل للإثبات — مثل التوقيع على مقترحات متضاربة عند الارتفاع نفسه، أو تشغيل مفتاح إجماع واحد على عدة عقد في الوقت نفسه.
الفارق في العواقب بينهما هائل. فالعقوبة اللينة تؤدي إلى تعليق أهلية الـ$SNDKB Provisioner، ونقل جزء من الـactive stake إلى الـlocked stake. انتبهوا، فالـlocked stake لا يزال مملوكًا لصاحبه، لكنه فقط لا يشارك مؤقتًا في الإجماع ولا يدرّ عائدًا. وهذا يختلف تمامًا عن اقتطاع الأصل مباشرةً. أما العقوبة الصارمة فهي التي تحرق جزءًا من DUSK فعليًا.
المستخدمون القادمون من بيئة ETH لديهم تصور حدسي عن الـslashing في ETH2.0، لكن Dusk يضيف طبقة عازلة من العقوبة اللينة. إنها تمنح المشغّل نافذة لتصحيح الخطأ — فإذا فاتتك عملية التصويت بسبب تقلبات الشبكة، فلن تُحرق عملاتك مباشرة، لكنك ستُقصى مؤقتًا عن المشاركة. أما إذا تعمّدت السلوك الخبيث، فالأمر مختلف تمامًا. $SPCXB
وبالنسبة لحاملي $DUSK العاديين، فإن أهم ما يجب مراقبته عند تشغيل عقدة ليس معدل العائد، بل: "هل مفتاح الإجماع الخاص بي يعمل فقط على جهاز واحد فريد؟" تؤكد الوثائق على هذه النقطة مرارًا، لكن كثيرين يظنون أن إعداد تحويل تلقائي للأعطال على خادم سحابي أمر مريح، ثم يتضح أن المثيل القديم لم يُغلق بالكامل، بينما بدأ المثيل الجديد بالفعل، فأصبح الاثنان نشطين في الوقت نفسه — وهذا يفعّل العقوبة الصارمة مباشرة.
لذلك أرى أن @Dusk ما ينبغي عرضه مستقبلًا في لوحة التشغيل ليس APY، بل حالة صحة العقدة، وفحص تفرد مفتاح الإجماع، وما إذا كان هناك خطر عقوبة لينة. لا ينبغي للـstaker أن يعود إلى الوثائق فقط بعد وقوع المشكلة.
#dusk @Dusk