بیس (Base) توضیح داده است که چرا شبکه اصلی آن دو بار در دو روز متوقف شده است.
شبکه لایه 2 اتریوم تحت حمایت کوینبیس (Coinbase) اعلام کرد که هر دو قطعی از یک باگ در منطق ساخت بلاک ترتیبدهنده (sequencer) آن ناشی شده است.
اولین قطعی در 25 ژوئن آغاز شد و حدود 116 دقیقه به طول انجامید. دومین قطعی در 26 ژوئن آغاز شد و حدود 20 دقیقه طول کشید. Base اعلام کرد که وجوه در طول هر دو حادثه امن باقی ماندند.
Base در گزارش رسمی پس از حادثه خود اعلام کرد که یک تراکنش نامعتبر در حین اجرا، همانطور که انتظار میرفت، با شکست مواجه شد. مشکل پس از این شکست رخ داد، زمانی که وضعیت ژورنال قدیمی (stale journal state) در سازنده بلاک (block builder) باقی ماند.
این وضعیت قدیمی شامل حسابها و اسلاتهای ذخیرهسازی بود که توسط تراکنش ناموفق لمس شده بودند. هنگامی که یک تراکنش معتبر بعدی وارد شد، سیستم از وضعیت ژورنال اشتباه استفاده کرد و کارمزد گس (gas) را به اشتباه محاسبه کرد.
این امر منجر به ایجاد بلاکی با انتقال وضعیت نامعتبر شد. سایر گرهها نتوانستند بلاک را بپذیرند، بنابراین زنجیره تولید بلاکهای لایه 2 جدید را متوقف کرد.
Base گفت: "یکپارچگی زنجیره به خطر نیفتاد و تمام وجوه در Base امن بودند."
تیم افزود که تولید بلاک پس از رفع مشکل به طور ایمن از سر گرفته شد.
در طول قطعیها، کاربران نتوانستند تراکنشهای جدیدی را در زنجیره (onchain) ثبت کنند. Base اعلام کرد که تراکنشها در ممپول (mempool) صفبندی شدند در حالی که زنجیره منتظر بازیابی تولید بلاک بود.
استخر تراکنش (transaction pool) بعداً از ظرفیت ذخیرهسازی خود فراتر رفت. در نتیجه، درخواستهای جدید eth_sendRawTransaction در طول مدت قطعی خطا بازگرداندند.
این توقف همچنین بر پیشرفت ترتیبدهنده (sequencer) و اعتبارسنج (validator) تأثیر گذاشت. Base گفت که این گرهها نتوانستند از بلاک نامعتبر عبور کنند تا زمانی که ترتیببندی بازگردد.
همانطور که قبلاً گزارش شد، Base ابتدا در 25 ژوئن تولید بلاک ناسالم را گزارش داد، قبل از اینکه مهندسان یک مشکل اجماع مرتبط با یک بلاک نامعتبر را شناسایی کنند.
Base اعلام کرد که با اعمال یک وصله ترتیبدهنده (sequencer patch) باگ اصلی را برطرف کرده است. این وصله اطمینان میدهد که وضعیت ژورنال پس از یک تراکنش ناموفق به درستی در حین اجرا به روز میشود.
این تیم همچنین در طول بازیابی، یک مشکل دوم را پیدا کرد. Base گفت که رفع مشکل بیشتر طول کشید، زیرا یک وضعیت رقابت (race condition) در ویژگی بازنشانی موتور (engine reset feature) مانع از همگامسازی ترتیبدهندهها پس از راهاندازی مجدد شد.
این مشکل دوم توضیح داد که چرا حادثه در روز بعد بازگشت. Base گفت که این مشکل ترتیبدهندهها را تحت تأثیر قرار داده، نه گرههای اعتبارسنجی، اما باز هم بازیابی را کند کرد.
صفحه وضعیت Base نشان داد که ترتیببندی در 25 ژوئن از سر گرفته شده است. همچنین به اپراتورهای گره اکوسیستم (ecosystem node operators) توصیه کرد در صورت گیر کردن، گرههای Base خود را راهاندازی مجدد کنند.
Base اعلام کرد که تست فازی پروتکل (protocol fuzz testing) و تست بارگذاری (load testing) خود را تقویت خواهد کرد. این روشها به تیمها کمک میکنند تا الگوهای تراکنش عجیب و غریبی را که ممکن است باگهای پنهان را آشکار کنند، بیابند.
این تیم همچنین برنامههایی برای نظارت بهتر و بررسیهای عملیاتی (operational checks) دارد. این تغییرات باید به مهندسان کمک کند تا مشکلات مشابه را زودتر تشخیص دهند و سریعتر پاسخ دهند.
Base همچنین میخواهد بازیابی پایدار (graceful recovery) را به اجماع Base (base-consensus) اضافه کند. این تغییر باعث میشود که گرههای اعتبارسنج (validator nodes) پس از شکستهای مشابه، همگامسازی را راحتتر ادامه دهند.
این قطعی در هفتهای پرکار برای این شبکه رخ داد. Base همچنین با ارتقاء Beryl خود پیش رفت، که استاندارد توکن B20 را اضافه میکند و دوره استاندارد برداشت از Base به اتریوم را از هفت روز به پنج روز کاهش میدهد.
این حادثه به توسعهدهندگان و کاربران دید واضحتری از نقطه ضعف ارائه میدهد. Base اکنون باگ را نامگذاری کرده، وصلهای منتشر کرده و تستهایی را که قصد بهبود آنها را دارد، لیست کرده است.
