主なzkEVMプロジェクト2023進捗状況ラウンドアップ

著者：アレックス・コノリー（Alex Connolly）、イミュータブル（Immutable）共同創設者兼CTO、翻訳：ゴールデンファイナンス（Golden Finance）xiaozou

2022年8月、私は「Ground Up Guide to zkEVM, EVM Compatibility and Rollups（zkEVM、EVM互換性およびロールアップのためのグラウンド・アップ・ガイド）」と題した、zkEVMの現在の開発状況に関するブログ記事を書きました。同じ週に、V神はzkEVMのさまざまなタイプに関する記事を投稿し、タイプ1、タイプ2の分類法を確立しました！

そのブログ投稿で、私は次のような予測をしました:

......も、スマートコントラクトのの現在の意識状態にも興味を持つはずです。どのチームも、「世界を征服しようとしている」チームであることを売り込む強い動機を持っています。"プロダクショングレード"のスマートコントラクトがイーサで利用できるようになるのは早くても2022年末までで、これらのチームの多くは2023年後半まで準備が整わないでしょう。

現在「2023年末」ですが、zkEVMの開発と採用の状況はどうなっているのでしょうか？

- Polygon zkEVM、Linea、Scrollがリリースされました！

- Immutable が次のロールアップを発表 - Immutable zkEVM

-。

- Polygon PoSをzkEVM Validiumにアップグレードする計画を発表

- Optimism がzkEVMとして動作するOPスタックチェーンをサポートする計画を示す

一言で言えば、zkEVMの開発は進んでいるが、既存のブロックチェーンと比較すると以下のようになる。既存のブロックチェーンと比較して、zkEVMはまだ大きな普及を遂げていません。この投稿の目的は、さまざまなzkEVMプロジェクトはどのように進んでいるのか、そして歓迎されるほどの注目を集めるにはどうすればよいのか、という明白な疑問に答えることです。center">

これは複雑に見えるかもしれないが、実は非常に理解しやすい。zkEVM は単に既存のイーサネット実行クライアント (Geth、Nethermind、Erigon など) を取り込み、その実行トレースの zk (ゼロ知識) 証明を生成し、それらの証明を使って L1-L2 メッセージのブリッジングを保証するものだと、当初は誰もが考えていました。しかし、EVMの当初の設計にはzk証明が含まれておらず、このアプローチは非常に非効率的です（例えば、Etherのkeccakハッシュ関数はコストが高い）。

- Type 1 - 対処するだけで、ユーザーや私はそれにお金を払います。既存のブロックチェーンのタイプ1プルーバー（証明手順）を利用できること、独自のイーサリアムクライアント（証明と同じくらい開発コストがかかる）を維持する必要がないこと、しかしクライアントのアップデートを実行し続けなければならないことです。

- Type 2 - 「アプリケーション層」には触れませんが（例えば、オペコードのコストや実装を変更しません）、チェーン上のノードをより証明者に優しいものに変更します。しかし、連鎖上のノードをより検証者に優しいものに変更する（例えば、状態を表現するためにスパース・メルクル・ツリーを使用する）。このアプローチの大きな欠点は、永久にフォークされたEtherクライアントを維持する必要があることです。イーサがすでに複数のプロダクショングレードのクライアントを維持するのに苦労していることを考えると、これはブロックチェーンエンジニアの専門チームを必要とする非常に重要な作業です。

- Type 3 - Type 2のすべての作業を完了させる一方で、EVMを修正して証明の最も難しい部分（たとえば、ほとんど使用されないプリコンパイルの一部）を削除します。を削除するようにEVMを修正する。これは、あなたのプローバーを市場に投入する最も速い方法ですが、上記のクライアント側のアップデートをすべて行う必要があり、既存のイーサリアムアプリやツールとの非互換性が発生します（例えば、これらのプリコンパイルを使用するコントラクトのブレーク）。

- Type 4 - 効率的なzk証明のために設計されたカスタムVMを作成し、そのVMを実行するカスタムクライアントを作成する。これは検証コストを大幅に削減しますが、カスタムVM/クライアントをサポートするためのツールやインフラの大規模なエコシステムを構築する必要があります。何らかの形でSolidityのコード変換を提供できるかもしれないが、開発者は既存の契約やツールを大幅に変更しなければならないかもしれない。私の意見では、ほとんどのタイプ4のロールアップは真のzkEVMではなく、「スマートコントラクトのzkロールアップ」の方がより正確な表現かもしれません。

おそらく表形式の方が理解しやすいでしょう。

