** Jinjin Finance Blockchain ، 10 يونيو ** تسبب خطأ في رمز فرز Arbitrum هذا الأسبوع في انقطاع قصير لقدرة الشبكة على إرسال المعاملات على دفعات ، وتعذر تأكيد المعاملات على السلسلة الرئيسية. تم إصلاح الثغرة الأمنية منذ ذلك الحين ، وتمت استعادة وظيفة إرسال دفعة المعاملة. في 10 يونيو ، أصدرت مؤسسة Arbitrum تقرير تحليل ما بعد الحدث عن خطأ فارز Arbitrum. بعد ذلك ، دعنا نراجع الحالة ونرى لماذا لم يتسبب هذا الخطأ في أي خسارة لأموال المستخدم.
** الجدول الزمني لحدث فارز أداة فرز الأخطاء **
في 06:04:53 يوم 7 يونيو 2023 ، فشل مُصدر الدُفعات في تحديث عرض حالة L1 بسبب مشكلة مؤقتة في عقدة جامع Arbitrum L1. بسبب مشكلة السبب الجذري ، استمر فارز Arbitrum في محاولة الاستعلام عن حالة رقم كتلة عرض L1 السابق. هذا يعني أنه حتى بعد حل مشكلة عقدة L1 المؤقتة من تلقاء نفسها ، سيستمر ناشر الدُفعات في محاولة الاستعلام عن حالة أرقام الكتلة L1 القديمة ، ولم تعد العقدة L1 لها حالتها لأنها ليست عقدة أرشيف.
في الساعة 09:38:28 في 7 يونيو 2023 ، توقف ملصق الدُفعات الخاص بـ Arbitrum عن نشر الحركات لأنه وصل إلى الحد الأقصى الذي تم تكوينه في قائمة الانتظار (256) ، وهو نفس الحد الأقصى لمجمع الذاكرة. إذا لم يتم الوصول إلى هذا الحد ، فسيستمر النشر الجماعي كالمعتاد.
في الساعة 11:09 صباحًا يوم 7 يونيو 2023 ، وبسبب الدُفعات غير المنشورة ، تم تشغيل تنبيه على العقد الذكي لـ Sequencer Inbox للتحقق من وجود دفعات جديدة ، وتم إرسال تحذير إلى قناة Slack.
في الساعة 11:10 صباحًا ، أدى الافتقار إلى إصدارات الدُفعات الأخيرة إلى تشغيل تنبيه مستند إلى السجل وإرسال تنبيه بالمستوى الحرج إلى قناة Slack.
في الساعة 11:13 صباحًا ، بدأ أحد أعضاء فريق المجتمع PagerDuty مع أحد أعضاء فريق SRE ، الذي اعترف بالحادث على الفور وبدأ في الاستجابة.
في الساعة 11:19:02 صباحًا ، أعاد فريق SRE إعادة تشغيل ملصق الدُفعة ، ولكن نظرًا للحد الأقصى للحركة المدرجة سابقًا في قائمة الانتظار ، مُنع ملصق الدُفعة من نشر المعاملات. لاحظ فريق SRE هذه المشكلة وبدأ في التبديل إلى موفر L1 RPC تابع لجهة خارجية في محاولة للتخفيف من المشكلة.
في 11:24:16 صباحًا ، بعد 5 دقائق من بدء ملصق الدُفعة ، قام بتحديث عرض الحالة L1 ونشر الدفعة الأولى من الحركات.
في الساعة 11:25:09 صباحًا ، تم تغيير تكوين ملصق الدُفعات لاستخدام موفر L1 RPC تابع لجهة خارجية وإعادة التشغيل لأن فريق SRE بدأ بالفعل في إجراء هذا التغيير ولم يلاحظ التجميع. بعد إعادة التشغيل ، تستمر المعاملات الدفعية في الحدوث.
في الساعة 11:30:21 صباحًا ، بعد 5 دقائق من بدء ملصق الدُفعة ، تم تحديث عرض الحالة L1 ، مما أدى إلى أن تكون حالة L1 غير متزامنة ، والتي كانت أيضًا السبب الجذري للمشكلة. تم تحديث حالة L1 إلى رقم الكتلة النهائي 17428199 ، ولكنها استخدمت أحدث رقم 178078 ، وهو ما يتوافق مع الكتلة الأخيرة في ذلك الوقت ، بدلاً من الكتلة النهائية المخزنة في حالتها ، مما أدى إلى مسح جميع المعاملات في قائمة الانتظار في Redis باستثناء ، لأن Redis يعتبر هذه المعاملات مؤكدة.
في الساعة 11:30:26 صباحًا ، نشر ملصق الدُفعة دفعة جديدة. يعتمد Redis على عرض الحالة L1 لتحديد ما سيتم نشره ، ولكن في هذه المرحلة تكون قائمة انتظار Redis فارغة ، كما هو مذكور سابقًا ، حالة L1 غير صحيحة ، وتم نشر دفعة برقم عشوائي في الحالة 178078 ، ولكن من أجل تحديد سيتم نشر الدُفعة ، باستخدام رقم كتلة غير ذي صلة 17428199 ، مما أدى إلى نشر دفعة قديمة برقم تسلسلي 229209 ، والتي تم نشرها بالفعل في الساعة 11:24:16 من قبل ، ثم تمت إعادة تشغيل ملصق الدُفعة. نظرًا لأن الدُفعة القديمة 229209 قد تم نشرها بالفعل ، فقد تم إرجاع معاملة L1 المقدمة بواسطة الدُفعة إلى الوراء.
في الساعة 11:36:35 صباحًا ، نفد عنوان ملصق الدُفعة من Ether لأنه لم يقم برد رسوم الغاز ، لذلك توقف عن النشر. هذه آلية مقصودة لمنع ملصق الدُفعة من استهلاك كل الغاز المخزن في تكلفة دفعة الاسترداد.
في الساعة 11:46 صباحًا ، تلقى أحد أعضاء فريق Nitro مكالمة لحل مشكلة برنامج مع استرداد الدُفعات.
في حوالي الساعة 11:58 صباحًا ، بدأت Arbitrum في تلقي تقارير تفيد بأن بعض المستخدمين وجدوا أن هناك مشكلة في أداة الفرز (بث المعاملات التي تم فرزها حديثًا إلى عقد RPC) ، لأن المزيد والمزيد من المعاملات المطلوبة كانت بسبب مشاكل الملصقات المجمعة بدلاً من النشر بالنسبة إلى السلسلة ، تؤثر هذه المشكلة بشكل أساسي على عملاء الخلاصة الذين يعانون من ضعف اتصالات الإنترنت أو تخصيص ذاكرة غير كافٍ ، حيث من المرجح أن ينخفضوا ويواجهوا مشكلات في إعادة الاتصال. توصي Arbitrum بأن يقوم المستخدمون الذين يقومون بتشغيل عدة عقد RPC بتشغيل مرحل تغذية محلي لتقليل عرض النطاق الترددي الخارجي المطلوب.
في الساعة 12:03 مساءً ، أزال Arbitrum حد معدل تغذية Cloudflare للتخفيف من مشكلة وصول العملاء إلى حد السعر عند محاولة إعادة الاتصال بعد قطع الاتصال بسبب اتصال الإنترنت.
في الساعة 12:05 مساءً ، أزال Arbitrum جميع حدود معدل Cloudflare للسماح بزيادة استخدام RPC العام لأولئك الذين كانت عقدهم تواجه مشكلة في الحفاظ على الاتصالات بالموجزات.
في الساعة 12:12:09 مساءً ، تم إغلاق ملصق الدُفعة المعيب وتم مسح قائمة انتظار Redis لإزالة الحالة السيئة.
في الساعة 12:12:40 مساءً ، بدأ ملصق الدُفعة على الإصدار القديم v2.0.14 ، ولم تكن هناك مشكلة في الجذر.
في الساعة 12:21:56 مساءً ، نجحت الدفعة الأولى من ملصقات الدُفعات التي تم افتتاحها حديثًا ، وهي تعمل بشكل مستمر منذ ذلك الحين.
** دروس حدث خطأ فارز Arbitrum المستفادة **
حدث هذا الفشل بسبب خطأ في ملصق الدُفعة. لم يتأثر جهاز التسلسل نفسه أو ينقطع واستمر في معالجة المعاملات طوال العملية. التقارير التي تفيد بنفاد أموال منظم التسلسل غير صحيحة. تتكون آلية تمويل Arbitrum من محفظتين ، وهما: محفظة "Sequencer" و "gas-refunder". فقط عندما يتمكن منظم التسلسل من تحرير الدفعة بنجاح ، سيتم ردها. لم تقم شبكة Arbitrum برد الأموال إلى منظم التسلسل لهذا الأموال ، والمشكلات ذات الصلة لم تكن ناجمة عن نفاد أموال منظم التسلسل ، لذلك لم تكن أموال المستخدمين في خطر.
ستقوم Arbitrum بتنظيف خيارات التكوين التي تمت إضافتها في الحل المؤقت. لاحقًا ، تخطط لإعادة تقييم مشكلات مهلة العميل والخادم لمنظم التسلسل لتحسين موثوقية الشبكة في حالة تراكم المعاملات. إصدار جديد "v2.1.0- تجريبي" .2 "نسخة تجريبية. بالإضافة إلى ذلك ، ستنشئ Arbitrum صفحة حالة شبكة عامة لتقليل الارتباك في حالة وجود مشكلات في الخدمة.
تمت الإشارة إلى هذه المقالة من الموقع الرسمي لمؤسسة Arbitrum
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
المراقبة الذهبية | مراجعة حدث خطأ فارز Arbitrum
المؤلف: Golden Finance Jason
! [1Y10H2VnvGHHMNxj5ZZizD4vqjbiaw6Y2vKX0uCq.jpeg] (https://img.gateio.im/social/moments-40baef27dd-7be970d5cb-dd1a6f-62a40f "7049246")
** Jinjin Finance Blockchain ، 10 يونيو ** تسبب خطأ في رمز فرز Arbitrum هذا الأسبوع في انقطاع قصير لقدرة الشبكة على إرسال المعاملات على دفعات ، وتعذر تأكيد المعاملات على السلسلة الرئيسية. تم إصلاح الثغرة الأمنية منذ ذلك الحين ، وتمت استعادة وظيفة إرسال دفعة المعاملة. في 10 يونيو ، أصدرت مؤسسة Arbitrum تقرير تحليل ما بعد الحدث عن خطأ فارز Arbitrum. بعد ذلك ، دعنا نراجع الحالة ونرى لماذا لم يتسبب هذا الخطأ في أي خسارة لأموال المستخدم.
** الجدول الزمني لحدث فارز أداة فرز الأخطاء **
في 06:04:53 يوم 7 يونيو 2023 ، فشل مُصدر الدُفعات في تحديث عرض حالة L1 بسبب مشكلة مؤقتة في عقدة جامع Arbitrum L1. بسبب مشكلة السبب الجذري ، استمر فارز Arbitrum في محاولة الاستعلام عن حالة رقم كتلة عرض L1 السابق. هذا يعني أنه حتى بعد حل مشكلة عقدة L1 المؤقتة من تلقاء نفسها ، سيستمر ناشر الدُفعات في محاولة الاستعلام عن حالة أرقام الكتلة L1 القديمة ، ولم تعد العقدة L1 لها حالتها لأنها ليست عقدة أرشيف.
في الساعة 09:38:28 في 7 يونيو 2023 ، توقف ملصق الدُفعات الخاص بـ Arbitrum عن نشر الحركات لأنه وصل إلى الحد الأقصى الذي تم تكوينه في قائمة الانتظار (256) ، وهو نفس الحد الأقصى لمجمع الذاكرة. إذا لم يتم الوصول إلى هذا الحد ، فسيستمر النشر الجماعي كالمعتاد.
في الساعة 11:09 صباحًا يوم 7 يونيو 2023 ، وبسبب الدُفعات غير المنشورة ، تم تشغيل تنبيه على العقد الذكي لـ Sequencer Inbox للتحقق من وجود دفعات جديدة ، وتم إرسال تحذير إلى قناة Slack.
في الساعة 11:10 صباحًا ، أدى الافتقار إلى إصدارات الدُفعات الأخيرة إلى تشغيل تنبيه مستند إلى السجل وإرسال تنبيه بالمستوى الحرج إلى قناة Slack.
في الساعة 11:13 صباحًا ، بدأ أحد أعضاء فريق المجتمع PagerDuty مع أحد أعضاء فريق SRE ، الذي اعترف بالحادث على الفور وبدأ في الاستجابة.
في الساعة 11:19:02 صباحًا ، أعاد فريق SRE إعادة تشغيل ملصق الدُفعة ، ولكن نظرًا للحد الأقصى للحركة المدرجة سابقًا في قائمة الانتظار ، مُنع ملصق الدُفعة من نشر المعاملات. لاحظ فريق SRE هذه المشكلة وبدأ في التبديل إلى موفر L1 RPC تابع لجهة خارجية في محاولة للتخفيف من المشكلة.
في 11:24:16 صباحًا ، بعد 5 دقائق من بدء ملصق الدُفعة ، قام بتحديث عرض الحالة L1 ونشر الدفعة الأولى من الحركات.
في الساعة 11:25:09 صباحًا ، تم تغيير تكوين ملصق الدُفعات لاستخدام موفر L1 RPC تابع لجهة خارجية وإعادة التشغيل لأن فريق SRE بدأ بالفعل في إجراء هذا التغيير ولم يلاحظ التجميع. بعد إعادة التشغيل ، تستمر المعاملات الدفعية في الحدوث.
في الساعة 11:30:21 صباحًا ، بعد 5 دقائق من بدء ملصق الدُفعة ، تم تحديث عرض الحالة L1 ، مما أدى إلى أن تكون حالة L1 غير متزامنة ، والتي كانت أيضًا السبب الجذري للمشكلة. تم تحديث حالة L1 إلى رقم الكتلة النهائي 17428199 ، ولكنها استخدمت أحدث رقم 178078 ، وهو ما يتوافق مع الكتلة الأخيرة في ذلك الوقت ، بدلاً من الكتلة النهائية المخزنة في حالتها ، مما أدى إلى مسح جميع المعاملات في قائمة الانتظار في Redis باستثناء ، لأن Redis يعتبر هذه المعاملات مؤكدة.
في الساعة 11:30:26 صباحًا ، نشر ملصق الدُفعة دفعة جديدة. يعتمد Redis على عرض الحالة L1 لتحديد ما سيتم نشره ، ولكن في هذه المرحلة تكون قائمة انتظار Redis فارغة ، كما هو مذكور سابقًا ، حالة L1 غير صحيحة ، وتم نشر دفعة برقم عشوائي في الحالة 178078 ، ولكن من أجل تحديد سيتم نشر الدُفعة ، باستخدام رقم كتلة غير ذي صلة 17428199 ، مما أدى إلى نشر دفعة قديمة برقم تسلسلي 229209 ، والتي تم نشرها بالفعل في الساعة 11:24:16 من قبل ، ثم تمت إعادة تشغيل ملصق الدُفعة. نظرًا لأن الدُفعة القديمة 229209 قد تم نشرها بالفعل ، فقد تم إرجاع معاملة L1 المقدمة بواسطة الدُفعة إلى الوراء.
في الساعة 11:36:35 صباحًا ، نفد عنوان ملصق الدُفعة من Ether لأنه لم يقم برد رسوم الغاز ، لذلك توقف عن النشر. هذه آلية مقصودة لمنع ملصق الدُفعة من استهلاك كل الغاز المخزن في تكلفة دفعة الاسترداد.
في الساعة 11:46 صباحًا ، تلقى أحد أعضاء فريق Nitro مكالمة لحل مشكلة برنامج مع استرداد الدُفعات.
في حوالي الساعة 11:58 صباحًا ، بدأت Arbitrum في تلقي تقارير تفيد بأن بعض المستخدمين وجدوا أن هناك مشكلة في أداة الفرز (بث المعاملات التي تم فرزها حديثًا إلى عقد RPC) ، لأن المزيد والمزيد من المعاملات المطلوبة كانت بسبب مشاكل الملصقات المجمعة بدلاً من النشر بالنسبة إلى السلسلة ، تؤثر هذه المشكلة بشكل أساسي على عملاء الخلاصة الذين يعانون من ضعف اتصالات الإنترنت أو تخصيص ذاكرة غير كافٍ ، حيث من المرجح أن ينخفضوا ويواجهوا مشكلات في إعادة الاتصال. توصي Arbitrum بأن يقوم المستخدمون الذين يقومون بتشغيل عدة عقد RPC بتشغيل مرحل تغذية محلي لتقليل عرض النطاق الترددي الخارجي المطلوب.
في الساعة 12:03 مساءً ، أزال Arbitrum حد معدل تغذية Cloudflare للتخفيف من مشكلة وصول العملاء إلى حد السعر عند محاولة إعادة الاتصال بعد قطع الاتصال بسبب اتصال الإنترنت.
في الساعة 12:05 مساءً ، أزال Arbitrum جميع حدود معدل Cloudflare للسماح بزيادة استخدام RPC العام لأولئك الذين كانت عقدهم تواجه مشكلة في الحفاظ على الاتصالات بالموجزات.
في الساعة 12:12:09 مساءً ، تم إغلاق ملصق الدُفعة المعيب وتم مسح قائمة انتظار Redis لإزالة الحالة السيئة.
في الساعة 12:12:40 مساءً ، بدأ ملصق الدُفعة على الإصدار القديم v2.0.14 ، ولم تكن هناك مشكلة في الجذر.
في الساعة 12:21:56 مساءً ، نجحت الدفعة الأولى من ملصقات الدُفعات التي تم افتتاحها حديثًا ، وهي تعمل بشكل مستمر منذ ذلك الحين.
** دروس حدث خطأ فارز Arbitrum المستفادة **
حدث هذا الفشل بسبب خطأ في ملصق الدُفعة. لم يتأثر جهاز التسلسل نفسه أو ينقطع واستمر في معالجة المعاملات طوال العملية. التقارير التي تفيد بنفاد أموال منظم التسلسل غير صحيحة. تتكون آلية تمويل Arbitrum من محفظتين ، وهما: محفظة "Sequencer" و "gas-refunder". فقط عندما يتمكن منظم التسلسل من تحرير الدفعة بنجاح ، سيتم ردها. لم تقم شبكة Arbitrum برد الأموال إلى منظم التسلسل لهذا الأموال ، والمشكلات ذات الصلة لم تكن ناجمة عن نفاد أموال منظم التسلسل ، لذلك لم تكن أموال المستخدمين في خطر.
ستقوم Arbitrum بتنظيف خيارات التكوين التي تمت إضافتها في الحل المؤقت. لاحقًا ، تخطط لإعادة تقييم مشكلات مهلة العميل والخادم لمنظم التسلسل لتحسين موثوقية الشبكة في حالة تراكم المعاملات. إصدار جديد "v2.1.0- تجريبي" .2 "نسخة تجريبية. بالإضافة إلى ذلك ، ستنشئ Arbitrum صفحة حالة شبكة عامة لتقليل الارتباك في حالة وجود مشكلات في الخدمة.
تمت الإشارة إلى هذه المقالة من الموقع الرسمي لمؤسسة Arbitrum