zkGalaxy の開発者ガイド

これは、zkEVM をサポートするためのアプローチを区別するのに非常に役立つヒューリスティックです。 ただし、zkEVM は、ゼロ知識アプリケーションを構築するために考えられるすべての方法のサブセットです。 zk 計算の固有の特性を活用したいプログラマーの場合、つまり 簡潔さ、知識ゼロ、正確さ、zkEVM は最良の選択ではない可能性があります。 開発者ツールのセット全体をレイアウトすることで、アプリケーションに適した zk スタックに関する意思決定プロセスを支援するガイドを提供したいと考えています。

過去 XNUMX ～ XNUMX 年で、zk ツールには多大な進歩がありました。 彼らは、通常のソフトウェア開発者が、威圧的な基礎となる数学や工学を深く理解していなくても、zk の強力な特性を活用できるところまで来ています。 その一方で、zk の専門家が zk スタックを非常に細かく制御できるようにする、パワーユーザー向けのツールが急増しています。

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

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

当然のことながら、これらと同じ原則が zk システムにも適用されます。これらの抽象化レイヤーは、zk の初心者が今日それらを使用してアプリケーションを構築するのに十分なほど成熟しています。

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

Arkworks 以前は、新しい zk アプリケーションを作成する唯一の方法は、すべてをゼロから構築することでした。 カスタムビルドの垂直統合ツールに対する Arkworks-rs の主な利点は、柔軟性のレベル、重複するエンジニアリングの削減、および監査作業の削減です。 Arkworks のコンポーネント間の適切なインターフェイス ラインは、チームがすべてをゼロから再構築することを強制することなく、zk テクノロジの猛烈なペースの革新の中でスタックを適切に維持できるアップグレードのペースを可能にします。

Arkworks は、zk ソフトウェア スタック全体を細かく制御する必要があるが、冗長な部分をすべてゼロから構築したくないプロジェクト向けです。 たとえば、新しいプルーフ システムのプロトタイピングを行っているが、コミットメント スキームや対応する楕円曲線がわからないなどの理由で、回路 DSL のカスタム バージョンを検討している場合、arkworks を使用すると、共有インターフェイスを使用して複数のオプションを迅速に切り替えることができます。ゼロから始めるよりも

ある計算に関する証明を作成するには、まずこの計算を zkSNARK システムが理解できる形式で表現する必要があります。 いくつかのドメイン固有言語によって、アプリケーション開発者がそのような方法で計算を表現できるようにするプログラミング言語が作成されました。 これらには以下が含まれます アステカノワール、スタークネットの カイロ, サーコム, ゾクラテス、およびアレオの レオ とりわけ。 基礎となる証明システムと数学的詳細は、通常、アプリケーション開発者には公開されません。

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

カイロ – Starknet でアプリを構築するために必要な Starkware DSL。 Cairo zkVM が解釈できる Cairo 固有のアセンブリ言語にコンパイルします。

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

サーコム — Circom は、回路を構築するための専用言語です。 現在、それは生産中の回路の事実上の言語です。 言語は特に人間工学的ではありません。 言語自体が、回路を書いているという事実を痛感させます。

レオ — Leo は、Aleo ブロックチェーンの言語として開発されました。 Leo にはいくつかの Rust に似た構文があり、ブロックチェーン内の状態遷移用に特別に作成されています。

ノワール – 錆びた構文。 言語自体ではなく IR を中心に設計されているため、任意のフロントエンドを持つことができます。 

アプリケーションで zk の独自の特性を利用したいすべてのアプリケーション開発者。 これらの言語のいくつかは、ZCash や Starknet などのチェーンを介して何十億ドルもの資金が移動し、戦闘テストが行​​われています。 ここで説明するプロジェクトの一部は、まだ本番環境で使用する準備ができていませんが、Arkworks のようなツールキットが提供するより細かい制御が必要でない限り、これらの言語のいずれかで回路を記述することが現在の最善の戦略です。

zkEVM の主な目標は、イーサリアムの状態遷移を行い、正確さの簡潔なゼロ知識証明を使用してその有効性を証明することです。 Vitalik の投稿で述べたように、これを行うには、微妙な違いとそれに対応するトレードオフを伴う方法がいくつかあります。 

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

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

