Kakarot zkEVM の詳細解説：Starknet の EVM 互換の道

執筆：Cynic

出典：イーサリアム愛好者

TL;DR

• 仮想マシンは、プログラムに実行環境を提供するソフトウェアシミュレーションのコンピュータシステムです。さまざまなハードウェアデバイスをシミュレートし、プログラムを制御された互換性のある環境で実行できます。イーサリアム仮想マシン（EVM）は、イーサリアムスマートコントラクトを実行するためのスタックベースの仮想マシンです。
• zkEVMは、ゼロ知識証明/有効性証明技術を統合したEVMです。これにより、すべての検証者がEVMを再実行することなく、EVMの実行プロセスをゼロ知識証明で検証できます。市場にはさまざまなzkEVM製品があり、それぞれ独自のアプローチと設計があります。
• zkEVMが必要な理由は、Layer 2でスマートコントラクトの実行をサポートする仮想マシンへの需要にあります。また、一部のプロジェクトは、EVMの広範なユーザーエコシステムを活用し、ゼロ知識証明により親しみやすい命令セットを設計するためにzkEVMを選択しています。
• Kakarotは、Cairo言語を使用してStarknet上に実装されたzkEVMです。EVMのスタック、メモリ、実行などをCairoスマートコントラクトの形式でシミュレートしています。Kakarotは、Cairo言語がまだ実験段階にあるため、Starknetアカウントシステムとの互換性、コスト最適化、安定性などの課題に直面しています。
• Warpは、SolidityコードをCairoコードに変換するコンバータであり、高級言語レベルでの互換性を提供します。一方、KakarotはEVMのオペコードとプリコンパイルを実装することで、EVMレベルでの互換性を提供しています。

仮想マシンとは？

仮想マシンとは何かを明確にするためには、まず現代の主流であるフォン・ノイマンアーキテクチャにおけるコンピュータの実行プロセスについて説明する必要があります。コンピュータ上で実行されるさまざまなプログラムは、通常、高級言語から段階的に変換され、最終的に機械が理解できる機械コードに変換されて実行されます。機械コードへの変換方法によって、高級言語は大きくコンパイル型言語とインタプリタ型言語に分けられます。

コンパイル型言語は、コードの記述が完了した後、コンパイラの処理を経て高級言語コードを機械コードに変換し、実行可能ファイルを生成します。一度コンパイルすれば、何度も高効率で実行できます。コンパイル型言語の利点は、コンパイル時にコードが機械コードに変換されるため、実行速度が速く、コンパイラがない環境でもプログラムを実行でき、ユーザーにとって使いやすく、追加のソフトウェアをインストールする必要がないことです。一般的なコンパイル型言語にはC、C++、Goなどがあります。

コンパイル型言語に対して、インタプリタ型言語があります。インタプリタ型言語は、コードがインタプリタによって逐次解釈され、コンピュータ上で直接実行され、毎回実行時に再翻訳プロセスが必要です。インタプリタ型言語の利点は、開発効率が高く、コードのデバッグが容易ですが、実行速度は相対的に遅いです。一般的なインタプリタ型言語にはPython、JavaScript、Rubyなどがあります。

言語は本質的にコンパイル型とインタプリタ型を区別するものではなく、最初の設計時にいくつかの傾向があるだけです。C/C++はほとんどの場合コンパイル実行されますが、インタプリタ実行も可能です（Cint、Cling）。多くの伝統的なインタプリタ型言語は、現在は中間コードにコンパイルされ、仮想マシン上で実行されています（Python、Lua）。

物理マシンの実行プロセスを理解したところで、仮想マシンについて説明します。

仮想マシンは、通常、異なるハードウェアデバイスをシミュレートすることで仮想的なコンピュータ環境を提供します。異なる仮想マシンがシミュレートできるハードウェアデバイスは異なりますが、通常はCPU、メモリ、ハードディスク、ネットワークインターフェースなどが含まれます。

イーサリアム仮想マシンEVMを例にとると、EVMはスタックベースの仮想マシンであり、イーサリアムスマートコントラクトを実行するために使用されます。EVMは、CPU、メモリ、ストレージ、スタックなどのハードウェアデバイスをシミュレートすることで、仮想的なコンピュータ環境を提供します。

具体的には、EVMはスタックベースの仮想マシンであり、データを格納し命令を実行するためにスタックを使用します。EVMの命令セットには、算術操作、論理操作、ストレージ操作、ジャンプ操作などのさまざまなオペコードが含まれており、これらの命令はEVMのスタック上で実行され、スマートコントラクトの実行を完了します。

EVMがシミュレートするメモリとストレージは、スマートコントラクトの状態とデータを格納するためのデバイスです。EVMはメモリとストレージを2つの異なる領域と見なし、メモリとストレージを読み書きすることでスマートコントラクトの状態とデータにアクセスできます。

