jakiro
著者: アーロン・チャン;出典: X、@zzmjxy
Bitcoin Core v30 では OP_RETURN 制限が緩和されます。それは「序数表記制限が無効だから」と皆さんおっしゃっています。
過去 3 か月間、私は Bitcoin Core v30 メーリング リスト、Citrea ホワイト ペーパー、および関連する技術文書を詳しく調べてきました。誰もが無視していた真実を発見してください: OP_RETURN ポリシー変更の本当の理由は序数ではありませんでした。それはビットVMです。
この物語はオーディナルズの物語よりも重要です。この観点から見ると、中国語と英語のコミュニティでは誰もこのことについて話したことはありません。
事件の背景
2024 年 4 月、Citrea は最初の完全な BitVM ブリッジ Clementine をリリースしました。
これは、L1 検証に BitVM を使用した、ビットコインの最初の zkRollup です。
その後、144 バイトのアンカー データをオンチェーンで公開する必要があるという技術的な問題に遭遇しました。
技術的要件
この 144 バイトには次のものが含まれます。
- <リ>
128バイト: Groth16ゼロ知識証明
<リ>
16 バイト: 累積作業の合計 (作業証明の合計)
このデータは、Watchtower がオペレーターに質問する際に、正しいビットコイン チェーンを持っていることを証明するために使用されました。ここに問題があります。OP_RETURN では 83 バイトしか許可されません。足りない。
主要な技術的制約
なぜそれを証人にしないのかと疑問に思う人もいるかもしれない。オーディナルズみたいな？主な違い: Citrea の後続の検証トランザクションでは、このデータを読み取る必要があります。
ビットコイン スクリプトは、前のトランザクションの監視データを参照できません。したがって、データは scriptPubKey の場所に**ある必要があります**。これはオプションではありません。
技術原則
簡単に言うと次のとおりです。
目撃データ:
- <リ>
「現在の取引が有効である」ことのみを証明できます✓
<リ>
後続のトランザクションでは読み取ることができません ✗
scriptPubKeyデータ:
- <リ>
後続のトランザクションのスクリプトによって参照可能 ✓
BitVM の検証ロジックには連鎖参照が必要なため、scriptPubKey を使用する必要があります。
強制的な計画
83 バイトでは十分ではなかったため、Citrea はデータを公開鍵として偽装する「使用できない」Taproot 出力を作成するという恐ろしいアプローチを使用することを余儀なくされました。
具体的な方法:
- <リ>
出力 0: OP_1 <最初の 32 バイトは公開鍵として偽装されます>
<リ>
出力1: OP_1 <公開鍵に偽装された32バイト>
<リ>
出力 2: OP_RETURN <残り 80 バイト>
これらの「公開キー」には、対応する秘密キーがまったくありません。それは決して費やされることはありません。
危険性分析
このソリューションの問題点は、UTXO セットを永続的にインフレートすることです。
各 WatchtowerChallenge トランザクションでは、決してクリーンアップできない 2 つの UTXO が作成されます。すべてのフルノードは、これらの「偽の公開キー」を永続的に保存する必要があります。これはまさに、コア開発者が避けようとしていた最悪のシナリオです。
メーリングリストのオリジナルテキスト
アントワーヌ・ポアンソは提案書に明確にこう書いています。
「Clementine はデータを保存するために使用できない Taproot 出力を使用します…OP_RETURN のサイズ制限のため」
このケースは、OP_RETURN ポリシー変更提案を**直接トリガー**します。元のメール。
開発者のロジック
コア開発者の思考回路:
- <リ>
現状: Citrea は偽 UTXO (悪い) を使用しています
<リ>
将来: さらに多くの BitVM プロジェクトがこれに続くでしょう
<リ>
または: ネイキッド マルチシグ (スタンプ プロトコルなど) を使用します。
<リ>
結論: OP_RETURN を手放し、「害の少ない」パスを提供する方がよい
これはハームリダクション戦略です。
BitVM の戦略的立場
なぜ Core は BitVM に「道を開く」ことに積極的なのでしょうか?なぜなら、BitVM はビットコイン L1 イノベーションの重要な方向性だからです。
Blockstream CEOのAdam Back氏は「BitVMのアンカーメカニズムはL1の重要な方向性である」と述べた。
BitVM エコシステムが発展すると、次のようになります。
- <リ>
さまざまな zkRollup
<リ>
クロスチェーンブリッジ
<リ>
複雑なオンチェーン検証
同様の固定ニーズもあるでしょう。
序数との本質的な違い
序数と BitVM アンカー データ:
序数:
- <リ>
場所：目撃者（剪定可能）
<リ>
動機: 思索/芸術
<リ>
特徴：色褪せする可能性があります
BitVM アンカー:
- <リ>
場所: scriptPubKey (永続的である必要があります)
<リ>
動機: インフラストラクチャのセキュリティのニーズ
<リ>
特徴：長期的な成長需要
まったく異なる技術的なシナリオ。
結論
したがって、Bitcoin Core v30 の OP_RETURN ポリシー変更は Ordinals への降伏ではなく、BitVM エコシステムの積極的なガイドです。それは投機に対する受け身の反応ではなく、技術革新への道を事前に切り開く方法です。これはコア開発者による前向きな考え方です。
したがって、Core が JPEG に焦点を当てたことはありませんが、次のとおりです。
- <リ>
将来の VM への道を開く (BitVM/Simplicity/Covenants)
<リ>
システムが進化し続けるために、10 年以上前に残された特別ルールをクリーンアップする
<リ>
ポリシー層がイノベーションを制限する「目に見えないコンセンサス」になることを回避する
これらをマスターすれば、今後10年間のビットコインの技術的な方向性を把握できるでしょう。これは、対序数、対ノットの間の単なる舌戦ではなく、テクノロジー進化の論理を真に理解することです。
