5種類のZK-EVMのアーキテクチャ、メリット・デメリット、解決策を詳しく解説
原作者：cookies
原文編集：Deep Tide TechFlow
原作者：
原文編集：Deep Tide TechFlow
この記事では、5 つのタイプの ZK-EVM について詳しく説明し、それぞれに独自のアーキテクチャ、長所と短所、考えられる解決策があります。
さらに、この記事では、読者が実際のアプリケーションにおけるこれらのタイプのパフォーマンスをよりよく理解できるように、いくつかの実践的なプロジェクトの例もリストします。あなたがブロックチェーン開発者であっても、ブロックチェーン技術に興味のある読者であっても、この記事は詳細かつ簡潔な洞察を提供します。
ZK-EVM の種類とその長所と短所を見てみましょう。
1. タイプ 1: イーサリアムと完全に同等。
2. タイプ 2: EVM と完全に同等。
3. タイプ 2.5: EVM と部分的に同等。
4. タイプ 3: EVM とほぼ同等。
5. タイプ 4: 高級言語が同等です。
タイプ 1: イーサリアムと完全に同等
アーキテクチャ: イーサリアムとまったく同じであり、イーサリアム システムのどの部分も変更されません。
アドバンテージ
完璧な互換性:
イーサリアムブロックを検証する機能。
Ethereum L1 のスケーラビリティを高めるのに役立ちます。
多くのインフラストラクチャを再利用するため、ロールアップに適しています。
欠点がある
完璧な互換性:
イーサリアムはもともと ZK 機能用に設計されたものではありません。
イーサリアムの多くのコンポーネントは、ZK Proof (ZKP) を生成するために大量の計算を必要とします。
イーサリアムブロックのプルーフの生成には何時間もかかります。
ZK-SNARK ASIC.
問題の解決策:
大規模並列化された証明者。
タイプ 2: EVM と完全に同等
建築：
データ構造 (ブロック構造と状態ツリー) はイーサリアムとは大きく異なります。
既存のアプリケーションと完全な互換性があります。
開発を容易にし、プルーフの生成を高速化するために、イーサリアムに若干の変更が加えられました。
アドバンテージ
タイプ 1 よりも校正時間が短縮されます。
EVM はデータ構造に直接アクセスしません。
Ethereum で実行されるアプリケーション: ほとんどの場合、タイプ 2 で実行できます。
既存の EVM デバッグ ツールおよびその他の開発インフラストラクチャのサポート。
欠点がある
デメリットを理解する前に、まず「ケチャック」とは何かを理解してください。
イーサリアムブロックチェーンのハッシュアルゴリズム。
イーサリアム上のデータを保護するために使用されます。
情報がハッシュに変換されていることを確認してください。
Keccak は、マークル証明 (アルファベット) を使用する言語と考えることができます。ZK-EVM が Keccak を別のハッシュ アルゴリズム (Poseidon など) に置き換えると、マークル証明は馴染みのないものになり、アプリケーションはマークル証明を読み取ってその主張を検証できなくなります。
プロジェクト
Scroll;
Polygon Hermez.
欠点に対する潜在的な解決策: イーサリアムは、将来的にはスケーラブルな履歴アクセスのプリコンパイルを追加する可能性があります。
プロジェクト
ただし、これらのプロジェクトは、より高度なプリコンパイルをまだ実装していないため、不完全なタイプ 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 は、反事実的な契約に依存するアプリケーションとは互換性がありません。
プロジェクト
zkSync
多くのデバッグ インフラストラクチャは EVM バイトコードで実行されるため、移植性がありません。
