موجز أحدث اجتماع للمطورين الرئيسيين في إثيريوم: تنشيط PeerDAS ، زيادة حد الغاز للبلوب

كتبه: كريستين كيم

ترجمة: لوسي، بلوكبيتس

تحرير: يُعقد اتصال ACDC لجميع مطوري النواة في Ethereum كل أسبوعين، حيث يتم مناقشة وتنسيق التغييرات على طبقة الإجماع في Ethereum. يركز اجتماع ACDC الحالي على إعداد شبكة اختبار Pectra Devnet 1 و PeerDAS Devnet 1 واقتراحات تحسين الإيثيريوم (EIPs) لـ Simple Serialize (SSZ).

تمت مناقشة المطورين بشأن صيانة حزم البرامج ومسائل EIP بما في ذلك عمليات التسمية والترقية لطبقة الاتفاق الجديدة لـ Ethereum، بالإضافة إلى تقدم التنفيذ تحت مواصفات Electra وتأثير تغييرات شبكة PeerDAS على معالجة وتحقق بيانات عقدة Ethereum والمشاكل الهندسية المعقدة المتعلقة بزيادة حد الغاز للتطبيق اللزج.

قامت Christine Kim ، نائبة رئيس بحوث Galaxy Digital ، بتسجيل نقاط الجدل في هذا الاجتماع بالتفصيل ، وسيتم ترجمة النص الأصلي من قبل BlockBeasts كما يلي:

في 13 يونيو 2024، اجتمع مطورو إثيريوم عبر Zoom لحضور اجتماع الاتفاق الأساسي لجميع المطورين (ACDC)Call #135. اجتماع ACDC هو سلسلة اجتماعات تُعقد كل أسبوعين، يديرها الباحث في مؤسسة إثيريوم، أليكس ستوكس، حيث يناقش المطورون وينسقون التغييرات على طبقة الاتفاق في إثيريوم (CL، المعروفة أيضًا باسم سلسلة البيكون). هذا الأسبوع، ناقش المطورون استعدادات Pectra Devnet 1، PeerDAS Devnet 1، وشبكة اختبار مخصصة ثالثة لاقتراحات تحسين الايثيريوم (EIPs) لتقنية السلسلة البسيطة (SSZ).

الإعلان

بدأ المطورون الاجتماع بإعلانين. أعرب Parithosh Jayanthi، مهندس تشغيل وصيانة في مؤسسة إيثريوم، عن أن فريق ethPandaOps، وهو فريق من المهندسين الذين يعملون في مؤسسة إيثريوم لتطوير وصيانة تشغيل إيثريوم (EF DevOps)، سيتولى صيانة وتطوير وحدة Kurtosis لحزمة إيثريوم. تم استخدام هذه الحزمة في الماضي من قبل المطورين لتشغيل شبكة اختبار إيثريوم وأدوات ذات الصلة، مثل لوحة بيانات Grafana المستخدمة لرصد واختبار تنفيذات العملاء المختلفة. قد يؤثر هذا التغيير على المستخدمين أثناء عملية نقل الحزمة من فريق Kurtosis إلى فريق ethPandaOps، حيث أن بعض الروابط ستتم إعادة توجيهها إلى مستودع GitHub الذي يديره فريق ethPandaOps بدلاً من فريق Kurtosis. يقترح Jayanthi على المستخدمين تحديث روابط البرامج الخاصة بهم ومتابعة إصدارات البرامج الجديدة التي ينشرها فريق ethPandaOps.

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

إليكترا

مواصفات التعليمات البرمجية للإصدار الرئيسي التالي من Electra ، v1.5.0-alpha.3 ، على وشك الانتهاء. وافق المطورون على دمج طلب السحب (PR) # 3768 من مستودع GitHub لمواصفات الإجماع في الإصدار التالي. تم إنشاء طلب السحب بواسطة مطور Nimbus Etan Kissling ، الذي أشار إلى أنه يجب إلحاق حقل “اللجنة \ _bits” بنهاية “التصديق” بدلا من منتصف البيانات لتجنب مشكلات التسلسل البيانات. بالإضافة إلى PR # 3768 ، سأل ستوكس عما إذا كانت هناك أي مشكلات معلقة أخرى تحتاج إلى معالجة قبل الإصدار الرئيسي التالي من مواصفات إلكترا. ذكر Jayanthi في دردشة Zoom أن هناك بعض المشكلات المفتوحة المتعلقة بتكامل المدقق التي يتم تشغيلها عبر طبقة التنفيذ (EL). وثق ستوكس متابعة حالة تكامل المدقق الذي تم تشغيله بواسطة EL بعد الاجتماع.

بخصوص التطورات في تنفيذ مواصفات Electra الأحدث، صرح معظم فرق عملاء طبقة الاتفاق (CL) خلال الاجتماع بأنهم قادرون على إعداد إصدار جديد للاختبار في غضون أسبوعين إلى أسبوعين ونصف بعد التأكد النهائي من v1.5.0-alpha.3. اتفق المطورون على إعادة مناقشة جدول زمني لشبكة Pectra Devnet 1 التالية خلال بضعة أسابيع.

