ログイン/ 登録

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

2023/12/25 19:00

従う

著者：アレックス・コノリー（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時代

zkSyncのEraは2023年3月にリリースされ、これまでのところ成功したと考えることができます。彼らはEtherNetとの「言語レベルの互換性」を目指しており、SolidityコードからカスタムVMへの直接コンパイラを提供している。彼らは、主要なEVMオペコードの多くの実装に大幅な変更を加え、コンパイルプロセスにも変更を加えているため、開発者はzkSync Eraにデプロイするために、しばしばコントラクトやデプロイスクリプトを変更する必要があります。

zkSync Eraは独自のカスタムクライアントを持っており、ネイティブのアカウント抽象化など、EVM以外の機能を実装することができます。zkSync Eraは完全なオンチェーンデータを必要とするが、将来的には "zkPorter "を導入する予定であり、これによりユーザーはStarkWareと同様に、異なる価格帯で異なるデータ利用可能モデルを選択できるようになる。これは、StarkWareが提案したVolitionモデルと同様に、ユーザーが異なる価格帯で異なるデータ利用可能モデルを選択できるようにするものである。

(7)StarkNet

StarkNetはイーサリアムエコシステムで最も野心的なプロジェクトの1つで、新しいVM(CairoVM)、新しいプログラミング言語(Cairo)、新しい証明書(2021年と2022年に順次オープンするStarkNetは、現在1億5000万ドル以上のTVLを誇り、毎月1000万件以上のトランザクションを処理している。

新しいエコシステムを一から構築することは挑戦的なことですが、ネイティブアカウントの抽象化など、EVMが苦戦してきた分野で根本的な革新をもたらす機会にもなり、パフォーマンスを劇的に向上させます。このツールチェーンの多くは、Immutable X、dydx v3、SorareといったStarkExベースのプロジェクトを通じてすでに大規模なテストを終えており、これらは2020年から稼働しており、広く採用されている。

当初、スタークネットのエコシステムは、昨年紹介したWarp Solidity→Cairo translatorなどのプロジェクトを通じて、言語レベルの互換性を模索していました。しかし、Warpはもはや時代遅れであり、StarkNetエコシステムは新しいCAIROツールセットに完全にコミットし、Solidityの後方互換性をサポートしないことを決定した。彼らは今、SolanaやSuiのような非EVMエコシステムと同じ課題に直面している。それとも、EVMの普及が勝つのでしょうか?

唯一の例外は、Kakarotチームが行っている作業で、CAIRO言語を使用したタイプ2.5のEVMを開発している。Kakarotを使えば、ユーザーはStarkNet上のコード/ステートを持つEVMコントラクトをデプロイしてやり取りできるようになり、EVMとの互換性を保ちながらStarkNetのパフォーマンスを享受できるようになります。基本的な実行環境はStarkNetであるため、イーサネットツールの互換性は犠牲になりますが、プロジェクトによっては許容できるトレードオフかもしれません。Kakarotはまだ生産レベルには達しておらず、このレイヤーアプローチのパフォーマンスとツールの互換性への影響は不明ですが、これはさまざまなzkEVMタイプ間のギャップを埋めるエキサイティングな試みであり、私たちがデザインスペースの探求を早くから進めていることを示しています。

(8)楽観主義

明らかな理由から、オプティミズムはしばしば楽観的なロールアップを重視するチームと考えられている。しかし、彼らは将来のオプションとしてzkのゼロ知識証明をサポートする予定であると繰り返し述べており、いくつかの積極的に貢献しているチームと活発な議論を行っています。zeth のようなエキサイティングな zk エコプロジェクトは、現在 Optimism ブロックのサポートを提供しています。おそらく、来年のzkEVMレビューでエキサイティングな変更があるでしょう！

お分かりのように、さまざまなkEVMチームの間で、アプローチには多くの違いがあります。同じタイプのロールアップであっても、証明者、クライアント、シーケンスメカニズムから非常に異なる設計を使用していることがよくあります。

これらの新しいzkEVMを比較するもう1つの非常に重要な方法があります。実際の構成です！一般に、簡単に変更できるアプリケーションレベルの構成よりも、基本的な設計上の決定が関係するため、各チェインのクライアントとプローバーのアーキテクチャを分析する方がはるかに興味深いです。しかし、アプリ開発者であれば、特定の構成が重要であることは間違いないので、各zkEVMのブロック時間、ブロックガス制限、証明リリース頻度、シーケンサーのコンセンサスメカニズム、およびアプリのユーザーエクスペリエンスに影響する可能性のあるものは必ず調べてください！

結論から言うと、2023年にはさまざまなチームによって多くの開発が行われています。では、すべてが進んでいるのであれば、このまま待つしかないのでしょうか？zkEVMが実質的な牽引力を得るためには、他に何に取り組む必要があるのでしょうか？

2、zkEVMの開発における未解決の課題は何ですか?

第一に、クライアントと証明者間の標準化されたインターフェースがありません。現在、各プローバーは、最初にそれらを構築するために使用されたクライアントとしか互換性がありません。理想的には、新しいプローバやクライアントは、できるだけ多くの既存のプローバ/クライアントと互換性があるべきである。様々なzkEVMチームが単一インターフェースのEIPに従うように促すことは、将来の開発にとって重要なステップである。

理解できるように、ほとんどのチームは現在、他のチームとの互換性を求めるよりも、自分たちのデプロイメントを改善することを優先しています。しかし最終的には、L2ソートされたzkEVMがマルチクライアント/プローバのセットアップを使用し、大きなバグが発生するリスクを減らすことを特に望みます。加えて、"古典的な "タイプ2関数の実装を標準化することで、複数の検証者が同一または類似のクライアントを使用できるようになるかもしれない（例えば、Sparse Merkle treeや、keccakの代わりにPoseidonハッシュ関数など）。geth "クライアントの数を減らすことは、エコシステムにとって大きな勝利となるだろう！RollCall」と呼ばれる標準化イニシアチブが、一連のロールアップ最適化提案（RIP）とともに提案されているが、このイニシアチブがどの程度注目されるかはまだ明らかではない。

第二に、これらのzkEVMのほとんどすべてが単一のシーケンサーであるという事実は、これらのロールアップの分散化とセキュリティに対する挑戦です。特に、プローバーの動作はL1-L2ブリッジが安全であることを保証するだけであることに注意。L2の事前確認に依存する外部システム（例えばCEX）は、単一のシーケンサーにのみ依存するため、多くの資金をリスクにさらすことになる。今日のL2の多くにとって、非常に破壊的なハッキングは単一のシーケンサー・キーを盗むだけで済むだろう。しかし、ひとたびシーケンサーを分散化すると、別の課題が発生する（上の太鼓のコンテンツを見ればわかるだろう！）。.L2のコンセンサスが得られたことをL1にzkで証明する必要があるのか？アクティビティの問題やMEVについてはどうでしょうか？ほとんどのシングル・シーケンサー・ロールアップは、ブランド/評判/チェーンの信頼性の理由から、現在MEVを利用していませんが、将来的には変わるかもしれません。

第三に、zkEVMのパフォーマンスとコストを測定するための標準的なフレームワークはありません。この論文の多くは、さまざまな zkEVM 設計の潜在的なパフォーマンスへの影響を比較していますが、現時点で実際のパフォーマンス仕様やテストを公開している zkEVM チームはほとんどありません。zkEVM コスト」は、

- proof-of-cloud コンピューティングのコストの生成（回路効率に影響される）

から構成されます。- L1 証明の検証コスト

- data availabilityのコスト

- 1 つの層から別の層へ情報を送信するコスト

これらの領域について標準化されたテストを作成し、その結果を集計して、建設業者がより多くの情報に基づいた決定を下せるようにしなければなりません。また、トランザクション・パッケージ全体にトランザクション・コストを分散させることができるため、コストの一部は使用量に依存する。また、これらのコストをどのようにユーザーに提示すべきかについては、多くの不確定要素がある（例えば、Immutable zkEVMは、ほとんどのケースでユーザーのパブリッシングコストを支払う予定であるのに対し、Scrollは、すべてのトランザクションが利益を生むように、複雑なL1 + L2チャージ設定を行っている）。加えて、多くの zkEVM はステートの成長に関連するパフォーマンス問題を経験する可能性があります！これらはすべて、現在よりもはるかに高度な測定可能性/比較可能性が必要になります。

第4に、ほとんどのスマートコントラクトのロールアップでは、終了メカニズムがまだよく理解されておらず、定義されていません。セルフホスティングは、Immutable Xのようなアプリケーションに特化したロールアップではよく定義されています。そのL1ブリッジに預けたアセットは、たとえシーケンサーが完全にオフラインであっても、完全に悪意があっても、回収可能であるべきです。これはしばしば「エスケープハッチ」と呼ばれる。しかし、スマートコントラクトのロールアップの場合、これは何を意味するのでしょうか？あなたのETHが、いずれにせよ利用できないはずのコントラクトに誓約されていたらどうなるのだろうか？これは検閲への耐性がすべてなのだろうか（トランザクションを強制する能力を保証する必要があるのだろうか）？異なる目的（例：ゲーム資産 vs. DeFi）で使用される zkEVM に対して、どの程度のデータ可用性が許容可能か？現実世界の障害シナリオをユーザーに伝えるための一貫したフレームワークが必要です！

第5に、zkEVMとイーサネットL1の関係は不明確です。この記事を書いている間に、V. God による「enchrined zkEVM」を振り返るブログ記事に再び興味をそそられました。主なポイントは、イーサネット・クライアント層は、他のソース (たとえば L2) から提出された EVM ブロックの実行を検証するために使用できる zk 証明実装を「安置」できるということです。これにより、すべてのL2 zkEVMがzkEVM証明器を最新の状態に保つ必要がなくなります（大きな利点です！）。--イーサリアムのコア・クライアント・チームを含む他のチームの成果物に依存することができ、完全にSNARKなイーサリアムが現実のものとなりました。つまり、「zkEVMを安置する」という提案は、イーサセントリックのL2スケーリングロードマップからの逸脱であり、L2によって獲得された価値を取り戻すものだと読むべきでしょうか？

そうではありません。L2は依然として、高速な確認（ゲームなどの分野で重要です）を提供するために独自のシーケンサーを必要としており、Vの提案する設計は、完全なオンチェーンデータを持つzkEVMのみをサポートします。これはイーサリアムのエコシステムにとって重要なトレードオフです。L2はイーサブロック空間のスケーリングにとって重要ですが、その動機（とBDチーム）は必ずしもイーサと一致しているとは限りません。

最後に、複数のzkEVMはユーザーと流動性を分断し続け、ユーザーエクスペリエンスの低下を招きます。今日、イーサリアムのL2が追加されるたびに、状態と流動性が分断され続けます。Arbitrumに2つのETHがある場合、他のL2のETHにアクセスすることは困難です。私見では、これはモノリシックチェーンに対するこれまでの最良の議論であり、コンポーザビリティが大幅に改善され、ユーザーは複数のチェーン間でバランスを取る必要がなくなります。現在の「L2ツールキット」(例えばPolygon CDK、Arbitrum Orbit、OP Stack)の人気により、チェインを開始するのはかつてないほど簡単になっていますが、その代償として、より大きな断片化の問題があります。

このマルチL2モデルが長期的に成功するためには、ほとんどの場合、個々のチェーンとバランスをユーザーから抽象化する必要があります。これは、不正の証明よりも有効性の証明、つまり高速なチェーン間ブリッジの検証を瞬時に証明することを強く主張する論拠のひとつである。しかし、強固なブリッジング／相互運用性のフレームワークがあっても、対処すべきユーザー・エクスペリエンスの問題はまだ数多く残っています。イミュータブルでは、ウォレット層のイミュータブルパスポートと垂直統合と...でこれに対処する計画です。

3、結論

zkEVMにとって、2023年は開発の進捗にとっても、実際の採用の準備にとっても重要な年になるでしょう。しかし、現実的には、私たちがそれらを使用できるようになるのは、早くても第 3 四半期から第 4 四半期になるでしょう！

2024年にzkEVMが解決しなければならない主な問題は、技術的な問題ではなく（解決しなければならない技術的な問題がまだいくつかあることは明らかですが）、価値の問題であることを明確にしておきたいと思います。エキサイティングなアプリケーションを生み出すことができるか？私たちには、優れたプロトコル開発者と優れたアプリ開発者が必要なのです！

有益なレポートを通じて仮想通貨業界の幅広い理解を得て、志を同じくする他の著者や読者との詳細な議論に参加してください。拡大している Coinlive コミュニティにぜひご参加ください。https://t.me/CoinliveSG

コメントを追加する

ログインあなたの素晴らしいコメントを残すために…

0 コメント

最も早い

コメントをさらに読み込む