مراجعة مؤتمر مطوري Ethereum: ترقية كانكون وهارد فورك وبراغ

المؤلف: كريستين كيم، نائب رئيس الأبحاث في Galaxy؛التجميع: قيمة سلسلة الكربون لـ Qin Jin

في 4 يناير 2024، اجتمع مطورو Ethereum في Zoom لتنفيذ جميع المطورين الأساسيين ( ACDE) على الاتصال رقم 178. إن مكالمة ACDE، التي يستضيفها عادةً قائد بروتوكول مؤسسة Ethereum، Tim Beiko، عبارة عن سلسلة من الاجتماعات نصف شهرية حيث يناقش المطورون وينسقون التغييرات على طبقة تنفيذ Ethereum (EL). تمت استضافة اجتماع هذا الأسبوع من قبل مطور مجهول من Geth EL والذي يستخدم الاسم المعروض "Lightclient". أعاد المطورون تأكيد تواريخ تفعيل شبكة الاختبار العامة الثلاثة التالية لترقية Cancun/Deneb (Dencun). كما ناقشوا أيضًا أولويات تغييرات التعليمات البرمجية (EIPs) في براغ/إلكترا، وهي ترقية الانقسام الكلي التالية بعد Dencun.

تحديث Dencun

لن تكون هناك ترقية Dencun أثناء تحديثات خاصة بالعطلات. منذ آخر مكالمة جماعية لـ ACDE في 21 ديسمبر، قام فريق العميل بإعداد إصدار جديد لشبكة اختبار Goerli. نظرًا للتأخير السابق في اختبار الترقية بسبب Prysm، طلب مطور Geth Marius van der Wijden من فريق عملاء Prysm تقديم تحديث حول التقدم الذي أحرزوه في قطع الإصدار الجديد. أكد مطور Prysm Terence Tsao أن فريق Prysm سيقوم بإعداد نسخة جديدة من شوكة Goerli الصلبة الأسبوع المقبل. ومع ذلك، فإن إصدار Goerli سيكون إصدارًا "ما قبل النشر"، مما يعني أنه لن يكون إصدار Prysm الموصى باستخدامه على شبكة Ethereum الرئيسية. بعد شوكة Goerli الصلبة، يخطط فريق Prysm لإصدار إصدار آخر مع بعض التغييرات والتحديثات، والتي يُنصح المستخدمون بتشغيلها على الشبكة الرئيسية واختبارها على شبكات اختبار Sepolia أو Holesky.

بينما ذكر Tsao أن فريق Prysm مرتاح لتاريخ تفعيل شوكة Goerli الصلبة في 17 يناير، كما تمت مناقشته في ACDE #177، فقد اقترح أن تاريخ التنشيط سيتم تحديد شوكة Sepolia وHolesky الصلبة بعد شوكة Goerli الصلبة. منذ ACDE #177، اقترح تيم بيكو، رئيس دعم البروتوكول في مؤسسة إيثريوم، أوقات شوكة اختبار عامة لشبكات اختبار إيثريوم العامة الثلاثة: Goerli وSepolia وHolesky. وقت تنشيط الشوكة الموصى به هو كما يلي:

Goerli--17 يناير 2024--Era 231680--Timestamp 1705473120

Sepolia--30 يناير 2024--عصر 132608--الطابع الزمني 1706655072

Holesky--7 فبراير 2024--العصر 29696—الطابع الزمني 1707305664

سأل Lightclient فرق العملاء الأخرى خارج Prysm إذا وافقوا على وقت التنشيط المقترح من Beiko للشوكة الصلبة Goerli. أكدت جميع فرق العملاء المشاركة في المكالمة (بما في ذلك Geth وLodestar وLighthouse وTeku وBesu) أنهم يشعرون أن التوقيت مناسب لإصدار إصدار لمشغلي عقدة Goerli الأسبوع المقبل على أبعد تقدير. لاحظ فريق عملاء Lighthouse أنه نظرًا لأنهم ما زالوا يختبرون بعض ميزات الشبكات لعملائهم، فإن الإصدار الذي يطلقونه قد يكون إصدارًا ما قبل النشر مثل Prysm.

اختلاف الخط الزمني لـ Dencun

