Vitalik Buterin 香港 Web3 フェスティバル講演実録：我々は暗号技術の限界に達するプロトコルを必要としている
TechFlow厳選深潮セレクト
Vitalik Buterin 香港 Web3 フェスティバル講演実録：我々は暗号技術の限界に達するプロトコルを必要としている
私たちは本当に、上限とは何か、そしてどうすれば真にその上限に到達できるのかを研究し始める必要がある。
Web3業界の深掘り報道に専念し潮流を洞察著者：Vitalik Buterin
整理：DeThings
2024年の香港Web3フェスティバル期間中、イーサリアム共同創設者であるVitalik Buterinは、DRK Lab主催の「Web3 Scholars Summit 2024」にて基調講演『Reaching the Limits of Protocol Design』を行いました。
以下はDeThingsによる中国語でのリアルタイム記録（要約・編集あり）です：
過去10年間で、プロトコル構築に用いられる技術の種類は大きく変化しました。2009年にビットコインが誕生した当時、使用されていた暗号技術は非常にシンプルでした。ビットコインプロトコル内で使われる暗号技術は、ハッシュと楕円曲線ECDSA署名、そして作業量証明（PoW）だけです。PoWもまた、ハッシュを利用した別の形式にすぎません。2020年代に使われているプロトコル構築技術を見てみると、ここ10年間に登場したより複雑な技術群が使われるようになっています。
これらの技術自体は長く存在しています。たとえばPCP定理はすでに数十年前に理論上は確立されていました。Craig Gentryによる完全準同型暗号（FHE）の発見は2009年からです。乱流回路（garbled circuits）も何十年も前から存在し、これは二者の計算を可能にする形式です。しかし、理論的に存在することと、実用的に使える段階にあることには大きな違いがあります。
実際に、ブロックチェーン分野自身が大きな貢献をしており、多くのリソースを投入することで、こうした技術を日常的なアプリケーションで利用可能なレベルまで引き上げてきたと考えています。
2020年代にブロックチェーンを構築する際、ハッシュと署名だけが唯一の手段だと仮定していた時代がありました。しかし2020年代に設計された新しい観測プロトコルでは、こうしたすべての技術が最初から重要な構成要素として扱われるようになりました。
まず第一に登場した画期的技術がZK-SNARKsです。ZK-SNARKsは、ある計算を行い、その出力を得たことを証明できる技術です。この証明の検証は、計算自体を再実行するよりもはるかに高速に行えます。さらに、入力データを公開せずに証明を検証することも可能です。
2010年のZK-SNARKsと、2016年12月にZcashプロトコルで初めて採用されたもの、そして現代のZK-SNARKsを比べると、その差は歴然です。
こうした新しい暗号技術の多くは、「誰も知らない技術」から「ニッチな関心対象」を経て、主流へと移行し、今やほぼデフォルトの設定となっています。過去10年間で、これらは劇的な進化と改善を遂げました。
「ZK-SNARKsはプライバシー面でも、スケーラビリティ面でも非常に有効です。ブロックチェーンは何を提供してくれるでしょうか？オープン性、許可不要アクセス、グローバルな検証可能性といったメリットを提供してくれます。しかし、これらすべては2つの大きな犠牲を払って達成されています。
その一つがプライバシー、もう一つがスケーラビリティです。ZK-SNARKは、これらの両方を取り戻す手助けをします。2016年にZcashプロトコルが登場して以来、イーサリアムエコシステム内でも徐々に広がりを見せ始めました。現在では、ほぼすべての新規プロジェクトがzkSNARK、MPC（マルチパーティ計算）、FHE（完全準同型暗号）を活用しています。人々の認知度はまだzkSNARKほどではありませんが、zkSNARKでは実現できない用途も存在します。たとえば、個人のプライベートデータ上で実行されるプライバシー保護計算などです。
投票も大きなユースケースの一つです。zk-SNARKsによってある程度のプライバシーは確保できますが、最良の特性を得たい場合は、MPC（マルチパーティ計算）とFHE（完全準同型暗号）を使う必要があります。多くの暗号AIアプリケーションも最終的にはMPCとFHEを使用しており、これらは過去10年間で効率が飛躍的に向上したプリミティブです。BLS（Boneh-Lynn-Shacham、集約署名）は、多数の参加者（潜在的には数万人）からの大量の署名を取得し、それらを単一の署名と同じくらいの速さで検証できるという興味深い技術です。
この機能は非常に強力です。BLS集約署名は、イーサリアムの現代的プルーフ・オブ・ステーク（PoS）コンセンサスの中心技術です。BLS集約が登場する前のPoSコンセンサスを見てみると、アルゴリズムは多くの場合数百のバリデータしかサポートできませんでした。一方、現在のイーサリアムには約30,000のバリデータが存在し、それぞれ12秒ごとに署名を送信しています。このような規模が可能になったのは、過去5〜10年の間にこの新しい形の暗号技術が十分に最適化され、実用レベルに到達したためです。これらの新技術により、多くのことが可能になったのです」。
こうした技術は急速に強力になり続けています。今日のプロトコルはこれらの技術を多用しています。私たちは、専用暗号学から汎用暗号学への大きな転換を経験しました。かつては新しいプロトコルを作るには、暗号学の内部動作を理解する必要がありましたが、今は特定用途向けのアルゴリズムではなく、汎用的なツールセットが利用できます。特殊な用途には特殊なアルゴリズムを作らなければなりませんでしたが、今や、過去5分間で話してきたような技術を使ったアプリケーションを、暗号学者でなくても作れるようになったのです。
単にCircomでコードを書いてコンパイルすれば、検証器と証明器が自動生成され、zk-SNARKアプリケーションの完成です。ここで直面する課題は、過去10年でどれほど遠くまで来たかということです。あと何が残っているのか？今日の技術と理論的理想との間にはどのようなギャップがあるのか？これが研究者や学術界が大きく貢献できるまさにキーフィールドだと思います。
現在の主な課題は基本的に二つあります。一つは効率、もう一つはセキュリティです。第三の課題として、機能拡張もあります。
たとえば、我々がまだ真正面から掌握できていない技術として「無差別混淆（indistinguishability obfuscation）」があります。もし実用的なアルゴリズムが実現できれば、それは非常に画期的でしょう。しかし、実際には、既存技術の効率と安全性の向上の方が重要だと考えています」。
効率について考えてみましょう。具体的な例としてイーサリアムブロックチェーンを取り上げます。イーサリアムでは、スロット時間は12秒です。つまり、ブロックと次のブロックの平均間隔は12秒です。通常のブロック検証時間、すなわち任意のイーサリアムノードがブロックを検証するのにかかる時間は約400ミリ秒です。
一方、zk-SNARKで通常のイーサリアムブロックを検証するには、現在約20分かかります。ただし、この時間は急速に短縮されており、2年前は5時間かかっていました。今の20分というのは平均値であり、依然として最悪ケースは存在します。たとえば、イーサリアムブロック全体がZcashの計算で占められていた場合、証明時間は20分を超えます。
とはいえ、2年前と比べれば大きく前進しています。現在の目標は何でしょうか？それはリアルタイム証明です。ブロックが生成された瞬間に、次のブロックが生成される前にその証明を得ることです。リアルタイム証明が実現すれば、世界中のすべてのイーサリアムユーザーが簡単に完全なプロトコル検証者になれます。しかし現状、イーサリアムノードを運営している人はごくわずかです。アーカイブノードを運用するには2TBのストレージが必要で、可能ではありますが非効率です。ブラウザウォレット、モバイルウォレット、他のチェーン上のスマートコントラクト用のライトウェイトウォレットなど、あらゆるタイプのイーサリアムウォレットが、本当に完全にイーサリアムのコンセンサスルールを検証できるようにできないでしょうか？
一部の人々はInfuraを信用していません。プルーフ・オブ・ステークのバリデータさえも信用せず、直接ルールを検証し、イーサリアムブロックの正当性を自ら確認したいのです。これをZK-SNARKでどう実現するか？そのためには、zK-SNARKの証明がリアルタイムでなければならない。つまり、任意のイーサリアムブロックに対して、おそらく5秒以内に証明を得られる方法が必要です。
問題は、そこに到達できるかどうかです。MPCとFHEにも同様の問題があります。先ほど触れたように、MPCとFHEの典型的なユースケースは投票です。すでに実用化が始まっています。約3週間前、ベトナムでイーサリアムイベントが開催されました。そのイベントでは、実際にMPC、つまり暗号的に安全な投票システムを使って、プロジェクトやハッカソンへの投票が行われました。
現在のMPCの問題点は、いくつかのセキュリティ属性が中央サーバーに依存していることです。この信頼前提を分散化できるでしょうか？理論的には可能です。しかし、そのためにはMPCとFHEが必要です。問題は、これらのプロトコルを保証するためのオーバーヘッドが非常に大きいことです。ZK-SNARKにFHEを組み合わせると、なおさらです。これらのプロトコルを一般ユーザーがデフォルトで使うものにするには、一票ごとの証明に5ドルもの計算コストがかかってはいけませんよね？大量の投票を迅速に、場合によってはリアルタイムで処理できる必要があります。
では、ZK-SNARKの目標をどう実現するか？効率を高めるために、三つの主要な方向性があると考えます。その一つが並列化と集約です。イーサリアムブロックの検証には最大で1000万ステップの計算が必要だとしましょう。各計算ステップごとに個別に証明を作成し、その後、証明を集約します。最初の2つの証明を取って、それらをまとめて証明します。次の2つも同様に証明し、さらにその結果の2つを証明していきます。このようにして証明の木を構築し、約20段階進むことで、プログラム全体の正当性を表す単一の大きな証明を得られます。
これは現在の技術でも可能です。理論的には5秒以内にブロックの正当性を証明できます。問題はどこにあるか？これは大量の並列計算を必要とする点です。1000万回の証明が必要になります。これを最適化できるでしょうか？並列化や集約証明の最適化は可能でしょうか？答えは「はい」です。そのための理論的アイデアは多く存在します。しかし、これらを実用的な形にしなければなりません。これはアルゴリズムの改善、低レベルの最適化、ハードウェア設計の改良が統合された課題です。ASICも非常に重要です。マイニングにおけるASICの重要性は周知の通りです。2013年にASICが登場したとき、ビットコインのハッシュレートがいかに急激に増加したか覚えていますよね？
ASICは非常に強力です。同じハードウェアコストと電力消費でも、ASICのハッシュ性能はGPUの約100倍です。では、SNARK証明にも同じ恩恵をもたらせるでしょうか？私は「できる」と考えます。現在、zK-SNARK証明専用のASICを実際に製造しようとする企業が増えてきています。zkEVM向けでも構いませんが、実際には非常に汎用的なものであるべきです。あらゆる種類の計算証明に使えるSNARK ASICを製造できるはずです。これにより、20分から5秒までの短縮は可能になるでしょうか？
最後に、効率性のさらなる向上です。より優れたzK-SNARKアルゴリズムが必要です。Groth16、ルックアップテーブル、64ビットSNARK、STARK、32ビットSTARKなど、さまざまなアイデアがあります。SNARKアルゴリズムの効率をさらに高めることはできるでしょうか？SNARKに適したハッシュ関数、SNARKに適した署名アルゴリズムをもっと作ることはできるでしょうか？ここには多くのアイデアがあります。ぜひこうした研究に取り組んでいただきたいと思います。
主なセキュリティ課題は「バグ」です。これはあまり語られませんが、極めて重要な問題だと考えます。私たちが持つ驚異的な暗号技術も、回路にバグがあるかもしれないと人々が懸念していれば、信頼されないでしょう。zk-SNARKでもzkEVMでも、コードは7000行程度あります。これは非常に効率化された状態です。一般的に、1000行あたり15～50のバグが存在します。イーサリアムでは努力して1000行あたり15未満に抑えていますが、ゼロではありません。数十億ドル相当の資産を扱うシステムにおいて、たった一つのバグがあれば、どんなに高度な暗号技術を使っていても、その資金は失われるのです。
では、既存の暗号技術を活用しつつバグを減らすにはどうすればよいでしょうか？現在使われている基本技術は「セキュリティ委員会」です。つまり、イーサリアム内で複数の人々を召集し、その大多数（例えば75％以上）がバグを認めれば、証明システムの結果を覆すことができます。これはかなり集中型の仕組みですが、現時点で最も良い選択肢です。近い将来には多重証明が登場するでしょう。図はStarknetの例です。これはイーサリアム上に構築されたRollupの一つです。複数の証明システムを持つことで、冗長性を利用していずれかのシステムにバグがあったとしてもリスクを低減できるという考え方です。3つの証明システムがあれば、どれか一つにバグがあっても、他の二つがまったく同じ場所でバグを起こす可能性は低いはずです。
最後に、将来的に面白い研究テーマとなるのは、人工知能ツールの活用です。新しいツールを使って形式的検証を行う可能性があるのではないでしょうか？数学的手法でZKEVMのようなものがバグを持っていないことを証明できるのか？たとえば、zkEVMの実装が、イーサリアム実装とまったく同じEVMコードの機能を検証していることを本当に証明できるのか？どんな入力に対しても一意の出力しか得られないことを証明できるのか？こうしたことを真剣に証明しようとすれば、いつか本当にバグのないzkEVMの世界が実現するかもしれません。
これはとても狂気じみていますよね？なぜなら、これまでそんなに複雑なバグのないプログラムを作ったことはなかったからです。しかし2019年には、AIが本当に美しい画像を生成できるとは誰も思っていませんでしたよね？だからこそ、今日私たちがどれほど進歩したかがわかります。AIの能力を目の当たりにしています。では、同様のツールを実際のタスクに応用できないでしょうか？たとえば、数千行にわたる複雑なプログラムに対して、複雑な命題の数学的証明を自動生成するようなことです。これは興味深いオープンチャレンジであり、注目すべき価値があります。
集約署名の効率について。現在、イーサリアムには3万のバリデータが存在し、ノードの運用条件は高いですよね？私のノートパソコンにもイーサリアムノードはありますが、普通のノートPCではありません。自分でHDDを増設しなければなりません。イーサリアムの理想は、可能な限り多くのバリデータをサポートすることです。
ステークドプルーフを可能な限り民主化し、あらゆる規模で直接参加できるようにしたい。イーサリアムノードの運用要件は非常に低く、使いやすいものにしたい。理論とプロトコルは可能な限りシンプルであるべきです。ここでの理論的限界は何でしょうか？各参加者が各期間に送信するデータは最低1ビット必要です。なぜなら、誰が署名に参加したか、していないかをブロードキャストしなければならないからです。
これが最も基本的な制限です。この制限を超えると、他に制約はありません。計算の下限はなく、集約証明や再帰的証明木が可能です。署名やさまざまな集約署名も可能ですし、STARKや格子ベースの暗号、32ビットSTARKなど、さまざまな技術が利用できます。
問題は、署名集約をどこまで最適化できるかです。これはピア・ツー・ピアのセキュリティに関する問題です。人々はP2Pネットワークについて十分に考慮していません。特に強調したい点ですが、暗号分野では、P2Pネットワークの上に凝った構造を作り、その後P2Pネットワークは勝手に動くものだと考えがちです。
ここには多くの隠れたリスクがあります。ビットコインにおけるP2Pネットワークの動作方法を思い出してください。2010年代には、すべてのノードがすべての情報を視認していました。日蝕攻撃（eclipse attack）、サービス拒否攻撃（DoS）、その他さまざまな攻撃が可能でした。
しかし、非常にシンプルなネットワークであり、その唯一の目的が「全員がすべての情報を得ること」であれば、問題は比較的単純です。問題は、イーサリアムの規模が拡大するにつれ、P2Pネットワークがますます複雑になっている点です。現在のイーサリアムP2Pネットワークはすでに64のシャードに分かれていますよね？
現在のように毎スロット30,000の署名を処理するために、署名集約を行うには、P2Pネットワークを64の異なるサブネットに分割し、各ノードはそのうちの一つまたは数個に属する必要があります。データ可用性サンプリング（data availability sampling）は、スケーラビリティを実現するためのイーサリアムの技術で、Rollupの手数料を非常に低く抑えることができます。
これもまた、より複雑なP2Pアーキテクチャに依存しています。図に示されているようなピアノード構成では、各ノードは全データの1/8しかダウンロードしません。では、このようなネットワークは本当に安全なのでしょうか？その安全性を保証できるのでしょうか？保証率を可能な限り高めることはできるのでしょうか？イーサリアムが依存するP2Pネットワークの安全性を、どのように守り、強化できるのでしょうか？
基本的に、この段階では、暗号技術の限界に到達できるプロトコルの設計に注力する必要があります。私たちの暗号技術は10年前よりもはるかに強力ですが、さらに強力になる余地があります。ここで本当に問うべきは、上限とは何か、そしてどうすればその上限に到達できるかです。
ここには同等に重要な二つのフロンティアがあります。一つは効率の継続的向上です。すべてをリアルタイムで証明できる世界を目指します。分散型プロトコル内で、ブログを通じて伝達されるすべての情報に、その情報とそれが依存するすべての内容がプロトコルルールに従っていることを証明するzk-SNARKがデフォルトで付随する世界を見たいのです。
もう一つのフロンティアはセキュリティの向上です。根本的には、エラーの発生確率を減らし、プロトコルが依存する実際の技術が非常に強力で、非常に信頼できるものにすることです。人々ができる限りそれを信頼できるようにする必要があります。バグがあるプロジェクトでは、人々は暗号技術ではなく人を信頼しようとします。
しかし、何度も見てきたように、マルチシグ（多重署名）もハッキングされることがあります。そうしたLayer2プロジェクトの通貨が、マルチシグによって管理されていたにもかかわらず、なぜか9つのうち5つが同時にハッキングされ、大量の資金が失われた事例があります。このような世界を超えるためには、本当に使える技術を信じ、ルールの遵守を少数の人々ではなく、暗号技術自体で実行しなければなりません。
しかし、そのためにはコードが信頼に値するものでなければなりません。問題は、コードを信頼できるようにできるか？ネットワークを信頼できるようにできるか？こうした製品やプロトコルの経済的側面を信頼できるようにできるか？これらがまさに中心的な課題であり、共に努力し、不断に改善していけることを願っています。ありがとうございました。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@DethingsNews
