الإيمان الثابت بعد أزمة الأمان: لماذا لا يزال SUI يمتلك إمكانات نمو طويلة الأجل؟

1. سلسلة ردود الفعل الناتجة عن هجوم واحد

في 22 مايو 2025، تعرض بروتوكول AMM الرائد "Cetus" المستضاف على شبكة SUI لهجوم من قراصنة، حيث استغل المهاجمون ثغرة منطقية تتعلق بمشكلة "تجاوز العدد الصحيح"، مما أدى إلى تحكم دقيق تسبب في خسائر تزيد عن 200 مليون دولار. لم تكن هذه الحادثة واحدة من أكبر حوادث الأمان في مجال DeFi حتى الآن هذا العام فحسب، بل أصبحت أيضًا الهجوم الأكثر تدميرًا منذ إطلاق الشبكة الرئيسية SUI.

وفقًا لبيانات DefiLlama، انخفض TVL الكامل لشبكة SUI في يوم الهجوم بأكثر من 330 مليون دولار في لحظة واحدة، حيث تبخرت قيمة قفل بروتوكول Cetus بنسبة 84% على الفور، لتصل إلى 38 مليون دولار. وبالمثل، تأثرت العديد من الرموز الشائعة على شبكة SUI، حيث انخفضت بنسبة تتراوح بين 76% و97% في غضون ساعة واحدة، مما أثار اهتمام السوق بسلامة SUI واستقرار نظامها البيئي.

لكن بعد هذه الموجة من الصدمات، أظهر نظام SUI البيئي مرونة وقوة تعافي كبيرتين. على الرغم من أن حدث Cetus تسبب في تقلبات في الثقة على المدى القصير، إلا أن الأموال على السلسلة ونشاط المستخدمين لم تتعرض لانخفاض مستمر، بل على العكس، فقد أدى ذلك إلى تعزيز الاهتمام بالأمان وبناء البنية التحتية وجودة المشاريع في النظام البيئي بشكل ملحوظ.

ستقوم Klein Labs بتحليل أسباب حادثة الهجوم هذه، وآلية توافق العقد في SUI، وأمان لغة MOVE، وتطور النظام البيئي لـ SUI، لتوضيح الهيكل البيئي الحالي لسلسلة الكتل العامة التي لا تزال في مرحلة التطور المبكر، ومناقشة إمكانيات تطورها المستقبلية.

2. تحليل أسباب هجوم Cetus

2.1 تنفيذ هجوم

وفقًا للتحليل الفني لفريق Slow Mist حول حادثة هجوم Cetus، تمكن المخترقون من استغلال ثغرة في الرياضيات الأساسية في البروتوكول، مستفيدين من الاقتراض السريع، وتلاعب دقيق في الأسعار، وعيوب في العقود، وسرقة أكثر من 200 مليون دولار من الأصول الرقمية في فترة زمنية قصيرة. يمكن تقسيم مسار الهجوم تقريبًا إلى ثلاث مراحل رئيسية:

①اطلاق قرض سريع، التلاعب بالسعر

استغل القراصنة أولاً أقصى انزلاق لتبادل 100 مليار haSUI من القرض السريع، ليقترضوا مبالغ ضخمة ويقوموا بالتلاعب في الأسعار.

تسمح القروض الفورية للمستخدمين بالاقتراض وسداد الأموال في نفس المعاملة، مع دفع رسوم فقط، وتتميز برافعة مالية عالية ومخاطر منخفضة وتكاليف منخفضة. استغل القراصنة هذه الآلية لخفض سعر السوق في وقت قصير، وتحكموا بدقة في نطاق ضيق للغاية.

ثم قام المهاجم بإعداد إنشاء مركز سيولة ضيق للغاية، حيث تم تحديد نطاق السعر بدقة بين أقل عرض 300,000 وأعلى سعر 300,200، بعرض سعر لا يتجاوز 1.00496621٪.

من خلال الطريقة المذكورة أعلاه، تمكن القراصنة من السيطرة على سعر haSUI من خلال استخدام كمية كافية من الرموز والسيولة الضخمة. بعد ذلك، استهدفوا عدة رموز لا قيمة فعلية لها.

② إضافة السيولة

