هذا هو الجزء الرابع من سلسلة المقالات الفنية حول مواثيق البيتكوين بواسطة Cointelegraph Research. لقراءة المقال السابق اضغط هنا.
لا تقوم أكواد التشغيل التالية بتنفيذ وظائف العهد الكاملة بشكل مستقل. بدلاً من ذلك، فهي بمثابة لبنات بناء لبناء المواثيق عند دمجها مع رموز التشغيل أو عناصر البرنامج النصي الأخرى.
OP_CHECKSIGFROMSTACK (OP_CSFS) وOP_CAT
OP_CSFS هو كود تشغيل مقترح يسمح لبرنامج Bitcoin النصي بالتحقق من التوقيعات عبر الرسائل العشوائية المتوفرة في المكدس. إنه مختلف عن OP_CHECKSIG، والذي يتحقق من التوقيعات على معاملة الإنفاق وفقًا لوضع SIGHASH النشط. من خلال تمكين التحقق من التوقيع للبيانات بخلاف تفاصيل المعاملة المتسلسلة، OP_CSFS يتيح فئة أوسع من الإنشاءات، بما في ذلك البرامج النصية المستندة إلى أوراكل حيث يقوم طرف خارجي بتوقيع رسائل خارج السلسلة تمثل أحداثًا في العالم الحقيقي. على سبيل المثال، يمكن لـ Oracle الموثوق به نشر توقيعات Schnorr عبر الرسائل التي تشفر النتائج الخارجية، و OP_CSFSيمكن أن يشترط البرنامج النصي المعتمد على المدفوعات وجود توقيع أوراكل صالح.
من تلقاء نفسها، OP_CSFS لا ينفذ العهود ويمكنه مصادقة البيانات الخارجية، لكنه لا يربط تلك البيانات ببنية معاملة الإنفاق. يتطلب هذا الربط OP_CAT.
OP_CAT هو كود تشغيل مقترح يمكّن من تسلسل قيمتين في مكدس البرنامج النصي لتشكيل تسلسل بايت واحد بدلاً من تسلسلين مختلفين. عندما يقترن مع OP_CSFS، فهو يسمح للبرنامج النصي بتجميع حقول المعاملات المحددة في رسالة أساسية والتحقق من التزام التوقيع المقدم بتلك الرسالة.
OP_CSFS و OP_CAT مجتمعة يمكن أن تؤدي إلى الاستبطان عن طريق إجبار المنفق على تقديم تفاصيل المعاملة على كومة الشهود. إذا كان كلاهما OP_CSFS و OP_CHECKSIG ينجح نفس التوقيع، فإنه يثبت أن تفاصيل المعاملة الصحيحة قد تم تمريرها إلى مجموعة الشاهد ويمكن التفكير فيها بشكل أكبر. من خلال التحقق من المعاملة مقابل قالب محدد مسبقًا، وهو بناء عهد، مشابه لـ OP_CTV، يمكن إنفاذها. تُظهر مجموعتان صغيرتان كيف يعمل هذا:


OP_CAT + حيل شنور
استخدام OP_CAT، يمكن تنفيذ الإنشاءات الشبيهة بالعهد ضمن Taproot بدونها OP_CSFS باستغلال كيف توقيعات شنور التفاعل مع قواعد Taproot sighash المحددة في بيب 341. يعيد البناء استخدام OP_CHECKSIG الذي يُستخدم عادةً لمصادقة ملكية مفتاح خاص، إلى أداة لاستبطان المعاملة.
توقيع شنور هو زوج ⟨ر، س⟩. في الظروف العادية، يتم إنشاء توقيع شنور هذا عن طريق تحديد رقم سري ك، استخلاص النقطة ص = كغوحساب قيمة التوقيع ق كوظيفة لتجزئة الرسالة والمفتاح الخاص. يقوم المدقق بعد ذلك بفحص زوج التوقيع ⟨ر، ق⟩ ضد المفتاح العام ص والرسالة قيد التوقيع. عشوائية k تضمن ذلك ق لا يمكن التنبؤ به وغير قابل للتكرار دون معرفة المفتاح الخاص.
خدعة الاستبطان يعمل عن طريق القضاء على العشوائية عن طريق إصلاح بعض هذه المتغيرات مسبقًا. بدلا من الاختيار ر بشكل عشوائي أثناء التوقيع، يلتزم البرنامج النصي بقيمة محددة مسبقًا وهي ر وإلى مفتاح عام ثابت ص. ولأن التحقق من شنور يتبع معادلة حتمية، يصبح من الممكن بناء هذه القيم بحيث يكون التوقيع العددي ق يجب أن تساوي تجزئة معلمات المعاملات المحددة.
يوفر المنفق ر و ق على كومة الشهود. OP_CAT يسلسلهم في زوج التوقيع ⟨ر، س⟩ بالصيغة OP_CHECKSIG يتوقع. يتحقق البرنامج النصي من ذلك مقابل المفتاح العام المشفر ص. لأن ر و ص يتم تثبيتها على نقطة الأساس ز, OP_CHECKSIG لن يقبل الزوج إلا إذا ق يساوي تجزئة SHA256 لبيانات المعاملة الفعلية المحسوبة بواسطة البروتوكول. لا يستطيع المنفق افتعال ق الذي يمر OP_CHECKSIG إلا إذا كانت تعكس بيانات المعاملة الحقيقية بشكل حقيقي. يجب على المنفق طحن بيانات المعاملة حتى تنتهي تجزئة SHA256 الخاصة بها ببايت محدد، الأمر الذي يستغرق حوالي 256 محاولة في المتوسط ويضيف تكلفة ضئيلة.

بهذه الطريقة، OP_CHECKSIG لم يعد يستخدم لمصادقة ملكية مفتاح خاص سري ولكن بدلاً من ذلك لفرض تطابق المعاملة مع قالب معين. التعبير يمكن مقارنته على نطاق واسع بـ OP_CTV.
نظرًا لأن هذا النهج يعتمد على توقيعات شنور وخوارزمية سيغاش الجذرية، فإنه ينطبق فقط على مخرجات SegWit v1 ولا يمتد إلى مخرجات SegWit v0 والذي يستخدم ملخص BIP-143 وتوقيعات ECDSA.
وفي مقالتنا القادمة سنبدأ مناقشتنا حول OP_CCV، وهو أكثر قدرة من OP_CSFS و OP_CAT مجموع.