2023年末までに、事実上すべてのアクティブなプロジェクトがタイプ3またはタイプ2である。タイプ 3またはタイプ 4 ロールアップです！興味深いことに、現在タイプ3であるほとんどすべてのプロジェクトは、イーサとの互換性を向上させ、独自のクライアントを開発する必要性をなくす可能性があるため、最終的にはタイプ2またはタイプ1のロールアップになることを計画しています。

昨年のブログ記事では、さまざまなzkEVMチームがどのようにプロバーを設計しているかに焦点を当てました。今年は、あまり議論されないこと（さまざまなzkEVM実装クライアント計画など）を含め、プロジェクトのアプローチの他の重要な側面を取り上げたいと思います。たとえば、多くの人はL2を「シーケンサー」と「プロヴァー」と考えていますが、標準的なzkEVMの設計は実際にはもっとこうなっています！

他のシーケンサー設計もありますが（これについては後述します）、ほとんどのzkEVMは現在、L2シーケンサーとして別のブロックチェーンを実行する予定です。独自の実行クライアント（トランザクションを受信して実行する）とコンセンサスクライアント（すべてのL2ノードのトランザクションの順序についてコンセンサスを得る）を持つ。

重要なのは、標準イーサリアクライアントを変更して独自のカスタムチェーンを作成するにはコストがかかるということです。すべてのイーサリアムクライアントの変更（特にすべてのハードフォーク）は、すべてのzKEVMチームにとってガバナンスの決定項目となります。カスタムパーツが多ければ多いほど、上流の変更は難しくなります。時間が経つにつれて、zKEVMの非同期が発生しやすくなります。ある時点でイーサと一致するzKEVMはすぐに同期が取れなくなります。

1, zkEVMプロジェクトの状況

それでは、私たちが昨年調査したプロジェクトはどうなったのでしょうか?

(1)ポリゴンzkEVM (およびポリゴンCDKチェーン)

ポリゴンzkEVM (およびポリゴンCDKチェーン)

ポリゴンzkEVMは2023年3月にメインネットで稼働し、現在までに約1000万件の取引を処理している。

もちろん、タイプ2/3として、Polygon zkEVMは独自のカスタムクライアントを実装する必要がある。Polygonは互換性のために独自のクライアント(zkevm-node)をゼロから構築することを選択しましたが、この新しいクライアントはダウンタイムインシデントがあり、標準的なイーサリアムクライアントが持つ機能の多くが欠けていました。

これを補うため、Polygonはgateway.fmと提携し、Erigon（旧turbo-geth）を修正し、Type 2/3のプローバーに必要な変更をサポートしました。これによってPolygon zkEVMは、より安定したベースレイヤーと、より最適化されたパフォーマンスを提供することになりますが、アップストリームのErigonとの互換性を維持することは継続的な課題です。

また、Astar、OKX、Palm Networkなど、多くのチームがPolygon Chain Development Kit（CDK）を使用してzkEVMを構築すると発表しました。クライアント、プローバ、データ・アベイラビリティ・ソリューションを組み合わせて独自のカスタムチェーンを構築する（つまり、独自の zkEVM ツールキットを構築する）ことにより、開発者が独自のニーズに応じて zkEVM を構築することをサポートすることです。現在、CDK は 1 つのクライアント実装（zkevm-node）と 1 つのプローバ（Polygon zkEVM）をサポートしています。将来的には、PolygonチームはCDKにさらに多くのクライアント実装（Type-2-Erigonなど）とプローバ（Polygon Zeroなど）を追加する予定です。

つまり、今日から独自のバージョンの Polygon zkEVM をデプロイできるようになります。 ただし、チーム用の zkevm-node を使用したデプロイは、他のクライアントに移行する必要があります。チーム用の zkevm-node を使用したデプロイは、将来的に他のクライアントに移行する必要があるかもしれません。

また、PolygonはPolygon PoS（世界最大かつ最も成功したブロックチェーンの1つ）をオフチェーンデータを持つzkEVMにアップグレードする予定ですが、アップグレードの正確なスケジュールはまだ決定していないことにも留意しておく必要があります。

(2)Scroll

Scrollは2023年に2つのテストグリッドとメイングリッドで稼働しました（10月）。Scrollは現在タイプ3のzkEVMであり、将来的にはタイプ1/2に切り替える意向を表明しているが、その正確な時期はまだ明らかではない。ScrollのクライアントはGeth v1.10.13のフォークであり、現在はシングルシーケンサモードで動作している。ScrollのクライアントはGeth v1.10.13のフォークで、現在シングルシーケンサーモードで動作している。Scrollの実行クライアントの一部は、アップストリームのイーサリアムからすでに2年遅れていることは注目に値する（ただし、アプリケーション層の偏りを最小限に抑えるために上海の実行クライアントのEIPを選択している）。これはチェーンに直ちに混乱をもたらすものではありませんが、多くのプロジェクトが、長期にわたって上流のイーサリアムにどれだけ近づけるか、そしてそのギャップを縮め続けるためにどれだけのエンジニアリング努力が必要かを決定する際に直面するガバナンスの課題を示しています。

