MATT提案がBitcoinの状態保持型契約をOP_CCVプルリクエスト32080で目指す

状態を運ぶオペコード、Bitcoinスクリプトへの実装案

Bitcoin Coreのリポジトリに公開された提案は、これまでネットワークのスクリプトに存在しなかった「記憶」を与えようとしている。状態保持型の契約とスケーラブルな不正証明を基盤層で可能にするMATT(Merkleize All The Things)フレームワークの最も直接的な実装が、プルリクエスト32080で運ばれるオペコードOP_CHECKCONTRACTVERIFY、略してOP_CCVだ。コベナントとは、コインが将来の取引でどこに送金されうるかをスクリプトのルールで制約する仕組みを指す。標準のBitcoinスクリプトは各取引を独立に評価し、過去の支出が何をしたかの記録を持たない。そのため契約は情報を先に繰り越して更新できず、進化する契約状態を表現できない。コベナント案の多くは、程度の差こそあれ状態を持つUTXOを許している。OP_CTVに基づくSapioのようなスクリプト言語は、アドレスを有限状態機械として扱い、各取引を状態遷移とみなすことでこれを実現してきた。コベナントは長年、活発なBitcoinプロトコル提案の一角にありながら、素のScriptはその保証に届かず実装には至っていない。この有限状態機械のパラダイムでは数値的な論理をきれいに表現できず、そこを埋めるのがMATTの役割だ。MATTではコミットされたデータを支出時に計算し、次の出力に再び埋め込める。各支出が事前に定めた状態の集合から選ぶのではなく、新しい状態を動的に導出できる。オペコードはTaproot出力向けに設計されており、コミットメントは追加のスクリプトデータではなく公開鍵そのものに乗る。この違いが、変動する残高に契約を適応させられるか、事前に合意した結果の固定木にしか適応させられないかを分ける。提案の対象はチャートに現れる部分ではなくブロックチェーン上のビットコイン(BTC)の価格を下支えするスクリプト層だが、支出時に引き出し条件を再計算するvaultから、争われた計算の1ステップだけを検証する不正証明システムまで、単純な決済を超えてこの資産に何をさせるかを定義するものである。

改変鍵と3つのチェックモード

すべてのTaproot出力は内部鍵と呼ばれる基底の公開鍵を含み、これは追加情報へのコミットのために暗号学的に改変(tweak)できる。改変後の鍵はQ = P + t·Gの形をとる。Pは内部鍵、Gはsecp256k1楕円曲線のジェネレーター、tはPとコミットされたデータのタグ付きハッシュである。通常のTaproot出力では、このコミットメントは隠された支出経路を持つtaptreeのMerkleルートを符号化するのが普通だ。MATTは同じ機構の上に立ち、契約状態も鍵に埋め込む。チェーンが検証するのは各状態遷移の有効性だけで、契約のロジックそのものは実行しない。オペコードは状態データ、出力インデックス、公開鍵、任意のtaptree、そしてモードを取る。出力を検査する3つのモードと、入力を検査する独立の1モードがある。デフォルトモードは入力UTXOの全額を指定出力に割り当てる。控除(deduct)モードは出力額に等しい部分だけを割り当て、残りを追加の出力に解放する。無視(ignore)モードは金額を制約せずスクリプトとデータのコミットメントだけを検証する。デフォルトと控除の両モードは検査対象の出力間で価値を保持するため、取引手数料は別の手数料用入力で支払う必要がある。専用の手数料入力とお釣り出力はコベナントの制約と衝突せず並走できる。これにより、OP_CTVやSIGHASH_ANYPREVOUTのようなより原始的なコベナント方式で起きうる資金の意図しない焼失を防げる。事前署名型コベナントが金額を先に確定させ、動的な手数料調整や部分解錠に対応できなかった制限も解消する。表現力はOP_CATとの組み合わせでさらに広がる。OP_CATはScriptでバイト連結を可能にし、両者を使えば支出スクリプトではなく契約データを保持する第2の木に対してオンチェーンでMerkle証明を構築・検証し、次の出力に更新後のルートへのコミットを強制できる。不正証明システムはここから導かれる。長い計算はオフチェーンで実行し、争われたステップと二進木中の経路だけがオンチェーンで公開・検証される。この計算はまずステップごとの二進表現へコンパイルされる必要があり、elftraceという二進回路ツールが扱う課題がまさにそこにある。構造はEthereumのオプティミスティックロールアップを映し出し、同じ不正証明モデルが多くのクロスチェーンブリッジを支えている。また、状態整合性の強制にLamportの一回限り署名と事前署名取引グラフに依存するBitVMからその負担を外し、OP_VAULTが提案したvault機能も再現できる。OP_VAULTの作者James O'Beirneは、OP_CCVをより汎用で堅牢な設計だと述べ、自身の初期提案を事実上置き換えるものだと位置づけている。

審査とアクティベーションの道のり

手数料処理の設計こそが、OP_CCVを過去のコベナント案から分かつ要点である。デフォルトと控除の各モードが価値を検査対象の出力内に保持し、手数料が別入力を流れるため、事前署名フローが破綻する手数料市場の実環境でも状態保持型の設計は機能し続けられる。現時点でマージされたものはない。プルリクエストにはアクティベーションの日程は示されておらず、仮に将来的に使われるとしても、ノード運用者が新しい合意ルールを強制するソフトウェアを実行する必要がある。Bitcoinの変更が皆たどる緩慢な道程だ。ホルダーへのより近い影響は設計空間の拡大にある。ネイティブなvaultが自己管理の保証でwrapped Bitcoinへの依存を減らしうる一方、状態木は信頼された管理主体なしにBitcoin DeFiが決済できる範囲を広げる。残る課題はBitcoin Coreのレビュアーと開発者コミュニティ側にあり、いずれかがメインネットに届く前にオペコードの合意動作を監査する必要がある。