Author: ChiHaoLu(chihaolu.eth)

Special thanks to Chih-Cheng Liang and Kimi Wu for reviewing this post.

Travel Preparations

本文會介紹 Kakarot 的重點部件與運作模式（e.g. 如何處理交易），來幫助大家理解這個項目的細節。在開始之前會希望讀者具備以下基本知識，可以更快掌握專有名詞和技術架構。

• What is EVM
• What is zkEVM（推薦閱讀：The different types of ZK-EVMs）
• What is L2 and what is ZK-Rollups
• What is StarkNet and what is Cairo VM

TL;DR

Kakarot 是一個 type 2.5 zkEVM，架設在 Cairo VM 上（沒錯，就是 VM 架在 VM 上）。Kakarot 以 Cairo 語言重新實作了 EVM 中的 opcodes 和 precompiles，讓 EVM 上能執行的程式碼在 Cairo VM 中也可以執行。

用最最最白話的方式來說，Kakarot 可以作為一個 Cairo Program（Cairo Contract）直接跑在（部署到）Starknet L2 上。

這樣開發者就能直接將 Solidity（或其他 EVM 相容語言）部署在 StarkNet 上。開發工具？我們可以跟 EVM 相容的鏈一樣用 Foundry、Hardhat、Wagmi。

而用戶也能透過過往習慣的 EVM 方式送出他們的交易，包含 RPC method、組 calldata、簽章都一樣。 錢包？我們可以跟 EVM 相容的鏈一樣用 Metamask、Wallet connect、imToken。

What is Kakarot?

由定義來看

Kakarot zkEVM 之於 Kakarot ZK-Rollups，就像 EVM 之於 Ethereum。前者是一個 VM 用來執行 opcodes，後者是一個區塊鏈網路用來記錄各種狀態。

首先，Kakarot 在定義上有兩種方式：

• Kakarot zkEVM：狹義來說 Kakarot 不是一條鏈，他只是一種虛擬機，用來執行 EVM 定義的 opcodes。
• Kakarot ZK-Rollups：廣義來說 Kakarot 被稱作 ZK-Rollups L2，Kakarot zkEVM 與 Starknet stack (CairoVM + StarknetOS runtime) 組合之後搭配 RPC Layer（RPC server 和 EVM indexer），才能稱作一條鏈。

以上提到的部件以及彼此之間如何合作就是下文會介紹的內容。

How Kakarot?

Kakarot zkEVM 的重點部件

在一個 Kakarot Protocol（Kakarot Core zkEVM）中，我們會有一個 Kakarot Core 專門用來執行 Ethereum-style 交易，同時提供相對應的 StarkNet accounts 給習慣 Ethereum 的用戶們（待會詳細解釋）。

在 Ethereum 會有一個 EOA 發起交易，在 Kakarot 也是，有一個 EOA 將這個 Ethereum-style 交易送給 Kakarot Core 要求執行 call（更詳細地說是 call 裡面的 data 和其他 field）並得到各種 state diff。

然而，當我們想把 EVM 能執行的程式遷移到 Cairo VM 上時，遇到最大的兩個問題就是「帳戶系統差異」以及「Blockhash 差異」。已知 StarkNet 上使用 Native AA，地址計算公式和 EVM 都不同，Blockhash 也不同，所以 Kakarot 作為兩者之間的橋樑，如何處理這個問題就格外重要。

而 Account Registry 和 Blockhash Registry 就作為處理這兩個 VM 系統之間差異的部件。

Account Registry 能夠儲存 EVM accounts（20 bytes）對應的 Starknet accounts（31 bytes）的 address mapping。Kakarot Core 執行時會給 Account Registry 一個 EVM address key 來得到 Starknet address value。

現今用戶還不能決定他們的 EVM 地址要對應到哪個 StarkNet 地址，官方有提到如果未來針對 Account Registry 進行改造，說不定用戶能自行決定要如何註冊（類似 ENS 的感覺）。

Blockhash Registry 則是負責儲存 block_number 對應 block_hash 的 mapping，在這兩個系統之中 Blockhash 都是一個重要的 opcode 用來取得過往的區塊資料，然而 Kakarot 沒辦法直接取得鏈上資料，所以需要一個 Blockhash Registry 來供其查詢。

為什麼 Kakarot 沒辦法直接取得鏈上資料？

就像 Ethereum 一樣 Kakarot 也有他自己的區塊和 block_hash，但 Kakarot 本質上並不是一條鏈（前面說過的），他是以合約形式在 StarkNet（或之類的 CairoVM）上執行。所以他不知道執行到 block_hash 這個 opcodes 時該怎麼反應，必須透過 Blockhash Registry 得到答案。

這個將 block_hash 寫入 Blockhash Registry 的行為由 Kakarot 的 administrator 完成，聽起來蠻中心化的，但因為 Kakarot 是一個還很初期的 project，未來的設計會有很多改變，詳細的 roadmap 可見：Kakarot’s Roadmap: From Enshrined EVM on L2 and L3s to Proving L1

Kakarot ZK-Rollups 的重點部件與交易生命週期

Kakarot ZK-Rollups 主要分為三個部分：

• 上一個章節介紹的 Kakarot zkEVM
• RPC layer (RPC server and EVM indexer)
• Underlying host CairoVM client (e.g. Starknet mainnet)

當用戶（EOA）想要發送一筆交易時，他會將這個 EVM-style 交易送到 Kakarot 的 ETH RPC（就跟我們在 EVM 相容的鏈 開發一樣，把交易送給 provider RPC），交易自始進入 RPC Layer。

「從頭到尾」用戶都不會看見 StarkNet，對用戶來講什麼 Cairo VM、Cairo Contract、StarkNet、StarkNet 上的 Native AA account 都是看不見的！

