الإيمان الثابت بعد أزمة الأمان: لماذا لا يزال 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 Mist حول حادثة هجوم Cetus، تمكن القراصنة من استغلال ثغرة تدفق حسابي رئيسية في البروتوكول، باستخدام القروض الفورية، والتلاعب الدقيق بالأسعار، وعيوب العقود، وسرقوا أكثر من 200 مليون دولار من الأصول الرقمية في فترة زمنية قصيرة. يمكن تقسيم مسار الهجوم بشكل أساسي إلى المراحل الثلاث التالية:

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

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

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

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

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

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

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

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

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

2. تم قطع زيادة البيانات: عند تنفيذ عملية التحويل n << 64 على القيمة العددية n، حدث قطع للبيانات بسبب تجاوز الإزاحة العرض الفعال لنوع البيانات 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. مستوى عالٍ من التعتيم: تم تشغيل العقد بسلاسة لمدة عامين دون أي أعطال، وقام بروتوكول Cetus بعدة عمليات تدقيق، لكن لم يتم اكتشاف أي ثغرات، والسبب الرئيسي هو أن مكتبة 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

• متوسط دورة الـ Epoch: 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 كلها تأتي من المساهمات الرئيسية للجهات الكبيرة، وإذا أراد البروتوكول التطور على المدى الطويل، فإنه سيتعين عليه إعطاء الأولوية لضمان الأمان.

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