تقول Base أن نفس خطأ المُسلسل تسبب في انقطاعات 25 و26 يونيو

أوضحت Base سبب توقف شبكتها الرئيسية عن إنتاج الكتل مرتين في غضون يومين

ملخص

• يُظهر أحدث تقرير لـ Base أن خطأً واحدًا في المُسلسِل (sequencer) تسبب في توقفين للشبكة الرئيسية خلال يومين متتاليين.
• ظلت الأموال آمنة، لكن قوائم انتظار المعاملات فاضت عندما توقفت Base مؤقتًا عن إنتاج كتل L2 جديدة.
• يخطط الفريق لتعزيز اختبارات التشويش (fuzz tests)، واختبارات التحميل، والمراقبة، وأدوات الاسترداد بعد الانقطاع.

صرّحت شبكة الطبقة الثانية (Layer-2) المدعومة من Coinbase، والمبنية على إيثريوم، بأن كلا الانقطاعين ناتجان عن نفس الخلل في منطق بناء الكتل الخاص بالمُسلسِل.

بدأ أول انقطاع في 25 يونيو واستمر حوالي 116 دقيقة. أما الثاني فبدأ في 26 يونيو واستمر حوالي 20 دقيقة. قالت Base إن الأموال ظلت آمنة خلال كلا الحادثتين.

خلل في المُسلسِل أوقف إنتاج الكتل

في تقريرها الرسمي لما بعد الحادثة، قالت Base إن معاملة غير صالحة فشلت أثناء التنفيذ، كما هو متوقع. وجاءت المشكلة بعد ذلك الفشل، عندما بقيت حالة دفتر أستاذ قديمة (stale journal state) داخل أداة بناء الكتل.

في 25 و26 يونيو، شهدت شبكة Base الرئيسية انقطاعين في إنتاج الكتل، كلاهما ناتج عن نفس الخلل الأساسي في منطق بناء الكتل.

لقد حددنا السبب الجذري وأصلحناه، وأرسلنا تقرير ما بعد الحادثة إلى سلاسل OP كملاحظات.

جميع الأموال كانت آمنة… pic.twitter.com/eArnK12AgZ

— Base Build (@buildonbase) 27 يونيو 2026

تضمنت تلك الحالة القديمة حسابات وخزائن تخزين (storage slots) تأثرت بالمعاملة الفاشلة. وعندما جاءت معاملة صالحة بعد ذلك، استخدم النظام حالة دفتر الأستاذ الخاطئة وفرض رسومًا على الغاز بشكل غير صحيح.

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

"لم يتم المساس بسلامة السلسلة وكانت جميع الأموال على Base آمنة"، قالت Base.

أضاف الفريق أن إنتاج الكتل استؤنف بأمان بعد التخفيف.

المعاملات في قائمة الانتظار أثناء التوقف

خلال فترات الانقطاع، لم يتمكن المستخدمون من إدراج معاملات جديدة على السلسلة. قالت Base إن المعاملات اصطفت في مجمع المعاملات (mempool) بينما انتظرت السلسلة استئناف إنتاج الكتل.

نما مجمع المعاملات لاحقًا إلى ما يتجاوز سعته التخزينية. ونتيجة لذلك، أعادت طلبات eth_sendRawTransaction الجديدة أخطاءً خلال فترة الانقطاع.

أثر التوقف أيضًا على تقدم المُسلسِل والمدقِّق (validator). قالت Base إن هذه العقد لم تستطع التحرك إلى ما بعد الكتلة غير الصالحة حتى عودة التسلسل.

كما ورد سابقًا، أشارت Base لأول مرة إلى إنتاج كتل غير صحي في 25 يونيو قبل أن يعزل المهندسون مشكلة إجماع (consensus) مرتبطة بكتلة غير صالحة.

التصحيح عالج مشكلة الحالة القديمة

قالت Base إنها أصلحت الخلل الرئيسي من خلال تطبيق تصحيح للمُسلسِل. يضمن التصحيح أن حالة دفتر الأستاذ تُحدَّث بشكل صحيح أثناء التنفيذ بعد معاملة فاشلة.

وجد الفريق أيضًا مشكلة ثانية أثناء الاسترداد. قالت Base إن التخفيف استغرق وقتًا أطول لأن حالة سباق (race condition) في ميزة إعادة تعيين المحرك (engine reset) منعت المُسلسِلات من اللحاق بالركب بعد إعادة التشغيل.

ساعدت تلك المشكلة الثانية في تفسير سبب عودة الحادثة في اليوم التالي. قالت Base إن المشكلة أثرت على المُسلسِلات وليس عقد المدقِّقين، لكنها مع ذلك أبطأت عملية الاسترداد.

أظهرت صفحة حالة Base أن التسلسل استؤنف في 25 يونيو. كما طلبت من مشغّلي عقد النظام البيئي إعادة تشغيل عُقد Base إذا كانت لا تزال عالقة.

تغييرات في الاختبار والاسترداد مخطط لها

قالت Base إنها ستعزز اختبارات التشويش (fuzz testing) واختبارات التحميل على البروتوكول. تساعد هذه الأساليب الفرق في العثور على أنماط معاملات غريبة قد تكشف عن أخطاء مخفية.

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

تريد Base أيضًا إضافة استرداد تدريجي (graceful recovery) إلى قاعدة الإجماع (base-consensus). من شأن هذا التغيير أن يسهل على عقد المدقِّقين مواصلة المزامنة بعد حالات فشل مماثلة.

جاء الانقطاع خلال أسبوع مزدحم للشبكة. كما مضت Base قدمًا في ترقيتها Beryl، التي تضيف معيار الرمز B20 وتقلل فترة السحب القياسية من Base إلى إيثريوم من سبعة أيام إلى خمسة أيام.

يمنح الحادث المطورين والمستخدمين رؤية أوضح لنقطة الضعف. وقد حددت Base الآن الخلل، وأصدرت تصحيحًا، وأدرجت الاختبارات التي تخطط لتحسينها.