ビットコインにZKをサポートさせる方法：OP_CATから状態証明とBitVMへ

ビットコインプロトコルへのZKの導入は避けられない傾向であり、これに対して取るべきルートは2つあります：1つは、最終的に高い確率でパスするOP_CATオペコードの助けを借りて、ビットコインスクリプトにSNARK検証を直接サポートさせることです。2つ目のルートはBitVMに基づいており、不正証明の導入が必要です。また、ZeroSyncチームは、過去のデータのノードクライアント検証のコストを削減するために、Chain State Proofsもターゲットにしています。strong>ビットコインをより深く理解するためには、社会システムとして考えるのが一番です。ビットコインの立ち上げの初期に、開発者はビットコインノードが実行する必要のあるソフトウェアプログラムを特定しましたが、これは社会システムが従うべき一連のルールを特定するのとよく似ています。社会システムとしてのビットコインが安定しているのは、「ビットコインとは何か」「ビットコインはどうあるべきか」という重要な疑問について、ある程度のコンセンサスが得られているからに他ならない。もちろん、コンセンサスに達するのは容易ではなく、これらの問題については、いまだに幅広い意見の相違があり、発展している。

これは、ビットコインの歴史的起源に関する問題にまで遡ることができます。サトシ・ナカモトが当初ビットコインのホワイトペーパーを発表したとき、彼はこう言った。"私は完全にP2Pで、いかなる第三者にも依存しない、まったく新しい電子決済システムに取り組んでいる"。この引用は、クリプトパンク・メーリングリスト（プライバシー保護と暗号技術に関心を持つ暗号学者や技術愛好家のグループによって1992年に設立された電子メール・ディスカッション・グループ）に掲載された。

しかし、ビットコインは製品設計レベルでデータスループットを制限している。単位時間あたりに処理できるトランザクションの数には制限があり、処理すべきトランザクションの数が急速に増えれば、ユーザーは急ぐために価格競争を始め、支払う手数料をすぐに吊り上げてしまう。ビットコインネットワーク内の単一トランザクションに対する最高手数料は、ブロックアウト報酬が半減した後の2024年に発生し、オンチェーン優先度が中程度のトランザクションに対する手数料は150ドルだった。ビットコインネットワークの高額な取引手数料が問題になっていると言っていいだろう。

取引手数料の問題を解決するために、ライトニングネットワークの開発には多くのリソースが投入されてきた。しかし、2016年に発表された論文によると、ライトニング・ネットワークは実際にはせいぜい数千万人のユーザーしかサポートできず、世界的な決済システムというビジョンを実現することはできない。

取引手数料が高すぎるという事実のほかに、ビットコインがそのビジョンで実現したかった匿名性を実現できていないという問題もあった。サトシ・ナカモトは、暗号パンクの電子メール・ディスカッション・グループで、ビットコインはプライバシーを保護しており、取引の開始者は完全に匿名にすることができると指摘した。しかし、KYCは取引開始者には必要ないが、ビットコインチェーン上の取引データは多くの情報を漏らし、ユーザーのプライバシーを大きく暴露する。

上記の問題にある程度対処するプライバシー機能を備えたウォレットクライアントがある一方で、これらのウォレットクライアントの開発者は大小の脅威に直面している。例えば、Samourai CoinJoinウォレットの開発者は2024年4月にFBIに逮捕され、その1週間後にはWasabiウォレットの開発者がCoinJoin連携コンポーネントを停止した。明らかに、これらのいわゆるプライバシーウォレットはユーザーにとって信頼できるものではありません。

結論から言うと、ビットコインのアイデアの多くは今日に至るまで実現には程遠く、技術は進化し続けている。それでも、ビットコインコミュニティの多くは、ビットコインのプロトコルの設計は変更されるべきではないと考えているが、私のようにビットコインの改良に熱心な者も多い。では、ビットコインはどのような方向に改善されるべきなのでしょうか？

上記の質問に対して、ビットコインコミュニティには多くの提案がありますが、理論的に最もうまくいくのはZKとSNARKに関するものです。ZKとSNARKを使用することで、以下の機能を実現することができます：

1.プライバシーの大幅な改善：ホモモーフィック・ピーターソンの使用は、取引金額と範囲証明に関してユーザーのプライバシーを大幅に改善することを約束します（BlockstreamのElementサイドチェーンで行われているように）、リンク可能な署名によるトランザクションの痕跡の隠蔽（Moneroなど）、そして真にプライベートなトランザクションの実現（Zcashなど）。

