اختتم اجتماع @ethereum #AllCoreDevs آخر في 15 سبتمبر: تمت مناقشة تحديثات شبكة التطوير والإضافات إلى Dencun ونظرة عامة شاملة على Reth!
جدول الأعمال: الرابط المباشر:
فيما يلي ملخص للاجتماع بواسطة @TimBeiko.
1. تحديث حالة Devnet-8
أولاً، تحديث الحالة على devnet-8: تخضع الشبكة للتطوير النهائي وقد دفع العديد من العملاء بالفعل تحديثات جديدة إليها. في هذه الأثناء، بدأنا باختبار عملية بناء MEV/البلوك باستخدام @KurtosisTech. صرح @NethermindEth أن مجمع المعاملات الثنائية الكبيرة الخاص بهم أصبح الآن جاهزًا، وبعد بضعة أيام من الاختبار على عقدة واحدة، قاموا بنشره على جميع عقد اختبار Dencun.
مجمع معاملات Geth's blob على وشك الاكتمال أيضًا. تقوم Besu بإجراء تحسينات واسعة النطاق على مجمع المعاملات الخاص بها (الحد من الحجم الإجمالي للمعاملات الثنائية الكبيرة وغير الثنائية الكبيرة) التي من المتوقع إصدارها في إصدارها التالي. تواصل Erigon تحسين مجموعة المعاملات الخاصة بها وتأمل أن تكون جاهزة لـ devnet-9. تشير شركة Prysm أيضًا إلى أن هناك بعض التأخير في تلقي البيانات الجانبية النقطية، والتي يقولون إنها تصل عادةً مع تأخير يبلغ حوالي 500 مللي ثانية بعد الكتلة (بينما تستغرق معالجة الكتلة حوالي 15 مللي ثانية).
إنهم يحققون في هذه المشكلة لتحديد ما إذا كان السبب هو حالة السباق بين عمليات استيراد blob وchunk. فيما يتعلق بمسألة ما إذا كان سيتم السماح بدعم معاملات blob في تجمع الذاكرة قبل الانقسام الكلي، فقد وافق الفريق بالإجماع على عدم القيام بذلك.
2、EIP-7514
بعد ذلك، واصلنا المناقشة من مكالمة ACDC الأسبوع الماضي حول ما إذا كان يجب إضافة حد أقصى ثابت إلى قائمة انتظار تنشيط أداة التحقق من الصحة. تم تشكيل هذا الاقتراح رسميًا باسم EIP-7514. باختصار، سيؤدي هذا إلى إبطاء النسبة المئوية لنمو حصة ETH في أسوأ السيناريوهات. أعرب دانكراد عن دعمه للاقتراح أثناء المكالمة، قائلًا إنه سيوفر لنا الوقت لإجراء تغييرات أكثر تعقيدًا على مكافآت المدققين.
جميع فرق CL تؤيد هذا التغيير، مع التحذير بأن هذا ينطبق فقط على قائمة انتظار الإيداع وليس قائمة انتظار السحب. وبعد مزيد من المناقشة قررنا تعيين الحد الأقصى على 8. لذلك، سيكون EIP-7514 جزءًا من ترقية Dencun! ومن المتوقع أنه في الأيام القليلة المقبلة، سيتم تحديث EIP ومواصفات CL ذات الصلة لتعكس هذا التغيير.
3.EVM وBlob
بعد ذلك، ناقشنا اقتراحًا مؤقتًا آخر: إضافة رمز تشغيل إلى جهاز Ethereum الظاهري (EVM) لكشف الرسوم الأساسية للكائنات الثنائية الثنائية الكبيرة (blob). تم تقديم هذا الاقتراح بواسطة @PlasmaPower0 من Arbitrum، الذي قال في R&D Discord في وقت سابق من هذا الأسبوع أنه سيكون مفيدًا لهم (وحلول الطبقة الثانية الأخرى). لدينا بالفعل كود تشغيل مشابه يكشف BASEFEE في EIP-1559، والذي تم تقديمه في نفس الوقت الذي تم فيه تنشيط EIP. وهذا يسهل على حلول الطبقة الثانية تحديد سعر الغاز الصحيح لتحصيل الرسوم من المستخدمين بناءً على تكاليف بيانات L1.
حضر @protolambda من Optimism أيضًا الاجتماع واقترح أن هذه ليست الطريقة الوحيدة للحصول على رسوم قاعدة النقطة للمستوى 2، حيث يمكنهم إلقاء نظرة على رأس الكتلة (الذي يحتوي على القيم المستخدمة لحساب رسوم قاعدة النقطة) و تقديم ميركل ضد تلك القيم تثبت. ومع ذلك، فهو يوافق على أنها ميزة رائعة. لا تقوم Arbitrum حاليًا بإجراء تحليل لرأس الكتلة، وقد يكون الاعتماد على هذا مشكلة بالنسبة لحلول الطبقة الثانية غير القابلة للتغيير، حيث قد يسبب هذا مشكلة إذا انتهى تنسيق رأس الكتلة بالتغيير.
ذكر أحد مؤلفي EIP-4844 @adietrichs أن كود التشغيل هذا لم يتم تضمينه في المواصفات الأصلية نظرًا لوجود رغبة في تطوير طريقة أكثر عمومية للوصول إلى معلومات رأس الكتلة (بدلاً من إضافة كود تشغيل لمرة واحدة). ومع ذلك، فإن تبني هذا التغيير الأكثر طموحًا سيكون مهمة أكثر طموحًا من تقديم كود التشغيل هذا.
المعلومات التي يكشفها كود التشغيل هذا هي بالفعل ما يحتاج عميل EL إلى حسابه، وهي مطابقة تقريبًا لرمز التشغيل BASEFEE. وافق فريق العميل بالإجماع على ضرورة إضافة كود التشغيل هذا، حتى يكون متوافقًا مع BASEFEE. إذا توصلنا في المستقبل إلى آلية "أكثر سلاسة"، فإن أي وظيفة زائدة عن الحاجة في كود التشغيل الجديد هذا ستصبح أيضًا مشكلة لأكواد التشغيل الأخرى التي تستخدم معلومات رأس الكتلة. أيضًا، تجدر الإشارة إلى أن هذا تغيير بسيط جدًا: قام @vdWijden بتنفيذه في Geth قبل وجود EIP، واستغرق الأمر حوالي 20 دقيقة فقط، وقد أجرى فريق Reth تغييرًا بشأنه أثناء مكالمة ACD للعلاقات العامة.
4、EIP-4788
بعد ذلك، ناقشنا بعض التحديثات على EIP-4788، وهو اقتراح لتخزين جذور المنارات في العقود على سلسلة Ethereum الرئيسية. على مدى الأسابيع القليلة الماضية، أجرينا العديد من عمليات التدقيق والاختبارات الغامضة للعقد، مما أدى إلى بعض التغييرات الطفيفة الموضحة في هذه العلاقات العامة. على الرغم من أنه لم يتم الانتهاء من جميع عمليات التدقيق ولم يتم إصدار التقارير بعد، فقد قدم @lightclients نظرة عامة على التغييرات التي تم النظر فيها حتى الآن. التغيير الأول هو التعامل بشكل صريح مع 0 طوابع زمنية بحيث تتسبب في التراجع (تمامًا مثل الطوابع الزمنية الأخرى غير الصالحة) بدلاً من إرجاع 0. التغيير الثاني يتعلق بحجم المخزن المؤقت. بافتراض أن فترة زمنية تتغير، فإن العقد الأصلي سيؤدي إلى إهدار التخزين بسبب الطريقة التي تعمل بها الحسابات المعيارية.
5. تحسين الغاز
وأخيرا، هناك تحسين الغاز الذي يقلل من عدد مرات تحميل CALLDATA. سيقوم المدققون بمراجعة هذه التغييرات ونتوقع أن نحصل على تقريرهم النهائي قبل اجتماع ACDE التالي. من أجل الحفاظ على المضي قدمًا في اختبار الغموض وأعمال التنفيذ، اتفقنا على دمج التغييرات المقترحة الآن.
ذكر @shemnon أيضًا أنه يجب توثيق هذه التغييرات في EIP الفعلي - ونحن نعمل على ذلك! بعد ذلك، ناقشنا كيف يجب على العملاء التعامل مع هذا إذا كان عنوان عقد النظام جزءًا من الحالة ولكنه فارغ في نهاية التنفيذ. على الرغم من أنه من غير المرجح أن يحدث هذا على الشبكة الرئيسية (حسب ما أفهمه!)، إلا أن هذه حالة حافة حدثت أثناء الاختبار عن طريق تعيين العنوان في كتلة التكوين.
نظرًا لأن هذه حالة حافة خاصة إلى حد ما ولا يوجد سلوك قانوني واضح، فقد اتفقنا على قضاء المزيد من الوقت في التفكير في هذه المشكلة ومواصلة المناقشة في اجتماع الاختبار في الأسبوع المقبل. هذا كل شيء عن تغييرات المواصفات! تم التخطيط لإدراج كل ما سبق في devnet-9. يوافق فريق العميل على أنه يجب تنفيذ كل شيء واختباره قبل انعقاد مؤتمر ACDC الأسبوع المقبل. في تلك المكالمة، سنتفق على تاريخ إطلاق devnet-9.
ومن المقرر عقد ACDE التالي في 28 سبتمبر، الساعة 14:00 بالتوقيت العالمي المنسق. حتى ذلك الحين، تابع @terencechain للحصول على ملخصات اجتماع الاختبار، و@benjaminion_xyz للحصول على معلومات اجتماع ACDC، و@christine_dkim للحصول على تغطية أكثر تفصيلاً للحدث بأكمله.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
سيكون EIP-7514 جزءًا من ترقية Ethereum Dencun
المؤلف: @TimBeiko الترجمة: Huohuo/Vernacular Blockchain
اختتم اجتماع @ethereum #AllCoreDevs آخر في 15 سبتمبر: تمت مناقشة تحديثات شبكة التطوير والإضافات إلى Dencun ونظرة عامة شاملة على Reth!
جدول الأعمال: الرابط المباشر:
فيما يلي ملخص للاجتماع بواسطة @TimBeiko.
1. تحديث حالة Devnet-8
أولاً، تحديث الحالة على devnet-8: تخضع الشبكة للتطوير النهائي وقد دفع العديد من العملاء بالفعل تحديثات جديدة إليها. في هذه الأثناء، بدأنا باختبار عملية بناء MEV/البلوك باستخدام @KurtosisTech. صرح @NethermindEth أن مجمع المعاملات الثنائية الكبيرة الخاص بهم أصبح الآن جاهزًا، وبعد بضعة أيام من الاختبار على عقدة واحدة، قاموا بنشره على جميع عقد اختبار Dencun.
مجمع معاملات Geth's blob على وشك الاكتمال أيضًا. تقوم Besu بإجراء تحسينات واسعة النطاق على مجمع المعاملات الخاص بها (الحد من الحجم الإجمالي للمعاملات الثنائية الكبيرة وغير الثنائية الكبيرة) التي من المتوقع إصدارها في إصدارها التالي. تواصل Erigon تحسين مجموعة المعاملات الخاصة بها وتأمل أن تكون جاهزة لـ devnet-9. تشير شركة Prysm أيضًا إلى أن هناك بعض التأخير في تلقي البيانات الجانبية النقطية، والتي يقولون إنها تصل عادةً مع تأخير يبلغ حوالي 500 مللي ثانية بعد الكتلة (بينما تستغرق معالجة الكتلة حوالي 15 مللي ثانية).
إنهم يحققون في هذه المشكلة لتحديد ما إذا كان السبب هو حالة السباق بين عمليات استيراد blob وchunk. فيما يتعلق بمسألة ما إذا كان سيتم السماح بدعم معاملات blob في تجمع الذاكرة قبل الانقسام الكلي، فقد وافق الفريق بالإجماع على عدم القيام بذلك.
2、EIP-7514
بعد ذلك، واصلنا المناقشة من مكالمة ACDC الأسبوع الماضي حول ما إذا كان يجب إضافة حد أقصى ثابت إلى قائمة انتظار تنشيط أداة التحقق من الصحة. تم تشكيل هذا الاقتراح رسميًا باسم EIP-7514. باختصار، سيؤدي هذا إلى إبطاء النسبة المئوية لنمو حصة ETH في أسوأ السيناريوهات. أعرب دانكراد عن دعمه للاقتراح أثناء المكالمة، قائلًا إنه سيوفر لنا الوقت لإجراء تغييرات أكثر تعقيدًا على مكافآت المدققين.
جميع فرق CL تؤيد هذا التغيير، مع التحذير بأن هذا ينطبق فقط على قائمة انتظار الإيداع وليس قائمة انتظار السحب. وبعد مزيد من المناقشة قررنا تعيين الحد الأقصى على 8. لذلك، سيكون EIP-7514 جزءًا من ترقية Dencun! ومن المتوقع أنه في الأيام القليلة المقبلة، سيتم تحديث EIP ومواصفات CL ذات الصلة لتعكس هذا التغيير.
3.EVM وBlob
بعد ذلك، ناقشنا اقتراحًا مؤقتًا آخر: إضافة رمز تشغيل إلى جهاز Ethereum الظاهري (EVM) لكشف الرسوم الأساسية للكائنات الثنائية الثنائية الكبيرة (blob). تم تقديم هذا الاقتراح بواسطة @PlasmaPower0 من Arbitrum، الذي قال في R&D Discord في وقت سابق من هذا الأسبوع أنه سيكون مفيدًا لهم (وحلول الطبقة الثانية الأخرى). لدينا بالفعل كود تشغيل مشابه يكشف BASEFEE في EIP-1559، والذي تم تقديمه في نفس الوقت الذي تم فيه تنشيط EIP. وهذا يسهل على حلول الطبقة الثانية تحديد سعر الغاز الصحيح لتحصيل الرسوم من المستخدمين بناءً على تكاليف بيانات L1.
حضر @protolambda من Optimism أيضًا الاجتماع واقترح أن هذه ليست الطريقة الوحيدة للحصول على رسوم قاعدة النقطة للمستوى 2، حيث يمكنهم إلقاء نظرة على رأس الكتلة (الذي يحتوي على القيم المستخدمة لحساب رسوم قاعدة النقطة) و تقديم ميركل ضد تلك القيم تثبت. ومع ذلك، فهو يوافق على أنها ميزة رائعة. لا تقوم Arbitrum حاليًا بإجراء تحليل لرأس الكتلة، وقد يكون الاعتماد على هذا مشكلة بالنسبة لحلول الطبقة الثانية غير القابلة للتغيير، حيث قد يسبب هذا مشكلة إذا انتهى تنسيق رأس الكتلة بالتغيير.
ذكر أحد مؤلفي EIP-4844 @adietrichs أن كود التشغيل هذا لم يتم تضمينه في المواصفات الأصلية نظرًا لوجود رغبة في تطوير طريقة أكثر عمومية للوصول إلى معلومات رأس الكتلة (بدلاً من إضافة كود تشغيل لمرة واحدة). ومع ذلك، فإن تبني هذا التغيير الأكثر طموحًا سيكون مهمة أكثر طموحًا من تقديم كود التشغيل هذا.
المعلومات التي يكشفها كود التشغيل هذا هي بالفعل ما يحتاج عميل EL إلى حسابه، وهي مطابقة تقريبًا لرمز التشغيل BASEFEE. وافق فريق العميل بالإجماع على ضرورة إضافة كود التشغيل هذا، حتى يكون متوافقًا مع BASEFEE. إذا توصلنا في المستقبل إلى آلية "أكثر سلاسة"، فإن أي وظيفة زائدة عن الحاجة في كود التشغيل الجديد هذا ستصبح أيضًا مشكلة لأكواد التشغيل الأخرى التي تستخدم معلومات رأس الكتلة. أيضًا، تجدر الإشارة إلى أن هذا تغيير بسيط جدًا: قام @vdWijden بتنفيذه في Geth قبل وجود EIP، واستغرق الأمر حوالي 20 دقيقة فقط، وقد أجرى فريق Reth تغييرًا بشأنه أثناء مكالمة ACD للعلاقات العامة.
4、EIP-4788
بعد ذلك، ناقشنا بعض التحديثات على EIP-4788، وهو اقتراح لتخزين جذور المنارات في العقود على سلسلة Ethereum الرئيسية. على مدى الأسابيع القليلة الماضية، أجرينا العديد من عمليات التدقيق والاختبارات الغامضة للعقد، مما أدى إلى بعض التغييرات الطفيفة الموضحة في هذه العلاقات العامة. على الرغم من أنه لم يتم الانتهاء من جميع عمليات التدقيق ولم يتم إصدار التقارير بعد، فقد قدم @lightclients نظرة عامة على التغييرات التي تم النظر فيها حتى الآن. التغيير الأول هو التعامل بشكل صريح مع 0 طوابع زمنية بحيث تتسبب في التراجع (تمامًا مثل الطوابع الزمنية الأخرى غير الصالحة) بدلاً من إرجاع 0. التغيير الثاني يتعلق بحجم المخزن المؤقت. بافتراض أن فترة زمنية تتغير، فإن العقد الأصلي سيؤدي إلى إهدار التخزين بسبب الطريقة التي تعمل بها الحسابات المعيارية.
5. تحسين الغاز
وأخيرا، هناك تحسين الغاز الذي يقلل من عدد مرات تحميل CALLDATA. سيقوم المدققون بمراجعة هذه التغييرات ونتوقع أن نحصل على تقريرهم النهائي قبل اجتماع ACDE التالي. من أجل الحفاظ على المضي قدمًا في اختبار الغموض وأعمال التنفيذ، اتفقنا على دمج التغييرات المقترحة الآن.
ذكر @shemnon أيضًا أنه يجب توثيق هذه التغييرات في EIP الفعلي - ونحن نعمل على ذلك! بعد ذلك، ناقشنا كيف يجب على العملاء التعامل مع هذا إذا كان عنوان عقد النظام جزءًا من الحالة ولكنه فارغ في نهاية التنفيذ. على الرغم من أنه من غير المرجح أن يحدث هذا على الشبكة الرئيسية (حسب ما أفهمه!)، إلا أن هذه حالة حافة حدثت أثناء الاختبار عن طريق تعيين العنوان في كتلة التكوين.
نظرًا لأن هذه حالة حافة خاصة إلى حد ما ولا يوجد سلوك قانوني واضح، فقد اتفقنا على قضاء المزيد من الوقت في التفكير في هذه المشكلة ومواصلة المناقشة في اجتماع الاختبار في الأسبوع المقبل. هذا كل شيء عن تغييرات المواصفات! تم التخطيط لإدراج كل ما سبق في devnet-9. يوافق فريق العميل على أنه يجب تنفيذ كل شيء واختباره قبل انعقاد مؤتمر ACDC الأسبوع المقبل. في تلك المكالمة، سنتفق على تاريخ إطلاق devnet-9.
ومن المقرر عقد ACDE التالي في 28 سبتمبر، الساعة 14:00 بالتوقيت العالمي المنسق. حتى ذلك الحين، تابع @terencechain للحصول على ملخصات اجتماع الاختبار، و@benjaminion_xyz للحصول على معلومات اجتماع ACDC، و@christine_dkim للحصول على تغطية أكثر تفصيلاً للحدث بأكمله.