jakiro
المؤلف: كريستين كيم ، جالاكسي ؛
في 12 سبتمبر ، 2024 ، عقد مطورو بروتوكول Ethereum مؤتمر التنفيذ (ACDE) 196th (ACDE) من خلال الاجتماع الافتراضي.هذا الأسبوع ، استضاف تيم بيكو ، رئيس مؤتمر الاتفاق في مؤسسة Ethereum (EF) هذا الأسبوع.مكالمة ACDE الجماعية هي سلسلة مؤتمرات كل أسبوعين حيث يناقش المطورون وتنسيق التغييرات على طبقة تنفيذ Ethereum (EL).
على ACDE #196 ،شارك المطورون آخر التحديثات التي أصدرتها Pectra Devnet 3 وناقشوا تغييرات كود Pectra المختلفة التي تم تنفيذها على شبكة التطوير في المستقبل.ناقشوا بجدية تقسيم الترقية إلى جزأين حتى يتمكنوا من نشر تغييرات رمز على DevNet 3 على جدول أسرع (ربما بحلول فبراير من العام المقبل).وافق المطور على اتخاذ قرار نهائي بشأن ذلك في مؤتمر ACD التالي.أخيرًا ، شارك مهندس عمليات مطور EF المسمى “PK910” أحدث التطورات في عمله على تنظيف مستودع Ethereum Public Testnet Github وتبديل بنيته لاستخدام أسهل.
Pectra Devnet 3
قدمت EF Development and Operations Engineer Parisosh Jayanthi إصدار Pectra Devnet 3.تم إطلاق شبكة التطوير يوم الأربعاء 11 سبتمبر.ويشمل إصلاحات لدمج المدقق في EIP 7251 والمواصفات المحدثة لـ EIP 7702.استنادًا إلى الاختبارات على DevNet 3 حتى الآن ، يبدو أن كلا من EIP 7251 و EIP 7702 يعملان كما هو متوقع.أشار جايانثي إلى وجود بعض المشكلات الموجودة في عملاء هولندا و Ethereumjs ، ويعمل كلا الفريقين على معالجتها.وأضاف Jayanthi أنه نظرًا لأن EIP 7702 متصل بالإنترنت في DevNet 3 ، فمن الأفضل أن يختبر مطورو المحفظة التنفيذ وتقديم ملاحظات حول استخدامها.يمكن العثور على جميع المعلومات حول Pectra Devnet 3 ، بما في ذلك الصنابير التي تطلب TestNet ETH ، على هذا الموقع.
تحديث مواصفات pectra
اقترح مطور Geth Felix Lange تغييرات على ترميز طلبات EL Trigger في Pectra.كخلفية ، ستمكن Pectra العقود الذكية على EL من بدء عمليات السحب والاندماج على CL.خلال مكالمة ACD الأخيرة ، شارك Lange اقتراحًا لتقليل مقدار العمل الذي يتطلبه عملاء EL لحل هذه الطلبات.منذ المكالمة الجماعية الأسبوع الماضي ، قام لانج بإضفاء الطابع الرسمي على توصياته والعمل الذي يتعين على فريق عميل EL القيام به لتحديث ترميز EIPs الأربعة التالية:
-
EIP 7685 ، طلب طبقة التنفيذ العامة ؛
-
EIP 7002 ، يمكن أن يؤدي EL إلى عمليات السحب ؛
-
EIP 6110 ، إيداع المدقق على التوريد على السلسلة ؛
-
EIP 7251 ، زيادة التوازن الفعال الأقصى.
وافق المطورين عمومًا على اقتراح لانج.ومع ذلك ، جادل مطورو Nimbus ، الذين بعنوان “Dustin” ، بأن الاقتراح كان “مرنًا بلا معنى” ولم يكن متوافقًا مع التغييرات المستقبلية في تنسيق التسلسل EL.وأكد أيضًا أن هناك حاجة إلى مواصفات إضافية لتوضيح ترتيب طلبات عملاء EL وسلوك عملاء CL عندما يقدم EL طلبات غير صالحة إلى CL.يوافق Lange على إضافة المزيد من النص إلى واجهة برمجة تطبيقات المحرك لتحديد ترتيب الطلبات.كما يتفق مع Dustin على أن سلوك عملاء CL عندما يكتشف عملاء CL طلبات غير صالحة من عملاء EL يجب اعتبارها أكثر عمقًا.
أشار الباحث في مؤسسة Ethereum Foundation بيتر ميلر إلى أنه بناءً على السلوك المنطقي لعملاء CL بموجب المواصفات الحالية ، يجب على عملاء CL رفض الكتل من ELS التي لم يتم فرزها بالطريقة الصحيحة.بالإضافة إلى ذلك ، إذا كانت هناك طلبات غير صالحة في القائمة التي يشاركها EL إلى CL ، فيجب على CL ببساطة معالجة جميع الطلبات الصالحة في القائمة وتجاهل الطلبات غير الصالحة.يتفق داستن مع ميلر ويقدم المشورة للمطورين لتحديد هذا السلوك في الوثائق المناسبة.وقال بيكو إنه يجب على المطورين العمل على حل المشكلات في اقتراح لانج وإكماله قبل مكالمة ACD التالية.
ثم،اقترح مطور Eragon Andrew Ashikhmin تحديثًا لـ EIP 7702 ، حيث قام بإعداد رمز حساب EOA.وأشار إلى أن فحص الصلاحية المحدد في EIP كان غير متسق مع فحص الصلاحية المحدد في EIP القديم.قال مطور Geth Matt Garnett (المعروف أيضًا باسم “LightClient”) إنه لديه بديل لمعالجة مشكلات الاتساق وتبسيط فحص فعالية EIP 7702.يفضل معظم المطورين وضع اللمسات الأخيرة على اقتراح LightClient وإضافته إلى Pectra Devnet 4.
النقاش التالي المتعلق بـ PECTRA يدور حول تسعير BLS precompilation بموجب EIP 2537.قال مطور Geth Jared Wasinger إنه وفقًا لتحليله القياسي ، يجب أن يكون سعر BLS precompilation مرتين كما هو محدد حاليًا.تعتمد التكلفة حاليًا على تنفيذ متعدد الخيوط ، وهو ليس معيارًا لتسعير التنفيذ الآخر المسبق.لذلك ، بناءً على تحليله باستخدام موضوع واحد ، يوصي Wasinger بإجراء تغييرات على جداول الخصم التي يتم تشغيلها في EIP 2537.أفاد فريق هولندا أنهم يقومون بتطوير أداة بحيث يمكن لفرق العملاء الأخرى بسهولة إجراء تحليل القياس الخاص بهم لـ EIPs أيضًا.تنصح Beiko الفريق بتنفيذ معاييره الخاصة لـ BLS precompilation والتوصل إلى أفكار حول إعادة تعيين هذه العمليات على مدار الأسبوعين المقبلين.
ملحق Pectra EIP
ثم بدأ المطورون في مناقشة موضوع إضافة EIPs جديدة إلى ترقية Pectra.في بداية المناقشة ، حذرت بيكو: “لدينا بالفعل كمية كبيرة من EIP في البكترا. إنها إلى حد بعيد أكبر شوكة من حيث عدد EIPs.” قال إنه من الواضح أن EIP 7742 (فصل تعداد النقطة بين EL و CL) هو القائمة الأقل إثارة للجدل من EIPs التي لا تزال قيد النظر في القائمة التي تمت ترقيتها.
اقترح أليكس ستوكس باحث EF مرة أخرى فكرة تقسيم البكتيرا إلى شوكين أصغر أصغر.”أعتقد أن الجميع يوافقون على أنه شوكة كبيرة جدًا. لذا فإن الشيء الطبيعي الذي يجب فعله هو تقسيمه إلى قسمين. عادةً ما يكون خطر الشوك الأصغر أقل. EIP ، وهذا يضيف حقًا إلى عبء الاختبار والأمن والمراجعة “.اقترح جايانثي أيضًا الفكرة في مكالمة هاتفية سابقة ، والتي قال إنه لا يزال يدعمه.”أعتقد أن السبب الرئيسي هو أنه في الوقت الحالي لدينا الكثير من eips ، نميل إلى لمس العديد من طبقات المكدس ، وكلما زاد عددنا ، من الصعب على أي شخص أن يكون لديه فهم عالمي لجميع التغييرات حتى في ظل التيار قال الحمل. “
فيما يتعلق بالطريقة التي يمكن بها تقسيم pectra eip الحالي إلى فرعين ، توصي Stokes باستخدام جميع EIPs التي تعمل حاليًا على شبكة التطوير لنشر الجزء الأول من Pectra ، ثم استخدام Peerdas و EOF وبعض eips الإضافية الأخرى لنشر الثانية جزء من البكترا.يثق المطورون من أنه من خلال القيام بذلك ، سيكونون قادرين على إطلاق الجزء الأول من Pectra بحلول فبراير المقبل.وقال الباحث في EF Ansgar Dietrichs في محادثة التكبير: “أعتقد أنه إذا ما زلنا نصدر النصف الأول فقط في يونيو ، فإن هذه الشوكة ستكون فاشلة”.
تفضل Beiko فكرة التقدير ، ولكنها تحذر من إزالة أي EIP من شبكة التطوير ، لأن هذا قد يجلب المزيد من العمل إلى فريق العميل ويمتد بدلاً من تقصير الجدول الزمني لإعداد تغييرات الكود هذه لتفعيل MainNet.يوصي Danno Ferrin ، وهو مطور بروتوكول Ethereum المستقل ، بتحسين EIP على DevNet 3 في أقرب وقت ممكن لتفعيل mainnet ، ثم العمل بالتوازي من Devnet 4 أو 5 ، ونقل peerdas و EOF إلى pectra eip.في الواقع ، في الترقية بعد Pectra ، سيصبح DevNet 4 أو 5 DevNet 0 ، والمطورين ليسوا متأكدين من كيفية تسميته.
في مكالمة جماعية سابقة ، وافق المطورون على تسمية الترقية بعد Pectra Fusaka ، لكنهم وافقوا أيضًا على الاستمرار في الترقية لانتقال Verkle.فيما يتعلق بهذا ، تنصح Ferrin للمطورين بعدم حجز ترقية مقدمًا حتى يتأكدوا من أن تغييرات الكود جاهزة لتفعيل MainNet.تسبب هذا في غضب من Geth Developer Guillaume Ballet ، الذي كان يقود انتقال Verkle ويصر على أن انتقال Verkle كان جاهزًا “منذ فترة طويلة”.لتخفيف التوترات ، قال بيكو إن هدف تقسيم البكرا إلى قسمين هو محاولة إطلاق تغييرات رمز البكتيرا على جدول زمني أسرع ، مما سيساعد على توضيح الطريق لانتقال Verkle بعد ذلك.
لكن،هناك خطر من أن الجزء الثاني من ترقية Pectra قد يصبح أكبر مع إضافة المزيد من EIPs ، لذلك سيستغرق إصدار المزيد من الوقت من قوائم Pectra EIP الحالية في وقت واحد.استجوب مطور Nethermind Ben Adams ،إذا تم تقسيم الترقية إلى جزأين ، فكيف ستستمر عملية اختبار Pectra.بالنظر إلى أن هذا القرار سيحدث ثورة في نطاق الترقية الفورية القادمة لـ Ethereum ، تنصح Beiko للمطورين بقضاء أسبوع في التفكير في هذه الفكرة.وطلب من المطورين الاستعداد لاتخاذ قرار نهائي بشأن المسألة في إجماع الإجماع يوم الخميس المقبل لجميع المطورين الأساسيين.
محاذاة بنية تكوين الشبكة
أخيرًا وليس آخرًا ، شارك مهندس عمليات EF DEV “PK910” تحديث عمله لتنظيف مستودع Ethereum Public Testnet Github وتعديل بنيته لاستخدامه أسهل.طلب من فريق العميل التحقق من تكوين العقدة من Ethereum MainNet و TestNet وإضافة أي معلومات مفقودة إلى المستودع المقابل.
