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