2.トランザクションのスループットを向上させる

実際、ビットコインに存在する問題に対する技術的解決策はたくさんあります。ビットコインの問題に対する技術的解決策はたくさんありますが、なぜ今日までビットコインのプロトコルに追加されなかったのでしょうか？それは、ビットコインのプロトコルを変更することが非常に難しいからです。ビットコインのエコシステムにはイーサ財団のような組織はなく、プロトコルの変更には高度なコミュニティのコンセンサスが必要で、これには多くのゲームとチェックアンドバランスが含まれます。そのため、EVMのオペコードが毎年更新されるイーサとは異なり、ビットコインのプロトコルは設立以来ほとんど変更されていません。

実際、プロトコルを変更するのが難しいという事実は、ある意味良いことでもあります。プロトコルの設計を変えることなくビットコインのパフォーマンスを向上させるには、どのような方法があるのでしょうか？

この疑問に答えるために。ビットコインについて知っていることを復習することから始めます。ビットコインを誰かに送金したい場合、まずビットコインネットワークにブロードキャストされるトランザクションを作成する必要があります。トランザクションの出力データには送金されたBTCの金額が記載され、BTCの受取人は受け取ったBTCを使用するために新しいトランザクションを作成することができます。

ここで重要なのは、ビットコインにはイーサリアムのようなグローバルな状態はなく、特にアカウントがない場合、トランザクションの出力データしかないということです。各トランザクションの出力には2つの状態があります：受信者によって使用されたか、または未使用です。未使用の取引出力は、おなじみのUTXOです。

もちろん、関連するBTCの量に加えて、各取引出力にはビットコインスクリプトと呼ばれる言語でのプログラミングが追加されています。このプログラミング部分に正しい証明証人を提示できる人は誰でも、その取引出力（UTXO）を使うことができます。ビットコインスクリプト自体は、一連のオペコードを含むスタックベースのプログラミング言語であり、前述のUTXOのためのアドオンプログラムは、多くの場合、スタックに基づいて計算を完了し、結果をスタックに戻す複数のオペコードで構成されています。

ビットコインの初期からある一般的なビットコインスクリプトには多くの種類があります。例として、ビットコインで最も一般的なスクリプト手順は、公開鍵＋デジタル署名をチェックするオペコードで構成されています。オペコードは、特定のUTXOを使用/ロック解除するには、公開鍵に対応するデジタル署名を提示する必要があることを示します。

推奨図書：「BTCへのアプローチ：BitVMを理解するために必要な背景知識（1）」

ここで、ビットコイン・スクリプティングが何をするのかをまとめてみます。まず、ビットコインスクリプトは何ができるのでしょうか？

• スタックを並べ替えたり、方程式チェック（特定の条件が満たされていることを検証するために使用される。）はif-elseのような分岐操作を実行できる。

• 32ビット数に対して、足し算や引き算など、限られた数の算術演算を実行できます。

• データをハッシュ化し、ECDSAやシュナー署名をチェックすることができます。

ビットコインスクリプトは何ができないのか？

• ループ、ジャンプ、再帰、つまりチューリング完全でない、非常に限られたプログラミング能力しかありません。

• ビット単位の演算はありません。

• 乗算と除算を実行するオペコードを欠いています。

• スタック上の要素を連結できません。

• チェーン上のトランザクションデータを読み取り、検査する機能はほとんどありません。ビットコインスクリプトは各トランザクションの量に直接アクセスすることができず、状態を引き継ぐ方法もありません（UTXOはすべて1回限りの使用で、各転送は新しいものを生成するために古いものを破棄します）。

ビットコインの初期バージョンでは、上記のスクリプトが「できなかった」ことのいくつかは実際にできましたが、機能の一部は後にサトシ・ナカモトによって無効にされました。サトシ・ナカモトはこれらのオペコードに脆弱性を発見した。例えば、スタックの2つの要素をマージするオペコードOP_CATは、ビットコインノードをリモートで攻撃し、クラッシュさせるために使用することができ、サトシ・ナカモトは用心深さからこれを無効にし、他の多くのオペコードも無効にしました。

