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 を一目で理解できるようにします。

免責事項：このページの情報は第三者から提供される場合があり、Gateの見解または意見を代表するものではありません。このページに表示される内容は参考情報のみであり、いかなる金融、投資、または法律上の助言を構成するものではありません。Gateは情報の正確性または完全性を保証せず、当該情報の利用に起因するいかなる損失についても責任を負いません。仮想資産への投資は高いリスクを伴い、大きな価格変動の影響を受けます。投資元本の全額を失う可能性があります。関連するリスクを十分に理解したうえで、ご自身の財務状況およびリスク許容度に基づき慎重に判断してください。詳細は免責事項をご参照ください。

0/400

コメントなし