قام المهاجم بإنشاء مراكز سيولة ضيقة، مدعيًا أنه أضاف سيولة، ولكن بسبب وجود ثغرة في دالة checked_shlw، تم تحصيل 1 توكن فقط في النهاية.

هذا أساسًا بسبب سببين:

1. إعداد القناع واسع جدًا: يعادل حد كبير جدًا لإضافة السيولة، مما يؤدي إلى أن تحقق المستخدم في العقد يصبح بلا جدوى. قام القراصنة من خلال إعداد معلمات غير طبيعية، بإنشاء إدخال يكون دائمًا أقل من هذا الحد، وبالتالي تجاوزوا فحص التدفق الزائد.

2. تم اقتطاع تجاوز البيانات: عند إجراء عملية إزاحة على القيمة العددية n باستخدام n << 64، حدث اقتطاع للبيانات بسبب تجاوز الإزاحة عرض البتات الفعالة لنوع البيانات uint256 (256 بت). تم تجاهل الجزء العالي من التجاوز تلقائيًا، مما أدى إلى أن تكون نتيجة العملية أقل بكثير من المتوقع، مما جعل النظام يقلل من تقدير عدد haSUI المطلوب للتبادل. كانت النتيجة النهائية المحسوبة أقل من 1، ولكن نظرًا لأن الحساب تم عن طريق التقريب لأعلى، كانت النتيجة النهائية تساوي 1، مما يعني أن القراصنة يحتاجون فقط لإضافة توكن واحد، ليتمكنوا من استبدال سيولة ضخمة.

③ سحب السيولة

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

حالة خسارة الأموال خطيرة، الهجوم أدى إلى سرقة الأصول التالية:

• 12.9 مليون SUI (حوالي 54 مليون دولار)

• 60,000,000 دولار أمريكي

• 4.9 مليون دولار أمريكي من شركة Haedal Stakeed SUI

• مرحاض بقيمة 19.5 مليون دولار

• انخفضت العملات الأخرى مثل HIPPO و LOFI بنسبة 75--80%، مما أدى إلى نقص السيولة.

2.2 أسباب وخصائص الثغرة هذه

تتميز ثغرة Cetus هذه بثلاث خصائص:

1. تكلفة الإصلاح منخفضة للغاية: من ناحية، السبب الجذري لحدث Cetus هو خطأ في مكتبة الرياضيات الخاصة بـ Cetus، وليس خطأ في آلية التسعير للبروتوكول أو خطأ في البنية التحتية الأساسية. من ناحية أخرى، فإن الثغرة تقتصر فقط على Cetus نفسها، ولا علاقة لها بكود SUI. تكمن جذر الثغرة في شرط حدودي واحد، ويمكن القضاء على المخاطر تمامًا بتعديل سطرين من الكود؛ بعد الانتهاء من الإصلاح، يمكن نشره على الشبكة الرئيسية على الفور، مما يضمن أن منطق العقود المستقبلية كامل، ويمنع هذه الثغرة.

2. ارتفاع الخفاء: تم تشغيل العقد بسلاسة دون أي أعطال لمدة عامين، وقد خضع بروتوكول سيتوس لعدة تدقيقات، لكن لم يتم اكتشاف أي ثغرات، والسبب الرئيسي في ذلك هو أن مكتبة Integer_Mate المستخدمة في الحسابات الرياضية لم تكن مضمنة في نطاق التدقيق.

استغل القراصنة القيم المتطرفة لبناء نطاقات تداول بدقة، مما أدى إلى إنشاء مشاهد نادرة للغاية تتطلب تقديم سيولة عالية للغاية، مما أدى إلى تفعيل منطق غير عادي، مما يدل على أن مثل هذه المشاكل يصعب اكتشافها من خلال الاختبارات العادية. وغالبًا ما تكون هذه المشاكل في منطقة عمياء في رؤية الناس، وبالتالي تم اكتشافها بعد فترة طويلة.

3. ليست مشكلة خاصة بـ Move:

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

تمت ملاحظة ثغرات مماثلة في لغات أخرى مثل (Solidity وRust)، بل إن عدم وجود حماية من تجاوز السعة العددية جعلها أكثر عرضة للاستغلال؛ قبل تحديث إصدار Solidity، كانت فحوصات تجاوز السعة ضعيفة جداً. تاريخياً، حدثت تجاوزات في الجمع والطرح والضرب، والسبب المباشر لذلك هو أن نتيجة العمليات تجاوزت النطاق. على سبيل المثال، الثغرات الموجودة في عقود BEC وSMT الذكية بلغة Solidity، تم تنفيذها من خلال معلمات مصممة بعناية، مما أدى إلى تجاوز بيانات التحويل داخل العقد وتحقيق الهجوم.