では、ビットコインスクリプトはSNARKを検証できるのでしょうか

理論的には、ビットコインスクリプトはチューリング完全ではありませんが、ビットコインスクリプトの基本操作はあらゆる計算を検証するのに十分です。

おそらく、大きな有限領域で算術演算を実行しようとすることもできますが、BitVMによって実装された2つの254ビット整数の乗算の場合のように、非常にコストがかかります。

また、OP_CATなしでMerkle証明を検証することも、for-loopのような操作を必要とするため、非常にコストがかかります。

そこで前の質問に戻ります。なぜビットコインのプロトコルを変更するだけで、より強力なオペコードを追加できないのでしょうか？

前述したように、ビットコインエコシステムには中央集権的な意思決定者がいないため、新しいプロトコルルールで多数決のコンセンサスを得るのは非常に難しく、ビットコインスクリプトに提案された改善案には多くの反対意見があり、、みんなの立場や視点は異なります、視点が異なります。ビットコインのネットワークでは、コミュニティが多数派のコンセンサスに達したかどうかを測定する良い方法はなく、そのような状況でアップデートを強制すると、チェーンフォークにつながる可能性があります。

もちろん、ビットコインは正確に決まっているわけではなく、最近のアップデートは2017年のSegWitと2021年のTaproot

です。

Taprootアップデートは非常に多くのルールを変更したため、理論的なリリースから実際に現場で有効化されるまで3年半かかりました。主な要因は、既存のセキュリティの前提を変更せず、ビットコインのプロトコルに大幅な改良を加えたことだ。どちらも離散対数の仮定に基づいており、同じ楕円曲線を使用するが、前者は後者よりも効率的で計算量が少ない。

さらに、ビットコインに対するTaprootの改良は、主に3つの部分に分類されます：

第1に、Taprootは、多数のオプション分岐を持つスクリプトの検証コストを削減します。第一に、Taprootは多数の選択枝を持つスクリプトの検証コストを削減し、ビットコインがより複雑な処理をサポートできるようにします;

第二に、Taprootはチェーン上で明らかにする必要があるスクリプトデータの量を削減します。証明;

第三に、Taprootは設計に他のメカニズムを追加します。

つまり、ビットコインにはTarpootのような付加価値があるので、ビットコインにはTaprootと同じメカニズムを使用する能力があります。コインにはTarpootのようなより強力な機能を追加する前例があるのだから、SNARKを検証するための専用のオペコードを追加してはどうだろうか？これは、いわゆるOP_SNARKオペコードを追加することは、Taprootのアップグレードとは大きく異なるからです。

第一に、OP_SNARKには非常に多くの設計案があるため、1つのスキームを支持する多数派を得るのは難しいでしょうし、第二に、この種の提案が通れば、すべてのビットコインノードがその特定のOP_SNARKスキームをサポートしなければならなくなり、大きな技術的負担が増えます。

さらに、OP_SNARK自体の複雑さも小さな課題ではありません。テストを除くと、Taprootは約1,600行のコードしか追加しておらず、これは許容範囲内ですが、OP_SNARKは比較にならないほど複雑なコードを含んでいます。

それから、OP_SNARKオペコードをアクティブにすべきかどうかを誰がレビューするのでしょうか？ビットコインのエコシステム内で、その詳細を理解している人が数人いない状態で、どうやってコンセンサスを得るのでしょうか？これらはすべて疑問です。つまり、要約すると、OP_SNARKのアップグレードはすぐには起こらないということです。

しかし、他にもあります。BitcoinスクリプトでSNARKを検証する方法は他にもあり、Bitcoinスクリプトをより強力なものにするためによりシンプルなオペコードを追加し、人々がスクリプトにSNARKバリデーターを実装できるようにすることもできます。しかし、ビットコインのスクリプト言語でSNARKバリデーターを書くのは非常に難しいという事実があります。

そこで、Blockstreamの研究チームは、Bitcoinスクリプトを置き換えるために設計されたプログラミング言語であるSimplicityを開発しています。解析と形式的検証が容易なように設計されています。

以下では、非常にシンプルだがヘビー級の提案についてお話しします。OP_CATオペコードです。前述したように、OP_CATはBitcoinのオリジナルバージョンに存在しましたが、特定の条件下でBitcoinノードがDOS攻撃されることを可能にするこのオペコードは、サトシ・ナカモトによって無効化されました。

