إعادة التفكير في حادثة هاكر Cetus: يجب أن يتجاوز أمان التمويل اللامركزي التفكير التقني البحت

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

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

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

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

لذلك ، تشمل الأسئلة التي يجب على Cetus أن تفكر فيها حقًا:

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

2. لماذا يُسمح بإدخال أرقام فلكية دون تحديد حدود؟ على الرغم من أن بروتوكولات DeFi تسعى إلى اللامركزية، فإن الأنظمة المالية الناضجة تحتاج إلى حدود واضحة في الوقت الذي تفتح فيه أبوابها. السماح بإدخال أرقام مبالغ فيها يدل على أن الفريق قد يفتقر إلى مواهب إدارة المخاطر التي تتمتع بالحدس المالي.

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

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

كشفت هذه الحادثة عن ضعف الأمان النظامي في صناعة DeFi: الفرق ذات الخلفيات التقنية البحتة غالباً ما تفتقر إلى "الحس المالي" الأساسي. من خلال تقرير Cetus، يبدو أن الفريق لم يدرك هذه النقطة بشكل كاف.

بالنسبة لـ Cetus وصناعة DeFi بأكملها، من المهم الخروج من قيود التفكير الفني البحت وتطوير الوعي بمخاطر الأمان لدى "مهندسي المالية" الحقيقيين. يمكن التفكير في إدخال خبراء إدارة المخاطر المالية لسد الفجوات المعرفية في الفريق الفني؛ إنشاء آلية مراجعة تدقيق متعددة الأطراف، لا تركز فقط على تدقيق الشفرات، بل تعطي أهمية أيضًا لتدقيق النماذج الاقتصادية؛ تنمية "حاسة المال"، محاكاة سيناريوهات هجوم مختلفة ووضع تدابير استجابة مناسبة، والحفاظ على يقظة عالية تجاه العمليات الشاذة.

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

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