3. آلية إجماع SUI

3.1 مقدمة في آلية توافق SUI

نظرة عامة:

SUI يعتمد إطار إثبات الحصة المفوض (DeleGated Proof of Stake، اختصاراً DPoS)، على الرغم من أن آلية DPoS يمكن أن تزيد من قدرة معالجة المعاملات، إلا أنها لا تستطيع توفير مستوى عالٍ جداً من اللامركزية كما في PoW (إثبات العمل). لذلك، فإن مستوى اللامركزية في SUI منخفض نسبياً، وعقبة الحوكمة مرتفعة نسبياً، مما يجعل من الصعب على المستخدمين العاديين التأثير مباشرة على حوكمة الشبكة.

• متوسط عدد المدققين: 106

• متوسط فترة الإيبوك: 24 ساعة

آلية العملية:

• تفويض الحقوق: لا يحتاج المستخدمون العاديون إلى تشغيل العقد بأنفسهم، فقط عليهم تدعيم SUI وتفويضها إلى المدققين المرشحين، ليتمكنوا من المشاركة في ضمان أمان الشبكة وتوزيع المكافآت. يمكن أن تقلل هذه الآلية من عتبة المشاركة للمستخدمين العاديين، مما يمكّنهم من المشاركة في توافق الشبكة من خلال "توظيف" المدققين الموثوقين. هذه أيضًا ميزة كبيرة لـ DPoS مقارنةً بـ PoS التقليدي.

• تمثيل دورة استخراج الكتل: يتم اختيار عدد قليل من المدققين لإصدار الكتل بترتيب ثابت أو عشوائي، مما يعزز سرعة التأكيد ويزيد من TPS.

• الانتخابات الديناميكية: بعد انتهاء كل فترة عد الأصوات، يتم إجراء تبديل ديناميكي وإعادة انتخاب مجموعة Validators وفقًا لوزن التصويت، لضمان حيوية العقد، وتوافق المصالح، واللامركزية.

مزايا DPoS:

• كفاءة عالية: نظرًا للتحكم في عدد عقد الكتلة، يمكن للشبكة إتمام التأكيد في مستوى مللي ثانية، مما يلبي احتياجات TPS العالية.

• تكلفة منخفضة: عدد العقد المشاركة في الإجماع أقل، مما يؤدي إلى تقليل عرض النطاق الترددي الشبكي وموارد الحوسبة المطلوبة لمزامنة المعلومات وتجميع التوقيعات بشكل ملحوظ. وبالتالي، تنخفض تكاليف الأجهزة والصيانة، وتنخفض متطلبات قوة الحوسبة، مما يؤدي إلى تكاليف أقل. وفي النهاية، تحقق رسوم مستخدمين أقل.

• أمان عالي: آلية الرهن والتفويض تجعل تكلفة الهجوم والمخاطر تتزايد بالتزامن؛ مع آلية مصادرة على السلسلة، يتم كبح التصرفات الخبيثة بفعالية.

في نفس الوقت، في آلية توافق SUI، تم اعتماد خوارزمية قائمة على BFT (التسامح مع الأخطاء البيزنطية)، مما يتطلب أن تتفق أكثر من ثلثي الأصوات من المدققين لتأكيد المعاملات. تضمن هذه الآلية أنه حتى لو أفسد عدد قليل من العقد، يمكن أن تظل الشبكة آمنة وتعمل بكفاءة عالية. كما يتطلب الأمر أكثر من ثلثي الأصوات لتنفيذ أي ترقية أو قرار كبير.

من الناحية الجوهرية، تعتبر DPoS حلاً وسطياً لنظرية "المثلث المستحيل"، حيث تم التوصل إلى توازن بين اللامركزية والكفاءة. تختار DPoS تقليل عدد العقد النشطة لإنتاج الكتل من أجل تحقيق أداء أعلى في "المثلث المستحيل" للأمان واللامركزية وقابلية التوسع، مما يعني التخلي عن درجة معينة من اللامركزية الكاملة مقارنةً بـ PoS أو PoW، لكنها تعزز بشكل ملحوظ من قدرة الشبكة على معالجة البيانات وسرعة المعاملات.