في وقت لاحق، ناقش Lightclient مناقشة Sepolia وقت التنشيط الموصى به لشبكة اختبار Holesky. اقترح مطور Prysm (اسم مستعار) يحمل الاسم عبر الإنترنت "Potuz" تأخير تحديد مواعيد الترقية لآخر شبكتين اختباريتين قبل الشبكة الرئيسية. "يجب أن نحاول عدم الالتزام بموعد الآن لأن الأمور قد لا تسير على ما يرام مع جويرلي والعودة من هناك مشكلة. سيكون من السهل إضافة إصدار جديد بالعصر الصحيح وعدم إجراء أي تغييرات. سيكون الأمر أسهل وقال بوتوز: "حذف إصدار وإصلاح الأخطاء، هذه مشكلة. إنها أطول بكثير من بضعة أسابيع".

أكد Lightclient أن فريق العميل لا يحتاج إلى إصدار إصدار جديد إلا بعد أسبوع من الانقسام الصعب لـ Goerli، لذلك ما لم يكن على Goerli في 24 يناير أو تم العثور على مشكلات في الترقية لاحقًا، وإلا فلن يتم حذف الإصدار الجديد بالضرورة. قال مطور Geth Marius van der Wijden إنه لا يرى أي ضرر في تحديد تواريخ لشبكات اختبار Sepolia وHolesky، حيث يمكن للمطورين تغيير التواريخ في أي وقت إذا ظهرت مشاكل على Goerli.

كتب بارناباس بوسا، مهندس DevOps في مؤسسة Ethereum، في غرفة الدردشة Zoom أنه في رأيه، فقط بعد التأكيد بعد أن تعمل نسخة Goerli بشكل طبيعي، من الضروري إصدار إصدارات جديدة لترقيات Sepolia وHolesky. وافق مطور Lighthouse الذي يستخدم الاسم عبر الإنترنت "Sean"، قائلًا إنه يمكن للمطورين تحديد تاريخ "مؤقت" للانقسام الصلب لـ Sepolia، ولكن يجب عليهم أولاً رؤية تقدم Goerli قبل 30 يناير.

يوصي بوتوز بإضافة أسبوع من الاختبار بين عمليات تنشيط الشوكة الصلبة لـ Goerli وSepolia، وذلك باستخدام أسبوعين للتحليل بشكل أساسي بدلاً من ثلاثة. وقال إن إضافة أسبوع من وقت الاختبار يسمح لإصدار العميل "بالنقع" لبضعة أيام قبل أن يحتاج فريق العميل إلى قطع إصدار جديد مرة أخرى لترقية شبكة الاختبار التالية. "أسبوعان قريبان جدًا. هذا ما أشير إليه." وأضاف بوتوز أنه إذا تم تحليل واختبار توزيع عميل Goerli بالكامل، فقد لا يستغرق الأمر ثلاثة أيام بين تنشيط الانقسام الصلب لـ Sepolia و Holesky. وقت الاستجابة الأسبوعي.

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

يتفق Lightclient مع ديتريش. ويعتقد أنه إذا تم إجراء المناقشات في وقت مبكر من شهر أكتوبر، فمن المرجح أن يكون المطورون أكثر تسامحًا مع تمديد جدول اختبار Dencun. قال Lightclient: أعتقد أن جزءًا من ذلك هو أننا أردنا إكمال الترقية في الخريف الماضي، والآن بعد أن نحاول حقًا تحقيق هذا الهدف، أعتقد أن جدولنا الزمني يجب أن يكون أكثر عدوانية قليلاً.

التزم بجدول زمني صارم

وفقًا لإرشادات المطور وفقًا للآراء التي تمت مشاركتها في المؤتمر عبر الهاتف، اقترح باريثوش جايانثي، مهندس مؤسسة DevOps في Ethereum، تأجيل ترقية الانقسام الصلب لـ Sepolia لمدة أسبوع تقريبًا وتحديد تاريخ الانقسام الصلب لـ Sepolia في مؤتمر عبر الهاتف ACDE في 25 يناير بعد ترقية Goerli. اعترض ماريوس فان دير فيدن على الاعتماد كليًا على استدعاء ACDE لإعادة التفاوض بشأن تاريخ تنشيط ترقية شبكة الاختبار. وقال: "ما أريد تجنبه حقًا هو أن نضطر إلى إجراء مكالمة أخرى مع All Core Devs لتأكيد التاريخ"، مضيفًا: أنا أكره الاضطرار إلى إجراء مكالمة أخرى مع All Core Devs فقط لأقول، "حسنًا، Sepolia متاحة الآن". لقد بدأ الأمر." علينا الآن أن ننتظر أسبوعين قبل أن نتمكن فعليًا من البدء في تنفيذ مشروع سيبوليا.