OP_CATの機能は、スタックの一番上にある2つの要素をポップし、それらを接続し、スタックに戻すことです。これは非常に単純に聞こえますが、ビットコインのスクリプティングに大きな機能的改善をもたらします。

たとえば、ビットコインスクリプトは、オンチェーン取引の金額などのステータス情報にアクセスすることはできませんが、OP_CATを使用すればこれが可能になります。要するに、OP_CATは基礎となるオペコードのレベルでのアップグレードであり、それによって多くの新機能が生まれる。

また、OP_CATはスクリプトでSNARKを検証するのに役立ちますか?

OP_CATは過去何年も議論されており、取引検査におけるその役割を認識する人が増えています。他の提案に対するOP_CATの利点は、以前からビットコインのスクリプトに存在していたため、コミュニティのコンセンサスを得やすいことだ。しかし、OP_CATが有効化されると、一部の人々のMEV利益が損なわれる可能性もあるため、ビットコインコミュニティはまだコンセンサスに達していない。

まとめると、ビットコインには、OP_CATのような単純なオペコードを有効にすることで、ビットコインスクリプトでSNARKを検証できるようにする潜在的な道があるかもしれません。"Great Script Restoration "と呼ばれる最近のイニシアチブがあり、乗算のオペコードを可能にし、すべての算術オペコードが任意の精度で操作できるようになっていることも注目に値します。

さらに、OP_CATのビットコイン ネットワークへの影響を検討すると、次のようになります。コインネットワークでは、通過後のビットコインノードランナーへの影響を調べることができます。ビットコインが検閲に強く分散型であるためには、ビットコインコミュニティはできるだけ多くの人がノードを実行してデータを検証することを望んでいます。ビットコインがSNARK検証作業をサポートした場合、ビットコインノードを実行するコストはまだ大幅に増加することはなく、ビットコインのセキュリティと検閲耐性にはほとんど害はないでしょう。

現在、ビットコインの1ブロックは最大4MBのデータを含むことができ、10分ごとに1ブロックが採掘されると予想されるため、そのほぼすべてをビットコインのスクリプトと証人（デジタル署名に似ている）で埋めることができます。その内訳は、各ブロックは現在最大80Kの署名検証を含むことができ、1ブロックあたり平均7Kから10Kの署名検証をサポートし、私の2020年のIntel CPUはビットコインブロックを検証するのに平均3.2秒かかります。もちろん、ブロック検証のスピードに影響するのは署名検証時間だけではありません。

さらに、ビットコイン取引の当日以降にZKingがサポートされる場合、結果として取引生成時間が延びても支障はないようです。資産を長期間保管するために使用されるハードウェアウォレットについては、画面があり、あまり大きくない傾向があり、その機能は鍵を保管し、署名を生成することです。ハードウェアウォレットは通常、240MHzのデュアルコアCPUと若干のメモリといった弱いCPUを搭載しており、ビットコイン取引に署名する際には非常に反応が速い。

私は小規模な調査を行い、署名デバイスがビットコイン取引に署名するまでの最長の遅延時間としてユーザーが受け入れられるものを尋ねました。署名デバイスが証明を生成するための最長の遅延時間として許容できるものをユーザーに尋ねる小さな調査を行ったところ、特に大きな利益が得られるのであれば、多くの人がより長い待ち時間を受け入れることができました。そのため、ビットコインの取引にZKを導入しても、それほど手間がかかるようには思えません。

上記では、ビットコインの基本設計をどのように変更すべきかについて多くの時間を費やしましたが、実際にはビットコインを変更せずに実装できるシナリオがかなりあります。ここでは、ブロックハッシュの有効性を証明するためにZKを組み込んだ、BitVM関連のアプリケーションであるChain State Proofsに注目したいと思います。

この技術はビットコインに何をもたらしたのでしょうか？ビットコインをどう変えたのか？まず、連鎖状態証明によって、ビットコインのカレンダーデータの同期と検証の作業負荷を圧縮することが可能になり、ノードの運用コストを劇的に削減することができます。現在、ジェネシスブロックから最新のビットコインブロックまでの同期と検証には、優れたハードウェアを搭載したデバイスで5時間30分、Raspberry Piレベルのデバイスでは数日かかりますが、State Proofsを導入することで、この時間消費を劇的に圧縮することができます。第二に、チェーンの状態証明は、BitVMで使用できるチェーンの重要な部分であり、BitVMの実装に弾みをつけるだろう。

