Author: cookies

Compiled by: TechFlow

Kakarot zkEVM is an EVM implemented in Cairo that enhances EVM compatibility and expands the Starknet ecosystem. What has earned it support from Vitalik and StarkWare? In this article, analyst cookies explores Kakarot's various stages, its strengths and weaknesses, and the challenges and opportunities facing the project.

What is CairoVM?

Kakarot is built on top of the virtual machine (VM) CairoVM, which serves as the foundational infrastructure for Starknet.

Key features of CairoVM:

· Represents execution as polynomials (equations) to enable provable execution;

· Enables STARK proofs for all Starknet transactions.

What is Cairo?

A Turing-complete, STARK-friendly CPU architecture:

· Turing-complete: The system can compute any computable function or program;

· STARK-friendly: A proof system provided by StarkWare. Off-chain computational integrity is proven by a prover and verified on-chain by a verifier.

How Cairo Works

Developers can write programs in Cairo within CairoVM, using high-level languages to describe statements they want to prove. This improves developer experience by enabling them to leverage the scalability of zero-knowledge proofs (ZKP) without needing to learn how to design complex circuits.

Kakarot Architecture

Kakarot is built on CairoVM and is:

· An EVM bytecode interpreter;

· A smart contract (SC) deployed on Starknet;

· Written in Cairo.

Kakarot enables:

· Deployment of existing EVM SCs.

Kakarot is not:

· A blockchain;

· A compiler: It does not convert Solidity code into Cairo.

As of May 2023:

· 100% bytecode equivalence (Type 3 zkEVM);

· 8 out of 9 EVM precompiles implemented.

Once all 9 EVM precompiles are implemented, Kakarot will become a Type 2.5 zkEVM.

Type 1 zkEVM is fully equivalent to Ethereum, making no changes to the Ethereum system to facilitate easier proof generation.

Advantages: The ultimate scaling solution for Ethereum.

Disadvantages: Computationally intensive, with long proof times (taking hours).

Examples: Scroll, Taiko.

Type 2 zkEVM is fully equivalent to the EVM, with minor modifications to the Ethereum system (e.g., different hash functions) to:

· Simplify development;

· Accelerate proof generation.

Advantages: Most Ethereum dApps remain compatible.

Disadvantages: Inherits EVM inefficiencies and remains ZK-unfriendly.

Example: Scroll.

Type 2.5 zkEVM is equivalent to the EVM except for gas costs. It increases gas costs for specific EVM operations that are difficult to prove with ZK.

Advantages: Lower risk compared to broader EVM implementations.

Disadvantages: Reduced tooling compatibility; some dApps may become incompatible.

Type 3 zkEVM is nearly equivalent to the EVM but removes particularly hard-to-implement features (e.g., certain precompiles).

Advantages: Even faster proof times and easier EVM development.

Disadvantages: Some dApps require rewriting.

Examples:

· Scroll;

· Polygon.

Type 4 zkEVM is high-level language equivalent, compiling smart contract source code (high-level languages) into ZK-SNARK-friendly languages.

Advantages: Avoids significant overhead.

Disadvantages: Contracts may have different addresses than on EVM, may not support hand-written EVM bytecode, and existing infrastructure cannot be reused since it runs on EVM bytecode.

Examples:

· zkSync;

· Nethermind.

Kakarot Roadmap | Phase 1 | Bringing EVM to Starknet

Initially, Kakarot will exist within Starknet as an enshrined EVM. Developer and user experience (UX) will be identical to Polygon, Scroll, or Ethereum.

Phase 2 | L3 zkEVMs

Deploying zkEVM app-chains via Kakarot allows them to leverage validity proofs to settle transactions on Starknet. Achieved by combining Kakarot and Madara on Starknet into a unified stack.

With just one click, rollups gain:

· Application-specific zkEVMs deployed on Starknet;

· Access to the EVM environment;

· Fast execution;

· Low gas: Using data availability (DA) solutions;

· Security.

By running Solidity smart contracts in CairoVM via Kakarot: Any Solidity smart contract deployed on EVM will be able to run on Starknet without code changes.

Able to combine the best of both worlds:

· Efficiency of the EVM;

· Smart contracts become provable.

Phase 3 | Type 1 zkEVM

To achieve this, Kakarot must:

· Use Cairo to implement Ethereum consensus rules inside a full node (Madara x Kakarot) to prove L1 consensus;

· Transition from Pedersen Merkle Patricia Trie (MPT) to Keccak MPT.

This depends on Ethereum’s roadmap: Verge. Currently, implementing Keccak MPT in a provable and cost-effective way is the main compatibility bottleneck for zkEVMs. After Verge, Keccak may be replaced by Poseidon as Ethereum’s preferred hash function.

My Thoughts

This is undoubtedly a major step toward bringing EVM compatibility to Starknet, but there are still concerns surrounding Kakarot's success.

Competition from the following projects

· ZK-rollups with different proof systems (SNARK): Scroll, zkSync, Polygon, Taiko, Linea;

· Optimistic rollups: Optimism, Arbitrum, Base;

· Alternative zkVMs: RISC Zero, Hyper Oracle.

Product-Market Fit (PMF)

Overall, Rollup-as-a-Service is an unproven thesis, requiring consideration of two key factors:

· How many rollups will actually need this service?

· Will rollups prefer building in-house for sovereignty and customizability?

Continuous Product Iteration

Kakarot is building a highly technically complex product that may require continuous iteration to succeed. It also relies on multiple components, including:

· Madara;

· DA solutions;

· Ethereum’s roadmap: The Verge.