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

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

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

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

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

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

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

2.1 تنفيذ هجوم

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

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

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

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

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

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

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

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

في الأساس بسبب سببين:

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

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

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

مزايا 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 كلها تأتي من المساهمات الرئيسية للكيانات الكبرى، ولضمان التنمية المستدامة للبروتوكول، من المؤكد أنه سيفضل ضمان الأمان.

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