في 31 أغسطس، اجتمع مطورو إيثريوم عبر Zoom لإجراء مكالمة جماعية للمطورين الأساسيين (ACDE). إن مكالمة ACDE، التي يستضيفها تيم بيكو من مؤسسة Ethereum، عبارة عن سلسلة من الاجتماعات نصف شهرية حيث يقوم فريق عملاء Ethereum بمناقشة وتنسيق التغييرات على طبقة تنفيذ Ethereum (EL). ناقش المطورون هذا الأسبوع التقدم المحرز في التطوير والاختبار على:
ترقية كانكون/دينيب (دينكون).
تحويل فيركل تري
تحديث تسلسل SSZ
1. ترقية كانكون
تم إطلاق Devnet #8 منذ أسبوعين في 16 أغسطس. قال بارناباس بوسا، مهندس DevOps في مؤسسة Ethereum، إن شبكة اختبار ترقية Cancun التي تركز على المطورين يبدو أنها تعمل بشكل جيد. ذكر Busa أنه يبدو أن هناك بعض المشكلات في العقد التي تقوم بتشغيل برنامج عميل Nethermind (EL). أوضح Lukasz Rozmej، مطور عميل Nethermind، أن طبيعة المشكلة كانت بسبب خطأ في التكوين في تنفيذ مجمع معاملات Blob. **(ملاحظة المترجم: Devnet 8 هي أول شبكة اختبار مخصصة، والتي تحتوي على جميع EIPs النهائية لترقية Cancun/Deneb)
فيما يتعلق بـ EIP 4788**، أعاد المطورون التأكيد لفترة وجيزة على سياسة النشر الجديدة لتغييرات التعليمات البرمجية**. سيتم نشر العقود التي تكشف بيانات سلسلة المنارات على EL مثل العقود الذكية العادية، مما يتطلب من شخص ما تمويل عنوان العقد قبل تنشيط الترقية. Devnet #9، شبكة الاختبار التالية لترقية كانكون، سوف تتبنى سير العمل هذا وتضمن أن المطورين على دراية بهذه العملية.
بدلاً من تأخير تاريخ إصدار Devnet #9، وافق المطورون على مواصلة الاختبار على Devnet #8 حتى يتم حل جميع المشكلات المتعلقة بتنفيذ العميل. "أفضل أن أثق في Devnet #9 بدلاً من القول إننا نريد أن تعمل هذه الأشياء. ... أفضل إصلاح المشكلات التي نعرفها. وإلا، إذا كانت لدينا مشكلة صعبة في Devnet #9 ، فسنقوم بذلك بالتأكيد "لدينا Devnet رقم 10 مرة أخرى، أنا لا أقول أنه لا ينبغي أن يكون لدينا Devnet رقم 10. يجب أن يكون لدينا عدد كبير من شبكات المطورين. أعتقد أنه يمكننا الآن أن نحاول جعل Devnet رقم 9 موثوقًا حقًا." قال إيثر، داني رايان، زميل في مؤسسة فانغ ورئيس المؤتمر الهاتفي لـ ACDC.
*كان الآخرون المشاركون في المكالمة، بما في ذلك Tim Beiko وMarius Van Der Wijden وJustin Florentine، يؤيدون قضاء المزيد من الوقت في اختبار Devnet #8 واختبار التغييرات لاحقًا في EIP 4788 على Devnet #9 *. اقترحت Beiko وقتًا للمطورين لإعادة عقد Devnet رقم 9 خلال المكالمة الجماعية التالية لـ ACDE. فيما يتعلق باستراتيجيات نشر شبكة الاختبار، توصي Beiko بالتسلسل التالي:
Devnet #9: Devnet آخر تم تجميد مواصفات Dencun الخاصة به. قم باختبار الشبكة وافترض أن المطورين راضون عنها، ثم انتقل إلى شبكة اختبار عامة. بخلاف ذلك، ابدأ تشغيل Devnet رقم 10.
Holesky: افصل شبكة اختبار Holeksy التي تم إطلاقها حديثًا ونشر ترقية Dencun عليها.
جويرلي: ثم قم بنشر Dencun على جويرلي. نظرًا لإطلاق شبكة الاختبار قبل الأخيرة قبل الشبكة الرئيسية، يجب أن تكون مواصفات الترقية في هذا الوقت نهائية وتزود المستخدمين والتطبيقات بوقت كافٍ لاختبار برامجهم قبل تنشيط ترقية الشبكة الرئيسية. من المحتمل أن يكون Dencun هو التفرع الأخير لـ Goerli قبل إهماله واستبداله بـ Holesky. (ملاحظة المترجم: كلمة Dencun هي كلمة مركبة مكونة من Cancun (Cancun) وDeneb. Cancun هو اسم ترقية طبقة تنفيذ Ethereum هذه، وDeneb هو اسم ترقية طبقة البروتوكول. لذلك، ترقية Cancun مدمجة مع تُعرف ترقية Deneb باسم ترقية Dencun.)
سيبوليا: أخيرًا، تم نشر دينكون في سيبوليا لتحقيق نتائج جيدة.
لم يثر أحد أي اعتراضات على اقتراح Beiko بإطلاق شبكة اختبار بعد Devnet #9. ذكرت Beiko أنه ستتم مشاركة الجدول الزمني المذكور أعلاه مع مجتمع الإيثريوم الأوسع في منشور بالمدونة بمجرد إطلاق شبكة اختبار Holesky رسميًا في 15 سبتمبر. بالإضافة إلى ذلك، قالت Beiko أن هناك أيضًا شبكة اختبار تسمى Ephemery قيد التطوير. Ehemery عبارة عن شبكة اختبار Ethereum لمشغلي عقدة التحقق والتي ستتم إعادة تعيينها إلى حالة التكوين بعد أسبوع أو أسبوعين. لمزيد من المعلومات حول شبكة Ephemery، اقرأ صفحة GitHub الخاصة بالمشروع هنا.
قبل الانتقال لمناقشة محاولات Verkle، سلط Busa الضوء على طلب سحب مفتوح (PR) على GitHub لشبكة اختبار Holesky. بناءً على طلب فريق Erigon (EL)، يقترح مسؤول العلاقات العامة إزالة وقت التنشيط المحدد لترقية Dencun على Holesky. سيقوم المطورون لاحقًا بتعيين قيمة لتنشيط Dencun على Holesky بدلاً من الكتابة فوق القيمة الحالية. أثار Busa أيضًا سؤالاً حول اختبار هدف/حد أقصى 3/6 بدلاً من حد 2/4. ** في هذا الموضوع، اقترحت Beiko طرح هذا الأمر مرة أخرى في مكالمة ACDC الأسبوع المقبل، حيث ذكر رايان أن التجارب الأخيرة بأحجام الكتل الكبيرة ستجلب رؤى جديدة. **
2. تحويل Verkle Trie
بعد ذلك، ناقش المطورون اقتراح Vitalik Buterin للجمع بين خرائط طريق Verkle Trie وState Expiry لتقليل تعقيد تنفيذ Verkle Trie وتسريع فوائد State Expiry على Ethereum. كخلفية، **Verkle Trie أو Verkle Tree عبارة عن بنية بيانات تسمح للمستخدمين بالتحقق بسهولة من كميات كبيرة من البيانات بالاعتماد على دليل تشفير واحد. **إنها لا تختلف عن Merkle Patricia Trie (MPT)، وهي بنية بيانات تستخدم لتخزين حالة Ethereum. ومع ذلك، فإن كفاءة إثبات أشجار Verkle أعلى نسبيًا من كفاءة MPT، ولهذا السبب كان المطورون يعملون على نقل MPT إلى Verkle.
**انتهاء الولاية عبارة عن مبادرة منفصلة مصممة لمعالجة مشكلة نمو الحالة غير المحدود. **الهدف من انتهاء صلاحية الحالة هو حذف أجزاء من حالة Ethereum التي لم يتمكن المستخدمون من الوصول إليها لفترة من الوقت (على سبيل المثال 365 يومًا)، وبالتالي تقليل حجم الحالة من أكثر من 100 جيجابايت إلى أقل من 50 جيجابايت. يفضل Andrew Ashikhmin من فريق حساب Erigon (EL) تجميع الترقيتين، بافتراض أن تحويل Verkle Trie سيتم تبسيطه إلى حد كبير إذا تم دمجه مع انتهاء الولاية. يشعر Guillaume Ballet من فريق عملاء Geth (EL)، الذي كان يقود مشروع Verkle Trie، بالقلق من أن يؤدي الاقتران إلى تأخير محاولات Verkle، حيث تم "التخلي" عن انتهاء صلاحية الحالة كموضوع بحث على مدار العامين الماضيين.
وتحدث بوتيرين بمزيد من المعلومات الأساسية عن دوافع اقتراحه قائلاً: "مع [Verkle] عملية النقل، تكمن المشكلة بشكل أساسي في تحويل أكثر من 50 غيغابايت من Merkle Patricia Trie إلى... Verkle Trie في شبكة حية أمر معقد للغاية. وهذا بالفعل شيء كان فريق البحث يعاني منه منذ أكثر من عام. أتذكر في العام الماضي في Devconnect، أنه كان في الأساس موضوعًا لنشاط بحثي، وبشكل أساسي تم تجميع الكثير من أعمال البحث والتطوير معًا مثل بقية خارطة طريق Verkle بأكملها، تمامًا كيف كانت عملية الانتقال الأخيرة. وفي بعض النواحي، فإن تعقيدها ينافس تعقيد عمليات الاندماج. "
** تابع بوتيرين ليقول كيف يؤدي انتهاء الولاية إلى تقليل تعقيد الانتقال إلى Verkle بشكل كبير. ومع ذلك، ذكر أيضًا أن هناك متطلبات مسبقة معقدة لانتهاء صلاحية الحالة، مثل الحاجة إلى إضافة المزيد من مساحة العنوان لدعم "فترات العناوين" الجديدة كل عام.** لذلك، على الرغم من أن تعقيد تنفيذ Verkle سيتم تقليله، إلا أن المطورين ما زالوا بحاجة لحل اللغز للقيام بالأمرين معًا، بالإضافة إلى ذلك، إذا تم تنفيذ Verkle Tries قبل انتهاء صلاحية الحالة، فسيكون لانتهاء الحالة أقل إلحاحًا، لذلك يجب على المطورين التفكير في استخدام Verkle لإجراء النقل، أو الانتظار بضع سنوات قبل تقديم Verkle ثم انتهاء الحالة. لم يكن المطورون واضحين بشأن القيمة الإضافية التي قد تنتج عن تجميع الترقيتين معًا، واتفقوا على مواصلة مناقشة الموضوع بشكل غير متزامن على Discord وVerkle Trie Implementors' Call.
3. تسلسل SSZ
بعد ذلك، قدم إيتان كيسلينج، مطور عميل Nimbus (CL)، أحدث تقدم له في ترقية هياكل بيانات Ethereum إلى تنسيق تسلسل SSZ. لمزيد من المعلومات حول هذه المشكلة، اقرأ نص المكالمة السابقة لمطوري Ethereum هنا. سلط كيسلينج الضوء على طريقة جديدة لتحديث تسلسل بيانات إيثريوم باستخدام تنسيق قائم على "PartialContainer" SSZ. ** كتب كيسلينج في التعليقات ضمن جدول أعمال المكالمة الجماعية لهذا الأسبوع، ** "يجمع هذا [التنسيق] بشكل أساسي بين جميع مزايا [التنسيق السابق] ويمكن أيضًا إعادة استخدامه لأغراض أخرى، مما يؤدي إلى التخلص من الأنواع الاختيارية SSZ Union وSSZ غير المستخدمة حاليًا ." (ملاحظة المترجم: التسلسل البسيط (SSZ) هو أسلوب التسلسل المستخدم في سلسلة المنارة. تحل هذه الطريقة محل جميع جوانب طبقة الإجماع باستثناء بروتوكول اكتشاف الأقران. يتم استخدام تسلسل بادئة الطول العودية في طبقة التنفيذ. بسيط تعتبر تصميمات التسلسل حتمية ويمكن أيضًا أن تكون Merkleized بكفاءة.)
بعد التحديث، سارعت Beiko إلى الإشادة بتطبيق EL المرجعي الذي تم إنشاؤه حديثًا في Python (المسمى EELS). في منشور مدونة حديث لمؤسسة Ethereum، كتب محرر EIP والباحث في مؤسسة Ethereum Sam Wilson: "EELS هو تطبيق مرجعي لـ Python للمكونات الأساسية لعميل تنفيذ Ethereum، مع التركيز على سهولة القراءة والوضوح. تهدف EELS إلى أن تكون خليفة روحيًا بالنسبة إلى Yellow Paper، وهي أكثر ملاءمة للمبرمجين ومتزامنة مع شوكات ما بعد الدمج، يمكن لـ EELS ملء اختبارات الحالة وتنفيذها، ومتابعة الشبكة الرئيسية، وهي مكان رائع لوضع نماذج أولية لـ EIPs جديدة.
يستخدم بعض المطورين بالفعل EELS لإعادة تنفيذ EIPs الخاصة بهم، وتقدم مؤسسة Ethereum منحة لأي شخص مهتم بتحديث الورقة الصفراء لتشمل ترقيات الشبكة المدمجة مسبقًا المفقودة مثل لندن وباريس لاستكمال EELS.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
ملخص الاجتماع التنفيذي الأخير للمطورين الأساسيين لـ Ethereum
المؤلف: كريستين كيم، المجرة؛ الترجمة: Huohuo/العامية Blockchain
في 31 أغسطس، اجتمع مطورو إيثريوم عبر Zoom لإجراء مكالمة جماعية للمطورين الأساسيين (ACDE). إن مكالمة ACDE، التي يستضيفها تيم بيكو من مؤسسة Ethereum، عبارة عن سلسلة من الاجتماعات نصف شهرية حيث يقوم فريق عملاء Ethereum بمناقشة وتنسيق التغييرات على طبقة تنفيذ Ethereum (EL). ناقش المطورون هذا الأسبوع التقدم المحرز في التطوير والاختبار على:
ترقية كانكون/دينيب (دينكون).
تحويل فيركل تري
تحديث تسلسل SSZ
1. ترقية كانكون
تم إطلاق Devnet #8 منذ أسبوعين في 16 أغسطس. قال بارناباس بوسا، مهندس DevOps في مؤسسة Ethereum، إن شبكة اختبار ترقية Cancun التي تركز على المطورين يبدو أنها تعمل بشكل جيد. ذكر Busa أنه يبدو أن هناك بعض المشكلات في العقد التي تقوم بتشغيل برنامج عميل Nethermind (EL). أوضح Lukasz Rozmej، مطور عميل Nethermind، أن طبيعة المشكلة كانت بسبب خطأ في التكوين في تنفيذ مجمع معاملات Blob. **(ملاحظة المترجم: Devnet 8 هي أول شبكة اختبار مخصصة، والتي تحتوي على جميع EIPs النهائية لترقية Cancun/Deneb)
فيما يتعلق بـ EIP 4788**، أعاد المطورون التأكيد لفترة وجيزة على سياسة النشر الجديدة لتغييرات التعليمات البرمجية**. سيتم نشر العقود التي تكشف بيانات سلسلة المنارات على EL مثل العقود الذكية العادية، مما يتطلب من شخص ما تمويل عنوان العقد قبل تنشيط الترقية. Devnet #9، شبكة الاختبار التالية لترقية كانكون، سوف تتبنى سير العمل هذا وتضمن أن المطورين على دراية بهذه العملية.
بدلاً من تأخير تاريخ إصدار Devnet #9، وافق المطورون على مواصلة الاختبار على Devnet #8 حتى يتم حل جميع المشكلات المتعلقة بتنفيذ العميل. "أفضل أن أثق في Devnet #9 بدلاً من القول إننا نريد أن تعمل هذه الأشياء. ... أفضل إصلاح المشكلات التي نعرفها. وإلا، إذا كانت لدينا مشكلة صعبة في Devnet #9 ، فسنقوم بذلك بالتأكيد "لدينا Devnet رقم 10 مرة أخرى، أنا لا أقول أنه لا ينبغي أن يكون لدينا Devnet رقم 10. يجب أن يكون لدينا عدد كبير من شبكات المطورين. أعتقد أنه يمكننا الآن أن نحاول جعل Devnet رقم 9 موثوقًا حقًا." قال إيثر، داني رايان، زميل في مؤسسة فانغ ورئيس المؤتمر الهاتفي لـ ACDC.
*كان الآخرون المشاركون في المكالمة، بما في ذلك Tim Beiko وMarius Van Der Wijden وJustin Florentine، يؤيدون قضاء المزيد من الوقت في اختبار Devnet #8 واختبار التغييرات لاحقًا في EIP 4788 على Devnet #9 *. اقترحت Beiko وقتًا للمطورين لإعادة عقد Devnet رقم 9 خلال المكالمة الجماعية التالية لـ ACDE. فيما يتعلق باستراتيجيات نشر شبكة الاختبار، توصي Beiko بالتسلسل التالي:
Devnet #9: Devnet آخر تم تجميد مواصفات Dencun الخاصة به. قم باختبار الشبكة وافترض أن المطورين راضون عنها، ثم انتقل إلى شبكة اختبار عامة. بخلاف ذلك، ابدأ تشغيل Devnet رقم 10.
Holesky: افصل شبكة اختبار Holeksy التي تم إطلاقها حديثًا ونشر ترقية Dencun عليها.
جويرلي: ثم قم بنشر Dencun على جويرلي. نظرًا لإطلاق شبكة الاختبار قبل الأخيرة قبل الشبكة الرئيسية، يجب أن تكون مواصفات الترقية في هذا الوقت نهائية وتزود المستخدمين والتطبيقات بوقت كافٍ لاختبار برامجهم قبل تنشيط ترقية الشبكة الرئيسية. من المحتمل أن يكون Dencun هو التفرع الأخير لـ Goerli قبل إهماله واستبداله بـ Holesky. (ملاحظة المترجم: كلمة Dencun هي كلمة مركبة مكونة من Cancun (Cancun) وDeneb. Cancun هو اسم ترقية طبقة تنفيذ Ethereum هذه، وDeneb هو اسم ترقية طبقة البروتوكول. لذلك، ترقية Cancun مدمجة مع تُعرف ترقية Deneb باسم ترقية Dencun.)
سيبوليا: أخيرًا، تم نشر دينكون في سيبوليا لتحقيق نتائج جيدة.
لم يثر أحد أي اعتراضات على اقتراح Beiko بإطلاق شبكة اختبار بعد Devnet #9. ذكرت Beiko أنه ستتم مشاركة الجدول الزمني المذكور أعلاه مع مجتمع الإيثريوم الأوسع في منشور بالمدونة بمجرد إطلاق شبكة اختبار Holesky رسميًا في 15 سبتمبر. بالإضافة إلى ذلك، قالت Beiko أن هناك أيضًا شبكة اختبار تسمى Ephemery قيد التطوير. Ehemery عبارة عن شبكة اختبار Ethereum لمشغلي عقدة التحقق والتي ستتم إعادة تعيينها إلى حالة التكوين بعد أسبوع أو أسبوعين. لمزيد من المعلومات حول شبكة Ephemery، اقرأ صفحة GitHub الخاصة بالمشروع هنا.
قبل الانتقال لمناقشة محاولات Verkle، سلط Busa الضوء على طلب سحب مفتوح (PR) على GitHub لشبكة اختبار Holesky. بناءً على طلب فريق Erigon (EL)، يقترح مسؤول العلاقات العامة إزالة وقت التنشيط المحدد لترقية Dencun على Holesky. سيقوم المطورون لاحقًا بتعيين قيمة لتنشيط Dencun على Holesky بدلاً من الكتابة فوق القيمة الحالية. أثار Busa أيضًا سؤالاً حول اختبار هدف/حد أقصى 3/6 بدلاً من حد 2/4. ** في هذا الموضوع، اقترحت Beiko طرح هذا الأمر مرة أخرى في مكالمة ACDC الأسبوع المقبل، حيث ذكر رايان أن التجارب الأخيرة بأحجام الكتل الكبيرة ستجلب رؤى جديدة. **
2. تحويل Verkle Trie
بعد ذلك، ناقش المطورون اقتراح Vitalik Buterin للجمع بين خرائط طريق Verkle Trie وState Expiry لتقليل تعقيد تنفيذ Verkle Trie وتسريع فوائد State Expiry على Ethereum. كخلفية، **Verkle Trie أو Verkle Tree عبارة عن بنية بيانات تسمح للمستخدمين بالتحقق بسهولة من كميات كبيرة من البيانات بالاعتماد على دليل تشفير واحد. **إنها لا تختلف عن Merkle Patricia Trie (MPT)، وهي بنية بيانات تستخدم لتخزين حالة Ethereum. ومع ذلك، فإن كفاءة إثبات أشجار Verkle أعلى نسبيًا من كفاءة MPT، ولهذا السبب كان المطورون يعملون على نقل MPT إلى Verkle.
**انتهاء الولاية عبارة عن مبادرة منفصلة مصممة لمعالجة مشكلة نمو الحالة غير المحدود. **الهدف من انتهاء صلاحية الحالة هو حذف أجزاء من حالة Ethereum التي لم يتمكن المستخدمون من الوصول إليها لفترة من الوقت (على سبيل المثال 365 يومًا)، وبالتالي تقليل حجم الحالة من أكثر من 100 جيجابايت إلى أقل من 50 جيجابايت. يفضل Andrew Ashikhmin من فريق حساب Erigon (EL) تجميع الترقيتين، بافتراض أن تحويل Verkle Trie سيتم تبسيطه إلى حد كبير إذا تم دمجه مع انتهاء الولاية. يشعر Guillaume Ballet من فريق عملاء Geth (EL)، الذي كان يقود مشروع Verkle Trie، بالقلق من أن يؤدي الاقتران إلى تأخير محاولات Verkle، حيث تم "التخلي" عن انتهاء صلاحية الحالة كموضوع بحث على مدار العامين الماضيين.
وتحدث بوتيرين بمزيد من المعلومات الأساسية عن دوافع اقتراحه قائلاً: "مع [Verkle] عملية النقل، تكمن المشكلة بشكل أساسي في تحويل أكثر من 50 غيغابايت من Merkle Patricia Trie إلى... Verkle Trie في شبكة حية أمر معقد للغاية. وهذا بالفعل شيء كان فريق البحث يعاني منه منذ أكثر من عام. أتذكر في العام الماضي في Devconnect، أنه كان في الأساس موضوعًا لنشاط بحثي، وبشكل أساسي تم تجميع الكثير من أعمال البحث والتطوير معًا مثل بقية خارطة طريق Verkle بأكملها، تمامًا كيف كانت عملية الانتقال الأخيرة. وفي بعض النواحي، فإن تعقيدها ينافس تعقيد عمليات الاندماج. "
** تابع بوتيرين ليقول كيف يؤدي انتهاء الولاية إلى تقليل تعقيد الانتقال إلى Verkle بشكل كبير. ومع ذلك، ذكر أيضًا أن هناك متطلبات مسبقة معقدة لانتهاء صلاحية الحالة، مثل الحاجة إلى إضافة المزيد من مساحة العنوان لدعم "فترات العناوين" الجديدة كل عام.** لذلك، على الرغم من أن تعقيد تنفيذ Verkle سيتم تقليله، إلا أن المطورين ما زالوا بحاجة لحل اللغز للقيام بالأمرين معًا، بالإضافة إلى ذلك، إذا تم تنفيذ Verkle Tries قبل انتهاء صلاحية الحالة، فسيكون لانتهاء الحالة أقل إلحاحًا، لذلك يجب على المطورين التفكير في استخدام Verkle لإجراء النقل، أو الانتظار بضع سنوات قبل تقديم Verkle ثم انتهاء الحالة. لم يكن المطورون واضحين بشأن القيمة الإضافية التي قد تنتج عن تجميع الترقيتين معًا، واتفقوا على مواصلة مناقشة الموضوع بشكل غير متزامن على Discord وVerkle Trie Implementors' Call.
3. تسلسل SSZ
بعد ذلك، قدم إيتان كيسلينج، مطور عميل Nimbus (CL)، أحدث تقدم له في ترقية هياكل بيانات Ethereum إلى تنسيق تسلسل SSZ. لمزيد من المعلومات حول هذه المشكلة، اقرأ نص المكالمة السابقة لمطوري Ethereum هنا. سلط كيسلينج الضوء على طريقة جديدة لتحديث تسلسل بيانات إيثريوم باستخدام تنسيق قائم على "PartialContainer" SSZ. ** كتب كيسلينج في التعليقات ضمن جدول أعمال المكالمة الجماعية لهذا الأسبوع، ** "يجمع هذا [التنسيق] بشكل أساسي بين جميع مزايا [التنسيق السابق] ويمكن أيضًا إعادة استخدامه لأغراض أخرى، مما يؤدي إلى التخلص من الأنواع الاختيارية SSZ Union وSSZ غير المستخدمة حاليًا ." (ملاحظة المترجم: التسلسل البسيط (SSZ) هو أسلوب التسلسل المستخدم في سلسلة المنارة. تحل هذه الطريقة محل جميع جوانب طبقة الإجماع باستثناء بروتوكول اكتشاف الأقران. يتم استخدام تسلسل بادئة الطول العودية في طبقة التنفيذ. بسيط تعتبر تصميمات التسلسل حتمية ويمكن أيضًا أن تكون Merkleized بكفاءة.)
بعد التحديث، سارعت Beiko إلى الإشادة بتطبيق EL المرجعي الذي تم إنشاؤه حديثًا في Python (المسمى EELS). في منشور مدونة حديث لمؤسسة Ethereum، كتب محرر EIP والباحث في مؤسسة Ethereum Sam Wilson: "EELS هو تطبيق مرجعي لـ Python للمكونات الأساسية لعميل تنفيذ Ethereum، مع التركيز على سهولة القراءة والوضوح. تهدف EELS إلى أن تكون خليفة روحيًا بالنسبة إلى Yellow Paper، وهي أكثر ملاءمة للمبرمجين ومتزامنة مع شوكات ما بعد الدمج، يمكن لـ EELS ملء اختبارات الحالة وتنفيذها، ومتابعة الشبكة الرئيسية، وهي مكان رائع لوضع نماذج أولية لـ EIPs جديدة.
يستخدم بعض المطورين بالفعل EELS لإعادة تنفيذ EIPs الخاصة بهم، وتقدم مؤسسة Ethereum منحة لأي شخص مهتم بتحديث الورقة الصفراء لتشمل ترقيات الشبكة المدمجة مسبقًا المفقودة مثل لندن وباريس لاستكمال EELS.