ヴィタリック：効率向上のための新しいアイデア - 接着とコプロセッサ・アーキテクチャ

原題：Glue and coprocessor architectures

Author: Vitalik, Founder, Ether; Compiled by Deng Tong, Golden Finance

Special thanks to Justin Drake, Georgios Konstantopoulos, AndrejKarpathy、Michael Gao、Tarun Chitra、そしてフィードバックとコメントをくれた様々なFlashbots貢献者に感謝する。

現代の世界で行われているリソース集約的な計算を適度なレベルで詳細に分析すると、何度も見つかる特徴の1つは、計算が2つの部分に分けられるということです:

。

• 比較的少量の、複雑だがあまり計算集約的ではない「ビジネスロジック」

• 大量の、集約的だが高度に構造化された「高価な作業」。

これら 2 つの形式の計算は、異なる方法で処理するのが最善です。前者では、アーキテクチャはあまり効率的でないかもしれませんが、非常に汎用的である必要があり、後者では、アーキテクチャはあまり汎用的でないかもしれませんが、非常に効率的である必要があります。

この異なるアプローチの実際の例にはどのようなものがあるでしょうか?

まず、私が最もよく知っている環境であるイーサネット仮想マシン (EVM) を見てみましょう。これは、私が最近実行したEthernetトランザクションのgethデバッグトレースです。トランザクションは合計46,924ガスを消費し、以下のように分類できます:

• Basic cost: 21,000

• Calling data: 11,556

• EVMの実行：24,368

• SLOAD Opcode: 6,400

• SSTORE opcode: 10,100

• LOG opcode: 2,149

• Other: 6,719

ENSハッシュ更新時のEVMトレース。最後の列はガス消費量です。

この話の教訓は、実行のほとんど(EVMだけを見ると約73%、計算をカバーする基本コストの部分を含めると約85%)が、非常に少数の構造化された高価な操作、つまりストレージの読み取り、書き込み、ロギング、暗号化(基本コストには署名検証のための3,000が含まれ、EVMにはハッシュのための272も含まれます)に集中しているということです。残りの実行部分は "ビジネスロジック "である。calldataのビットをスワップして、セットしようとしているレコードのIDとセットするハッシュを抽出する、などである。トークン譲渡では、これは残高の加算と減算を含み、より高度なアプリケーションでは、これはループなどを含むかもしれません。

EVMでは、これら2つの実行形式は異なる方法で処理されます。高価な作業はまだEVMオペコード（SLOADなど）によってトリガーされますが、実際の計算の99％以上は、クライアント側のコード（またはライブラリ）内に直接書かれた特別なモジュールで行われます。

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

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

変圧器モデルのブロックの前方通過

ここで何が見えるでしょうか。実行される操作の構造を記述する、Pythonで書かれた比較的少量の「ビジネスロジック」が見えます。実際には、入力がどのようにフェッチされ、出力に対してどのようなアクションが実行されるかなどの詳細を決定する別のタイプのビジネスロジックがあります。しかし、個々の演算そのもの（self.norm、torch.cat、+、*、self.attn ......内の個々のステップ）を掘り下げていくと、ベクトル化された計算が見えてくる。最初の例と同様に、計算のごく一部がビジネスロジックに使用され、計算の大部分は大規模な構造化行列とベクトル演算に使用されます。

EVMの例と同様に、これら2種類の作業は2つの異なる方法で処理されます。高水準のビジネスロジックコードはPythonで書かれています。Pythonは非常に汎用的で柔軟な言語ですが、同時に非常に遅い言語でもあります。一方、集中的な演算は、高度に最適化されたコード、通常はGPU上で動作するCUDAコードで記述される。ASIC上でLLM推論が実行されるケースも増えてきています。

SNARKのような最新のプログラマブル暗号も、2つのレベルで同様のパターンに従っています。第一に、プルーバーは、上記のAIの例のように、ベクトル化された演算によって重い作業を行う高水準言語で書くことができます。私が作成した循環型STARKコードは、これを示している。第二に、暗号内で実行されるプログラム自体を、汎用のビジネスロジックと高度に構造化された高価な作業を分ける方法で書くことができる。