لتهدئة مشاعر جميع الأطراف، اقترح مطور Geth Guillaume Ballet إنشاء مجموعتين من التواريخ المبدئية للشوكة الصلبة Sepolia، في حالة نتيجة الانقسام الصلب في Goerli إذا كانت نتيجة الانقسام الصعب في Goerli سلبية، فيمكن للمطورين الالتزام بمجموعة واحدة من التواريخ؛ وإذا كانت نتيجة الانقسام الصعب في Goerli سلبية، فيمكن للمطورين الالتزام بمجموعة أخرى من التواريخ. ومع ذلك، يعارض كل من Lightclient وDietrichs هذه الفكرة لأنه يجب تقييم طبيعة الأخطاء والمشكلات في Goerli أولاً قبل أن يتمكن المطورون من تعيين جدول زمني جديد للانقسام الصلب لـ Sepolia.

بالمناسبة، سأل أحد المطورين بالاسم المستعار "Danceratopz" في فريق اختبار مؤسسة Ethereum عما إذا كان المطور يريد الانتظار حتى يتم تقييم Goerli. مشاكل على الشبكة قبل ترقية Sepolia. كخلفية، يشير انتهاء صلاحية النقطة إلى إزالة بيانات النقطة من حالة الإيثريوم بعد أسبوعين تقريبًا.

يفضل كل من Sean من Lighthouse وJustin Florentine من فريق Besu تقييم انتهاء صلاحية النقطة على إحدى شبكات الاختبار الثلاث قبل تنشيط Dencun على الشبكة الرئيسية. وأكد فلورنتين أن انتظار انتهاء صلاحية النقطة الكبيرة على شبكة الاختبار سيساعد أيضًا فريق بروتوكول الطبقة الثانية ومطوري التطبيقات على الاستعداد لترقية Dencun. قال Sean من Lighthouse إنه على الرغم من أن ملاحظة انتهاء صلاحية النقطة على Goerli ليس ضروريًا، فقد يكون ذلك سببًا لتمديد فترة الاختبار بين Sepolia وHolesky حتى يتمكن المطورون وفرق المستوى الثاني من المرور عبر النقطة بأكملها في دورة حياة Sepolia. لم يتفق المطورون الآخرون المشاركون في المكالمة بشكل صريح مع اقتراح شون.

بدلاً من ذلك، سأل Lightclient المطورين في المكالمة الجماعية عما إذا كانوا سيلتزمون بالجدول الزمني المقترح من Beiko لترقية Sepolia في 30 يناير، يليه بعد أسبوع ترقية Holesky في 7 فبراير. بشكل يومي. نظرًا لعدم وجود خلافات أخرى بين المطورين، قال Lightclient أن المطورين سيلتزمون بالجدول الزمني الأصلي. كتب بوتوز في دردشة عبر تطبيق Zoom أنه يأمل في ترقية كل من شبكتي الاختبار Sepolia وHolesky في 7 فبراير، بدلاً من ترقية الأولى قبل أسبوع. في رسالة Discord بعد المكالمة، أكد Lightclient مجددًا أن جدول اختبار Dencun الخاص بـ Dencun لم يتغير في الوقت الحالي.

براغ/إلكترا

بعد ذلك، يناقش المطورون ما هي خطط EIP يجب إعطاء الأولوية للترقية التالية (براغ/إلكترا) بعد تثبيت Dencun. قال ماريوس فان دير فيجدين إنه يجب على المطورين التركيز على استكمال ترقية شجرة Merkle الخاصة بشركة براغ/إلكترا بدلاً من خطط الاستثمار المعززة الأخرى. وأضاف لهذا الرأي تحذيرين، الأول هو جاهزية شجرة ميركل. كما تمت مناقشته في ACDE #177، يخطط المطورون لاستدعاء ACDE مخصص للتعمق في تفاصيل تنفيذ شجرة Merkle واستعدادها لترقيات الانقسام الكلي.

الاعتبار الثاني الذي ذكره Van der Wijden هو القدرة على فصل ترقيات EL عن طبقة الإجماع (CL). ذكر Van der Wijden أن هناك بعض خطط EIP "ذات الأولوية العالية والعاجلة للغاية" على CL والتي قد يلزم تنفيذها بشكل أسرع من ترقية شجرة Merkle على EL. "أعتقد أنه من المهم أن يناقش أعضاء طبقة الإجماع ما إذا كانوا بحاجة إلى إجراء انقسام جذري لهذه التغييرات [الطارئة]، أو ما إذا كان من الممكن القيام بذلك دون مشاركة EL، أو ما إذا كانت مشاركة EL مطلوبة، وهو ما نحتاجه على أي حال. ثم يمكنني العيش مع شوكة صلبة أصغر. وقال فان دير فايدن: "لذا فإن شجرة ميركل هي بالتأكيد أولوية قصوى وعلينا أن ندفع من أجلها مع وضع هاتين النقطتين في الاعتبار".

