@APRO Oracle عندما يصبح السوق سيّئًا، يجد الجميع فجأة سببًا يبرر ذلك.

البروتوكول يحمّل المسؤولية للـ Oracle.

الـ Oracle يحمّل المسؤولية لمصدر البيانات.

مصدر البيانات يشير إلى تقلبات السوق.

يُترك المستخدمون يحاولون فهم ما الذي حدث بالفعل.

هذه هي سلسلة تحميل المسؤولية.

بالنسبة لي، الجزء المثير للاهتمام في APRO ليس فكرة أن الـ Oracle يمكنه بطريقة ما منع كل الأعطال. لا يعمل شيء في مجال العملات المشفّرة بهذه الطريقة. السؤال الأكبر هو ما إذا كانت البنية التحتية يمكنها جعل البيانات أكثر شفافية وقابلة للتحقق والمساءلة عندما تصبح الظروف صعبة.

تبدو موجزات الأسعار بسيطة عندما يكون السوق هادئًا. أثناء التقلبات الشديدة، تصبح جزءًا حاسمًا من البنية التحتية. قد يؤدي تحديث متأخر أو نقطة بيانات غير موثوقة إلى إحداث عمليات تصفية (Liquidations) وتوليد عواقب تتجاوز الخطأ الأصلي بكثير.

وهنا تبرز أهمية تصميم الـ Oracle.

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

نهج APRO يجعل هذه المساءلة جزءًا مهمًا من النقاش.

سيختبر الحدث الضاغط الرئيسي التالي كل طبقة من طبقات البنية التحتية. السؤال المثير للاهتمام هو ما إذا كان بإمكان APRO المساعدة في تحويل تلك اللحظة من لعبة لوم إلى شيء يمكن للمطورين بالفعل التحقيق فيه وفهمه والتعلم منه.

$AT