这次攻击暴露是一个经典的整数溢出问题,具体表现为类型转换过程中的数据截断。

تفصيل التفاصيل الفنية:

1) تحديد الثغرات: تظهر المشكلة في آلية تحويل النوع في دالة get_amount_by_liquidity، حيث يؤدي التحويل الإجباري من u256 إلى u64 إلى فقدان البيانات العليا.

2) عملية الهجوم:

1، يقوم المهاجم بتمرير قيمة كبيرة من معامل حجم السيولة من خلال دالة add_liquidity؛
2. يستدعي النظام دالة get_delta_b لحساب كمية رموز B المطلوبة؛
3، في عملية الحساب، يجب أن يكون ناتج ضرب بيانات من نوع u128 نظريًا من نوع u256؛

العيب الرئيسي: تحويل نتيجة u256 إلى u64 عند إرجاع الدالة، مما يؤدي إلى قطع البيانات الأعلى 128 بت.

3)利用效果:原需要大量代币才能铸造的流动性额度,现在仅需极少量代币即可完成。 攻击者以极 السعر المنخفض 获得العملاق 额流动性份额,随后通过销毁部分流动性实现资金池套利。

تشبيه بسيط: مثل استخدام آلة حاسبة يمكنها عرض 8 أرقام فقط لحساب 1 مليار × 1 مليار، فإن النتيجة المكونة من 20 رقمًا يمكن أن تعرض فقط 8 أرقام الأخيرة، بينما تختفي الـ 12 رقمًا الأولى مباشرة. استغل المهاجمون هذه الثغرة "فقدان دقة الحساب".

Move语言在资源管理和类型安全方面确实具备显有优势,能够有效防范双重支付、资源泄露等底层安全问题。 但此次Cetus协议出现的是应用逻辑层面的数学计算错误,并非Move语言本身的设计缺陷。

بشكل أكثر تحديدًا، على الرغم من أن نظام أنواع Move صارم، إلا أنه لا يزال يعتمد على حكم المطورين الصحيح لعمليات التحويل الصريح (explicit casting). عندما يقوم البرنامج بتنفيذ تحويل نوع u256 إلى u64، لا يستطيع المترجم تحديد ما إذا كان هذا تصميمًا مقصودًا أو خطأً منطقيًا.

此外,这次安全事件与Sui的共识机制、交易处理、状态管理等核心底层功能完全无关。 Sui Network只是忠实执行了Cetus协议提交的交易指令,漏洞源于应用层协议本身的逻辑缺陷。

说白了,再先进的编程语言也无法完全杜绝应用层的逻辑错误。 Move能够防范大部分底层安全风险,但无法代替开发者进行业务逻辑的边界检查和数学运算的溢出保护。