كيف يعمل القفل الزمني للحوكمة؟

يحوّل القفل الزمني للحوكمة الإجراء المعتمد إلى عملية ظاهرة علناً يجب أن تنتظر قبل التنفيذ. تعرّف على كيفية عمل المعرّفات والأدوار والتأخيرات وانتهاء الصلاحية والإلغاء ونوافذ الخروج.

لأغراض تعليمية فقط؛ ولا يُعد نصيحة استثمارية. قد يؤدي الاستثمار إلى خسارة.

الإجابة المباشرة

القفل الزمني للحوكمة هو متحكم في التنفيذ، وليس تصويتاً آخر. بعد أن تسمح الحوكمة بحمولة ما، يقوم مقترِح معتمد بجدولة العملية المحددة. يسجل العقد الوقت الذي يمكن أن تصبح فيه قابلة للتنفيذ ويرفض تنفيذها قبل ذلك الوقت. يجعل هذا التأخير ترقية معلقة أو تغييراً في معلمة أو تحويلاً من الخزانة أو تغييراً في الأدوار ظاهراً قبل دخوله حيز التنفيذ.

التأخير المعلن ليس سوى جزء واحد من الضوابط. راجع معرّف العملية، وأقرب وقت للتنفيذ، وأي قاعدة لانتهاء الصلاحية، والعملية السابقة، والمقترِح، والمنفذ، وصاحب صلاحية الإلغاء، والمسؤول، وكل مسار آخر يمكنه التحكم في العقد المستهدف. لا يوفر قفل زمني مدته 48-hour نافذة خروج مدتها 48-hour إذا أُضيفت العملية إلى قائمة الانتظار متأخرة، أو تأخرت المراقبة، أو استغرقت عمليات السحب وقتاً أطول، أو تمكن مفتاح آخر ذو صلاحيات خاصة من إجراء التغيير نفسه فوراً.

لا يقرر القفل الزمني ما إذا كان الإجراء مشروعاً أو آمناً. بل يمنح الأشخاص وأنظمة المراقبة الآلية وقتاً لفك ترميز الاستدعاءات ومحاكاة آثارها والإلغاء أو الإيقاف المؤقت عند وجود الصلاحية وإبلاغ التغيير والخروج من المراكز عندما يكون هناك مسار خروج فعلي.

آلية العمل

