5種類のZK-EVMのアーキテクチャ、メリット・デメリット、解決策を詳しく解説

原作者：s

原文編集：Deep Tide TechFlow

この記事では、5 つのタイプの ZK-EVM について詳しく説明し、それぞれに独自のアーキテクチャ、長所と短所、考えられる解決策があります。

さらに、この記事では、読者が実際のアプリケーションにおけるこれらのタイプのパフォーマンスをよりよく理解できるように、いくつかの実践的なプロジェクトの例もリストします。あなたがブロックチェーン開発者であっても、ブロックチェーン技術に興味のある読者であっても、この記事は詳細かつ簡潔な洞察を提供します。

ZK-EVM の種類とその長所と短所を見てみましょう。

1. タイプ 1: イーサリアムと完全に同等。

2. タイプ 2: EVM と完全に同等。

3. タイプ 2.5: EVM と部分的に同等。

4. タイプ 3: EVM とほぼ同等。

5. タイプ 4: 高級言語が同等です。

タイプ 1: イーサリアムと完全に同等

アーキテクチャ: イーサリアムとまったく同じであり、イーサリアム システムのどの部分も変更されません。

＃＃＃ アドバンテージ

完璧な互換性:

• イーサリアムブロックを検証する機能;
• イーサリアム L1 のスケーラビリティを高めるのに役立ちます。
• 多くのインフラストラクチャを再利用できるため、ロールアップに適しています。

欠点

完璧な互換性:

• イーサリアムは元々 ZK 機能用に設計されたものではありません。
• イーサリアムの多くのコンポーネントは、ZK プルーフ (ZKP) を生成するために大量の計算を必要とします。
• イーサリアム ブロックのプルーフの生成には何時間もかかります。

問題の解決策:

• 大規模な並列化証明者;
• ZK-SNARK ASIC。

タイプ 2: EVM と完全に同等

建築：

※データ構造（ブロック構造やステートツリー）はイーサリアムとは大きく異なります。

• 既存のアプリケーションと完全な互換性があります。
• 開発を容易にし、プルーフ生成を高速化するためにイーサリアムに若干の変更を加えました。

＃＃＃ アドバンテージ

• タイプ 1 よりも速い校正時間を実現します。
• EVM はデータ構造に直接アクセスしません。
• イーサリアムで実行されるアプリケーション: タイプ 2 で実行される可能性があります。
• 既存の EVM デバッグ ツールおよびその他の開発インフラストラクチャのサポート。

欠点

デメリットを理解する前に、まず「ケチャック」とは何かを理解してください。

• イーサリアムブロックチェーンのハッシュアルゴリズム。
• イーサリアム上のデータを保護するために使用されます。
• メッセージがハッシュに変換されていることを確認してください。

タイプ 2 は、履歴ブロックのマークル証明を検証して履歴トランザクション、領収書/状態に関する情報を検証するアプリケーションとは互換性がありません。これは、ハッシュ アルゴリズムが変更されると (Kecck ではなくなると)、証明が無効になるためです。

Keccak は、マークル証明 (アルファベット) を使用する言語と考えることができます。ZK-EVM が Keccak を別のハッシュ アルゴリズム (Poseidon など) に置き換えると、マークル証明は馴染みのないものになり、アプリケーションはマークル証明を読み取ってその主張を検証できなくなります。

欠点に対する潜在的な解決策: イーサリアムは、将来的にはスケーラブルな履歴アクセスのプリコンパイルを追加する可能性があります。

＃＃＃ 計画

• スクロール; ※ポリゴン・エルメス。

ただし、これらのプロジェクトは、より高度なプリコンパイルをまだ実装していないため、不完全なタイプ 2 と見なすことができます。

タイプ 2.5: EVM と部分的に同等

建築：

ZK を証明するのが難しい特定の EVM 操作のガスコストを増加します。

• プリコンパイル済み。
• Keccak オペコード;
• コントラクトを呼び出すモード。
• メモリにアクセスします。
• 保管所。

＃＃＃ アドバンテージ

• 最悪の場合の証明時間が大幅に改善されました。
• EVM スタックにさらに深い変更を加えるよりも安全です。

欠点

• 開発ツールの互換性が低下します。 ※一部動作しないアプリもございます。

タイプ 3: EVM とほぼ同等

建築：

• ZK-EVM 実装では、実装が非常に難しい一部の関数が削除され、通常はプリコンパイルされます。
• ZK-EVM はコントラクト コード、メモリ、スタックの処理方法に若干の違いがあります。

＃＃＃ アドバンテージ

• 検証時間を短縮します。
• EVM の開発を容易にします。
• 目標は、互換性の低いアプリケーションの書き換えを最小限に抑えることです。

欠点

• さらなる非互換性; ※タイプ3で削除されたプリコンパイルを使用するアプリケーションは書き直す必要があります。

＃＃＃ 計画

現在、Scroll と Polygon は Type 3 とみなされますが、ZK-EVM チームは Type 3 であることに満足すべきではありません。Type 3 は、ZK-EVM が互換性を向上させるためにプリコンパイルを追加して Type 2.5 に移行する移行段階です。

タイプ 4: 高級言語と同等

建築：

• 高級言語 (Solidity、Vyper など) で書かれたスマート コントラクト コードを受け入れます。
• ZK-SNARK に優しいように設計された言語にコンパイルされています。

＃＃＃ アドバンテージ

• 非常に速い校正時間。
• オーバーヘッド (コスト、時間、計算量) の削減。
• 証明者になるための障壁を低くし、分散化の程度を高めます。

欠点

• タイプ 4 システムでは、アドレスは正確なバイトコードに依存するため、コントラクトのアドレスは EVM 内のアドレスと異なる場合があります。
• これは、タイプ 4 ZK-EVM にバイトコードがない場合、アドレスを作成できないことを意味します。
• タイプ 4 は、上記の場合、反事実的な契約に依存するアプリケーションとは互換性がありません。
• 多くのデバッグ インフラストラクチャは EVM バイトコードで実行されるため、移植性がありません。

＃＃＃ 計画

• zkSync

最後に、上記のタイプを比較して、誰もがさまざまな zkEVM を一目で理解できるようにします。