元の翻訳: GaryMa Wuがブロックチェーンについて語る
Blockspace によると、ビットコインの草の根コミュニティはビットコインの基盤となるソフトウェアの変更を推進し始めており、これは 4 年以上の間で珍しい出来事です (以前は、基盤となる大きな変更はすべてコア開発者グループによって推進されていました)。
今回は、2 つのビットコイン改善提案 (BIP)、BIP-119 (CTV) と BIP-348 (CSFS) に対する草の根の支持が生まれています。これら 2 つの提案は、ビットコインが「契約」の機能を実装できるようにするビットコイン スクリプトを作成する新しい方法を提案しています。両方の提案は、ビットコインの次のソフトフォークで実装される可能性があります。
一部の読者がビットコイン契約とこれらの特定の BIP ソリューションとの関係を一時的に理解できなくなることを防ぐために、ここで明確にします。
簡単に言えば、コヴナントはビットコイン ネットワークにおける機能的な概念であり、この記事で言及されている 2 つの BIP は、この機能的な概念に対する異なる実装ソリューションです。
ビットコイン契約とは何ですか?
意味：
契約は、ビットコイン プロトコルで提案されたメカニズムであり、取引に条件や制限を設けて、ビットコインの使用または転送方法を指示することができます。これらの条件は複数のトランザクションにまたがる可能性があり、将来の支出が行われる方法を制限し、ビットコインのスクリプト機能を強化します。
効果：
より複雑なアプリケーション（ローン、分散型取引所、金庫など）をサポートするために、ビットコインのスマート コントラクト機能を改善します。
資金の盗難や不正使用を防ぐためのセキュリティを強化しました。
取引手数料の削減やプライバシーの向上など、ネットワーク パフォーマンスを最適化します。
ここで、コヴナントとは概念であり、この記事で言及されている BIP-119 (CTV) と BIP-348 (CSFS) はコヴナントの機能概念の具体的な実装であることが大まかに分かります。
現在のステータス:
ビットコインのメインネットは現在、Covenants関連の機能を公式に統合していませんが、関連する議論や提案（BIP-119など）は長年にわたって進められています。
BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)
トランザクション出力が、後続の支出トランザクションが一致する必要がある「テンプレート」を指定できるようにする、提案された Bitcoin オペコード。
これは、元 Bitcoin Core 貢献者の Jeremy Rubin によって提案され、5 年以上前から存在しています。資金が事前に定義された方法でのみ使用されるように制限することで、「状態保持」機能を有効にします。
アプリケーションシナリオには以下が含まれます。
取引手数料を削減するためにバッチ支払いを作成します。 分散型取引所 (DEX) または貸付プロトコルを構築します。
資金を盗難から保護するために Vault を実装します。
· CTV は、複雑なロジックを必要とせずに出力形式の制限に重点を置いた Covenants の軽量実装です。
BIP 348: OP_CHECKSIGFROMSTACK (CSFS)
現在のトランザクションのハッシュだけでなく、任意のメッセージに対して署名が有効であることを検証できるようにする提案された Bitcoin オペコード。データ スタックから署名、公開キー、メッセージを取得し、署名が一致するかどうかを確認します。
2024 年 11 月にジェレミー ルービンとブランドン ブラックによって正式に提案されました。
OP_CSFS は、トランザクション入力の「イントロスペクション」、つまり署名されたトランザクションの完全な内容または状態を検査できるため、より柔軟な契約を実装するための強力なツールです。
具体的な用途:
契約の実装: OP_CSFS を使用すると、複雑な条件付きロジックを作成し、資金が特定のルールに従ってのみ使用されるようにすることができます。たとえば、バリデーターは、トランザクション入力が事前に設定されたテンプレートまたは制約に準拠しているかどうかを確認できます。
セキュリティ強化: 署名検証による盗難や不正な支出を防ぐための Vault と分散プロトコルのサポート。
拡張性: 他のオペコード (OP_CAT など) と組み合わせることで、より複雑なスマート コントラクトを構築できます。
Bitcoin の Covenants や BIP-119 (CTV)、BIP-348 (CSFS) の提案について言及する場合、OP_CAT は間違いなく欠かせません。
BIP 347: OP_CAT
歴史：
初期の存在: OP_CAT は、ビットコインが 2009 年にリリースされたときに Satoshi Nakamoto によって組み込まれた、ビットコインのオリジナルのスクリプト言語の一部でした。もともとはスクリプトの柔軟性を高め、より複雑なロジックをサポートするために設計されました。
削除理由（2010年）:
OP_CAT は、潜在的なセキュリティの脆弱性とリソースの悪用を防ぐために、2010 年に削除 (無効化) されました。
· 具体的な問題:制限されていない場合、悪意のあるユーザーが OP_CAT を使用して無限長のデータ (再帰呼び出しを通じて) を生成すると、Bitcoin ノードがこのデータを処理する必要があり、コンピューティングとストレージのオーバーヘッドが増加するため、「サービス拒否攻撃」(DoS 攻撃) が発生する可能性があります。
当時、ビットコインのスクリプト言語は簡素化され、プロトコルの軽量、安全、分散性を確保するために最も基本的な機能が保持されていました。
定義と機能:
OP_CAT は、Bitcoin Script 言語のオペコードです。これは直接的な Covenant 実装ではありませんが、複雑な Covenant ロジックを構築するための潜在的なツールです。上記の 2 つのオペコードと比較すると、OP_CAT はより汎用的でデータ操作に適していますが、複雑な機能を実現するには他のオペコードと組み合わせる必要があります。
現状：
近年、ビットコイン コミュニティでは OP_CAT の復活について再議論が行われています。以前はコミュニティに優しい BIP-420 提案の形で登場しましたが、現在は BIP-347 番号で bitcoin/bips リポジトリに正式に統合されています。
調子はどうだい？
Coindeskによると、過去数週間で多くの西洋のビットコイン開発者がTwitterでCTVとCSFSへの支持を表明しており、これは間違いなく、少なくともソーシャルメディア界では、ビットコインコミュニティの一部がこれらの変更を受け入れる方向に動いていることを示す強力なシグナルです。
さらに、開発者は一般的に、これら 2 つの提案の定義は比較的「狭い」と考えています。簡単に言えば、これは、一度有効にすると、ユーザーが誤って誤用する可能性が低くなることを意味します。ビットコイン開発者コミュニティは歴史的にビットコインへの変更に対して慎重でした。たとえば、BIP 119 は 5 年近く休止状態でしたが、つい最近まで CTV は過激すぎるため有効化できないと考えられていました。
両提案の共同提案者であるジェレミー・ルービン氏によるCTV推進の以前のキャンペーンは、特にアダム・バック氏やジミー・ソング氏など多くのフォロワーを持つビットコインのインフルエンサーたちから強い反対に直面していた。こうした批判は最終的にビットコインコミュニティに広く不満を抱かせることとなり、ルービン氏はビットコイン分野から退くことを余儀なくされた。
それで、この変化を引き起こした正確な原因は何でしょうか?最近の OP_CAT オペコードの支持により、「許容可能」と見なされるビットコイン提案の範囲が広がり、CTV と CSFS が比較的「保守的な」選択肢として位置づけられているようです。 OP_CAT を支持する人々のほとんどが、BIP 119 と BIP 348 (および他のほとんどの提案) も支持していることは注目に値します。
次は何が期待できるでしょうか?まず、議論は継続されます。開発者は、4月に予定されているOPNEXT、7月のBTC++、10月のTABConfなど、いくつかの技術会議で提案をさらに検討することが期待されています。開発者が予備的な合意に達すると、ソフトフォークの実際の有効化はマイナー、コミュニティ、投資家に引き渡され、最終確認が行われます。
コミュニティ/ソフトフォークプロセスにおける BIP の議論の進捗状況を追跡するにはどうすればよいでしょうか?
答えは非常に難しいです！
ビットコインの技術コミュニティでは通常、これらの提案について詳細な議論が行われます。しかし、これは一見すると不明瞭で循環的な議論プロセスです。
簡単に言えば、ビットコインのソフトフォークのプロセスでは、開発者、管理者、投資家、マイナーなど、さまざまなビットコイン関係者からのサポート レベルを大まかに見積もる必要があります。最も直接的なサポートの指標は、多くの場合、マイナーから発信されます。マイナーは、マイニングしたブロック内でシグナルを送信することで、コードベースの変更に対する承認を示すことができるからです。通常、Bitcoin Core では、アップデートを有効化するためにロックする前に、一定期間にわたって 95% のブロックがサポートを通知する必要があります。
しかし、「幅広いサポート」をどのように定義するかについてはコンセンサスがなく、ビットコインのコンセンサスは常に進化しています。マイナーは、ビットコイン ネットワーク内で「カウント可能な」エンティティであるという理由だけで、重要なシグナル プロバイダーとなります。つまり、ビットコインの分散型構造のため、「目に見える」観点から全体的なコンセンサスを測定することは困難です。
しかし、ビットコイン NFT で有名な開発会社 Taproot Wizards は、OP_CAT を例に挙げて、ビットコインのソフトフォークの長くて複雑なプロセスをフローチャートの形で明らかにしています。興味のある読者は、https://www.quantumcats.xyz/bip-land で自分で確認することができます。ここでは、それを要約してみます。
BIP 提案ライフサイクル | ビットコインのソフトフォークの長く複雑なプロセス
1. この提案は当初、Bitcoin 開発者のメーリング リストで提案され、議論されました。
2. コミュニティ全体でのより大規模な議論に入り、提案された機能の長所と短所に関する長期的な議論のジレンマに入ります。これ以上の進展が見られない場合、ここで停止します。
3. 草の根コミュニティが Github で提案の BIP ドラフトを作成します。
4. 開発者は関連コードの実装を開始し、長期的な監査バグがない場合にのみ先に進むことができます。
5. Bitcoin リポジトリ BIP エディターによるレビューとコミュニティによる初期承認の後、公式の BIP 番号が割り当てられます。
6. Signet テスト ネットワークに入ります。 Signet は、開発者がメイン ネットワークに影響を与えることなく、新しい機能やコードの変更を試すことができる Bitcoin テスト ネットワークです。 (おそらく、ほとんどの新機能はこの段階で永久に棚上げされるでしょう)
7. 実験のために Liquid サイドチェーンにエントリする可能性があります。
8. Bitcoin Core に PR を送信します。
9. 非常に不確実な Bitcoin Core のコードレビューと提案のマージ プロセスに入ります。提案がほとんどの反対意見を回避し、技術的な要件を満たしている (重大なバグがない) 場合にのみ、マージ段階に入る機会が与えられます。主要な開発者 (Pieter Wuille など) の意見は多くの場合非常に重要であり、その承認または拒否は提案の運命に大きな影響を与えます。
10. コードレビューに問題がなければ、Bitcoin リポジトリのメンテナーが PR をメイン プロジェクトにマージするのを待ちます。現在、メンテナーは 5 人います: Michael Ford (fanquake)、Hennadii Stepanov (hebasto)、Andrew Chow (achow 101)、Gloria Zhao (glozow)、Ryan Ofsky (ryanofsky)。
11. ビットコイン開発者やマイナーなどのさまざまなグループ間では、潜在的な論争や議論が引き続き存在します。
12. アクティベーションメカニズムを選択します。
a. マイナー主導のソフトフォーク (MASF): 新しいルールは、BIP-9 または BIP-8 のデフォルト モードなどのシグナリング (通常は 95% のしきい値) を通じてマイナーによってアクティブ化されます。比較的安定していますが、幅広い合意とテストの調整が必要なので時間がかかります。
b. ユーザーが開始するソフトフォーク (UASF): ノードオペレーター (ユーザー) は、マイナーの抵抗を回避するために新しいルール (BIP-8 の「Lockinontimeout: True」など) を強制的にアクティブ化しますが、チェーンフォークのリスクやコミュニティの意見の不一致が生じる可能性があります。
結論
ウー氏は、Bitcoin.orgドメイン名の管理者であるCobraが、ビットコインネットワークは2025年にビットコインコアの外部の匿名開発者によって開始されるユーザー主導のソフトフォーク（UASF）を導入する可能性があると警告したことが以前に報じられていたと述べた。これは実際には、この記事で言及されているBIP 119の潜在的な変更である。コブラは、これらの改善により、草の根コミュニティが主導し、ビットコインのコア開発者以外の人々が推進する「強硬派」と「改善派」の分裂を引き起こす可能性があると考えている。
UASF（ユーザー主導ソフトフォーク）は、ビットコインユーザーが主導するプロトコルアップグレード方法であることがわかっています。マイナーやその他の関係者がサポートしていなくても、ノードソフトウェアをアップグレードすることでプロトコルの更新を強制するため、チェーンフォークのリスクも伴います。もちろん、現時点ではあまり心配する必要はありません。結局のところ、多くのことがまだ解決されていないからです。たとえば、将来のソフトフォークには CTV と CSFS のみが含まれるのでしょうか?このオペコード セットでよく議論される OP_CAT は考慮されますか?ソフトフォークの実際のアクティベーションプロセスはどのように展開されるのでしょうか?他の利害関係者（ビットコインマイナーなど）はそれを真剣に受け止めるでしょうか？
結局のところ、BIP のコンセンサスが十分に大きい限り、草の根コミュニティによって推進される提案も、マイナー主導のソフトフォーク (MASF) の形で実行することができます。そして、UASF にも歴史上成功した事例があります。 UASF は 2017 年の SegWit アップグレードで重要な役割を果たし、ユーザーはソフトフォークの推進、ハードフォークの回避、ビットコインの拡張の促進に成功しました。
参考リンク:
