لقد كادت مراكز الرافعة الخاصة بك أن تتعرض لخسارة فادحة الليلة الماضية، والقاتل الحقيقي ليس تقلبات السوق بل هو القاتل الخفي وراء أنظمة DeFi.

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

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

فما هو السبب؟ بشكل أساسي، لا يمكن للبلوكشين الاتصال مباشرة بالبيانات الواقعية. أنت بحاجة إلى "جسر" — وهو الـ oracle — لنقل أسعار خارج السلسلة، والطقس، وأسعار الصرف وغيرها من المعلومات إلى السلسلة. المشكلة أن هذا الجسر هش جدًا:

- البيانات قد تتأخر أو تتعرض للتلاعب
- سعر متطرف واحد يمكن أن يثير عاصفة تصفية فورية
- العقد المركزية قد تتعرض للشر، أو فشل نقطة واحدة قد يتسبب في تعطل النظام بأكمله

هناك من فكر في مسار آخر. بدلاً من أن تتم جميع العمليات الحسابية على السلسلة (وهو بطيء ومكلف)، يمكن جمع البيانات وإجراء العمليات المعقدة خارج السلسلة، ثم فقط نضع النتائج على السلسلة للتحقق والتأكيد. يبدو الأمر وكأنه "حكم قضائي" — جمع الأدلة وتحليلها يتم خارج المحكمة، والقاضي يضرب على الطاولة فقط بعد توفر الأدلة الكافية.

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

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