ملخص الاجتماع الأخير للمطورين الأساسيين في ETH Place: سيكون هناك شوكة ظل Goerli واختبار لترقية Cancun / Deneb قبل نهاية العام

العنوان الأصلي: Ethereum جميع المطورين الأساسيين استدعاء الإجماع # 124 Writeup

المقال الأصلي بقلم كريستين كيم

التجميع الأصلي: Luccy ، BlockBeats

ملاحظة المحرر:

تعقد ورشة عمل ETH لجميع دعوات إجماع المطورين الأساسيين (ACDCs) كل أسبوعين لمناقشة وتنسيق التغييرات التي تطرأ على طبقة إجماع ورشة العمل ETH (CL). هذه هي المكالمة الجماعية رقم 124 ل ACDC ، والتي تغطي تحديثات Devnet # 12 ، والتقدم المحرز في ترقية Cancun / Deneb ، والموضوعات المتعلقة بنشر Slashable. خلال الاجتماع ، ناقش المطورون بنشاط التغييرات الطفيفة في بروتوكول شبكة Libp2p لتقليل تأثير تضخيم الرسائل الكبيرة على العقد.

قدمت كريستين كيم ، VP الأبحاث في Galaxy Digital ، ملاحظة مفصلة حول النقاط البارزة في الاجتماع ، والتي جمعتها BlockBeasts على النحو التالي:

في 14 ديسمبر 2023 ، اجتمع مطورو ETH على Zoom لجلسة استدعاء إجماع جميع المطورين الأساسيين (ACDC) #124. المكالمة الجماعية ل ACDC عبارة عن سلسلة من الاجتماعات كل أسبوعين بقيادة داني رايان ، الباحث في مؤسسة ورشة عمل ETH ، حيث يناقش المطورون وينسقون التغييرات على طبقة إجماع ورشة العمل ETH (CL). ركز المطورون هذا الأسبوع على التقدم المحرز في اختبار ترقية Cancun / Deneb على شبكة اختبار Devnet # 12. منذ اجتماع تنفيذ المطور الشامل (ACDE) الأسبوع الماضي ، تم ضم جميع مجموعات عملاء طبقة التنفيذ (EL) وطبقة الإجماع (CL) إلى Devnet # 12 ، بما في ذلك عميل Prysm. تم تمكين برنامج MEV-Boost ، ولكن لا يتم تضمين مجموعات العميل مع Prysm. قال المطورون إنهم يسيرون على الطريق الصحيح مع خطط لإطلاق فرع الظل Goerli في الأسبوع أو الأسبوعين المقبلين لاختبار ترقية Cancun / Deneb وتشمل جميع العملاء. بالإضافة إلى ذلك ، ناقش المطورون قواعد نشر المعلومات حول Slashable ، بالإضافة إلى جدول المكالمات للأسبوعين المقبلين.

تحديث ديفنت #12

قال برنابا بوسا ، مهندس DevOps في مؤسسة ETH ، إن جميع مجموعات عملاء EL / CL ، بما في ذلك تلك التي تستخدم Prysm كعميل CL ، قد تم دمجها بنجاح في Devnet # 12. لم يتم اختبار محفظة العميل باستخدام Prysm لبرنامج MEV-Boost. ومع ذلك ، في Devnet # 12 ، يختبر سير عمل MEV عملاء CL الآخرين. في الآونة الأخيرة ، خضع عميل Lighthouse لتحديث تصحيح لمعالجة الأخطاء المتعلقة ب MEV. بالإضافة إلى ذلك ، قال Parithosh Jayanthi ، مهندس DevOps آخر في المؤسسة ، إنهم لاحظوا مشكلة في عقدة Besu على Devnet # 12 وأنهم ما زالوا يعملون لتحديد السبب الجذري. كخطوة تالية ، سيقوم المطورون عمدا بإرسال كتل ضارة عبر الشبكة ، واختبار مولدات الكتل ، وإجراء اختبارات الخلية لعملاء Prysm المضافين حديثا للتأكيد على مجموعات عميل الاختبار على Devnet. قال Jayanthi في رسالة Discord عامة خلال المكالمة أن المطورين ما زالوا يخططون لإطلاق فرع ظل على شبكة اختبار Goerli بحلول نهاية العام.