3.2 خلال هذا الهجوم، كانت أداء SUI

3.2.1 آلية تجميد التشغيل

في هذه الحادثة، قامت SUI بتجميد سريع للعناوين المتعلقة بالجهات المهاجمة.

من منظور الكود، فإنه يجعل من المستحيل تجميع معاملات التحويل على السلسلة. تعتبر عقد التحقق المكون الأساسي في سلسلة كتل SUI، حيث تتحمل مسؤولية التحقق من المعاملات وتنفيذ قواعد البروتوكول. من خلال تجاهل المعاملات المرتبطة بالجهات المهاجمة بشكل جماعي، فإن هؤلاء المدققين يطبقون في الواقع آلية مشابهة لآلية "تجميد الحسابات" في التمويل التقليدي على مستوى الإجماع.

SUI يحتوي على آلية قائمة الرفض (deny list) مدمجة، وهي ميزة قائمة سوداء يمكن أن تمنع أي معاملات تتعلق بالعناوين المدرجة. نظرًا لأن هذه الميزة موجودة في العميل، فعندما يحدث الهجوم

SUI يمكنه تجميد عنوان المخترق على الفور. إذا لم تكن هذه الميزة موجودة، حتى لو كان لدى SUI 113 مدقق فقط، سيكون من الصعب على Cetus تنسيق جميع المدققين للاستجابة واحدًا تلو الآخر في فترة زمنية قصيرة.

3.2.2 من يملك الحق في تعديل القائمة السوداء؟

TransactionDenyConfig هو ملف تكوين YAML/TOML يتم تحميله محليًا بواسطة كل مُصادق. يمكن لأي شخص يقوم بتشغيل العقدة تحرير هذا الملف وإعادة تحميله بشكل حار أو إعادة تشغيل العقدة وتحديث القائمة. من الظاهر أن كل مُصادق يبدو أنه يعبر بحرية عن قيمه.

في الواقع، من أجل التناسق والفعالية في سياسة الأمان، فإن تحديثات هذا التكوين الرئيسي تتم عادةً بشكل منسق. نظرًا لأنها "تحديث طارئ مدفوع من قبل فريق SUI"، فإن أساسًا مؤسسة SUI (أو المطورين المعتمدين من قبلها) هم من يقومون بإعداد وتحديث قائمة الرفض هذه.

أصدرت SUI قائمة سوداء، ومن الناحية النظرية يمكن للمتحققين اختيار ما إذا كانوا سيتبنونها أم لا------ لكن في الواقع، يفترض معظم الناس أنهم سيتبنونها تلقائيًا. لذلك، على الرغم من أن هذه الميزة تحمي أموال المستخدمين، إلا أنها في جوهرها تحتوي بالفعل على درجة معينة من المركزية.

3.2.3 جوهر وظيفة القائمة السوداء

ميزة القائمة السوداء ليست في الواقع منطقًا أساسيًا للبروتوكول، بل إنها أشبه بوسيلة للتعامل مع الحالات الطارئة، لضمان سلامة أموال المستخدمين.

إنها في الأساس آلية لضمان الأمان. تشبه "سلسلة الأمان" المرتبطة بالباب، حيث يتم تفعيلها فقط ضد أولئك الذين يريدون اقتحام المنزل، أي ضد الأشخاص الذين يسعون لإساءة استخدام البروتوكول. بالنسبة للمستخدمين:

• بالنسبة للمتداولين الكبار، فإن مقدمي السيولة الرئيسيين، فإن البروتوكول هو الأكثر حرصًا على ضمان أمان الأموال، لأنه في الواقع، فإن بيانات السلسلة tvl كلها تأتي من المساهمات الرئيسية للمتداولين الكبار، ولضمان التطور المستدام للبروتوكول، يجب بالضرورة ضمان الأمان أولاً.

• بالنسبة للمستثمرين الأفراد، فإنهم مساهمون في نشاط النظام البيئي، وداعمون أقوياء في بناء التكنولوجيا والمجتمع. كما تأمل الجهات المعنية في جذب المستثمرين الأفراد للمشاركة في البناء.