#dusk $DUSK @Dusk لطالما كنتُ أتساءل عن سيناريو معيّن: إذا جاء دور شخصٍ ما ليُنتج كتلة، لكن عقدته تعلّقت أو كانت غير متّصلة بالإنترنت بالضبط في ذلك الوقت، فهل تبقى الشبكة تنتظر سلفًا، أم توجد آلية جاهزة للانتقال التلقائي؟ هذه المرة خصّصتُ وقتًا للبحث في كيفية تصميم هذا الجزء ضمن عملية إجماع Dusk.
يمر إنتاج الكتل في Dusk بثلاث خطوات: أولًا، يقوم العقدة المُختارة بإقتراح كتلة. ثم تقوم مجموعة من العقد بالتوقيع والتصويت للتأكيد على صلاحية هذه الكتلة. بعد ذلك، تقوم مجموعة أخرى من العقد بإجراء جولة تصويت ثانية، وتقوم بتجميع نتائج الجولة السابقة، وبذلك يتم التوصّل رسميًا إلى إجماع. بعد اكتمال هذه الخطوات الثلاث تُعدّها جولة واحدة. إذا لم تتمكن العقدة التي اقترحت الكتلة من إرسالها بشكل طبيعي ضمن الوقت المحدد، أو لم تكتمل عملية التصويت بما يكفي من عدد الأصوات في المنتصف، فستنتهي هذه الجولة بفشل بسبب انتهاء المهلة (timeout)، ثم تنتقل إلى الجولة التالية عبر تكرار التدوير: يتم اختيار مجموعة جديدة من المشاركين لمحاولة مرة أخرى، وتستمر هذه الحلقة حتى يتحقق الإجماع فعليًا.
كنتُ أظن في البداية أن آلية "إعادة المحاولة بعد انتهاء المهلة" ثابتة وغير مرنة: في كل مرة تنتهي المهلة تنتظر مدة ثابتة محددة، ثم تعيد المحاولة. لكن بعد مراجعة سجلّ التطوير لديهم، وجدت أن الأمر ليس كذلك. إذ توجد نقطة تعديل مكتوبة صراحةً بعنوان "تنفيذ مهلة تكيّفية"، كما توجد أخرى تشير إلى "السماح بالرجوع إلى كتل من جولات أقل". وهذا يعني أن النظام لا يستخدم من البداية إلى النهاية نفس زمن الانتظار الثابت، بل يقوم بضبط نافذة الانتظار وفقًا للظروف الفعلية للشبكة، كما يتعامل مع حالات مثل: إذا كان هناك بالفعل قد تم قبول كتل من جولات أقدم من قبل المشاركين، فلن تكون هناك حاجة لإثقال النظام بمشقة إعادة المحاولة في الجولة اللاحقة.
بالنسبة لي، فإن هذه التفاصيل تعني حلًّا لمشكلة واقعية جدًا: عندما يزداد عدد العقد في الشبكة، دائمًا سيكون هناك من يعاني من تذبذب في الشبكة أو ينقطع اتصالُه. فإذا لم توجد هذه الآلية لإعادة الاختيار التلقائي وضبط المهلة بشكل ديناميكي، فقد تتعطل الشبكة في أي لحظة بسبب عدم استجابة عقدة واحدة سيئة الحظ. ومع ذلك، لم أجد بيانات تاريخية محددة—مثلًا، حتى الآن: كم مرة تم فعليًا تفعيل آلية "انتهاء المهلة/إعادة الاختيار" على الشبكة الرئيسية؟ وكم يستغرق الأمر في المتوسط بعد التفعيل ليعود إنتاج الكتل إلى وضعه الطبيعي؟ لم أتمكن حتى الآن من العثور على سجلات تشغيل يمكن الاستناد إليها للتحقق
يمر إنتاج الكتل في Dusk بثلاث خطوات: أولًا، يقوم العقدة المُختارة بإقتراح كتلة. ثم تقوم مجموعة من العقد بالتوقيع والتصويت للتأكيد على صلاحية هذه الكتلة. بعد ذلك، تقوم مجموعة أخرى من العقد بإجراء جولة تصويت ثانية، وتقوم بتجميع نتائج الجولة السابقة، وبذلك يتم التوصّل رسميًا إلى إجماع. بعد اكتمال هذه الخطوات الثلاث تُعدّها جولة واحدة. إذا لم تتمكن العقدة التي اقترحت الكتلة من إرسالها بشكل طبيعي ضمن الوقت المحدد، أو لم تكتمل عملية التصويت بما يكفي من عدد الأصوات في المنتصف، فستنتهي هذه الجولة بفشل بسبب انتهاء المهلة (timeout)، ثم تنتقل إلى الجولة التالية عبر تكرار التدوير: يتم اختيار مجموعة جديدة من المشاركين لمحاولة مرة أخرى، وتستمر هذه الحلقة حتى يتحقق الإجماع فعليًا.
كنتُ أظن في البداية أن آلية "إعادة المحاولة بعد انتهاء المهلة" ثابتة وغير مرنة: في كل مرة تنتهي المهلة تنتظر مدة ثابتة محددة، ثم تعيد المحاولة. لكن بعد مراجعة سجلّ التطوير لديهم، وجدت أن الأمر ليس كذلك. إذ توجد نقطة تعديل مكتوبة صراحةً بعنوان "تنفيذ مهلة تكيّفية"، كما توجد أخرى تشير إلى "السماح بالرجوع إلى كتل من جولات أقل". وهذا يعني أن النظام لا يستخدم من البداية إلى النهاية نفس زمن الانتظار الثابت، بل يقوم بضبط نافذة الانتظار وفقًا للظروف الفعلية للشبكة، كما يتعامل مع حالات مثل: إذا كان هناك بالفعل قد تم قبول كتل من جولات أقدم من قبل المشاركين، فلن تكون هناك حاجة لإثقال النظام بمشقة إعادة المحاولة في الجولة اللاحقة.
بالنسبة لي، فإن هذه التفاصيل تعني حلًّا لمشكلة واقعية جدًا: عندما يزداد عدد العقد في الشبكة، دائمًا سيكون هناك من يعاني من تذبذب في الشبكة أو ينقطع اتصالُه. فإذا لم توجد هذه الآلية لإعادة الاختيار التلقائي وضبط المهلة بشكل ديناميكي، فقد تتعطل الشبكة في أي لحظة بسبب عدم استجابة عقدة واحدة سيئة الحظ. ومع ذلك، لم أجد بيانات تاريخية محددة—مثلًا، حتى الآن: كم مرة تم فعليًا تفعيل آلية "انتهاء المهلة/إعادة الاختيار" على الشبكة الرئيسية؟ وكم يستغرق الأمر في المتوسط بعد التفعيل ليعود إنتاج الكتل إلى وضعه الطبيعي؟ لم أتمكن حتى الآن من العثور على سجلات تشغيل يمكن الاستناد إليها للتحقق