ملخص الاجتماع الأخير لمطوري Ethereum الأساسيين: #12启动 Devnet ، عملية تخطيط الترقية

في 30 نوفمبر 2023 ، اجتمع مطورو Ethereum على Zoom لحضور اجتماع إجماع جميع المطورين الأساسيين (ACDC) #122. المكالمة الجماعية ل ACDC هي سلسلة من الاجتماعات نصف الأسبوعية يديرها الباحث في مؤسسة Ethereum Danny Ryan حيث يناقش المطورون وينسقون التغييرات على طبقة إجماع Ethereum (CL). ركز المطورون هذا الأسبوع على آخر التطورات في اختبار Cancun / Deneb ، بما في ذلك:

· إطلاق Devnet # 12: يجري اختبار برنامج عميل Teku و Lodestar و Lighthouse على Devnet # 12 ، بالإضافة إلى جميع برامج عميل طبقة التنفيذ (EL). يتوقع فريق Prysm أن يكون برنامجهم جاهزا للاختبار في غضون أسبوعين إلى ثلاثة أسابيع على أحدث Devnet.

· مشكلة خروج المدقق على Devnet #11: في Devnet #11 ، حدد المطورون مشكلة تتعلق بخروج المدقق ، والتي يتم حلها حاليا بواسطة فريق عميل Nimbus. سيستمر Devnet # 11 في العمل بشكل طبيعي حتى يتم حل المشكلة.

· توضيح مواصفات الشبكة: ناقش المطورون توضيح مواصفات طلبات "BlockByRoot" و "BlobSidecarsByRoot" ، مع توضيح ما إذا كان يجب أن تستجيب عقد طبقة الإجماع (CL) لهذه الطلبات بترتيب معين.

بالإضافة إلى تحديث Cancun / Deneb ، ناقش المطورون بعض مشكلات العملية التي أثارها تيم بيكو ، رئيس دعم البروتوكول في مؤسسة Ethereum ، لتحسين تنسيق ترقية Ethereum.

ديفنت # 12

في يوم الأربعاء 30 نوفمبر 2023 ، تم إطلاق ترقية Cancun / Deneb رسميا على Devnet # 12. قال ماريو فيغا من فريق اختبار مؤسسة Ethereum إنه "لم يتم تحديد أي مشكلات رئيسية حتى الآن" في عملاء CL الثلاثة الذين يعملون حاليا على شبكة الاختبار. ذكر برنابا بوسا ، مهندس DevOps في المؤسسة ، أن هناك ما مجموعه 225 مدققا منتشرين عبر ثلاث عقد بين Lighthouse و Teku و Lodestar. نظرا لاستقرار Devnet # 12 ، سأل Parithosh Jayanthi ، مهندس DevOps في المؤسسة ، المطورين عما إذا كان ينبغي عليهم البدء في التخطيط لشوكة ظل Goerli لإجراء مزيد من الاختبارات على Cancun / Deneb. ومع ذلك ، بالنظر إلى أن Prysm ، عميل CL الأكثر شعبية في الوقت الحالي ، لم ينضم بعد إلى Devnet # 12 ، فقد قرر المطورون تعليق خطط شوكة الظل Goerli حتى يصبح برنامج عميل Prysm جاهزا للاختبار. يقترح بيكو الانتقال إلى شوكة الظل Goerli في وقت ما قبل نهاية العام. نظرا لاستقرار Devnet # 12 ، يتم تعليق الخطط حتى يصبح برنامج عميل Prysm جاهزا للاختبار.

ديفنت # 11

يشارك مطور Nimbus ، الذي يحمل اسم الشاشة "Dustin" ، تفاصيل مشكلة Devnet # 11 التي يعمل عليها فريقه. تم اكتشاف هذه المشكلات لأول مرة عندما خرج مطور من ثلث مدققي Devnet #11 للاستخدام على Devnet #12. يسأل ريان داستن عما إذا كان بإمكانه اكتشاف هذه المشكلات من خلال اختبارات إضافية. ورد داستن بأن طبيعة هذه الأخطاء، في رأيه، ناجمة عن تفاصيل التنفيذ خارج نطاق مواصفات توافق الآراء. ومع ذلك ، فهو يعترف أيضا بوجود "توتر واضح" بين كتابة برنامج العميل بدقة وفقا لمواصفات CL من أجل اختبار فوائد التغطية والخوض في المناطق الرمادية للمواصفات من أجل تحقيق أداء أفضل للعقدة.

