【ロングスレッド】見過ごされてきた真実：Bitcoin Core v30がOP_RETURNの制限を解除した本当の動機

Chainfeeds ガイド：

Bitcoin Core v30 の OP_RETURN ポリシー変更：これは Ordinals への降伏ではなく、BitVM エコシステムへの積極的な誘導です。投機への受動的な対応ではなく、技術革新のために事前に道を整えるものです。これは Core 開発者による先見的な思考です。

出典：

記事著者：

Aaron Zhang

見解：

Aaron Zhang：2024年4月、Citrea は最初の完全な BitVM bridge —— Clementine をリリースしました。これは Bitcoin 上で最初の zkRollup であり、BitVM を用いて L1 検証を行います。その後、彼らは技術的な課題に直面しました：チェーン上に 144 バイトのアンカーデータを公開する必要があったのです。この 144 バイトには、128 バイトの Groth16 zero-knowledge proof と、16 バイトの total accumulated work（総作業量証明）が含まれています。これらのデータは、Watchtower が Operator に異議を唱える際に、彼らが正しい Bitcoin チェーンを保持していることを証明するために使用されます。ここで問題が発生します：OP_RETURN は 83 バイトしか許可されていません。足りません。なぜ witness に入れないのか？Ordinals のように？重要な違いは、Citrea の後続検証トランザクションがこれらのデータを読み取る必要がある点です。しかし Bitcoin Script は前のトランザクションの witness データを参照できません。したがって、データは scriptPubKey の位置に置く必要があり、これは選択肢ではありません。簡単に言えば：Witness データは現在のトランザクションの有効性を証明できますが、後続のトランザクションで読み取ることはできません。scriptPubKey のデータは後続トランザクションの Script から参照できます。BitVM の検証ロジックはチェーン参照が必要なので、scriptPubKey を使う必要があります。83 バイトでは足りず、Citrea はやむを得ず非常に悪い方法を採用しました：「使えない」Taproot outputs を作成し、データを公開鍵に偽装したのです。この方法の問題は、UTXO set の永続的な膨張です。各 WatchtowerChallenge トランザクションは、永久にクリーンアップできない UTXO を2つ作成します。すべてのフルノードはこれらの偽公開鍵を永久に保存しなければなりません。これは Core 開発者が常に回避したいと考えていた最悪のケースです。Core 開発者の思考プロセス：現状では Citrea が偽 UTXO（悪い方法）を使い、将来的にはより多くの BitVM プロジェクトがこれに倣うか、あるいは裸のマルチシグ（Stamp プロトコルのような）を使うでしょう。結論としては、OP_RETURN を解放し、「より小さな害」の道を提供した方が良いということです。これは harm reduction（害の軽減）戦略です。なぜ Core は BitVM のために道を開くのか？それは BitVM が Bitcoin L1 の革新にとって重要な方向性だからです。Blockstream CEO の Adam Back は「BitVM の anchor メカニズムは L1 の重要な方向性だ」と述べています。もし BitVM エコシステムが発展すれば、さまざまな zkRollups、クロスチェーン bridges、複雑なオンチェーン検証が同様のアンカー需要を持つことになるでしょう。