Vitalikの新しい記事：接着剤と協調プロセッサアーキテクチャ、効率と安全性を向上させる新しい構想

原文タイトル：《Glue and coprocessor architectures》

著者：Vitalik Buterin、イーサリアム創設者

編訳：邓通、金色财经

特別感謝 Justin Drake、Georgios Konstantopoulos、Andrej Karpathy、Michael Gao、Tarun Chitra およびさまざまな Flashbots の貢献者からのフィードバックとコメント。

もしあなたが中程度の詳細で現代世界におけるリソース集約型計算を分析すると、繰り返し発見される特徴の一つは、計算が二つの部分に分けられるということです：

• 相対的に少量の複雑だが計算量の少ない「ビジネスロジック」；
• 大量で密度が高いが高度に構造化された「高コストの作業」。

これら二つの計算形式は、異なる方法で処理するのが最適です：前者は、効率が低いかもしれませんが非常に高い汎用性を持つアーキテクチャが必要です；後者は、汎用性が低いかもしれませんが非常に高い効率を持つアーキテクチャが必要です。

実践におけるこの異なる方法の例は何ですか？

まず、私が最もよく知っている環境、イーサリアム仮想マシン (EVM) を見てみましょう。これは私が最近行ったイーサリアム取引の geth デバッグトレースです：ENS 上で私のブログの IPFS ハッシュを更新する取引。この取引は合計で 46924 gas を消費し、以下のように分類できます：

• 基本コスト：21,000
• 呼び出しデータ：1,556
• EVM 実行：24,368
• SLOAD オペコード：6,400
• SSTORE オペコード：10,100
• LOG オペコード：2,149
• その他：6,719

ENS ハッシュ更新の EVM トレース。倒数第二列は gas 消費。

この話の教訓は：実行の大部分（EVM のみを見れば約 73%、基本コスト部分を含めれば約 85%）が、極少数の構造化された高コストの操作に集中しているということです：ストレージの読み書き、ログ、暗号化（基本コストには署名検証のための 3000 が含まれ、EVM にはハッシュのための 272 も含まれます）。残りの実行は「ビジネスロジック」です：calldata のビットを交換して、私が設定しようとしているレコードの ID とそれに設定したハッシュを抽出するなどです。トークン転送では、残高の追加と減算が含まれ、高度なアプリケーションではループなどが含まれる可能性があります。

EVM では、これら二つの実行形式は異なる方法で処理されます。高度なビジネスロジックは、通常は Solidity というより高級な言語で書かれ、EVM にコンパイルされます。高コストの作業は EVM オペコード（SLOAD など）によってトリガーされますが、99% 以上の実際の計算は、クライアントコード（さらにはライブラリ）内部に直接書かれた専用モジュールで行われます。

このパターンの理解を深めるために、別の文脈で探ってみましょう：Python で書かれた AI コードを使用する torch。

トランスフォーマーモデルの一つのブロックの前方伝播

ここで何を見ていますか？私たちは、実行されている操作の構造を記述する相対的に少量の「ビジネスロジック」を見ています。実際のアプリケーションでは、入力を取得する方法や出力に対して実行する操作などの詳細を決定する別のタイプのビジネスロジックもあります。しかし、各個別の操作自体（self.norm、torch.cat、+、*、self.attn 内部の各ステップ……）を深く掘り下げると、ベクトル化計算が見えてきます：同じ操作が大量の値を並行して計算します。最初の例と同様に、ビジネスロジックには少量の計算が使われ、大部分の計算は大規模な構造化行列とベクトル演算の実行に使われます ------ 実際には、大部分は単なる行列乗算です。

EVM の例と同様に、これら二つのタイプの作業は二つの異なる方法で処理されます。高度なビジネスロジックコードは Python で書かれており、非常に汎用性が高く柔軟な言語ですが、非常に遅いです。私たちは単に低効率を受け入れます、なぜならそれは総計算コストのごく一部にしか関与しないからです。同時に、密集した操作は高度に最適化されたコードで書かれ、通常は GPU 上で実行される CUDA コードです。私たちはますます LLM 推論が ASIC 上で行われるのを目にしています。

