مؤتمر Ethereum ACDE: قد يتم إصدار تغييرات التعليمات البرمجية على Devnet3 العام المقبل

Pectra Devnet 3

يشرح باريثوش جايانثي، مهندس DevOps في EF، إصدار Pectra Devnet 3. سيتم إطلاق شبكة التطوير يوم الأربعاء 11 سبتمبر. يتضمن إصلاحات لدمج أداة التحقق من الصحة في EIP 7251 والمواصفات المحدثة لـ EIP 7702. استنادًا إلى الاختبار الذي تم إجراؤه على Devnet 3 حتى الآن، يبدو أن كلا من EIP 7251 وEIP 7702 يعملان كما هو متوقع. وأشار جايانثي إلى أنه تم اكتشاف بعض المشكلات في عملاء Nethermind وEthereumJS وأن فريقي العميلين يعملان بجد لحلها. وأضاف جايانثي أنه بما أن EIP 7702 يتم تشغيله على Devnet 3، فسيكون من الجيد السماح لمطوري المحفظة باختبار التنفيذ وتقديم تعليقات حول استخدامهم له. يمكن العثور على جميع المعلومات حول Pectra Devnet 3، بما في ذلك الحنفيات لطلب testnet ETH، على هذا الموقع.

تحديث مواصفات Pectra

اقترح مطور Geth Felix Lange تشغيل EL في Pectra المطلوب يتم تغيير الترميز. كخلفية، ستقوم Pectra بتمكين العقود الذكية على EL لبدء عمليات سحب المدقق والدمج على CL. أثناء مكالمة ACD الأخيرة، شارك Lange توصية لتقليل حجم العمل المطلوب من قبل عملاء EL لتحليل هذه الطلبات. منذ مكالمة الأسبوع الماضي، قام لانج بإضفاء الطابع الرسمي على توصياته والعمل الذي يتعين على فريق عميل EL القيام به لتحديث ترميز EIPs الأربعة التالية:

EIP 7685، طلب طبقة التنفيذ العام؛

EIP 7002، EL يمكن أن يؤدي إلى السحب؛< /p>

EIP 6110، إيداع مدقق الإمداد عبر السلسلة

EIP 7251، زيادة الحد الأقصى للرصيد الفعال.

يوافق المطورون عمومًا على اقتراح لانج. ومع ذلك، يعتقد مطور Nimbus الذي يطلق عليه "Dustin" أن الاقتراح "مرن بلا جدوى" وغير متوافق مع التغييرات المستقبلية في تنسيق تسلسل EL. وشدد أيضًا على أن هناك حاجة إلى مواصفات إضافية لتنظيم ترتيب الطلبات من عملاء EL بشكل واضح وسلوك عملاء CL عندما ترسل EL طلبات غير صالحة إلى CL. وافق لانج على إضافة المزيد من النص إلى Engine API لتحديد ترتيب الطلبات. كما أنه يتفق مع Dustin على ضرورة إيلاء المزيد من الاعتبار المتعمق لسلوك عميل CL عندما يكتشف عميل CL طلبًا غير صالح من عميل EL.

أشار بيتر ميلر، الباحث في مؤسسة إيثريوم، إلى أنه بناءً على السلوك المنطقي لعملاء CL بموجب المواصفات الحالية، يجب على عملاء CL رفض الكتل من EL التي لم يتم ترتيبها بالطريقة الصحيحة. بالإضافة إلى ذلك، إذا كانت هناك طلبات غير صالحة في القائمة التي شاركها EL مع CL، فيجب على CL ببساطة معالجة جميع الطلبات الصالحة في القائمة وتجاهل الطلبات غير الصالحة. يتفق Dustin مع Miller ويوصي المطورين بتحديد هذا السلوك في الوثائق المناسبة. وقالت Beiko إنه يجب على المطورين العمل على إصلاح المشكلات في اقتراح Lange وإكماله قبل مكالمة ACD التالية.

بعد ذلك، اقترح مطور Erigon Andrew Ashikhmin تحديثًا لـ EIP 7702، وإعداد رموز حساب EOA. وأشار إلى أن فحوصات الصلاحية المحددة في خطة EIP كانت غير متوافقة مع تلك المحددة في خطة EIP القديمة. يقول مطور Geth Matt Garnett (المعروف أيضًا باسم "Lightclient") أن لديه بديل لمعالجة مشكلات الاتساق وتبسيط عمليات التحقق من صلاحية EIP 7702. يفضل المطورون في الغالب الانتهاء من اقتراح Lightclient وإضافته إلى Pectra Devnet 4.

تدور المناقشة التالية المتعلقة بـ Pectra حول تسعير التجميع المسبق لـ BLS بموجب EIP 2537. قال مطور Geth، جاريد واسينجر، إنه بناءً على تحليله المعياري، يجب أن تكون تكلفة التجميع المسبق لـ BLS ضعف ما هو مذكور حاليًا. حاليًا، تعتمد التكلفة على التنفيذ متعدد الخيوط، وهو ليس المعيار الذي يتم من خلاله تسعير عمليات التنفيذ الأخرى المترجمة مسبقًا. لذلك، بناءً على تحليله باستخدام التنفيذ أحادي الترابط، أوصى واسينجر بإجراء تغييرات على جدول الخصم للعمليات في EIP 2537. أفاد فريق Nethermind أنهم يقومون بتطوير أداة حتى تتمكن فرق العملاء الأخرى من إجراء التحليل المعياري الخاص بهم بسهولة لـ EIP. اقترحت Beiko أن يقوم الفريق بإجراء معاييره الخاصة بشأن التجميع المسبق لـ BLS والتوصل إلى أفكار حول إعادة تسعير هذه العمليات خلال الأسبوعين المقبلين.