EVMがシミュレートするスタックは、命令のオペランドと結果を格納するために使用されます。EVMの命令セットのほとんどの命令はスタックベースであり、スタックからオペランドを読み取り、結果をスタックにプッシュします。

要するに、EVMはCPU、メモリ、ストレージ、スタックなどのハードウェアデバイスをシミュレートすることで仮想的なコンピュータ環境を提供し、スマートコントラクトの命令を実行し、スマートコントラクトの状態とデータを格納します。実際の実行では、EVMはスマートコントラクトのバイトコードをメモリにロードし、命令セットを実行してスマートコントラクトのロジックを実行します。EVMが実際に置き換えるのは、上図のオペレーティングシステム + ハードウェアの部分です。

EVMの設計プロセスは明らかにボトムアップであり、最初にシミュレートするハードウェア環境（スタック、メモリ）を決定し、それに基づいて独自のアセンブリ命令セット（Opcode）とバイトコード（Bytecode）を設計しました。アセンブリ命令セットは人間が見るためのものですが、底層の知識が多く関与しているため、開発者に対する要求が高く、開発が煩雑になるため、高級言語が必要です。EVMはそのアセンブリ命令セットのカスタマイズ設計により、従来の高級言語を直接利用することが難しく、新しい高級言語を再設計してこの仮想マシンに適合させました。イーサリアムコミュニティは、EVMの実行効率のために2つのコンパイル型高級言語、SolidityとVyperを設計しました。Solidityは言うまでもなく、VyperはVitalikがSolidityに存在するいくつかの欠陥を改善するために設計したEVM高級言語ですが、コミュニティではあまり高い採用度を得られず、次第に歴史の舞台から姿を消しました。

zkEVMとは何か

簡単に言えば、zkEVMはゼロ知識証明/有効性証明技術を利用したEVMであり、EVMの実行プロセスをゼロ知識証明/有効性証明によってより効率的かつ低コストで検証できるようにします。すべての検証者がEVMの実行プロセスを再実行する必要はありません。

市場には多くのzkEVM製品があり、競争が激しく、主要なプレイヤーにはStarknet、zkSync、Scroll、Taiko、Linea、Polygon zkEVM（旧Polygon Hermez）などがあり、Vitalikによって5つのタイプ（1、2、2.5、3、4）に分類されています。具体的な内容はVitalikのブログを参照してください。

なぜzkEVMが必要なのか

この問題は2つの側面から考える必要があります。

最初のzkRollupの試みは、比較的単純な送金や取引機能しか実現できませんでした。例えば、zkSync LiteやLoopringなどです。しかし、かつての海は水になりません。イーサリアム上のチューリング完全なEVMに慣れた人々は、プログラミングによって多様なアプリケーションを創造できないと、L2上の仮想マシンを求め始めました。スマートコントラクトを書く必要があるのです。

EVMの一部の設計がゼロ知識証明/有効性証明の生成に対して不親切であるため、一部のプレイヤーは、底層でゼロ知識証明/有効性証明に親しみやすい命令セットを使用することを選択しました。例えば、StarknetのCairo AssemblyやzkSyncのZinc Instructionです。しかし、皆がEVMの巨大なユーザーエコシステムを放棄したくないため、上層でEVMと互換性を持たせることを選択しました。これが3、4タイプのzkEVMです。また、一部のプレイヤーはEVMの伝統的な命令セットOpcodeを維持し、Opcodeのためにより効率的な証明を生成することに注力しています。これが1、2タイプのzkEVMです。EVMの巨大なエコシステムが理由です。

Kakarot：仮想マシン上の仮想マシン？

なぜ仮想マシン上にさらに仮想マシンを作ることができるのでしょうか？これはコンピュータ業界の人々にとっては当たり前のことですが、コンピュータを理解していないユーザーにとってはそうではないかもしれません。実際、これは非常に理解しやすいことで、積み木を積むようなものです。下層が十分に堅固であれば（チューリング完全な実行環境があれば）、無限に上層に積み木を重ねることができます。しかし、どれだけの層を積んでも、最終的な実行は最下層の物理ハードウェアに処理されるため、層が増えると効率が低下します。また、異なる積み木の設計が異なるため（仮想マシンの設計が異なる）、積み木が高くなるにつれて、積み木が崩れる可能性が高くなります（実行エラーが発生する可能性が高くなる）ため、より高い技術レベルが必要になります。

Kakarotは、Starknet上でCairo言語を使用して実装されたEVMであり、Cairoスマートコントラクトの形式でEVMのスタック、メモリ、実行などをシミュレートしています。相対的に言えば、EVMを実装することはそれほど難しいことではありません。最も使用されているGo-EthereumのGolangで書かれたEVMを除いて、現在はPython、Java、JavaScript、Rustで書かれたEVMも存在します。

