🚨 تم إسقاط تقرير Sunnyside devnet (09/30) للتو - حول devnet-5 تم تشغيله عند ~ 11٪ مقياس الشبكة الرئيسية (~ 1.7 ألف عقدة كاملة). إذا كنت تهتم بتوسيع نطاق الكائن الثنائي كبير الحجم وحدود الشبكة ، فهذه قراءة أساسية. موضوع 🧵

استمرت إنتاجية النقطة عند devnet-5 على 22/33 نقطا ، وامتدت إلى 48/72 ، مع وصول استخدام الغاز إلى ذروته بالقرب من ~ 45 مترا. كان المحدد الأكبر هو سعة الشبكة: تصل العقد الكاملة ذات الحد الأقصى للتحميل بسرعة 50 ميجابت في الثانية إلى السقف باستمرار عند 48/72 نقطة.

على عكس شبكات devnets الصغيرة السابقة ، تجاوزت طفرات EL P2P للعقد الكاملة القيل والقال تماما ، مما أدى إلى عدم استقرار جديد على نطاق واسع. الجانب EL من الشبكات هو الآن مصدر التقلبات المهيمن. خفت حدة تحميل القيل والقال في الأعمدة ، على الأرجح لأن حركة مرور EL كانت بالفعل تشبع النطاق الترددي وكان لدى العقد المزيد من أقران CL لمشاركة طلبات الأعمدة.

عند التوفر ، أظهرت موثوقية GetBlobsV2 بوضوح بعض الانحطاط مع الحمل العالي. أظهر Geth و Nethermind توفرا أعلى للكائن الثنائي كبير الحجم من معدل الضرب، مما يشير إلى أنهما غالبا ما يحتفظان بالكائنات الثنائية كبيرة الحجم جزئية فقط - مما يشير إلى أن السماح بالعوائد الجزئية من واجهة برمجة تطبيقات GetBlobs يمكن أن يساعد في أداء CL عند عدد الكائن الثنائي كبير الحجم الأعلى. وفي الوقت نفسه ، أدى أداء GetBlobAPI ل Reth إلى تحسين الكثير ، حيث ضاعف عدد الأقران (~ 120 مقابل ~ 40-60) وأخيرا تخلص من مشكلات المزامنة / OOM السابقة.

استنتاج: ستفتح Fusaka الدعم لمزيد من الكائنات الثنائية كبيرة الحجم ل L2s ، بينما سيتم توسيع نطاق BPOs المجدولة حاليا إلى هدف 14 نقطة لكل كتلة (بحد أقصى 21). لتجاوز هذا الحد ، يلزم الاهتمام بعناية بالاختناقات الحرجة التي تم تسليط الضوء عليها في هذا التقرير - وهي عرض النطاق الترددي للتحميل ، واستقرار شبكات P2P ، والقيم المتطرفة الخاصة بالعميل. يجب أن تكون الأولوية الفورية هي تحسين كفاءة النطاق الترددي وتحسين معالجة الكائن الثنائي كبير الحجم للعميل، مثل تمكين الإرجاع الجزئي عبر واجهة برمجة تطبيقات GetBlobs. تظل Sunnyside Labs ملتزمة بتطوير هذه المجالات وستواصل العمل لدفع إنتاجية blob إلى حدودها - ولكن دائما بطريقة تضمن أن الشبكة تعمل بأمان وموثوقية.