ملحق Pectra EIP

ثم بدأ المطورون يتحدثون عن إضافة EIPs جديدة لترقيات Pectra. في بداية المناقشة، حذرت Beiko: "لدينا بالفعل عدد كبير من EIPs في Pectra. وهي بالفعل أكبر شوكة حتى الآن من حيث حجم EIP." وفقًا للآراء التي شاركها المطورون قبل المكالمة، Beiko قال، من الواضح أن EIP 7742 (فصل عدد النقاط بين EL وCL) هو الأقل إثارة للجدل في قائمة EIPs التي لا تزال قيد النظر لتضمينها في الترقية.

طرح أليكس ستوكس، الباحث في EF، مرة أخرى فكرة تقسيم بيكترا إلى شوكتين أصغر حجمًا. "أعتقد أن الجميع متفقون على أن هذه شوكة كبيرة جدًا. لذا فإن الشيء الطبيعي الذي يجب فعله هو تقسيمها إلى قسمين. بشكل عام، الشوكات الأصغر حجمًا أقل خطورة. وعلى وجه الخصوص، لدى بيكترا الآن الكثير من EIP عبر الطبقات، وهذا حقًا قال ستوكس: “يزيد من عبء الاختبار والأمن والمراجعة”. وقال جايانثي، الذي أثار الفكرة أيضًا في مكالمة سابقة، إنه لا يزال يدعم الفكرة. "أعتقد أن السبب الرئيسي هو أنه لدينا الآن الكثير من EIPs ونميل إلى لمس العديد من طبقات المكدس، وكلما أضفنا المزيد، من الصعب على أي شخص أن يكون لديه صورة كبيرة لجميع التغييرات، قال جايانثي: "حتى في ظل الحمل الحالي".

فيما يتعلق بكيفية تقسيم Pectra EIP الحالي إلى فرعين، اقترح ستوكس استخدام جميع EIPs التي تعمل حاليًا على شبكة التطوير لإصدار الجزء الأول من Pectra، ثم استخدام PeerDAS وEOF وبعض العناصر الإضافية الأخرى EIPs تعالوا لإصدار الجزء الثاني من Pectra. المطورون واثقون من أنه من خلال القيام بذلك سيكونون قادرين على إصدار الجزء الأول من Pectra بحلول فبراير من العام المقبل. قال أنسجار ديتريش، الباحث في EF، في دردشة عبر Zoom: "أعتقد أن هذا الشوكة سيكون فاشلاً إذا كنا لا نزال نصدر النصف الأول فقط في يونيو".

تفضل Beiko فكرة الشوكة، ولكنها تحذر من إزالة أي EIPs من devnet لأن ذلك قد يؤدي إلى إنشاء المزيد من العمل لفرق العملاء وإطالة فترة إعدادها لتنشيط الشبكة الرئيسية بدلاً من تقصيرها تغييرات التعليمات البرمجية. أوصى مطور بروتوكول Ethereum المستقل Danno Ferrin بإكمال EIP على Devnet 3 في أقرب وقت ممكن لتنشيط الشبكة الرئيسية، ثم العمل بالتوازي بدءًا من Devnet 4 أو 5 لنقل PeerDAS وEOF إلى Pectra EIP. في الواقع، في الترقية بعد Pectra، سيصبح Devnet 4 أو 5 Devnet 0، والمطورون غير متأكدين من كيفية تسميته.

في مكالمة سابقة، وافق المطورون على تسمية الترقية باسم Pectra Fusaka، لكنهم وافقوا أيضًا على حجز الترقية لانتقال Verkle. في هذا الصدد، نصحت فيرين المطورين بعدم طلب الترقيات مسبقًا حتى يكونوا واثقين من أن تغييرات التعليمات البرمجية جاهزة لتنشيط الشبكة الرئيسية. أثار هذا غضب مطور Geth Guillaume Ballet، الذي كان يقود جهود انتقال Verkle وأصر على أن انتقال Verkle كان جاهزًا "منذ وقت طويل". ولتخفيف التوترات، قالت Beiko إن الغرض من تقسيم Pectra إلى قسمين هو في النهاية محاولة إصدار تغييرات كود Pectra في جدول زمني أسرع، مما سيساعد في تمهيد الطريق لانتقال Verkle بعد ذلك.

ومع ذلك، هناك خطر من احتمال زيادة الجزء الثاني من ترقية Pectra بمزيد من EIPs ويصبح أكبر، لذلك سيستغرق النشر وقتًا أطول مما كان عليه عند نشر قائمة Pectra EIP الحالية في نفس الوقت. تساءل بن آدامز، مطور Nethermind، ماذا سيحدث لعملية اختبار Pectra إذا تم تقسيم الترقية إلى جزأين ؟ سلوك. بالنظر إلى أن هذا القرار سيغير نطاق الترقية الفورية التالية لـ Ethereum تمامًا، فقد أوصت Beiko المطورين بأخذ أسبوع للنظر في الفكرة. وطلب من المطورين الاستعداد لاتخاذ قرار نهائي بشأن هذه المسألة خلال مكالمة إجماع المطورين الأساسية يوم الخميس المقبل.

محاذاة هيكل تكوين الشبكة

أخيرًا وليس آخرًا، شارك مهندس EF DevOps "pk910" تحديثًا حول عمله لتنظيف مكتبة مستودع GitHub لشبكة الاختبار العامة لـ Ethereum وضبط بنيتها لتناسب جعله أسهل في الاستخدام. وطلب من فريق الحساب التحقق من تكوين العقدة لشبكة Ethereum الرئيسية وشبكة الاختبار وإضافة أي معلومات مفقودة إلى المستودعات المقابلة.