توجد لدى BTCVN4 إشارات غير جيدة.
في 31/8، وقع في Injective استغلال (exploit) تسبب في خسائر بنحو 4.9 مليون دولار. في البداية، وُصفت الحادثة بأنها هجوم موجّه ضد بعض تطبيقات Binary Options ضمن النظام البيئي.
ومع ذلك، يثير تقرير تحليل مؤرخ في 3/9 مشكلة أكثر خطورة:
👉 قد تكون الثغرة قد تفاعلت مع وحدات native/core الخاصة بـ Injective نفسها، بدلًا من أن تكون موجودة فقط في تطبيق Binary Options خارجي.
وهنا تحديدًا ما يجب أن يركز عليه حاملو INJ.
1. تصادم Market-ID: نقطة انطلاق عملية الاستغلال
بحسب التحليلات على السلسلة، استغل المهاجم خطأً متعلقًا بطريقة إنشاء Injective للـ market ID.
يتكوّن Market ID من عدة حقول بيانات مثل:
• نوع Oracle
• الرمز
• Quote denomination
• رمز Oracle
• مزود Oracle
تكمن المشكلة في كيفية دمج هذه الحقول دون وجود آلية فصل/طول واضحة بما يكفي.
وهذا يمكن نظريًا أن يخلق حالة:
تكويدان مختلفان للسوق → ينتجان نفس market ID.
استغل المهاجم هذه القدرة لإنشاء أسواق Binary Options ببنية خاصة، ثم تفاعل مع منطق التسوية/الاسترداد.
تشير التقارير إلى أن المهاجم أنشأ نحو 299 سوقًا خلال حوالي 19 ساعة، وتمكن في النهاية من سحب نحو 4.9 مليون دولار.
2. لكن السؤال الأهم: أين يقع الخطأ؟
وهذا هو الجزء الجدير بالانتباه.
أكدت Injective أن:
• لم يتم اختراق آلية الإجماع
• لم يتأثر INJ الأصلي
• لا تزال أصول Staked INJ آمنة
• أثرت الحادثة فقط على بعض التطبيقات التي تستخدم Binary Options
وهذا خبر جيد لحاملي INJ.
لكن بعض التحليلات المستقلة تقول إن القصة أكثر تعقيدًا.
بحسب الباحث Earthling Paddy، فإن الاستغلال كان مرتبطًا بوحدات native exchange وinsurance الخاصة بـ Injective.
بمعنى آخر:
قد تكون Binary Options هي “البوابة” التي استخدمها المهاجم، لكن المنطق المستغل يقع أعمق داخل وحدات البروتوكول.
وهذا فرق بالغ الأهمية.
إذا كان الخطأ محصورًا في عقد ذكي/تطبيق مستقل → فمجال الخطر يكون ضيقًا نسبيًا.
لكن إذا كان التطبيق قادرًا على تفعيل منطق خاطئ داخل وحدات البروتوكول الأصلية، فتصبح المشكلة:
هجوم على طبقة التطبيق → لكن سطح الهجوم يقع في طبقة البروتوكول.
🔴 3. أوضح دليل: التصحيح العاجل عدّل منطق CORE
من أبرز التفاصيل التي لفتت انتباه BTCVN4 هو الترقية العاجلة نفسها:
v1.20.3-safeharbor.1
وقد تم نشر هذا الإصدار على شبكة Injective الرئيسية أثناء معالجة الحادث.
وبحسب التقارير التحليلية، فإن التصحيح أجرى تغييرات ملحوظة مثل:
✅ إضافة فحص denomination إلى insurance fund.
✅ تعطيل تسوية Binary Options على الشبكة الرئيسية.
واللافت أن هذه التغييرات تقع ضمن كود البلوكتشين الأساسي.
لذلك، يطرح السؤال المنطقي نفسه:
إذا كانت المشكلة محصورة بالكامل في تطبيق خارجي لـ Binary Options، فلماذا احتاج التصحيح العاجل إلى تعديل المنطق في طبقة البروتوكول/النواة؟
وهذا ليس دليلًا كافيًا للجزم بأن إجماع Injective أو INJ الأصلي قد تعرّضا للاختراق.
لكنه مؤشر قوي بما يكفي لئلا نختزل الحادثة إلى أنها “مجرد تطبيق خارجي تم اختراقه”.
4. هل تم “إيقاف” السلسلة فعلًا أم أنها مجرد ترقية طارئة؟
وهذه أيضًا نقطة مثار جدل.
وصفت Injective الحادثة بأنها ترقية شبكة متسارعة، مؤكدةً في الوقت نفسه أن البلوكتشين والإجماع ما زالا آمنين.
ومع ذلك، تشير بيانات السلسلة التي حللها بعض الباحثين إلى أنه لم يظهر أي بلوك جديد لمدة نحو 3 ساعات و42 دقيقة، خلال الوقت الذي نشر فيه المدققون الترقية العاجلة.
حتى إن بعض المدققين وُضعوا في الجيل لعدم استكمال الترقية ضمن المهلة المطلوبة.
لذلك، من الناحية التقنية، هناك فرق بين:
“تم اختراق الإجماع” و“تم تعليق إنتاج الكتل لتطبيق تصحيح طارئ”.
هذان الأمران ليسا متطابقين.
في الوقت الحالي، تدعم البيانات الرأي القائل إن المهاجم لم يستولِ على آلية الإجماع، لكن الشبكة تعرضت لاضطراب ملحوظ أثناء الاستجابة للحادث.
5. ما الذي نعرفه بالفعل؟
في الوقت الراهن، هناك بعض النقاط الواضحة نسبيًا:
1️⃣ تم استغلال نحو 4.9 مليون دولار.
2️⃣ استخدم المهاجم تصادم market-ID في منطق تسوية Binary Options.
3️⃣ يُعتقد أن نحو 1,980 ETH قد تم تحويلها إلى Ethereum، وما تزال موجودة حاليًا في العنوان المرتبط بالحادث وفقًا للتقارير المنشورة.
4️⃣ نشرت Injective الإصدار الطارئ v1.20.3-safeharbor.1.
5️⃣ تم تعطيل تسوية Binary Options على الشبكة الرئيسية.
6️⃣ تمت إضافة فحص للـ denomination في منطق insurance fund.
7️⃣ أكدت Injective أن الإجماع وINJ الأصلي وأصول staking لم تتعرض للاختراق.
تُظهر هذه النقاط أن عملية الاستغلال تم احتواؤها بسرعة نسبيًا، وأن الضرر لم يتحول إلى هجوم على طبقة الإجماع.
6. لكن ما الذي لا يزال بلا إجابة؟
وهذا هو الجزء الذي يرى BTCVN4 أن على حاملي INJ متابعته عن كثب.
❓ ما مسار الهجوم بالضبط؟
❓ ما الوحدات التي تفاعل معها تصادم market-ID؟
❓ لماذا استلزم خطأ بدأ من Binary Options تعديل منطق البروتوكول الأساسي؟
❓ ما حجم الخسارة النهائية؟
❓ من الذي تحمل فعليًا فجوة الخسارة البالغة نحو 4.9 مليون دولار؟
❓ هل تم استرداد الأموال المستغلة أم لا؟
❓ هل توجد متغيرات أخرى من نفس فئة الثغرة؟
❓ هل توجد وحدات native أخرى تستخدم منطق market-ID مشابهًا وتحتاج إلى إعادة التدقيق؟
والأهم من ذلك كله:
هل فحصت Injective كامل سطح الهجوم في الوحدات الأصلية أم أنها أغلقت فقط متجه Binary Options؟
سيكون تقرير تقني كامل لما بعد الحادث مهمًا جدًا للإجابة عن هذه الأسئلة.
تقول التقارير الحالية إن Injective لم تنشر بعد تقريرًا تقنيًا كاملًا لما بعد الحادث يصف مسار التنفيذ بالكامل وتوزيع الخسائر.
7. فكيف ينبغي لحاملي INJ أن يفهموا هذا الحادث؟
برأيي، لا ينبغي بعدُ الجزم بأن Injective تعرضت إلى “core compromise”.
لأنه لا توجد حتى الآن أدلة على أن:
تمكن المهاجم من السيطرة على الإجماع.
تم سك INJ الأصلي بشكل غير مشروع.
سرقة Staked INJ.
تمكن المهاجم من السيطرة على مجموعة المدققين.
لكن في الوقت نفسه لا ينبغي التقليل من شأن الحادث.
لأنه إذا تأكدت التقارير المتعلقة بتصادم market-ID والتفاعل مع core module في تقرير ما بعد الحادث، فإن جوهر القضية سيكون أخطر بكثير من مجرد عقد ذكي معطوب لـ Binary Options.
سيوضح ذلك:
يمكن لتطبيق ما أن يفعّل منطقًا خطيرًا موجودًا داخل وحدات البروتوكول الأصلية.
هذه مشكلة تتعلق ببنية أمان البروتوكول، وليست مجرد خطأ في dApp واحد.
وجهة نظر BTCVN4
أعتقد أن هناك طبقتين من المعلومات يجب الفصل بينهما حاليًا:
الطبقة 1 – الخبر الجيد:
تمكنت Injective من احتواء عملية الاستغلال، ولم يتم اختراق آلية الإجماع بحسب المعلومات المتاحة، كما بقي INJ الأصلي والـ staking محميين.
الطبقة 2 – المخاطر التي يجب مراقبتها:
إذا كان تصادم market-ID ناتجًا فعلاً من أو يمكنه التأثير في وحدات native exchange/insurance، فعلينا أن نعرف إلى أي مدى تمتد فئة الثغرة هذه.
هذا هو ما يحدد مستوى الخطر طويل الأمد على INJ.
لذلك، من وجهة نظري:
👉 لا تنشروا الذعر بأن INJ قد انهار.
لكن أيضًا:
👉 لا تتسرعوا في استنتاج أن الأمر “مجرد Binary Options وبالتالي لا علاقة له بالبروتوكول”.
هاتان النهايتان المتطرفتان غير صحيحتين.
الأمر الأكثر انتظارًا الآن ليس تغريدة تطمئن السوق.
بل هو:
تقرير تقني كامل لما بعد الحادث.
إذا أثبت تقرير ما بعد الحادث أن الثغرة كانت محصورة فقط في Binary Options وأن الوحدات ذات الصلة خضعت لتدقيق شامل → فسيتراجع الخطر بشكل ملحوظ.
وعلى العكس، إذا تبيّن أن تصادم market-ID أو منطقًا مشابهًا موجودًا في وحدات native متعددة أخرى → فقد يتحول هذا إلى مشكلة كبيرة بالنسبة للفرضية طويلة الأمد لـ INJ.
ينبغي على حاملي INJ مراقبة 4 أمور بشكل خاص في الأيام المقبلة:
تقرير تقني رسمي لما بعد الحادث.
ما إذا كانت هناك ثغرة إضافية في وحدات native exchange/insurance.
ما إذا كان مبلغ ~4.9 مليون دولار قد تم استرداده أم لا يزال في محفظة المهاجم.
ما إذا كان المدققون وexchange ونظام Injective البيئي قد عادوا للعمل الطبيعي بالكامل أم لا.
ليس هذا وقت الذعر، لكنه بالتأكيد وقت رفع مستوى الحذر.
حظًا موفقًا من BTCVN4
