يتجادل مطورو Ethereum الأساسيون حول العملية والجدول الزمني لـ Fusaka

ركز اجتماع Ethereum الأخير All Core Devs على العملية وليس فقط على الكود: تحديدًا ما إذا كان يجب الالتزام بفترة الثلاثين يومًا المعلنة مسبقًا بين إصدارات العملاء وأول تفرع لشبكة الاختبار مع تقدم ترقية Fusaka. دفع بعض المشاركين إلى إعادة التأكيد على هذا الالتزام حتى يكون لدى فرق البنية التحتية والتطبيقات الوقت الكافي للتكيف؛ بينما جادل آخرون بضرورة المرونة لتجنب تأخير خارطة الطريق بشكل أوسع.

دارت المناقشة في ظل نتائج مختلطة على devnet. في Devnet-3، استغرقت تجربة عدم النهائية المخطط لها وقتًا أطول، حسبما أفاد Barnabas Busa من فريق Dev Ops. قال: "كنا نريد أن نجري التجربة لمدة يومين تقريبًا في البداية، والآن وصلنا إلى اليوم الخامس"، مشيرًا إلى أن المشاركة انخفضت ثم عادت لتتجاوز 50%. تتطلب النهائية موافقة أكثر من ثلثي إجمالي الحصة الفعالة.

وعلى النقيض من ذلك، تعافت شبكة اختبار منفصلة بسرعة بعد إعادة تشغيل منسقة: "تعافت السلسلة في غضون ساعتين تقريبًا، على ما أعتقد"، قال Busa. هذا التمرين يختبر مدى تفاعل المتغيرات في حادثة حية، مما يمكن أن يساعد Ethereum على التعافي في الأزمات.

اقرأ المزيد: ترقية Fusaka في Ethereum قد تواجه تأخيرًا

مع اقتراب الإصلاحات في الأيام القادمة، الخطة على المدى القريب هي استعادة Devnet-3 إلى كامل صحته، إعادة تشغيل الاختبار ثم إطلاق Devnet-5.

لكن النقطة الأكثر إثارة للجدل كانت الانضباط في جدولة الشبكات العامة. أكد Lightclient على الوعد القائم: "ينص على 30 يومًا قبل أول شبكة اختبار." وحذر من تغيير الأهداف لمجرد الراحة، بناءً على تقييم المطورين الأساسيين للوقت الذي تحتاجه الفرق الأخرى غير الحاضرة في الاجتماع.

الاهتمام العملي هو كيفية تحسين وتيرة التفرعات الصلبة. تقليص الفجوات بين الاختبارات يمكن أن يسرع التفرعات، لكنه يزيد من خطر إصدار الفرق التابعة لتحديثات متسرعة. الحجة المضادة هي أن خطوط الإنتاج الطويلة تؤخر كل شيء آخر في قائمة الانتظار، وهو ما قد لا يرضي مجتمع Ethereum الأوسع.

قال Lightclient: "لا أعتقد أنه يجب علينا اختيار الجداول الزمنية بناءً على ما يريده المجتمع بالضرورة. الأشخاص الذين يصدرون البرمجيات قالوا إنهم يريدون 30 يومًا لتقديم برمجيات عالية الجودة سيستخدمها المجتمع."

ومع ذلك، انجرف النقاش الحاد نوعًا ما نحو الالتزام بالعملية المكتوبة ما لم يطلب أصحاب المصلحة تغييرًا صريحًا.

كان هناك أيضًا إحباط من إعادة مناقشة نفس السؤال في كل دورة. قال Lightclient: "أعتقد فقط أنه من السيء جدًا أن نستمر في السماح بتغيير القرارات"، مشيرًا إلى أن مطوري التطبيقات وL2s ليسوا عادةً في الاجتماعات الأساسية ويعتمدون على فترات زمنية متوقعة لجدولة إصداراتهم الخاصة.

في الوقت الحالي، التوافق هو المضي قدمًا كما لو أن فترة الثلاثين يومًا لا تزال سارية، مع السعي بنشاط للحصول على مدخلات جديدة، حسبما قال المنسق Tim Beiko. "يجب أن نعد الجدول الزمني بما هو موجود في وثيقة [العملية] ثم بالتوازي نتحقق مع أصحاب المصلحة المتأثرين." إذا كان هناك دعم واسع حقًا لمسار أسرع، فسيقوم الفريق بتوثيقه رسميًا.