Kakarot’s Roadmap: From Enshrined EVM on L2 and L3s to Proving L1
--
A primer on Kakarot
Kakarot zkEVM is an implementation of the Ethereum Virtual Machine (EVM) written in Cairo. Cairo is a Turing-complete language associated with the CairoVM. The CairoVM enables provable compute by leveraging polynomials and the ZK-STARK proof system. A zkEVM is characterised by its ability to generate provable transactions, and thus provable blocks. Kakarot being built on top of the CairoVM, every transaction executed on Kakarot is provable.
Kakarot zkEVM enables teams to build & deploy EVM apps. Developers can deploy any Solidity (or any EVM compatible language) on Kakarot, as they would on Ethereum or Polygon. Their end-users are then able to interact with dApps with their usual toolchain (Metamask, Wallet connect, etc.).
Ultimately, Kakarot will provide interoperability with native Starknet protocols and composability between protocols, for instance, combining TVL in DeFi and user base in GameFi.
Fractal Scaling
Kakarot zkEVM can exist in different forms. Firstly, it can be deployed as a smart-contract on top of Starknet L2 and thus expose an EVM (Ethereum RPC, Ethereum transactions, etc.) on Starknet.
Alternatively, Kakarot can be integrated into a stack to deploy L3 zkEVMs. This is where the Madara sequencer comes in.
By combining Madara (a Starknet full node) and Kakarot (an EVM runtime), one is able to create a L3 zkEVM. The stack is the following: a substrate full node, that uses the CairoVM as its execution engine, and Kakarot as a runtime for smart contracts. Transactions on Kakarot can be proven and verified on a settlement layer, resulting in EVM compatible fractal scaling.
Roadmap
Phase 1: Kakarot zkEVM on Starknet — Bring the EVM to Starknet
Kakarot will start by existing as an enshrined EVM inside Starknet L2. This will enable developers to deploy their Solidity (or any EVM-compatible language) smart contracts directly on Starknet, with the toolbox they’re familiar with (Foundry, Hardhat, Wagmi, etc.).
Their end-users would then able to interact with their dApps using their usual toolchain (Metamask, Wallet connect, etc.).
TL;DR: the developer and user experiences on Kakarot will be exactly the same as Polygon’s, Scroll’s or Ethereum L1.
Phase 2: Kakarot x Madara — L3 zkEVMs
Kakarot and Madara will be combined into a unified stack to enable L3 zkEVMs — and L4, L5, etc. when it makes sense. Teams will be able to deploy their zkEVM app-chains, and leverage validity proofs to settle transactions on Starknet.
I’ve asked myself many times: Why L3s? Why provability?
Provability enables the following: compute off-chain, or up a layer, verify on-chain.
L3s that leverage validity proofs (like Kakarot) have an interesting and underrated property: the ability to decouple security and decentralisation. Users are able to benefit from the security of Ethereum L1 without requiring the same level of decentralisation, i.e. thousands of validators.
Note that decentralisation for rollups is desirable. It brings liveness and censorship resistance, two very important (underrated?) properties. This can be achieved with a sequencer set in the hundreds rather than in the thousands.
As a result of computing on another layer, gas costs are exponentially lower than on L2, and performance (TPS) is higher. Note that L2 is already exponentially cheaper than L1. The scalability of rollups stacks and multiplies.
To further reduce gas costs, proof verification and data availability (DA) can be separated. Starknet L2 can serve solely as a proof verification layer, while new data availability solutions, such as Celestia or EigenDA, can be utilized for posting transaction data.
Users will have the choice to opt-in to either option, depending on their security requirements. Posting both proofs and transaction data on Starknet is the more secure option, while using DA solutions for posting transaction data is the more cost-effective alternative.
Phase 3: Kakarot x Madara — type 1 zkEVM
Kakarot and Madara can also be combined to enable type 1 zkEVMs. If one is able to:
1. Write the Ethereum consensus rules in Cairo inside the Madara x Kakarot full node, thus enable the proving of L1 consensus.
2. Switch from Pedersen Merkle Patricia Trie (MPT) to Keccak MPT.
Then, Kakarot would become a type 1 zkEVM client, able to prove L1 blocks. This is a more advanced use-case that depends on Ethereum’s roadmap, most notably the Verge. After the Verge, keccak might be replaced by poseidon as the hash function of choice for Ethereum. This would help zkEVM teams in becoming type 1 as the main compatibility blocker for zkEVMs is the storage layout, i.e. implementing Keccak MPT in a provable and reasonably cheap way.
Additional research topics
- Madara enables Kakarot chains to leverage the substrate messaging protocol for cross-rollups communication.
- Substrate’s modularity enables Kakarot chains to innovate with their consensus protocol.
- Substrate’s forkless runtime upgrades enable Kakarot chains to upgrade the version of their EVM without hard forks.
Thanks for reading y’all! We’re preparing super cool news soon, so stay alert 🤫🔥!
- We’re participating to 0xtitans competition on June 4th! Watch out for MatchboxDAO games in the near future,
- We’re getting ready to launch our testnet!
- And more exciting news!
