في 10 مارس 2026، تلقى قطاع التمويل اللامركزي (DeFi) تنبيهاً جديداً. فقد أدى خطأ في إعداد أوراكل المخاطر CAPO على بروتوكول Aave إلى تصفية خاطئة لما يقارب 27 مليون $ من مراكز wstETH. ورغم أن البروتوكول لم يتكبد ديوناً معدومة وسيحصل المستخدمون المتضررون على تعويض كامل، إلا أن هذا الحادث أثار سؤالاً أوسع: عندما تتعطل البنية التحتية الأساسية، كيف يمكن للمستخدمين العاديين حماية أصولهم بشكل استباقي دون الاعتماد على فرق المشاريع في التعويض؟
تُعد الأوراكل الرابط الحاسم بين بيانات العالم الحقيقي خارج السلسلة والعقود الذكية على السلسلة، ما يجعلها العمود الفقري لأسواق الإقراض في التمويل اللامركزي. وإذا تعطل هذا المكون، يمكن حتى لأقوى البروتوكولات أن تدخل في حالة من الفوضى بسرعة. وباستخدام حادثة التصفية الأخيرة على Aave كدراسة حالة، يستعرض هذا المقال بشكل منهجي كيفية انتشار مخاطر الأوراكل ويقدم استراتيجيات دفاع عملية من منظور المستخدم.
تصفية بقيمة 27 مليون $: القصة وراء خطأ إعداد أوراكل Aave
في 10 مارس، تعرض بروتوكول Aave لعطل في نظام الأوراكل الخاص به على highlight كل من شبكة Ethereum الرئيسية ونسخ Prime، ما أدى إلى تصفية خاطئة لحوالي 10,938 مركز wstETH عبر نحو 34 حساباً، بإجمالي يقارب 27 مليون $. وقد حققت روبوتات التصفية التابعة لأطراف ثالثة أرباحاً بحوالي 499 ETH خلال الحادثة.
وأكد مؤسس Aave، ستاني كوليشوف، لاحقاً أن الحادثة نتجت عن خطأ في إعداد نظام CAPO (أوراكل تسعير أصول الضمانات)، وليس عن ثغرة في البروتوكول. لم يتم تسجيل أي ديون معدومة، وسيتم تعويض جميع المستخدمين المتضررين بالكامل من خلال الأموال المستردة عبر BuilderNet وخزينة DAO، مع توقع أن لا يتجاوز إجمالي التعويض 345 ETH.
مراجعة التسلسل الزمني: كيف تسبب متغير واحد في سلسلة من الأحداث
تم إطلاق نظام CAPO من قبل Aave في نهاية عام 2024، وهو آلية أوراكل للمخاطر صُممت لمنع هجمات التلاعب بالأوراكل. يقوم بحساب وتقديم معدلات الصرف القصوى وتحديثات معدل النمو عبر أوراكل فوضوية خارج السلسلة، ثم يفرض منطق التحقق من خلال العقود الذكية على السلسلة. وخلال أكثر من عام من التشغيل، عالج CAPO أكثر من 1,200 حمولة و3,000+ متغير دون حوادث كبيرة.
في 10 مارس، واجه مدير المخاطر في Aave، شركة Chaos Labs، عدم توافق بين القيود على السلسلة ونوايا التحديث أثناء تحديث روتيني للمتغيرات. تضمنت الأحداث الرئيسية في التسلسل الزمني ما يلي:
- نية التحديث: حددت عملية Chaos Labs خارج السلسلة أن متغير
snapshotRatioالخاص بـ wstETH يحتاج إلى تحديث ليصبح حوالي 1.2282، ليعكس معدل الصرف المنطقي قبل سبعة أيام. - قيد على السلسلة: هذا المتغير مقيد بآلية أمان في العقد الذكي—حيث يمكن أن ترتفع المعدلات بنسبة لا تزيد عن %3 كل ثلاثة أيام. ونتيجة لذلك، يمكن أن يتحرك من حوالي 1.1572 إلى 1.1919 فقط، whisk لا يمكن الوصول مباشرة إلى الهدف 1.2282.
- عدم توافق التحديث: في المقابل، تم تحديث متغير
snapshotTimestampبنجاح إلى الطابع الزمني قبل سبعة أيام. - النتائج: أدى عدم التوافق بين النسبة والطابع الزمني إلى قيام نظام CAPO بتحديد سقف معدل صرف wstETH عند حوالي 1.1939 فقط، بينما كان المعدل السوقي الفعلي حوالي 1.2282—أي بفارق يقارب %2.85. وقد أدى pipeline هذا التقدير المنخفض إلى تصفيات جماعية.
تحليل البيانات: الخلل البنيوي وراء انحراف %2.85
| المؤشر | القيمة | المصدر/الشرح |
|---|---|---|
| إجمالي التصفيات | ~27 مليون $ | إجمالي قيمة المراكز المتأثرة بالحادث |
| الكمية المصفاة | ~10,938 wstETH | إجمالي wstETH التي تم تصفيتها قسرياً |
| الحسابات المتضررة | ~34 | عدد المستخدمين المتأثرين مباشرة |
| انحراف معدل الصرف | ~%2.85 | سقف معدل CAPO كان أقل من المعدل السوقي الفعلي |
| أرباح المصفيين | ~499 ETH | أرباح روبوتات التصفية التابعة لأطراف ثالثة |
| تعويض المستخدمين | ≤ 345 ETH | الأموال المخصصة منعب خزينة Aave DAO لتعويض المستخدمين، بما في ذلك 141.5 ETH تم استردادها بالفعل عبر BuilderNet |
في جوهره، كان السبب الفني الأساسي لهذا الحادث هو فشل تحديث المتغيرات بشكل ذري. يعتمد نموذج أمان CAPO على تزامن تحديث المتغيرات، لكن العملية خارج السلسلة لم تدرك القيود على السلسلة، مما أدى إلى عدم توافق بين snapshotRatio وsnapshotTimestamp—وهما متغيران يجب أن يتحركا معاً. يكشف هذا التفصيل التقني عن مشكلة أعمق: حتى بعد أكثر من عام من التشغيل المستقر، لا تزال نقاط الاحتكاك قائمة بين حوكمة المتغيرات والتنفيذ على السلسلة في الأنظمة المعقدة.
وجهات النظر المتباينة: مرونة البروتوكول أم هشاشة النظام؟
أثار الحادث نقاشاً على عدة أصعدة:
وجهات نظر داعمة:
- الاعتراف بمرونة البروتوكول: يرى كثيرون أن Aave أظهر إدارة ناضجة للأزمات. فقد قامت Chaos Labs وBGD Labs بسرعة بخفض سقف اقتراض wstETH إلى 1 في النسخ المتأثرة وأعادوا ضبط المتغيرات عبر Risk Steward لاستعادة معدلات الصرف. ويُعتبر غياب الديون المعدومة دليلاً على فعالية ضوابط المخاطر.
- الإشادة بآلية التعويض: تعهد مؤسس Aave بسرعة بتعويض كامل، مع استرداد جزء من الأموال عبر BuilderNet وتغطية الباقي من خزينة DAO. وقد لقي هذا النهج الذي يضع المستخدم أولاً تقديراً واسعاً من المجتمع.
وجهات نظر ناقدة وتأملية:
- القلق من تعقيد الأوراكل: يرى البعض أنه رغم أن CAPO صُمم لتعزيز الأمان، إلا أن تعقيد المتغيرات فيه أدخل مخاطر جديدة. فقد أدى خطأ بسيط في تحديث المتغيرات إلى سلسلة تصفيات بقيمة 27 مليون $، ما يبرز هشاشة البنية التحتية للتمويل اللامركزي.
- التساؤل حول عدالة آليات التصفية: رغم أن الحادثة نتجت عن خلل تقني، إلا أن التصفيات تمت وفقاً لقواعد البروتوكول. ويعتبر البعض أن مثل هذه التصفيات "العادلة شكلياً ولكنها غير منصفة فعلياً" تكشف عن معضلة أخلاقية في الأنظمة المؤتمتة—فعندما تكون بيانات الإدخال خاطئة، هل يظل "التنفيذ الصحيح" مبرراً؟
تمحيص السردية
من الناحية الواقعية:
- بالفعل، تسبب خطأ إعداد CAPO في تقليل قيمة wstETH بن sop حوالي %2.85، مما أدى إلى تصفيات بقيمة تقارب 27 مليون $.
- لم يتكبد البروتوكول ديوناً معدومة وسيتم تعويض المستخدمين المتضررين بالكامل.
- السبب الجذري هو فشل العملية خارج السلسلة في مراعاة القيود على السلسلة عند تحديث المتغيرات، وليس خللاً في تصميم CAPO أو الأوراكل نفسه.
من منظور وجهات النظر:
- "مخاطر الأوراكل يمكن التحكم بها" مقابل "التعقيد يزيد المخاطر"—الأولى تستند إلى عدم وجود ديون معدومة وردة الفعل السريعة من Aave، والثانية على فرضية أنه لولا التدخل السريع لكانت العواقب أسوأ بكثير.
- نقاش "عدالة التصفية"—المؤيدون يرون أن تطبيق القواعد بشفافية مبرر، بينما يرى المنتقدون أنه عندما يكون مصدر البيانات معيباً، تفقد النتيجة أساس العدالة.
من الناحية الافتراضية:
- تشير بعض التحليلات إلى احتمال وجود أخطاء إعداد مماثلة في بروتوكولات أخرى تستخدم آليات أوراكل معقدة، لكن لا يوجد دليل مباشر حتى الآن.
- النقاش حول ما إذا كانت "مخاطر الأوراكل مسعرة بالكامل" هو في الغالب استنتاجات مستمدة من هذا الحدث، دون دعم كمي واضح.
التأثير على الصناعة: حوكمة الأوراكل على أعتاب إعادة هيكلة
يمكن النظر إلى تأثير هذا الحادث على صناعة التمويل اللامركزي من منظورين: قصير وطويل الأمد:
التأثير قصير الأمد:
- تأثير محدود على ثقة Aave: بفضل الاستجابة السريعة والالتزام بالتعويض الكامل، بقيت مكانة Aave السوقية مستقرة إلى حد كبير. بل إن البعض يرى أن إدارة الأزمة دليل على النضج.
- اختبار الثقة في wstETH: رغم تأكيد مساهمي Lido أن الحادثة لا تتعلق بـ wstETH أو بروتوكول Lido نفسه، إلا أن wstETH، كأصل تمت تصفيته، تعرض لضغوط بيع إضافية أثناء الحادثة، مما قد يؤثر على تقييم بعض الحائزين للمخاطر.
- أرباح روبوتات التصفية: حقق المصفيون حوالي 499 ETH، مما يبرز الحوافز لمراقبة واستغلال الشذوذات في منظومة التمويل اللامركزي.
التأثير طويل الأمد:
- إعادة هيكلة عمليات حوكمة الأوراكل: سيدفع هذا الحادث البروتوكولات إلى مراجعة وتشديد عمليات تحديث متغيرات الأوراكل. وقد حدد تقرير Chaos Labs بوضوح أن "العملية خارج السلسلة لم تراعِ القيود على السلسلة" كسبب جذري. وستكون هناك حاجة لآليات محاكاة واختبار أكثر صرامة قبل التحديث.
- إعادة تقييم مخاطر E-Mode: تركزت التصفيات في مراكز Efficient Mode (E-Mode)، المصممة لتحسين كفاءة رأس المال للأصول شديدة الترابط، لكنها قد تضخم أثر أعطال الأوراكل المحددة. قد تحتاج البروتوكولات إلى إعادة النظر في افتراضات المخاطر الخاصة بـ E-Mode.
- تزايد الحاجة لتثقيف المستخدمين: مع فائق تعقيد آليات الأوراكل، تزداد عتبة المعرفة اللازمة للمستخدمين لفهم مخاطر البروتوكول. ويثبت هذا الحدث مجدداً أن "الأنظمة التي تعمل بأمان لعام كامل" قد تتعرض لأعطال غير متوقعة. هناك حاجة لإرشادات أوضح لمساعدة المستخدمين على تحديد هذه المخاطر والتعامل معها.
نظرة مستقبلية: ثلاثة مسارات محتملة لتطور مخاطر الأوراكل
بالنظر إلى بنية منظومة التمويل اللامركزي الحالية، يمكننا توقع عدة مسارات تطور محتملة لمخاطر الأوراكل:
السيناريو الأول: التحسين التدريجي
ستعزز البروتوكولات حوكمة متغيرات الأوراكل، مع إدخال عمليات محاكاة خارج السلسلة ومراجعة متعددة التوقيع أكثر صرامة. ستستمر أنظمة شبيهة بـ CAPO، لكن تحديث المتغيرات سيتبع نهج "بطيء، تدريجي، متعدد التوقيع". سيقل أثر ذلك على المستخدمين تدريجياً، رغم احتمال حدوث أخطاء صغيرة بين الحين والآخر.
السيناريو الثاني: التحسين الجذري
يدفع هذا الحدث الصناعة إلى وضع معايير لإعداد الأوراكل، مع دور أكبر لمزودي خدمات المخاطر المتخصصين مثل BGD Labs وChaos Labs. قد تقدم البروتوكولات "لوحات مراقبة صحة الأوراكل" لعرض حالات المتغيرات الرئيسية في الوقت الفعلي. ويمكن للمستخدمين مراقبة المخاطر بشكل استباقي عبر أدوات خارجية.
السيناريو الثالث: المخاطر القصوى
في سيناريو أكثر تشاؤماً، إذا تم إعداد عدة أوراكل بشكل خاطئ في الوقت ذاته أو تمكن المهاجمون من التلاعب بتحديثات المتغيرات، فقد تحدث تصفيات واسعة النطاق. وإذا تزامنت هذه الأحداث مع فترات تقلبات سوقية عالية، فقد تؤدي إلى من أزمات سيولة وتراكم ديون معدومة. وقد تجنبت Aave الديون المعدومة هذه المرة بفضل التدخل السريع، لكن ليس كل البروتوكولات تمتلك قدرات طوارئ مماثلة.
الحماية الذاتية للمستخدم: أربع خطوات للدفاع الاستباقي ضد مخاطر الأوراكل
بالنسبة لمستخدمي التمويل اللامركزي، يشكل الدفاع الاستباقي—not الاعتماد على تعويضات المشاريع—أساس أمان الأصول. فيما يلي استراتيجيات عملية مستخلصة من هذا الحادث:
افهم أصول الضمانات الخاصة بك
تعد wstETH، كأصل تخزين سائل، ذات علاقة سعرية معقدة مع sop ETH. يجب على الحائزين فهم كيفية تسعيرها من قبل الأوراكل. عموماً، تتحقق البروتوكولات من الأسعار عبر مصادر متعددة، لكن آليات شبيهة بـ CAPO قد تضيف طبقات حسابية إضافية. ينبغي للمستخدمين مراجعة وثائق البروتوكول لمعرفة تفاصيل إعداد الأوراكل للأصول المحددة.
راقب متغيرات مخاطر البروتوكول
- تابع مزودي خدمات المخاطر: غالباً ما تشير تقارير منظمات مثل Chaos Labs إلى مشكلات محتملة مبكراً. يمكن للمستخدمين متابعة هؤلاء المزودين على X (تويتر سابقاً) أو ديسكورد للحصول على التحديثات.
- افهم قيود تحديث المتغيرات: كما في قاعدة "نمو %3 كل ثلاثة أيام" في هذا الحادث، لكل أصل قواعد تحديث خاصة بمتغيرات الأوراكل. ورغم صعوبة متابعة جميع التفاصيل التقنية في الوقت الفعلي، غالباً ما تناقش منتديات الحوكمة المجتمعية تعديلات المتغيرات.
نوّع المخاطر وحدد هوامش أمان
- تجنب التركيز الزائد في أصل واحد: حتى في E-Mode، لا تضع كل equal مراكزك في أصل واحد شديد الترابط. يساعد تنويع الضمانات على تقليل التعرض الكلي للمخاطر إذا تعطل أوراكل أصل معين.
- حافظ على هامش أمان صحي: أثناء تقلبات السوق أو انحرافات الأوراكل الطفيفة، يوفر عامل الصحة الأعلى هامشاً وقائياً. تجنب دفع نسبة الاقتراض إلى الحد الأقصى؛ واترك هامش أمان لا يقل عن %20.
- تتبع حدود التصفية مقابل الأسعار الحالية: تحقق بانتظام من مدى قرب مراكزك من التصفية. إذا كان الفارق صغيراً جداً، قد يؤدي حتى انحراف أوراكل بنسبة %2-%3 إلى التصفية—كما حدث في هذا الحادث.
استخدم أدوات المراقبة والتنبيهات
- قم بإعداد مراقبة على السلسلة: تتيح لك منصات مثل Forta إعداد تنبيهات مخاطر للبروتوكولات التي تستخدمها. ستحصل على إشعارات فورية إذا حدثت تغييرات كبيرة في المتغيرات أو شذوذات في الأوراكل.
- استفد من لوحات مخاطر التمويل اللامركزي: تعرض أدوات مثل DeBank وZapper لمحات عامة عن الأصول وتدمج مؤشرات المخاطر. يمكن للمستخدمين الاطلاع على الوضع العام للإقراض في البروتوكول ومخاطر التصفية.
افهم حدود "التعويض"
يعكس وعد Aave بالتعويض الكامل إدارة مشروع مسؤولة، لكن لا ينبغي أن يدفع ذلك المستخدمين إلى التراخي. على المدى الطويل، ليس كل البروتوكولات لديها القدرة أو الرغبة في تعويض الخسائر الناتجة عن الأعطال التقنية. ينبغي للمستخدمين إدارة المخاطر بعقلية "عدم توقع تعويض".
الخلاصة
كان خطأ إعداد أوراكل Aave بمثابة اختبار ضغط لإدارة المخاطر في التمويل اللامركزي وتنبيه لوعي المستخدم بالمخاطر. وراء تصفيات بقيمة 27 مليون $ كان هناك فشل تقني نتج عن عدم توافق المتغيرات، ما يثير سؤالاً أوسع حول كيفية التعايش مع الأنظمة المعقدة.
بالنسبة للمستخدمين، لا يمكن القضاء على مخاطر الأوراكل بالكامل، لكنها قابلة للإدارة من خلال فهم الآليات، ومتابعة المستجدات، وتحديد هوامش أمان حكيمة. في التمويل اللامركزي، تظل الحماية الأكثر موثوقية نابعة من وعي المستخدم بالمخاطر ودفاعه الاستباقي. فعندما تتصدع أحياناً حدود "القانون هو الكود"، لا ينجو إلا من استعد جيداً للعاصفة.
