Base أوضحت لماذا توقفت شبكتها الرئيسية عن إنتاج الكتل مرتين في يومين.
قالت شبكة الطبقة الثانية من إيثيريوم المدعومة من Coinbase إن كلا الانقطاعين ناتجا عن نفس الخطأ في منطق بناء الكتل لمجمع التسلسلات الخاص بها.
بدأ الانقطاع الأول في 25 يونيو واستمر حوالي 116 دقيقة. بدأ الثاني في 26 يونيو واستمر حوالي 20 دقيقة. قالت Base إن الأموال بقيت آمنة خلال كلتا الحادثتين.
في تشريحها اللاحق الرسمي، قالت Base إن معاملة غير صالحة فشلت أثناء التنفيذ، كما هو متوقع. جاءت المشكلة بعد هذا الفشل، عندما بقيت حالة سجل قديمة داخل مُنشئ الكتل.
تضمنت هذه الحالة القديمة الحسابات وفتحات التخزين التي تأثرت بالمعاملة الفاشلة. عندما جاءت معاملة صالحة تالية، استخدم النظام حالة السجل الخاطئة وخصم الغاز بشكل غير صحيح.
أدى هذا إلى إنشاء كتلة ذات انتقال حالة غير صالح. لم تتمكن العقد الأخرى من قبول الكتلة، فتوقفت السلسلة عن إنتاج كتل L2 جديدة.
"لم تتأثر سلامة السلسلة، وجميع الأموال على Base كانت آمنة،" حسبما ذكرت Base.
وأضاف الفريق أن إنتاج الكتل استؤنف بأمان بعد التخفيف.
خلال الانقطاعات، لم يتمكن المستخدمون من إدراج معاملات جديدة على السلسلة. قالت Base إن المعاملات اصطفت في طابور انتظار الـ mempool بينما كانت السلسلة تنتظر استعادة إنتاج الكتل.
نموذج المعاملات (transaction pool) نما لاحقًا ليتجاوز ما يمكنه تخزينه. ونتيجة لذلك، أرجعت طلبات eth_sendRawTransaction الجديدة أخطاءً خلال فترة الانقطاع.
أثر التوقف أيضًا على تقدم مجمعات التسلسل (sequencers) والمدققين (validators). قالت Base إن هذه العقد لم تتمكن من تجاوز الكتلة غير الصالحة حتى عاد التسلسل.
كما ورد سابقًا، أشارت Base لأول مرة إلى إنتاج كتل غير صحي في 25 يونيو قبل أن يعزل المهندسون مشكلة توافق مرتبطة بكتلة غير صالحة.
قالت Base إنها أصلحت الخطأ الرئيسي بتطبيق رقعة لمجمع التسلسلات. تضمن الرقعة تحديث حالة السجل بشكل صحيح أثناء التنفيذ بعد معاملة فاشلة.
كما وجد الفريق مشكلة ثانية أثناء الاسترداد. قالت Base إن التخفيف استغرق وقتًا أطول لأن حالة سباق (race condition) في ميزة إعادة ضبط المحرك أوقفت مجمعات التسلسل عن اللحاق بالركب بعد إعادة التشغيل.
ساعدت هذه المشكلة الثانية في تفسير سبب تكرار الحادث في اليوم التالي. قالت Base إن المشكلة أثرت على مجمعات التسلسل، وليس على عقد المدققين، لكنها لا تزال تبطئ عملية الاسترداد.
أظهرت صفحة حالة Base أن التسلسل استؤنف في 25 يونيو. كما طلبت من مشغلي عقد النظام البيئي إعادة تشغيل عقد Base إذا كانوا لا يزالون عالقين.
قالت Base إنها ستعزز اختبارات فحص البروتوكول (protocol fuzz testing) واختبارات التحميل (load testing). تساعد هذه الأساليب الفرق في العثور على أنماط معاملات غريبة قد تكشف عن أخطاء خفية.
يخطط الفريق أيضًا لتحسين المراقبة والفحوصات التشغيلية. وقالت إن هذه التغييرات يجب أن تساعد المهندسين على اكتشاف مشاكل مماثلة في وقت مبكر والاستجابة بشكل أسرع.
ترغب Base أيضًا في إضافة استرداد سلس إلى إجماع Base (base-consensus). من شأن هذا التغيير أن يسهل على عقد المدققين الاستمرار في المزامنة بعد فشل مماثل.
جاء الانقطاع خلال أسبوع حافل للشبكة. تقدمت Base أيضًا بتحديثها Beryl، الذي يضيف معيار الرمز B20 ويقلص فترة السحب القياسية من Base إلى إيثيريوم من سبعة أيام إلى خمسة أيام.
يمنح هذا الحادث المطورين والمستخدمين رؤية أوضح لنقطة الضعف. قامت Base الآن بتحديد اسم الخطأ، وإصدار رقعة، وسرد الاختبارات التي تخطط لتحسينها.
