پیشنهادهای مبتنی بر کووننت (Covenant) در بیت‌کوین به طور کلی این امکان را فراهم می‌کنند که UTXO ها (واحد خرج‌نشده تراکنش) بتوانند وضعیت خود را حفظ کنند. زبان‌های اسکریپت‌نویسی مانند Sapio که بر پایه OP_CTV کار می‌کنند، با استفاده از آدرس‌ها به عنوان نمایش‌دهنده اتوماتای متناهی حالت (finite state automaton) و تراکنش‌ها به عنوان انتقال‌دهنده حالت، به این هدف دست می‌یابند. با این حال، پیاده‌سازی منطق عددی پیچیده در این پارادایم دشوار است.
شکافی که توسط MATT، و به طور خاص پیاده‌سازی پیشنهادی آن از طریق OP_CCV، پر می‌شود. MATT به داده‌های متعهد شده اجازه می‌دهد تا در زمان خرج شدن محاسبه شده و دوباره در خروجی بعدی جاسازی شوند. این امر موجب می‌شود که هر خرج بتواند وضعیت جدیدی را به صورت پویا استخراج کند، به جای انتخاب از مجموعه‌ای از وضعیت‌های از پیش تعیین شده.
جاسازی وضعیت در کلید Taproot
برای درک پیشنهاد MATT، مفید است ابتدا بررسی کنیم که Taproot چگونه داده‌ها را از طریق کلیدهای عمومی متعهد می‌کند. هر خروجی Taproot حاوی یک کلید عمومی پایه به نام کلید داخلی است که می‌تواند از نظر رمزنگاری اصلاح یا "توییک" (tweak) شود تا اطلاعات اضافی را متعهد کند. به طور رسمی، کلید توییک شده Q = P + t·G است، که در آن P کلید داخلی، G مولد منحنی بیضوی secp256k1 و t یک هش تگ‌گذاری شده از P و داده‌های متعهد شده است.
در خروجی معمولی Taproot، این تعهد معمولاً ریشه Merkle یک تریپ‌تری (taptree) را رمزگذاری می‌کند که شامل مسیرهای خرج پنهان است. MATT بر این مکانیزم بنا نهاده شده تا وضعیت قرارداد را نیز در کلید جاسازی کند. به جای جاسازی منطق پیچیده مستقیماً در زبان اسکریپت بیت‌کوین، MATT محاسبه را به صورت دنباله‌ای از تعهدات وضعیتی رمزگذاری می‌کند و زنجیره تنها معتبر بودن هر انتقال وضعیت را تأیید می‌کند.
نقش OP_CCV در MATT
MATT می‌تواند از طریق ترکیب‌های مختلف opcode پیاده‌سازی شود. مستقیم‌ترین و خوش‌تعریف‌ترین پیاده‌سازی به OP_CHECKCONTRACTVERIFY (OP_CCV) متکی است. OP_CCV ابزاری را فراهم می‌کند که UTXO های وضعیت‌بردار (state-carrying UTXOs) را در چارچوب Taproot امکان‌پذیر می‌سازد. OP_CCV به یک اسکریپت اجازه می‌دهد تا تأیید کند که آیا کلید ورودی یا خروجی Taproot برای تعهد به داده‌های وضعیتی خاص توییک شده است یا خیر. ابتدا کلید داخلی با هش وضعیت فعلی قرارداد توییک شده و سپس توییک استاندارد تریپ‌تری Taproot روی آن اعمال می‌شود. بنابراین، کلید خروجی حاصل هم به تری‌اسکریپت (tapscript - مجموعه شرایط خرج) و هم به وضعیت فعلی قرارداد متعهد می‌شود.
OP_CCV می‌تواند اجبار کند که چه وضعیتی به خروجی بعدی منتقل شود. این امکان را به اسکریپت می‌دهد تا داده‌های وضعیتی را که در پشته شاهد (witness stack) ارائه شده، بازرسی کند، محاسباتی را روی آن انجام دهد و الزام کند که وضعیت به‌روز شده حاصل به درستی در خروجی مشخص شده مجدداً متعهد شود. این نحوه اجبار انتقال‌های وضعیتی در زنجیره است. فرمت پشته به صورت زیر است:
`
این opcode از سه حالت برای بررسی خروجی و همچنین یک حالت ورودی مجزا پشتیبانی می‌کند. در حالت پیش‌فرض (default)، کل ارزش BTC از UTXO ورودی به خروجی مشخص شده اختصاص می‌یابد؛ در حالت کسر (deduct)، تنها بخشی برابر با مقدار خروجی تخصیص داده می‌شود و باقیمانده برای خروجی‌های بیشتر در دسترس است؛ و در حالت نادیده گرفتن (ignore)، اسکریپت و تعهد داده بدون محدود کردن مقدار تأیید می‌شوند. از آنجا که حالت‌های پیش‌فرض و کسر برای حفظ ارزش در خروجی‌های بررسی شده طراحی شده‌اند، کارمزد تراکنش باید از طریق ورودی‌های مجزای پرداخت کارمزد تأمین شود. یک ورودی کارمزد اختصاصی و خروجی تغییر (change output) را می‌توان به تراکنش اضافه کرد بدون اینکه با محدودیت‌های کووننت تداخل داشته باشد. این امر از سوزانده شدن تصادفی وجوه که در پیاده‌سازی‌های کووننت ابتدایی‌تر مانند OP_CTV یا SIGHASH_ANYPREVOUT رخ می‌دهد، جلوگیری می‌کند. همچنین به محدودیت عمده کووننت‌های سبک تراکنش از پیش امضا شده (presigned-transaction-style covenants) می‌پردازد که معمولاً مقادیر را از قبل تعریف می‌کنند و بنابراین نمی‌توانند هزینه‌های کارمزد پویا یا باز کردن قفل جزئی را در خود جای دهند.
OP_CCV و OP_CAT: اثبات‌های Merkle و اثبات‌های تقلب
هنگامی که OP_CCV با OP_CAT ترکیب می‌شود، چارچوب کامل MATT بیانگرتر می‌شود. OP_CAT امکان الحاق بایت در Script را فراهم می‌کند که ساخت و تأیید اثبات‌های Merkle را مستقیماً در زنجیره ممکن می‌سازد. در چنین ترتیبی، دو درخت Merkle مجزا به خروجی Taproot مرتبط می‌شوند. اولین مورد، درخت اسکریپت Taproot آشنا (تریپ‌تری) است که برگ‌های آن اسکریپت‌های خرج قرارداد هستند. دومی، یک درخت وضعیت مجزا است که برگ‌های آن داده‌های قرارداد، مانند مراحل میانی یک محاسبه، هستند. اسکریپت OP_CCV + OP_CAT می‌تواند یک اثبات Merkle را در برابر ریشه درخت وضعیت فعلی تأیید کند، ریشه به‌روزشده را پس از یک انتقال محاسبه کند و از OP_CCV برای وادار کردن خروجی بعدی به تعهد به آن استفاده کند.
این ساختار سیستم‌های اثبات تقلب (fraud-proof systems) را با شرط برش (slashing condition) امکان‌پذیر می‌سازد که در آن یک محاسبه طولانی به صورت خارج از زنجیره (off-chain) متعهد می‌شود و تنها مرحله مورد مناقشه خاص (با مسیر آن در درخت باینری) نیاز به افشا و تأیید در زنجیره دارد. سیستم‌های مشابه به عنوان رول‌آپ‌های خوش‌بینانه (optimistic rollups) در سایر سیستم‌های بلاک‌چین وجود دارند: کل محاسبه به صورت خارج از زنجیره اجرا می‌شود و قرارداد روی زنجیره تنها زمانی مداخله می‌کند که کسی چالشی را مطرح کند. اثبات‌های تقلب نیازمند این هستند که محاسبه به یک مدار باینری یا معادل آن نمایشی گام به گام کامپایل شود که بتوان آن را در یک درخت Merkle متعهد کرد. OP_CCV + OP_CAT نیاز به امضاهای یک‌بار مصرف Lamport و گراف‌های تراکنش از پیش امضا شده که BitVM برای اجبار سازگاری وضعیت به آن‌ها متکی است را از بین می‌برد.
فراتر از اثبات‌های تقلب، ترکیب OP_CCV و OP_CAT همچنین پیامدهایی برای کیف پول‌ها (vaults) دارد. OP_CCV به تنهایی می‌تواند کیف پول‌ها را پیاده‌سازی کند، اما هنگامی که با OP_CAT ترکیب می‌شود، کیف پول‌های کاملاً مجهز را امکان‌پذیر می‌سازد که اساساً معادل عملکرد پیشنهادی OP_VAULT هستند. همانطور که جیمز اوبرین، نویسنده OP_VAULT، اشاره کرده است، OP_CCV نمایشی عمومی‌تر و قوی‌تر است که به طور مؤثر پیشنهاد قبلی او را جایگزین می‌کند.
در مقاله بعدی این مجموعه، از پیشنهادات عمومی کووننت به بررسی آپ‌کدهای خاص برنامه مانند OP_VAULT، OP_UNVAULT و OP_EVICT خواهیم پرداخت. هر یک از این آپ‌کدها برای حل یک مشکل خاص طراحی شده‌اند نه ارائه قابلیت برنامه‌نویسی گسترده.