تُسند الصلاحية إلى القفل الزمني. يجب أن يملك القفل الزمني العقد المستهدف أو أن يحمل الدور ذي الصلة فيه. إذا لم تكن للحاكم أي صلاحية على العقد المستهدف، فلن يغيّر تمرير المقترح شيئاً؛ وإذا احتفظ مسؤول منفصل بصلاحية موازية، فقد يتجاوز ذلك المسار التأخير.
يجدول المقترِح عملية محددة. في TimelockController من OpenZeppelin، يُحسب معرّف العملية المفردة من تجزئة target وvalue وdata وpredecessor وsalt؛ أما العمليات المجمعة فتُحسب من تجزئة المصفوفات المقابلة مع التبعية نفسها وقيمة salt نفسها. يؤدي تغيير أي حقل إلى إنشاء معرّف عملية مختلف. وتميز قيمة salt الإجراءات التي تكون متطابقة لولاها.
يبدأ الحد الأدنى للتأخير عند الجدولة. لا يؤدي نجاح التصويت بالضرورة إلى بدء القفل الزمني. تسجل الجدولة طابعاً زمنياً للجاهزية باستخدام تأخير لا بد أن يساوي على الأقل الحد الأدنى الحالي في العقد. تنتقل عمليات OpenZeppelin من Unset إلى Waiting، ثم إلى Ready، وأخيراً إلى Done بعد نجاح التنفيذ.
تُفحص التبعيات والصلاحيات عند التنفيذ. يجب أن تكون العملية السابقة قد بلغت حالة Done. ويجب أن يستوفي المستدعي قاعدة المنفذ وأن ينجح استدعاء العقد المستهدف. لا يستطيع المنفذ تغيير الحمولة المجدولة. يؤدي منح دور المنفذ إلى address(0) إلى إتاحة التنفيذ لأي شخص بعد النضج، ما يحسن استمرارية التنفيذ لكنه يتيح لأي حساب اختيار اللحظة الدقيقة المؤهلة للتنفيذ.
يعيد الإلغاء العملية المعلقة إلى حالتها الأولية. في عقود OpenZeppelin الحالية، يستطيع حساب يحمل CANCELLER_ROLE إلغاء عملية ما دامت معلقة، بما في ذلك عندما تكون جاهزة ولم تُنفذ بعد. وتبدأ إعادة الجدولة مؤقتاً جديداً. يهم توزيع الأدوار: فقد تمنح الإصدارات الأقدم والأقفال الزمنية الأخرى صلاحية الإلغاء للمقترِح أو المسؤول بدلاً من ذلك.
يعتمد انتهاء الصلاحية على التطبيق. لا يتضمن TimelockController من OpenZeppelin انتهاء صلاحية مدمجاً لفترة السماح؛ فالعملية الجاهزة تظل جاهزة حتى تُنفذ أو تُلغى. أما Timelock في Compound v2 فيشترط التنفيذ في موعد لا يتجاوز eta + GRACE_PERIOD، ويضبط كوده المصدري GRACE_PERIOD على 14 days. ويصنف Governor Bravo المقترح المدرج في قائمة الانتظار منتهي الصلاحية بعد تجاوز ذلك الحد.
يجب أن تخضع الإدارة أيضاً للتأخير. لا تسمح OpenZeppelin باستدعاء updateDelay إلا من خلال استدعاء يرسله القفل الزمني إلى نفسه. وبالمثل، يفرض النشر ذاتي الإدارة تمرير تغييرات الأدوار عبر عمليات مجدولة. وينبغي لمسؤول خارجي مؤقت استُخدم أثناء الإعداد أن يتنازل عن ذلك الدور بعد اكتمال التهيئة؛ وإلا فسيظل مسار ثقة منفصلاً.

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

مثال محلول

افترض أن مقترحاً يخفض عتبة التصفية في سوق إقراض من 75% إلى 60%. ينتهي التصويت عند Monday 12:00 UTC، لكن المقترِح لا يجدول العملية حتى Tuesday 18:00 UTC. مدة التأخير المجدولة هي 48 hours، ولذلك يكون أقرب تنفيذ عند Thursday 18:00 UTC، وليس Wednesday 12:00 UTC.

تتضمن العملية عقد مدير المخاطر بوصفه target، وقيمة value تساوي صفراً من الرمز الأصلي، وdata مشفرة لتغيير المعلمة، ومن دون عملية سابقة، ومع قيمة salt معلنة. يجب أن تتطابق إعادة حساب التجزئة من هذه الحقول مع معرّف العملية الصادر. ويُعد اختلاف عنوان السوق أو العتبة أو قيمة salt عملية مختلفة، حتى لو بدا وصف الواجهة مطابقاً.

لذلك تتاح للمستخدمين مدة 48 hours من وقت الجدولة، لكن وقت الخروج القابل للاستخدام أقصر. إذا وصل التنبيه بعد 6 hours من الجدولة واستغرقت قائمة انتظار فك الرهن أو السحب 24 hours، فلن يتبقى سوى هامش قدره 18 hours:

usable response time = ready time - detection time - exit settlement time

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

المخاطر والضوابط

