原文: A Developer's Guide to the zkGalaxy

昨年の夏、Vitalik はさまざまな種類の zkEVM (ゼロ知識イーサリアム仮想マシン) の概要を説明したブログ投稿を書きました。 Vitalik は、パフォーマンスと互換性を定義し、トレードオフします。

これは、zkEVM 対応メソッドを区別するための非常に便利なヒューリスティックです。ただし、zkEVM は、ゼロ知識アプリケーションを構築する可能なすべての方法のサブセットです。 zk 計算の固有の特性、つまり単純さ、ゼロ知識、正確性を活用したいプログラマーにとって、zkEVM は最良の選択ではない可能性があります。この記事では、開発ツールセット全体を説明することで、開発者が意思決定プロセス中に適切な zk スタックを選択するのに役立つガイドを提供したいと考えています。

抽象的な複雑さの力

ここ 1 ～ 2 年で、ZK ツールは大幅に改善されました。通常のソフトウェアの開発者は、基礎となる難解な数学や工学を深く理解することなく、zk の強力な特性を活用できます。一方で、上級ユーザー向けのツールが急増し、zk の専門家が zk スタックを非常にきめ細かく制御できるようになりました。

最新のソフトウェアは、専門家の生産性を最大化するために、無数の抽象化レイヤーに基づいて構築されています。エンジニアリングにおける抽象化には、いくぶん直感的である多くの利点があります。Web 開発者は、オペレーティング システムがどのように機能するかを深く理解する必要はありません。

優れた再利用可能な抽象化レイヤーを構築するための鍵は、1 つのレイヤーの複雑さをカプセル化し、スタック内の上位レイヤーにシンプルだが表現力豊かなインターフェイスを提供することです。これを正しく実行すると、さまざまな専門分野や知識を持つ開発者がスタック全体で有用なツールを構築できるようになります。

画像の説明

zk スタックとレイヤーのツール/テクニックの例

低レベルのzk開発

Arkworks-rs

Arkworks-rs は、zkSNARK アプリケーションのサブコンポーネントの効率的かつ安全な実装を提供する Rust ライブラリのエコシステムです。 Arkworks は、他の既存のライブラリとの共通性を再実装することなく、zk アプリケーションのソフトウェア スタックをカスタマイズするために必要なインターフェイスを開発者に提供します。

アドバンテージ

アドバンテージ

モジュール化による柔軟性

コードの重複を減らす

エンジニアリングコストの削減

監査/バグの対象領域を削減する

大規模なリファクタリングを行わずにコンポーネントをアップグレード

欠点がある

欠点がある

ソフトウェア スタック全体に関する深い知識が必要です

正しく理解していないと、制御しすぎるとフットガンにつながる可能性があります

きめ細かい制御には、スタックのすべてのレベルにおける専門知識が必要です。

Arkworks はいくつかの賢明なデフォルトを提供します。

zk ドメイン固有言語 (DSL)

何らかの計算に関する証明を作成するには、まずその計算を zkSNARK システムが理解できる形式で表現する必要があります。一部のドメイン固有言語は、アプリケーション開発者がこの方法で計算を表現できるようにするプログラミング言語を作成しました。これらの言語には、Aztec Noir、Starknet の Cairo、Circom、ZoKrates、Aleo の Leo などが含まれます。基礎となる証明システムと数学的詳細は、通常、アプリケーション開発者には公開されません。

開発者の経験

zkApps の開発者は、ドメイン固有の言語でプログラムを作成することに熟練している必要があります。これらの言語の中には、よく知られたプログラミング言語によく似ているものもあれば、学習するのが非常に難しいものもあります。それらのいくつかを分析してみましょう。

カイロ - Starknet でアプリケーションを構築するには Starkware DSL が必要です。 Cairo zkVM で解釈できる Cairo 固有のアセンブリ言語にコンパイルされます。

ZoKrates - ZoKrates は、回路を作成するための高級言語を含む、SNARK の一般的なニーズに対応するツールキットです。 ZoKrates は曲線、証明スキーム、バックエンドに関してある程度の柔軟性を備えており、開発者は単純な CLI 引数を介してホット スワップを行うことができます。

Circom — Circom は電気回路の構築に特化した言語です。現在、それは回路を作成するための実際の言語です。この言語は特に人間工学的ではないため、開発者は回路が記述されていることがはっきりとわかります。

Leo - Leo は、Aleo ブロックチェーンの言語として開発されました。 Leo には、ブロックチェーン内の状態遷移に特化した Rust のような構文がいくつかあります。

Noir - Rust にインスピレーションを得た構文。言語自体ではなく IR を中心に構築されているため、任意のフロントエンドを持つことができます。