أنسغار، الباحث في مؤسسة إيثريوم كتب ديتريش في غرفة دردشة على برنامج زووم أنه "يعارض بشدة" تركيز ترقية براغ/إلكترا على شجرة ميركل بسبب المخاوف بشأن شجرة ميركل. ومن المرجح أن يعني تعقيد التغييرات البرمجية المطلوبة لأشجار كير أن الترقية ستتم. تأجيلها حتى عام 2025. يتفق مطور عملاء Nethermind Lukasz Rozmej مع ديتريش. وقال روزميج: "تخبرني تجربتي أن إعادة تصميم الدولة أمر صعب للغاية ويستغرق وقتًا طويلاً للغاية"، مضيفًا: "بينما أعتقد أن أشجار ميركل جيدة جدًا ويتم إحراز تقدم كبير، أعتقد أنه إذا ركزنا فقط على ميركل، فإن الأمر سيستغرق وقتًا طويلاً". سيكون الهارد فورك التالي بعد عام على الأقل، إن لم يكن أطول. لذا فإن اقتراحي هو ربما التركيز على بعض الهارد فورك الأصغر بينما يعمل كل فريق على ميركل وتخصيص الموارد المناسبة، وعبء العمل، والقوة العقلية، أو أي شيء تريد تسميته. إلى هذا الموضوع."

التركيز على ميركل

المطورين لا أتفق حول ما إذا كان يجب على براغ/إلكترا التركيز على ميركل أو إعطاء الأولوية لتغييرات أصغر في الكود يمكن إصدارها بشكل أسرع من إصدار ميركل. وشدد باليه على أنه في رأيه، "لا توجد تشعبات ثانوية"، وكلما طال انتظار المطورين قبل تنفيذ Merkle، كلما أصبح تنفيذ تحديثات حالة Ethereum أكثر صعوبة. اقترح Tomasz K. Stańczak، وهو أيضًا مطور عميل Nethermind، نهجًا طموحًا، يلتزم فيه ببرامج EIP أكثر مما قد تتضمنه شركة براغ/إلكترا. [دعونا] نستفيد من قدرات فريقنا، وفي هذا العام علينا أن نثبت أننا قادرون على التعامل مع أكبر التحديات التي نواجهها. وإذا أشارت ميركل أخيرا للفريق إلى أن المزيد والمزيد من الصعوبات تتراكم بحلول شهر مارس/آذار، فقد يثير الناس الأسئلة مرة أخرى ويقولون "حسنا، ميركل رحلت". لكننا سنستمر في استخدام مجموعة جيدة جدًا من خطط الاستثمار الأوروبية الأخرى التي سندرجها، كما قال ستانتشاك، موضحًا أنه بالإضافة إلى ميركل، هناك بعض خطط الاستثمار الأوروبية المهمة الأخرى التي قد تتضمنها براغ/إلكتر، مثل تلك المتعلقة بالملكية وإعادة التخصيص والملكية. EIP المتعلقة بتجريد الحساب.

ردًا على سؤال Stańczak، قال Lightclien أنه بعد التزام المطورين بمجموعة من EIPs، قد يكون من الصعب مواصلة مناقشة أي EIPs يجب تضمينها في براغ / إلكترا: إحدى خطط الاستثمار الأوروبية (في إشارة إلى ميركل) هي "مشروع سيستغرق من 18 إلى 24 شهراً". فضل أندرو أشيخمين، مطور عميل Erigon، إطلاق EIP أصغر في شوكة براغ/إلكترا أثناء تطوير Merkle لاستخدامه في الشوكات اللاحقة. أيد باليه اقتراح Stańczak بالتركيز على تطوير Merkel في براغ/إلكترا وإزالتها من الترقية إذا تبين أن المشكلات الرئيسية في تنفيذها تتطلب مزيدًا من الوقت لحلها.

التركيز على ترقية CL

حول EL (طبقة التنفيذ ) ومشكلة فصل ترقية CL (طبقة الإجماع)، ذكر بوتوز أن براغ/إلكترا لديها اقتراح EIP واحد فقط يتطلب فقط تغييرات على CL. "التغيير الوحيد هو إلغاء لوحة فهرس الشهادات... وجميع التغييرات الأخرى، حتى تلك التي يبدو أنها تتضمن CL فقط، مثل Max EB، تعتمد على تغييرات أخرى في EL. لذلك أعتقد أن شوكة CL البحتة هي "لن يحدث ذلك. على الأقل، لا أعتقد أنه سيحدث هذا العام، وليس العام المقبل. وقال بوتوز: "ليس لدينا ما يكفي من مقترحات CL النقية".