これが実際に意味することは、最も単純な命令のみを実行している場合でも、可能な限り最も高価な命令に対して (パフォーマンス コストで) 支払うことです。 これは、一般化可能性とパフォーマンスの間の直接的なトレードオフにつながります。一般化可能性のための命令を追加すると、これに対して支払うことになります。 あらゆる あなたが証明する命令！

これはユニバーサル回路の根本的な問題ですが、 技術の新たな発展 IVC (incremental verifiable compute) のように、この制限は、計算を小さなチャンクに分割し、それぞれが専用の小さなサブサーキットを持つことで改善できます。

今日の zkEVM 実装では、この問題の影響を軽減するためにさまざまな戦略が使用されています。たとえば、zkSync は、よりコストのかかる操作 (主にハッシュや ECDSA などの暗号プリコンパイル) をメインの実行証明回路から切り離し、別の回路にまとめます。スナーク再帰を介して終了します。 zkSync は、コストの大部分がいくつかの複雑な命令から発生していることに気付いた後、このアプローチを採用しました。

本質的に、より EVM に相当する命令セットを証明する方がコストがかかる理由は、EVM が zk 計算用に設計されていないためです。 スタックの早い段階で EVM を放棄することで、zkEVM を zk 用により最適化された命令セットで実行できるため、証明コストが低くなります。

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

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

zkEVM は、L1 dApp 開発者を制限する輻輳の問題を摩擦なく軽減する Ethereum スケーリング ソリューションです。

zkEVM の目標は、現在の Ethereum 開発に可能な限り近い開発者エクスペリエンスをサポートすることです。 Solidity を完全にサポートしているため、チームは複数のコードベースを構築して維持する必要がありません。 zkEVM は、妥当な時間内に妥当なサイズのプルーフを生成できるように、ある程度の互換性をトレードオフする必要があるため、これを完全に行うのはやや非現実的です。

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

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

💡 その名前にもかかわらず、LLVM は VM (仮想マシン) ではありません。 LLVM は、言語にとらわれない中間表現 (IR) によってアンカーされる一連のコンパイラ ツールの名前です。

=なし; ファンデーション（名前についてですが、 SQL インジェクションのジョーク ご参考までに) は、任意の LLVM フロントエンド言語を SNARK 内で証明できる中間表現に変換できるコンパイラを構築しています。 zkLLVM は、Rust、C、C++ などの多くの高水準言語をサポートする業界標準のツールチェーンである既存の LLVM インフラストラクチャの拡張機能として設計されています。

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

これら 2 つのコンポーネントは、証明を生成するために必要なすべてです。 ユーザーは理論的には自分で証明を生成できますが、これはやや特殊な計算タスクであるため、ハードウェアを持っている他の誰かに支払ってもらいたいと思うかもしれません。 このカウンターパーティ発見メカニズムでは、 =nil; 財団はまた、証明者がユーザーのために計算を証明するために争う「証明市場」を確立しました。 この自由市場のダイナミクスは、証明者が最も価値のある証明タスクを最適化することにつながります。

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

もう XNUMX つのトレードオフは、古典的な抽象化と制御です。 この使いやすいインターフェースを進んで使用するユーザーは、基礎となる暗号プリミティブの制御を放棄しています。 多くのユーザーにとって、これは非常に有効なトレードオフです。多くの場合、暗号化の専門家にこれらの決定を任せたほうがよいからです。

zkVM はすべての zk 仮想マシンのスーパーセットを表しますが、zkEVM は特定のタイプの zkVM であり、現在普及しているため、別のトピックとして議論する価値がありました。 特注の暗号 VM 以外に、ISA に基づく、より一般化された zkVM の構築に取り組んでいるプロジェクトが他にもいくつかあります。

EVM を証明する代わりに、システムは新しい VM で RISC-V や WASM などの別の命令セット アーキテクチャ (ISA) を証明することができます。 これらの一般化された zkVM に取り組んでいる XNUMX つのプロジェクトは、RISC Zero と zkWASM です。 ここで、RISC Zero について少し掘り下げて、この戦略がどのように機能するか、およびその利点と欠点のいくつかを示してみましょう。 

