مقدمة
في 22 مايو، تعرض Cetus، بروتوكول DEX الرائد في نظام Sui البيئي، لهجوم من قبل قراصنة. ظهرت ثغرة أمنية في العقد الأساسي للبروتوكول، واستغل المهاجم الفرصة لسرقة كمية كبيرة من الأصول. وقد جذبت هذه الحادثة اهتمامًا واسع النطاق في فترة قصيرة من الزمن، ولم تؤثر على المستخدمين ذوي الصلة فحسب، بل دفعت أيضًا العديد من مشاريع Sui إلى دخول حالة الاستجابة للطوارئ.
ولكن ما تلا ذلك لم يكن تراجعًا عن السلسلة أو تدخلًا من سلطة فائقة، بل بداية سريعة: تصويت المحقق، وإغلاق المشروع طواعية، وتجميد سلسلة الأصول، والتفتيش الذاتي للبروتوكول والترقية... شكلت العملية برمتها تمرينًا حقيقيًا في حوكمة الأمن المالي على السلسلة.
حتى وقت كتابة هذا المقال، مرت خمسة أيام منذ الهجوم الذي شنه القراصنة. كان لهذا الحادث تأثير واسع النطاق وأثار مناقشات ساخنة في المجتمع حول "الأمان على السلسلة" و"الحوكمة اللامركزية" و"استجابة الطوارئ البروتوكولية". تحاول هذه المقالة الإجابة على السؤال التالي: ما الذي حدث بالضبط هذه المرة؟ أين تقع المسؤولية؟ كيف يستجيب النظام البيئي لسوي؟ ماذا يمكننا أن نتعلم من هذا؟
كيف حدث الهجوم؟
وقع الهجوم في صباح يوم 22 مايو 2025، مستهدفًا مجمع السيولة CLMM التابع لشركة Cetus. اكتشف المهاجم ثغرة في العقد واستخدم المعاملات المصطنعة لاستخراج الأصول في جولات متعددة من العمليات.
العملية المحددة هي كما يلي:
حوالي الساعة 10:30 بالتوقيت العالمي المنسق، بدأ الهجوم. قام المخترق بخفض السعر في المجمع من خلال معاملات غير طبيعية، وفتح مراكز سيولة في منطقة السعر المرتفع، واستغل ثغرات منطق العقد لحقن كمية كبيرة من السيولة "المزيفة" بكمية صغيرة جدًا من الرموز.
بعد ذلك، قام المخترق بتنفيذ "إضافة/إزالة السيولة" بشكل متكرر لسحب الأصول الفعلية من المجمع.
استمر الهجوم حوالي 20 دقيقة، وبدأت بعض أنظمة المراقبة في إطلاق الإنذارات.
بعد 40 دقيقة من الهجوم
10:40 بالتوقيت العالمي المنسق، اكتشف نظام مراقبة Cetus سلوكًا غير طبيعي للمسبح. في الساعة 10:53 بالتوقيت العالمي المنسق، أكد فريق Cetus مصدر الهجوم وأخطر المشاريع الأخرى في نظام Sui البيئي.
في الساعة 10:57 بالتوقيت العالمي المنسق، أغلقت شركة Cetus على الفور مجمع السيولة الأساسي لمنع المزيد من الخسائر. 11:20 بالتوقيت العالمي المنسق، سيتم تعليق جميع العقود ذات الصلة. وكان رد الفعل سريعًا، لكن المتسللين سرقوا بالفعل مبلغًا كبيرًا من الأموال.
كيفية تجميد أموال الهاكر؟
بعد توسع الحادث، أطلق النظام البيئي استجابة طارئة على نطاق أوسع:
بدأ محققو Sui بسرعة التعاون على السلسلة وصوتوا على ما إذا كانوا سيرفضون حزم المعاملات من عنوان المخترق؛
بعد الوصول إلى عتبة المشاركة البالغة 33%، تم تجميد عنوان المخترق بشكل فعال، ولم يعد من الممكن معالجة المعاملات على السلسلة.
هذا ليس تراجعًا عن النظام أو تدخلاً في الخلفية، بل عملية يقوم بها المحقق من خلال آلية الإجماع. لم يتم تغيير حالة السلسلة، ولم يتم العبث بمعاملات المستخدم، وتم إكمال كل شيء بناءً على القواعد الموجودة على السلسلة. يشير ما يسمى بـ "استعادة النظام" إلى إعادة حالة شبكة blockchain بأكملها إلى لحظة معينة قبل الهجوم، تمامًا مثل إعادة الزمن إلى الوراء. وهذا يعني عادةً أن المعاملات المؤكدة بالفعل سيتم مسحها وإعادة كتابة تاريخ السلسلة. يشير مصطلح "التدخل خلف الكواليس" إلى سلطة مركزية (مثل مالك المشروع أو المؤسسة) تتلاعب بشكل مباشر بالعقد أو الأموال وتتخذ قرارات المعالجة متجاوزة الإجراءات العادية.
لم يحدث أي مما سبق في هذه الحادثة. يقوم المحقق بتنفيذ التجميد من خلال التصويت العام واتخاذ القرارات المستقلة وفقًا لقواعد السلسلة، وهو تجسيد للحوكمة اللامركزية.
ما هو الوضع المالي الحالي؟
البيانات التي أصدرتها شركة Cetus هي كما يلي:
سرق المتسللون ما مجموعه حوالي 230 مليون دولار أمريكي من الأصول؛
ومن بين هذه الأصول، لا تزال 160 مليون دولار أميركي موجودة في عنوانين مجمدين في سويسرا ولم يعد من الممكن تحويلها؛ تم نقل 60 مليون دولار أمريكي من الأصول عبر السلسلة إلى إيثريوم، ولا يزال يتم تعقب عنوانين معروفين.
يعمل البروتوكول على تعزيز التصويت المجتمعي لتحديد كيفية إعادة الأصول والتعويض.
لماذا وقع الحادث؟ هل المشكلة في السلسلة نفسها؟ أم أنها مشكلة تتعلق بضعف طبقة التطبيق؟
وفقًا لتقرير SlowMist وتحليل الخبراء الفنيين، فإنهم جميعًا يشيرون إلى نفس المشكلة:يكمن السبب الجذري للحادث في المشكلة المتعلقة بمنطق الكود مفتوح المصدر المستخدم في عقد Cetus. استغل المهاجم خطأً يتعلق بفحص تجاوز البيانات في عقد طبقة التطبيق. لو تم اكتشاف الثغرة وإصلاحها مسبقًا، لما حدثت أي خسائر. لذلك، فهي ليست ثغرة في لغة البرمجة Move نفسها.
ومن المهم بنفس القدر:لم تتعرض شبكة Sui نفسها للهجوم ولم يشكل ذلك أي خطر على النظام.
هذه حادثة أمان قياسية على مستوى طبقة البروتوكول، وليست مشكلة أمان على مستوى طبقة السلسلة.

