4D zkEVM の詳細説明: イーサリアムのスケーラビリティの将来
著者: クリスティーン・キム
導入
導入
ゼロ知識イーサリアム仮想マシン (zkEVM) は、短期および長期的にイーサリアムのスケーラビリティを向上させる可能性がある、非常に期待されている革新的なテクノロジーです。今年の 3 つの主要なイーサリアム スケーリング プロジェクト、zkSync、Polygon、および Scroll はそれぞれ、zkEVM 実装の大幅な進歩を発表しており、その多くは今年初めにアルファ段階を開始し、現在は L2 ブロックチェーンとして独立して実行されています。時間が経つと、zkEVM がイーサリアムのベース レイヤ上で直接実行されるようになる可能性があります。
zkEVM は、イーサリアム仮想マシン (EVM) と同じ高レベル プログラミング言語または低レベル バイトコードを実行できる仮想マシンであり、ゼロ知識証明 ZKP とデータ自体を検証する暗号証明を使用してこのコードを証明します。属性や内容など、 に関する情報を明らかにすることはありません。 1982 年に遡ると、コンピューター科学者の Goldwasser、Micali、Rackoff (Silvio Micali は Algorand ブロックチェーンの創設者) が初めて ZKP の概念を導入しました。 ZKP は、暗号化の別の分野である準同型暗号化と混同されることがよくあります。準同型暗号は、暗号化されたデータを復号化せずに操作を実行できるようにするもので、1978 年に Rivest、Adleman、Dertouzos によって初めて提案され、クラウド コンピューティングとストレージの主要テクノロジーの 1 つになりました。準同型暗号は、トランザクション金額を難読化するために使用されるプライバシー コイン Grin など、一部のパブリック ブロックチェーン プロトコルでも使用されていることに注目する価値があります。
過去 40 年にわたり、コンピューター科学者は ZKP を安全かつ効率的に生成するためのさまざまなアルゴリズムを発明してきました。その多くは、スケーラブルで透明な知識引数 (STARK) または簡潔な非対話型知識引数 (SNARK) の 2 つの大きなカテゴリに分類されます。これらのアルゴリズムは、核軍縮 (核兵器を廃絶し削減する行為)、ID システム、さらに最近ではスケーラブルなパブリック ブロックチェーンや暗号通貨など、幅広いユースケース向けに開発されました。特にイーサリアムでは、他の暗号化スキームと比較してそのシンプルさと検証の容易さから、ZKP がスケーリングの「聖杯」であると多くの開発者が考えています。暗号プロトコルを広く効果的に使用できるようにするために、構築や解読は困難だが検証は容易であることが、暗号プロトコル開発者の共通の目標です。
ゼロ知識システムは、一般化して任意の複雑さのコードを証明するために適用することが困難であり、イーサリアム ブロックチェーン上のあらゆる種類のトランザクション アクティビティをネイティブにサポートおよび証明するための ZKP を構築することは、過去数年間の計画にわたって開発者によって継続的な研究努力となってきました。 Starkware が、Starkware チームが作成したカスタム プログラミング言語である Cairo を通じて実装された、イーサリアムに基づくトランザクションを証明するための最初の汎用 ZK システムを発売したのは、2021 年 11 月のことでした。しかし、2022 年 7 月に、zkSync、Polygon、Scroll を含む 3 つの異なるイーサリアムベースの L2 プロトコルが、zkEVM の形式で ZKP を使用したイーサリアムのスケーリングにおける画期的な進歩を発表しました。
注: 口語的には zkEVM と呼ばれますが、これらの仮想マシンは ZKP のプライバシーの利点を活用しませんが、ZKP のセキュリティと効率の利点を十分に活用します。したがって、これらのタイプの仮想マシンのより正確な名前は Proof of Validity Generation EVM ですが、このレポートでは、より一般的な名前 zkEVM を使用します。
このレポートは、読者に zkEVM の一般的な概念を理解してもらい、イーサリアム開発におけるさまざまな実装を理解してもらうことを目的としています。 zkEVM は比較的抽象的なトピックであるため、このレポートはイーサリアム ネットワークの現状の簡単な概要から始まり、ブロック生成、EVM、および Rullups などの核となる概念を紹介することで zkEVM を理解するための基礎を築きます。次に、イーサリアム上に存在できるさまざまなタイプの zkEVM を要約し、現在運用されている 5 つの主要な zkEVM 実装を比較します。この新興テクノロジーの実装上の課題と、zkEVM の長期にわたる競争環境の見通しに焦点を当てます。全体として、zkEVM はまだイーサリアムの開発と採用の初期段階にあります。
今日のイーサリアム
zkEVM の複雑な仕組みに入る前に、まずトランザクションがイーサリアム ブロックにどのように含まれるかを高いレベルで理解することが重要です。
ブロックの生成
ユーザーが新しいトランザクションを Ethereum に送信すると、ネットワークに接続されているコンピューター (ノードとも呼ばれます) はトランザクションを mempool と呼ばれるローカル データ構造に保存します。 mempool は未確認のトランザクションのリストを維持する責任を負い、ノードを実行して 32 ETH をステークするバリデーターをランダムに選択し、それを通じて mempool 内のトランザクションがブロックにバッチ化されます。イーサリアム ブロックチェーンに新しいブロックを追加することを選択した検証者は、「提案者」と呼ばれることもあります。 MEV から追加の報酬を得るために、提案者の中には、ブロックを構築するときにローカルのメモリプールではなくサードパーティのブロック ビルダーに依存する人もいます。
ブロックは親ブロック (前のブロック ヘッダー) によって順序付けされ、リンクされます。各ブロックには親ブロックのハッシュが含まれており、ブロックをリンクすることでブロックチェーン データ構造を形成します。親ブロックのハッシュを介したブロックのリンクを次の図に示します。
2022 年 9 月 15 日以前、イーサリアムはプルーフ オブ ワーク PoW コンセンサス メカニズムに依存していました。マイナーは検証者に代わってブロック生成を担当しました。マイナーは多額の資本を抵当に入れる必要はありませんが、大量の電力を消費する必要がありますユーザートランザクションを処理するため。
PoW および PoS コンセンサス プロトコルの下では、イーサリアム ブロックチェーンのスケーラビリティの欠如は、ブロック スペースが限られていることに起因します。ブロックスペースはイーサリアム上のガスによって制限されます。実行に多くの計算作業が必要なトランザクションの価格は通常、より高いガス単位で設定されますが、計算コストが低い (つまり、リソースの消費量が少ない) トランザクションのガスコストは低くなります。ガスは、基本料金と呼ばれる動的なガス料金を自動的に設定するイーサリアム ネットワークを通じて ETH に変換されます。イーサリアム プロトコルはブロック スペースを制限しており、ブロック スペースには最大 3,000 万ユニットのガスしか含めることができません。この最大ブロック ガス制限により、ブロック伝播時間が短縮され、ハード フォークのリスクが軽減されます。
イーサリアム仮想マシン
トランザクションがイーサリアム上のブロックに含まれると、イーサリアム仮想マシン (EVM) と呼ばれるカスタム ランタイムを通じて実行されます。 EVM は、イーサリアム上に任意の複雑さのコードをデプロイするように設計されており、これがイーサリアムをチューリング完全システムとも呼ばれる汎用ブロックチェーンにしているのです。
EVM がトランザクションを実行する方法には特定のルールがあります。まず、EVM は、Solidity や Yul などの人間が読めるプログラミング言語を、EVM バイトコードと呼ばれる機械指向または「低レベル」言語にコンパイルします。次に、EVM はバイトコードを解析して、「オペコード」と呼ばれる一連の命令のリストを作成します。各オペコードは、EVM に異なるタスクを実行するように指示し、EVM バイトコードで 16 進形式で表されます。たとえば、スマート コントラクトがオンチェーンで実行されるときに一時データを保存するように EVM に指示するオペコードは、記憶術的には「MSTORE」、または 16 進数では「0x52」として表されます。読者がオペコードを概念化できるように、イーサリアム イエロー ペーパーで定義されている単純なオペコードを以下に示します。
長年にわたり、イーサリアム開発者は EVM に新しいオペコードを追加し続け、ユーザーがハッシュ関数やスカラー乗算などのより高度な操作をネットワーク上で実行できるようにするプリコンパイルも追加しました。 EVM は、この種の最初のランタイム環境として、汎用パブリック ブロックチェーンでのスマート コントラクト展開の標準として広く採用されています。ただし、この種初のテクノロジである EVM には設計上の制限があり、最も重要なのは EVM の ZKP 互換性の欠如です。
Rollups
イーサリアムのスケーラビリティを向上させるために、トランザクションの実行をベースレイヤーからロールアップまで抽象化する L2 ネットワークがいくつかあります。ロールアップはトランザクション データを圧縮するため、トランザクションのバッチをベース レイヤに送信するために必要なブロック スペースの量が、オンチェーン メモリプールを通じてこれらのトランザクションを個別に確認するために必要なブロック スペースの量よりも大幅に少なくなります。ロールアップは、バリデーターやマイナーではなく、「発注者」と呼ばれるネットワーク オペレーターによって実行されます。シーケンサーは、ロールアップの状態遷移を検証する責任があります。これらは、ユーザートランザクションをロールアップのバッチにパッケージ化し、このトランザクションのバッチの証明をイーサリアムベースレイヤーに送信するエンティティです。次の図は、ロールアップにおけるソーターの役割を示しています。
ロールアップは、プラズマやステート チャネルなど、イーサリアム上の他のスケーリング ソリューションとは異なります。イーサリアムの歴史を通じて、コア開発者はイーサリアムのスケーラビリティロードマップを研究し、破棄してきました。ロールアップには、オプティミスティック ロールアップと ZK ロールアップの 2 つの主なタイプがあります。オプティミスティック ロールアップは不正行為の証明に依存しています。つまり、L2 ネットワークの状態への変更は、その有効性を直接証明することなくイーサリアムに展開されます。少なくとも 1 人の正直な参加者がオプティミスティック ロールアップの状態遷移を観察している限り、無効な状態遷移を検出してキャンセルすることができます。 Arbitrum and Optimism の場合、不正行為の証拠を提出できる「チャレンジウィンドウ」は 1 週間続きます。オプティミスティック ロールアップの状態遷移は、チャレンジ ウィンドウが終了すると最終的で有効であるとみなされます。
一方、ZK ロールアップは ZKP に依存しており、トランザクション バッチが L2 で処理されるたびに有効性の証明を生成し、それをイーサリアムに公開します。すべてのトランザクション バッチの有効性証明を自動的に生成することにより、ZK ロールアップのセキュリティも強化されます。これは、新しい有効性証明がイーサリアムに送信されるたびに ZK ロールアップから資金を引き出すことができることも意味しますが、楽観的ロールアップの場合は、紛争や不正証明が生成されるまでに通常約 7 日間の待機期間があります。 ZK ロールアップは、オプティミスティック ロールアップよりも優れたデータ圧縮も提供します。次の表は、オプティミスティックと ZK ロールアップの違いをまとめたものです。
ZK ロールアップに対するオプティミスティック ロールアップの主な利点は、オプティミスティック ロールアップの仮想マシンが EVM の仮想マシンとほぼ同一であることです。 Optimism や Arbitrum など、現在 Ethereum 上で実行されている Optimistic Rollup 実装は、それぞれ OVM および AVM と呼ばれる、Ethereum と同じトランザクション実行環境をシミュレートします。ほとんどの ZK ロールアップはアプリケーション固有です。つまり、すべての種類の Ethereum ベースのトランザクションと DApp をサポートしているわけではありません。 Loopring、StarkEx Rollups、zkSync 1.0 は、特定のタイプの支払い、トークントランザクション、NFT ミントを可能にするアプリケーション固有の ZK ロールアップの例です。
StarkNet などの特定の ZK ロールアップはユニバーサルです。つまり、あらゆる種類のトランザクションと DApp がサポートされます。ただし、これらの ZK ロールアップでは、DApp 開発者は、新しいカスタム実行環境でスマート コントラクト コードを実行する方法を学習する必要があります。この環境は通常、EVM 互換性ではなく ZKP 生成用に最適化されています。既存の分散アプリケーションとユーザーが新しい実行環境をオンボードすることが難しいことを考えると、これはイーサリアムでの ZK ロールアップの採用に課題をもたらします。この問題を克服するために、Polygon Hermez、zkSync、Scroll などの ZK ロールアップ プロジェクトは、イーサリアム上のすべてのスマート コントラクト コードのネイティブ実行環境である EVM と互換性のある ZK ロールアップの実装に取り組んでいます。
STARKs、SNARKs、Volitions and Validiums
実際には、ロールアップは、オンチェーンで発行される証明の種類 (楽観的ロールアップの不正証明または ZK ロールアップの有効性証明) だけでなく、ロールアップのデータ可用性戦略と証明アルゴリズムによっても区別されます。
現在、SNARK と STARK として知られる有効性証明には 2 つの大きなカテゴリがあります。
SNARK は、ビットコインとイーサリアムで最も一般的に使用されているデータ暗号化技術である楕円曲線暗号に依存しています。また、SNARK は通常、信頼できるセットアップに依存します。つまり、アルゴリズムでは、信頼できるエンティティによって事前にデータが生成される必要があります。信頼できるセットアップは、繰り返し発生するイベントではなく、個人またはグループがコア データを生成する 1 回限りのプロセスです。このデータは Common Reference String (CRS) と呼ばれ、信頼できる証明を生成するために zk-SNARK アルゴリズムで使用される数値です。 CRS の生成に必要な入力が侵害されると、不正確な証明が生成される可能性があります。したがって、信頼できるセットアップ参加者全員が、CRS/SRS の生成に使用された入力を破棄するか、儀式の完了後に回復不能にすることが重要です。
STARK は、楕円曲線や信頼できる設定に依存しません。 STARK はハッシュ関数に依存しており、一部の開発者はこれが量子暗号に対して有益であると信じています。ただし、STARK はより複雑で、実行にはより多くのコンピューティング リソースが必要です。 2012年から続くSNARKsに続き、2018年に誕生しました。これらの理由により、SNARK は STARK よりも広く使用されています。 STARKs ベースのアルゴリズムの例には、Fractal、SuperSonic、Fri-STARKs、genSTARK などがあります。
有効性証明を生成するさまざまな方法に加えて、ZK ロールアップはデータの可用性戦略も異なります。データ可用性ポリシーによって、トランザクション バッチのどのコンポーネントが最終的にオンチェーンで公開されるかが決まります。 Optimistic や ZK を含むロールアップは通常、トランザクションのバッチが処理されるたびに、データの 3 つのコピーをメインネット Ethereum にコミットします。まず、Rollups バリデーターが新しいネットワーク状態のルート ハッシュをイーサリアムに送信します。 (状態は、L2 上のトランザクションと口座残高の更新された記録を指します。) 状態は、次の図に示すように、マークル ツリー データ構造に記録されます。
ルート ハッシュは、マークル ツリー全体の暗号化コミットメントであり、ステート コミットメントと呼ばれることもあります。すべての ZK ロールアップがルート ハッシュをイーサリアムにコミットする必要があるわけではありませんが、通常は、イーサリアム上で公開されたデータを簡単に再構築し、ロールアップで実行されたトランザクションを検証できるようにするためにそうします。
L2 ブロックチェーンの新しい状態を確認するために使用される高レベルのルート ハッシュに加えて、暗号証明がイーサリアムに記録されます。オプティミスティック ロールアップの場合、この証明は ZKP または不正証明になります。これは、STARKs または SNARKs アルゴリズムによって生成できます。最後に、これら 2 つのデータに加えて、ZK Rollups は、状態デルタとも呼ばれる、処理されたトランザクション バッチの圧縮バージョンもイーサリアムに公開します。ステート デルタは、大量のトランザクション データをイーサリアムに送信するためのコスト効率の高い方法であり、ZK ロールアップに特有のものです。オプティミスティック ロールアップは、他のデータ圧縮技術を使用してトランザクションをバッチ化し、オンチェーンに送信します。
また、Scroll チームなどの一部の ZK Rollups プロジェクトは、実際には追加のデータ圧縮の利点を得るために状態デルタを Ethereum に投稿することに依存していません。スクロール開発者は、イーサリアム改善提案 EIP-4844 やダンクシャーディングなどの今後のコード変更により、イーサリアムにトランザクション データを送信するコストが大幅に削減され、他のデータ圧縮技術に対するステート デルタの効率向上は無視できる程度になると考えています。
ロールアップでは、マークル ツリーの最下位レベルのデータを使用し、それをマークル ツリーの最上位 (ルート) のルート分布と組み合わせることで、オンチェーンで送信されたトランザクションのバッチの内容を誰でも再構築して検証できるようになります。ほとんどのロールアップの特徴は、イーサリアムにコミットされたオンチェーン データを使用して、L2 ネットワーク上で実行されるトランザクションを再作成できることです。ただし、一部のロールアップは、状態デルタやその他の圧縮されたトランザクション データをイーサリアムに送信することを回避し、代わりにデータを別の場所に公開して、運用コストを削減し、ネットワークのスケーラビリティを向上させます。開発者の中には、トランザクション データをイーサリアムにコミットすることを回避し、トランザクション再構築の保証を破る L2 ネットワークはロールアップとして分類されるべきではないと主張する人もいるでしょう。
Rollup が状態デルタを処理する方法によって、ネットワークが Validium または Volition として分類できるかどうかが決まります。
Validium はロールアップとして理解でき、チェーン上の有効性証明とルート ハッシュのみを送信し、チェーンから離れた別のネットワークに状態デルタを保存します。ロールアップはイーサリアムのデータ可用性に依存しなくなり、ネットワーク ブロック スペースによって制限されるため、理論的にはロールアップのトランザクション スループットを 9,000 TPS まで高めることができます。 Validium の欠点はセキュリティであり、オフチェーン データの公開に使用される別のネットワークにはイーサリアムと同じセキュリティ保証がありません。
Volitions は、ステート デルタをオフチェーンまたはオンチェーンで発行する決定をユーザーに委ねており、これはイーサリアム スケーリングのスタートアップ Starkware によって先駆けられました。これは、イーサリアムや Starkware の信頼できるデータ可用性評議会 (DAC) などのオフチェーン ネットワークにオンチェーンで直接確認することで、トランザクションに強化されたセキュリティが必要かどうかをユーザーが判断できる新しい方法です。ただし、コストが高くなる可能性があります。
EVM 同等性の 4 つの主なレベル
上記の内容は、イーサリアム、EVM、および ZK ロールアップでのトランザクション実行の全体的なフレームワークを理解するのに役立ちます。次に、zkEVM について説明します。
zkEVM は、メインネット Ethereum と同じトランザクション実行環境を模倣する ZK ロールアップです。 zkEVM の実装は、証明アルゴリズムとデータ可用性戦略、および zkEVM の EVM 同等レベルが異なります。 EVM の等価性には主に 4 つのレベルがあります。さまざまなレベルの概要は次のとおりです。
同等の語学力
言語レベルの EVM 同等性を実現するには、zkEVM が EVM 対応言語を理解し、ネイティブにコンパイルできなければなりません。言い換えれば、これらのタイプの zkEVM は、Solidity や Yul などの EVM 対応プログラミング言語を、ZKP 生成用に最適化されたカスタム言語に変換します。これは、ZK ロールアップで EVM 互換性を実現する最も簡単で効果的な方法の 1 つであると考えられています。ただし、これらのタイプの zkEVM は、ユーザーとスマート コントラクト開発者に EVM との対話と同じエクスペリエンスを提供するという点で最も制限されています。
EVM との言語レベルの互換性とは、EVM の高レベル プログラミング言語を、ZKP を生成するように設計された仮想マシンによって解釈されるカスタムの低レベル言語に変換するコンパイラを通じて Solidity を実行することを意味します。 Solidity コードを介して EVM と対話することだけを気にしているほとんどの Ethereum ユーザーとスマート コントラクト開発者にとって、Ethereum メインネット上と同じ種類のコードが zkEVM を介して実行できる限り、zkEVM の基本的な動作は重要ではない可能性があります。一方、EVM 用に構築された複雑な開発ツール、フレームワーク、テスト環境は、言語レベルの EVM 互換性のみを備えた zkEVM で動作するように変更する必要がある場合があります。
バイトコードレベルで同等
EVM 同等性の 2 番目と 3 番目のレベルはバイトコード レベルで、Solidity や Yul などの高レベル言語からコンパイルされた EVM バイトコードを ZK ロールアップが解釈する必要があります。 zkEVM は、EVM と同じ高レベル プログラミング言語および低レベル バイトコードをエミュレートできるため、EVM とのより深い互換性が可能になります。これらのタイプの zkEVM は構築がより複雑で、より高度なエンジニアリングが必要です。
仮想マシンが EVM バイトコードを実行する方法は、オペコードと呼ばれる特定の命令リストを通じて行われ、各命令は EVM に異なるタスクを実行するように指示します。バイトコード互換の zkEVM の目標は、EVM バイトコードを証明し、バイトコードに含まれるさまざまなオペコードを解析できる ZK システムを作成することです。これらのタイプの zkEVM の利点は、EVM ベースのアプリケーションおよびツールと互換性があることです。完全にバイトコード互換の zkEVM は、ネイティブの Ethereum ベースのアプリケーションと同じデバッグ ツールと開発者インフラストラクチャをサポートできます。ただし、完全なバイトコード互換性を実現すると、多くの場合、非効率的で高価な ZK システムの作成につながるため、コストの削減と効率の向上を考慮する必要があります。
現在、バイトコード互換の zkEVM は、Polygon zkEVM と Scroll zkEVM を含む 2 つあります。現在の設計では、これら 2 つの実装は EVM バイトコードと部分的にのみ互換性がありますが、時間の経過とともに、これらの実装は完全な互換性を目指して取り組んでいます。
コンセンサスレベルの同等性
EVM 同等性の 4 番目で最後のレベルはコンセンサス レベルです。これは、ZK ロールアップが達成できる最高のネイティブ EVM 互換性です。これは「祀られているロールアップ」と呼ばれることもありますが、すべての「祀られているロールアップ」が ZK に基づく必要はなく、オプティミスティック ロールアップにすることもできます。その考え方は、zkEVM によって生成された暗号証明はイーサリアム上でいかなる形でも再実行する必要がなく、証明自体をメインネット イーサリアム上で生成されたブロックの検証に使用できるというものです。ある意味、コンセンサスレベルの互換性を実現する zkEVM は、zkEVM の真の形式です。
一部の開発者にとって、コンセンサスレベルの互換性を実現する ZK ロールアップは、zkEVM と呼ぶべき唯一の ZK ロールアップですが、言語とバイトコードの互換性を持つ他の ZK ロールアップは、それぞれ EVM と同等であるとみなされる必要がありますが、zkEVM ではありません。 zkEVM の正確な定義と、そのさまざまなレベルの EVM の同等性について、イーサリアム開発者の間で多くの議論が行われています。実際、EVM の同等性は範囲であり、上記の各レベルは厳密なカテゴリではありません。 zkEVM 開発の初期の性質は、言語レベルの互換性を目指して構築されたプロジェクトが、ある種のバイトコード レベルの互換性も提供する可能性があり、バイトコード レベルで互換性のある zkEVM が最終的には実質的なコンセンサス レベルの同等性を持つ混合ロールアップに進化する可能性があることを意味します。
イーサリアム上のzkEVMプロジェクトの概要
現時点ではコンセンサスレベルの互換性を実現できる実用的なzkEVMは存在せず、開発者らは依然として研究開発を続けており、イーサリアムコア開発者らはこれを「数年にわたるエンジニアリングの努力」と表現している。一部の zkEVM は言語およびバイトコード レベルで同等の性能を達成しており、主にイーサリアム上のアプリケーション中心である現在の ZK ロールアップ レイヤ 2 エコシステムを改善するためのアイデアを提供します。アプリケーション中心のトランザクションではなく、一般的なスマート コントラクトとユーザー トランザクションを実行する ZK ロールアップを構築するのは困難な作業であり、これまでメインネットで正常に起動できたプロジェクトはほんの一握りです。
以下は、イーサリアム上の 5 つの zkEVM プロジェクトの概要です。
zkSync 2.0
ブロックチェーン開発チームの Matter Labs は 2018 年 12 月に設立され、2020 年 6 月にイーサリアム上で zkSync と呼ばれる独自の ZK ロールアップ プロトコルを開始しました。 zkSync は、合計ロック値でイーサリアム上で 6 番目に大きい L2 ネットワークであり、ETH、ERC 20 トークン、ネイティブ NFT の低ガス転送、アトミック スワップや指値注文など、限られた範囲のスマート コントラクト操作をサポートしています。同社は最近、Andreessen Horowitz 氏率いるシリーズ B ラウンドで 5,000 万ドルを調達し、今後数年間の zkSync エコシステムの拡大に充てる 2 億ドルの財務基金を発表しました。
zkSync 2.0 は、あらゆるタイプのスマート コントラクト操作をサポートするように設計された、言語レベルで互換性のある zkEVM です。 zkSync 2.0 は、UltraPLONK と呼ばれる SNARK に基づく証明アルゴリズムに依存しています。また、LLVM と呼ばれるオープンソースのコンパイラ インフラストラクチャにも依存しており、Solidity やその他の種類のプログラミング言語を zkEVM バイトコードにコンパイルします。このプロジェクトは 2022 年 10 月に「ベイビー アルファ」段階に開始され、2022 年末までに外部ユーザーに完全に公開される予定ですが、Matter Labs チームはまだ zkSync 2.0 プルーフ生成の完全な詳細を明らかにしていません。 L2 ネットワーク間の激しい競争と、ロールアップ テクノロジの初期段階による技術的脆弱性のリスクが大きいため、ほとんどのロールアップ プロジェクトは極秘に実行され、オープン ソースはサポートされていません。 zkSync 2.0 が正常に起動されると、ユーザーはオフチェーン トランザクションからイーサリアムへのオンチェーンではなく、zkPorter と呼ばれる別のプロトコルに状態デルタを公開することを選択できるようになります。この戦略により、理論的には、zkSync 2.0 の 1 秒あたりのトランザクション スループットが 2,000 TPS から 20,000 TPS 以上に増加します。
StarkNet
zkSync と同様に、StarkNet は Starkware チームによって構築された汎用 ZK ロールアップであり、すでにイーサリアム上で実行されています。 Starknet のトランザクション実行環境は StarkNet OS と呼ばれ、そのネイティブのスマート コントラクト プログラミング言語は Cairo と呼ばれます。他の ZK ロールアップと比較して、Starknet は最も完全に機能するブロックチェーン ネットワークの 1 つです。 StarkNet は、オプションのオフチェーン データ ソリューションをユーザーに提供し、非 Volitions タイプのロールアップよりも大幅に低い取引手数料を実現します。 StarkNet オペレーティング システムは、STARK に基づく証明アルゴリズムに依存しています。 zkSync 2.0 と同様、StarkNet OS 上でプルーフを生成するプロセスはオープンソースではありません。競合他社の zkSync と同様に、証明生成に関する詳細は時間の経過とともにオープンソース化され、誰でも専用回線を介してネットワークに接続できるようになります。
StarkNet 自体は EVM との言語レベルの互換性をサポートしていませんが、イーサリアム実行層ソフトウェア クライアントである Nethermind の背後にあるチームは、Warp と呼ばれる Solidity to Cairo 言語コンパイラーを積極的に構築しています。 Warp コンパイラーを使用すると、StarkNet ユーザーは、カイロでコードを書き直すことなく、イーサリアムベースのスマート コントラクトをデプロイできます。さらに、StarkNet と EVM の互換性をサポートするために、別の Solidity-to-Cairo 言語コンパイラーを構築する Kakarot と呼ばれるコミュニティ主導のプロジェクトがあります。
Starkware チームは 7 月にネイティブ StarkNet トークンと新しい基盤の計画を発表しました。トークン配布スキームは、最初の 100 億供給量の 3 分の 1 が StarkNet のコア貢献者に割り当てられることが明らかになった後、論争の種となりました。今年Starkwareは80億ドルの評価額で1億ドルを調達した。このラウンドは投資会社Greenoaks Capital、Coatue、Tiger Globalが主導した。 StarkNet に加えて、StarkWare は StarkEx と呼ばれるカスタマイズ可能なブロックチェーン スケーラビリティ ソリューションもユーザーに提供します。このソリューションは、STARK をベースとした ZK の新技術を活用しています。 StarkNet とは異なり、StarkEx はアプリケーション中心の ZK ロールアップです。 StarkEx を使用してイーサリアム上で優れたスケーラビリティを実現する注目すべき DeFi アプリケーションには、soRare、Immutable、DeversiFi などがあります。
Polygon zkEVM
Polygon チームによって構築された zkEVM (旧名 Matic Network) は、EVM とのバイトコード レベルの互換性を実現します。 Polygon の zkEVM は、2023 年初頭にイーサリアム上で起動される予定であり、最近公開レビューのためにオープンソース化されました。もちろん、コードは公開されていますが、オープン ソース ライセンスに基づいてリリースされていないため、使用、変更、共有することはできません。 Polygon の zkEVM 実装は、SNARK および STARK に基づく証明に依存しています。特に、zk-SNARK は zk-STARK の正しさを証明するために使用されます。これには、zk の生成だけでなく、zk-STARK に関連する高速証明時間を利用できるという利点があります。 -SNARKs コンピューティング リソースが比較的軽いという利点。データ可用性の問題に関しては、Polygon の zkEVM 実装はオフチェーン データ ソリューションをすぐにはサポートしませんが、Polygon は可用性の高いアプリケーションの開発に積極的に取り組んでいます。
2017 年に設立された Polygon は、主にイーサリアムのスケーリング ソリューションに焦点を当てた企業です。同社は2020年6月にPoSと呼ばれるプルーフ・オブ・ステークベースのイーサリアムサイドチェーンをローンチした。それ以来、Polygon の製品プラグインは大幅に成長し、より多様になりました。 zkEVM 実装に加えて、Polygon は他の 2 つの ZK ロールアップ実装、Polygon Miden と Polygon Zero を積極的に開発しています。これらは、Optimistic Rollup と Polygon Nightfall と呼ばれる ZK Rollup を組み合わせたハイブリッド ロールアップ実装です。今年初め、Polygon チームは ICO 以来初となる大規模な資金調達ラウンドを完了し、Sequoia Capital India が率いるベンチャーキャピタル 40 社から 4 億 5,000 万ドルを調達しました。
Scroll
Scroll は、バイトコード レベルで互換性のあるもう 1 つの zkEVM 実装です。 Scroll は、Sandy Peng、Ye Zhang、Haichen Shen によって 2021 年に設立され、2022 年にホワイトリストに登録されたユーザー向けにプレアルファ版のテストネットの開始を発表しました。特に、zkEVM 実装を取り巻くすべてのコードは公開されており、オープン ソース ライセンスの下でリリースされています。 Scroll は SNARK に基づく証明アルゴリズムに依存し、オフチェーンのデータ可用性ソリューションをサポートしません。さらに、Scroll チームは、zkEVM をサポートするためのプルーフ生成のための分散型マーケットプレイスを設計しています。無許可で検閲に耐えられる方法で ZKP を生成するために、世界中のユーザーが実行できる専用のハードウェア施設の構築にも注力しています。
Scroll チームは、Privacy Scaling Ethereum (PSE) チームとして知られるイーサリアム財団のスケーリング ソリューション研究開発チームと緊密に連携しています。 zkSync、StarkWare、Polygon などの他のチームと比較すると、Scroll は規模が小さく、研究に重点を置いており、商業的ではありません。彼らは zkEVM の実装だけに焦点を当てていますが、他の競合チームは他の ZK 関連製品やサービスを持っています。スクロールは今年、ポリチェーン・キャピタルやベイン・キャピタル・クリプトなどの大手仮想通貨ベンチャーキャピタル企業のほか、イーサリアム財団関係者のイン・トン氏やカルロス・アリア氏を含む数人のエンジェル投資家からシリーズA資金で3000万ドルを調達した。
Privacy & Scaling Explorations (PSE)
PSE はイーサリアム財団の研究機関であり、ZKP の最先端の研究とイーサリアムへの応用の研究に重点を置いています。彼らは以前は「AppliedZKP」グループとして知られていました。このレポートで取り上げられている他の zkEVM 実装とは対照的に、PSE の zkEVM は、近い将来の大規模な使用を満たすことに焦点を当てていません (PSE 研究の実践的なコンポーネントは Scroll チームによって実装されています)。 PSE によって研究されている zkEVM は、「enshined Rollup」モデルに従って EVM とのコンセンサスレベルの互換性を達成することに重点を置いています。
PSE 研究で使用された証明アルゴリズムは、Halo 2 と呼ばれる zk-SNARK です。これは、暗号通貨 Zcash (ZEC) の中心開発者である Electric Coin Company によって開発されました。 PSE チームによって構築された zkEVM 実装はオープンソースであり、誰でも貢献できます。 zkEVM に加えて、PSE チームは、共謀防止分散型アプリケーション インフラストラクチャ、ユーザー トランザクション プライバシーの強化、代替暗号署名スキームに関する研究など、他のいくつかのプロジェクトを推進しています。
zkEVM 構築の課題
Ethereum 上で本番環境に対応した zkEVM 実装を構築するには、いくつかの継続的な課題があります。 zkEVM などの新しいテクノロジーの実装、zkEVM の分散運用、zkEVM プルーフを生成するための専用ハードウェアの構築の実証されていないテスト済みの性質は、開発者にとって大きなハードルです。このセクションでは、これらの課題についてのいくつかの洞察について説明します。
新しいフィールド
zkEVM はイーサリアム上の新しいコンセプトであり、正式に実行されるのは 2022 年になります。このテクノロジーの単純な課題は、その性質が実証されておらず、大規模なテストが行われていることです。ほとんどの zkEVM 実装がプルーフを生成する方法、プルーフを生成するためのハードウェア要件、および分散シーケンサーの詳細については、まだ不明な点が多くあります。信頼性の高いスケーリング ソリューションとして zkEVM の信頼を構築することは、Scroll、Polygon、StarkNet、zkSync などのチームにとって重要な焦点です。
分散化の課題
有効性と不正証明の生成は集中化された発注者に大きく依存するため、zkEVM 操作への分散パスを取り巻く問題は、すべてのロールアップ (オプティミスティック ロールアップを含む) に当てはまります。前述したように、シーケンサーは、ユーザー トランザクションをバッチ処理し、これらのバッチの証明をイーサリアム L1 に送信する責任を負う L2 ステークホルダーです。
現在イーサリアム上で実行されているすべてのロールアップは、集中シーケンサーによって操作され、単一のエンティティによって管理されるアップグレード可能なスマート コントラクトに依存しています。現在のロールアップの一元化の主な理由の 1 つは、テクノロジーの初期には、コード内の予期しないバグに迅速な修正が必要であったことです。さらに、特に zkEVM の背後にあるテクノロジーは常に変化しているため、この初期段階のテクノロジーをデバイス上で実行するようユーザーに自信を持って動機付けることが困難になっています。 Rollup の分散型注文者を実装するということは、通常、トークンを起動し、複数の注文者と証明者を許可のない方法で組織するコンセンサス プロトコルを作成することを意味します。トークンの起動とコンセンサスプロトコルの作成はパブリックブロックチェーンにとって新しいことではありませんが、責任を持って起動するには時間と事前の熟慮が必要です。 StarkWareのトークン計画は、その供給設計と初期配布により物議を醸しており、PolygonもzkEVMの立ち上げ後に現在のトークンエコノミクスを改善すると期待されている。 zkSyncは今後数か月以内にロールアップ用のトークンを発売すると予想されているが、Scrollのトークン計画は依然として不明瞭である。
zkEVM の現在の状況では、ソーターの分散化に向けた重要な第一歩は、プロジェクト ソフトウェアをオープンソースにすることですが、この記事の執筆時点ではオープンソースに取り組んでいる人はほとんどいません。すでに多数のユーザーがいるロールアップ zkEVM 実装には、分散型 zkEVM 操作の点で利点がある可能性があります。
zkEVM ハードウェア チャレンジ
zkEVM 証明は検証が簡単ですが、ZKP の背後にある数学が一連の線形計算に依存しているため、その生成には大量の計算が必要です。このため、マシン上でプルーフを生成する作業を並列化することが困難になります。最近、再帰的証明を使用してこの方向に進歩が見られました。再帰的プルーフとは、プルーフのプルーフを繰り返し生成してトランザクションをさらに圧縮し、ZK ロールアップ上のトランザクションの小さなバッチを並行して処理できるようにすることを指し、プルーフ生成のレイテンシを短縮する手法です。これは、StarkNet VM と Polygon の zkEVM が有効性証明を生成するために使用する手法です。
ZKP の生成は計算集約的であるため、zkEVM はグラフィックス プロセッシング ユニット (GPU)、フィールド プログラマブル ゲート アレイ (FPGA)、さらには特定用途向け集積回路 (ASIC) などの高度なハードウェアに依存する必要がある場合があります。プルーフを生成するために必要な計算を実行するには特殊なハードウェアが必要ですが、これは Proof-of-Work (PoW) コンセンサス プロトコルに従ってブロックを効率的にマイニングするために特殊なハードウェアが必要であるのと何ら変わりません。 2 つのハードウェア業界の成長の違いは、プルーバーとマイナーの選択プロセスにあります。
証明者は、有効性の証明を生成する責任を負うネットワークの利害関係者です。一方、シーケンサーは、ユーザー トランザクションを順序付けしてバッチにパッケージ化し、データをレイヤー 1 ブロックチェーンに送信する責任を負います。技術的には、注文者と証明者の責任を 1 つの役割にまとめることができます。ただし、プルーフの生成とトランザクションの順序付けは両方とも効率的に実行するために高度に専門化されたスキルを必要とするため、これらの責任を分割することでロールアップ機能の不必要な集中化を防ぎます。
証明者と発注者の選択プロセスがマイナーの選択プロセスと同様であり、ナカモトのコンセンサスの達成に依存し、最も効率的なハードウェア参加者に報酬を与える場合、ZKP「マイニング」業界はビットコインマイニングと同じ道をたどる可能性があります。トラック開発。ただし、特定の証明者の選択プロセスが、PoW コンセンサスではなく Proof-of-Stake (PoS) に設計が似ている可能性が高い理由はいくつかあります。
まず、サトシ スタイルの選択プロセスは、最も効率的なハードウェアを備えた証明者が証明市場を支配することを意味します。消費電力を削減しながら証明者市場の独占を避けるために、スクロールのようなプロジェクトは、イーサリアムバリデーターが32 ETHをステーキングする必要がある方法とは異なり、証明者が資産を担保としてステーキングすることを要求する代替設計を検討しています。ステーキング モデルの実装により、指定されたトランザクション バッチの有効性証明の計算に失敗するなど、ネットワークのセキュリティと稼働性に違反する行為に対して証明者が罰せられることが保証されます。
すべての証明者を競争させて証明を生成するのではなく、決定論的に証明者を選択して証明を生成することのもう 1 つの利点は、トランザクションのスループットとネットワークのスケーラビリティの向上です。証明者を選択するということは、すべての証明者がトランザクションの同じバッチに対して証明を生成するのではなく、複数の証明者がトランザクションの異なるバッチに対して同時に証明を生成できることを意味します。しかし、何らかの形式の賭けと罰に依存するリーダー選挙システムには、複雑さという弱点があります。サトシ式の PoW システムと比較して、PoS システムは、参加者の正直さを保つために、チェックとバランスのより複雑な設計に依存しています。たとえば、ナカモト式コンセンサスでは通常、報酬を得るために参加者である採掘者が自分の作業の証拠を提出することのみを要求されます。
ほとんどの zkEVM は、確率的 (競合ベース) のパーミッションレス証明者選択プロセスではなく、決定論的 (割り当てベース) を選択することで、Rollup の電力使用量を最小限に抑えようとする可能性があります。イーサリアムの共同創設者ヴィタリック・ブテリン氏は、zkEVM の有効性証明の計算に必要な電力は、ETH のマイニングに使用される電力の 1% 未満であると推定しています。 zkEVM 設計者の目標は、証明時間をできるだけ短縮しながら、できるだけ多くのユーザーが経済的に証明生成にアクセスできるようにすることでした。コンセンサスレベルの互換性のある zkEVM を実現するための要件の 1 つは、プルーフ生成時間をイーサリアム L1 のブロック時間 (平均 13.5 秒) に匹敵するまで短縮することです。
zkEVM の背後にある仕様が明確になり、標準化されて初めて、ZKP ハードウェア メーカーは真に成長し、成熟することができます。最後に、Rollups が証明者とシーケンサーを許可なく選択するモデルを採用して実装しない限り、Validity Proof Computing 業界の電力使用量を予測することは依然として困難です。
zkEVM の競争力の見通し
短期的には、zkEVM 参加者はメインネット上で立ち上げる最初のプロジェクトになることを目指して競い合っています。ただし、長期的には、EVM の互換性レベル (言語からコンセンサス レベルまで) と VM の効率性で競合することになります。 zkEVM の背後にあるテクノロジーがより広くテストされ、使用され、理解されるようになれば、zkEVM はユーザー獲得に関して楽観的なロールアップや他の L2 スケーラビリティ ソリューションと競合する必要がある可能性があります。
先行者利益と後発者利益
zkSync、Polygon、および Scroll チームの zkEVM 実装は、メインネットでの起動を目指して競い合っています。メインネットの早期立ち上げは、DApp 開発者を引き付ける上での先行者利益をもたらす可能性があり、ロールアップ間の相互運用性と DApp の構成可能性の難しさを考慮すると、これは特に重要な利点になる可能性があります。 DApp のコンポーザビリティ、つまりビルディング ブロックのように DApp 上に DApp を構築できる機能は、イーサリアム分散ファイナンス (DeFi) エコシステムの特に重要な機能であり、すでに広く採用されている L1 または L2 によって DApp 開発者が受け入れられる可能性が高くなります。 。
一方で、テクノロジーとしての zkEVM の新規性により、zkEVM の最初のロールアウト実装はイーサリアム DApp 開発者向けに最適化される可能性は低いです。このレポートで述べたように、バイトコード レベルおよびコンセンサス レベルで EVM と完全に互換性のある zkEVM 実装は、まだ実稼働環境で使用する準備ができていません。 Ethereum DApps の展開をよりネイティブにサポートする zkEVM 実装は最初にリリースされるわけではない可能性があり、より多くの EVM 同等物を備えた zkEVM には後発であるという利点があります。同等性が深まるほど、zkEVM 開発者の参入障壁は低くなります。言い換えれば、2015 年以来主要な DApp 実行環境である EVM が移行できるツールが多ければ多いほど、zkEVM DApp 開発者の採用がよりスムーズになります。
EVM の同等性を通じて DApp 開発者を惹きつけることは、zkEVM 実装間の競争の最初の明白な領域であり、DApp 開発者の採用における先行者利益は強力ですが、テクノロジーはまだ初期段階にあるため、重要な反復と改善がまだ必要です。本番環境に対応した zkEVM を構築するためのスペースが確保されます。結局のところ、このゲームはゼロからの革新者のジレンマに似ています。先手となってレイアウトとコミュニティを構築しようとするのが良いのか、それとも後手になってより優れた機能で先手を打倒する方が良いのでしょうか?
仮想マシンの設計
zkEVM の競争と時間の経過による改善のもう 1 つの分野は効率です。前述したように、EVM は ZK システム用に最適化されていないため、汎用 ZK ロールアップの構築はイーサリアムベースのスマート コントラクトと DApps にとって重大なオーバーヘッドになる可能性があります。時間の経過とともに、SNARK または STARK プルーフ用に最適化された他の仮想マシン設計により、EVM の互換性が低下する可能性があります。これは Starkware チームが強く抱いている見解です。 Solidity を Cairo の Warp ツールにコンパイルするなどの作業は、コミュニティ主導の取り組みであり、社内の StarkWare チームは、単に EVM と互換性があるというよりも、StarkNet の仮想マシンを可能な限り効率的にすることに重点を置いていました。
Ethereum では、DApp の下位互換性を壊さずに EVM (および関連する Solidity) を大幅に変更またはアップグレードすることはできないことに注意してください。 EVM が 2015 年にリリースされて以来、開発者は EVM とその高レベル プログラミング言語である Solidity をいじくり回し、使いやすさとセキュリティを小さな方法で改善してきました。たとえば、2019 年の Ethereum Istanbul ハード フォーク アップグレード中に、コア開発者は、正規チェーンの一意の識別子を返す「CHAINID」と呼ばれる新しいオペコードを EVM に追加しました。これは、ノードが CHAINID をチェックできるようにすることで、アップグレードされたノードがアップグレードされていないノードに接続するのを防ぐためであり、「リプレイ攻撃」を防ぐのに特に役立つアップグレードです。
イーサリアムのコア開発者らは、イーサリアムの開発ロードマップではEVMのさらなるアップグレードが今後も行われると主張してきた。新しいオペコードとプリコンパイルは今後も EVM に追加される可能性が高く、既存の zkEVM 実装は EVM の変更に対応できる柔軟性が必要であることが示唆されています。ただし、これらの改善があっても、Mina、Sui、Aptos などの L1 ブロックチェーンには、さまざまな仮想マシンやスマート コントラクト言語の設計を実験する機会がまだあり、長期的には EVM が時代遅れになる可能性があります。 zkEVM 実装は主に、バイトコードおよびコンセンサス レベルでの EVM との深い互換性に焦点を当てており、スマート コントラクト開発における EVM の関連性と優位性に長年賭けてきました。
楽観的ロールアップから ZK ロールアップへ
結局のところ、このレポートで説明されている 5 つの zkEVM 実装が Optimism や Arbitrum などの Optimistic Rollups を上回るということは、当然の結論ではありません。技術レベルでは、ZK ロールアップは楽観的なロールアップよりも安全で効率的で、潜在的にコスト効率も高くなります。ただし、EVM 用に設計された汎用コンピューティングを証明する柔軟性は、大規模にテストおよび展開されていません。 zkEVM が開始され、その背後にあるテクノロジーがより成熟して堅牢になると、不正証明ベースのオプティミスティック ロールアップ (Optimism や Arbitrum など) がアップグレードされ、有効性証明の生成に移行する可能性があります。さらに、ハイブリッド ロールアップ システムとマルチ証明者システムは、不正証明を使用してユーザー トランザクションを楽観的に検証し、有効性証明を断続的に発行します。
zkEVM の背後にあるテクノロジーが進化するにつれて、有効性証明の生成時間を徐々に高速化することは活発な研究分野となり、Vitalik Buterin のような Ethereum コア開発者や Optimism の Kelvin Fichter のような L2 開発者によって今日真剣に議論されています。
結論は
結論は
最近のzkEVMへの市場の関心の高まりにより、イーサリアムのスケーラビリティロードマップの最終段階についていくつかの疑問が生じています。本当の意味で、zkEVM (EVM とのコンセンサスレベルの互換性を備えた ZK ロールアップ) は、スマート コントラクト実行の主要プラットフォームとしてイーサリアムに賭けながら、EVM の優位性に対する長期的な賭けを表します。 zkEVM は、トランザクションの実行をコンセンサスやデータの可用性と組み合わせるのではなく、ロールアップに抽象化することに重点を置いているため、イーサリアムのスケーラビリティ ロードマップに対する長期的な賭けでもあります。
今年は、ほぼ量産準備が整った zkEVM がいくつか発表されましたが、この技術はまだ初期段階にあります。 EVM とのコンセンサスレベルの互換性を備えた zkEVM の実現はまだ研究プロジェクトであり、製品化の準備が整うまでには何年もかかる可能性があります。ただし、同じことは zkEVM にも当てはまり、ちょうど 1 年前に EVM とのバイトコード レベルの互換性を達成しました。 Polygon、zkSync、StarkWare、および Scroll による zkEVM 実装の急速な開発は、コンピューター科学と数学の限界を予想を超えて押し広げ続けています。イーサリアムメインネット上での Polygon zkEVM と zkSync 2.0 のリリースは、実際のユーザーと DApp アクティビティで zkEVM をテストするための重要な開始点となります。
2 つの実稼働対応 zkEVM の可用性とスケーラビリティにより、zkEVM の競争環境だけでなく、オプティミスティック ロールアップや L1 の競争チェーンも破壊される可能性があります。 zkEVM が成功した場合、長期的に競争力を維持するには、オプティミスティック ロールアップを ZK ロールアップ設計に変換する必要があります。 L1 オルトチェーンも、スケーラブルな EVM と競合するために、仮想マシンの設計を革新する必要があります。イーサリアム上の ZKP の準備性と適用性についてはまだ証明されていないことが多く、本番環境に対応した zkEVM の発売は、この新しいテクノロジーの競争環境の始まりと見なされるべきです。
元のリンク