تحديث المعلومات القابلة للقطع

بعد ذلك ، ناقش المطورون بإيجاز العديد من القضايا المتعلقة بانتشار وتوقيت رسالة Slashable على ETH بعد ترقية Cancun / Deneb. بالنسبة للخلفية ، تتضمن المعلومات القابلة للشرطة المائلة نشر الكتل والنقط المكررة أو غير الصالحة. قدم Dapplion ، وهو مطور مجهول لعميل Lodestar ، طلب سحب (PR) عبر GitHub يهدف إلى إضافة أحداث جديدة إلى واجهة برمجة تطبيقات Beacon Chain لتمكين مشغلي العقدة من التعرف على أحداث Slashable بسرعة أكبر ، والتي ستكون مفيدة بشكل خاص إذا كان هناك قدر كبير من المعلومات القابلة للقطع. في العلاقات العامة الخاصة به ، يذكر Dapplion ، "بالنسبة للمشغلين الكبار ، تعتمد التكلفة الإجمالية لحدث القطع بشكل كبير على وقت استجابتهم. إذا كان هناك العديد من المفاتيح المتضمنة في الأخطاء التشغيلية ، فقد يستغرق الأمر بعض الوقت حتى يتم تضمين هذه المعلومات القابلة للقطع في السلسلة. تم دمج العلاقات العامة في Dapplion في مواصفات واجهة برمجة تطبيقات Beacon Chain قبل المكالمة ويتم تنفيذها من قبل فرق عملاء CL المختلفة ، مثل Prysm و Lighthouse.

يقترح Dapplion أيضا العلاقات العامة المتعلقة بقياس وقت انتشار الكتلة. وأشار إلى أن قياس وقت انتشار الكتلة سيصبح أكثر صعوبة بسبب ترقية كانكون / دينيب وإدخال معاملات blob. يشرح دابليون الحل الذي يقترحه في العلاقات العامة الخاصة به. كما لاحظ المطورون في مؤشر ترابط العلاقات العامة, يميلون إلى حل هذه المشكلة عن طريق إضافة حقل طابع زمني إلى أحداث واجهة برمجة تطبيقات Beacon Chain الحالية ذات الصلة.

الموضوع الثالث الذي ناقشه المطورون يتعلق بنشر المعلومات القابلة للقطع بعد ترقية Cancun / Deneb كان شروط انتشار النقطة. أشار مطور المنارة “شون” (أو “realbigsean” على GitHub) إلى أن قواعد انتشار النقطة الحالية أدت إلى عواقب غير مقصودة. أثناء المكالمة ، قال شون ، "إذا كنت تستخدم واجهة برمجة تطبيقات Beacon لمصادقة البث ، فمن غير المتوقع أن يؤدي نهج القيل والقال إلى رسائل صالحة وغير صالحة. والسبب في ذلك هو أنه ، من الناحية الفنية ، من الممكن نشر نقطتين بفهارس blob مختلفة لرأس Slashable المرتبط بهما. يسمح لك بنشر هذه ، ولكن ليس تلك التي لها نفس فهرس blob. 」

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

بعد ذلك ، ناقش المطورون تغييرات طفيفة على بروتوكول شبكة libp2p لتقليل تأثير التضخيم على العقد التي ترسل رسائل كبيرة ، مثل الكتل التي تحتوي على عدد كبير من النقط. سلط شون الضوء على رسالة التحكم الجديدة “IDONTWANT” ، والتي يمكن استخدامها لإخطار أقران libp2p بإيقاف إرسال الرسائل الكبيرة مؤقتا. قال ريان إنه سيحاول التواصل مع فريق libp2p لدمج هذه العلاقات العامة ، وإذا كان هناك مزيد من التأخير ، فسيتم إعادة النظر في المشكلة في المكالمة الجماعية ACDE الأسبوع المقبل.