この記事では、BitcoinでZK検証を可能にする実用的な方法について掘り下げ、BitcoinのUTXOモデル、スクリプトの制限、Taproot、OP_CAT、BitVM、Chain State Proofsなどのトピックを取り上げています。BitcoinプロトコルへのZKの統合は避けられないという明確な議論を提供しています。2つの潜在的なルートが強調されています。1つはBitcoinスクリプトでSNARK検証を直接サポートするためにOP_CATオペコードを再導入することです。この変更は最終的に承認される可能性が非常に高いです。2つ目のアプローチは、詐欺証明を組み込んだBitVMに関連しています。さらに、ZeroSyncチームのChain State Proofsに関する提案は、ノードクライアントが歴史的データを検証するコストを削減することを目的としています。
メインテキスト:ビットコインを完全に理解するには、それを社会システムとして見ることが役立ちます。ビットコインの創造者たちは、初期にノードが実行する必要があるソフトウェアを定義し、社会を統治するルールを確立するのと同様にしました。ビットコインの安定性は、その基本的な性質に関する幅広い合意に依存しており、これについての質問が生じます。「ビットコインとは本質的に何か?」や「ビットコインはどのように進化すべきか?」しかし、これらの質問についての合意に達することは悪名高く難しいものであり、意見は大幅に異なり、絶えず進化しています。
これはビットコインの歴史的な起源にさかのぼります。サトシ・ナカモトがビットコインの白書を公開したとき、彼は「私は全く新しい電子決済システムに取り組んでいます。このシステムは完全にP2Pであり、どの第三者にも依存する必要がありません。」と述べました。このパッセージはCypherpunksメーリングリスト(1992年に設立された暗号学者や技術愛好家からなるメールディスカッショングループで、プライバシー保護や暗号技術に関心のある人々が参加しています)で公開されました。
ただし、ビットコインは製品設計レベルでデータスループットを制限しています。単位時間あたりに処理できる取引数には限りがあります。取引処理件数が急速に増加すると、ユーザーは取引を迅速に完了させるために価格競争を開始し、支払われる取引手数料を急速に増加させます。ビットコインネットワークで最も高い取引手数料が発生したのは、2024年にブロック報酬が半減した後であり、チェーン上の優先度が中程度の取引の手数料が150ドルに達しました。ビットコインネットワークの高額な取引手数料は問題となっています。
取引手数料の問題を解決するために、人々は大量のリソースをライトニングネットワークの開発に投資してきました。しかし、2016年に発表された論文によると、ライトニングネットワークは実際には数千万人のユーザーをサポートすることしかできず、グローバルな支払いシステムのビジョンを実現することができません。過剰に高い取引手数料に加えて、ビットコインは目指していた匿名性を実現することができなかったという別の問題があります。
サトシ・ナカモトは、サイファーパンクの電子メールディスカッショングループで、ビットコインにはプライバシー保護機能があり、トランザクションの開始者は完全に匿名にできると指摘しました。ただし、トランザクションイニシエーターはKYCを必要としませんが、ビットコインチェーン上のトランザクションデータは多くの情報を漏らし、ユーザーのプライバシーを大幅に公開します。上記の問題をある程度解決するプライバシー機能を備えたウォレットクライアントもありますが、これらのウォレットクライアントの開発者はさまざまなサイズの脅威に直面しています。例えば、2024年4月にSamourai CoinJoinウォレットの開発者がFBIに逮捕され、その1週間後にはWasabiウォレットの開発者がCoinJoinの調整コンポーネントをシャットダウンしました。明らかに、これらのいわゆるプライバシーウォレットは、ユーザーの信頼に完全に値するものではありません。
要約すると、ビットコインの多くの概念は今日までに実現されていないばかりか、関連する技術もまだ継続的な開発中です。それでも、ビットコインコミュニティの多くの人々は、ビットコインのプロトコル設計は変更されるべきではないと信じていますが、私のような多くの人々もビットコインの改善に情熱を持っています。では、ビットコインはどの方向に改善すべきでしょうか?
上記の問題に対応するため、ビットコインコミュニティには多くの提案があり、最も理論的な結果を出しているものはZKとSNARKsに関連しているはずです。ZKとSNARKsを使用すると、以下の機能が実現できます:
大幅に改善されたプライバシー:トランザクション金額に対してホモモーフィックペターソンコミットメントを使用し、ユーザープライバシーを大幅に向上させます(Blockstreamのエレメントサイドチェーンで行われているように)。トランザクションのトレースを隠すためにリンク可能な署名(Moneroなど)を使用し、真にプライベートなトランザクション(Zcashなど)を実現します。
トランザクションのスループットを向上させる
ビットコインの現在の問題を解決するためには、さまざまな技術的な解決策がありますが、なぜこれらの技術がビットコインプロトコルに統合されていないのでしょうか?その答えは、プロトコルの変更が困難であることにあります。イーサリアムのように、ビットコインにはイーサリアム財団のような中央集権的な組織がありません。プロトコルの変更には、コミュニティの合意が必要であり、広範な交渉と利益のバランスが求められます。その結果、イーサリアムは定期的にEVMオペコードを更新していますが、ビットコインのプロトコルは創設以来ほとんど変更されていません。
ある意味、プロトコルを変更することの困難さは有益です。変更が簡単に実装されれば、悪意のある改ざんや攻撃がより可能になるでしょう。これは問題を提起します: プロトコルを変更せずにビットコインのパフォーマンスを改善する方法は何ですか?
これに答えるために、Bitcoinの基本を再訪する必要があります。Bitcoinを他の誰かに転送する場合、トランザクションを作成し、Bitcoinネットワークにブロードキャストします。トランザクションの出力データは転送されるBTCの量を指定します。受信者は受け取ったBTCを使って新しいトランザクションを作成し、その過程で新しい出力データを生成することができます。
ビットコインには、特に口座の状態がないため、イーサリアムのようなグローバルな状態を持っていません。トランザクションの出力データしかありません。各トランザクションの出力には、受取人によって使用されたかどうかの2つの状態があります。未使用のトランザクション出力(UTXO)は私たちがよく知っているものです。関連するBTCの量に加えて、各トランザクション出力には、ビットコインスクリプトで書かれたスクリプトも添付されています。このスクリプトに正しい証拠(証人)を提供できる人がUTXOを使うことができます。
Bitcoin Scriptは、一連のオペコードを持つスタックベースのプログラミング言語です。UTXOに添付されたプログラムは、スタックを基に演算を行い、その結果を返します。一般的なBitcoinスクリプトは、Bitcoinの登場以来存在しています。たとえば、最も一般的なスクリプトは公開鍵とデジタル署名をチェックするオペコードで構成されています。このオペコードにより、UTXOを消費またはロックするためには、公開鍵に対応するデジタル署名を提供する必要があります。
おすすめの読み物:[BTCに接近中:BitVM(1)を理解するための背景知識]
ビットコインスクリプトの機能
ビットコインスクリプトの機能:
ビットコインスクリプトではできないこと:
ビットコインの初期バージョンでは、上記の「できない」機能の一部は可能でしたが、一部のオペコードは後に中本聡によってセキュリティの脆弱性のために無効化されました。例えば、2つのスタック要素を結合できるOP_CATオペコードは、ビットコインノードをリモートで攻撃しクラッシュを引き起こすために使用されました。中本聡はセキュリティ上の理由からOP_CATおよび他のオペコードを無効にしました。
ビットコインスクリプトはSNARKを検証できますか?理論的には、ビットコインスクリプトはチューリング完全ではありませんが、基本的な操作は任意の計算を検証するのに十分です。しかし、実際には、SNARKの検証は不可能です。なぜなら、検証手順に必要なプログラムサイズがBitcoinの最大ブロック制限である4MBを超えるからです。大きな有限体での算術演算を試みることもできますが、そのコストは非常に高くなります。例えば、BitVMでは、2つの254ビット整数を乗算すると、ほぼ8KBのBitcoinスクリプトサイズになります。さらに、OP_CATがない場合、Merkle証明を検証するコストも高くなります。なぜなら、これにはループに類似した操作が必要だからです。
なぜBitcoinプロトコルをより強力なオペコードを追加するように修正しないのですか?先述のように、新しいプロトコルルールについての過半数の合意を得ることは非常に困難です。Bitcoinには中央集権的な意思決定者が存在せず、Bitcoin Scriptを改善する提案にはさまざまな視点を持つ利害関係者からのかなりの反対があります。Bitcoinネットワークのコミュニティの合意を効果的に測定する方法はありませんし、それにないまま更新を強制するとチェーンの分割につながる可能性があります。もちろん、Bitcoinは完全に不変ではありません。最新のアップデートは2017年のSegWitと2021年のTaprootです。
多くのルールを変更したTaprootのアップグレードは、理論的なリリースから実際のアクティベーションまで3年半かかりました。Taprootを可能にする重要な要素は、既存のセキュリティの前提を変更せず、Bitcoinプロトコルに明確な改良をもたらしたことです。例えば、ECDSAの代わりにSchnorr署名の使用を許可しています。どちらも離散対数の仮定に基づき、同じ楕円曲線を使用していますが、前者の方が効率的で計算量も少なくなります。
さらに、Taprootのビットコインの改善は、次の3つの側面に分類できます。
まず、Taprootは多数の条件分岐を持つスクリプトの検証コストを削減し、Bitcoinがより複雑なプログラムをサポートできるようにします。
さらに、Taprootはチェーン上で公開されるスクリプトデータ量を減らし、複数のスクリプトプログラムをMerkleツリーに組み込むことができます。各スクリプトは異なる葉に配置されています。特定のスクリプトをトリガーする場合、それが配置されている葉とMerkleプルーフを公開するだけで済みます。
第三に、Taprootは他のメカニズムデザインも追加しました。
より高度な機能を統合するためのTaprootとのビットコインの前例を考えると、なぜSNARK検証専用のオペコードが導入されていないのか疑問に思うかもしれません。主な違いは、OP_SNARKに必要な複雑さとコンセンサスにあります。明確でわかりやすいデザインで幅広い支持を得たTaprootとは異なり、OP_SNARK提案は多岐にわたるため、単一のアプローチでコミュニティをまとめることは困難です。実装された場合、すべてのビットコインノードはこの特定のSNARK検証方法をサポートする必要があり、技術的な要求が大幅に増加します。さらに、OP_SNARK固有の複雑さは大きなハードルであり、Taprootはコミュニティの標準で管理可能な約1,600行のコードを追加しましたが、OP_SNARKははるかに複雑なコーディングを必要とします。さらに、OP_SNARKの活性化を誰が評価し、その複雑さを完全に理解している人がほとんどいないときにコンセンサスを得るかを決定することは、さらに困難になります。これらの課題を考えると、OP_SNARKアップグレードが近い将来に実現する可能性は低いでしょう。
しかし、Bitcoin ScriptでSNARKを検証する他の方法があります。より単純なオペコードを追加してBitcoinスクリプトをより機能的にすることで、SNARK検証プログラムをスクリプトに実装することができます。しかし、実際には、Bitcoinスクリプト言語でSNARK検証プログラムを書くことは非常に困難です。そのため、Blockstreamの研究チームは、Bitcoin Scriptを置き換えるために設計されたプログラミング言語であるSimplicityを開発しています。Simplicityは、ブロックチェーンのコンセンサスシステムに特化しており、故意にチューリング完全ではなく、静的解析と形式的検証が容易になっています。
Bitcoinのスクリプト機能を大幅に向上させる可能性がある、一見シンプルですが非常に影響力のある提案に注目しましょう:OP_CATオペコードの再活性化です。 OP_CATは、元々Bitcoinの初期のコードに含まれていましたが、特定の条件下でDoS攻撃を可能にする可能性があるため、後にSatoshi Nakamotoによって無効にされました。しかし、Bitcoinコミュニティ内での再導入に対する関心が高まっています。
OP_CATの機能はシンプルです。スタックからトップの2つの要素を取り、それらを連結し、その結果をスタックに戻します。これは基本的に見えるかもしれませんが、ビットコインのスクリプト言語において大幅な改善をもたらす可能性があります。たとえば、現在のビットコインのスクリプトは、特定のオンチェーン取引データ(例:関与した金額など)にアクセスできませんが、OP_CATを使用することでこの機能が導入されるかもしれません。さらに、OP_CATはMerkleプルーフの検証において重要な役割を果たす可能性があります。
実質的に、OP_CATは幅広い新機能につながる可能性がある低レベルのオペコードのアップグレードです。多くの人が指摘しているように、OP_CATはさまざまな目標の達成に重要な役割を果たす可能性があります。重要な問題は、OP_CATがスクリプト内でのSNARK検証に役立つかどうかです。答えはイエスです。Merkle証明検証はFRIベースのSNARKsの検証に向けた一歩であり、OP_CATは貴重な追加となります。過去に、SNARK検証用に設計されたスクリプトは、ビットコインのブロックサイズ制限に収まりきれないことがあったかもしれませんが、OP_CATはこれらのスクリプトを効率化し、よりコンパクトにするのに役立つかもしれません。
OP_CATは何年もの間話し合われており、トランザクションの内観における潜在的な役割への認識が高まっています。他の提案に比べてその主な利点の1つは、かつてビットコインスクリプトの一部であったことであり、これによりコミュニティの合意形成が容易になる可能性があります。しかし、デメリットとしては、OP_CATの有効化は一部のMEV(マイナー抽出可能価値)の利益に悪影響を及ぼす可能性があり、そのためコミュニティ内での再活性化についての議論が続いています。
要約すると、ビットコインは、OP_CATのような単純なオペコードを再導入することで、スクリプトでSNARK検証を可能にするための一歩を踏み出すことができます。さらに、乗算オペコードを再導入し、すべての算術演算を任意の精度で実行できるようにする「Great Script Restoration」と呼ばれる最近の提案についても言及する価値があります。
さらに、OP_CATがビットコインネットワークに与える影響を評価する際には、ビットコインノードオペレーターへの影響も考慮することが重要です。ビットコインが検閲耐性を持ち、分散化された状態を維持するために、コミュニティはできるだけ多くの人々にノードを運用してトランザクションを検証することを目指しています。もしビットコインがSNARK検証を導入する場合、ノードの運用コストは大幅に上昇せず、ビットコインのセキュリティや検閲耐性に大きな影響を与えません。
現在、ビットコインのブロックは最大4MBのデータを保持でき、新しいブロックはおおよそ10分ごとに採掘されます。ほとんどのブロックはビットコインのスクリプトとウィットネスデータ(デジタル署名に似たもの)で埋められています。平均して、各ブロックは7,000から10,000の署名検証を収容することができ、ブロックごとに最大約80,000の検証を行うことができます。2020年の私のIntel CPUでは、ビットコインのブロックの検証に約3.2秒かかります。もちろん、ブロックの検証速度は署名検証の時間だけでなく、他の要素にも影響を受けます。
さらに、もしビットコインの取引がいずれゼロ知識(ZK)証明をサポートするようになれば、取引生成時間の増加は重要な懸念事項ではないかもしれません。長期的な資産保管に使用されるハードウェアウォレットは通常、スクリーンとコンパクトなデザインを備え、キーストレージと署名作成に焦点を当てています。これらのウォレットは通常、240MHzのデュアルコアプロセッサなどの低消費電力のCPUを使用していますが、ビットコインの取引を効率的に処理します。
私はユーザーに小規模な調査を行い、署名デバイスがプルーフを生成するために許容できる最大の遅延について尋ねました。多くの人々は、特に大きな利益が得られる場合、長い待ち時間を許容することに問題はないと述べました。したがって、Bitcoin取引にZKを導入すると、ほとんど問題はないようです。Bitcoinの基本設計の潜在的な変更について多くの時間を費やしてきましたが、Bitcoin自体を変更することなく開発できるアプリケーションがたくさんあります。そのようなアプリケーションの1つとして、BitVMに関連するChain State Proofsがあります。このアプローチでは、ゼロ知識証明を使用してブロックハッシュの正確性を検証します。
この技術がビットコインに与える影響は何ですか?まず、チェーンステートプルーフはビットコインの過去のデータを同期および検証する際に関わる作業量を大幅に削減できます。これにより、ノードの運用コストが低下します。現在、ハイエンドデバイスではジェネシスブロックから最新ブロックまでのデータの同期および検証に約5時間30分かかり、Raspberry Piレベルのデバイスでは数日かかります。チェーンステートプルーフによって、このプロセスを大幅に短縮することができます。
Chain State ProofsはBitVMの進化において重要な役割を果たします。ZeroSyncチームはChain State Proofsを徹底的に研究し、“header chain Proofs”と呼ばれる簡素化されたバージョンを開発しました。この手法は、ゼロ知識証明を使用してBitcoinのブロックヘッダーを検証し、Bitcoinの歴史全体にわたる850,000個のブロックヘッダーを包括する“header chain”を作成します。各ブロックヘッダーは80バイトの証明を生成するためにハッシュ化されます。この手法では、関連する作業の証明を検証するために、各ヘッダーに対して2回のSHA-256計算が必要です。ZeroSyncはこれらのheader chain proofsを生成するためにSTARKsを利用し、製作コストは約$4,000かかりますが、ブラウザ上での検証は約3秒で行われます。
ただし、ヘッダーチェーンプルーフはブロック内のトランザクションを検証しないため、最もプルーフ・オブ・ワーク(PoW)を持つブロックチェーンが有効であると仮定するだけであり、Bitcoinクライアントがこのチェーンから最新のブロックを同期することに依存することになります。この設定では、攻撃者は理論的には無効なトランザクションを含むブロックを作成し、その後にさらにブロックを追加し、歴史的なデータを同期するクライアントを誤解させるために、ヘッダーチェーンプルーフを生成することができます。ただし、このような攻撃のコストは非常に高く、既存のBitcoinフルノードクライアントによって検出される可能性が高いです。
しかし、そのような攻撃が成功する可能性は低いですが、攻撃者が大量のBTCを盗むことができれば、ヘッダーチェーンの証明は完全に安全な解決策とは見なされません。チェーンの完全な状態を確認するには、ECDSAおよびsecp256k1楕円曲線に基づいたSchnorr署名の検証を含む、すべてのBitcoinブロックの内容が有効であることを確認する必要があります。Bitcoinの過去のブロックには、月ごとに約3000万の署名が含まれており、過去には約25億の署名と多数のSHA-256計算が存在します。その結果、Bitcoinネットワークは月間約7GBのブロックデータを生成し、過去のデータは650GBを超えています。実際には、この数値は2倍から3倍高くなる場合もあります。
BitVMではビットコインが任意の計算タスクを検証できるようになります。これにより、プロトコルの変更なしにSNARK検証を行う最適な方法を提供します。BitVMは、Bitcoinのスクリプトサイズの制限を2つの方法で克服します。まず、Taproot MerkleTreeスクリプト構造を活用します。次に、個々のスクリプト間でアクセスできるKVストレージスキームを使用し、多数のスクリプトプログラムへの接続を容易にします。ただし、BitcoinプロトコルはこのKVストレージスキームの整合性を強制しません。BitVMは、詐欺証明を使用して悪意のあるProverを検出します。Proverが無効な主張をしたり、誤ったKVストレージを使用したりした場合、他の人はBitcoinブロックチェーン上で取引を開始し、Proverの不正行為を報告し、Proverの賭けられた資産を没収することができます。
要約すると、ビットコインは重大な課題に取り組んでおり、これらに対処するためにさまざまな提案が提案されていますが、ビットコインコミュニティから急速に受け入れられる可能性は低いです。プロトコルの変更は、ビットコインの分散化とセキュリティの強みと制約の両方を反映して、短期的には達成できません。SNARKとSTARKの可能性は、コミュニティ内でかなりの興奮を生み出しています。BitVMは、中長期的にSNARK検証を統合するための最も有望な方法であるように思われますが、完全に実用化するにはさらなる研究開発が必要です。OP_CATオペコードを再度有効にすることも検討すべき方法ですが、再アクティブ化の利点がリスクを上回ることを実証し、ビットコインスクリプトでSNARK検証または同様の機能を容易にする単純なオペコードを特定する必要があります。最終的に、ビットコインコミュニティは、テクノロジーの実用性を高め、より実用的なユースケースをサポートすることを目指しています。
元のコンテンツはこちらを読んでください: https://www.youtube.com/watch?v=GrSCZmFuy7U
この記事では、BitcoinでZK検証を可能にする実用的な方法について掘り下げ、BitcoinのUTXOモデル、スクリプトの制限、Taproot、OP_CAT、BitVM、Chain State Proofsなどのトピックを取り上げています。BitcoinプロトコルへのZKの統合は避けられないという明確な議論を提供しています。2つの潜在的なルートが強調されています。1つはBitcoinスクリプトでSNARK検証を直接サポートするためにOP_CATオペコードを再導入することです。この変更は最終的に承認される可能性が非常に高いです。2つ目のアプローチは、詐欺証明を組み込んだBitVMに関連しています。さらに、ZeroSyncチームのChain State Proofsに関する提案は、ノードクライアントが歴史的データを検証するコストを削減することを目的としています。
メインテキスト:ビットコインを完全に理解するには、それを社会システムとして見ることが役立ちます。ビットコインの創造者たちは、初期にノードが実行する必要があるソフトウェアを定義し、社会を統治するルールを確立するのと同様にしました。ビットコインの安定性は、その基本的な性質に関する幅広い合意に依存しており、これについての質問が生じます。「ビットコインとは本質的に何か?」や「ビットコインはどのように進化すべきか?」しかし、これらの質問についての合意に達することは悪名高く難しいものであり、意見は大幅に異なり、絶えず進化しています。
これはビットコインの歴史的な起源にさかのぼります。サトシ・ナカモトがビットコインの白書を公開したとき、彼は「私は全く新しい電子決済システムに取り組んでいます。このシステムは完全にP2Pであり、どの第三者にも依存する必要がありません。」と述べました。このパッセージはCypherpunksメーリングリスト(1992年に設立された暗号学者や技術愛好家からなるメールディスカッショングループで、プライバシー保護や暗号技術に関心のある人々が参加しています)で公開されました。
ただし、ビットコインは製品設計レベルでデータスループットを制限しています。単位時間あたりに処理できる取引数には限りがあります。取引処理件数が急速に増加すると、ユーザーは取引を迅速に完了させるために価格競争を開始し、支払われる取引手数料を急速に増加させます。ビットコインネットワークで最も高い取引手数料が発生したのは、2024年にブロック報酬が半減した後であり、チェーン上の優先度が中程度の取引の手数料が150ドルに達しました。ビットコインネットワークの高額な取引手数料は問題となっています。
取引手数料の問題を解決するために、人々は大量のリソースをライトニングネットワークの開発に投資してきました。しかし、2016年に発表された論文によると、ライトニングネットワークは実際には数千万人のユーザーをサポートすることしかできず、グローバルな支払いシステムのビジョンを実現することができません。過剰に高い取引手数料に加えて、ビットコインは目指していた匿名性を実現することができなかったという別の問題があります。
サトシ・ナカモトは、サイファーパンクの電子メールディスカッショングループで、ビットコインにはプライバシー保護機能があり、トランザクションの開始者は完全に匿名にできると指摘しました。ただし、トランザクションイニシエーターはKYCを必要としませんが、ビットコインチェーン上のトランザクションデータは多くの情報を漏らし、ユーザーのプライバシーを大幅に公開します。上記の問題をある程度解決するプライバシー機能を備えたウォレットクライアントもありますが、これらのウォレットクライアントの開発者はさまざまなサイズの脅威に直面しています。例えば、2024年4月にSamourai CoinJoinウォレットの開発者がFBIに逮捕され、その1週間後にはWasabiウォレットの開発者がCoinJoinの調整コンポーネントをシャットダウンしました。明らかに、これらのいわゆるプライバシーウォレットは、ユーザーの信頼に完全に値するものではありません。
要約すると、ビットコインの多くの概念は今日までに実現されていないばかりか、関連する技術もまだ継続的な開発中です。それでも、ビットコインコミュニティの多くの人々は、ビットコインのプロトコル設計は変更されるべきではないと信じていますが、私のような多くの人々もビットコインの改善に情熱を持っています。では、ビットコインはどの方向に改善すべきでしょうか?
上記の問題に対応するため、ビットコインコミュニティには多くの提案があり、最も理論的な結果を出しているものはZKとSNARKsに関連しているはずです。ZKとSNARKsを使用すると、以下の機能が実現できます:
大幅に改善されたプライバシー:トランザクション金額に対してホモモーフィックペターソンコミットメントを使用し、ユーザープライバシーを大幅に向上させます(Blockstreamのエレメントサイドチェーンで行われているように)。トランザクションのトレースを隠すためにリンク可能な署名(Moneroなど)を使用し、真にプライベートなトランザクション(Zcashなど)を実現します。
トランザクションのスループットを向上させる
ビットコインの現在の問題を解決するためには、さまざまな技術的な解決策がありますが、なぜこれらの技術がビットコインプロトコルに統合されていないのでしょうか?その答えは、プロトコルの変更が困難であることにあります。イーサリアムのように、ビットコインにはイーサリアム財団のような中央集権的な組織がありません。プロトコルの変更には、コミュニティの合意が必要であり、広範な交渉と利益のバランスが求められます。その結果、イーサリアムは定期的にEVMオペコードを更新していますが、ビットコインのプロトコルは創設以来ほとんど変更されていません。
ある意味、プロトコルを変更することの困難さは有益です。変更が簡単に実装されれば、悪意のある改ざんや攻撃がより可能になるでしょう。これは問題を提起します: プロトコルを変更せずにビットコインのパフォーマンスを改善する方法は何ですか?
これに答えるために、Bitcoinの基本を再訪する必要があります。Bitcoinを他の誰かに転送する場合、トランザクションを作成し、Bitcoinネットワークにブロードキャストします。トランザクションの出力データは転送されるBTCの量を指定します。受信者は受け取ったBTCを使って新しいトランザクションを作成し、その過程で新しい出力データを生成することができます。
ビットコインには、特に口座の状態がないため、イーサリアムのようなグローバルな状態を持っていません。トランザクションの出力データしかありません。各トランザクションの出力には、受取人によって使用されたかどうかの2つの状態があります。未使用のトランザクション出力(UTXO)は私たちがよく知っているものです。関連するBTCの量に加えて、各トランザクション出力には、ビットコインスクリプトで書かれたスクリプトも添付されています。このスクリプトに正しい証拠(証人)を提供できる人がUTXOを使うことができます。
Bitcoin Scriptは、一連のオペコードを持つスタックベースのプログラミング言語です。UTXOに添付されたプログラムは、スタックを基に演算を行い、その結果を返します。一般的なBitcoinスクリプトは、Bitcoinの登場以来存在しています。たとえば、最も一般的なスクリプトは公開鍵とデジタル署名をチェックするオペコードで構成されています。このオペコードにより、UTXOを消費またはロックするためには、公開鍵に対応するデジタル署名を提供する必要があります。
おすすめの読み物:[BTCに接近中:BitVM(1)を理解するための背景知識]
ビットコインスクリプトの機能
ビットコインスクリプトの機能:
ビットコインスクリプトではできないこと:
ビットコインの初期バージョンでは、上記の「できない」機能の一部は可能でしたが、一部のオペコードは後に中本聡によってセキュリティの脆弱性のために無効化されました。例えば、2つのスタック要素を結合できるOP_CATオペコードは、ビットコインノードをリモートで攻撃しクラッシュを引き起こすために使用されました。中本聡はセキュリティ上の理由からOP_CATおよび他のオペコードを無効にしました。
ビットコインスクリプトはSNARKを検証できますか?理論的には、ビットコインスクリプトはチューリング完全ではありませんが、基本的な操作は任意の計算を検証するのに十分です。しかし、実際には、SNARKの検証は不可能です。なぜなら、検証手順に必要なプログラムサイズがBitcoinの最大ブロック制限である4MBを超えるからです。大きな有限体での算術演算を試みることもできますが、そのコストは非常に高くなります。例えば、BitVMでは、2つの254ビット整数を乗算すると、ほぼ8KBのBitcoinスクリプトサイズになります。さらに、OP_CATがない場合、Merkle証明を検証するコストも高くなります。なぜなら、これにはループに類似した操作が必要だからです。
なぜBitcoinプロトコルをより強力なオペコードを追加するように修正しないのですか?先述のように、新しいプロトコルルールについての過半数の合意を得ることは非常に困難です。Bitcoinには中央集権的な意思決定者が存在せず、Bitcoin Scriptを改善する提案にはさまざまな視点を持つ利害関係者からのかなりの反対があります。Bitcoinネットワークのコミュニティの合意を効果的に測定する方法はありませんし、それにないまま更新を強制するとチェーンの分割につながる可能性があります。もちろん、Bitcoinは完全に不変ではありません。最新のアップデートは2017年のSegWitと2021年のTaprootです。
多くのルールを変更したTaprootのアップグレードは、理論的なリリースから実際のアクティベーションまで3年半かかりました。Taprootを可能にする重要な要素は、既存のセキュリティの前提を変更せず、Bitcoinプロトコルに明確な改良をもたらしたことです。例えば、ECDSAの代わりにSchnorr署名の使用を許可しています。どちらも離散対数の仮定に基づき、同じ楕円曲線を使用していますが、前者の方が効率的で計算量も少なくなります。
さらに、Taprootのビットコインの改善は、次の3つの側面に分類できます。
まず、Taprootは多数の条件分岐を持つスクリプトの検証コストを削減し、Bitcoinがより複雑なプログラムをサポートできるようにします。
さらに、Taprootはチェーン上で公開されるスクリプトデータ量を減らし、複数のスクリプトプログラムをMerkleツリーに組み込むことができます。各スクリプトは異なる葉に配置されています。特定のスクリプトをトリガーする場合、それが配置されている葉とMerkleプルーフを公開するだけで済みます。
第三に、Taprootは他のメカニズムデザインも追加しました。
より高度な機能を統合するためのTaprootとのビットコインの前例を考えると、なぜSNARK検証専用のオペコードが導入されていないのか疑問に思うかもしれません。主な違いは、OP_SNARKに必要な複雑さとコンセンサスにあります。明確でわかりやすいデザインで幅広い支持を得たTaprootとは異なり、OP_SNARK提案は多岐にわたるため、単一のアプローチでコミュニティをまとめることは困難です。実装された場合、すべてのビットコインノードはこの特定のSNARK検証方法をサポートする必要があり、技術的な要求が大幅に増加します。さらに、OP_SNARK固有の複雑さは大きなハードルであり、Taprootはコミュニティの標準で管理可能な約1,600行のコードを追加しましたが、OP_SNARKははるかに複雑なコーディングを必要とします。さらに、OP_SNARKの活性化を誰が評価し、その複雑さを完全に理解している人がほとんどいないときにコンセンサスを得るかを決定することは、さらに困難になります。これらの課題を考えると、OP_SNARKアップグレードが近い将来に実現する可能性は低いでしょう。
しかし、Bitcoin ScriptでSNARKを検証する他の方法があります。より単純なオペコードを追加してBitcoinスクリプトをより機能的にすることで、SNARK検証プログラムをスクリプトに実装することができます。しかし、実際には、Bitcoinスクリプト言語でSNARK検証プログラムを書くことは非常に困難です。そのため、Blockstreamの研究チームは、Bitcoin Scriptを置き換えるために設計されたプログラミング言語であるSimplicityを開発しています。Simplicityは、ブロックチェーンのコンセンサスシステムに特化しており、故意にチューリング完全ではなく、静的解析と形式的検証が容易になっています。
Bitcoinのスクリプト機能を大幅に向上させる可能性がある、一見シンプルですが非常に影響力のある提案に注目しましょう:OP_CATオペコードの再活性化です。 OP_CATは、元々Bitcoinの初期のコードに含まれていましたが、特定の条件下でDoS攻撃を可能にする可能性があるため、後にSatoshi Nakamotoによって無効にされました。しかし、Bitcoinコミュニティ内での再導入に対する関心が高まっています。
OP_CATの機能はシンプルです。スタックからトップの2つの要素を取り、それらを連結し、その結果をスタックに戻します。これは基本的に見えるかもしれませんが、ビットコインのスクリプト言語において大幅な改善をもたらす可能性があります。たとえば、現在のビットコインのスクリプトは、特定のオンチェーン取引データ(例:関与した金額など)にアクセスできませんが、OP_CATを使用することでこの機能が導入されるかもしれません。さらに、OP_CATはMerkleプルーフの検証において重要な役割を果たす可能性があります。
実質的に、OP_CATは幅広い新機能につながる可能性がある低レベルのオペコードのアップグレードです。多くの人が指摘しているように、OP_CATはさまざまな目標の達成に重要な役割を果たす可能性があります。重要な問題は、OP_CATがスクリプト内でのSNARK検証に役立つかどうかです。答えはイエスです。Merkle証明検証はFRIベースのSNARKsの検証に向けた一歩であり、OP_CATは貴重な追加となります。過去に、SNARK検証用に設計されたスクリプトは、ビットコインのブロックサイズ制限に収まりきれないことがあったかもしれませんが、OP_CATはこれらのスクリプトを効率化し、よりコンパクトにするのに役立つかもしれません。
OP_CATは何年もの間話し合われており、トランザクションの内観における潜在的な役割への認識が高まっています。他の提案に比べてその主な利点の1つは、かつてビットコインスクリプトの一部であったことであり、これによりコミュニティの合意形成が容易になる可能性があります。しかし、デメリットとしては、OP_CATの有効化は一部のMEV(マイナー抽出可能価値)の利益に悪影響を及ぼす可能性があり、そのためコミュニティ内での再活性化についての議論が続いています。
要約すると、ビットコインは、OP_CATのような単純なオペコードを再導入することで、スクリプトでSNARK検証を可能にするための一歩を踏み出すことができます。さらに、乗算オペコードを再導入し、すべての算術演算を任意の精度で実行できるようにする「Great Script Restoration」と呼ばれる最近の提案についても言及する価値があります。
さらに、OP_CATがビットコインネットワークに与える影響を評価する際には、ビットコインノードオペレーターへの影響も考慮することが重要です。ビットコインが検閲耐性を持ち、分散化された状態を維持するために、コミュニティはできるだけ多くの人々にノードを運用してトランザクションを検証することを目指しています。もしビットコインがSNARK検証を導入する場合、ノードの運用コストは大幅に上昇せず、ビットコインのセキュリティや検閲耐性に大きな影響を与えません。
現在、ビットコインのブロックは最大4MBのデータを保持でき、新しいブロックはおおよそ10分ごとに採掘されます。ほとんどのブロックはビットコインのスクリプトとウィットネスデータ(デジタル署名に似たもの)で埋められています。平均して、各ブロックは7,000から10,000の署名検証を収容することができ、ブロックごとに最大約80,000の検証を行うことができます。2020年の私のIntel CPUでは、ビットコインのブロックの検証に約3.2秒かかります。もちろん、ブロックの検証速度は署名検証の時間だけでなく、他の要素にも影響を受けます。
さらに、もしビットコインの取引がいずれゼロ知識(ZK)証明をサポートするようになれば、取引生成時間の増加は重要な懸念事項ではないかもしれません。長期的な資産保管に使用されるハードウェアウォレットは通常、スクリーンとコンパクトなデザインを備え、キーストレージと署名作成に焦点を当てています。これらのウォレットは通常、240MHzのデュアルコアプロセッサなどの低消費電力のCPUを使用していますが、ビットコインの取引を効率的に処理します。
私はユーザーに小規模な調査を行い、署名デバイスがプルーフを生成するために許容できる最大の遅延について尋ねました。多くの人々は、特に大きな利益が得られる場合、長い待ち時間を許容することに問題はないと述べました。したがって、Bitcoin取引にZKを導入すると、ほとんど問題はないようです。Bitcoinの基本設計の潜在的な変更について多くの時間を費やしてきましたが、Bitcoin自体を変更することなく開発できるアプリケーションがたくさんあります。そのようなアプリケーションの1つとして、BitVMに関連するChain State Proofsがあります。このアプローチでは、ゼロ知識証明を使用してブロックハッシュの正確性を検証します。
この技術がビットコインに与える影響は何ですか?まず、チェーンステートプルーフはビットコインの過去のデータを同期および検証する際に関わる作業量を大幅に削減できます。これにより、ノードの運用コストが低下します。現在、ハイエンドデバイスではジェネシスブロックから最新ブロックまでのデータの同期および検証に約5時間30分かかり、Raspberry Piレベルのデバイスでは数日かかります。チェーンステートプルーフによって、このプロセスを大幅に短縮することができます。
Chain State ProofsはBitVMの進化において重要な役割を果たします。ZeroSyncチームはChain State Proofsを徹底的に研究し、“header chain Proofs”と呼ばれる簡素化されたバージョンを開発しました。この手法は、ゼロ知識証明を使用してBitcoinのブロックヘッダーを検証し、Bitcoinの歴史全体にわたる850,000個のブロックヘッダーを包括する“header chain”を作成します。各ブロックヘッダーは80バイトの証明を生成するためにハッシュ化されます。この手法では、関連する作業の証明を検証するために、各ヘッダーに対して2回のSHA-256計算が必要です。ZeroSyncはこれらのheader chain proofsを生成するためにSTARKsを利用し、製作コストは約$4,000かかりますが、ブラウザ上での検証は約3秒で行われます。
ただし、ヘッダーチェーンプルーフはブロック内のトランザクションを検証しないため、最もプルーフ・オブ・ワーク(PoW)を持つブロックチェーンが有効であると仮定するだけであり、Bitcoinクライアントがこのチェーンから最新のブロックを同期することに依存することになります。この設定では、攻撃者は理論的には無効なトランザクションを含むブロックを作成し、その後にさらにブロックを追加し、歴史的なデータを同期するクライアントを誤解させるために、ヘッダーチェーンプルーフを生成することができます。ただし、このような攻撃のコストは非常に高く、既存のBitcoinフルノードクライアントによって検出される可能性が高いです。
しかし、そのような攻撃が成功する可能性は低いですが、攻撃者が大量のBTCを盗むことができれば、ヘッダーチェーンの証明は完全に安全な解決策とは見なされません。チェーンの完全な状態を確認するには、ECDSAおよびsecp256k1楕円曲線に基づいたSchnorr署名の検証を含む、すべてのBitcoinブロックの内容が有効であることを確認する必要があります。Bitcoinの過去のブロックには、月ごとに約3000万の署名が含まれており、過去には約25億の署名と多数のSHA-256計算が存在します。その結果、Bitcoinネットワークは月間約7GBのブロックデータを生成し、過去のデータは650GBを超えています。実際には、この数値は2倍から3倍高くなる場合もあります。
BitVMではビットコインが任意の計算タスクを検証できるようになります。これにより、プロトコルの変更なしにSNARK検証を行う最適な方法を提供します。BitVMは、Bitcoinのスクリプトサイズの制限を2つの方法で克服します。まず、Taproot MerkleTreeスクリプト構造を活用します。次に、個々のスクリプト間でアクセスできるKVストレージスキームを使用し、多数のスクリプトプログラムへの接続を容易にします。ただし、BitcoinプロトコルはこのKVストレージスキームの整合性を強制しません。BitVMは、詐欺証明を使用して悪意のあるProverを検出します。Proverが無効な主張をしたり、誤ったKVストレージを使用したりした場合、他の人はBitcoinブロックチェーン上で取引を開始し、Proverの不正行為を報告し、Proverの賭けられた資産を没収することができます。
要約すると、ビットコインは重大な課題に取り組んでおり、これらに対処するためにさまざまな提案が提案されていますが、ビットコインコミュニティから急速に受け入れられる可能性は低いです。プロトコルの変更は、ビットコインの分散化とセキュリティの強みと制約の両方を反映して、短期的には達成できません。SNARKとSTARKの可能性は、コミュニティ内でかなりの興奮を生み出しています。BitVMは、中長期的にSNARK検証を統合するための最も有望な方法であるように思われますが、完全に実用化するにはさらなる研究開発が必要です。OP_CATオペコードを再度有効にすることも検討すべき方法ですが、再アクティブ化の利点がリスクを上回ることを実証し、ビットコインスクリプトでSNARK検証または同様の機能を容易にする単純なオペコードを特定する必要があります。最終的に、ビットコインコミュニティは、テクノロジーの実用性を高め、より実用的なユースケースをサポートすることを目指しています。
元のコンテンツはこちらを読んでください: https://www.youtube.com/watch?v=GrSCZmFuy7U