على الرغم من ذلك، قال Ansgar Dietrichs أن بعض EIPs هي في الأساس ترقيات تتمحور حول CL والتي تتطلب فقط تغييرات طفيفة على EL ويمكن لفريق عميل EL التنفيذ بسهولة. لا تزال خطط EIP هذه تتطلب EL وCL لتنسيق عملية الانقسام الكلي. أضاف ديتريش لاحقًا أنه يعتقد أن أخذ عينات توفر البيانات (DAS) هو أهم تغيير في الكود بعد EIP 4844 من منظور CL. لدى ديتريش وLightclient بعض الخلافات حول ما إذا كانت DAS تتطلب عملية انقسام كلي ليتم تنفيذها.

متابعة EOF وEIPs الأخرى

اسم الشبكة A يعمل المطور تحت الاسم المستعار "Rodiazet" ضمن فريق Ipsilon التابع لمؤسسة Ethereum، والمخصص للبحث في جهاز Ethereum Virtual Machine (EVM). كخلفية، EOF هو اختصار لتنسيق كائن EVM، وهو عبارة عن سلسلة من التحسينات على EVM التي تم اعتبارها في الأصل لتضمينها في ترقية Cancun/Deneb.

بالإضافة إلى ميركل، اقترح المطورون أيضًا بعض EIPs الأخرى للنظر فيها، مثل EIP 5920 (رمز تشغيل PAY) وEIP 2537 (عملية منحنى BLS12-381 المترجمة مسبقًا) ). يمكن العثور على القائمة الكاملة لبرامج EIP المرشحة لبراغ/إلكترا في سلسلة ميتا للترقية على موقع Ethereum Magician. في حين أن معظم المطورين يؤيدون إعطاء الأولوية لميركل إلى حد ما بعد كانكون/دينيب، فمن غير الواضح إلى أي مدى ينبغي إعطاء الأولوية لميركل لبراغ/إلكترا على تلك الموجودة في خطط الاستثمار الأوروبية الصغيرة لعام 2024 والتي يمكن تنفيذها بشكل أسرع وأسهل. أكد Lightclient على أن المطورين لا يحتاجون إلى اتخاذ قرارات نهائية بشأن محتوى براغ/إلكترا خلال المؤتمر الهاتفي هذا الأسبوع. واقترح مواصلة المناقشة حول هذا الموضوع خلال المؤتمر الهاتفي القادم لـ ACDE.

تحدث المطورون بسرعة عن EIPs في موضوع براغ/إلكترا الذي لم تتم مناقشته بعد في المكالمة، بما في ذلك على سبيل المثال لا الحصر، EIPs التالية:< /p>< p style="text-align: left;">EIP-7002: يمكن أن تؤدي طبقة التنفيذ إلى الخروج

< strong>EIP- 7549: نقل فهرس اللجنة خارج نطاق الشهادة

EIP-3074: أكواد تشغيل AUTH وAUTHCALL

EIP-6110: توفير إيداعات المدقق على السلسلة

< strong>EIP-6913: تعليمات SETCODE

EIP-7377: معاملة الترحيل

EIP-4444: ربط البيانات التاريخية في عميل التنفيذ

EIP -6404: جذر معاملة SSZ

EIP-6465: جذر استخراج SSZ

EIP-6466: جذر إيصال SSZ

EIP-7212: الترجمة المسبقة لدعم المنحنى secp256r1

للحصول على نظرة عامة تفصيلية حول طرق عرض EIP المذكورة أعلاه، يرجى الاطلاع على تسجيل المكالمات الكامل المنشور على YouTube.

تم تأكيد EIP 7587 رسميًا

وأخيرًا، Ethereum أعاد كارل بيكهوزن، الباحث في Fund Society، إحياء المناقشات حول EIP 7587، والذي سيحتفظ بمجموعة من العناوين المجمعة مسبقًا للاستخدام بواسطة بروتوكولات الطبقة الثانية. سأل Beekhuizen المطورين عن أفضل السبل لإضفاء الطابع الرسمي على EIP إلى EIP معلوماتي يخلق معايير لعمليات حوكمة Ethereum المستقبلية. اقترح أحمد بيطار، مطور Nethermind، دمج EIP في وثيقة EIP 1، التي تحدد المبادئ التوجيهية لعملية EIP. يوصي Lightclient بمناقشة هذا الموضوع بشكل أكبر على موقع Ethereum Magician وإعادة النظر فيه حسب الحاجة خلال مكالمة ACDE التالية.