Vitalikが投資参加、KakarotはいかにしてEVMをStarknetに導入するのか？
TechFlow厳選深潮セレクト
Vitalikが投資参加、KakarotはいかにしてEVMをStarknetに導入するのか？
本稿では、アナリストのcookiesがKakarotの各段階とその長所・短所、ならびにプロジェクトが直面する課題や機会について考察します。
Web3業界の深掘り報道に専念し潮流を洞察執筆：cookies
翻訳：TechFlow
Kakarot zkEVM は、Cairo で実装された EVM であり、EVM の互換性を強化することで Starknet エコシステムを拡張するものです。Vitalik と StarkWare の支持を得たその理由とは？アナリスト cookies が本稿で、Kakarot の各段階や長所・短所、そしてプロジェクトが直面する課題と機会について考察します。
CairoVM とは何か？
Kakarot は、Starknet の基盤インフラである仮想マシン（VM）CairoVM 上に構築されています。
CairoVM の主な特徴：
・実行を多項式（方程式）として表現し、検証可能な実行を実現する；
・すべての Starknet トランザクションに対して STARK 証明を可能にする。
Cairo とは何か？
チューリング完全な STARK フレンドリーな CPU アーキテクチャ：
・チューリング完全：任意の計算／プログラムを実行できるシステム；
・STARK フレンドリー：StarkWare が提供する証明システム。オフチェーンでの計算の完全性を証明者が証明し、オンチェーンの検証者が検証する。
Cairo の仕組み
開発者は CairoVM 内で Cairo を使用してプログラムを記述でき、証明すべき内容（ステートメント）を高水準言語で記述できます。これにより、ゼロ知識証明（ZKP）のスケーラビリティを活用しながらも、複雑な回路設計を学ぶ必要がないため、開発者体験が向上します。
Kakarot のアーキテクチャ
Kakarot は CairoVM 上に構築されており、以下の特性を持つ：
・EVM バイトコードインタプリタ；
・Starknet 上にデプロイされるスマートコントラクト（SC）；
・Cairo で記述されている。
Kakarot が可能にすること：
・既存の EVM スマートコントラクトのデプロイ。
Kakarot ではないもの：
・ブロックチェーン；
・コンパイラ：Solidity コードを Cairo に変換しない。
2023年5月時点：
・バイトコードアーキテクチャの100％実装（Type 3 zkEVM）；
・9つのEVMプリコンパイルのうち8つを実装済み。
残り1つのEVMプリコンパイルを実装後、Kakarot は Type 2.5 zkEVM となる。
Type 1 zkEVM はイーサリアムと完全に等価であり、証明生成を容易にするためにイーサリアムシステムを変更しない。
利点：イーサリアム拡張の究極的ソリューション。
欠点：計算負荷が高く、証明に長時間を要する（数時間かかる場合がある）。
例：Scroll、Taiko。
Type 2 zkEVM は EVM と完全に等価だが、異なるハッシュ関数など軽微な変更を加えることで：
・より簡単な開発；
・より高速な証明生成を実現。
利点：ほとんどのイーサリアム dApp が利用可能。
欠点：EVM 固有の効率問題および ZK 非対応。
例：Scroll。
Type 2.5 zkEVM は Gas コストを除き EVM と同等。ZK 証明が困難な特定操作の Gas コストを増加させる。
利点：広範な EVM よりリスクが少ない。
欠点：開発ツールとの互換性低下、一部の dApp が非互換になる可能性。
Type 3 zkEVM はほぼ EVM と同等だが、特に実装が難しい機能（例：プリコンパイル）を除外している。
利点：さらに短い証明時間、より容易な EVM 開発。
欠点：一部の dApp は再記述が必要。
例：
・Scroll；
・Polygon。
Type 4 zkEVM は高水準言語レベルで同等。スマートコントラクトのソースコード（高水準言語）を ZK-SNARK フレンドリーな言語にコンパイルする。
利点：大きなオーバーヘッドを回避できる。
欠点：コントラクトがEVMと同じアドレスを持たない可能性、手書きのEVMバイトコードがサポートされない可能性、インフラがEVMバイトコード上で動作するため移行不可。
例：
・zksync；
・Nethermind。
Kakarot ロードマップ | 第1段階 | EVM を Starknet に導入
Kakarot は当初、Starknet 内の「公式採用EVM（Enshrined EVM）」として存在する。開発者およびユーザー体験（UX）は、Polygon、Scroll、またはイーサリアムとまったく同じになる。
第2段階 | L3 zkEVMs
Kakarot を通じて zkEVM アプリケーションチェーンをデプロイし、それらが有効性証明を利用して Starknet 上でトランザクションを解決できるようにする。Kakarot と MadaraStarknet を統合したスタックによって実現。
・Starknet 上にデプロイされたアプリケーション固有の zkEVM；
・EVM 環境へのアクセス；
・高速な実行；
・低Gas：データ可用性（DA）ソリューションを使用；
・セキュリティ。
CairoVM 内で Kakarot を使って Solidity SC を実行することにより、EVM 上でデプロイされた任意の Solidity スマートコントラクトが、コード変更なしに Starknet 上で動作可能になる。
両者の利点を兼ね備えることが可能：
・EVM の効率性；
・スマートコントラクトが証明可能になる。
第3段階 | Type 1 zkEVM
これを実現するために、Kakarot は以下を行う必要がある：
・Madara x Kakarot フルノード内で Cairo を使ってイーサリアムのコンセンサスルールを記述し、L1 コンセンサスを証明する；
・Pedersen Merkle Patricia Trie（MPT）から Keccak MPT への切り替え。
これはイーサリアムのロードマップ「The Verge」に依存する。現在、Keccak MPT を証明可能かつ安価に実装することは、zkEVM の主要な互換性障壁となっている。The Verge 完了後、Keccak に代わり、Poseidon がイーサリアムの推奨ハッシュ関数となる可能性がある。
筆者の見解
これは確かに Starknet に EVM 互換性をもたらす大きな一歩だが、Kakarot の成功にはいくつかの懸念も残っている。
競合他社との競争
・異なる証明システム（SNARK）を採用するZK-rollup：Scroll、zksync、Polygon、Taiko、Linea；
・Optimistic-rollup：Optimism、Arbitrum、Base；
・異なる zkVM：RISC Zero、Hyper Oracle。
製品市場適合性（PMF）
全体として、「Rollup as a Service」はまだ検証されていない仮説であり、以下の2つの重要な側面を考慮する必要がある：
・どれだけの Rollup がこのサービスを必要とするか？
・Rollup は主権とカスタマイズ性のために、自社内での構築を好むのではないか？
継続的な製品の反復
Kakarot は非常に技術的に複雑な製品を構築しており、成功するには継続的な反復が必要かもしれない。また、以下の複数の要素にも依存している：
・Madara；
・DA ソリューション；
・イーサリアムのロードマップ：The Verge。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
cookies
