تم حل استغلال MWEB في Litecoin وتصحيح إعادة تنظيم الكتل

واجهت Litecoin مؤخرًا أحد أخطر الحوادث التقنية المتعلقة بميزة Mimblewimble Extension Blocks (MWEB)، بعد أن سمحت ثغرة في التحقق لمهاجم بإنشاء peg-out متضخم بنحو 85,034 LTC.

تبيّن أن المشكلة نشأت من فشل في تحقق مستوى ربط الكتل، حيث لم تطابق بيانات مداخل MWEB بشكل صحيح الـ UTXO الأساسي الذي يتم إنفاقه.

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

كيف وقع استغلال MWEB

وفقًا لـ تقرير ما بعد الحادث الصادر عن Litecoin، بدأ الاستغلال في مارس 2026 عند ارتفاع الكتلة 3,073,882، عندما استغل مهاجم فجوة التحقق بنجاح.

من خلال التلاعب ببيانات مداخل MWEB، جعل المهاجم مدخلاً صغيرًا يبدو كأنه يبرر مخرجًا أكبر بكثير أثناء معالجة الـ peg-out.

في الواقع، كانت قيمة المدخل الأساسي حوالي 1–2 LTC فقط، لكن النظام قبلها بشكل خاطئ كدعم لأكثر من 85,000 LTC.

هذه لم تكن مشكلة قياسية على مستوى المحافظ أو مستوى المعاملات. بل نشأت من كيفية التحقق من كتل MWEB أثناء ربط السلسلة.

بينما عملت طبقات الميمبول وبناء المعاملات بشكل صحيح، فشلت خطوة التحقق النهائية على مستوى الإجماع في التحقق الكامل من سلامة بيانات تعريف MWEB مقابل المخرجات المشار إليها.

بمجرد اكتشاف الـ peg-out غير الطبيعي، حدد المعدنون بسرعة التناقض وشرعوا في اتخاذ إجراءات منسقة لمنع المزيد من الانتشار.

تم عزل المخرجات المشتبه بها، وجُمِد جزء من الأموال على مستوى البروتوكول لمنع تحريكها عبر الشبكة.

الاحتواء والتعافي وتنسيق المعدنين

بعد الاكتشاف، انتقل المطورون ومسابح التعدين الكبرى إلى وضع الاستجابة الطارئة.

لعبت مسابح التعدين، بما في ذلك F2Pool، دورًا مركزيًا في استقرار الشبكة عبر الاتفاق على قواعد تحقق محدثة ورفض بيانات MWEB المشوّهة.

ساعد هذا التنسيق في منع انتشار الاستغلال على طول السلسلة.

دخل المهاجم لاحقًا في مفاوضات وأعاد غالبية الأموال المستولى عليها.

تم استرداد حوالي 84,184 LTC عبر معاملات منسقة، بينما احتُفظ بمكافأة قدرها 850 LTC كجزء من الاتفاق مقابل التعاون في حل الحادث.

بدلاً من التراجع عن السلسلة، اختار المطورون نهج المصالحة.

قام النظام عمليًا بتحييد المخرج المتضخم من خلال إعادة توازن محاسبة MWEB عبر آليات peg-in محكومة وتجمد المخرجات غير الصالحة.

سمح هذا النهج للشبكة باستعادة الاتساق دون الحاجة إلى تراجع كامل.

حادث ثانٍ أدى إلى إعادة تنظيم للسلسلة بطول 13 كتلة

وقعت حادثة ثانوية مرتبطة في أبريل 2026، عندما كشفت محاولات إعادة استغلال نفس الثغرة عن ضعف مختلف في كيفية تعامل العقد مع بيانات MWEB المشوّهة.

هذه المرة، لم تؤدِ المشكلة إلى تضخم إضافي بل تسببت في عدم استقرار في معالجة العقد.

واجهت العقد المطوّرة توقفات في المعالجة عند مواجهة كتل MWEB متحورة، بينما استمر بعض المعدنين في تمديد سلسلة بُنيت على قواعد تحقق قديمة.

أدى هذا الانحراف إلى إعادة تنظيم مؤقتة للسلسلة بطول 13 كتلة، حيث قامت F2Pool بتعدين جزء كبير من الكتل المتأثرة خلال الفترة غير المستقرة.

كانت إعادة التنظيم قصيرة الأمد.

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

تصحيحات البروتوكول والحل النهائي

أصدر المطورون تحديثات طارئة ضمن سلسلة Core 0.21.5.x، تعالج كلًا من ثغرة التحقق الأصلية ومشكلة التعامل مع الكتل الثانوية.

عزّزت التصحيحات التحقق من مداخل MWEB أثناء ربط الكتل، وحسّنت معالجة حالات الكتل المتحورة، وعزّزت فحوصات التناسق عبر طبقات التعدين والإجماع.

أكد تحليل ما بعد الحادث أن الاستغلال لم ينتج عنه تضخم دائم أو فقدان سلامة السلسلة النهائية.

ومع ذلك، أبرز الحادث حساسية أنظمة كتل الامتداد مثل MWEB، حيث تضيف الخصوصية والتعقيد مخاطر تحقق جديدة.

مع استعادة تنسيق المعدنين، ونشر العقد المصلّحة، وتحيد المخرجات غير الصالحة، عادت الشبكة إلى تشغيل مستقر.