ثغرة Resolv USR ليست خطأ - بل هي ميزة

استغلال USR من Resolv ليس خطأ برمجي — بل هو نظام يعمل بشكل صحيح وفقًا لتصميمه. وهذا هو المشكلة الأكبر.

عندما يصبح “التصميم” ثغرة طريقة إصدار USR بسيطة جدًا: المستخدم يرسل USDC إلى العقد خدمة خارج السلسلة (تملك مفتاح خاص مميز) تقرر كم USR ستصدر العقد الذكي يتحقق فقط من الحد الأدنى، بدون حد أقصى لا يوجد حد لنسبة الضمانات لا يوجد سقف بمعنى آخر: من يملك المفتاح يقول كم يصدر، والنظام يصدر بقدر ذلك يمكنك إرسال 1 دولار… ومن الناحية النظرية يمكن إصدار مليارات USR. هذا التصميم موجود منذ البداية. ليس خطأ برمجيًا. ليس خطأ في الكود. بل هو فرضية: 👉 “المفتاح لن يُكشف أبدًا.” ثم حدث ما لا مفر منه تم اختراق المفتاح. سيناريو الهجوم حدث بشكل “نظيف” جدًا: المهاجم يودع حوالي 200 ألف USDC عبر معاملتين يستخدم المفتاح لإصدار 80 مليون USR بدون ضمانات يبيع على الفور على البورصات اللامركزية ويحصل على حوالي 23 مليون دولار قيمة ETH لا حاجة لاستغلال منطق العقد. لا حاجة لتجاوز العقد. فقط… استخدم الصلاحيات الصحيحة. نقطة فشل واحدة — الكابوس المألوف يعتمد النظام بأكمله على مفتاح خاص واحد: لا Multisig لا Timelock لا حد للإصدار لا يتحقق من نسبة الضمان على السلسلة => بمجرد كشف المفتاح = يتم تفعيل آلة طباعة النقود غير المحدودة هذه ليست مشكلة تقنية بعد الآن. إنها مشكلة هندسة النظام. “الكود هو القانون” — لكن هذا القانون خطير جدًا أسوأ ما في الأمر ليس الخسارة التي تبلغ 23 مليون دولار. بل هو: 👉 العقد عمل بشكل مثالي 👉 لا يوجد سطر كود “خاطئ” 👉 لا يوجد خطأ يمكن تصحيحه لكن النظام لا زال ينهار. هذا يوضح حقيقة غالبًا ما تتجاهله DeFi: نظام لا يحتاج إلى خطأ برمجي للفشل. فقط تصميم خاطئ لنموذج التهديد كافٍ. درس كبير: لا تثق في الأشياء غير الموجودة على السلسلة ما حدث مع USR هو تذكير قوي: السلطة خارج السلسلة = مخاطر لا يمكن التحقق منها المفتاح الخاص ≠ بدون ثقة “سنحافظ على المفتاح بأمان” ليس نموذج أمان نظام DeFi حقيقي يحتاج إلى: حدود واضحة على السلسلة (سقف الإصدار، نسبة الضمان) Multisig أو تحكم موزع Timelock للأفعال المهمة آلية فشل آمنة عند وجود حالات غير طبيعية الخلاصة لم يتم اختراق USR بالمعنى التقليدي. إنه فقط يُستخدم بالطريقة التي يسمح بها. وهذا هو الأمر المقلق: عندما يسمح نظام ما بطباعة النقود غير المحدودة بمفتاح واحد — فإن استغلاله ليس “إذا”، بل “متى”. في عالم الكريبتو، أحيانًا أخطر شيء ليس الخطأ البرمجي. بل هو الثقة الخاطئة.