"أعني أن المزيد من الاختبارات أمر جيد دائما ، ولكن معرفة كيفية دمج المزيد من الوظائف من جانب العميل بشكل أكثر منهجية في الاختبارات الجارية ربما يكون أكثر آلية ، سواء كان ذلك باستخدام Hive أو Kurtosis أو أي شيء آخر. أعتقد أنه سيكون من المفيد بالتأكيد أن يتم حل هذه المشكلات أو يمكن تقسيم الأمور بشكل جيد بما يكفي لتكون قادرة على دمج المزيد من هذه المهام "، مضيفا أن التحدي الآخر الذي يجب على مطوري CL التفكير في معالجته هو معرفة مستوى التفاصيل التي يجب أن تمليها مواصفات CL وتوحيد سلوك العقدة. "التحدي الآخر هنا هو درجة التوحيد القياسي ، وهي في الحقيقة ليست مجرد قضية هندسة برمجيات ، إلى أي مدى يجب أن يكون السلوك موحدا؟" سأل داستن. يجتاز جميع عملاء CL الاختبارات التي تتحقق من السلوك الأساسي ، ولكن السلوك خارج نطاق هذه الاختبارات غامض. "هل هذه أشياء غامضة عمدا؟ ما الذي يجب أن يكون واضحا حقا من خلال القاعدة وما الذي يجب أن يكون غامضا عمدا؟ سأل داستن.

على الأقل ، وافق المطورون على إضافة المزيد من الاختبارات إلى Devnets وشبكات الاختبار المستقبلية لعدد كبير من مخارج المدققين في Cancun/Deneb. يقر ريان أيضا بأن هناك مجالا لتغطية اختبار أكثر صرامة وشمولية عندما يتعلق الأمر بعملاء CL وتنفيذ مواصفات CL. اقترح Vega أن يقوم Dustin بإنشاء منشور HackMD يوضح بالتفصيل مخاوفه ومناقشة الموضوع في مكالمة اختبار Cancun / Deneb التالية. وأضاف Jayanthi أنه استنادا إلى بعض المشكلات التي تم تحديدها مؤخرا في Cancun / Deneb Devnets ، هناك حاجة واضحة للمطورين للحصول على أدوات يمكنها تنفيذ عدد معين من السلوكيات المتعلقة بالتكامل على السلسلة بشكل منهجي ، مثل عمليات سحب ETH المخزنة ، وعمليات سحب المدقق ، وما إلى ذلك. للقيام بذلك ، يوصي Jayanthi ببناء مثل هذه الأداة باستخدام مزيج من مجموعات اختبار Hive و Kurtosis.

وفي معرض حديثه عن أداة الاختبار الجديدة لترقية Cancun/Deneb، أشار Jayanthi إلى أن المطورين يعملون على أداة لتنشيط عمليات لم شمل السلسلة بشكل موثوق على شبكات Devnets وشبكات الاختبار. لضمان عمل هذه الأداة ، طلب Jayanthi من المطورين مشاركة تفاصيل الأخطاء المعروفة التي أدت إلى عمليات إعادة تنظيم السلسلة على Ethereum. أوضح Jayanthi أنه سيستخدم هذه الأخطاء لاختبار الأداة والتأكد من أنها يمكن أن تحدد بشكل موثوق وقت حدوث إعادة التنظيم ومتى يتم حلها.

توضيح مواصفات الشبكة

ناقش المطورون بإيجاز طلب سحب مفتوح اقترحه الباحث في مؤسسة Ethereum Justin Traglia فيما يتعلق بترتيب الردود التي يجب على عملاء CL إعادتها عند تلقي طلب "BlockbyRoot" أو "BlobSidecarsByRoot". يسأل ريان كيف تقوم فرق عملاء CL المختلفة بتنفيذ هذه الميزة بالفعل. لم يجب أي من المطورين في المكالمة على هذا السؤال. اقترح ريان إحياء النقاش حول قناة Ethereum Research and Development Discord لإشراك مجموعة واسعة من مطوري العملاء. يقر ريان بوجود غموض في مواصفات الطلبين ، والتي "قد تكون سبب مشاكل وحالات حافة غريبة" و "تستحق التوضيح والفرز" ، كما يؤكد ريان.

ذكر ريان أيضا أنه سيصدر إصدارا جديدا من مواصفات CL في الأيام القليلة المقبلة. يضيف أحدث إصدار بشكل كبير مواصفات حول متى يمكن لعميل CL توفير كتل وكتل عبر طلب RPC "byRoot". لمزيد من المعلومات الأساسية حول مناقشة استرداد الكتل والكتل المفقودة عبر طلبات RPC "byRoot" ، يرجى الرجوع إلى سجل المكالمات السابق. يؤكد Ryan أن الإضافات الجديدة إلى مواصفات CL المضمنة في أحدث إصدار لن يكون لها أي تغييرات جذرية في الكود تؤثر على الكود للمدققين الذين يعملون بالفعل على Devnet # 11 أو # 12.

عملية تخطيط الترقية