ZeroSyncチームはチェーン状態証明を深く研究し、より軽い「ヘッダーチェーン証明」を作成しました。ZKと組み合わせたこのソリューションは、ビットコインのブロックヘッダの有効性のみを証明し、ビットコインの歴史における85万すべてのブロックヘッダを含む「ヘッダチェーン」を形成し、各ブロックヘッダに対して80バイトのハッシュを生成します。

このアプローチでは、対応するPoW証明を検証するために、各ビットコインのブロックヘッダに対して二重のSHA-256計算が必要であり、ZeroSyncがSTARKを使用してビットコインのヘッダチェーン証明を生成するには約4,000ドルかかり、私のブラウザで証明を検証するには4,000ドルしかかかりません。ブラウザで証明を検証するのにかかる時間は約3秒です。

しかし、ブロック内の取引内容の検証は含まれていないため、ヘッダーチェーン証明は、以下のプロセスでしか生成できません。プロセスでは、ヘッダーチェーン証明は、最も多くのPOW証明を持つブロックチェーンが有効であると仮定し、デフォルトでビットコインクライアントがこのチェーン上の最新のブロックを同期することを許可するだけです。このシナリオでは、攻撃者は無効なトランザクションを含むブロックを作成し、そのブロックの後にさらにブロックを追加し、ヘッダーチェーン証明を生成して、過去のデータを同期するビットコインクライアントを欺くことができますが、そうすることは非常に高価であり、既存のビットコインフルノードクライアントによって直接否定されるでしょう。

しかし、この攻撃シナリオの成功率は非常に低いです。しかし、もし攻撃者が莫大な量のBTCを盗むことができるのであれば、ヘッダーチェーン証明は確実な解決策とは認められません。完全なチェーン状態を証明したいのであれば、secp256k1楕円曲線に基づくECDSAやSchnorr署名検証を含め、ビットコインブロック内のすべてが有効であることを直接証明する必要があります。

ビットコインは毎月、その過去のブロックに3,000万件の署名を含むことができ、その歴史の中で合計25億件の署名操作、および大量のSHA-256操作が行われます。これは、毎月ビットコインネットワークによって生成されるブロックデータの約7GBになり、すべての履歴データの合計は650GB以上になります。

さて、次にBitVMを見てみましょう。BitVM. BitVMは、ビットコインがあらゆる計算タスクを検証することを可能にし、プロトコルを変更することなくSNARK検証への最良の道です。BitVMは、ビットコインブロックによって課されるスクリプトサイズの制限を回避するために2つのテクニックを使用します。

第二に、個々のスクリプトにまたがってアクセスできるKVストレージスキームを可能にし、超豊富なスクリプトプログラムへの接続を可能にします。しかし、ビットコインのプロトコルは、前述のKVストレージスキームの完全性を義務付けておらず、BitVMは、悪意のあるProverをチェックするために不正の証明を必要とするため、Proverが無効なステートメントや疑わしいKVストレージを投稿した場合、他の人は、Proverが悪さをしていることを示すトランザクションをビットコインチェーン上で開始し、事前に誓約された資産を奪うことができます。

要約すると、ビットコインビットコインは重大な課題に直面しており、これらの問題に対処するためにさまざまな提案がなされています。しかし、これらの提案がビットコインコミュニティによってすぐに採用されることはなく、プロトコルの変更は短期的には行われないでしょう。これは良いことでもあり、悪いことでもあり、ビットコインが分散化され、より安全であるということでもあります。

ビットコインコミュニティの多くは、SNARK/STARKの可能性に興奮しています。

中長期的にSNARK検証を実装する最も現実的な方法はBitVMである可能性が高いですが、実際に機能させるにはより多くの研究開発投資が必要になります。ビットコインスクリプトでSNARK検証を可能にする単純なオペコードを調査するか、OP_CATのような機能で実装できるシナリオを探る必要があります。どのオプションを選択するにしても、ビットコインコミュニティの最終的な目的は、製品を実用的なものにし、より上陸可能なシナリオをサポートすることでなければなりません。

Original link: https://www.youtube.com/watch?v=GrSCZmFuy7U