هذا هو الجزء الخامس من سلسلة المقالات التقنية التي تنشرها Cointelegraph Research حول العهود في بيتكوين. لقراءة المقال السابق، انقر هنا. 

MATT (تحويل كل شيء إلى شجرة ميركل) هو إطار عمل للعقود الذكية في بيتكوين، يتيح إنشاء عقود ذات حالة وإثباتات احتيال قابلة للتوسع. يحتفظ العقد ذو الحالة بالمعلومات وينقلها عبر معاملات متعددة، ويمكنه تحديث هذه المعلومات مع تطور العقد. لا توفر نصوص بيتكوين البرمجية القياسية هذه الإمكانية، إذ يُقيَّم كل تحويل على نحو مستقل، من دون الاحتفاظ بذاكرة لعمليات التنفيذ السابقة.

يتيح كل مقترح للعقود المشروطة حملَ UTXOs للحالة إلى حدٍّ ما، كما توضّح لغات البرمجة النصية مثل Sapio، المبنية على OP_CTV. وتعمل هذه الآلية باستخدام العناوين لتمثيل آلة حالات منتهية، حيث تؤدي المعاملات دور انتقالات الحالة. لكن لا توجد طريقة أنيقة لتنفيذ المنطق العددي ضمن هذا النموذج، وهي فجوة يسدّها MATT، ولا سيما عبر تطبيقه المقترح باستخدام OP_CCV. وبما أن MATT يتيح حساب البيانات الملتزم بها وقت الإنفاق وإعادة تضمينها في المخرج التالي، يمكن لكل إنفاق اشتقاق حالة جديدة ديناميكيًا، بدلًا من الاختيار من مجموعة حالات محددة مسبقًا.

كيف يلتزم OP_CCV بالحالة ضمن مفتاح Taproot

لفهم مقترح MATT، من المفيد أولًا استعراض كيفية التزام Taproot بالبيانات عبر المفاتيح العامة. يحتوي كل مخرج Taproot على مفتاح عام أساسي يُسمى المفتاح الداخلي، ويمكن تعديله تشفيريًا أو «تطويعه» ليتضمن معلومات إضافية. وصيغة المفتاح العام المطوَّع هي Q = P + t·G، حيث P هو المفتاح الداخلي، وG هو المولّد لمنحنى secp256k1 الإهليلجي، وt هو تجزئة موسومة للمفتاح P والبيانات الملتزم بها.

في مخرج Taproot اعتيادي، يشفّر هذا الالتزام عادةً جذر Merkle لشجرة taptree التي تحتوي على مسارات إنفاق مخفية. وينطلق MATT من هذه الآلية ليضمّن أيضًا حالة العقد في المفتاح. وبدلًا من تضمين منطق معقد مباشرةً في لغة Bitcoin النصية، يشفّر MATT العمليات الحسابية كسلسلة من التزامات الحالة، ولا تتحقق السلسلة إلا من صحة كل انتقال للحالة.

يمكن تنفيذ MATT باستخدام مجموعات مختلفة من أكواد العمليات. ويعتمد التنفيذ الأكثر مباشرةً والأوضح مواصفات على OP_CHECKCONTRACTVERIFY (OP_CCV). يوفر OP_CCV العنصر الأساسي الذي يجعل UTXOs الحاملة للحالة ممكنة ضمن Taproot. يتيح OP_CCV للبرنامج النصي التحقق من أن مفتاح مدخل أو مخرج Taproot قد طُوِّع للالتزام بقطعة محددة من بيانات الحالة. يُطوَّع المفتاح الداخلي أولًا باستخدام تجزئة للحالة الراهنة للعقد، ثم يُطبَّق فوقه تطويع شجرة taptree القياسي في Taproot. ولذلك يلتزم مفتاح المخرج الناتج بكلٍّ من tapscript (مجموعة شروط الإنفاق) والحالة الراهنة للعقد.

يمكن لـ OP_CCV بعد ذلك فرض الحالة التي تُنقل إلى المخرج التالي. فهو يتيح للبرنامج النصي فحص بيانات الحالة المقدمة على مكدس الشاهد، وإجراء العمليات الحسابية عليها، واشتراط إعادة الالتزام بالحالة المحدَّثة الناتجة على نحو صحيح في مخرج محدد. وهكذا تُفرض انتقالات الحالة على السلسلة. وتنسيق المكدس هو:

<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY

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

OP_CCV + OP_CAT: براهين Merkle وبراهين الاحتيال

عند الجمع بين OP_CCV وOP_CAT، يصبح إطار MATT بأكمله أكثر تعبيرًا. يتيح OP_CAT وصل البايتات في Script، ما يجعل إنشاء براهين Merkle والتحقق منها مباشرةً على السلسلة ممكنًا. وفي هذا الترتيب، ترتبط بمخرج Taproot شجرتا Merkle منفصلتان. الأولى هي شجرة البرامج النصية المألوفة في Taproot (taptree)، وأوراقها هي برامج الإنفاق النصية للعقد. والثانية شجرة حالة منفصلة، وأوراقها بيانات العقد، مثل الخطوات الوسيطة لعملية حسابية. يستطيع برنامج OP_CCV + OP_CAT النصي التحقق من برهان Merkle مقابل جذر شجرة الحالة الراهنة، وحساب الجذر المحدَّث بعد الانتقال، واستخدام OP_CCV لإلزام المخرج التالي بالالتزام به.

يتيح هذا التصميم إنشاء أنظمة لإثبات الاحتيال تتضمن شرطًا للمصادرة، حيث تُلتزم عملية حسابية طويلة خارج السلسلة، ولا يلزم كشف الخطوة محل النزاع تحديدًا (مع مسارها في الشجرة الثنائية) والتحقق منها على السلسلة إلا عند الحاجة. وتوجد أنظمة مشابهة على شكل تجميعات تفاؤلية في أنظمة بلوك تشين أخرى: تُنفّذ العملية الحسابية كاملةً خارج السلسلة، ولا يتدخل العقد على السلسلة إلا عندما يرفع أحدهم اعتراضًا. وتتطلب براهين الاحتيال ترجمة العملية الحسابية إلى دائرة ثنائية أو تمثيل مكافئ خطوة بخطوة يمكن الالتزام به ضمن شجرة Merkle. من شأن OP_CCV + OP_CAT أن يغني عن الحاجة إلى توقيعات Lamport أحادية الاستخدام ومخططات المعاملات الموقعة مسبقًا التي يعتمد عليها BitVM لفرض اتساق الحالة.

إلى جانب براهين الاحتيال، ينطوي الجمع بين OP_CCV وOP_CAT أيضًا على آثار مهمة للخزائن. يستطيع OP_CCV وحده تنفيذ الخزائن، لكن جمعه مع OP_CAT يتيح إنشاء خزائن متكاملة الوظائف تكافئ عمليًا الوظائف المقترحة في OP_VAULT. وكما أشار James O’Beirne، مؤلف OP_VAULT، فإن OP_CCV يمثل تصميمًا أعم وأكثر متانة يتجاوز فعليًا مقترحه السابق.

في المقال التالي من هذه السلسلة، سننتقل من المقترحات العامة للعقود المشروطة إلى استعراض أكواد العمليات المخصصة لتطبيقات بعينها، مثل OP_VAULT وOP_UNVAULT وOP_EVICT. صُمم كل كود من أكواد العمليات لحل مشكلة محددة، لا لتوفير قابلية برمجة واسعة النطاق.

المجلة: تلقّى حاملو Bitcoin نقود eCash — ماذا يمكنكم أن تفعلوا بها؟