誰のため

zk の独自のプロパティをアプリケーションで活用したいと考えているアプリケーション開発者。

アドバンテージ

アドバンテージ

ユーザーは基礎となる zk の詳細を理解する必要はありません

ある程度の制作経験があれば、すぐに使用できます

オンチェーンで検証可能

欠点がある

欠点がある

ユーザーは新しい DSL を学ぶ必要がある

これらの言語に関するツールとサポートはサイロ化されています

(現時点では) 基礎となるプルーフスタックを制御することはほとんどありません。

zkEVMs

zkEVM の主な目的は、イーサリアムの状態遷移を取得し、簡潔なゼロ知識の正当性証明を使用してその妥当性を証明することです。 Vitalik の投稿で述べたように、これを行う方法は数多くありますが、微妙な違いとそれに応じたトレードオフがあります。

これらすべてのアプローチの主な技術的な違いは、言語スタックの正確にどこで計算が証明システムで使用できる形式に変換されるか (算術化) です。一部の zkEVM では、これは高級言語 (Solidity、Vyper、Yul) で行われますが、他のものはオペコード レベルに至るまで EVM を証明しようとします。これらのアプローチ間のトレードオフについては、Vitalik の投稿で詳しく説明されていますが、一文で要約します。スタック上で発生する変換/演算が少なくなるほど、パフォーマンス上のペナルティが大きくなります。

高い運用コスト

仮想マシンのプルーフを作成する際の主な課題は、回路のサイズが、実行される各命令の可能なすべての命令のサイズに比例して増大することです。これは、回路は各プログラムでどの命令が実行されるかを知らないため、すべての命令をサポートする必要があるためです。

汎用回路では、実行される各命令のコストは、サポートされているすべての命令の合計に比例します。

これが実際に意味するのは、たとえ最も単純な命令を実行しているだけであっても、最も高価な命令に対して (パフォーマンス コスト) を支払うことになるということです。これは、汎用性とパフォーマンスの間の直接のトレードオフにつながります。汎用性を高めるために命令を追加すると、証明するすべての命令に対して料金を支払うことになります。これは汎用回路の根本的な問題です。

しかし、IVC (Incremental Verifiable Computing) などの新しい開発により、計算をより小さなチャンクに分割し、それぞれに専用の小さなサブ回路を設けることで、この制限を改善できます。

今日の zkEVM 実装は、この問題を軽減するためにさまざまな戦略を使用しています。たとえば、zkSync は、より高価な操作 (主にハッシュなどの暗号化プリコンパイルとその他のいくつか) を削除します。

zkEVM の理想的な顧客は、L1 イーサリアムでのトランザクションよりも桁違いに安価である必要があるスマート コントラクト アプリケーションです。これらの開発者は、zk アプリケーションを最初から作成するための専門知識や帯域幅を必ずしも持っているわけではありません。したがって、Solidity などの使い慣れた高水準言語でアプリケーションを作成することが望ましいです。

多数の開発チーム

スケーリング イーサリアムは、現在、zk テクノロジーの最も需要の高いアプリケーションです。

開発者の経験

開発者の経験

zkEVM の目標は、現在のイーサリアム開発にできるだけ近い開発者エクスペリエンスをサポートすることです。 Solidity が完全にサポートされているため、チームは複数のコードベースを構築および保守する必要がありません。 zkEVM は、適切な時間内に適切なサイズのプルーフを生成できるようにするために、ある程度の互換性を犠牲にする必要があるため、これは多少現実的ではありません。

zkSync とスクロール

zkSync と Scroll の主な違いは、スタック上で算術演算を実行する場所とタイミングです。つまり、通常の EVM 構造から SNARK に適した表現に移行する場所です。 zkSync の場合、これは YUL バイトコードを独自のカスタム zk 命令セットに変換するときに発生します。スクロールの場合、これは実際の実行トレースが実際の EVM オペコードで生成される最後に発生します。

したがって、zkSync の場合、zk バイトコードが生成されるまでは、すべてが EVM と対話するのと同じです。 Scroll の場合、実際のバイトコードが実行されるまではすべて同じです。これは、パフォーマンスをサポートと引き換えにする微妙な違いです。たとえば、zkSync は、完全に異なるバイトコードであるため、すぐに使用できるデバッガーのような EVM バイトコード ツールをサポートしません。 Scroll は命令セットから優れたパフォーマンスを引き出すのが難しいですが、zk 用に設計されたものではありません。どちらの戦略にも長所と短所があり、最終的には相対的な成功に影響を与える可能性のある外因的要因が数多くあります。

zkLLVM回路コンパイラ