現代のプログラム可能な暗号学、例えば SNARK は、二つのレベルで再び類似のパターンに従います。まず、証明器は高級言語で書かれることができ、重い作業はベクトル化操作によって行われます。ここでの円形 STARK コードがそれを示しています。次に、暗号学内部で実行されるプログラム自体は、一般的なビジネスロジックと高度に構造化された高コストの作業の間で分割される方法で書かれることができます。

その仕組みを理解するために、STARK 証明の最新のトレンドの一つを見てみましょう。一般的で使いやすくするために、チームはますます広く採用されている最小仮想マシン（RISC-V など）用の STARK 証明器を構築しています。実行状況を証明する必要があるプログラムは、すべて RISC-V にコンパイルされ、その後、証明器はそのコードの RISC-V 実行状況を証明できます。

RiscZero ドキュメントからの図表

これは非常に便利です：これは、私たちが一度だけ証明ロジックを書く必要があり、その時から、証明が必要な任意のプログラムは任意の「従来の」プログラミング言語で書くことができることを意味します（例えば、RiskZero は Rust をサポートしています）。しかし、問題があります：このアプローチは大きなオーバーヘッドを生じます。プログラム可能な暗号はすでに非常に高価です；RISC-V インタプリタに実行コードのオーバーヘッドを追加するのはあまりにも多すぎます。したがって、開発者はトリックを考え出しました：計算の大部分を構成する特定の高コストの操作（通常はハッシュと署名）を特定し、それらの操作を非常に効率的に証明するための専用モジュールを作成します。次に、低効率だが汎用的な RISC-V 証明システムと、高効率だが専門的な証明システムを組み合わせるだけで、両方の利点を得ることができます。

ZK-SNARK 以外のプログラム可能な暗号、例えば多者計算 (MPC) や完全同型暗号 (FHE) も、同様の方法で最適化される可能性があります。

全体的に見て、現象はどうなっていますか？

現代の計算はますます私が言うところの「グルーとコプロセッサアーキテクチャ」に従っています：あなたには高い汎用性を持つが効率が低い中央の「グルー」コンポーネントがあり、データを一つまたは複数のコプロセッサコンポーネント間で転送する役割を果たします。これらのコプロセッサコンポーネントは低い汎用性を持ちますが、高い効率を持っています。

これは単純化されたものです：実際には、効率と汎用性の間のトレードオフ曲線はほぼ常に二つ以上のレベルがあります。GPU や業界で一般に「コプロセッサ」と呼ばれる他のチップは、CPU よりも汎用性が低いですが、ASIC よりは汎用性があります。専門化のトレードオフは複雑で、どのアルゴリズムの部分が五年後も変わらず、どの部分が六ヶ月後に変わるかの予測と直感に依存しています。ZK 証明アーキテクチャでは、類似の多層専門化がよく見られます。しかし、広範な思考モデルにおいては、二つのレベルを考慮するだけで十分です。多くの計算分野で同様の状況が見られます：

上記の例から、計算は確かにこのように分割できることが示されており、これは自然法則のように思えます。実際、計算の専門化の例は何十年も前から見つけることができます。しかし、私はこの分離が増加していると考えています。これには理由があります：

私たちは最近、CPU のクロック速度向上の限界に達したため、さらなる利益を得るには並列化が必要です。しかし、並列化は推論が難しいため、開発者にとっては、順次推論を続け、並列化をバックエンドで発生させる方が実際的であることが多く、特定の操作のために構築された専用モジュールにパッケージ化されます。

計算速度は最近非常に速くなり、ビジネスロジックの計算コストは実際に無視できるほどになりました。この世界では、計算効率以外の目標を達成するためにビジネスロジックの実行を最適化する VM を持つことも意味があります：開発者の使いやすさ、親しみやすさ、安全性、その他の類似の目標です。同時に、専用の「コプロセッサ」モジュールは効率のために設計され続け、グルーとの相対的にシンプルな「インターフェース」からその安全性と開発者の使いやすさを得ることができます。

