執筆：cookies

翻訳：TechFlow

あなたは本当にZK-EVMを理解していますか？

本稿では、ZK-EVMの5つのタイプについて詳しく説明します。それぞれ独自のアーキテクチャ、長所と短所、および可能な解決策を持っています。

また、実際のプロジェクト例も紹介し、これらのタイプが実用上どのように機能するかをより深く理解できるようにしています。ブロックチェーン開発者であれ、ブロックチェーン技術に興味を持つ読者であれ、この記事は簡潔かつ深い洞察を提供します。

それでは、ZK-EVMの種類とその利点と欠点について考察してみましょう。

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

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

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

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

5. タイプ4：高級言語レベルで同等

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

アーキテクチャ：イーサリアムと完全に同一であり、イーサリアムシステムのどの部分も変更しない。

タイプ1｜利点

完璧な互換性：

・イーサリアムのブロックを検証可能

・イーサリアムL1のスケーラビリティ向上に貢献

・インフラを大量に再利用できるため、Rollupに適している

タイプ1｜欠点

完璧な互換性：

・イーサリアムは当初ZK機能向けに設計されていない

・ZK証明（ZKP）生成には多くのコンポーネントで膨大な計算が必要

・イーサリアムブロックの証明生成には数時間かかる

問題の解決策：

・証明者の大規模並列化

・ZK-SNARK専用ASIC

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

アーキテクチャ：

・データ構造（ブロック構造および状態ツリー）はイーサリアムとは大きく異なる

・既存アプリケーションとの完全な互換性

・EVMの開発を容易にし、証明生成を高速化するために、イーサリアムに対して微小な変更を加える

タイプ2｜利点

・タイプ1よりも高速な証明時間

・EVMから直接アクセスされないデータ構造

・イーサリアム上で動作するアプリケーションは、タイプ2でも動作する可能性が高い

・既存のEVMデバッグツールや他の開発インフラをサポート

タイプ2｜欠点

欠点を理解する前に、「Keccak」について知っておく必要があります：

・イーサリアムブロックチェーンのハッシュアルゴリズム

・イーサリアム上のデータ保護に使用

・情報をハッシュに変換することを保証

タイプ2は、過去の取引やレシート／状態に関するアプリケーションで使用されるMerkle証明による歴史的ブロックの検証と互換性がない。これは、ハッシュアルゴリズムが変更された場合（Keccakではなくなる）、証明が無効になるためです。

Keccakを一種の言語と考えてください。これはMerkle証明（文字）を使用します。もしZK-EVMがKeccakを別のハッシュアルゴリズム（例えばPoseidon）に置き換えると、Merkle証明は見知らぬものとなり、アプリケーションはそれらの主張を読み取り検証できなくなります。

欠点への潜在的な解決策：イーサリアムが将来拡張可能な履歴アクセス用プリコンパイルを追加できる。

タイプ2のプロジェクト

・Scroll

・Polygon Hermez

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

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

アーキテクチャ：

・ZK証明が困難な特定のEVM操作のGasコストを増加

・プリコンパイル

・Keccakオペコード

・コントラクト呼び出しパターン

・メモリアクセス

・ストレージ

タイプ2.5｜利点

・最悪の場合の証明時間を大幅に短縮

・EVMスタックに対するより深い変更よりも安全

タイプ2.5｜欠点

・開発ツールとの互換性低下

・一部のアプリケーションが動作しなくなる

タイプ3｜ほぼEVMと同等

アーキテクチャ：

・ZK-EVMの実装において、特に実現が難しい機能（通常はプリコンパイル）を削除

・コントラクトコード、メモリ、またはスタックの処理にわずかな差異がある

タイプ3｜利点

・検証時間を短縮

・EVMの開発を容易に

・あまり互換性の高くないアプリケーションに対しても最小限の書き直しで済むことを目指す

タイプ3｜欠点

・さらに互換性が低下

・タイプ3で削除されたプリコンパイルを使用するアプリケーションは再作成が必要

タイプ3｜プロジェクト

現在、ScrollおよびPolygonはタイプ3と見なされています。しかし、ZK-EVMチームはタイプ3に満足すべきではありません。タイプ3は、互換性を高めるためにプリコンパイルを追加し、タイプ2.5へ移行する過渡段階です。

タイプ4｜高級言語レベルで同等

アーキテクチャ：

・SolidityやVyperなどの高級言語で書かれたスマートコントラクトコードを受け入れる

・ZK-SNARKに適した言語にコンパイル

タイプ4｜利点

・非常に高速な証明時間

・オーバーヘッド（コスト、時間、計算量）の削減

・証明者となるハードルの低下：分散化の促進

タイプ4｜欠点

・タイプ4システムでは、アドレスは正確なバイトコードに依存するため、EVMでのアドレスと異なる可能性がある

・つまり、タイプ4のZK-EVMがバイトコードを持っていない場合、アドレスを作成できない

・上記の場合、タイプ4はファクトレス契約（反事実コントラクト）に依存するアプリと互換性がない

・多くのデバッグインフラはEVMバイトコード上で動作するため、移植できない

タイプ4｜プロジェクト

・zkSync

最後に、上記の各タイプを比較することで、異なるZK-EVMの違いを一目で理解できます。