イーサリアムのパフォーマンスを解放する：EVMボトルネックを超えるイノベーションの道
TechFlow厳選深潮セレクト
イーサリアムのパフォーマンスを解放する：EVMボトルネックを超えるイノベーションの道
EVMは高性能アプリケーションの課題に本当に対応できるのか？
Web3業界の深掘り報道に専念し潮流を洞察著者：Siddharth Rao、IOSG Ventures
イーサリアム仮想マシン（EVM）のパフォーマンスについて
イーサリアムメインネット上で行われるすべての操作には一定のGasがかかる。もし基本的なアプリケーションを実行するために必要な計算量をすべてオンチェーンで処理しようとすれば、アプリはクラッシュするか、ユーザーは破産するだろう。
このような状況からL2が生まれた。OP Rollup（OPRU）は、一連のトランザクションをまとめて処理し、それらをメインネットに提出する「ソーター（sequencer）」を導入した。これにより、アプリはイーサリアムのセキュリティを継承しつつ、ユーザーにとってより良い体験を提供できるようになった。ユーザーはより迅速にトランザクションを送信でき、手数料も安価になる。処理コストは下がったものの、依然としてネイティブなEVMが実行層として使用されている。ZK Rollupでも同様で、ScrollやPolygon zkEVMは現在または将来、EVMベースのzk回路を使用する予定だ。zk証明は、証明装置上で個々または一括して実行された各トランザクションに対して生成される。これにより開発者は「完全オンチェーン」のアプリケーションを構築できるようになるが、果たして高性能なアプリケーションを効率的かつ経済的に実行し続けられるだろうか？
これらの高性能アプリケーションとは何か？
まず思い浮かぶのはゲーム、オンチェーンオーダーブック、Web3ソーシャル、機械学習、遺伝子解析モデルなどである。これらすべては大量の計算を必要とし、L2上での実行は非常に高価になってしまう。EVMのもう一つの問題は、現代の他のシステム（例：SVM＝Sealevel Virtual Machine）と比較して、計算速度と効率が劣ることにある。
L3のEVMを使えば計算コストをさらに下げられるかもしれないが、EVM自体の構造は並列計算をサポートしないため、大規模計算の実行には最適ではない可能性がある。また、新しいレイヤーを追加するたびに、分散化の理念を維持するために新たなインフラ（新しいノードネットワーク）を構築する必要がある。つまり、同じ数のプロバイダーを拡張するか、まったく新しいノードプロバイダー（個人／企業）によるリソース提供、あるいはその両方が求められる。
そのため、より高度な解決策が登場するたびに、既存のインフラをアップグレードしたり、上位に新しいレイヤーを追加したりする必要が生じる。この問題を解決するには、後量子時代にも安全で、分散化され、信頼不要かつ高性能な計算インフラが必要となる。それは、分散型アプリケーション向けに量子アルゴリズムを効率的に活用できるような基盤であるべきだ。
Solana、Sui、Aptosといった代替L1は並列実行を可能にしているが、市場の感情や流動性不足、開発者不足により、イーサリアムへの脅威とはなっていない。信頼の欠如に加え、イーサリアムがネットワーク効果によって築き上げた防波堤は画期的であり、現時点でETH／EVMの真の対抗馬は存在しない。ここで問われるのは、「なぜすべての計算をオンチェーンで行わなければならないのか？ 同じく信頼不要・分散化された実行システムは存在しないのか？」という点である。これはDComputeシステムが実現しようとしていることだ。
DComputeインフラは分散化され、後量子安全かつ信頼不要でなければならない。ブロックチェーン／分散技術そのものである必要はないが、計算結果の検証、正しい状態遷移、最終確定の仕組みは極めて重要である。EVMチェーンの動作もまさにそうであり、ネットワークの安全性と改ざん防止を保ちつつ、分散化され、信頼不要で安全な計算をオフチェーンに移すことが可能になる。
ここで主に無視しているのはデータ可用性の問題である。筆者はデータ可用性を軽視しているわけではない。CelestiaやEigenDAのようなソリューションがすでにこの方向に向かって進んでいるからだ。
1：計算のみを外部委託（Only Compute Outsourced）
2. 計算とデータ可用性の両方を外部委託
Type 1を見てみると、zk-rollupはすでにこれを実現している。しかし、EVMに制限されるか、開発者がまったく新しい言語／命令セットを学ぶ必要がある。理想的なソリューションは、効率的で（コストとリソースの面で）有効であり、分散化され、プライバシー保護され、検証可能なものが望ましい。ZK証明はAWSサーバー上で構築できるが、それらは分散化されていない。NillionやNexusといったソリューションは、汎用計算の問題を分散化のアプローチで解決しようとしている。しかし、ZK証明がない限り、これらのソリューションは検証不可能である。
Type 2はオフチェーン計算モデルと分離されたデータ可用性レイヤーを組み合わせるが、計算の検証は依然としてオンチェーンで行われる必要がある。
では、今日利用可能な、完全には信頼できない、あるいは将来的に完全に信頼不要となる可能性のある分散計算モデルを見てみよう。
他の計算システム（Alternative Computation Systems）
イーサリアムにおける計算の外部委託エコシステム図
- セキュア・エンクレーブ計算（Secure Enclave Computations）／信頼できる実行環境（Trusted Execution Environments, TEE）
TEE（信頼できる実行環境）とは、コンピュータやスマートフォン内部にある特別なボックスのようなものだ。独自の鍵とロックを持ち、特定のプログラム（信頼できるアプリケーション）だけがアクセスできる。これらの信頼できるアプリケーションがTEE内部で実行される際、他のプログラムやOS自体からも保護される。
これは、ごく少数の特別な人物しか入れない秘密の隠れ家のようなものだ。TEEの最も一般的な例はセキュア・エンクレーブであり、私たちが使うデバイスに搭載されている。AppleのT1チップやIntelのSGXなどがそれにあたり、FaceIDなどの重要な操作をデバイス内で実行するために使われる。
TEEは隔離されたシステムであるため、認証プロセスは破壊されないとされているが、そこには信頼の前提が存在する。これは、IntelやAppleが作ったという理由で安全だと信じているセキュリティゲートのようなものだが、世界には十分な数のハッカーや強力なコンピュータが存在し、このゲートを突破できる可能性がある。TEEは「後量子安全」ではなく、無限のリソースを持つ量子コンピュータがそのセキュリティを破ることができる。コンピュータの性能が急速に向上する中、長期的な計算システムや暗号方式を設計する際には、後量子安全性を常に念頭に置く必要がある。
- 安全なマルチパーティ計算（SMPC）
SMPC（安全なマルチパーティ計算）は、ブロックチェーン業界でもよく知られている計算手法であり、SMPCネットワーク内の一般的なワークフローは以下の3つのステップからなる：
-
ステップ1：計算の入力を「シェア（shares）」に変換し、SMPCノード間で分配する。
-
ステップ2：実際に計算を実行する。通常、複数のSMPCノード間でメッセージ交換が行われる。このステップの終了時に、各ノードは計算結果の一部（シェア）を持っている。
-
ステップ3：結果のシェアを1つ以上の結果ノードに送信し、LSS（秘密共有復元アルゴリズム）を実行して出力結果を再構成する。
自動車の生産ラインを想像してほしい。エンジン、ドア、ミラーなどの部品の製造がOEM（作業ノード）に外注され、その後、それらを組み立てるアセンブリライン（結果ノード）で完成車が作られる。
秘密共有（Secret sharing）は、プライバシー保護された分散計算モデルにおいて極めて重要である。これにより、単一の参加者が完全な「秘密」（この場合は入力値）を得て、悪意ある誤った出力を生成することを防ぐことができる。SMPCは、最も簡単で安全な分散システムの一つと考えられる。現時点では完全に分散化されたモデルは存在しないが、理論的には可能である。
SharemindのようなMPCプロバイダーはMPCインフラを提供しているが、プロバイダー自体は集中化されている。どうやってプライバシーを確保し、ネットワーク（あるいはSharemind）が悪意を持っていないことを確かめるのか？ そこで登場するのがzk証明とzk検証可能計算である。
- Nil Message Compute（NMC）
NMCはNillionチームが開発した新しい分散計算手法であり、MPCのアップグレード版である。NMCでは、ノード間で結果に関するメッセージ交換を行う必要がない。そのため、彼らは「ワンタイムマスキング（One-Time Masking）」という暗号プリミティブを用い、一連の乱数（ブラインディングファクター）を使って秘密情報をマスクする。これはワンタイムパッドに似ている。OTMは効率的に正しさを保証することを目指しており、NMCノードは計算実行のためにメッセージを交換する必要がない。つまり、NMCはSMPCのようなスケーラビリティの問題を抱えない。
- ゼロ知識検証可能計算（Zero-Knowledge Verifiable Computation）
ZK検証可能計算（ZK Verifiable Computation）とは、一連の入力と関数に対してゼロ知識証明を生成し、任意のシステムが正しく計算を実行したことを証明するものである。ZK検証計算はまだ初期段階にあるが、すでにイーサリアムネットワークのスケーリングロードマップにおいて極めて重要な位置を占めている。
ZK証明にはさまざまな実装形態がある（以下画像参照、「Off-Chaining_Models」という論文からの要約）：
以上でZK証明の実現方法について基本的な理解を得た。では、ZK証明を使って計算を検証するには何が必要か？
-
まず、証明プリミティブを選択する必要がある。理想的には、証明生成コストが低く、メモリ要求が少なく、検証が容易なものであるべきだ。
-
次に、計算を通じて上記のプリミティブの証明を生成するために設計されたzk回路を選ぶ。
-
最後に、ある計算システム／ネットワーク上で、与えられた関数に指定された入力を適用し、出力を得る。
開発者の難題 - 証明の効率のジレンマ
もう一つ指摘すべきは、回路構築のハードルの高さだ。Solidityを学ばせるだけでも難しいのに、今度はCircomなどを学んで回路を構築したり、Cairoのような特定のプログラミング言語を学んでzk-appを開発するよう求めるのは、あまりにも非現実的だ。
上の統計グラフが示すように、新しいWeb3開発環境に開発者を引き込むよりも、既存のWeb3環境をより開発しやすいものにするほうが、はるかに持続可能である。
もしZKがWeb3の未来であるなら、Web3アプリケーションは既存の開発スキルを活かして構築されるべきであり、JavaScriptやRustなどの言語で書かれたアルゴリズムの実行に対しても証明を生成できるようなzk回路が必要となる。
そのようなソリューションは実際に存在する。筆者が思いつくのは2つのチーム：RiscZeroとLurk Labsである。どちらのチームも、開発者が急激な学習曲線を克服せずにzk-appを構築できるようにするという非常に似たビジョンを持っている。
Lurk Labsはまだ初期段階にあるが、長期間にわたりこのプロジェクトに取り組んできた。彼らは汎用回路によるNova証明の生成に焦点を当てている。Nova証明はカーネギーメロン大学のAbhiram Kothapalli、マイクロソフトリサーチのSrinath Setty、およびNYUのIoanna Tziallaeによって提案された。他のSNARKシステムと比べ、Nova証明は増分検証可能計算（IVC）において特別な利点を持つ。IVC（Incrementally Verifiable Computation）は、コンピュータサイエンスと暗号学の概念であり、複雑で長い計算を最初からやり直すことなく検証できるようにすることを目的としている。計算時間が長い場合、IVC向けに証明を最適化する必要がある。
Nova証明は他の証明システムのように「すぐに使える」ものではなく、あくまで「折りたたみテクニック」にすぎない。開発者は依然として証明を生成するための証明システムを必要とする。そのためLurk LabsはLurk Langを構築した。これはLISPの実装である。LISPは低レベル言語のため、汎用回路上での証明生成が容易になり、JavaScriptへの変換も簡単に行える。これにより、Lurk Labsは1740万人のJavaScript開発者を獲得できる可能性がある。Pythonなど他の汎用言語への変換もサポートされている。
まとめると、Nova証明は優れた基礎的証明システムのように見える。欠点としては、計算量に比例して証明サイズが線形に増加する点があるが、一方でNova証明にはさらなる圧縮の余地がある。
STARK証明のサイズは計算量の増加に伴って増大しないため、非常に大規模な計算の検証に適している。開発者体験をさらに改善するため、RiscZeroはBonsaiネットワークも公開している。これはRiscZeroが生成した証明によって検証される分散計算ネットワークである。以下はBonsaiネットワークの動作原理を表す簡単な図式である。
Bonsaiネットワークの設計の美点は、計算の初期化、検証、出力のすべてがオンチェーンで完結できる点にある。これらすべてはユートピアのように聞こえるが、STARK証明には検証コストが高すぎるという問題もある。
Nova証明は繰り返し計算（折りたたみスキームが経済的）や小規模な計算に適しており、Lurkは機械学習推論の検証に優れたソリューションとなる可能性がある。
勝者は誰か？
一部のzk-SNARKシステムは初期設定フェーズで「信頼できる設定（trusted setup）」を必要とし、一連の初期パラメータを生成する。ここでの信頼の前提は、その設定が誠実に実行され、悪意ある行為や改ざんがなかったことにある。攻撃を受けた場合、無効な証明が作成される可能性がある。
STARK証明は、多項式の低次数特性を検証するための低次数テストの安全性を仮定している。また、ハッシュ関数がランダムオラクルのように振る舞うことも仮定している。
両システムの正しく実装されていることも、セキュリティ上の前提条件となる。
SMPCネットワークは以下の点に依存している：
-
SMPC参加者の中には「正直だが好奇心旺盛（honest but curious）」な者が含まれる可能性があり、他のノードと通信することで基礎情報へのアクセスを試みる。
-
SMPCネットワークの安全性は、参加者がプロトコルを正しく実行し、故意に誤りや悪意ある行動を起こさないという前提に依存している。
-
一部のSMPCプロトコルは、暗号パラメータや初期値を生成するための「信頼できる設定」フェーズを必要とする。ここでの信頼前提は、その設定が誠実に行われることである。
-
SMPCネットワークと同様に信頼前提は変わらないが、OTM（Off-The-Grid Multi-party Computation）の存在により、「正直だが好奇心旺盛」な参加者は存在しない。
OTMは参加者のプライバシーを保護することを目的としたマルチパーティ計算プロトコルである。計算中に参加者の入力データを公開しないことでプライバシーを守る。そのため、「正直だが好奇心旺盛」な参加者は存在せず、他のノードとの通信を通じて基礎情報を取得しようとしても不可能である。
明確な勝者はいるのか？ わからない。しかし、それぞれのアプローチには独自の利点がある。NMCはSMPCの明らかな進化のように見えるが、ネットワークはまだ本番稼働しておらず、実戦テストも受けていない。
ZK検証可能計算の利点は、それが安全でプライバシー保護されることにある。しかし、内蔵された秘密共有機能はない。証明生成と検証の非対称性は、検証可能な外部委託計算の理想的なモデルを作る。純粋にzk検証計算を使用するシステムでは、多数の計算を実行するために、コンピュータ（または単一ノード）が非常に強力である必要がある。プライバシーを守りながら負荷分散とバランスを実現するには、秘密共有が必要となる。この場合、SMPCやNMCのようなシステムを、LurkやRiscZeroのようなzkジェネレーターと組み合わせることで、強力な分散型検証可能外部委託計算インフラを構築できる。
今日のMPC／SMPCネットワークは集中化されている点が特に重要である。現在最大のMPCプロバイダーはSharemindであり、その上にZK検証レイヤーを追加することは有用かもしれない。分散型MPCネットワークの経済モデルはまだ成立していない。理論的にはNMCはMPCシステムの進化形だが、成功事例はまだ見られていない。
ZK証明方式の競争においては、勝者がすべてを独占するような展開にはならないだろう。各証明方式は特定のタイプの計算に最適化されており、万能のモデルは存在しない。計算タスクの種類は多岐にわたり、開発者が各証明システムでどのようなトレードオフをするかにも依存する。筆者は、STARKベースのシステム、SNARKベースのシステム、そしてそれらの将来の最適化が、ZKの未来においていずれも重要な役割を果たすと考えている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
IOSG Ventures