بيرداس

فيما يلي، ناقش المطورون تقدم تنفيذ PeerDAS. PeerDAS هو تحسين شبكة Ethereum سيعزز قدرة العقد على معالجة والتحقق من كميات كبيرة من البيانات التي يتم تقديمها عبر تدفق blob بشكل تعسفي. ركز ستوكس على القرارات التي اتخذت في اجتماع ACDC السابق، وهي أن المطورين سيواصلون تطوير PeerDAS بشكل متزامن مع Pectra EIPs الأخرى، من خلال تنفيذ دورة تنشيط منفصلة لـ PeerDAS على شبكة التطوير.

قال مطور Lodestar Gajinder Singh إن المطورين سيقومون بتنشيط PeerDAS على شبكة التطوير المنفصلة عن شبكة التطوير الأخرى التي تم فيها ترقية Deneb استنادًا إلى المناقشة في الاجتماع الأخير حول PeerDAS. وقال مطور Teku Enrico Del Fante إنه من الأسهل بالنسبة للمطورين بناء PeerDAS على المواصفات الثابتة التي تم تحديدها في ترقية Deneb السابقة لإيثريوم بدلاً من المواصفات المتغيرة باستمرار في Pectra. ووافق Jayanthi على أن تنفيذ PeerDAS الآن مع تنفيذات Pectra EIP الأخرى قد يسبب مشاكل معقدة أثناء عمليات الاختبار، خاصة عند محاولة تحديد مصدر الأخطاء. واقترح فصل هاتين العمليتين ثم دمجهما بعد استقرار تنفيذ كل منهما. وأكد Stokes على أن المطورين يمكنهم مناقشة دمج PeerDAS مع تنفيذات Pectra EIP الأخرى مرة أخرى بعد حوالي شهر.

بالنسبة لبدء موضوع PeerDAS Devnet 1 ، لا يوجد تقدير دقيق من الفريق العميل حول متى سيكونون جاهزين لبدء الشبكة التجريبية. تقديرات الأفراد في الاجتماع تتراوح تقريبًا بين 2 أسبوع وشهر واحد. اقترح Stokes أنه بعد بضعة أسابيع ، عندما يكون لفريق العميل وقت أكثر لتنفيذ PeerDAS ، يجب إعادة مناقشة جدول زمني للشبكة التطويرية.

ثم، أشار بيكو إلى أن PeerDAS هو تحسين للشبكة وليس تغييرًا في بروتوكول Ethereum الأساسي، ولكنه لا يزال يأمل في تضمين تغييرات الشفرة في EIP-العنصر الفرعي لترقية Pectra. يعد مستند EIP-العنصر الفرعي قائمة بجميع التغييرات الأساسية في بروتوكول Ethereum المضمنة في الترقيات. أشار بيكو إلى أن PeerDAS هو أكبر ميزة في Pectra، على الرغم من أنه لا يتطلب تفعيل شوكة صلبة، يجب أن يتم تضمينه في المستند لإظهار استعداد المطورين لتفعيله في Pectra الشبكة الرئيسية عند الاستعداد الكامل في الوقت المناسب. لا يوجد معارضة لهذا.

زيادة حد الغاز للتجزئة

PeerDAS غير الطريقة التي تتعامل بها العقد عبر طبقة الشبكة النقية مع بيانات النقل والمعالجة على شبكة الإيثيريوم. لكي يستفيد المستخدمون، وخصوصاً مجموعات rollups في Layer-2، من هذه التغييرات، يجب على المطورين زيادة الحد الحالي لكل كتلة من ستة مجموعات blobs إلى حد أعلى، مما سيسمح بزيادة تدفق مجموعات blobs (البيانات العشوائية) بشكل أكبر. تغيير حدود blobs يتطلب تعديلًا على بروتوكول الإيثيريوم الأساسي، كما تم مناقشته من قبل المطورين في اجتماع هذا الأسبوع، وقد ينطوي ذلك على عمل هندسي أكثر تعقيداً من بسيط ضبط قيمة ثابتة في تكنولوجيا البروتوكول.

اقترح ستوكس في تغيير حدود الغاز للكتلة ، فصل الاعتماد بين طبقة التنفيذ (EL) وطبقة الاتفاق (CL). حاليًا ، أي تغيير في حدود الغاز للكتلة يتطلب تغيير بروتوكول EL و CL. اقترح ستوكس بعض الطرق لكسر هذه العلاقة التبعية ، مما يتيح للمطورين إزالة حدود الغاز المشفرة بشكل صلب من EL بشكل آمن والسماح لـ CL بتحديدها بالكامل. أشار باحث في مؤسسة إثيريوم (EF) دانكراد فيست إلى أن تغيير حدود الغاز للكتلة يؤثر أيضًا على حساب الغاز في الكتلة بشكل متسلسل بين EL و CL. فيست قال: “أفضل طريقة هي تغيير طريقة الحساب. قد يكون حساب سعر الغاز في EL خطأ. يجب أن يكون ذلك في CL ، ولكن الآن تغيير ذلك أصعب. … هذا ليس سهلاً.”

