
يشير Locktime إلى "خط نضج" محدد مسبقًا للأموال أو العمليات على البلوكشين. قبل الوقت أو الحدث المحدد، لا يمكن استخدام الأموال أو تنفيذ العملية. بعد انتهاء locktime، تصبح الأصول أو الإجراءات متاحة. يمكن تحديد locktime كنقطة زمنية مطلقة أو ارتفاع كتلة، أو كفاصل زمني نسبي يبدأ من تأكيد معين.
هناك نوعان رئيسيان من locktime: المطلق والنسبي. يعمل locktime المطلق كوديعة لأجل، حيث يحدد وقتًا محددًا أو ارتفاع كتلة تصبح فيه الأموال متاحة. بينما يعمل locktime النسبي كـ"فترة تهدئة"، ويتطلب مرور عدد معين من الكتل أو فترة زمنية بعد تأكيد المعاملة قبل أن يمكن استخدام الأصول.
يُستخدم هذا الميكانيزم على نطاق واسع لتأخير تسوية المعاملات، واستحقاق التوكنات للفرق، وقفل عمليات staking وyield farming، وتأخير تنفيذ الحوكمة، بالإضافة إلى عمليات atomic swaps عبر السلاسل وضمانات الدفع في Lightning Network.
في Bitcoin، يمكن فرض locktime على مستوى المعاملة أو السكريبت. على مستوى المعاملة، يحدد حقل nLockTime أقرب وقت ممكن لتأكيد المعاملة. أما على مستوى السكريبت، فتقوم أوامر برمجية محددة بالتحقق من شروط القفل عند إنفاق الأموال.
تطبيق على مستوى المعاملة:
يدعم حقل nLockTime قاعدتين: إذا كانت القيمة أقل من حوالي 500 مليون، يتم تفسيرها كارتفاع كتلة؛ وإذا كانت تساوي أو تزيد عن ذلك، تُقرأ كختم زمني (Unix timestamp). لكي يسري مفعول nLockTime، يجب ألا يكون رقم تسلسل كل إدخال مضبوطًا على قيمته القصوى؛ وإلا تعتبر المعاملة قابلة للإنفاق فورًا.
تطبيق على مستوى السكريبت:
OP_CHECKLOCKTIMEVERIFY (CLTV، تم تفعيله عبر BIP-65 في 2015) يسمح للسكريبتات بفرض أن الأموال لا يمكن إنفاقها إلا إذا بلغ ارتفاع الكتلة الحالي أو الختم الزمني عتبة محددة.OP_CHECKSEQUENCEVERIFY (CSV، تم تفعيله عبر BIP-68/112 في 2016) يدعم locktime النسبي من خلال اشتراط مرور فترة محددة (كتل أو وقت) بعد تأكيد المعاملة قبل السماح بالإنفاق.على سبيل المثال، يمكنك إنشاء معاملة إلى "نفسك في المستقبل" لا يمكن إنفاقها إلا بعد الكتلة 900000، أو استخدام CSV لقفل الأموال لمدة 100 كتلة إضافية بعد التأكيد. كما يستخدم Bitcoin "الوقت الوسيط الماضي" لآخر 11 كتلة (BIP-113) لتقليل قدرة المعدنين على التلاعب بالطوابع الزمنية.
على منصات مثل Ethereum، يُطبق locktime عادة عبر متغيرات العقود الذكية وضوابط الوصول. قبل انتهاء المدة، يرفض العقد عمليات السحب أو تغيير المعلمات أو إطلاق التوكنات؛ وبعد الموعد النهائي، يُسمح بهذه الإجراءات.
تشمل التطبيقات الشائعة ثلاثة أمثلة:
غالبًا ما يستخدم المطورون مكتبات مدققة (مثل TimelockController وVesting من OpenZeppelin) لتكوين الحد الأدنى من التأخيرات، وصلاحيات الأدوار، والمستفيدين لزيادة الأمان.
في منتجات yield farming للـDeFi أو منتجات staking في المنصات المركزية، يحدد locktime كلاً من السيولة والعائد السنوي. غالبًا ما تقدم فترات القفل الأطول عوائد أعلى لكنها تقيد قدرتك على إعادة تخصيص الأموال خلال فترة القفل.
على منصات مثل Gate، ستجد خيارات مثل "مرن"، "7 أيام"، "30 يومًا"، أو "90 يومًا" للـlocktime. المنتجات المرنة تقدم عوائد أقل لكنها تتيح السحب في أي وقت؛ أما الخيارات محددة الأجل فتعطي عوائد أعلى لكنها قد تفرض رسوم سحب مبكر أو تتطلب التنازل عن المكافآت. تحقق مما إذا كان السحب المبكر مسموحًا، وكيفية حساب العوائد، وما إذا كان هناك سحب تلقائي عند الاستحقاق عند اختيار المنتج.
استراتيجية عملية هي "القفل المتدرج"—تقسيم الأموال إلى أجزاء بفترات قفل مختلفة لتحقيق توازن بين السيولة والعائد. احتفظ بجزء مرن للاحتياجات قصيرة الأجل لتجنب البيع القسري بأسعار غير مناسبة.
تستخدم المبادلات عبر السلاسل وLightning Network عقود Hash Time-Locked Contracts (HTLCs) لضمان الذرية—إما أن تنجح المبادلة للطرفين أو يُسترد المال لكليهما. يضمن "hash lock" أن من يملك السر الصحيح فقط يمكنه استلام الأموال؛ ويضمن "time lock" أنه إذا انتهت المهلة، تُعاد الأموال لأصحابها الأصليين.
تسير العملية كالتالي: يقوم الطرف A بقفل الأموال على السلسلة بحيث لا يمكن للطرف B استلامها إلا بكلمة المرور الصحيحة قبل الموعد النهائي؛ وإلا يمكن للطرف A استردادها بعد الانتهاء. يقوم الطرف B بعملية مماثلة على سلسلة أخرى، بحيث إما ينجح كلا الطرفين أو تنتهي المهلة وتُسترد الأموال.
في Lightning Network، تستخدم قنوات الدفع locktimes نسبية لتأمين الأموال إذا فشلت المدفوعات. يتم ضبط المهلات بناءً على أوقات تأكيد الشبكة والازدحام—تستخدم المبادلات الذرية على السلسلة عادة مهلات تتراوح من عدة ساعات حتى يوم واحد للسماح بالتأكيدات وإجراءات المستخدمين.
كلتا الطريقتين تحددان "متى تصبح الأموال متاحة"، لكن لكل منهما مزايا وعيوب. ارتفاع الكتلة يقيس "كم عدد الكتل المتبقية"، ويتجنب انحراف الساعة؛ بينما الطوابع الزمنية أكثر وضوحًا لكنها عرضة لتعديلات طفيفة من قبل المعدنين أو المدققين.
في Bitcoin، تُفسر قيم nLockTime الأقل من ~500 مليون كارتفاع كتلة (مناسب لـ"انتظر N كتل")، بينما القيم الأعلى تعتبر طوابع زمنية (مثالي لتواريخ تقويمية محددة). في Ethereum، تستخدم العقود عادة block.timestamp، لكن أوقات الكتل الفعلية قد تنحرف لعشرات الثواني بسبب ظروف الشبكة—لذا غالبًا ما تتضمن timelocks نوافذ واسعة للمرونة.
أفضل ممارسة: استخدم ارتفاع الكتلة للمعالم التقنية (مثل التنفيذ بعد N كتل بعد الترقية)؛ واستخدم الطوابع الزمنية للالتزامات الخارجية (مثل فك القفل في تاريخ UTC محدد)، مع ترك هامش زمني دائمًا.
المخاطر الرئيسية تتعلق بقيود السيولة، وتقلب الأسعار، وتفاصيل التنفيذ. كلما طالت فترة قفل الأموال، زادت احتمالية تفويت الفرص السوقية؛ وقد تضطر إلى السحب المبكر في حالات الحاجة العاجلة مع خسارة العائد أو دفع غرامات.
من ناحية التنفيذ، يمكن تعديل الطوابع الزمنية قليلاً من قبل المعدنين/المدققين. يحد Bitcoin من ذلك عبر قاعدة "الوقت الوسيط الماضي" (ليس قبل متوسط آخر 11 كتلة)، وتحدد معظم الشبكات انحراف الوقت المسموح (مثلاً حتى ساعتين). في Ethereum، يمكن حدوث تلاعب طفيف بالطوابع الزمنية—لذا تجنب الاعتماد على دقة الثواني.
الأخطاء في الإعداد شائعة أيضًا: مثل تفسير العتبات بشكل خاطئ (كتل مقابل ثوانٍ)، أو نسيان ضبط تسلسل الإدخالات لـnLockTime، أو صلاحيات timelock غير الصحيحة، ما قد يجعل الأصول غير قابلة للوصول. إذا كانت الأصول المقفلة تستخدم كضمان، فقد يؤدي انخفاض الأسعار أثناء فترة القفل إلى تصفية مع عدم وجود فرصة لإعادة التعبئة بسرعة.
بالنسبة للمطورين والمستخدمين، تتبع الممارسة الآمنة عملية "تصميم-تكوين-تحقق":
الخطوة 1 (لمطوري Bitcoin): حدد ما إذا كان locktime مطلقًا أم نسبيًا. في المطلق مع nLockTime، اضبط جميع تسلسلات الإدخالات أقل من القيمة القصوى؛ وفي النسبي استخدم CSV مع ترميز الكتلة/الوقت الصحيح. اختبر دائمًا على testnet قبل النشر.
الخطوة 2 (لمطوري Ethereum): استخدم عقود Timelock وVesting المدققة؛ كوّن الحد الأدنى من التأخيرات، والأدوار، وإجراءات الطوارئ. في تنفيذ الحوكمة، اتبع تدفق الاقتراح → الانتظار في الطابور → التأخير → التنفيذ وأعد اختبار السيناريوهات الرئيسية في بيئات الاختبار.
الخطوة 3 (للمستخدمين على Gate): عند staking أو استخدام منتجات العائد (staking)، اختر فترة قفل مناسبة؛ تحقق من قواعد السحب المبكر والغرامات المحتملة؛ احتفظ بجزء من الأموال مرنًا للطوارئ؛ ضع تذكيرات بالاستحقاق وراقب تحديثات المنتجات.
الخطوة 4 (عمليات عبر السلاسل والقنوات): اختر مهلات HTLC طويلة بما يكفي مع مراعاة تأكيدات cross-chain وازدحام الشبكة؛ فضل التطبيقات المدققة؛ وابدأ بمبالغ صغيرة قبل التوسع.
تذكر ثلاثة أساسيات:
يشير Locktime إلى فترة تُجمّد فيها أموالك على السلسلة—لا يمكنك تحويل أو استخدام هذه الأصول حتى النضج. بعد الانتهاء، تُفك الأموال تلقائيًا وتصبح متاحة للاستخدام. هذا الميكانيزم شائع في مكافآت العائد DeFi واستحقاق التوكنات، ويهدف إلى حماية مصالح المستثمرين.
تختلف Locktimes في المنصات حسب نوع المنتج—غالبًا ما تأتي مكافآت العائد بفترات مثل 30 أو 90 أو 180 يومًا. عادة تقدم فترات القفل الأطول عوائد سنوية أعلى. اختر فترة القفل على Gate وفقًا لاحتياجات السيولة لديك.
معظم المنصات لا تدعم فك القفل المبكر خلال فترة القفل؛ السحب المبكر عادة يؤدي إلى خسارة المكافآت أو دفع غرامات. قد تسمح بعض المنتجات بفك القفل المبكر مقابل رسوم عالية. قيّم احتياجاتك التمويلية قبل الالتزام بأي فترة قفل.
في بروتوكولات الإقراض DeFi، يحدد locktime متى يمكنك سحب الضمانات. تتطلب بعض البروتوكولات بقاء الضمانات مقفلة لفترات محددة لضمان أمان القرض. قد تؤدي عمليات فك القفل المبكر إلى مخاطر تصفية أو غرامات—تعامل بحذر.
تختلف قواعد Locktime بشكل كبير بين التوكنات والمنصات. لدى Bitcoin وEthereum آليات مختلفة؛ كما تختلف سياسات منصات DeFi. راجع دائمًا شروط القفل وتفاصيل العائد للأصل الذي اخترته على Gate أو أي منصة أخرى قبل المشاركة.