最も重要な高コストの操作は何かがますます明確になっています。これは暗号学において最も顕著であり、どのタイプの特定の高コストの操作が最も使用される可能性があるか：モジュラス演算、楕円曲線の線形結合（別名マルチスカラー乗算）、高速フーリエ変換などです。人工知能においても、この状況はますます明らかになり、20年以上にわたり、大部分の計算は「主に行列乗算」であり続けています（精度レベルは異なります）。他の分野でも同様の傾向が見られます。20年前と比べて、（計算集約型）計算における未知の未知数ははるかに少なくなっています。

これは何を意味しますか？

重要な点は、グルー（Glue）は良いグルー（Glue）になるように最適化されるべきであり、コプロセッサ（coprocessor）も良いコプロセッサ（coprocessor）になるように最適化されるべきだということです。私たちはいくつかの重要な分野でこれが意味することを探ることができます。

EVM

ブロックチェーン仮想マシン（例えば EVM）は効率的である必要はなく、親しみやすさが必要です。正しいコプロセッサ（別名「プリコンパイル」）を追加するだけで、非効率的な VM 内の計算は実際にネイティブな効率的な VM 内の計算と同じくらい効率的にすることができます。例えば、EVM の 256 ビットレジスタが生じるオーバーヘッドは比較的小さく、EVM の親しみやすさと既存の開発者エコシステムがもたらす利点は巨大で持続的です。EVM を最適化する開発チームは、並列化の欠如が通常はスケーラビリティの主要な障害ではないことを発見しました。

EVM を改善する最良の方法は、おそらく (i) より良いプリコンパイルや専用オペコードを追加すること、例えば EVM-MAX と SIMD の組み合わせが合理的である可能性があり、(ii) ストレージレイアウトを改善すること、例えば、Verkle ツリーの変更が副作用として、隣接するストレージスロットへのアクセスコストを大幅に削減することです。

イーサリアム Verkle ツリー提案におけるストレージ最適化、隣接するストレージキーを一緒に配置し、そのことを反映するようにガスコストを調整します。このような最適化は、EVM 自体を調整するよりも重要である可能性があります。

セキュアコンピューティングとオープンハードウェア

ハードウェアレベルで現代の計算のセキュリティを向上させる大きな課題は、その過度に複雑で専有的な性質です：チップ設計は効率的である必要があり、これには専有的な最適化が必要です。バックドアは簡単に隠され、サイドチャネルの脆弱性は絶えず発見されています。

人々は、よりオープンで安全な代替案を推進するために、さまざまな角度から努力を続けています。計算はますます信頼された実行環境で行われるようになり、ユーザーの携帯電話上での実行を含め、ユーザーのセキュリティが向上しています。よりオープンソースの消費者ハードウェアを推進する運動は続いており、最近では Ubuntu を実行する RISC-V ノートパソコンのような勝利を収めています。

Debian を実行する RISC-V ノートパソコン

しかし、効率は依然として問題です。上記のリンク記事の著者は次のように書いています：

RISC-V のような新しいオープンソースチップ設計は、すでに存在し数十年にわたって改善されてきたプロセッサ技術と競争することはできません。進歩には常に出発点があります。

より偏執的な考え、例えば FPGA 上に RISC-V コンピュータを構築するという設計は、より大きなオーバーヘッドに直面しています。しかし、もしグルーとコプロセッサアーキテクチャがこのオーバーヘッドが実際には重要でないことを意味するなら、どうなるでしょうか？もし私たちがオープンで安全なチップが専有チップよりも遅くなることを受け入れ、必要であれば推測実行や分岐予測などの一般的な最適化を放棄し、最も密集した特定のタイプの計算のために（必要であれば専有的な）ASIC モジュールを追加することでそれを補おうとするなら、どうなるでしょうか？敏感な計算は「メインチップ」で行われ、そのチップは安全性、オープンソース設計、サイドチャネル耐性のために最適化されます。より密集した計算（例えば ZK 証明、AI）は ASIC モジュールで行われ、これらは実行されている計算に関する情報をあまり持たない（場合によっては、暗号化されたブラインド化を通じて、場合によってはゼロ情報でさえ）でしょう。