これがどのように機能するかを見るには、STARKが示す最新のトレンドの1つを見ればよい。汎用的で使いやすくするために、RISC-Vのような広く採用されている最小限の仮想マシン用にSTARKプローバを構築するチームが増えています。実行を証明する必要があるプログラムはすべてRISC-Vにコンパイルすることができ、そして証明者はそのコードのRISC-Vでの実行を証明することができます。

RiscZeroドキュメントからの図

これは非常に便利です。つまり、証明ロジックを一度書くだけでよく、それ以降は、証明を必要とするプログラムはどのような「伝統的な」証明ロジックでも使用できます。それ以降、証明を必要とするプログラムは、どのような「伝統的な」プログラミング言語でも書くことができます（例えば、RiskZeroはRustをサポートしています）。しかし問題がある。このアプローチには多くのオーバーヘッドが発生する。プログラム可能な暗号化はすでに非常に高価なものであり、RISC-Vインタープリターでコードを実行するオーバーヘッドが加わるのは大きすぎる。そこで開発者は、計算の大部分を占める特定の高価な演算（通常はハッシュと署名）を特定し、それらの演算を非常に効率的に証明する特別なモジュールを作るというトリックを思いついた。そして、非効率だが汎用的なRISC-Vの証明システムと、効率的だが特殊化された証明システムを組み合わせれば、両方の長所を生かすことができる。

マルチパーティ計算 (MPC) や完全同型暗号化 (FHE) など、ZK-SNARK 以外のプログラマブル暗号化も、同様のアプローチで最適化できるかもしれません。

全体として、この現象は何でしょうか?

現代のコンピューティングは、私が「グルーとコプロセッサ」アーキテクチャと呼ぶものに従うことが多くなっています。

これは単純化したものです。実際には、効率性と汎用性の間のトレードオフ曲線には、ほとんど常に2つ以上のレベルがあり、GPUや、業界で一般的に「コプロセッサ」と呼ばれるその他のチップは、CPUよりも汎用性が低いですが、ASICよりは汎用性が高いです。特殊化のトレードオフは複雑で、アルゴリズムのどの部分が5年後も変わらず、どの部分が半年後に変わるかについての予測や直感に左右される。ZK証明アーキテクチャにおいても、同様の多層的な専門化がしばしば見られる。しかし、大まかな思考モデルとしては、2層で十分である。

上記の例から、計算がこのように分割できることは確かに自然法則のように思えます。実際、何十年もの間、計算の専門化の例を見つけることができます。しかし、この分離はますます進んでいると思います。

CPUのクロック速度の向上が限界に達したのは最近のことなので、これ以上の向上は並列化によってのみ可能です。しかし、並列化について推論するのは難しいので、開発者は逐次的に推論し続け、並列化は特定の操作のために構築された専用モジュールに包まれたバックエンドで行わせる方が現実的であることがよくあります。

ビジネスロジックの計算コストが本当に無視できるほど高速になったのは最近のことです。この世界では、ビジネスロジックが実行されるVMを最適化して、開発者の使いやすさ、親しみやすさ、セキュリティなど、計算効率以外の目標を達成することは理にかなっています。同時に、専用の「コプロセッサ」モジュールは、効率のために設計し続けることができ、バインダとの比較的単純な「インターフェイス」から、セキュリティと開発者の使いやすさを得ることができます。

最も重要な高価な操作が何であるかは、明らかになりつつあります。モジュロ演算、楕円曲線の線形結合（別名マルチスカラー乗算）、高速フーリエ変換などです。この傾向は人工知能でも顕著になってきており、20年以上前からほとんどの計算が（精度の差はあるにせよ）「ほとんどが行列の乗算」である。同様の傾向は他の分野でも見られる。計算集約型の）計算では、20年前と比べて未知の部分がはるかに少なくなっている。

これは何を意味するのでしょうか?

1つの重要なポイントは、グルアーは優れたグルアーであるために最適化されるべきであり、コプロセッサーは優れたコプロセッサーであるために最適化されるべきであるということです。このことの意味を探るには、いくつかの重要な分野があります。

EVM

