يتحدث Eth2 dev عن التحديات والدروس المستفادة قبل إطلاق mainnet

بعد سنوات من التأخير والتغييرات في الخطط ، يقترب إصدار Ethereum 2.0 أخيرًا في 1 ديسمبر.

تقدم Ethereum 2.0 Phase 0 الآلية التي طال انتظارها المتمثلة في الاشتراك في منصة العقود الذكية ، بالإضافة إلى إطلاق الهيكل العظمي لـ Eth2 blockchain المستقبلية ، سلسلة Beacon.

تسارعت وتيرة التقدم في عام 2020 بشكل مطرد مع إدخال المزيد والمزيد من شبكات الاختبار وتكرارها. بينما كانوا ناجحين بشكل إجمالي ، لم يتم إعفاؤهم من المشاكل المتعلقة بالمزامنة وإنتاج الكتلة.

جاء جزء من هذه المشكلات من التحدي المتمثل في الحفاظ على نفس الوتيرة بين سبعة عملاء مختلفين ، أو برنامج عقدة Ethereum 2.0 ، الذي يعمل مع لغات برمجة مختلفة وأكوام تكنولوجية.

تحدث كوينتيليغراف مع زهاري كاراجوف ، مطور الأبحاث في Nimbus – أحد هؤلاء العملاء – لمعرفة المزيد حول الطريق الذي سافره Ethereum 2.0 حتى الآن والخطوات التالية من الرحلة.

تم تحرير المقابلة بشكل خفيف من أجل الطول والسياق.

كوينتيليغراف: يبدو أن Nimbus كان لديه بعض المشكلات الأخرى في اللحاق بمواصفات Ethereum 2.0 المشتركة. لماذا تعتقد ذلك؟

زهاري كاراجوف: كنا مشغولين جدًا في إعداد نيمبوس لشبكة مينيت. من العدل أن نقول إن الأمر كان أكثر صعوبة بالنسبة لنا لأنه استغرق منا بعض الوقت لتطوير بعض المكونات التي كانت متاحة بالفعل للفرق الأخرى – وبشكل أكثر تحديدًا ، طبقة الشبكات Libp2p.

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

CT: يبدو أن Prysm و Lighthouse – اللذان تم بناؤهما على غرار عملاء Ethereum 1.0 الحاليين في Go و Rust ، على التوالي – كانا متقدمين على الآخرين حتى الآن. هل هذا لأنهم كانوا قادرين على البناء على العمل المنجز لـ Ethereum 1.0؟

ZK: سيكون تفسيري بمثابة تبسيط ، حيث توجد العديد من العوامل المعنية. لكن يمكنني القول إن تطوير Libp2p كان أهم مصدر للتأخير بالنسبة لنا. ومن السهل رؤية المنطق هنا: Teku ، الذي تم تطويره في Java ، لم يكن به تطبيق Libp2p ، وأصبح جاهزًا أيضًا في مرحلة لاحقة قليلاً.

كان فريق Prysm يتمتع برفاهية تطوير Libp2p منذ وقت طويل جدًا ، حيث تم تطويره في الأصل في Go ، بينما تمكنت Lighthouse من الاستفادة من التطبيق الذي تم إنشاؤه ، مرة أخرى ، منذ بعض الوقت من قبل فريق Parity لعمله على المنقط.

Libp2p هي طبقة الشبكات في Ethereum 2.0 – يمكنك القول إنها تقنية مختلفة تمامًا عن تلك المستخدمة في Ethereum 1.0. من الناحية العملية ، إنها تقنية اشتراك للنشر تسمى Gossipsub ، وهي طريقة محسّنة لبث المعلومات في الشبكة.

CT: دعنا نتحدث عن شبكة اختبار Medalla. ما الدروس التي تعلمها Nimbus ومجتمع Eth2 ، خاصة بالنظر إلى الفترات التي لم يكن فيها blockchain يوفر ضمانات نهائية للكتلة؟

ZK: حسنًا ، بدأت النضالات في النهاية بمشكلة فنية. هناك حادثة Cloudflare Roughtime الشهيرة ، والتي أظهرت بالضبط ما كنا نناقشه في محادثتنا السابقة. إذا كان كل شخص على الشبكة يستخدم نفس العميل ، فقد تؤدي مشكلة فنية في هذا العميل المحدد إلى وضع الكثير من المدققين في وضع عدم الاتصال ، مما قد يجعل الشبكة على الفور في حالة غير نهائية.

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

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

CT: خلال فترة testnet والفترة غير النهائية ، اشتكى بعض المستخدمين من تخفيض حصصهم حتى لو كانوا متصلين بالإنترنت. هل هذا خطأ أم سمة من سمات النظام؟

ZK: يمكنك وصفها بأنها نتيجة غير متوقعة. المشكلة في الأساس هي أن العميل يحصل على مكافأة مقابل الشهادات التي يتم بثها على الشبكة. لكن من المفترض أن يتم تضمين هذه الشهادات في كتل. إذا لم يكن هناك من ينتج الكتل ، فإن شهاداتك لا تنتهي في السلسلة. لذا ، يبدو أنك غير نشط.

أعتقد أن هذه المشكلة معترف بها جيدًا ومعترف بها من قبل فريق التنفيذ وفريق البحث. يجب معالجتها في مستقبل Ethereum – في المرحلة 1 ، أو حتى المرحلة 0.5 ، وهي واحدة من أولى ترقيات الشبكة. لكن يجب ألا ننسى أنه سيكون غير متوقع تمامًا إذا رأينا معدلات مشاركة منخفضة على الشبكة الرئيسية ، كما هو الحال عندما تكون هناك حصة حقيقية متضمنة ، فإن حوافز المدققين على الاتصال بالإنترنت تكون أقوى بكثير.

CT: هل تعتقد أن هذه التعقيدات ومتطلبات الاتصال بالإنترنت باستمرار قد تؤدي إلى إبعاد الأشخاص عن التعقيد بأجهزتهم الخاصة؟

ZK: حسنًا ، هذا مفهوم خاطئ شائع جدًا وأعتقد أنه يجب علينا القيام بعمل أفضل في التواصل. في الواقع ، إن مخاطر عدم الاتصال بالإنترنت طوال الوقت ليست كبيرة. ستحقق ربحًا إذا كنت متصلاً بالإنترنت أكثر من 50٪ من الوقت. فكر في الأمر: يمكنك أن تكون غير متصل بالإنترنت لمدة نصف العام ، وستظل عند مستوى الصفر. لن تكسب أي أموال ، لكنك أيضًا لن تخسر أي أموال. البروتوكول متسامح تماما في هذا الصدد.

CT: ماذا يأتي بعد إطلاق mainnet للمرحلة 0؟ هل تجزئة الترقية التالية في القائمة أم أنك تتوقع المزيد من العمل المطلوب لسلسلة الإشارة التنبيهية الأولية هذه؟

ZK: بالتأكيد ستكون هناك ترقيات تأتي مع تكامل المرحلة الأولى ، وستتطلب تغييرات جذرية – أو دعنا نسميها مجرد شوكة صلبة – حيث ستصدر فرق العملاء برامج جديدة مع توفير المزيد من الوظائف عبر الإنترنت. نتوقع طرح الأداة النهائية في مرحلة ما ، والتي ستنهي سلسلة Ethereum 1.0 من خلال آلية إجماع Ethereum 2.0. كل هذه الإصدارات المستمرة ستحدث بالتوازي. إنهم مستقلون قليلاً عن بعضهم البعض ويشكلون جزءًا من خارطة طريق Ethereum للسنوات القليلة القادمة.