صلاحية التجاوز. احصر المالكين ومسؤولي العقود الوكيلة وأدوار التحكم في الوصول وإشارات الترقية ومجالس الطوارئ والوحدات والمنفذين عبر السلاسل. يحدد أقصر مسار ذي صلاحيات خاصة مدة التأخير الفعلية.
استبدال الحمولة أو ضعف فك الترميز. أعد حساب معرّف العملية من الحقول الخام، وحدد تطبيقات العقود الوكيلة، وفك ترميز كل محدد وكل وسيطة، وحاكِ المجموعة كاملة. نص المقترح المقروء للبشر ليس الحمولة القابلة للتنفيذ.
إشعار غير كافٍ. أطلق التنبيهات من أحداث الجدولة والإلغاء على السلسلة، لا من منشورات المنتديات وحدها. قِس مهلة الإشعار من الجدولة المؤكدة إلى أقرب كتلة أو طابع زمني قابل للتنفيذ، ثم اطرح وقت الاكتشاف وتسوية الخروج.
فشل الإلغاء. تحقق من الحسابات القادرة على الإلغاء، وما إذا كانت عاملة، والعتبة التي تتطلبها، وما إذا ظل الإلغاء ممكناً بعد أن تصبح العملية جاهزة. تدرّب على المعاملة قبل وقوع حادث.
فشل المنفذ أو التلاعب بالتوقيت. قد يصبح المنفذون المقيدون غير متاحين أو يؤخرون التنفيذ عمداً. يحسن التنفيذ المفتوح الاستمرارية، لكنه يسمح لأطراف ثالثة بالتنفيذ فور النضج؛ لذا يجب أن تكون الأسعار التابعة وتحديثات أوراكل ومراكز المستخدمين آمنة عند ذلك الحد.
إجراءات قديمة في قائمة الانتظار. عندما لا يوجد انتهاء للصلاحية، قد تظل العمليات القديمة الجاهزة قابلة للتنفيذ إلى أجل غير مسمى. تتبع العمليات المتروكة وألغها صراحة. وعندما توجد فترة سماح، راقب نهايتها الدقيقة واشترط دورة حوكمة جديدة بعد انتهاء الصلاحية.
مخاطر التبعية والتجميع. تحقق من معرّف العملية السابقة وترتيب المجموعة الذري. قد يؤدي استدعاء واحد متراجع إلى منع مجموعة ذرية؛ وقد تؤدي تبعية غير صحيحة إلى تعطيل عملية صالحة لولا ذلك بصورة دائمة.
إدارة غير آمنة. أخضع تخفيضات التأخير ومنح الأدوار واستبدال القفل الزمني للقفل الزمني نفسه. أزل مسؤولي النشر، واحتفظ بمقترِح ومنفذ صالحين واحد على الأقل، وتجنب أي تهيئة تقفل التحكم نهائياً.
عدم وجود خروج موثوق. قارن التأخير بقوائم انتظار السحب ونهائية الجسور وسيولة السوق وصلاحيات الإيقاف والازدحام. لا يحمي التأخير المنشور المستخدمين عندما يتعذر إخراج الأصول قبل التنفيذ.

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

مفاهيم خاطئة شائعة

“يبدأ التأخير عند انتهاء التصويت.” يبدأ عادة عند جدولة الإجراء الناجح، ما لم يربط التطبيق المنشور بين اللحظتين صراحة.
“يمكن لأي شخص التنفيذ، ولذلك يمكن لأي شخص تغيير المقترح.” لا يستطيع المنفذ المفتوح تشغيل سوى حمولة مجدولة مسبقاً يتطابق معرّف عمليتها وشروطها.
“تعني Ready وجوب تنفيذ الإجراء فوراً.” تعني Ready أن الإجراء أصبح مؤهلاً. ولا يزال التنفيذ يتطلب معاملة وصلاحيات وتبعيات مستوفاة واستدعاء ناجحاً للعقد المستهدف.
“لكل قفل زمني نافذة تنفيذ.” يختلف انتهاء الصلاحية باختلاف التطبيق. يستخدم Compound v2 فترة سماح، بينما لا تنتهي العمليات الجاهزة في TimelockController من OpenZeppelin افتراضياً.
“يزيل القفل الزمني الطويل مخاطر الحوكمة.” لا يفيد التأخير إلا عندما تكون المراقبة والفهم والإلغاء أو الإيقاف والتواصل والخروج ممكنة كلها قبل التنفيذ. ويمكن للمسؤولين الموازيين وعمليات السحب المعطلة إبطال فائدته.

المصادر

Governance API: TimelockController - OpenZeppelin Documentation (تاريخ الاطلاع: 2026-08-20)
Access Control: Delayed operation - OpenZeppelin Documentation (تاريخ الاطلاع: 2026-08-20)
Timelock.sol - Compound Finance (تاريخ الاطلاع: 2026-08-20)
GovernorBravoDelegate.sol - Compound Finance (تاريخ الاطلاع: 2026-08-20)