OP_CHECKTEMPLATEVERIFY تعليمة يُقترح إضافتها إلى Bitcoin Script، اللغة التي تُكتب بها شروط إنفاق البيتكوين. تفحص ما إذا كانت بيانات مختارة من المعاملة توافق خطة مُعدة مسبقاً، أي قالباً. تُمثّل الخطة ببصمة تشفيرية قصيرة تسمى هاش. ليست هذه البصمة توقيعاً ولا بصمة للمعاملة كاملة؛ ويحدد BIP119 بدقة البيانات التي تشملها.
تريد آنا تجهيز أموال لتوزيعها لاحقاً بين بيتر وإيفا. ولا تريد الاعتماد فقط على وعد شخص يحتفظ بالمال. في Bitcoin تُسجل الأموال غير المنفقة كمخارج معاملات تسمى UTXO؛ ويحمل كل مخرج مبلغاً وشروط استخدامه. يمكن لـCTV إضافة خطة توزيع محددة إلى تلك الشروط. وعند إنفاق المخرج، تفحص العقد، أي البرامج التي تتحقق من قواعد الشبكة، التزام المعاملة الجديدة بالخطة. مستلم مختلف أو مبلغ يخالف المحدد لن يجتاز الفحص. يصف Jeremy Rubin هذا المقترح في BIP119، الذي حصل على رقم BIP عام 2020. [1] [3]
يحدد القالب بنية التحويل: إلى كم مخرج سابق تشير المدخلات، وما المخارج الجديدة الواجب إنشاؤها. وبالنسبة إلى المخارج الجديدة يثبّت المبالغ والسكربتات، أي شروط إنفاقها لاحقاً. وبمزيد من التفصيل، يشمل BIP119 أيضاً إصدار المعاملة؛ وnLockTime، حقل القيود الزمنية للمعاملة كاملة؛ وحقول المدخلات nSequence التي قد تؤثر في الأقفال الزمنية؛ وفهرس المدخل الجاري فحصه. إذا كان أي scriptSig، وهو سكربت مدخل يقدّم بيانات الإنفاق، غير فارغ، يُضاف أيضاً هاش يشمل جميع حقول scriptSig. إذن ليست المسألة قائمة مستلمين فقط: تغيير أي حقل آخر مشمول ينتج قالباً مختلفاً أيضاً. أما الإشارات إلى العملات السابقة المحددة ومبالغها فمسألة منفصلة سنشرحها أدناه. [1]
البايت وحدة شائعة لقياس حجم البيانات. يستخدم الفحص المقترح هاشًا للقالب بطول 32 بايت محسوبًا بواسطة SHA256. تحسب العقدة البصمة نفسها من المعاملة التي تنفق المخرج، وترفض عدم التطابق. يثبت التوقيع الرقمي الإذن بالدفع باستخدام مفتاح خاص، وهو قيمة عددية سرية، دون الكشف عن المفتاح. قد يشترط جزء آخر من البرنامج توقيعًا؛ فلا يستبدله CTV في جميع الحالات. أطوال الوسيط الأخرى لا تنفذ هذا الفحص، وهي محجوزة لتوسعات مستقبلية، وإن كان يمكن لسياسة الترحيل رفضها. لذا لا يعني الوسيط الخاطئ تلقائيًا أن العملات أُقفلت بأمان. [1] [4] [12]
نستخدم في المثال التالي sats، وهي أصغر وحدات البيتكوين. لا يتضمن هاش القالب مباشرةً outpoint، أي الإشارة إلى UTXO المحدد الذي يُنفق، ولا مبلغ المدخل. لكن عدد المدخلات محدد رغم ذلك. لنفترض السماح بمدخل واحد فقط ومخرجات مجموعها 99 000 sats. يترك مدخل بقيمة 100 000 sats رسومًا قدرها 1 000 sats. والمدخل الأقل من مجموع المخرجات لا يمول هذه المعاملة. أما المدخل الأكبر مع بقاء المخرجات نفسها فيزيد الرسوم، ولا ينشئ باقيًا يُعاد تلقائيًا. [6] [9]
يمكن للقالب أن يشترط الانتقال إلى مخرج آخر يحتوي برنامجه على تأخير ومسار استرداد. يسمح ذلك ببناء خزنة تتيح وقتًا للتعامل مع سحب غير مرغوب فيه. لكن CTV ليس منظومة الأمان كاملة: المفاتيح وشروط المخرجات التالية والمراقبة وتأكيد الاسترداد في الوقت المناسب كلها مهمة. ويمكن إعداد بعض القيود بمعاملات موقعة مسبقًا، ولكن بمتطلبات مختلفة للتعاون وحذف المفاتيح. [8] [5]
تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. في أسلوب التحكم بالازدحام المقترح، يُؤكد أولًا مخرج يلزم الأموال بتوزيع لاحق. وقد تظهر مخرجات المستلمين الفردية في معاملات تالية، مثلًا حين يقل انشغال الشبكة. يحتاج المستلمون إلى بيانات الخطة وطريقة فعلية لممارسة حقهم. وهذا ليس كدفعة عادية تأكدت بالفعل إلى عناوينهم، ولا يجعل مساحة الكتلة المحدودة بلا حدود. [7] [11]
المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. قد تُعد آنا الخطة قبل نشر الدفعة بوقت طويل، حين لا تعرف أسعار الرسوم المستقبلية. تمنعها المخارج الثابتة من تقليل المبلغ المعاد إلى محفظتها بحرية وعرض الفرق على المعدّن. لذا يحتاج التصميم إلى طريقة لإضافة رسوم. أحد الخيارات CPFP مُعد بعناية: تنفق معاملة لاحقة مخرجاً من المعاملة الأصلية وتعرض رسوماً لتحفيز المعدّن على إدراجهما معاً. وخيار آخر هو قالب يسمح منذ البداية بمدخل إضافي. لا يمكن ببساطة إضافة ذلك المدخل إلى قالب لا يسمح إلا بمدخل واحد. وMempool مجموعة المعاملات غير المؤكدة لدى عقدة معينة؛ قبول المعاملة فيها لا يضمن إدراجها في كتلة. [2] [6] [10]
يتحقق CTV وحده من قالب بعينه؛ وليس لغة عامة لقراءة كل بيانات المعاملة ومقارنتها بحرية. يمكن استخدامه لإعداد خطط متفرعة لمعاملات مستقبلية، لكن لا ينبغي مساواته بقيود Covenants التكرارية العامة. وقد تتيح تركيباته مع تعليمات مقترحة أخرى قدرات أوسع. لذا يجب معرفة ما إذا كان العرض يستخدم CTV وحده أم حزمة تغييرات كاملة. [1] [2]
عند المراجعة في 17 أكتوبر 2026، يحمل BIP119 حالة Draft، أي أنه مقترح ما زال قيد التطوير. سيمنح OP_NOP4، التعليمة التي لا تؤثر حالياً أثناء التحقق من الكتل، وظيفة فحص جديدة. يسمى هذا التشديد للقواعد المشتركة Soft Fork. لكن الوثيقة نفسها لا تحدد التفعيل. نشر BIP لا يحوّل opcode إلى تعليمة مفروضة فعلياً؛ كما لا يثبت الكود أو تأييد مطوّر أو محفظة تجريبية تطبيقها على شبكة Bitcoin الرئيسية، mainnet. لذلك يجب تحديد الشبكة والقواعد والمقترحات الأخرى التي يعتمد عليها كل عرض. [1]
ما دامت القاعدة غير مطبقة، لا يكفي وجودها في البرنامج للاعتماد على حمايتها؛ فالإجماع ورفض mempool ليسا الشيء نفسه. وحتى مع دعم CTV، قد يحبس قالب إلزامي وحيد بلا مسار بديل مخرجًا لا يكفي رصيده. لكن إيداعًا صغيرًا جديدًا لا يمنع تلقائيًا إنفاق UTXO أخرى مُوّلت بصورة صحيحة. يحتاج التصميم الآمن إلى فحص المبالغ والرسوم والنسخ الاحتياطية وكل مسارات الاسترداد. [1] [4] [6]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Covenants, Timelock, قواعد الإجماع, Bitcoin Script, UTXO, CPFP (Child Pays for Parent). تشير إلى هذا المدخل أيضًا Covenants, Bitcoin Vault, OP_CAT, Ark.