ブロックチェーン全体が暗号化に基づいて構築されているのは、暗号化が分散型台帳全体の第1層の生態系を生み出したからです。そして、暗号化のために、第2層のオフチェーン拡張計画が浮上しています。 2022年8月、Vitalikは「 記事「さまざまなタイプのZK-EVM」は、下の図に示すように、現在の主流の拡張ソリューションの全体的な比較を提供します。
図1:ZK-EVMの種類 概要
したがって、現在のzkVM拡張ソリューションは、他のzkVMソリューションは既存のエコシステムの継続とサポートと互換性がないため、基本的にzkEVMソリューションを中心に展開されますが、将来的には問題になります。 Web2のアップグレードはWeb3の重要な部分であり、特に多くのC ++、Rust、Go、AssemblyScript、C#、およびその他の言語と互換性のあるzkWasmに代表されるソリューションの出現後、Web2アプリケーションのアカウントシステムをアップグレードすることが可能になりました。期待されるzkEVM 左から過去へ、zkWasmは右から後へと移動し、長年混乱してきたパブリックチェーンをめぐる論争を続けるのではなく、Web3アプリケーションアップグレードの大規模なエコロジーを共同で構築します。
イーサリアムの究極のコア機能は、DA+決済+コンセンサスの分散型台帳ポジショニングです。 eWASMのzkWasmソリューションは、Web3.0エコシステムの構築に適しています。
zkEVMは過去を継承し、ブロックチェーンのエコロジーを最適化し、zkWasmは未来をスタートさせ、Web3.0の未来を創造します!
ブロックチェーンだけでなく、zkWasmでロールアップを構築する
まえがきで述べたように、Web2.0とWeb3.0を真に結びつけるエコロジカルな時代は、AppRollupの時代です。 チェーンのアイデアについてまだ沈黙している生態学と比較して、ロールアップの時代は、チェーンが台帳の役割を果たすため、あまり多くのチェーンを作成する必要はありません。チェーンは当然のことながら、データ可用性(DA)、決済、コンセンサスの本質的な機能を引き受けるキャリアです。
図2:AppRollupはAppchainよりもはるかに柔軟です
暗号学において、ゼロ知識証明(英語: zero-knowledge proof)またはゼロ知識プロトコル(zero-knowledge protocol)とは、一方の当事者(証明者)が他方の当事者(テスター)に対して、ある命題を証明する方法である。 その特徴は、その過程で「命題が真であるということ以外、何の情報も明らかにされない」ということです。 したがって、「漏れゼロプルーフ」と理解できます。 これは、MITのShafi Goldwasser、Silvio Micali、Charles Rackoffによって、1985年に「Knowledge Complexity of Interactive Proof Systems」([GMR85])と題された論文で最初に提案されました。 著者は論文の中で、証明者が特定のデータを明かさずにデータの信憑性を検証者に納得させることは可能であると述べています。 ゼロ知識証明は対話的であり、証明者は検証者ごとにデータの真正性を一度証明する必要があります。また、非対話的であることもでき、すなわち、証明者が証明を作成し、この証明を使用する人は誰でも検証することができる。
画像3:ゼロ知識証明の開発の歴史
zk-SNARK (Succinct Non-Interactive Arguments of Knowledge) は、2011 年の Bit+11 論文で初めて登場した、おそらく最も一般的なゼロ知識証明の形式です。 2013年までに、ピノキオPHGR13の論文のおかげで、ゼロ知識証明を実際のアプリケーションで使用できるようになり、zk-SNARKSは低速ではありますが、一般的な計算に適しているようになりました。 2016年に提案されたGroth16アルゴリズムは、計算の複雑さを大幅に軽減し、zk-SNARKSを非常に効率的にし、今日でも標準となっています。
ただし、信頼できるセットアップは、これらのゼロ知識プロトコルのセキュリティにとって重要です。 ゼロ知識プロトコルを実行できるようにするには、初期化プロセスを使用して暗号化パラメータを生成する必要があります。 サードパーティは、暗号化パラメータがランダムで、予測不可能で、安全であることを確認するために、この操作を実行します。
その後、2017年にBulletproofs(BBBPWM17)、2018年にzk-STARK(BBHR18)が導入されました。 以前のものとは異なり、これらは初期信頼設定を必要としない一種の範囲証明です。 2019年のPlonKの論文では、回路ごとに個別の信頼できるセットアップを必要とするGroth16とは対照的に、1つの信頼できるセットアップのみを開始する必要があるユニバーサルゼロ知識証明アルゴリズムを実装しました。
この分野が進化するにつれて、ゼロ知識証明は純粋な理論から、ブロックチェーン、安全な通信、電子投票、アクセス制御、およびゲームにおける有用な実用的なアプリケーションへと移行しました。 商用アプリケーションへの投入が進むにつれて、技術を進歩させるためのよりエキサイティングな開発が行われるでしょう。
したがって、zk-SNARKS、zk-STARKS、PLONK、およびBulletproofsは、ゼロ知識証明の現在の主要な実装方法を構成しています。 それぞれの方法には、プルーフサイズ、プルーバー時間、検証時間の点で長所と短所があります。 ブロックチェーン拡張ソリューションでは、基本的にZK-SNARKフレンドリーな実装方法を中心に展開しています。
WebAssembly(略してWASM)は、Webテクノロジーファミリー(JavaScript、HTML、CSS)の比較的新しいメンバーであり、2019年12月にW3Cによって公式に認められた標準になりました。 WebAssembly は、JavaScript ランタイムと連動する新しいランタイムをブラウザーに導入します。 比較すると、より軽量で、命令セットが小さく、厳密な分離モデルがあります(WebAssemblyにはデフォルトでI/Oがありません)。 WebAssembly 開発の主な動機の 1 つは、より多くのプログラミング言語 (C++、Rust、Go など) のコンパイル ターゲットを提供し、開発者がより幅広いツールセットを使用して新しい Web アプリケーションを開発したり、既存のアプリケーションを移植したりできるようにすることでした。
図4:ワズムのテリトリー
Web2であろうとWeb3であろうと、Wasmのサポートと使用範囲はますます広範になっています。
図5:WebAssemblyエコシステムの主要企業・組織
zkVMの新しいメンバーとして、zkWasmは基本的にオフチェーン、オンチェーンのストレージ証明を通じて複雑な操作を解決し、Web2の主流言語のアイデアと互換性があり、Web2とWeb3の接続アップグレードを実現し、複雑なビジネスロジックのオフチェーン計算を実行し、貴重な結果を提供し、トレーサビリティ、真正性検証、清算のために証明書をチェーン上に保存されます。 アカウントシステムは、既存のウォレットシステムで構成されています。 エコシステム全体は、次の図で表すことができます。
図6:zkWasmの生態
全体的なデータ論理傾向は、次の図で表すことができます。
図7:オンチェーンコントラクト + オフチェーン仮想マシン(VM) + WASMコンポーザビリティ
イーサリアム2.0の初期アップデートの重要なコアには、EVMからeWASMへの移行も含まれていました。しかし、2.0の実際の進捗は期待通りではなかったため、最新の計画ではeWASMについてはあまり言及されていませんでした。
図8:ETH2.0の全体計画
最近の計画ではeWASMについては言及されていませんが、eWASMがもたらすメリットも認識されています。 この評価基板 (EVM) は当初から、効率よりも正確性を重視するように設計されていました。 これは、ネットワーク上のすべてのノードがEVMを完全に正確に実行する必要があるという事実に反映されています。 WasmはEVMに似ていますが、Web用に発明されました。 正しさとは異なり、Wasmは効率と高速読み込みを強調しています。 イーサリアムの開発者であるLane Rettig氏は、このEVMは「多くの設計思想」なしに作成されたと述べています。 彼は、EVMは実用的な視点ではなく理論的な視点から設計されているため、内部的には健全ですが、現実の世界で最高のパフォーマンスを発揮することはできないと考えています。 優れた機能。 Nick Johnson氏も同意見です。 対照的に、Wasm は実際のハードウェア命令に近い状態で記述されているため、実際のコーディング ロジックをより効果的に変換できます。 実際、Wasm 命令は、マシンで使用される命令と 1 対 1 で直接マッピングされるため、パフォーマンスが大幅に向上します。 同時に、Ewasm はプリコンパイルの必要性を削減または排除し、相互運用性のためにより多くの言語をサポートし、EVM よりも幅広いツールセットの恩恵を受けることができます。
EVMよりもeWASMを使用する主な利点は、主流派によって次のように認識されています。
パフォーマンス : EVMと比較して、eWASMはEVMバイトコードよりも高速かつ効率的になるように設計されたWebAssemblyを使用しているため、より優れたパフォーマンスを提供します。 WebAssemblyはネイティブに近いパフォーマンスを提供し、イーサリアムネットワークの速度とスケーラビリティを大幅に向上させることができます。
相互運用性 : eWASM は、C++、Rust、AssemblyScript などの複数のプログラミング言語をサポートしているため、EVM よりも優れた相互運用性を提供します。 これにより、開発者は好みの言語でスマートコントラクトを作成できるようになり、コードの品質と開発者の生産性が向上します。
セキュリティ : eWASMは、スマートコントラクトを相互に分離し、互いのメモリにアクセスするのを防ぐことができるメモリサンドボックスなどの複数のセキュリティ機能を備えているため、EVMよりも優れたセキュリティを提供します。 さらに、eWASMは、再入攻撃や整数オーバーフローなどの一般的なスマートコントラクトの脆弱性に対する保護を強化します。
柔軟性 : eWASMは、スマートコントラクトを個別に更新できる複数のモジュールで構成できる動的リンクをサポートしているため、EVMよりも優れた柔軟性を提供します。 これにより、コードの整理が改善され、スマートコントラクトのメンテナンスが容易になります。
コミュニティサポート : eWASMはイーサリアムコミュニティから強力なサポートを受けており、GethやParityを含むいくつかの主要なイーサリアムクライアントがeWASMサポートを実装しています。 これは、開発者がeWASMを使用してスマートコントラクトを構築する際に、幅広いツールとリソースにアクセスできることを意味します。
しかし、基盤となるイーサリアムネットワークは本当にEVMをeWasmに置き換える必要があるのでしょうか? リプレースプロセス中のさまざまなセキュリティリスクと、既存のエコシステムへの影響を過小評価することはできません。 これが、最新の計画でeWASMがあまり言及されていない理由かもしれません。
図9:ヴィタリック・ブテリン氏が最新のイーサリアムロードマップを提案
ロードマップでは、アップグレードをイーサリアムアーキテクチャへの影響に基づいていくつかのカテゴリに分類しています。 これには以下が含まれます。
マージ : プルーフ・オブ・ワークからプルーフ・オブ・ステークへのアップグレードが必要
Surge : ボリューム スタッキングとデータ シャーディングによるスケーリングを含むアップグレード
Scourge:検閲耐性、分散化、および抽出可能な最大値に関するプロトコルリスクを伴うアップグレード
Verge : ブロックの検証を容易にするアップグレード
パージ:ノードの運用にかかる計算コストを削減し、プロトコルのアップグレードを簡素化します。
散財 :上記のカテゴリに分類されないその他のアップグレード
イーサリアムの究極のコア機能は、DA+決済+コンセンサスの分散型台帳ポジショニングであることは誰もが認識しています。 このように、多くのスケーラビリティ要件は、イーサリアム自体にあまり多くの変更を必要とせず、他の未知のリスクをもたらします。 魚とクマ。 両方を同時に行う方法は、作業をレイヤーに分割することです。 eWASM を 2 番目のレイヤーに配置することは、より合理的で効果的なソリューションです。 特にzkと組み合わせた後、zkWasmの技術ソリューションは、eWASMが達成したい効果を完全に継承することができます。 同時に、Web2とWeb3の両方にサービスを提供し、相互に接続することができます。 zkEVMは過去を継承し、ブロックチェーンの生態学を最適化し、zkWasmは未来を開始し、Web3.0の未来を創造します!
図10:zkWasm = zkp + WASM
ブロックチェーン全体が暗号化に基づいて構築されているのは、暗号化が分散型台帳全体の第1層の生態系を生み出したからです。そして、暗号化のために、第2層のオフチェーン拡張計画が浮上しています。 2022年8月、Vitalikは「 記事「さまざまなタイプのZK-EVM」は、下の図に示すように、現在の主流の拡張ソリューションの全体的な比較を提供します。
図1:ZK-EVMの種類 概要
したがって、現在のzkVM拡張ソリューションは、他のzkVMソリューションは既存のエコシステムの継続とサポートと互換性がないため、基本的にzkEVMソリューションを中心に展開されますが、将来的には問題になります。 Web2のアップグレードはWeb3の重要な部分であり、特に多くのC ++、Rust、Go、AssemblyScript、C#、およびその他の言語と互換性のあるzkWasmに代表されるソリューションの出現後、Web2アプリケーションのアカウントシステムをアップグレードすることが可能になりました。期待されるzkEVM 左から過去へ、zkWasmは右から後へと移動し、長年混乱してきたパブリックチェーンをめぐる論争を続けるのではなく、Web3アプリケーションアップグレードの大規模なエコロジーを共同で構築します。
イーサリアムの究極のコア機能は、DA+決済+コンセンサスの分散型台帳ポジショニングです。 eWASMのzkWasmソリューションは、Web3.0エコシステムの構築に適しています。
zkEVMは過去を継承し、ブロックチェーンのエコロジーを最適化し、zkWasmは未来をスタートさせ、Web3.0の未来を創造します!
ブロックチェーンだけでなく、zkWasmでロールアップを構築する
まえがきで述べたように、Web2.0とWeb3.0を真に結びつけるエコロジカルな時代は、AppRollupの時代です。 チェーンのアイデアについてまだ沈黙している生態学と比較して、ロールアップの時代は、チェーンが台帳の役割を果たすため、あまり多くのチェーンを作成する必要はありません。チェーンは当然のことながら、データ可用性(DA)、決済、コンセンサスの本質的な機能を引き受けるキャリアです。
図2:AppRollupはAppchainよりもはるかに柔軟です
暗号学において、ゼロ知識証明(英語: zero-knowledge proof)またはゼロ知識プロトコル(zero-knowledge protocol)とは、一方の当事者(証明者)が他方の当事者(テスター)に対して、ある命題を証明する方法である。 その特徴は、その過程で「命題が真であるということ以外、何の情報も明らかにされない」ということです。 したがって、「漏れゼロプルーフ」と理解できます。 これは、MITのShafi Goldwasser、Silvio Micali、Charles Rackoffによって、1985年に「Knowledge Complexity of Interactive Proof Systems」([GMR85])と題された論文で最初に提案されました。 著者は論文の中で、証明者が特定のデータを明かさずにデータの信憑性を検証者に納得させることは可能であると述べています。 ゼロ知識証明は対話的であり、証明者は検証者ごとにデータの真正性を一度証明する必要があります。また、非対話的であることもでき、すなわち、証明者が証明を作成し、この証明を使用する人は誰でも検証することができる。
画像3:ゼロ知識証明の開発の歴史
zk-SNARK (Succinct Non-Interactive Arguments of Knowledge) は、2011 年の Bit+11 論文で初めて登場した、おそらく最も一般的なゼロ知識証明の形式です。 2013年までに、ピノキオPHGR13の論文のおかげで、ゼロ知識証明を実際のアプリケーションで使用できるようになり、zk-SNARKSは低速ではありますが、一般的な計算に適しているようになりました。 2016年に提案されたGroth16アルゴリズムは、計算の複雑さを大幅に軽減し、zk-SNARKSを非常に効率的にし、今日でも標準となっています。
ただし、信頼できるセットアップは、これらのゼロ知識プロトコルのセキュリティにとって重要です。 ゼロ知識プロトコルを実行できるようにするには、初期化プロセスを使用して暗号化パラメータを生成する必要があります。 サードパーティは、暗号化パラメータがランダムで、予測不可能で、安全であることを確認するために、この操作を実行します。
その後、2017年にBulletproofs(BBBPWM17)、2018年にzk-STARK(BBHR18)が導入されました。 以前のものとは異なり、これらは初期信頼設定を必要としない一種の範囲証明です。 2019年のPlonKの論文では、回路ごとに個別の信頼できるセットアップを必要とするGroth16とは対照的に、1つの信頼できるセットアップのみを開始する必要があるユニバーサルゼロ知識証明アルゴリズムを実装しました。
この分野が進化するにつれて、ゼロ知識証明は純粋な理論から、ブロックチェーン、安全な通信、電子投票、アクセス制御、およびゲームにおける有用な実用的なアプリケーションへと移行しました。 商用アプリケーションへの投入が進むにつれて、技術を進歩させるためのよりエキサイティングな開発が行われるでしょう。
したがって、zk-SNARKS、zk-STARKS、PLONK、およびBulletproofsは、ゼロ知識証明の現在の主要な実装方法を構成しています。 それぞれの方法には、プルーフサイズ、プルーバー時間、検証時間の点で長所と短所があります。 ブロックチェーン拡張ソリューションでは、基本的にZK-SNARKフレンドリーな実装方法を中心に展開しています。
WebAssembly(略してWASM)は、Webテクノロジーファミリー(JavaScript、HTML、CSS)の比較的新しいメンバーであり、2019年12月にW3Cによって公式に認められた標準になりました。 WebAssembly は、JavaScript ランタイムと連動する新しいランタイムをブラウザーに導入します。 比較すると、より軽量で、命令セットが小さく、厳密な分離モデルがあります(WebAssemblyにはデフォルトでI/Oがありません)。 WebAssembly 開発の主な動機の 1 つは、より多くのプログラミング言語 (C++、Rust、Go など) のコンパイル ターゲットを提供し、開発者がより幅広いツールセットを使用して新しい Web アプリケーションを開発したり、既存のアプリケーションを移植したりできるようにすることでした。
図4:ワズムのテリトリー
Web2であろうとWeb3であろうと、Wasmのサポートと使用範囲はますます広範になっています。
図5:WebAssemblyエコシステムの主要企業・組織
zkVMの新しいメンバーとして、zkWasmは基本的にオフチェーン、オンチェーンのストレージ証明を通じて複雑な操作を解決し、Web2の主流言語のアイデアと互換性があり、Web2とWeb3の接続アップグレードを実現し、複雑なビジネスロジックのオフチェーン計算を実行し、貴重な結果を提供し、トレーサビリティ、真正性検証、清算のために証明書をチェーン上に保存されます。 アカウントシステムは、既存のウォレットシステムで構成されています。 エコシステム全体は、次の図で表すことができます。
図6:zkWasmの生態
全体的なデータ論理傾向は、次の図で表すことができます。
図7:オンチェーンコントラクト + オフチェーン仮想マシン(VM) + WASMコンポーザビリティ
イーサリアム2.0の初期アップデートの重要なコアには、EVMからeWASMへの移行も含まれていました。しかし、2.0の実際の進捗は期待通りではなかったため、最新の計画ではeWASMについてはあまり言及されていませんでした。
図8:ETH2.0の全体計画
最近の計画ではeWASMについては言及されていませんが、eWASMがもたらすメリットも認識されています。 この評価基板 (EVM) は当初から、効率よりも正確性を重視するように設計されていました。 これは、ネットワーク上のすべてのノードがEVMを完全に正確に実行する必要があるという事実に反映されています。 WasmはEVMに似ていますが、Web用に発明されました。 正しさとは異なり、Wasmは効率と高速読み込みを強調しています。 イーサリアムの開発者であるLane Rettig氏は、このEVMは「多くの設計思想」なしに作成されたと述べています。 彼は、EVMは実用的な視点ではなく理論的な視点から設計されているため、内部的には健全ですが、現実の世界で最高のパフォーマンスを発揮することはできないと考えています。 優れた機能。 Nick Johnson氏も同意見です。 対照的に、Wasm は実際のハードウェア命令に近い状態で記述されているため、実際のコーディング ロジックをより効果的に変換できます。 実際、Wasm 命令は、マシンで使用される命令と 1 対 1 で直接マッピングされるため、パフォーマンスが大幅に向上します。 同時に、Ewasm はプリコンパイルの必要性を削減または排除し、相互運用性のためにより多くの言語をサポートし、EVM よりも幅広いツールセットの恩恵を受けることができます。
EVMよりもeWASMを使用する主な利点は、主流派によって次のように認識されています。
パフォーマンス : EVMと比較して、eWASMはEVMバイトコードよりも高速かつ効率的になるように設計されたWebAssemblyを使用しているため、より優れたパフォーマンスを提供します。 WebAssemblyはネイティブに近いパフォーマンスを提供し、イーサリアムネットワークの速度とスケーラビリティを大幅に向上させることができます。
相互運用性 : eWASM は、C++、Rust、AssemblyScript などの複数のプログラミング言語をサポートしているため、EVM よりも優れた相互運用性を提供します。 これにより、開発者は好みの言語でスマートコントラクトを作成できるようになり、コードの品質と開発者の生産性が向上します。
セキュリティ : eWASMは、スマートコントラクトを相互に分離し、互いのメモリにアクセスするのを防ぐことができるメモリサンドボックスなどの複数のセキュリティ機能を備えているため、EVMよりも優れたセキュリティを提供します。 さらに、eWASMは、再入攻撃や整数オーバーフローなどの一般的なスマートコントラクトの脆弱性に対する保護を強化します。
柔軟性 : eWASMは、スマートコントラクトを個別に更新できる複数のモジュールで構成できる動的リンクをサポートしているため、EVMよりも優れた柔軟性を提供します。 これにより、コードの整理が改善され、スマートコントラクトのメンテナンスが容易になります。
コミュニティサポート : eWASMはイーサリアムコミュニティから強力なサポートを受けており、GethやParityを含むいくつかの主要なイーサリアムクライアントがeWASMサポートを実装しています。 これは、開発者がeWASMを使用してスマートコントラクトを構築する際に、幅広いツールとリソースにアクセスできることを意味します。
しかし、基盤となるイーサリアムネットワークは本当にEVMをeWasmに置き換える必要があるのでしょうか? リプレースプロセス中のさまざまなセキュリティリスクと、既存のエコシステムへの影響を過小評価することはできません。 これが、最新の計画でeWASMがあまり言及されていない理由かもしれません。
図9:ヴィタリック・ブテリン氏が最新のイーサリアムロードマップを提案
ロードマップでは、アップグレードをイーサリアムアーキテクチャへの影響に基づいていくつかのカテゴリに分類しています。 これには以下が含まれます。
マージ : プルーフ・オブ・ワークからプルーフ・オブ・ステークへのアップグレードが必要
Surge : ボリューム スタッキングとデータ シャーディングによるスケーリングを含むアップグレード
Scourge:検閲耐性、分散化、および抽出可能な最大値に関するプロトコルリスクを伴うアップグレード
Verge : ブロックの検証を容易にするアップグレード
パージ:ノードの運用にかかる計算コストを削減し、プロトコルのアップグレードを簡素化します。
散財 :上記のカテゴリに分類されないその他のアップグレード
イーサリアムの究極のコア機能は、DA+決済+コンセンサスの分散型台帳ポジショニングであることは誰もが認識しています。 このように、多くのスケーラビリティ要件は、イーサリアム自体にあまり多くの変更を必要とせず、他の未知のリスクをもたらします。 魚とクマ。 両方を同時に行う方法は、作業をレイヤーに分割することです。 eWASM を 2 番目のレイヤーに配置することは、より合理的で効果的なソリューションです。 特にzkと組み合わせた後、zkWasmの技術ソリューションは、eWASMが達成したい効果を完全に継承することができます。 同時に、Web2とWeb3の両方にサービスを提供し、相互に接続することができます。 zkEVMは過去を継承し、ブロックチェーンの生態学を最適化し、zkWasmは未来を開始し、Web3.0の未来を創造します!
図10:zkWasm = zkp + WASM