原作者: Janos Nick、Blockstream
オリジナル編集: Bai Ding、Faust、Geek Web3
要約: この記事は、ビットコインに ZK 検証機能をサポートさせる方法を簡潔に指摘しています。取り上げられている具体的なトピックには、ビットコイン UTXO とスクリプトの機能上の欠陥、Taproot や OP_CAT などの概念、および BitVM と Chain State Proof が含まれます。一般的な内容。この記事では、比較的明確な観点を提示しています。
ビットコイン プロトコルへの ZK の導入は避けられない傾向であり、これには 2 つの方法があります。1 つは、ビットコイン スクリプトが OP_CAT オペレーション コードの助けを必要とする SNARK 検証と、OP_CAT が最終的にパスする確率を直接サポートできるようにすることです。 2 番目のルートは BitVM に基づいており、不正行為を防止する方法を導入する必要があります。また、ZeroSync チームは、履歴データのノード クライアント検証のコストを削減するために Chain State Proofs を提案しました。
本文: ビットコインをより深く理解するには、ビットコインを社会システムとして扱うのが最善です。ビットコインが初期に発売されたとき、開発者は、社会システムが従うべき一連のルールを決定するのと同じように、ビットコイン ノードが実行する必要があるソフトウェア プログラムを決定しました。ビットコインの社会システムが安定して稼働できるのは、「ビットコインの本質とは何か」「どうあるべきか」という重要な問題について、全員が一定の合意を持っているからです。もちろん、合意に達することは簡単ではありません。上記の問題に関しては、意見の相違が広く広がり、進化しつつあります。
これはビットコインの歴史的な起源にまで遡ります。サトシ・ナカモト氏はビットコインのホワイトペーパーを発表した際、「私はまったく新しい電子決済システムに取り組んでいる。このシステムは完全にP2Pであり、サードパーティに依存する必要はない」と述べた。この一節は、Cypherpunks メーリング リスト (プライバシー保護と暗号技術に懸念を持つ暗号学者と技術愛好家のグループによって 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 を使用する新しいトランザクションを作成できます。その後、この新しいトランザクションは新しい出力データを生成し、BTC を他のトランザクションに送信します。
ここで注意すべきことは、ビットコインはイーサリアムのようなグローバルな状態を持たず、特にアカウントを持たず、トランザクション出力データのみを持った状態であるということです。各トランザクションの出力には、受信者によって使用されたか、未使用であるかの 2 つの状態があります。未使用のトランザクション出力は、おなじみの UTXO です。
もちろん、関連する BTC 金額に加えて、各トランザクション出力には、ビットコイン スクリプトと呼ばれる言語で書かれた追加プログラムがあります。このプログラムの正しい証拠を提供できる人は誰でも、トランザクション出力 (UTXO) を使用できます。ビットコイン スクリプト自体は、一連のオペコードを含むスタックベースのプログラミング言語です。多くの場合、前述の UTXO アペンダーは、スタックに基づいて計算を完了し、結果をスタックに戻します。
ビットコインの初期から存在している一般的なビットコイン スクリプトにはさまざまな種類があります。たとえば、ビットコインで最も一般的なスクリプトは、公開キーとデジタル署名をチェックするオペコードで構成されます。このオペコードは、UTXO を使用/ロック解除するには、対応する公開キーのデジタル署名を提示する必要があることを規定しています。
ここでは、Bitcoin Script の機能をまとめます。まず、ビットコインスクリプトで何ができるのでしょうか?
· スタックの再配置、等価性チェックの実行 (等価性チェックを使用して特定の条件が満たされているかどうかを検証し、トランザクションのセキュリティと正当性を確保)、および if-else と同様の分岐操作を実行できます。
· 32 ビット数値に対して限定された算術演算 (加算と減算) を実行できます。
· データをハッシュ化し、ECDSA および Schnorr 署名をチェックできます。
ビットコインスクリプトでできないことは何ですか?
· ループ、ジャンプ、再帰はありません。つまり、チューリングが完全ではなく、プログラミング機能は非常に限定されています。
· ビット単位の演算はできません。乗算と除算のオペコードが不足しています。
· スタック上の要素を連結することはできません。
· オンチェーンのトランザクション データを読み取って検査する能力がほとんどありません。
· ビットコイン スクリプトは各トランザクションの金額に直接アクセスできず、ステータスを渡す方法もありません (UTXO は 1 回限りの使用であり、転送のたびに古いものは破棄され、新しいものが生成されます)。
ビットコインの初期バージョンでは、上記のスクリプトで「実行できない」ことの一部は実際には実行できますが、一部の機能は後にサトシ・ナカモトによって無効にされました。これは、サトシ・ナカモトがこれらのオペコードに抜け穴があることを発見したためです。たとえば、スタック内の 2 つの要素を結合するオペコード OP_CAT を使用して、ビットコイン ノードをリモート攻撃してノードを崩壊させることができます。サトシ ナカモトは警戒して OP_CAT を無効にし、他のいくつかのオペコードも無効にしました。
では、Bitcoin Script は SNARK を検証できるのでしょうか?ビットコイン スクリプトは理論的にはチューリング完全ではありませんが、その基本的な操作はあらゆる計算を検証するのに十分です。しかし、検証ステップに必要なプログラム サイズがビットコインの最大ブロック制限である 4MB を超えているため、実際には SNARK 検証はまだ達成できません。
おそらく、大きな有限フィールドで算術演算を実行しようとすることはできますが、コストが非常に高くなります。たとえば、BitVM によって実装される 2 つの 254 ビット整数の乗算では、関連する Bitcoin スクリプトのサイズが 8KB 近くに達します。
さらに、OP_CAT を使用しないマークル証明の検証も、for ループと同様の操作が必要となるため、コストがかかります。
それでは、前の質問に戻ります。なぜ単純にビットコイン プロトコルを変更して、より強力なオペコードを追加できないのでしょうか?
前述したように、ビットコインのエコシステムには集中的な意思決定者が存在しないため、新しいプロトコルのルールについて多数決の合意に達することは非常に困難です。ビットコインネットワークでは、コミュニティが過半数の合意に達したかどうかを測定する良い方法がなく、この場合に更新を強制するとチェーンフォークにつながります。
もちろん、ビットコインは完全に静的なわけではありません。最新のアップデートは 2017 年の SegWit と 2021 年の Taproot です。
Taproot のアップグレードでは多くのルールが変更され、理論上のリリースから実際のアクティベーションまでに 3 年半かかりました。 Taproot を有効にする重要な要素は、既存のセキュリティの前提を変更せず、ビットコイン プロトコルを明確に改善することです。たとえば、ECDSA の代わりに Schnorr 署名を使用できます。どちらも離散対数の仮定に基づいており、同じ楕円曲線を使用しますが、前者の方が後者より効率的で、計算量が少なくなります。
さらに、Taproot によるビットコインの改良は主に次の 3 つの部分に分かれています。
まず、Taproot は、多数の選択的分岐を含むスクリプトの検証コストを削減し、ビットコインがより複雑なプログラムをサポートできるようにします。
第 2 に、Taproot はチェーン上で公開する必要があるスクリプト データを削減します。各スクリプトを別のリーフに配置して、複数のスクリプトを 1 つのマークル ツリーにまとめることができます。特定のスクリプトをトリガーしたい場合は、それを公開するだけで済みます。 . それが位置する葉とマークル証明。
第三に、タップルートは他の機械設計も追加しました。
そうは言っても、ビットコインには Tarpoot のようなより強力な機能を追加した前例があるため、SNARK を検証するための専用のオペコードを追加してみてはいかがでしょうか。これは、いわゆる OP_SNARK オペコードの追加が Taproot アップグレードとは大きく異なるためです。
まず第一に、OP_SNARK には多くの設計アイデアがあり、ほとんどの人が単一のソリューションをサポートすることは困難です。第二に、そのような提案が可決された場合、すべてのビットコイン ノードがこの特定の OP_SNARK ソリューションをサポートする必要があり、大きな技術的課題が追加されます。 。 重荷。
さらに、OP_SNARK 自体の複雑さも大きな課題です。テストを除くと、Taproot は約 1600 行のコードを追加するだけで許容範囲内ですが、OP_SNARK にはさらに複雑なコードが含まれています。
さらに、OP_SNARK オペコードをアクティブ化する必要があるかどうかを誰がレビューするのでしょうか?少数の人がその詳細を理解せずに、ビットコインのエコシステム内でコンセンサスを得るにはどうすればよいでしょうか?これらはすべて質問です。したがって、全体として、OP_SNARK のアップグレードは短期間では行われません。
ただし、ビットコイン スクリプトで SNARK を検証する別の方法もあります。より単純なオペコードを追加することで、ビットコイン スクリプトをより機能的にすることができ、スクリプトに SNARK バリデーター プログラムを実装できるようになります。しかし、実際には、SNARK検証プログラムをビットコインスクリプト言語で書くのは非常に困難です。
したがって、Blockstream 研究チームは、Bitcoin Script を置き換えるように設計されたプログラミング言語である Simplicity を開発しています。 Simplicity はブロックチェーン コンセンサス システム向けに特別に設計されており、意図的にチューリング完全ではないため、静的分析や形式的な検証が容易になります。
次に、ビットコイン スクリプトをより強力にする可能性がある、非常にシンプルだが強力な提案である OP_CAT オペコードについて説明します。前述したように、OP_CAT はビットコインの初期バージョンに存在していましたが、このオペコードにより特定の条件下でビットコイン ノードが DOS 攻撃を受ける可能性があるため、サトシ ナカモトによって無効化されましたが、ビットコイン コミュニティの一部の人々はこれを再度有効にしたいと考えています。 。 それ。
OP_CAT は、2 つの要素をスタックの先頭にポップし、連結して、スタックに戻します。これは非常に単純に聞こえますが、ビットコイン スクリプトに大幅な機能向上をもたらすことができます。
たとえば、ビットコイン スクリプトは当初、チェーン上のトランザクション量などのステータス情報にアクセスできませんでしたが、OP_CAT を使用すると、マークル証明の検証にも使用できるようになります。つまり、OP_CAT は基礎となるオペコード レベルでのアップグレードであり、多くの新しい機能が派生します。OP_CAT を使用することで達成できる効果が提案されています。
また、OP_CAT はスクリプト内の SNARK の検証に役立ちますか?答えは、マークル証明の検証のサポートは FRI ベースの SNARK の検証に役立ち、OP_CAT はこれをサポートできるためです。以前は、SNARK 検証に含まれるスクリプトが大きすぎてビットコイン ブロックに収まらなかった可能性がありましたが、OP_CAT を使用すると、プログラムのサイズを削減できます。
OP_CAT については過去に何年も議論されており、トランザクション検査 (イントロスペクション) におけるその役割を認識する人が増えています。他の提案と比較した OP_CAT の利点は、以前から Bitcoin Script に存在していたので、コミュニティでの合意形成が容易であることです。ただし、OP_CATのアクティブ化は一部の人々のMEV収入に損害を与える可能性があるため、ビットコインコミュニティはまだそれについて合意に達していません。
要約すると、OP_CAT などの単純なオペコードを有効にすることで、ビットコイン スクリプトで SNARK の検証を可能にする潜在的なパスがビットコインに存在する可能性があります。また、乗算オペコードを有効にし、すべての算術オペコードが任意の精度で動作できるようにする「Great Script Restoration」と呼ばれる最近の提案があることにも言及する価値があります。
さらに、ビットコインネットワークに対するOP_CATの影響を考慮する場合、通過後のビットコインノード運営者への影響を調べることができます。ビットコインの検閲耐性と分散化を実現するために、ビットコインコミュニティはできるだけ多くの人がノードを実行してデータを検証することを望んでいます。ビットコインがSNARK検証操作をサポートする場合、ビットコインノードの実行コストは大幅に増加せず、ビットコインのセキュリティと検閲耐性に大きな害を及ぼすことはありません。
現在、ビットコイン ブロックには最大 4 MB のデータを含めることができ、ブロックは 10 分ごとにマイニングされると予想されており、ほぼすべてのブロックにビットコイン スクリプトと証人 (デジタル署名と同様) を埋め込むことができます。計算すると、現在、各ブロックには最大 80K の署名検証を含めることができます。私の 2020 Intel CPU では、ビットコイン ブロックの検証に平均 3.2 秒かかります。もちろん、ブロック検証の速度に影響を与えるのは、時間のかかる署名検証だけではありません。
また、将来的にビットコイントランザクションがZK化に対応すれば、トランザクション生成時間が延長されても問題ないと思われます。資産の長期保管に使用されるハードウェア ウォレットの場合、画面が備わっていることが多く、その機能はキーの保存と署名の生成です。ハードウェア ウォレットの CPU は通常、ある程度のメモリを備えた 240MHz デュアルコア CPU など、比較的弱いものであり、ビットコイン トランザクションに署名するときに非常に高速に応答します。
私は、署名デバイスが証明を生成するまでに許容できる最大遅延についてユーザーに尋ねる小規模な調査を行ったところ、多くの人が、特に大きなメリットが得られる場合には、より長い待ち時間を許容していました。したがって、ビットコイン取引にZKを導入しても、それほど問題はないようです。
上記では、ビットコインの基本的な設計を変更する方法について多くのスペースを費やして説明しましたが、実際には、ビットコインを変更せずに実装できるアプリケーション シナリオが数多くあります。ここでは、BitVM - Chain State Proofs に関連するアプリケーションを取り上げたいと思います。これは、ZK と組み合わせることで、ブロック ハッシュの有効性を証明できます。
このテクノロジーはビットコインにどのような変化をもたらしましたか?まず、Chain State Proofs を使用すると、ビットコイン カレンダー データの同期と検証のワークロードが圧縮され、ノードの実行コストが大幅に削減されます。現在、良好なハードウェアを備えたデバイスでジェネシス ブロックから最新のビットコイン ブロックを同期して検証するには 5 時間 30 分かかりますが、今度は状態証明が導入された場合、Raspberry Pi レベルのデバイスでは数日かかります。 -消費プロセスを大幅に削減できます。次に、チェーン状態証明は BitVM で使用できる重要な部分であり、BitVM の実装を促進します。
ZeroSync チームは、チェーン状態プルーフに関する徹底的な研究を実施し、より軽量な「ヘッダー チェーン プルーフ」を作成しました。このソリューションは、ZK と組み合わせることで、ビットコイン ブロック ヘッダーの有効性のみを証明し、850,000 個すべてを含む「ヘッダー チェーン」を形成します。ビットコイン履歴のブロック ヘッダーを分析し、ブロック ヘッダーごとに 80 バイトのハッシュを生成します。
このスキームでは、対応する PoW 証明を検証するために、各ビットコイン ブロック ヘッダーで 2 回の SHA-256 計算が必要です。 ZeroSync は STARK を使用してビットコインのヘッダー チェーンの証明を生成します。証明の生成コストは約 4,000 ドルで、ブラウザで証明を確認するのにかかる時間はわずか 3 秒です。
ただし、ブロック内のトランザクション内容の検証プロセスが含まれていないため、ヘッダー チェーンの証明は、最も多くの POW 証明を持つブロックチェーンが有効であると想定することしかできず、デフォルトでビットコイン クライアントがこのチェーン上の最新のブロックを同期することを許可します。 。このシナリオでは、攻撃者は無効なトランザクションを含むブロックを作成し、このブロックの後にさらにブロックを追加し、履歴データを同期するビットコイン クライアントを欺くためのヘッダー チェーンの証明を生成できますが、そうすることで攻撃は非常にコストがかかり、既存のビットコインフルノードクライアントによって直接その誤りが暴かれる可能性があります。
ただし、この攻撃シナリオの成功率は低いにもかかわらず、攻撃者が大量の BTC を盗むことを可能にする場合、ヘッダー チェーンの証明は絶対確実なソリューションとは言えません。完全なチェーン状態を証明したい場合は、secp256k1 楕円曲線に基づく ECDSA および Schnorr 署名検証を含め、ビットコイン ブロック内のすべてのコンテンツが有効であることを直接証明する必要があります。
ビットコインの毎月の履歴ブロックには 3,000 万の署名が含まれる可能性があり、履歴には合計 25 億の署名操作と多数の SHA-256 操作が含まれます。このようにして、ビットコインネットワークは毎月約7GBのブロックデータを生成し、すべての履歴データの合計は650GBを超えます。実際には、この数は 2 ～ 3 倍になる可能性があります。
次に、BitVM を見てみましょう。 BitVM を使用すると、ビットコインであらゆるコンピューティング タスクを検証できるようになり、プロトコルを変更せずに SNARK 検証を達成するための最良のパスになります。 BitVM は 2 つの手法を使用して、スクリプト サイズのビットコイン ブロック制限を回避します。まず、Taproot MerkleTree のスクリプト構造を使用します。
2 番目に、単一のスクリプトからアクセスできる KV ストレージ スキームが有効になり、多数のスクリプトへの接続が可能になります。ただし、ビットコイン プロトコルは、上記の KV ストレージ スキームの整合性を強制しません。証明者が無効なステートメントまたは問題のある KV ストレージを発行した場合、BitVM は悪意のある証明者をチェックする必要があり、ビットコイン チェーン上でトランザクションを開始する可能性があります。 、プルーバーが不適切な行為をし、事前に担保に入れていた資産を取り上げたことを示しています。
要約すると、ビットコインは大きな課題に直面しており、これらの問題を解決するためにさまざまな解決策が提案されていますが、これらの提案はビットコインコミュニティにすぐには採用されず、プロトコルの変更は短期間で完了することはできません。良いことでもあり悪いことでもありますが、それはビットコインが分散化され、より安全であることも意味します。
ビットコインコミュニティの多くは、SNARK/STARK の可能性に興奮しています。中長期的に SNARK 検証を達成するための最も実現可能な方法は BitVM である可能性が最も高いですが、実際に効果を発揮するにはさらに多くの研究開発投資が必要です。
OP_CAT オペコードを再度有効にすることもアイデアですが、オペコードを再起動する利点がリスクをはるかに上回っていることを証明し、どの単純なオペコードがビットコイン スクリプトで SNARK 検証を可能にするかを調査するか、OP_CAT 関数と同様のシナリオを調査する必要があります。達成できます。どのソリューションを選択するにしても、ビットコイン コミュニティの最終目標は、製品を実用化し、より実装可能なシナリオをサポートすることである必要があります。