Kakarot zkEVMの技術的な難点は、プロトコルがStarknetチェーン上のコントラクトとして存在するため、2つの重要な問題を引き起こすことです。

1. 互換性 Starknetはイーサリアムとは完全に異なるアカウントシステムを使用しており、イーサリアムではアカウントはEOA（外部所有アカウント）とCA（コントラクトアカウント）に分かれていますが、Starknetではネイティブのアカウント抽象をサポートしており、すべてのアカウントがコントラクトアカウントです。また、使用される暗号アルゴリズムが異なるため、ユーザーは同じエントロピーを使用してStarknetでイーサリアムと同じアドレスを生成することができません。
2. コスト Kakarot zkEVMはチェーン上のコントラクトとして存在するため、コード実装に高い要求があり、可能な限りGasに最適化し、インタラクションコストを削減する必要があります。
3. 安定性 Golang、Rust、Pythonなどの従来の高級言語とは異なり、Cairo言語はまだ実験段階にあり、Cairo 0からCairo 1、さらにCairo 2（またはお好みでCairo 1 version 2）へと進化しています。公式チームは言語の特性を継続的に修正しています。また、Cairo VMは十分なテストを受けておらず、今後大規模な書き換えが行われる可能性も排除できません。

Kakarotプロトコルは、5つの主要なコンポーネントで構成されています（GitHubドキュメントでは4つと記載されていますが、EOAが含まれていないため、本文では読者の理解を助けるために調整しました）：

• Kakarot (Core)：イーサリアム形式のトランザクションを実行し、イーサリアムユーザーに対応するStarknetアカウントを提供します。
• Contract Accounts：イーサリアムのCAに相当し、コントラクトのバイトコードやコントラクト内の変数の状態を格納します。
• Externally Owned Accounts：イーサリアムのEOAに相当し、イーサリアムのトランザクションをKakarot Coreに転送します。
• Account Registry：イーサリアムアカウントとStarknetアカウントの対応関係を格納します。
• Blockhash Registry：Blockhashは特殊なOpcodeであり、過去のブロックデータが必要ですが、Kakarotはチェーン上で直接データを取得できません。このコンポーネントはblock_number -> block_hashのマッピングを格納し、管理者が書き込み、Kakarot Coreに提供します。

KakarotのCEOであるElias Tazartesのフィードバックによれば、チームの最新バージョンでは、Account Resisterの設計を放棄し、31バイトのStarknetアドレスを20ビットのEVMアドレスにマッピングして対応関係を保存することに変更しました。将来的には、相互運用性を向上させ、Starknetコントラクトが独自のEVMアドレスを登録できるようにするために、Account Registerの設計を再利用する可能性があります。

Starknet上でのEVM互換性：WarpとKakarotの違い

Vitalikが定義したzkEVMのタイプに従えば、WarpはType-4に属し、Kakarotは現在Type-2.5に属します。

Warpは、SolidityコードをCairoコードに変換するトランスレーターであり、コンパイラーとは呼ばれないのは、出力されるCairoが依然として高級言語であるためです。Warpを使用することで、Solidity開発者は元の開発状態を維持し、新しいCairo言語を学ぶ必要がありません。多くのプロジェクトにとって、WarpはStarknetエコシステムへの参入障壁を下げ、大量のエンジニアリングコードをCairoで書き直す必要がなくなります。

トランスレーションの考え方はシンプルですが、互換性は最も低く、一部のSolidityコードはCairoにうまく翻訳できず、アカウントシステムや暗号アルゴリズムなどのコードロジックを変更する必要があります。具体的なサポートされていない機能についてはWarpドキュメントを参照してください。例えば、多くのプロジェクトはEOAアカウントとコントラクトアカウントの実行ロジックを区別しますが、Starknetではすべてのアカウントがコントラクトアカウントであるため、この部分のコードは修正後にトランスレーションを行う必要があります。

Warpは高級言語レベルでの互換性を提供し、KakarotはEVMレベルでの互換性を提供します。

EVMの完全な書き換え、Opcodeとプリコンパイルの逐条実装により、Kakarotはより高いネイティブ互換性を持っています。結局のところ、同じ仮想マシン（EVM）内で実行する方が、異なる仮想マシン（Cairo VM）内で実行するよりも常に互換性が高いです。Account RegistryやBlockhash Registryは、異なるシステム間の違いを巧妙に隠蔽し、ユーザーの移行摩擦を最小限に抑えています。

Kakarotチーム

Kakarotチームに対して、この記事に対する貴重な意見をいただき、特にElias Tazartesに感謝します。Thank you, sir!