تفاصيل Prysm انقطاع شبكة Fusaka الرئيسية وخسارة 382 ETH

فشلت عقد Prysm تحت حمل Attestation الثقيل خلال Fusaka، مما أدى إلى فقدان حوالي 18.5% من الفتحات، وانخفاض المشاركة و382 ETH من الخسائر.

أجبر Attestations غير المتزامنة Prysm على إعادة تشغيل حالات beacon القديمة، مما أدى إلى تشغيل آلاف عمليات إعادة حساب مكلفة واستنزاف الموارد.

قام Prysm بمعالجة المشكلة من خلال أعلام التكوين والإصدارات اللاحقة، مع تحديث منطق التحقق لتجنب عمليات إعادة تشغيل الحالة التاريخية.

واجهت شبكة Ethereum الرئيسية ترقية Fusaka اضطرابات في 4 ديسمبر 2025، بعد فشل عقد Prysm أثناء معالجة attestation. حدثت المشكلة على شبكة Ethereum الرئيسية خلال نافذة ترقية Fusaka، بمشاركة فريق عميل التوافق Prysm. وكان السبب استهلاك الموارد، مما أدى إلى تأخير استجابة المدققين وتسبب في فقدان الفترات، وانخفاض المشاركة، وخسائر في مكافآت المدققين.

استنزاف الموارد يعرقل فترات Fusaka

خلال الحادث، كافح تقريبًا جميع عقد beacon Prysm لمعالجة attestation محددة تحت عبء ثقيل. ومن الجدير بالذكر أن المشكلة أثرت على الفترات من 411439 حتى 411480، والتي تمتد حوالي 42 فترة. ومع ذلك، فشلت العقد في الاستجابة في الوقت المحدد لطلبات المدققين، مما تسبب في فقدان الكتل والاعتمادات.

على طول هذا النطاق، فقدت الشبكة 248 كتلة من أصل 1,344 فتحة. ونتيجة لذلك، وصل معدل الفتحات المفقودة إلى حوالي 18.5%. كما انخفضت مشاركة الشبكة بشكل حاد، ووصلت إلى أدنى مستوى يقارب 75% خلال ذروة الاضطراب.

عانى المدققون من خسائر قابلة للقياس خلال التباطؤ. ووفقًا لفريق Prysm، بلغت مكافآت الاعتمادات المفقودة حوالي 382 ETH. تراكمت هذه الخسائر حيث لم يتمكن المدققون من تقديم الأدلة في الوقت المحدد.

الأدلة غير المتزامنة أدت إلى عمليات إعادة حساب مكلفة

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

للتحقق من كل دليل، أعاد Prysm بناء حالات beacon القديمة بشكل متكرر. استلزم هذا إعادة تشغيل الكتل السابقة وأداء انتقالات فترات مكلفة. وفي ظل التزامن العالي، حاولت العقد إجراء مئات من عمليات إعادة الحساب في وقت واحد.

مثال واحد كان اعتمادًا على إشارة إلى الكتلة 0xc6e4ff من الفترة 411441. وأعاد Prysm تشغيل العديد من انتقالات الحالة للتحقق من صحتها. ولاحظ المهندسون أن هذا السلوك تكرر تقريبًا 4000 مرة عبر البنية التحتية.

الإصلاحات والكشف والمراقبة المستمرة

خلال الحادث، نصح فريق Prysm المستخدمين بتمكين العلم --disable-last-epoch-target في الإصدار 7.0.0. وقامت هذه التدابير المؤقتة بتقليل ضغط إعادة حساب الحالة. والأهم من ذلك، أنها تجنبت الحاجة إلى إصدار عميل طارئ.

لاحقًا، أصدرت الإصدارات 7.0.1 و7.1.0 إصلاحات دائمة. غيرت هذه التحديثات منطق التحقق من الاعتمادات ليعتمد على الحالة الرأسية، متجنبة إعادة التشغيل التاريخية. وحذر الفريق من استخدام العلم --ignore-unviable-attestations.

تم الكشف عن المشكلة من خلال تقارير من مطورين رئيسيين ومستخدمين. أظهرت المقاييس زيادة في أعداد عمليات إعادة الحساب، وارتفاع استهلاك الموارد، وفشل طلبات gRPC. ووفقًا لبيانات Miga Labs التي استشهد بها Prysm، فإن توزيع العملاء تغير خلال عملية الاسترداد، مما يسلط الضوء على مخاوف التنوع المستمرة.

تظهر منشور Prysm تفاصيل انقطاع شبكة Fusaka وخسارة 382 ETH على Crypto Front News. زوروا موقعنا لقراءة المزيد من المقالات المثيرة حول العملات الرقمية، وتقنية البلوكشين، والأصول الرقمية.