وافق المطورون على مواصلة التحقيق في أفضل طريقة لتغيير قيود غاز الكتلة وحساب الغاز في الكتلة. وافق المطورون أيضًا على مواصلة مناقشة ما إذا كان تنشيط PeerDAS في Pectra سيترافق مع زيادة في قيود غاز الكتلة. هناك تباين في رأي المطورين حول ما إذا يجب دمج هذه التغييرات معًا أم إجراء تنفيذ متعدد للشوكة الصلبة في مراحل متعددة.

قال Jayanthi إن الجمع بين هذه التغييرات كان قرارا “محفوفا بالمخاطر” لأن المطورين لن يعرفوا كيف ستؤدي PeerDAS حتى يتم تفعيلها على الشبكة الرئيسية. وأضاف برنابا بوسا ، مهندس DevOps في مؤسسة إثيريوم (EF) ، أن نطاق هارد فورك Pectra كبير بالفعل لدرجة أنه لا توجد حاجة إلى تغييرات إضافية في التعليمات البرمجية. قال بوسا: “النقطة المهمة هي أن لدينا بالفعل الكثير من طويل EIPs ، وأشعر أننا نضيف باستمرار المزيد من المحتوى طويل حتى لا ينتهي أبدا”. لذا، علينا أن نرسم خطا في مكان ما، وهنا ننتهي. لا أعتقد أنه من الممكن إطلاق PeerDAS وزيادة عدد النقط في العام ونصف العام المقبلين من الاختبار ".

يوصي مطور بشاشة اسمه “Francesco” بإزالة PeerDAS لـ Pectra لتقليل المخاطر في حالة عدم زيادة عدد البلوبات مع تغير الشبكة. يسأل Francesco: “ما هي فوائد PeerDAS لـ Pectra إذا لم يتم زيادة عدد البلوبات؟”

لتوضيح صعوبة اختبار PeerDAS بشكل أكبر، أشارت جايانثي إلى أن اختبار تقديم blobs إلى Ethereum من خلال EIP 4844 لا يحاكي تمامًا أداء ال blobs على الشبكة الرئيسية لـ Ethereum وتأثيرها. وقالت جايانثي: “المشكلة تكمن في صعوبة الشبكة التجريبية. لقد قمنا بالفعل بالكثير من الاختبارات المتعلقة بـ 4844، ولكن أداء ال blobs على الشبكة الرئيسية ليس متطابقًا تمامًا مع أدائها في الاختبار. لقد شاهدنا مشاكل في العقد الضعيفة، وشاهدنا تحديات زمنية وما إلى ذلك، وهذا هو السبب في رأيي في أنه يجب علينا القيام بذلك خطوة بخطوة بدلاً من إكمالها مرة واحدة.”

قام الباحث EF Ansgar Dietrichs بتعليق يقول إن ربط زيادة كمية الكتلة مع PeerDAS خطأ، لأنه بالفعل يطلب من المطورين اختيار قيمة كتلة واحدة فقط. على الرغم من أن المطورين يمكنهم اختيار نفس العدد الموجود على شبكة Ethereum الرئيسية، إلا أن القرار بشأن الرقم الذي يجب أن يستخدمه PeerDAS يجب أن يتخذ. السبب الوحيد لاختيار نفس الرقم هو زيادة تعقيد PeerDAS للسماح بالتراجع إلى آلية انتشار الكتلة الموجودة في تخصيص Deneb الحالي عند حدوث خطأ. وأضاف Dietrichs أن القلق بشأن تعقيد الاختبار يؤكد مزيدًا من وجهة نظره بأنه يجب تنشيط Pectra من خلال تحقيق فصل الشبكتين الصلبتين بدلاً من واحد، ولكن هذا لا يعني أنه يجب فصل تغيير كمية الكتلة عن PeerDAS.

تحديث SSZ

قام كيسلينج بمشاركة تحديثات تقدمية لثلاث مقترحات تحسين للشوكة الصلبة ذات الصلة بـ SSZ. وأشار إلى أن العمل الفعلي على تنفيذ هذه المقترحات قد بدأ بالفعل على عدة عملاء، بما في ذلك تيكو وجراندين وليتهاوس. وأوضح أن المطورين يمكنهم الآن بدء مناقشة جداول زمنية لشبكة تطوير هذه المقترحات المتعلقة بـ SSZ، وقد يتم تضمينها في ترقية بيكترا في الاجتماع القادم لـ ACDC.

تسمية F-Star

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