Kakarot 的用戶只會與 Kakarot RPC 互動，用的是 Ethereum JSON-RPC specification，看的是 EVM address，寫的是 EVM 合約，所以使用起來會與其他 EVM 相容的鏈無異。

Kakarot RPC 接收到交易之後：

• 如果是 read 行為：Kakarot RPC 去撈取 Kakarot Indexer（EVM Indexer DB）的資料然後回傳。
• 如果是 write 行為：那就會將其送往 StarkNet RPC，與 CairoVM Chain 互動（通常是 StarkNet 這條鏈）。

為了易讀性，後面的 CairoVM Chain（Client）我都以 StarkNet 代稱。

Kakarot Core zkEVM 作為一個 Cairo Program（Cairo Contract）架設（部署）在 StarkNet 上，交易執行的過程中因為用戶的交易使用的是 EVM address，所以 StarkNet 需要利用前一個章節提到的 Account Registry 得到這個 EVM address 在 StarkNet 中的帳戶狀態。

再次提醒，這一切在 StarkNet 上發生的事情 Kakarot 的用戶都不會知道，從他們的角度只會看見 EVM 形式的訊息。

這一筆交易中使用到的 EVM address（無論是 EOA 還是 CA）都會在 StarkNet 中被部署成一個 Starknet smart contract，這個合約主要作為該 EVM address 在 Kakarot Network 上的帳戶狀態並紀錄在 StarkNet 中（畢竟是在 StarkNet 合約嘛）。紀錄的資訊包含 ETH balance，如果有用到 ERC20 Token contract，那 EVM address 的 balance 地址也是這個 StarkNet 地址。

這裡有一個小細節：Kakarot 用戶會使用一個 EOA 對 EVM 格式的交易進行簽章，這個簽章簽的是 EVM 形式的 transaction hash。RPC Layer 會將這個 EVM 格式的交易以一定方式進行 wrap，轉為 StarkNet transaction 格式。

這個 EVM transaction hash 因為 wrap 的方式相同，會 1–1 對應出一個 StarkNet transaction hash，如此一來這個交易簽章與其 EVM transaction hash 才能在 StarkNet 與其帳戶合約中被妥善驗證。

交易會被執行完後會得到 state diff 和 Cairo execution traces（在這裡其實就指 blocks）。這些資訊會被 load 到 Kakarot Indexer 供未來查詢使用。而 state diff 和 trace 也會送往 Cairo Prover 產生證明最後送到 Ethereum L1 驗證並紀錄。這部分和 StarkNet 架構更有關係，相關內容可以看這篇文章：StarkNet 介紹：重點部件 Overview。

Why Kakarot?

理解了上述內容後，可以從以下三個角度去切入為什麼我們需要 Kakarot。

1. 降低 CairoVM 的門檻

我們都知道在 StarkNet 上開發合約需要撰寫 Cairo，而 Cairo 不僅語法複雜，其迭代速度也難以讓人跟進，所以想在 StarkNet 上（或任何 Cairo VM Chain）部署應用的人，或說想要利用 StarkNet 這條鏈優勢（low gas、fast execution、cryptographic security）的人，就可以用 Kakarot 作為一個切入點。

2. 擴展 StarkNet

Kakarot 促使 StarkNet 成為一個 DualVM 環境，能夠讓用戶在上面同時使用 EVM 或 CairoVM 來發送交易或撰寫合約。

3. Front Run

Kakarot 希望能將所有未來想要嘗試的以太坊升級（new EIP、new EVM features）實作在 Kakarot zkEVM 中（成為另外一個新的 program），並將其部署然後進行測試。這樣的好處是，Kakarot 團隊認為過往有太多 EIP 浪費太多時間與資源，如果能夠在一條鏈上先進行測試，那就能先實驗他的成果如何。

舉例來說 Discussion: Removal of RIPEMD-160 and blake2f Precompiles 這個提案就提到，這兩個 precompile 自始至終只被呼叫過 1000 多次，而所有的 Rollup 都在當初勢必要跟著 Ethereum 實作那些 hardfork 出現的 opcodes/precompiles/new features（e.g. 新的 gas 定價模型、新的儲存模型例如 Verkle、新的帳戶或交易模型），但現在卻發現成效不彰，可見是會浪費多少成本。

另外一個例子是 EIP-1153: Transient storage opcodes 從誕生到 merged 耗了 5.5 年，是耗費時間最長的 EIP。而 EIP-3074: AUTH and AUTHCALL opcodes 則是在浩浩蕩蕩的 4 年討論之後重生又處決。

所以發現成效不好不僅是浪費 Ethereum 很多開發資源，同時要求 Rollup 跟進 Ethereum new features 也是，這是 Kakarot 提出先實驗再 merged 很重要的原因。

已知 Kakarot zkEVM 已經完全復刻 EVM，且 Kakarot 本質上並不是一條鏈，而是作為一個 Cairo Program 運作在 Cairo VM Chains 上，他的特性就是「超級小包的 EVM」，所以能夠非常敏捷的開發與迭代，不像其他 Rollup 在更改 protocol 的實驗上需要耗費很多成本。

Conclusion

Kakarot 可以稱作是 Starknet 生態系的一部分，如果把 Kakarot zkEVM 架設（部署）在 StarkNet 上，那 Kakarot 上執行的每一筆交易都會記錄到 StarkNet 上。

所以 Kakarot 是 Starknet 的 L3 嗎？如果 L3 的定義是 L3 之於 L2 如同 L2 之於 L1，會把必要的 data 上傳來確保安全性，那 Kakarot 在某種程度上是可以稱作 StarkNet L3 的。因為 Kakarot 並不是真的一條鏈，他的交易實際上是依賴在 StarkNet 中驗證和執行確保。

Kakarot 介紹：重點部件 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.