#dusk $DUSK
بصراحة، أنا مصدوم. فقط 5 نقاط رغم أنني حصلت على 5K مشاهدة، يبدو هذا غير عادل جدًا ومخيّب للآمال.
أنشر اليوم بقلب مثقل… لكن قبل النشر، إليك سكالب سريع:
Long $PORTAL 📈
Short $CYS 📉
لا تنسَ أن تشكرني عندما تحجز الأرباح
كنت أعتقد في الأصل أن التخفيض الذي حدث على @Dusk يعني شيئًا واحدًا: خسارة الرهان وإعادة تشغيل العقدة
دليل الاسترداد يرسم خطًا أكثر حدة.
العقوبة اللينة يمكن أن توقف أهلية المُوفِّر (provisioner) وتحوّل جزءًا من رهانها النشط إلى رهان مُقيَّد. هذا الرهان ما زال ملكًا للمُشغّل ويمكن إلغاء تقييده.
العقوبات الصارمة تُطبّق على سلوك إجماع غير صالح بشكل مُثبت، مثل التصويت المتعارض أو التباس/تكافؤ (equivocation). يُحرق جزء من الرهان، ولا يمكن لاستئناف التشغيل أو إعادة الرهن أن يستعيده
هذا هو الفارق الذي عالق.
تتعامل Dusk مع الفشل في المشاركة والتناقض في المشاركة بشكل مختلف. قد يؤدي إصدار قديم، أو فترة توقف طويلة، أو مزامنة سيئة، أو حظر حركة الشبكة إلى فشل تشغيلي. توقيع رسائل متعارضة يعبر إلى سلوك يمكن للبروتوكول إثبات أنه كان غير صالح.
تحذير المفتاح المكرر يجعل الحدود عملية.
تشغيل نفس مفتاح الإجماع على عقدتين نشطتين يمكن أن يتسبب في أن توقع كلتا الآلتين رسائل غير متوافقة حتى لو كان المشغّل يعتقد أن العقدة الثانية مجرد نسخة احتياطية.
أنا أحب أن يبدأ الاسترداد بإصلاح إصدار البرمجية، والمزامنة، والاتصال، وإعدادات المفتاح قبل إنشاء وضع مُوفِّر جديد. إعادة الرهن دون إيجاد السبب ستضع فقط وضعًا جديدًا خلف نفس الإعداد المكسور
النموذج يعني أيضًا أن التكرار (النسخ الاحتياطي) يجب تصميمه بعناية. النسخة الاحتياطية التي تهدف لتحسين التوفر يمكن أن تُشكّل خطر “الحرق الصارم” إذا أصبحت نشطة بالمفتاح نفسه.
هل يؤدي فصل الفشل التشغيلي عن equivocation إلى فرض عقوبات أكثر عدلًا، أم يجعل إدارة مفاتيح الإجماع هي الجزء الأكثر قسوة في تشغيل مُوفِّر؟
سحب المُوفِّر على @Dusk يطرح سؤالًا مثيرًا للاهتمام
ما الأهم للحفاظ على أمان المدققين؟
بصراحة، أنا مصدوم. فقط 5 نقاط رغم أنني حصلت على 5K مشاهدة، يبدو هذا غير عادل جدًا ومخيّب للآمال.
أنشر اليوم بقلب مثقل… لكن قبل النشر، إليك سكالب سريع:
Long $PORTAL 📈
Short $CYS 📉
لا تنسَ أن تشكرني عندما تحجز الأرباح
كنت أعتقد في الأصل أن التخفيض الذي حدث على @Dusk يعني شيئًا واحدًا: خسارة الرهان وإعادة تشغيل العقدة
دليل الاسترداد يرسم خطًا أكثر حدة.
العقوبة اللينة يمكن أن توقف أهلية المُوفِّر (provisioner) وتحوّل جزءًا من رهانها النشط إلى رهان مُقيَّد. هذا الرهان ما زال ملكًا للمُشغّل ويمكن إلغاء تقييده.
العقوبات الصارمة تُطبّق على سلوك إجماع غير صالح بشكل مُثبت، مثل التصويت المتعارض أو التباس/تكافؤ (equivocation). يُحرق جزء من الرهان، ولا يمكن لاستئناف التشغيل أو إعادة الرهن أن يستعيده
هذا هو الفارق الذي عالق.
تتعامل Dusk مع الفشل في المشاركة والتناقض في المشاركة بشكل مختلف. قد يؤدي إصدار قديم، أو فترة توقف طويلة، أو مزامنة سيئة، أو حظر حركة الشبكة إلى فشل تشغيلي. توقيع رسائل متعارضة يعبر إلى سلوك يمكن للبروتوكول إثبات أنه كان غير صالح.
تحذير المفتاح المكرر يجعل الحدود عملية.
تشغيل نفس مفتاح الإجماع على عقدتين نشطتين يمكن أن يتسبب في أن توقع كلتا الآلتين رسائل غير متوافقة حتى لو كان المشغّل يعتقد أن العقدة الثانية مجرد نسخة احتياطية.
أنا أحب أن يبدأ الاسترداد بإصلاح إصدار البرمجية، والمزامنة، والاتصال، وإعدادات المفتاح قبل إنشاء وضع مُوفِّر جديد. إعادة الرهن دون إيجاد السبب ستضع فقط وضعًا جديدًا خلف نفس الإعداد المكسور
النموذج يعني أيضًا أن التكرار (النسخ الاحتياطي) يجب تصميمه بعناية. النسخة الاحتياطية التي تهدف لتحسين التوفر يمكن أن تُشكّل خطر “الحرق الصارم” إذا أصبحت نشطة بالمفتاح نفسه.
هل يؤدي فصل الفشل التشغيلي عن equivocation إلى فرض عقوبات أكثر عدلًا، أم يجعل إدارة مفاتيح الإجماع هي الجزء الأكثر قسوة في تشغيل مُوفِّر؟
سحب المُوفِّر على @Dusk يطرح سؤالًا مثيرًا للاهتمام
ما الأهم للحفاظ على أمان المدققين؟
- Fair penalty design
35%
- Consensus-key security
22%
- Reliable node uptime
13%
- All equally important
30%
23 الأصوات • تمّ إغلاق التصويت