في 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 هي كلمة مركبة تتكون من كانكون (كانكون) ودينيب. كانكون هو اسم ترقية طبقة تنفيذ إيثريوم، ودينب هو اسم ترقية طبقة البروتوكول. لذلك، ترتبط ترقية كانكون بـ Deneb تسمى الترقيات بشكل جماعي ترقيات Dencun.)
سيبوليا: أخيرًا، تم نشر دينكون في سيبوليا لتحقيق نتائج جيدة.
لم يعترض أحد على اقتراح Beiko بإطلاق شبكة اختبار بعد Devnet #9. ذكرت Beiko أنه ستتم مشاركة الجدول الزمني أعلاه مع مجتمع Ethereum الأوسع في منشور مدونة بمجرد إطلاق شبكة اختبار 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.
انتهاء صلاحية الحالة هي مبادرة منفصلة مصممة لمعالجة مشكلة نمو الحالة غير المحدود. الهدف من انتهاء صلاحية الحالة هو تقليل حجم الحالة من أكثر من 100 جيجابايت إلى أقل من 50 جيجابايت عن طريق إزالة أجزاء من حالة Ethereum التي لم يصل إليها المستخدم خلال فترة زمنية معينة (على سبيل المثال، 365 يومًا). فضل 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 غير المستخدم حاليًا والنوع الاختياري SSZ. " (ملاحظة المترجم: التسلسل البسيط (SSZ) هو أسلوب التسلسل المستخدم في سلسلة المنارة. تحل هذه الطريقة محل طبقة التنفيذ المستخدمة في كل مكان في طبقة الإجماع باستثناء بروتوكول اكتشاف الأقران. التسلسل العودي مسبوق بالطول. التسلسل البسيط حتمي حسب التصميم ويمكن أيضًا أن يتم Merkleized بشكل فعال.)
بعد التحديث، سارعت Beiko إلى الإشادة بتطبيق EL المرجعي الذي تم إنشاؤه حديثًا في Python (المسمى EELS). في منشور مدونة حديث لمؤسسة Ethereum، كتب محرر EIP والباحث في مؤسسة Ethereum، سام ويلسون: "EELS هو تطبيق مرجعي لـ Python للمكونات الأساسية لعميل تنفيذ Ethereum، مع التركيز على سهولة القراءة والوضوح. تهدف EELS إلى أن تكون خليفة روحيًا لـ Ethereum Foundation." Yellow Paper، وهو أكثر ملاءمة للمبرمجين ومتزامنًا مع شوكات ما بعد الدمج، يمكن لـ EELS ملء اختبارات الحالة وتنفيذها، ومتابعة الشبكة الرئيسية، وهو مكان رائع لوضع نماذج أولية لـ EIPs جديدة.
يستخدم بعض المطورين بالفعل EELS لإعادة تنفيذ EIPs الخاصة بهم، وتقدم مؤسسة Ethereum منحة لأي شخص مهتم بتحديث الورقة الصفراء لتشمل ترقيات الشبكة المدمجة مسبقًا المفقودة مثل لندن وباريس لاستكمال EELS.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
ملخص الاجتماع التنفيذي رقم 116 لمطوري Ethereum Core: ترقية كانكون، وتحويل Verkle Trie، وتسلسل SSZ
المؤلف: كريستين كيم / المصدر:
ترجمة: 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 هي كلمة مركبة تتكون من كانكون (كانكون) ودينيب. كانكون هو اسم ترقية طبقة تنفيذ إيثريوم، ودينب هو اسم ترقية طبقة البروتوكول. لذلك، ترتبط ترقية كانكون بـ Deneb تسمى الترقيات بشكل جماعي ترقيات Dencun.)
سيبوليا: أخيرًا، تم نشر دينكون في سيبوليا لتحقيق نتائج جيدة.
لم يعترض أحد على اقتراح Beiko بإطلاق شبكة اختبار بعد Devnet #9. ذكرت Beiko أنه ستتم مشاركة الجدول الزمني أعلاه مع مجتمع Ethereum الأوسع في منشور مدونة بمجرد إطلاق شبكة اختبار 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.
انتهاء صلاحية الحالة هي مبادرة منفصلة مصممة لمعالجة مشكلة نمو الحالة غير المحدود. الهدف من انتهاء صلاحية الحالة هو تقليل حجم الحالة من أكثر من 100 جيجابايت إلى أقل من 50 جيجابايت عن طريق إزالة أجزاء من حالة Ethereum التي لم يصل إليها المستخدم خلال فترة زمنية معينة (على سبيل المثال، 365 يومًا). فضل 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 غير المستخدم حاليًا والنوع الاختياري SSZ. " (ملاحظة المترجم: التسلسل البسيط (SSZ) هو أسلوب التسلسل المستخدم في سلسلة المنارة. تحل هذه الطريقة محل طبقة التنفيذ المستخدمة في كل مكان في طبقة الإجماع باستثناء بروتوكول اكتشاف الأقران. التسلسل العودي مسبوق بالطول. التسلسل البسيط حتمي حسب التصميم ويمكن أيضًا أن يتم Merkleized بشكل فعال.)
بعد التحديث، سارعت Beiko إلى الإشادة بتطبيق EL المرجعي الذي تم إنشاؤه حديثًا في Python (المسمى EELS). في منشور مدونة حديث لمؤسسة Ethereum، كتب محرر EIP والباحث في مؤسسة Ethereum، سام ويلسون: "EELS هو تطبيق مرجعي لـ Python للمكونات الأساسية لعميل تنفيذ Ethereum، مع التركيز على سهولة القراءة والوضوح. تهدف EELS إلى أن تكون خليفة روحيًا لـ Ethereum Foundation." Yellow Paper، وهو أكثر ملاءمة للمبرمجين ومتزامنًا مع شوكات ما بعد الدمج، يمكن لـ EELS ملء اختبارات الحالة وتنفيذها، ومتابعة الشبكة الرئيسية، وهو مكان رائع لوضع نماذج أولية لـ EIPs جديدة.
يستخدم بعض المطورين بالفعل EELS لإعادة تنفيذ EIPs الخاصة بهم، وتقدم مؤسسة Ethereum منحة لأي شخص مهتم بتحديث الورقة الصفراء لتشمل ترقيات الشبكة المدمجة مسبقًا المفقودة مثل لندن وباريس لاستكمال EELS.