詳細に説明したように、zk アプリケーションの開発には無数の異なるオプションがあり、それぞれに独自のトレードオフがあります。この図は、zk の専門知識のレベルとパフォーマンスのニーズに基づいて、ジョブに最適なツールを選択するためのこの決定マトリックスを要約するのに役立ちます。これは完全なリストではなく、zk の開発に応じて更新されます。

zkLLVM は、既存の LLVM インフラストラクチャの拡張として設計されており、Rust、C、C++ などの多くの高級言語をサポートする業界標準のツールチェーンです。

走り方

何らかの計算を証明したいユーザーは、単純に計算を C++ で実装できます。 zkLLVM は、修正された Clang コンパイラ (現在は C++) をサポートする高レベルのソース コードを取得し、回路の中間表現を生成します。この時点で、回路は検証の準備ができていますが、ユーザーは何らかの動的入力に対して回路を検証したい場合があります。動的入力を処理するために、zkLLVM にはアロケーターと呼ばれる追加コンポーネントがあり、完全に前処理され、回路とともに証明できる準備が整ったすべての入力と証人を含む割り当てテーブルを生成します。

これら 2 つのコンポーネントはプルーフを生成するために必要です。理論的には、ユーザーが自分で証明を生成することもできますが、これはやや特殊な計算タスクであるため、ハードウェアを備えた他の誰かがそれを行うのに費用がかかる可能性があります。このカウンターパーティ発見メカニズムの場合、=nil; 財団は、証明者が料金を支払ったユーザーの計算を証明するために競う「証明市場」も構築します。この自由市場の力学により、証明者は最も価値のある証明タスクを最適化することになります。

長所と短所を比較検討する

証明される各計算タスクは固有であり、異なる回路を生成するため、証明者が処理できる必要がある回路の数は無限です。この強制された一般性により、個々の回路の最適化が困難になります。プルーフマーケットの導入により、市場が価値があると判断した回路の特殊化が可能になります。この市場がなければ、この自然なコールドスタートの問題により、この回路を最適化するよう検証者を説得するのは困難でしょう。

アドバンテージ

アドバンテージ

ユーザーは使い慣れた高級言語でコードを作成できます

すべての zk の内部構造は抽象化されており、ユーザーの影響を受けません。

特定のものに依存しない"仮想マシン"欠点がある

欠点がある

各プログラムには異なる回路があります。最適化が難しい。 (市場がこの問題を部分的に解決していることを証明しています)

内部 zk ライブラリの交換/アップグレードは簡単ではありません (フォークが必要)

zkVM

zkVM はすべての zk 仮想マシンのスーパーセットを表しますが、zkEVM は特定のタイプの zkVM であり、今日の人気のため別のトピックに値します。カスタム暗号 VM に加えて、より一般的な ISA ベースの zkVM の構築に取り組んでいるプロジェクトが他にもいくつかあります。

システムは、EVM を認証するのではなく、新しい VM の RISC-V や WASM などの別の命令セット アーキテクチャ (ISA) を認証できます。これらの汎用 zkVM に取り組んでいる 2 つのプロジェクトは、RISC Zero と zkWASM です。

画像の説明

Risc Zero

リスクゼロプルーフ生成のためのハイレベルアーキテクチャ

RISC Zero は、RISC-V アーキテクチャ上で実行されるあらゆる計算を証明できます。 RISC-V は、人気が高まっているオープンソースの命令セット アーキテクチャ (ISA) 標準です。 RISC (縮小命令セット コンピューター) の考え方は、複雑さを最小限に抑えた非常にシンプルな命令セットを構築することです。これは、スタックの上位にある開発者がこのアーキテクチャを使用して命令を実装すると、ハードウェアの実装が簡素化される一方で、最終的に大きな負荷がかかることを意味します。

この哲学はコンピューティング全般にも当てはまり、ARM チップは RISC スタイルの命令セットを活用しており、モバイル チップ市場を支配し始めています。命令セットが単純であればあるほど、エネルギー効率とチップ面積効率も高くなることがわかりました。

この類推は、zk 証明を生成する効率に非常によく当てはまります。前に説明したように、zk の実行軌跡を証明するときは、軌跡内の各項目のすべての命令のコストの合計を支払うことになるため、単純で命令の総数が少ない方が良いです。

どのように動作します

開発者の観点から見ると、RISC Zero を使用して zk 証明を処理することは、AWS Lambda 関数を使用してバックエンド サーバー アーキテクチャを処理することによく似ています。開発者はコードを記述するだけで RISC Zero または AWS Lambda と対話し、サービスはバックエンドの複雑さをすべて処理します。

