تم إسقاط تقرير آخر - تقرير 8/4 PeerDAS Devnet من Sunnsyide Labs هنا! هل تشعر بالفضول لمعرفة كيفية تصرف العقد في ظروف نمط الإنتاج باستخدام PeerDAS؟ 🧵

هذه المرة ، قامت Sunnyside Labs بتشغيل نوعين من devnets بناء على صورة fusaka-devnet-2 الخاصة ب @ethPandaOps ، للتحقق من استقرار الشبكة في بيئة أكثر واقعية: 1. Interop devnet (عملاء CL / EL مختلطين مع 50٪ supernode) 2. Perfect PeerDAS devnet (تحتفظ كل عقدة حصريا بعمود بيانات فريد)

لكل تكوين devnet ، قمنا بتشغيل 3 سيناريوهات اختبار جديدة عليه: 1. النقط مع Txs كبيرة هذا للتحقيق في كيفية تأثير الحركات المنتظمة على منافسة انتشار الكتلة مع انتشار عمود البيانات عبر العقد. لقد حافظنا على كل كتلة في الاختبار للوصول إلى 22 ميجابايت (حجم كتلة 2 ميجابايت). 2. حد النطاق الترددي + Txs كبير يهدف هذا الاختبار إلى التحقيق في سلوك الشبكة في ظروف العقد محدودة النطاق الترددي مثل المخزنين المنزليين. النطاق الترددي هو اضبط على 100/50 ميجابت في الثانية للعقد الفائقة و 50/25 ميجابت في الثانية للعقد الكاملة ، وفقا للتوصيات من EIP-7870. 3. اختبار Genesis Sync يتم اختبار مزامنة Genesis عبر devnets لمعرفة أي حاصرات أو أخطاء في عملية المزامنة. فيما يلي الأفكار التي حصلنا عليها من هذه الاختبارات:

1 - المعاملات الكبيرة لها تأثير منخفض على الشبكة ، في ظل شبكة غير مقيدة في كل من Interop Devnet و Perfect PeerDAS Devnet ، صمدت الشبكة أمام 60 نقطة دون مشاكل كبيرة ، حتى مع المعاملات الإضافية بخلاف الكائنات الثنائية كبيرة الحجم. هذه النتيجة هي نفس سيناريو الأساس مع الكائنات الثنائية كبيرة الحجم فقط. يشير هذا إلى أن المعاملات العادية بخلاف الكائنات الثنائية كبيرة الحجم لها تأثير ضئيل على استقرار الشبكة في ظل عدم وجود قيود على الموارد.

2 - يؤثر حد النطاق الترددي على الشبكة في مسارات مختلفة مع اختناق الوصلات الصاعدة إلى 100/50 ميجابت في الثانية للعقد الفائقة و50/25 ميجابت في الثانية للعقد الكاملة، انهار معدل نقل الكائن الثنائي كبير الحجم إلى 20 كائن ثنائي كبير الحجم / كتلة على Interop devnet و 30 كائن ثنائي كبير الحجم / كتلة على Perfect PeerDAS devnet. في ظل هذه الحدود ، أظهر الارتفاع الحاد في رسائل IWANT حول موضوع beacon_block أن كتل المنارات كانت تكافح من أجل الانتشار. أيضا ، بمجرد أن تصل العقد إلى سقوف الخروج الخاصة بها ، كشفت EL mempools عن عدد أقل بكثير من النقط ، كما يتضح من الانخفاض الحاد في معدلات نجاح getBlobsV2. تشير المناقشات الداخلية إلى الحد الأقصى للتحميل البالغ 50 ميجابت في الثانية على العقد الفائقة باعتباره الجاني الرئيسي: تم تصميم هذا السقف في EIP-7870 لبناة الكتل المحليين ، وليس للعقد الفائقة التي تخدم الشبكة الأوسع. وبالتالي ، كانت هذه الاختبارات أقسى من ظروف العالم الحقيقي. ستجري Sunnyside Labs اختبارا للمتابعة هذا الأسبوع مع عرض نطاق ترددي أعلى للعقدة الفائقة لقياس التأثير الدقيق لهذا القيد.

3 - تعمل مزامنة Genesis مع Interop devnet ، لكنها فشلت في Perfect PeerDAS devnet اكتملت مزامنة Genesis بشكل لا تشوبه شائبة على Interop devnet ، لكنها توقفت بعد فترة ترقية Fulu مباشرة على Perfect PeerDAS. إذا لم تتمكن العقدة من الحصول على جميع الأعمدة أثناء مزامنة التكوين، فيجب أن تستعلم بشكل مثالي عن نظراء إضافيين لملء الفجوات، والتي لم يتم تنفيذها بعد في أي عملاء. ما إذا كان جلب العمود عبر النظير هذا يصبح ميزة مطلوبة قبل أن يظل Fusaka مفتوحا ؛ ومن المتوقع صدور القرار في مؤتمر آسيا والديمقراطي يوم الخميس المقبل.

4 - تم النجاح في ردم حفظ المدقق في @Teku_Consensys يتيح ردم الوصاية للمدقق للعميل اكتشاف الأعمدة التاريخية المفقودة واسترجاعها تلقائيا من الأقران. أكد اختبارنا المخصص أن تطبيق Teku يعمل بشكل لا تشوبه شائبة - فقد حدد الفجوات وردم بالكامل دون عوائق في الظروف العادية. تم تحديد خطأ صغير في حالة الحافة حيث كانت هناك فجوة كبيرة في السلسلة دون أي نقط في الاختبارات ، والتي تم إصلاحها بسرعة من قبل الفريق. يعمل عملاء آخرون الآن على هذه الميزة ، وسيتم اختبارها في Devnets Sunnyside المستقبلية عند اكتمال التنفيذ.

ستستمر Sunnyside Labs في تشغيل devnets هذا الأسبوع ، مع التركيز على الموضوعات التالية: - Devnet Interop مع حدود نطاق ترددي أعلى للعقدة الفائقة وفترات زمنية أطول - مزيد من التحليل في اختبارات مزامنة التكوين على Perfect PeerDAS devnet - المزيد من devnets التي تركز على الحد الأقصى لحجم الكتلة (بتنسيق مضغوط سريع) ، والعقد التالفة باستخدام blobber ، والنهاية على الشبكة المنقسمة