Cointelegraph Researchは、ビットコインの契約に関するシリーズの第5部を公開し、MATT（Merkleize All The Things）という新しいフレームワークとOP_CHECKCONTRACTVERIFY（OP_CCV）というオペコードを詳細に説明しました。この提案は、ビットコインに複数の取引にわたって可変契約状態を保持させる能力を与えることを目的としており、標準的なビットコインスクリプトが持たない機能です。

BTC / USD
出典：CoinGecko。価格は参考値です。

MATTがTaprootキーに状態を埋め込む方法

MATTは、Taprootの既存の調整メカニズムを拡張し、Taproot出力の公開鍵QをQ = P + t·Gとして導出します。ここでPは内部キー、tはコミットするデータのタグ付きハッシュです。従来はスクリプトツリーのMerkleルートのみをコミットしていましたが、MATTは状態データも調整に埋め込みます。状態はハッシュ化され調整に含まれ、次の出力が新しい状態を持ち、支出時に再計算されます。

OP_CHECKCONTRACTVERIFYが状態遷移を強制する

MATTの核心はOP_CHECKCONTRACTVERIFYです。レポートによれば、OP_CCVはスクリプトがTaproot入力または出力キーが特定の状態データで調整されていることを検証できるようにします。オペコードのスタック形式は<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFYで、3つの動作モードがあります：デフォルト（全入力値を指定出力へ移動）、減算（出力額のみ移動し、残りを他の出力に残す）、無視（金額制約なしに検証）。これらのモードは価値を保持しつつ、別々の手数料入力を許可し、OP_CTVやSIGHASH_ANYPREVOUTなどの以前の契約設計で見られた資金焼却問題を回避します。

OP_CATで表現力を拡張

OP_CHECKCONTRACTVERIFYとOP_CATを組み合わせると、フレームワークはオンチェーンでMerkle証明を構築・検証できます。Taproot出力には標準スクリプトツリーと、途中計算ステップを格納する別の状態ツリーの2つのMerkleツリーが関連付けられます。OP_CATはバイト列を連結し、スクリプトが現在の状態のMerkle証明を再構築し、遷移後の新しいルートを計算し、OP_CCVを使用して次の出力がその新しいルートにコミットするよう強制します。この設計は、ほとんどの計算がオフチェーンで行われ、争点のみがオンチェーンで検証される楽観的ロールアップに似た詐欺防止システムをサポートします。

次に注目すべき点

MATTの次のステップは、正式なBIP提案とBitcoin CoreでのOP_CHECKCONTRACTVERIFY実装のコミュニティテストです。Bitcoin開発者メーリングリストの更新や、状態を持つ契約、詐欺防止型金庫、シリーズで強調されたその他のユースケースを示すテストネット展開を注視してください。

FAQ

OP_CHECKCONTRACTVERIFYとは何ですか？

OP_CHECKCONTRACTVERIFYは、Taproot出力のキーが特定の契約状態データに調整されていることを検証する提案されたビットコインオペコードで、状態を持つUTXOを可能にします。

MATTは以前の契約提案とどのように異なりますか？

MATTは支出時に新しい状態を動的に計算し、柔軟な手数料入力をサポートしますが、OP_CTVなどの以前の提案は固定金額を要求し、動的状態更新がありません。