ブロックチェーン仮想マシン（EVMなど）は効率的である必要はありません。適切なコプロセッサ (別名「プリコンパイル」) を追加することで、非効率的な VM での計算も、ネイティブに効率的な VM での計算と同じくらい効率的になります。例えば、EVMの256ビット・レジスタは比較的オーバーヘッドが少なく、EVMのなじみやすさと既存の開発者エコシステムの恩恵は大きく、長期にわたります。EVMを最適化している開発チームは、並列性の欠如がスケーラビリティの大きな障害にならないことが多いことさえ分かっています。

EVMを改善する最善の方法は、(i) より優れたプリコンパイルまたは専用オペコードを追加すること、たとえばEVM-MAXとSIMDの組み合わせが理にかなっているかもしれません。

イーサネット・ヴァークル・ツリー提案のストレージ最適化では、隣接するストレージキーをまとめて、これを反映するようにガスコストを調整します。 このような最適化は、より良いプリコンパイルとともに、EVM自体を調整するよりも重要かもしれません。

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

ハードウェアレベルで現代のコンピューティングのセキュリティを向上させる上での大きな課題の1つは、その過度に複雑でプロプライエタリな性質です。チップは非常に効率的に設計されており、独自の最適化を必要とします。バックドアを隠すことは容易であり、サイドチャネルの脆弱性は常に発見されています。

さまざまな角度から、よりオープンでセキュアな代替手段を推進する努力が続けられている。一部のコンピューティングは、ユーザーの携帯電話を含む信頼された実行環境でますます行われるようになっており、ユーザーのセキュリティは向上しています。よりオープンソースのコンシューマ向けハードウェアを求める動きは続いており、最近ではUbuntuを実行するRISC-Vラップトップなどが勝利している。

Debianが動作するRISC-Vラップトップ

しかし、効率はまだ問題です。リンク先の記事の著者は次のように書いています:

RISC-Vのような新しいオープンソースのチップ設計は、すでに存在し、何十年もかけて改良されてきたプロセッサ技術に太刀打ちできそうにありません。進歩には常に出発点があります。

FPGA上にRISC-Vコンピュータを構築するこの設計のような、より偏執的なアイデアは、より大きなオーバーヘッドに直面しています。しかし、もしグルーイングやコプロセッサ・アーキテクチャが、このオーバーヘッドが実際には問題ではないことを意味するとしたらどうでしょうか。オープンでセキュアなチップはプロプライエタリなチップより遅くなることを受け入れ、投機的実行や分岐予測などの一般的な最適化は必要に応じて放棄し、最も集約的な特定のタイプの計算のために（必要に応じてプロプライエタリな）ASICモジュールを追加することでこれを補おうとしたらどうだろう？機密性の高い計算は、セキュリティ、オープンソース設計、サイドチャネル耐性のために最適化された「メインチップ」で行うことができる。より集中的な計算（ZK証明やAIなど）はASICモジュールで行われ、ASICモジュールは実行中の計算に関する情報をより少なくすることができる（場合によっては、暗号的な目隠しによって、情報がゼロになることさえある）。

暗号技術

もう1つの重要なポイントは、暗号技術、特にプログラマブル暗号技術が主流になることについて、すべてが非常に楽観的だということです。ある種のハッシュ関数のオーバーヘッドは、計算を直接実行するよりも数百倍高いだけであり、アーティファクト（主に行列の乗算）のオーバーヘッドは非常に低いです。完全に汎用的なVM実行、特にRISC-Vインタプリタで実行される場合、約10,000倍のオーバーヘッドが発生し続ける可能性がありますが、本稿で説明する理由から、これは問題ではありません。

AIモデル推論における最大の構成要素である、行列の乗算に特化したMPCの簡略図です。モデルと入力を非公開にする方法など、詳細はこちらの記事をご覧ください。

グルーレイヤーが必要なのは使い慣れたものだけであり、効率的なものである必要はないという考えに対する1つの例外は、待ち時間と、それほどではありませんが、データ帯域幅です。計算が、同じデータに対して何十回も繰り返される重い操作を含む場合 (暗号やAIの場合のように)、非効率なグルー層によって引き起こされる待ち時間は、実行時に大きなボトルネックになる可能性があります。このように、グルーレイヤーにも、より具体的ではありますが、効率性の要件があります。