بعد ذلك ، ناقش المطورون عناصر العملية المختلفة التي اقترحتها Beiko. قال Beiko إن منشور مدونة يحذر مستخدمي Goerli testnet من الإهمال الوشيك في غضون 3 أشهر من تنشيط ترقية Cancun / Deneb على Goerli ، أو 1 شهر بعد تنشيط الترقية على شبكة Ethereum الرئيسية ، أيهما لاحق ، سيتم نشرها على مدونة Ethereum Foundation في 30 نوفمبر. منذ انتهاء المكالمة ، تم نشر منشور المدونة أعلاه ويمكن قراءته هنا.

يقترح Beiko إنشاء مجلد خاص بالترقية ضمن مستودع Ethereum "pm" لتنظيم الملفات المختلفة المتعلقة بترقية معينة في مجلد واحد لاستخدامها لاحقا. وافق المطورون في المكالمة على اقتراح Beiko.

يتعلق عنصر العملية الثاني الذي اقترحته Beiko بإنشاء مستند "Meta EIP" لتتبع النطاق الكامل لترقيات الشبكة التي تم إكمالها على Ethereum. "لا يوجد مكان جيد لتتبع النطاق الكامل لترقية الشبكة قبل نشرها والإعلان عنها في منشور مدونة" ، كتب بيكو في منشور حول اقتراح Meta EIP الخاص به. "بالنسبة إلى Dencun, لدينا EL EIPs في ملف تخفيض السعر 7 الذي يصعب العثور عليه, و CL EIPs هي جزء من مواصفات سلسلة المنارة 3. هذا ليس رائعا ، حيث يصعب العثور على كلاهما ، ويستخدمان "تنسيقات" مختلفة ، ويؤديان إلى الازدواجية. نظرا لأن ERC و EIPs منفصلان الآن ، أوصي (بالعودة) باستخدام Meta EIPs لتتبع EIPs المضمنة في ترقية الشبكة. كان المطورون يؤيدون إنشاء هذه المستندات. وقال بيكو إنه سيصوغ وثيقة لمراجعة ترقية كانكون / دينيب هذا الأسبوع.

أخيرا ، أثار Beiko سؤالا حول فائدة وضع علامة على تغييرات الكود المقترحة ، مقترحات تحسين Ethereum (EIPs) ، على أنها "النظر في التضمين" (CFI). وفقا لبيكو ، فإن CFI هي حالة استخدمها المطورون تاريخيا ك "إشارة ناعمة" ، مما يشير إلى أن مؤلفي EIP يجب أن يستمروا في العمل على المقترحات التي قد يتم تضمينها في عمليات الهارد فورك المستقبلية. يتم استخدامه فقط لتغييرات وترقيات التعليمات البرمجية التي تركز على EL. 「[CFI] أعلى من الأفكار العشوائية من أشخاص عشوائيين ، ولكن قبل أن يتم قبولهم في الشوكة ، "قال بيكو.

في الماضي ، لم يبذل تصنيف CFIs سوى القليل من الجهد في الإشارة إلى EIPs على EL التي سيتم تنفيذها في الترقية ، أو متى. وقد تم تطبيقه على مجموعة واسعة من EIPs بدرجات متفاوتة من استعداد الكود والدعم من فرق العملاء. في حالة اقتراح تنسيق كائن EVM (EOF) ، يستخدم المطورون هذه العلامة للإشارة إلى التزامهم بتنفيذ EOF في الترقية القادمة التالية ، Cancun / Deneb. ومع ذلك ، فقد تم رفض EOF ، بالإضافة إلى العديد من المقترحات الأخرى التي تم وضع علامة عليها أيضا على أنها CFIs ، من Cancun/Deneb ، ومن غير الواضح حالة EIPs التي تم وضع علامة عليها على أنها CFIs في الترقية التالية براغ / إلكترا.

قال بيكو إنه إذا لم تساعد هذه الحالة ، فيجب على المطورين إزالتها ، ولكن إذا كانوا يعتزمون الاحتفاظ بها ، فيجب على مطوري CL أيضا استخدام نفس التسمية على تغييرات التعليمات البرمجية التي يفكرون في تنفيذها في ترقيات CL. من غير الواضح إلى أي مدى تعكس عملية مراجعة CL EIP عملية مراجعة EL EIP وما إذا كان ينبغي أن تتطور بنفس الطريقة في المستقبل. عادة ، تتم مناقشة تغييرات الكود المقترحة على مواصفات CL في المكالمة الجماعية ACDC ، بينما تتم مناقشة EIPs المقترحة لمواصفات EL في المكالمة الجماعية ACDE.

كما توصل دانو فيرين من Swirlds Labs إلى فكرة إنشاء حقل عنصر نائب لجميع EIPs ، سواء كانت مرتبطة ب CL أو EL ، والتي تحدد حالتها أثناء عملية المراجعة ، بما في ذلك حالة CFI. في هذه المكالمة ، لم يكن هناك قرار واضح بشأن موضوع حالة EIP ووضع العلامات CFI.

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • تعليق
  • إعادة النشر
  • مشاركة
تعليق
0/400
لا توجد تعليقات
  • تثبيت