الإيمان الثابت بعد أزمة الأمان: لماذا لا يزال SUI يتمتع بإمكانية نمو طويلة الأجل؟
1. رد فعل متسلسل ناتج عن هجوم واحد
في 22 مايو 2025، تعرض بروتوكول AMM الرائد "Cetus" الموزع على شبكة SUI لهجوم قراصنة، حيث استغل المهاجم ثغرة منطقية تتعلق بمشكلة "overflow integers"، مما أدى إلى خسارة أصول تتجاوز 200 مليون دولار. لم تكن هذه الحادثة واحدة من أكبر حوادث الأمان في مجال DeFi حتى الآن هذا العام فحسب، بل أصبحت أيضًا أكثر الهجمات تدميرًا منذ إطلاق الشبكة الرئيسية لـ SUI.
وفقًا للبيانات، شهدت القيمة الإجمالية المقفلة (TVL) على سلسلة SUI انخفاضًا حادًا تجاوز 330 مليون دولار في يوم وقوع الهجوم، كما تبخر مبلغ الإغلاق الخاص ببروتوكول Cetus بشكل瞬ى بنسبة 84%، ليصل إلى 38 مليون دولار. نتيجة لذلك، تأثرت العديد من الرموز الشهيرة على SUI، حيث انخفضت بشكل كبير بنسبة 76% إلى 97% في غضون ساعة واحدة، مما أثار اهتمام السوق بسلامة SUI واستقرار النظام البيئي.
لكن بعد هذه الموجة من الصدمات، أظهر نظام SUI الإيكولوجي مرونة وقوة استعادة كبيرة. على الرغم من أن حدث Cetus أدى إلى تقلبات في الثقة على المدى القصير، إلا أن الأموال على السلسلة ونشاط المستخدمين لم تتعرض لتراجع مستمر، بل بالعكس، ساهمت في تعزيز الاهتمام في الأمان، وبناء البنية التحتية وجودة المشاريع بشكل ملحوظ.
ستتناول هذه المقالة أسباب حادثة الهجوم هذه، وآلية توافق العقد الخاصة بـ SUI، وأمان لغة MOVE، وتطور نظام SUI البيئي، وستستعرض الوضع البيئي الحالي لهذه السلسلة العامة التي لا تزال في مرحلة التطوير المبكر، وستناقش إمكانيات تطورها المستقبلية.
2. تحليل أسباب هجوم حدث Cetus
2.1 عملية تنفيذ الهجوم
وفقًا للتحليل الفني لفريق الأمان حول حادثة هجوم Cetus، تمكن القراصنة من استغلال ثغرة تجاوز عددي حاسمة في البروتوكول، من خلال استخدام القروض الفورية، وتلاعب دقيق في الأسعار، وعيوب في العقود، وسرقة أكثر من 200 مليون دولار من الأصول الرقمية في فترة زمنية قصيرة. يمكن تقسيم مسار الهجوم تقريبًا إلى المراحل الثلاث التالية:
①قم بإطلاق قرض فوري، وتلاعب بالسعر
استغل القراصنة أولاً أكبر انزلاق في تبادل 100 مليار haSUI من القروض الفورية، واستدانوا كميات كبيرة من الأموال، وقاموا بالتلاعب بالأسعار.
تسمح القروض الفورية للمستخدمين باقتراض وإرجاع الأموال في نفس المعاملة، مع دفع رسوم فقط، مما يوفر خصائص مثل الرفع العالي، المخاطر المنخفضة، والتكاليف المنخفضة. استخدم القراصنة هذه الآلية لتقليل الأسعار في السوق في فترة قصيرة، وتحكموا فيها بدقة ضمن نطاق ضيق جدًا.
بعد ذلك، كان المهاجمون يستعدون لإنشاء مركز سيولة ضيق للغاية، مع تحديد نطاق السعر بدقة بين أدنى عرض 300,000 وأعلى سعر 300,200، ليكون عرض السعر فقط 1.00496621%.
من خلال الطريقة المذكورة أعلاه، تمكن القراصنة من التحكم في سعر haSUI باستخدام كمية كافية من الرموز والسيولة الكبيرة. بعد ذلك، قاموا بالتحكم في عدة رموز بلا قيمة فعلية.
② إضافة السيولة
قام المهاجم بإنشاء مركز سيولة ضيق، مدعياً أنه أضاف سيولة، ولكن بسبب وجود ثغرة في دالة checked_shlw، حصل في النهاية على 1 توكن فقط.
في جوهرها، يعود ذلك إلى سببين:
إعداد القناع واسع جدًا: يعادل حدًا كبيرًا جدًا لإضافة السيولة، مما يؤدي إلى عدم وجود تحقق من إدخال المستخدم في العقد. استخدم المتسلل معلمات غير طبيعية، حيث قام ببناء مدخلات تكون دائمًا أقل من هذا الحد، متجاوزًا بذلك كشف الفائض.
تم قطع تجاوز البيانات: عند تنفيذ عملية الإزاحة 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 هذه بثلاث سمات:
تكلفة الإصلاح منخفضة جداً: من ناحية، السبب الجذري لحدث Cetus هو إغفال في مكتبة الرياضيات الخاصة بـ Cetus، وليس خطأ في آلية تسعير البروتوكول أو خطأ في البنية التحتية الأساسية. من ناحية أخرى، فإن الثغرة محصورة فقط في Cetus ولا تتعلق بشيفرة SUI. تكمن جذور الثغرة في شرط حدودي، ولا يتطلب الأمر سوى تعديل سطرين من الشيفرة للقضاء على المخاطر تماماً؛ بعد الانتهاء من الإصلاح، يمكن نشره على الشبكة الرئيسية على الفور، مما يضمن استكمال منطق العقد في المستقبل ويمنع هذه الثغرة.
ارتفاع الخصوصية: تم تشغيل العقد بشكل مستقر دون أي أعطال لمدة عامين، وتم إجراء العديد من التدقيقات، لكن لم يتم اكتشاف أي ثغرات، والسبب الرئيسي في ذلك هو أن مكتبة Integer_Mate المستخدمة في الحسابات الرياضية لم تكن مشمولة في نطاق التدقيق.
استغل القراصنة القيم القصوى لبناء نطاقات تداول بدقة، وخلق سيناريوهات نادرة للغاية تتطلب تقديم سيولة مرتفعة جداً، مما أدى إلى تفعيل منطق استثنائي، مما يدل على أن مثل هذه المشاكل يصعب اكتشافها من خلال الاختبارات العادية. غالباً ما تكون هذه المشاكل في منطقة عمياء في رؤية الناس، لذا تم اكتشافها بعد فترة طويلة.
ليست مشكلة خاصة بـ 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 مدققًا فقط، سيكون من الصعب تنسيق جميع المدققين للرد واحدًا تلو الآخر في فترة زمنية قصيرة.
3.2.2 من يملك الحق في تعديل القائمة السوداء؟
TransactionDenyConfig هو ملف إعداد YAML/TOML يتم تحميله محليًا بواسطة كل مُصادق. يمكن لأي شخص يقوم بتشغيل عقدة تحرير هذا الملف وإعادة تحميله أو إعادة تشغيل العقدة وتحديث القائمة. من الظاهر أن كل مُصادق يبدو أنه يعبر بحرية عن قيمه الخاصة.
في الواقع، من أجل التناسق والفعالية في سياسة الأمان، فإن تحديثات هذا التكوين الحساس عادة ما تكون منسقة. نظرًا لأنها "تحديثات طارئة مدفوعة من الفريق"، فإن الأساس هو الذي يقوم بشكل أساسي بإعداد وتحديث هذه القائمة المرفوضة (أو المطورين المعتمدين من قبله).
إصدار القائمة السوداء، من الناحية النظرية يمكن للمتحققين اختيار ما إذا كانوا سيستخدمونها ------ ولكن في الواقع، فإن معظم الناس سيقومون تلقائيًا بتبنيها. لذلك، على الرغم من أن هذه الميزة تحمي أموال المستخدمين، إلا أنها في جوهرها تحمل درجة معينة من المركزية.
3.2.3 جوهر وظيفة القائمة السوداء
ميزة القائمة السوداء ليست في الواقع منطقًا أساسيًا للبروتوكول، بل هي أشبه بطبقة أمان إضافية للتعامل مع الحالات الطارئة وضمان أمان أموال المستخدم.
تعتبر آلية ضمان الأمان في جوهرها. تشبه "سلسلة الأمان" المربوطة على الباب، حيث يتم تفعيلها فقط ضد الأشخاص الذين يرغبون في اقتحام المنزل، أي ضد الأشخاص الذين يتعمدون الإضرار بالاتفاقية. بالنسبة للمستخدمين:
بالنسبة للجهات الكبيرة، فإن مقدمي السيولة الرئيسيين، فإن البروتوكول هو الأكثر حرصًا على ضمان أمان الأموال، لأنه في الواقع، جميع بيانات السلسلة tvl تأتي من المساهمات الرئيسية للجهات الكبيرة. من أجل تطوير البروتوكول على المدى الطويل، يجب أن تكون الأولوية لضمان الأمان.
بالنسبة للمستثمرين الأفراد، فإنهم مساهمون نشطون في النظام البيئي، وداعمون قويون للتكنولوجيا وبناء المجتمع. كما يأمل المشروع أيضًا في جذب المستثمرين الأفراد للمشاركة في البناء، حتى يتمكنوا من تحسين النظام البيئي تدريجياً وزيادة معدل الاحتفاظ. أما بالنسبة لمجال التمويل اللامركزي، فإن الأولوية القصوى هي...
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مرونة نظام SUI البيئي: تحليل حادثة هجوم Cetus ومناقشة إمكانيات التطور المستقبلية
الإيمان الثابت بعد أزمة الأمان: لماذا لا يزال SUI يتمتع بإمكانية نمو طويلة الأجل؟
1. رد فعل متسلسل ناتج عن هجوم واحد
في 22 مايو 2025، تعرض بروتوكول AMM الرائد "Cetus" الموزع على شبكة SUI لهجوم قراصنة، حيث استغل المهاجم ثغرة منطقية تتعلق بمشكلة "overflow integers"، مما أدى إلى خسارة أصول تتجاوز 200 مليون دولار. لم تكن هذه الحادثة واحدة من أكبر حوادث الأمان في مجال DeFi حتى الآن هذا العام فحسب، بل أصبحت أيضًا أكثر الهجمات تدميرًا منذ إطلاق الشبكة الرئيسية لـ SUI.
وفقًا للبيانات، شهدت القيمة الإجمالية المقفلة (TVL) على سلسلة SUI انخفاضًا حادًا تجاوز 330 مليون دولار في يوم وقوع الهجوم، كما تبخر مبلغ الإغلاق الخاص ببروتوكول Cetus بشكل瞬ى بنسبة 84%، ليصل إلى 38 مليون دولار. نتيجة لذلك، تأثرت العديد من الرموز الشهيرة على SUI، حيث انخفضت بشكل كبير بنسبة 76% إلى 97% في غضون ساعة واحدة، مما أثار اهتمام السوق بسلامة SUI واستقرار النظام البيئي.
لكن بعد هذه الموجة من الصدمات، أظهر نظام SUI الإيكولوجي مرونة وقوة استعادة كبيرة. على الرغم من أن حدث Cetus أدى إلى تقلبات في الثقة على المدى القصير، إلا أن الأموال على السلسلة ونشاط المستخدمين لم تتعرض لتراجع مستمر، بل بالعكس، ساهمت في تعزيز الاهتمام في الأمان، وبناء البنية التحتية وجودة المشاريع بشكل ملحوظ.
ستتناول هذه المقالة أسباب حادثة الهجوم هذه، وآلية توافق العقد الخاصة بـ SUI، وأمان لغة MOVE، وتطور نظام SUI البيئي، وستستعرض الوضع البيئي الحالي لهذه السلسلة العامة التي لا تزال في مرحلة التطوير المبكر، وستناقش إمكانيات تطورها المستقبلية.
2. تحليل أسباب هجوم حدث Cetus
2.1 عملية تنفيذ الهجوم
وفقًا للتحليل الفني لفريق الأمان حول حادثة هجوم Cetus، تمكن القراصنة من استغلال ثغرة تجاوز عددي حاسمة في البروتوكول، من خلال استخدام القروض الفورية، وتلاعب دقيق في الأسعار، وعيوب في العقود، وسرقة أكثر من 200 مليون دولار من الأصول الرقمية في فترة زمنية قصيرة. يمكن تقسيم مسار الهجوم تقريبًا إلى المراحل الثلاث التالية:
①قم بإطلاق قرض فوري، وتلاعب بالسعر
استغل القراصنة أولاً أكبر انزلاق في تبادل 100 مليار haSUI من القروض الفورية، واستدانوا كميات كبيرة من الأموال، وقاموا بالتلاعب بالأسعار.
تسمح القروض الفورية للمستخدمين باقتراض وإرجاع الأموال في نفس المعاملة، مع دفع رسوم فقط، مما يوفر خصائص مثل الرفع العالي، المخاطر المنخفضة، والتكاليف المنخفضة. استخدم القراصنة هذه الآلية لتقليل الأسعار في السوق في فترة قصيرة، وتحكموا فيها بدقة ضمن نطاق ضيق جدًا.
بعد ذلك، كان المهاجمون يستعدون لإنشاء مركز سيولة ضيق للغاية، مع تحديد نطاق السعر بدقة بين أدنى عرض 300,000 وأعلى سعر 300,200، ليكون عرض السعر فقط 1.00496621%.
من خلال الطريقة المذكورة أعلاه، تمكن القراصنة من التحكم في سعر haSUI باستخدام كمية كافية من الرموز والسيولة الكبيرة. بعد ذلك، قاموا بالتحكم في عدة رموز بلا قيمة فعلية.
② إضافة السيولة
قام المهاجم بإنشاء مركز سيولة ضيق، مدعياً أنه أضاف سيولة، ولكن بسبب وجود ثغرة في دالة checked_shlw، حصل في النهاية على 1 توكن فقط.
في جوهرها، يعود ذلك إلى سببين:
إعداد القناع واسع جدًا: يعادل حدًا كبيرًا جدًا لإضافة السيولة، مما يؤدي إلى عدم وجود تحقق من إدخال المستخدم في العقد. استخدم المتسلل معلمات غير طبيعية، حيث قام ببناء مدخلات تكون دائمًا أقل من هذا الحد، متجاوزًا بذلك كشف الفائض.
تم قطع تجاوز البيانات: عند تنفيذ عملية الإزاحة 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 هذه بثلاث سمات:
تكلفة الإصلاح منخفضة جداً: من ناحية، السبب الجذري لحدث Cetus هو إغفال في مكتبة الرياضيات الخاصة بـ Cetus، وليس خطأ في آلية تسعير البروتوكول أو خطأ في البنية التحتية الأساسية. من ناحية أخرى، فإن الثغرة محصورة فقط في Cetus ولا تتعلق بشيفرة SUI. تكمن جذور الثغرة في شرط حدودي، ولا يتطلب الأمر سوى تعديل سطرين من الشيفرة للقضاء على المخاطر تماماً؛ بعد الانتهاء من الإصلاح، يمكن نشره على الشبكة الرئيسية على الفور، مما يضمن استكمال منطق العقد في المستقبل ويمنع هذه الثغرة.
ارتفاع الخصوصية: تم تشغيل العقد بشكل مستقر دون أي أعطال لمدة عامين، وتم إجراء العديد من التدقيقات، لكن لم يتم اكتشاف أي ثغرات، والسبب الرئيسي في ذلك هو أن مكتبة Integer_Mate المستخدمة في الحسابات الرياضية لم تكن مشمولة في نطاق التدقيق.
استغل القراصنة القيم القصوى لبناء نطاقات تداول بدقة، وخلق سيناريوهات نادرة للغاية تتطلب تقديم سيولة مرتفعة جداً، مما أدى إلى تفعيل منطق استثنائي، مما يدل على أن مثل هذه المشاكل يصعب اكتشافها من خلال الاختبارات العادية. غالباً ما تكون هذه المشاكل في منطقة عمياء في رؤية الناس، لذا تم اكتشافها بعد فترة طويلة.
تتفوق 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 مدققًا فقط، سيكون من الصعب تنسيق جميع المدققين للرد واحدًا تلو الآخر في فترة زمنية قصيرة.
3.2.2 من يملك الحق في تعديل القائمة السوداء؟
TransactionDenyConfig هو ملف إعداد YAML/TOML يتم تحميله محليًا بواسطة كل مُصادق. يمكن لأي شخص يقوم بتشغيل عقدة تحرير هذا الملف وإعادة تحميله أو إعادة تشغيل العقدة وتحديث القائمة. من الظاهر أن كل مُصادق يبدو أنه يعبر بحرية عن قيمه الخاصة.
في الواقع، من أجل التناسق والفعالية في سياسة الأمان، فإن تحديثات هذا التكوين الحساس عادة ما تكون منسقة. نظرًا لأنها "تحديثات طارئة مدفوعة من الفريق"، فإن الأساس هو الذي يقوم بشكل أساسي بإعداد وتحديث هذه القائمة المرفوضة (أو المطورين المعتمدين من قبله).
إصدار القائمة السوداء، من الناحية النظرية يمكن للمتحققين اختيار ما إذا كانوا سيستخدمونها ------ ولكن في الواقع، فإن معظم الناس سيقومون تلقائيًا بتبنيها. لذلك، على الرغم من أن هذه الميزة تحمي أموال المستخدمين، إلا أنها في جوهرها تحمل درجة معينة من المركزية.
3.2.3 جوهر وظيفة القائمة السوداء
ميزة القائمة السوداء ليست في الواقع منطقًا أساسيًا للبروتوكول، بل هي أشبه بطبقة أمان إضافية للتعامل مع الحالات الطارئة وضمان أمان أموال المستخدم.
تعتبر آلية ضمان الأمان في جوهرها. تشبه "سلسلة الأمان" المربوطة على الباب، حيث يتم تفعيلها فقط ضد الأشخاص الذين يرغبون في اقتحام المنزل، أي ضد الأشخاص الذين يتعمدون الإضرار بالاتفاقية. بالنسبة للمستخدمين:
بالنسبة للجهات الكبيرة، فإن مقدمي السيولة الرئيسيين، فإن البروتوكول هو الأكثر حرصًا على ضمان أمان الأموال، لأنه في الواقع، جميع بيانات السلسلة tvl تأتي من المساهمات الرئيسية للجهات الكبيرة. من أجل تطوير البروتوكول على المدى الطويل، يجب أن تكون الأولوية لضمان الأمان.
بالنسبة للمستثمرين الأفراد، فإنهم مساهمون نشطون في النظام البيئي، وداعمون قويون للتكنولوجيا وبناء المجتمع. كما يأمل المشروع أيضًا في جذب المستثمرين الأفراد للمشاركة في البناء، حتى يتمكنوا من تحسين النظام البيئي تدريجياً وزيادة معدل الاحتفاظ. أما بالنسبة لمجال التمويل اللامركزي، فإن الأولوية القصوى هي...