(3)イミュータブルzkEVM

7月以来、イミュータブル（Immutable）zkEVMは公開されています。zkEVMはパブリック・テスト・ネットワークを持ち、1月にメイン・ネットワークで稼働する予定です。immutable zkEVMは、コア・ドメイン（ゲーム）用にカスタマイズされた標準的なgo-ethereumクライアント・バージョンを使用しています。興味深いことに、Immutable zkEVM は、イーサリアムのセキュリティを維持しながらドメイン固有の要件を満たすようにカスタマイズできる L2 の能力が主な魅力の 1 つであるにもかかわらず、この記事でこれまでに調査された唯一のドメイン固有の zkEVM です。例えば、Immutable zkEVM はコストを削減するためにバリディウム・データを使用し、ほぼ瞬時に確認を行うためにシングルブロックのファイナリティ PoSBFT デザインを選択しました。

しかし、このチェーンのリリースでは、証明書のサポートは提供されません。Immutable zkEVMがType 1のPolygon Zeroを採用するのは、そのプロセスが使用可能で費用対効果が高いことが証明されたときを予定しているからです。ImmutableがType 3をリリースする唯一の方法は、クライアントに大幅な変更を加えることですが、クライアントがEtherから逸脱することの影響を考えると、私たちはそれをしたくありません。現在、Polygon ZeroはPlonky-2を搭載しています。Plonky-3は現在活発に開発中で、2024年中盤から後半にはプロダクショングレードに達する見込みです。これにより、Polygonは2つの独立したプローバー（Polygon ZeroとPolygon zkEVM）を持つことになり、開発者はCDKベースのチェーンで使用するプローバーを選択できるようになります。Linea

Lineaは8月にメインネットをリリースし、Polygon/Scrollと同様のアプローチを取った。Lineaが現在Ethernet Londonと異なるのは、表に示すようにいくつかの点だけです。

リネアは、"zkGeth "と命名された独自のGethのアップデート版を使用しています。このクライアントのソースコードはオープンソースではなく、証明書もオープンソースではありません。リネアは、十分に文書化された分散化ロードマップの一環として、これらのコンポーネントをすべてオープンソース化する予定であり、リネアの文書によれば、「zkGeth」から、Consensysが開発したBesuクライアントの更新版である「linea-besu」に移行する予定である。中期的には、リネアチームはlinea-besuを通常のbesuとマージし、Besuのプラグインシステムに依存して、タイプ2のzkEVMになるために必要な状態変更を行うことを計画している。

(5)Taikoはこのプロジェクトにしばらく取り組んできた。strong>Taiko

Taikoは5番目のテストネットワークを磨き上げており、来年にはメインネットワークで稼動する予定です。Taikoは、（Scrollに似た）zk proverの独自のPSEベースの実装に取り組んでいます。興味深いことに、Taikoはこの記事の中で唯一、単一のシーケンサーをL2ブロックチェーンに漸進的に分散化するという設計パターンを現在検討していないチームである。Taikoのデザインは、Justin Drakeが説明したBased Rollupというコンセプトに基づいている。この実装は、ロールアップがソートを完全にEther L1に委ねることを意味し、Ether L1の活動性と分散性を自動的に継承することを可能にする。しかし、これには重大な欠点がある。L2シーケンサーは「高速な最終確認」を提供しないため、ユーザーはトランザクションが確認されるまで長く待たなければならない。Justin Drake氏は、待ち時間を提供するために「Based pre-confirmations（事前確認に基づく）」メカニズムを提案している。Justin Drakeは、わずか100msのレイテンシで確率的な確認を提供する "Based preconfirmations "メカニズムを提案しているが、これは本番レベルには程遠く、"preconfirmation promise "と "preconf tips "を別々に導入するのは得策ではない。個別の "preconf promise "と "preconf tips "システムの導入は、既存のイーサリアムツールに影響を与える可能性がある。これは活発な研究分野です！

Taikoは当初からType 1 zkEVMになるつもりだと言っており、他のzkEVMによってもたらされる互換性の違いは、証明生成のコストが高くなることよりも悪くなると考えています。興味深いことに、コアとなる「実行クライアント」はGeth v1.13（taiko-geth）を改良したものだ。しかし、L1との通信を処理し、ベースとなる順序付けプロセスを監視する独自の「コンセンサス・クライアント」（taiko-client）も維持している。

(6)zkSync時代