暗号学

もう一つの重要な点は、これが暗号学、特にプログラム可能な暗号が主流になることに非常に楽観的であるということです。私たちはすでに SNARK、MPC、その他の設定で、特定の高度に構造化された計算の超最適化された実装を見ています：特定のハッシュ関数のオーバーヘッドは、直接計算を実行するよりも数百倍高いだけであり、人工知能（主に行列乗算）のオーバーヘッドも非常に低いです。GKR などのさらなる改善がこのレベルをさらに低下させる可能性があります。完全に汎用的な VM 実行、特に RISC-V インタプリタで実行される場合、約一万倍のオーバーヘッドを生じる可能性がありますが、本文で説明した理由から、これは重要ではありません：計算の最も密集した部分をそれぞれ効率的な専用技術で処理する限り、総オーバーヘッドは制御可能です。

AI モデル推論の最大コンポーネントである行列乗算専用 MPC の簡略図。モデルと入力のプライバシーを保持する方法については、本文を参照してください。

「グルー層は親しみやすさが必要で、効率は必要ない」という考えの一つの例外は遅延であり、データ帯域幅の点でも小さな程度であります。もし計算が同じデータに対して数十回の重い操作を繰り返す場合（暗号学や人工知能のように）、非効率的なグルー層によって生じる遅延は実行時間の主要なボトルネックになる可能性があります。したがって、グルー層にも効率の要求があり、これらの要求はより具体的です。

結論

全体的に見て、私は上記のトレンドが複数の視点から非常に前向きな発展であると考えています。まず、これは開発者の使いやすさを維持しながら計算効率を最大化する合理的な方法であり、両者の利益を同時に得ることができます。特に、クライアント側で専門化を実現することで、私たちはユーザーのハードウェア上で敏感で性能要求の高い計算（例えば ZK 証明、LLM 推論）を実行する能力を向上させます。次に、これは効率の追求が他の価値、最も明白なものは安全性、オープン性、シンプルさを損なわないことを確保するための巨大な機会の窓を創出します：コンピュータハードウェアにおけるサイドチャネルの安全性とオープン性、ZK-SNARK における回路の複雑性の低減、仮想マシン内の複雑性の低減。歴史的に見て、効率の追求はこれらの他の要因を二次的な地位に追いやってきました。グルーとコプロセッサアーキテクチャがあれば、それはもはや必要ありません。機械の一部は効率を最適化し、別の部分は汎用性や他の価値を最適化し、両者が協調して機能します。

このトレンドは暗号学にも非常に有利です。なぜなら、暗号学自体が「高コストの構造化計算」の主要な例であり、このトレンドはその発展を加速させているからです。これは安全性を向上させるためのもう一つの機会を追加します。ブロックチェーンの世界では、安全性の向上も可能になります：私たちは仮想マシンの最適化を心配する必要が少なくなり、むしろプリコンパイルや仮想マシンと共存する他の機能の最適化に焦点を当てることができます。

第三に、このトレンドは規模が小さく新しい参加者に参加の機会を提供します。もし計算がそれほど単一でなく、よりモジュール化されるなら、参入障壁は大幅に低下します。特定のタイプの計算の ASIC を使用する場合でも、何かを成し遂げる可能性があります。ZK 証明の分野や EVM 最適化においても同様です。ほぼ最前線の効率を持つコードを書くことがより容易でアクセスしやすくなります。このようなコードの監査や形式的検証もより容易でアクセスしやすくなります。最後に、これら非常に異なる計算分野がいくつかの共通のパターンに収束しているため、それらの間により多くの協力と学習の余地があります。