قام فريق تطوير Prysm مؤخرًا بنشر تقرير تحليل بعد الحدث يوضح بالتفصيل الحدث غير الطبيعي الذي حدث بعد ترقية Fusaka في 4 ديسمبر 2025. لقد هددت هذه المشكلة استقرار شبكة إيثريوم مؤقتًا، لكن في النهاية تم حلها بفضل آلية تنوع العملاء.
يوضح التقرير أن المشكلة حدثت بعد تفعيل ترقية Fusaka في epoch رقم 411,392 (في 4 ديسمبر، 21:49 بالتوقيت العالمي الموحد). عند معالجة بيانات إثبات معينة، أدى عميل Prysm consensus إلى تكرار حساب حالات تاريخية بكميات كبيرة، مما أدى إلى استهلاك سريع لموارد CPU والذاكرة، ونتيجة لذلك، تعرض العقد لانخفاض في الأداء بشكل يشبه هجوم رفض الخدمة (DoS). هذه ليست عيبًا في تصميم البروتوكول، بل هي مشكلة في تنفيذ العميل تحت ظروف حدودية محددة.
حوالي 15% إلى 22.71% من عقد التحقق في شبكة Prysm تأثرت بالمشكلة. خلال الحدث، انخفض معدل مشاركة المُصادقين بشكل مفاجئ من أكثر من 95% إلى حوالي 75%، وتخللت الشبكة 41 epoch متتالي، مما أدى إلى خسارة تقريبًا 382 ETH من مكافآت الإثبات، وبلغت الحالة حد فقدان النهائي. أشار المطورون الأساسيون لـ Prysm، Terence Tsao، إلى أن حسابات استرجاع الحالات التاريخية تتطلب قدرًا كبيرًا من العمل، وأن تشغيلها بشكل متزامن متعدد الخيوط يبطئ أداء العقد بشكل ملحوظ.
ومن الجدير بالذكر أن ترقية Fusaka كانت ناجحة في حد ذاتها. أدخلت هذه الترقية تقنية PeerDAS (اختيارية التوافر البيانات النظيرة)، بهدف زيادة سعة blob في Layer 2 بمقدار ثمانية أضعاف، ولم تتسبب في توقف أو انقسام في الإجماع خلال عملية الترقية.
السبب وراء تجنب شبكة إيثريوم لعواقب أكثر خطورة هو تنوع العملاء. بالإضافة إلى Prysm، حافظت عشرة عملاء إجماعيين آخرين مثل Lighthouse و Teku و Nimbus على عمليات إصدار الكتل بشكل طبيعي طوال العملية، مما سمح لما يقرب من 75% إلى 85% من المُصادقين بالبقاء على الإنترنت، وضمان عدم تدمير النهائي. إذا حدثت مشكلة مماثلة في العملاء الذين يمثلون نسبة أعلى، فستكون النتائج أكثر خطورة، بما في ذلك توقف تجميع Layer 2 أو عرقلة سحب المُصادقين.
بعد الحدث، أصدرت مؤسسة إيثريوم بسرعة إرشادات طارئة، وبدأ فريق Prysm بنشر إصلاح مؤقت أثناء التشغيل، وأطلق حلولًا دائمة في الإصدارين v7.0.1 و v7.1.0. بحلول 5 ديسمبر، عادت نسبة المشاركة في الشبكة إلى ما يقرب من 99%، واستعادت شبكة إيثريوم الرئيسية عملها الطبيعي خلال 24 ساعة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحليل حدث ترقية Fusaka في إيثريوم: تقرير Prysm بعد الحدث يكشف السبب الجذري للفشل
قام فريق تطوير Prysm مؤخرًا بنشر تقرير تحليل بعد الحدث يوضح بالتفصيل الحدث غير الطبيعي الذي حدث بعد ترقية Fusaka في 4 ديسمبر 2025. لقد هددت هذه المشكلة استقرار شبكة إيثريوم مؤقتًا، لكن في النهاية تم حلها بفضل آلية تنوع العملاء.
يوضح التقرير أن المشكلة حدثت بعد تفعيل ترقية Fusaka في epoch رقم 411,392 (في 4 ديسمبر، 21:49 بالتوقيت العالمي الموحد). عند معالجة بيانات إثبات معينة، أدى عميل Prysm consensus إلى تكرار حساب حالات تاريخية بكميات كبيرة، مما أدى إلى استهلاك سريع لموارد CPU والذاكرة، ونتيجة لذلك، تعرض العقد لانخفاض في الأداء بشكل يشبه هجوم رفض الخدمة (DoS). هذه ليست عيبًا في تصميم البروتوكول، بل هي مشكلة في تنفيذ العميل تحت ظروف حدودية محددة.
حوالي 15% إلى 22.71% من عقد التحقق في شبكة Prysm تأثرت بالمشكلة. خلال الحدث، انخفض معدل مشاركة المُصادقين بشكل مفاجئ من أكثر من 95% إلى حوالي 75%، وتخللت الشبكة 41 epoch متتالي، مما أدى إلى خسارة تقريبًا 382 ETH من مكافآت الإثبات، وبلغت الحالة حد فقدان النهائي. أشار المطورون الأساسيون لـ Prysm، Terence Tsao، إلى أن حسابات استرجاع الحالات التاريخية تتطلب قدرًا كبيرًا من العمل، وأن تشغيلها بشكل متزامن متعدد الخيوط يبطئ أداء العقد بشكل ملحوظ.
ومن الجدير بالذكر أن ترقية Fusaka كانت ناجحة في حد ذاتها. أدخلت هذه الترقية تقنية PeerDAS (اختيارية التوافر البيانات النظيرة)، بهدف زيادة سعة blob في Layer 2 بمقدار ثمانية أضعاف، ولم تتسبب في توقف أو انقسام في الإجماع خلال عملية الترقية.
السبب وراء تجنب شبكة إيثريوم لعواقب أكثر خطورة هو تنوع العملاء. بالإضافة إلى Prysm، حافظت عشرة عملاء إجماعيين آخرين مثل Lighthouse و Teku و Nimbus على عمليات إصدار الكتل بشكل طبيعي طوال العملية، مما سمح لما يقرب من 75% إلى 85% من المُصادقين بالبقاء على الإنترنت، وضمان عدم تدمير النهائي. إذا حدثت مشكلة مماثلة في العملاء الذين يمثلون نسبة أعلى، فستكون النتائج أكثر خطورة، بما في ذلك توقف تجميع Layer 2 أو عرقلة سحب المُصادقين.
بعد الحدث، أصدرت مؤسسة إيثريوم بسرعة إرشادات طارئة، وبدأ فريق Prysm بنشر إصلاح مؤقت أثناء التشغيل، وأطلق حلولًا دائمة في الإصدارين v7.0.1 و v7.1.0. بحلول 5 ديسمبر، عادت نسبة المشاركة في الشبكة إلى ما يقرب من 99%، واستعادت شبكة إيثريوم الرئيسية عملها الطبيعي خلال 24 ساعة.