أنا الآن أتابع أوركلز الـDeFi، ولم أعد أهتم كثيرًا بما إذا كان “السعر دقيقًا”.
في السابق، عندما كنت أبحث في بروتوكولات الإقراض، كان لدي عادة.
عند رؤية الأوركل، كان يتبادر إلى ذهني تلقائيًا:
“هل مصدر هذا السعر موثوق؟”
ثم أتحقق هل استخدموا Chainlink أو RedStone أو غير ذلك من منصات التنبؤ.
وبعدها ينتهي الأمر.
لكن لاحقًا، بعد أن مررت أنا بنفسي بتقلبات حادة في السوق، اكتشفت أن المسبب الحقيقي للصداع لم يكن أصلًا هو أن السعر ليس دقيقًا عادةً.
بل هو:
ماذا يحدث للأوركل عندما يَختلّ السوق فجأة؟
في مرة هبط فيها السوق بسرعة، كنت أحدّق في تغيّر سعر الأونتشين على مدار السلسلة، وخلال دقائق فقط لم يعد الوضع كما هو في السابق.
عندها فقط أدركت:
أخطر لحظة في بروتوكول الإقراض هي تحديدًا عندما يكون تحديد السعر هو الأصعب.
تظهر المواد الرسمية أن TermMax يستخدم RedStone كمصدر رئيسي لبيانات الأسعار، مع إعداد Backup Oracle في الوقت نفسه؛ كما يذكر الورق الأبيض بوضوح أنه تم اعتماد نظام أوركل مزدوج، لكنه يعترف أيضًا بأن الاعتماد على الأوركل بحد ذاته يُعدّ مخاطرة.
لأن كثيرين يبحثون في الأوركل، وينظرون فقط إلى:
“هل السعر دقيق؟”
لكن ما ينبغي على النظام المالي أن يسأله حقًا هو:
“إذا حدث خلل في مصدر السعر، هل يمكن للنظام أن يعمل بشكل طبيعي أم لا؟”
هاتان المسألتان ليستا شيئًا واحدًا.
إذا كان فرق سعر BTC هو 0.1% فقط عادةً، فقد لا تهتم إطلاقًا.
لكن إذا انهار السوق فجأة، وتعطل مصدر سعر ما أو توقف أو حدث تأخير أو شذوذ، فقد تكون مشكلة بروتوكول الإقراض أمام واقع هو أن سعر التصفية سيكون مختلفًا تمامًا.
الأوركل ليس مجرد واجهة بيانات بسيطة، بل هو في الواقع “عين” الـDeFi.
كون العين ترى بدقة من عدمه أمر.
لكن الخطر الحقيقي هو:
ماذا لو توقفت فجأة عن الرؤية؟
تقوم TermMax بإدخال Backup Oracle في البنية، وبجوهريتها فهي تعترف بمشكلة واقعية للغاية:
مصادر البيانات أيضًا قد تتعطل.
بالطبع، الأوركل المزدوج ليس آمنًا بشكل مطلق أيضًا؛ فالتنسيق بين مصادر البيانات، وكيف يتم التعامل مع الاستثناءات في الحالات غير الطبيعية، ما زال يستحق المتابعة.
لكنني بالمقابل أحب منطق هذا التصميم.
لأن البنية التحتية المالية الناضجة لا تفترض أبدًا:
“لن يخطئ النظام أبدًا.”
بل تفكر مسبقًا في:
“إذا أخطأ، ماذا نفعل في الطبقة التالية؟”
انظر إن كانوا قد صمموا بجد:
ماذا يحدث بعد حدوث المشكلة.
@TermMax #TermMax
في السابق، عندما كنت أبحث في بروتوكولات الإقراض، كان لدي عادة.
عند رؤية الأوركل، كان يتبادر إلى ذهني تلقائيًا:
“هل مصدر هذا السعر موثوق؟”
ثم أتحقق هل استخدموا Chainlink أو RedStone أو غير ذلك من منصات التنبؤ.
وبعدها ينتهي الأمر.
لكن لاحقًا، بعد أن مررت أنا بنفسي بتقلبات حادة في السوق، اكتشفت أن المسبب الحقيقي للصداع لم يكن أصلًا هو أن السعر ليس دقيقًا عادةً.
بل هو:
ماذا يحدث للأوركل عندما يَختلّ السوق فجأة؟
في مرة هبط فيها السوق بسرعة، كنت أحدّق في تغيّر سعر الأونتشين على مدار السلسلة، وخلال دقائق فقط لم يعد الوضع كما هو في السابق.
عندها فقط أدركت:
أخطر لحظة في بروتوكول الإقراض هي تحديدًا عندما يكون تحديد السعر هو الأصعب.
تظهر المواد الرسمية أن TermMax يستخدم RedStone كمصدر رئيسي لبيانات الأسعار، مع إعداد Backup Oracle في الوقت نفسه؛ كما يذكر الورق الأبيض بوضوح أنه تم اعتماد نظام أوركل مزدوج، لكنه يعترف أيضًا بأن الاعتماد على الأوركل بحد ذاته يُعدّ مخاطرة.
لأن كثيرين يبحثون في الأوركل، وينظرون فقط إلى:
“هل السعر دقيق؟”
لكن ما ينبغي على النظام المالي أن يسأله حقًا هو:
“إذا حدث خلل في مصدر السعر، هل يمكن للنظام أن يعمل بشكل طبيعي أم لا؟”
هاتان المسألتان ليستا شيئًا واحدًا.
إذا كان فرق سعر BTC هو 0.1% فقط عادةً، فقد لا تهتم إطلاقًا.
لكن إذا انهار السوق فجأة، وتعطل مصدر سعر ما أو توقف أو حدث تأخير أو شذوذ، فقد تكون مشكلة بروتوكول الإقراض أمام واقع هو أن سعر التصفية سيكون مختلفًا تمامًا.
الأوركل ليس مجرد واجهة بيانات بسيطة، بل هو في الواقع “عين” الـDeFi.
كون العين ترى بدقة من عدمه أمر.
لكن الخطر الحقيقي هو:
ماذا لو توقفت فجأة عن الرؤية؟
تقوم TermMax بإدخال Backup Oracle في البنية، وبجوهريتها فهي تعترف بمشكلة واقعية للغاية:
مصادر البيانات أيضًا قد تتعطل.
بالطبع، الأوركل المزدوج ليس آمنًا بشكل مطلق أيضًا؛ فالتنسيق بين مصادر البيانات، وكيف يتم التعامل مع الاستثناءات في الحالات غير الطبيعية، ما زال يستحق المتابعة.
لكنني بالمقابل أحب منطق هذا التصميم.
لأن البنية التحتية المالية الناضجة لا تفترض أبدًا:
“لن يخطئ النظام أبدًا.”
بل تفكر مسبقًا في:
“إذا أخطأ، ماذا نفعل في الطبقة التالية؟”
انظر إن كانوا قد صمموا بجد:
ماذا يحدث بعد حدوث المشكلة.
@TermMax #TermMax