RISC Zero の場合、開発者は Rust または C++ (最終的には RISC-V をターゲットとするもの) を作成します。次に、システムは、コンパイル中に生成された ELF ファイルを仮想マシン回路の入力コードとして受け入れます。開発者は単にproof を呼び出すだけで、レシート (実行トレースを含むzkproof) オブジェクトが返され、誰でもどこからでも「verify」を呼び出すことができます。開発者の観点からは、zk がどのように機能するかを理解する必要はなく、基礎となるシステムがこれらすべての複雑さを処理します。

このような共通インターフェイスをサポートするには、(プルーフ サイズと生成速度の点で) 多くのオーバーヘッドが必要になります。

既存のライブラリを幅広くサポートできるようにするには、プルーフ生成技術の大幅な改善が必要です

事前に構築された再利用可能な回路

ブロックチェーン アプリケーションなどに特に役立ついくつかの基本的で再利用可能な回路については、チームがこれらの回路を構築して最適化している場合があります。特定のユースケースに応じて入力を行うだけです。たとえば、マークルの Proofs of Inclusion は、暗号通貨アプリケーション (エアドロップ リスト、Tornado Cash など) で一般的に必要とされるものです。アプリケーション開発者は、これらの実証済みのコントラクトをいつでも再利用し、その上のいくつかのレイヤーを変更するだけで独自のアプリケーションを作成できます。

たとえば、Tornado Cash の回路は、プライベート エアドロップ アプリケーションやプライベート投票アプリケーションに再利用できます。 Manta と Semaphore は、このような汎用回路ガジェットを含む完全なツールキットを構築しています。これは、基盤となる zk 月の数学に関する知識がほとんどまたはまったくなくても、Solidity コントラクトで使用できます。

詳細に説明したように、zk アプリケーションの開発には無数の異なるオプションがあり、それぞれに独自のトレードオフがあります。

この図は、zk の専門知識のレベルとパフォーマンスのニーズに基づいて、ジョブに最適なツールを選択するためのこの決定マトリックスを要約するのに役立ちます。これは完全なリストではなく、zk の開発に応じて更新されます。

zkGalaxy アプリケーション開発者ガイド

1. 低レベルの Snark ライブラリ

該当シーン

プルーフスタック全体に対するきめ細かい制御が必要

共通コンポーネントの再構築を避ける

スキーム、曲線、その他の低レベルのプリミティブのさまざまな組み合わせを証明してみてください。

適用できない

高度な証明インターフェイスを探している初心者

オプションのツール

Arkworks-rs

2. zk DSLs

該当シーン

実証済みの言語を使用したい

必要な回路サイズは最小限、抽象化を控える意欲

適用できない

証明バックエンドに対するきめ細かい制御が必要 (現在、一部の DSL ではバックエンドを交換できます)

オプションのツール

Circom

Aztec Noir

Cairo

ZoKrates

Leo

3.zkコンパイラ

該当シーン

汎用回路のオーバーヘッドを負担したくない

使い慣れた言語で回路を書きたい

高度にカスタマイズされた回路が必要

適用できない

基礎となる暗号プリミティブを制御したい

すでに高度に最適化された回路が必要です

オプションのツール

nil zkLLVM

4.zkEVM

該当シーン

EVM 上で dApp がすでに実行されている

ユーザーに安い取引を提供する必要がある

新しいチェーンへのデプロイに必要な労力を最小限に抑えたい

zk (圧縮) の単純さだけを気にする

適用できない

完全なEVM同等性が必要

zk を必要とするプライバシー プロパティ

非ブロックチェーンのユースケースがある

オプションのツール

zksync 2.0 

Polygon zkEVM

Scroll

Starknet

5.zkVM

該当シーン

高級言語でコードを書きたい

実装の正しさを証明する必要がある

この実行の一部の入力情報を検証者から隠す必要がある

zk の専門知識はほとんどまたはまったくありません

適用できない

非常に低遅延の環境 (それでも遅いですが)。

(現時点では) 巨大なプログラムがあります。

オプションのツール

RISC Zero

zkWASM

6. 事前に構築された再利用可能な回路

該当シーン

Merkle コンテインメントなどの一般的な zk ビルディング ブロックに依存するスマート コントラクト アプリケーションがあります。

ZK の内部にあるものについての専門知識はほとんどありません。

適用できない

高度に専門化されたニーズがある

事前構築された回路ではサポートされていないユースケース

結論は

Manta Network

Semaphore

結論は

ありがとう

ありがとう

この記事の編集は、DAOrayaki コミュニティからのサポートとフィードバックを受けています。

原文: A Developer's Guide to the zkGalaxy