RISC Zero は、RISC-V アーキテクチャで実行されるあらゆる計算を証明できます。 RISC-V は、人気が高まっているオープンソースの命令セット アーキテクチャ (ISA) 標準です。 RISC (reduced instruction set computer) の哲学は、最小限の複雑さで非常に単純な命令セットを構築することです。 つまり、スタックの上位層にいる開発者は、ハードウェアの実装を簡素化しながら、このアーキテクチャを使用して命令を実装する際により大きな負荷を負うことになります。

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

このアナロジーは、zk プルーフを生成する効率に非常によく当てはまります。 前に説明したように、zk で実行トレースを証明するときは、トレース内のすべての項目ごとにすべての命令のコストの合計を支払うため、単純で合計命令数が少ないほど優れています。

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

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

ブロックチェーン アプリケーションやその他の場所で特に役立つ一部の基本的で再利用可能な回路については、チームが既にこれらの回路を構築して最適化している場合があります。 特定のユースケースの入力を提供するだけです。 たとえば、マークル包含証明は、仮想通貨アプリケーション (エアドロップ リスト、トルネード キャッシュなど) で一般的に必要とされるものです。 アプリケーション開発者は、これらの実戦でテスト済みのコントラクトをいつでも再利用でき、最上位のレイヤーを変更するだけで独自のアプリケーションを作成できます。

たとえば、Tornado Cash の回路は、 プライベートエアドロップアプリケーション または 私的投票申込書. Manta と Semaphore は、基礎となる zk moon の数学をほとんど、またはまったく理解していなくても、Solidity コントラクトで使用できる、このような一般的な回路ガジェットのツールキット全体を構築しています。

詳細に説明したように、zk アプリケーションを開発するための無数のさまざまなオプションがあり、すべて独自のトレードオフ セットがあります。 このチャートは、zk の専門知識のレベルとパフォーマンスのニーズに基づいて、ジョブに最適なツールを選択できるように、この意思決定マトリックスを要約するのに役立ちます。 これは包括的なリストではありません。この分野でさらに多くのツールが登場していることに気付いたら、将来これに追加する予定です。

zk はいくつかのテクノロジの最先端にあり、それを構築するには、数学、暗号化、コンピューター サイエンス、およびハードウェア エンジニアリングを深く理解する必要があります。 しかし、利用可能な抽象化レイヤーが日々増えているため、アプリ開発者は博士号を取得していなくても zk の機能を活用できます。 検証時間の制限は、スタックのすべてのレベルでの最適化によって時間の経過とともにゆっくりと解消されるため、平均的な開発者向けのさらに単純なツールが表示される可能性があります。

好奇心旺盛なソフトウェア開発者であるあなたが、今すぐアプリケーションで zk を使い始めることができると確信できたことを願っています。 ハッピーハッキング 🙂

開示： Blockchain Capital は、上記のプロトコルのいくつかに投資しています。

各ブログ投稿で表明されている見解は、各著者の個人的な見解である可能性があり、必ずしもブロックチェーン キャピタルおよびその関連会社の見解を反映しているわけではありません。 Blockchain Capital も著者も、各ブログ投稿で提供される情報の正確性、妥当性、または完全性を保証しません。 ブログ投稿に含まれる情報の正確性、完全性、または公平性に関して、Blockchain Capital、著者、またはその他の人物によって、またはそれらに代わって、明示または黙示を問わず、表明または保証は行われません。そのような情報について。 各ブログ投稿に含まれる内容は、投資、規制、法律、コンプライアンス、税金、またはその他のアドバイスを構成するものではなく、投資の決定を行う際に依存するものでもありません。 ブログの投稿は、証券の売買や投資戦略の採用の提案の現在または過去の推奨または勧誘と見なされるべきではありません。 ブログの投稿には、考えられる多くの出来事や要因の結果として変化する可能性のある信念、仮定、期待に基づく予測やその他の将来の見通しに関する記述が含まれている場合があります。 変更が発生した場合、実際の結果は、将来の見通しに関する記述で表明されたものとは大きく異なる可能性があります。 すべての将来の見通しに関する記述は、そのような記述が行われた時点でのみ述べられており、ブロックチェーン キャピタルも各著者も、法律で義務付けられている場合を除き、そのような記述を更新する義務を負いません。 Blockchain Capital によって作成、公開、またはその他の方法で配布されたドキュメント、プレゼンテーション、またはその他の資料がブログ投稿で参照されている限り、そのような資料は、そこに記載されている免責事項に注意して読む必要があります。