يوجد تصميم لدى TermMax يبدو غير ملفت للنظر، لكن عندما كنت أتصفح المستندات ووجدته، توقفت ونظرت إليه لوقت طويل.
عندما كنت أراجع أمان DeFi من قبل، كانت أول ردة فعلي دائمًا تتعلق بالتدقيق (audit) والـmulti-sign وهل سبق أن حدثت حوادث. لكن في TermMax هناك شيء أكثر دقة: بعض المعلمات الأساسية لا يمكن لمدير النظام تغييرها كما يشاء، بل يمكن أن تصبح نافذة فورًا في اللحظة التالية.
لدى Vault الخاص بها Timelock.
تقريبًا تكون العملية كالتالي: يقوم Curator أولًا بتقديم التعديل، ثم يدخل في فترة انتظار، وعند انتهاء الوقت فقط يتم قبول التعديل رسميًا. مدة الانتظار الافتراضية هي يوم واحد، وليست قابلة للتعيين عشوائيًا؛ فالمدى الذي تذكره الجهة الرسمية هو الأدنى يوم واحد والأقصى 30 يومًا. وخلال فترة الانتظار يوجد دور اسمه Guardian يمكنه فحص التعديلات التي لم تصبح نافذة بعد، وإذا وجد شيئًا غير صحيح يمكنه إلغاء التعديل. (TS Finance Docs)
برأيي، ليس الأكثر فائدة هنا هو رقم “24 ساعة”، بل حقيقة أنه يترك عمدًا نافذة فارغة.
إذا تم تعديل معلمة الرسوم عن طريق الخطأ، أو حدثت مشكلة في الصلاحيات، ففي حال تنفيذ التعديل فورًا، كلما كانت سرعة التنفيذ على السلسلة أعلى، قلّ الوقت المتاح للآخرين لاكتشاف المشكلة. إن Timelock يفصل عمليًا بين “تقديم التعديل” و“نفاذه الحقيقي” إلى حالتين منفصلتين.
كما يضيف TermMax Timelock أيضًا بشكل منفصل إلى أماكن مثل Oracle التي تؤثر في تقييم الضمانات وأحكام التصفية. (TS Finance Docs)
هذا النوع من التصميم لا يملك حضورًا كبيرًا عادةً.
عندما تكون الأمور عادية، لن يظن أحد أن بروتوكولًا “يحتاج إلى الانتظار يومًا لتعديل المعلمات” لأنه بذلك يصبح أكثر روعة؛ وقد يعتقد حتى أنه مزعج. لكن عند مواجهة صلاحيات غير طبيعية أو عملية خاطئة فعلًا، قد تكون هذه الأيام هي نافذة الفحص والاكتشاف وإلغاء التعديل.
لذلك عندما أراجع البروتوكولات الآن، أميل إلى قلب صفحة إضافية نحو آليات الخلفية.
صفحة البداية الخاصة بـ APY موجهة للجميع، لكن ما يجعلني أرغب في البحث أكثر قليلًا هو: عند حدوث مشكلة، هل يترك البروتوكول وقتًا للمستخدمين أم لا.
عندما تنظرون إلى مشاريع DeFi، هل تقومون بالبحث بشكل خاص عن أشياء مثل Timelock؟
@TermMax #TermMax
عندما كنت أراجع أمان DeFi من قبل، كانت أول ردة فعلي دائمًا تتعلق بالتدقيق (audit) والـmulti-sign وهل سبق أن حدثت حوادث. لكن في TermMax هناك شيء أكثر دقة: بعض المعلمات الأساسية لا يمكن لمدير النظام تغييرها كما يشاء، بل يمكن أن تصبح نافذة فورًا في اللحظة التالية.
لدى Vault الخاص بها Timelock.
تقريبًا تكون العملية كالتالي: يقوم Curator أولًا بتقديم التعديل، ثم يدخل في فترة انتظار، وعند انتهاء الوقت فقط يتم قبول التعديل رسميًا. مدة الانتظار الافتراضية هي يوم واحد، وليست قابلة للتعيين عشوائيًا؛ فالمدى الذي تذكره الجهة الرسمية هو الأدنى يوم واحد والأقصى 30 يومًا. وخلال فترة الانتظار يوجد دور اسمه Guardian يمكنه فحص التعديلات التي لم تصبح نافذة بعد، وإذا وجد شيئًا غير صحيح يمكنه إلغاء التعديل. (TS Finance Docs)
برأيي، ليس الأكثر فائدة هنا هو رقم “24 ساعة”، بل حقيقة أنه يترك عمدًا نافذة فارغة.
إذا تم تعديل معلمة الرسوم عن طريق الخطأ، أو حدثت مشكلة في الصلاحيات، ففي حال تنفيذ التعديل فورًا، كلما كانت سرعة التنفيذ على السلسلة أعلى، قلّ الوقت المتاح للآخرين لاكتشاف المشكلة. إن Timelock يفصل عمليًا بين “تقديم التعديل” و“نفاذه الحقيقي” إلى حالتين منفصلتين.
كما يضيف TermMax Timelock أيضًا بشكل منفصل إلى أماكن مثل Oracle التي تؤثر في تقييم الضمانات وأحكام التصفية. (TS Finance Docs)
هذا النوع من التصميم لا يملك حضورًا كبيرًا عادةً.
عندما تكون الأمور عادية، لن يظن أحد أن بروتوكولًا “يحتاج إلى الانتظار يومًا لتعديل المعلمات” لأنه بذلك يصبح أكثر روعة؛ وقد يعتقد حتى أنه مزعج. لكن عند مواجهة صلاحيات غير طبيعية أو عملية خاطئة فعلًا، قد تكون هذه الأيام هي نافذة الفحص والاكتشاف وإلغاء التعديل.
لذلك عندما أراجع البروتوكولات الآن، أميل إلى قلب صفحة إضافية نحو آليات الخلفية.
صفحة البداية الخاصة بـ APY موجهة للجميع، لكن ما يجعلني أرغب في البحث أكثر قليلًا هو: عند حدوث مشكلة، هل يترك البروتوكول وقتًا للمستخدمين أم لا.
عندما تنظرون إلى مشاريع DeFi، هل تقومون بالبحث بشكل خاص عن أشياء مثل Timelock؟
@TermMax #TermMax