#dusk $DUSK
استمرت عبارة "وضع الطوارئ" بالظهور في الورقة البيضاء الخاصة بـ Dusk، وكنت أتخطّاها. وعندما قرأت القسم فعليًا، اتّضح أن الآلية أكثر تحديدًا مما يوحي به الاسم.
إجماع Dusk العادي: كل جولة تعمل حتى حد أقصى قدره 50 تكرارًا (iteration). في كل خطوة، اقتراح (Proposal) والتحقق (Validation) والتصديق (Ratification)، توجد مهلة (timeout). إذا لم يتكوّن نصاب (quorum) قبل انتهاء المهلة، تنتقل الخطوة إلى ما بعدها، وفي النهاية يبدأ تكرار جديد. تسلسلي، ومحصور (bounded)، ويمكن التنبؤ به.
وضع الطوارئ مختلف. يتم تفعيله بعد 16 تكرارًا فاشلًا متتاليًا— حيث تعني الفشل أنه لم يتم الوصول إلى نصاب، غالبًا بسبب أن المدققين (validators) غير متصلين أو معزولين. بمجرد تفعيله: يتم تعطيل مهلات انتهاء الخطوات. تُبدأ تكرارات جديدة، لكن يبقى كل تكرار جارٍ مفتوحًا بدل أن يُغلق. تعمل عدة تكرارات مفتوحة بالتوازي. هذا يزيد فرصة إنتاج كتلة. كما يزيد أيضًا فرصة حدوث تفرعات (forks).
يتم حل التفرعات في وضع الطوارئ عبر اختيار الكتلة من أقل رقم تكرار. إذا تعذّر على الشبكة أيضًا تكوين كتلة، يكون الملاذ الأخير هو "كتلة الطوارئ": كتلة فارغة، دون معاملات، وموقّعة من كيان Dusk باستخدام مفتاحه العام العالمي. يقوم مقدمو الخدمة (Provisioners) الذين يملكون أغلبية الحصة بطلب ذلك.
فلماذا لا تقوم الشبكة بتشغيل وضع الطوارئ كلما أرادت أن تكون أسرع.
الوضع العادي يبادل بعض السرعة بوضوح نهائي (finality) أنظف. يزيد التكرارات المفتوحة المتزامنة من قابلية الاستمرار (liveness) تحت الضغط، لكن ذلك يُدخل تعقيدًا — وعودة الكتلة الفارغة هي تدخل مركزي: فالسلسلة تواصل التقدم، لكن كيان Dusk هو الذي يتحرك بها.
أجد حقًا أن سؤال تصميم "كتلة الطوارئ" أكثر إثارة للاهتمام — لأنه يعني أن ضمان قابلية الاستمرار يعتمد في النهاية على توفر كيان Dusk واستعداده للتوقيع. فسلامة البروتوكول واللامركزية تسحبان في اتجاهين مختلفين قليلًا.
ما لم أره مُشرحًا هو ما يحدث للمعاملات التي كانت قيد التنفيذ عندما تستبدل كتلة الطوارئ كتلة عادية — هل يتم إدراجها مجددًا في الجولة التالية أم يتم إسقاطها. @Dusk
$DUSK #dusk
استمرت عبارة "وضع الطوارئ" بالظهور في الورقة البيضاء الخاصة بـ Dusk، وكنت أتخطّاها. وعندما قرأت القسم فعليًا، اتّضح أن الآلية أكثر تحديدًا مما يوحي به الاسم.
إجماع Dusk العادي: كل جولة تعمل حتى حد أقصى قدره 50 تكرارًا (iteration). في كل خطوة، اقتراح (Proposal) والتحقق (Validation) والتصديق (Ratification)، توجد مهلة (timeout). إذا لم يتكوّن نصاب (quorum) قبل انتهاء المهلة، تنتقل الخطوة إلى ما بعدها، وفي النهاية يبدأ تكرار جديد. تسلسلي، ومحصور (bounded)، ويمكن التنبؤ به.
وضع الطوارئ مختلف. يتم تفعيله بعد 16 تكرارًا فاشلًا متتاليًا— حيث تعني الفشل أنه لم يتم الوصول إلى نصاب، غالبًا بسبب أن المدققين (validators) غير متصلين أو معزولين. بمجرد تفعيله: يتم تعطيل مهلات انتهاء الخطوات. تُبدأ تكرارات جديدة، لكن يبقى كل تكرار جارٍ مفتوحًا بدل أن يُغلق. تعمل عدة تكرارات مفتوحة بالتوازي. هذا يزيد فرصة إنتاج كتلة. كما يزيد أيضًا فرصة حدوث تفرعات (forks).
يتم حل التفرعات في وضع الطوارئ عبر اختيار الكتلة من أقل رقم تكرار. إذا تعذّر على الشبكة أيضًا تكوين كتلة، يكون الملاذ الأخير هو "كتلة الطوارئ": كتلة فارغة، دون معاملات، وموقّعة من كيان Dusk باستخدام مفتاحه العام العالمي. يقوم مقدمو الخدمة (Provisioners) الذين يملكون أغلبية الحصة بطلب ذلك.
فلماذا لا تقوم الشبكة بتشغيل وضع الطوارئ كلما أرادت أن تكون أسرع.
الوضع العادي يبادل بعض السرعة بوضوح نهائي (finality) أنظف. يزيد التكرارات المفتوحة المتزامنة من قابلية الاستمرار (liveness) تحت الضغط، لكن ذلك يُدخل تعقيدًا — وعودة الكتلة الفارغة هي تدخل مركزي: فالسلسلة تواصل التقدم، لكن كيان Dusk هو الذي يتحرك بها.
أجد حقًا أن سؤال تصميم "كتلة الطوارئ" أكثر إثارة للاهتمام — لأنه يعني أن ضمان قابلية الاستمرار يعتمد في النهاية على توفر كيان Dusk واستعداده للتوقيع. فسلامة البروتوكول واللامركزية تسحبان في اتجاهين مختلفين قليلًا.
ما لم أره مُشرحًا هو ما يحدث للمعاملات التي كانت قيد التنفيذ عندما تستبدل كتلة الطوارئ كتلة عادية — هل يتم إدراجها مجددًا في الجولة التالية أم يتم إسقاطها. @Dusk
$DUSK #dusk