بعد الهجوم، كيف تصرفت المشاريع الأخرى في نظام Sui البيئي؟
بعد إغلاق Cetus، بدأت العديد من المشاريع على Sui في إجراء عمليات تفتيش ذاتية للأمن. لقد لاحظنا أن بروتوكول Momentum قام أيضًا بتعليق المعاملات بمجرد حدوث الهجوم، وأكمل عملية تدقيق كاملة لسلسلة التعليمات البرمجية والتحقيق في المخاطر، واستعاد الأموال المسروقة بعد تجميدها.
باعتبارها Dex الرائدة في نظام Sui البيئي، أوقف بروتوكول Momentum التداول على الفور وتعاون مع مؤسسة Sui لحظر الأموال المسروقة لمنع المتسللين من نشرها إلى المزيد من حسابات الأصول التجارية من خلال معاملات Dex. وفي الوقت نفسه، تم إجراء فحص ذاتي شامل. بعد أن أصبحت نتائج الفحص الذاتي صحيحة وبعد التأكد من تجميد الأموال المسروقة بنجاح من قبل مؤسسة Sui، تمت استعادة وظيفة التداول أولاً.
ما هي متابعة الحادثة؟
حاليًا:
أكملت شركة Cetus إصلاح الثغرة الأمنية الأساسية وهي تراجع الكود مع فريق التدقيق؛
يجري صياغة خطة تعويض للمستخدمين، والتي ستعتمد جزئيًا على قرار التصويت على اقتراح الحوكمة البيئية؛
كما استأنفت مشاريع Sui الأخرى عملياتها أو تستكمل تعزيز الأمن.
ولم يتوقف النظام البيئي بأكمله. وبدلاً من ذلك، تمت مراجعة آلية السلامة بشكل أكثر منهجية بعد الحادث.
ماذا تخبرنا هذه الحادثة؟
لقد أدى الهجوم على Cetus مرة أخرى إلى جعل جميع المطورين والمستخدمين يواجهون مشكلة واقعية:
على ماذا يعتمد أمان البروتوكول؟
أصبحت الإجابة واضحة بشكل متزايد:
اعتمادًا على الحكمة الجماعية التي جلبتها اللامركزية، وعدم استخدام اللامركزية كذريعة للتقاعس؛
اعتمادًا على الاستثمار المنهجي المستمر، وليس تقرير تدقيق واحد أو اثنين؛
اعتمادًا على الاستعدادات المعتادة وبناء الآلية، وليس فقط العلاجات بعد الحدث؛
اعتمادًا على رغبة كل مشارك في تحمل المسؤولية واتخاذ إجراءات استباقية، بدلاً من إلقاء اللوم على "السلسلة" أو "التكنولوجيا" في المشكلة.
لقد رأينا أن المتسللين تسببوا في خسائر، لكنهم لم يدمروا النظام؛ لقد رأينا أيضًا أن اللامركزية لا تتعلق بالاختباء وراء القواعد والمراقبة من الهامش، بل تتعلق بالتجمع بشكل عفوي للدفاع عن النتيجة النهائية وحماية المستخدمين.
الخلاصة
اللامركزية الحقيقية ليست شعارًا، بل مسؤولية
لا يوجد منقذ في هذه العاصفة.
صوّت محققو Sui على تجميد المعاملات المحفوفة بالمخاطر؛ وأكملت بروتوكولات أخرى عمليات التفتيش الأمني الذاتية، واستأنف بعضها العمل عبر الإنترنت بسرعة؛ كما يولي المستخدمون أيضًا اهتمامًا وثيقًا ويشجعون التحسينات.
اللامركزية ليست سياسة عدم التدخل، بل هي تعاون مع حدود ومبادئ ومسؤوليات. في نظام بدون واجهة خلفية، يجب دعم الثقة من خلال كل سطر من التعليمات البرمجية، وكل آلية، وكل قرار.
إن هذه الحادثة أزمة واختبار ومرآة.
يخبرنا:
اللامركزية ليست هدفًا، بل هي طريقة. الهدف هو بناء الثقة؛ إن اللامركزية تجلب الحكمة الجماعية.
إن اللامركزية مهمة، ولكن كفاءة رأس المال وأمان البروتوكول أكثر أهمية.