This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
カカロット: Starknet の EVM 互換道路の探索
著者: シニック
TL;DR
※仮想マシンとは、プログラムの実行環境をソフトウェアで模擬したコンピュータシステムです。さまざまなハードウェア デバイスをエミュレートできるため、制御された互換性のある環境でプログラムを実行できます。イーサリアム仮想マシン (EVM) は、イーサリアム スマート コントラクトを実行するために使用されるスタックベースの仮想マシンです。 ※zkEVMは、ゼロ知識証明・妥当性証明技術を統合したEVMです。これにより、すべての検証者が EVM を再実行する必要がなく、ゼロ知識証明を使用して EVM の実行を検証できます。市場にはさまざまな zkEVM 製品があり、それぞれに独自のアプローチと設計が施されています。
仮想マシンとは何ですか?
仮想マシンとは何かを明確にするには、まず、現在の主流のノイマン アーキテクチャ下でのコンピュータの実行プロセスについて説明する必要があります。コンピューター上で実行されるさまざまなプログラムは、通常、高級言語の層によって変換され、最終的には機械が理解できる実行用の機械コードを生成します。高級言語は機械語への変換の仕方により、コンパイル言語とインタプリタ言語に大別されます。
コンパイル済み言語とは、コードを作成した後、コンパイラーで処理して高級言語コードをマシンコードに変換し、実行可能ファイルを生成する必要があることを意味します。一度コンパイルすると、効率よく複数回実行できます。コンパイル言語の利点は、コンパイル中にコードが機械語に変換されるため、実行速度が速く、コンパイラなしの環境でもプログラムを実行できるため、ユーザーにとって使いやすく、コンパイラの必要がないことです。追加のソフトウェアをインストールします。一般的なコンパイル言語には、C、C++、Go などが含まれます。
コンパイル言語に相当するのはインタプリタ言語です。インタープリタ型言語とは、コードがインタプリタを通じて 1 行ずつ解釈および実行され、コンピュータ上で直接実行され、実行するたびに翻訳プロセスを再翻訳する必要があることを意味します。インタプリタ型言語の利点は、開発効率が高く、コードのデバッグが容易であることですが、実行速度は比較的遅いです。一般的なインタープリター言語には、Python、Java、Ruby などが含まれます。
物理マシンの実行プロセスがわかったので、今度は仮想マシンについて話しましょう。
仮想マシンは通常、さまざまなハードウェア デバイスをシミュレートすることによって仮想コンピュータ環境を提供します。仮想マシンごとにシミュレートできるハードウェア デバイスは異なりますが、一般的には CPU、メモリ、ハードディスク、ネットワーク インターフェイスなどが含まれます。
イーサリアム仮想マシン (EVM) を例に挙げると、EVM はイーサリアム スマート コントラクトを実行するために使用されるスタックベースの仮想マシンです。 EVM は、CPU、メモリ、ストレージ、スタックなどのハードウェア デバイスをシミュレートすることにより、仮想コンピュータ環境を提供します。
具体的には、EVM はスタックを使用してデータを保存し、命令を実行するスタックベースの仮想マシンです。 EVM の命令セットには、算術演算、論理演算、ストレージ演算、ジャンプ演算などのさまざまなオペコードが含まれています。これらの命令は EVM のスタック上で実行され、スマート コントラクトの実行を完了できます。
EVM によってエミュレートされるメモリとストレージは、スマート コントラクトの状態とデータを保存するために使用されるデバイスです。 EVM はメモリとストレージを 2 つの異なる領域として扱い、メモリとストレージの読み書きによってスマート コントラクトの状態とデータにアクセスできます。
EVM によってエミュレートされたスタックは、命令のオペランドと結果を格納するために使用されます。 EVM の命令セット内のほとんどの命令はスタックベースであり、スタックからオペランドを読み取り、結果をスタックにプッシュします。
つまり、EVMは、スマートコントラクトの命令を実行し、スマートコントラクトの状態とデータを保存できるCPU、メモリ、ストレージ、スタックなどのハードウェアデバイスをシミュレートすることにより、仮想コンピュータ環境を提供します。実際の動作では、EVM はスマート コントラクトのバイトコードをメモリにロードし、命令セットを実行することでスマート コントラクトのロジックを実行します。 EVM が実際に置き換えるのは、上図のオペレーティング システム + ハードウェアの部分です。
EVM の設計プロセスは明らかにボトムアップであり、最初にシミュレートされたハードウェア環境 (スタック、メモリ) が完成し、次に一連のアセンブリ命令セット (Opcode) とバイトコード (Bytecode) が対応する環境に従って設計されます。アセンブリ命令セットは人間が読むためのものですが、多くの低レベルの知識が必要であり、開発者にとっては高い要件があり、開発が面倒です。そのため、あいまいで扱いにくい低レベルの言語を保護するために高レベル言語が必要です。呼び出しを行い、開発者により良いエクスペリエンスを提供します。 EVM のアセンブリ命令セットはカスタマイズされた設計のため、従来の高級言語を直接使用することは難しく、仮想マシンに適応するために新しい高級言語を再作成するだけです。 Ethereum コミュニティは、EVM の実行効率を高めるために、2 つのコンパイルされた高水準言語 (Solidity と Vyper) を設計しました。 Solidity を強調する必要はありませんが、Vyper は、Solidity のいくつかの欠点を改善して Vitalik によって設計された EVM 高級言語ですが、コミュニティで広く採用されていないため、徐々に歴史の舞台から消えていきます。
zkEVMとは何ですか
zkEVMとは、簡単に説明すると、ゼロ知識証明・妥当性証明技術を用いたEVMであり、すべての検証者に実装を依頼することなく、ゼロ知識証明・妥当性証明によってEVMの実行プロセスをより効率的かつ低コストで検証することができます。 EVM の実行プロセスを終了します。
市場には多くの zkEVM 製品があり、この分野は注目を集めており、主なプレーヤーには Starknet、zkSync、Scroll、Taiko、Linea、Polygon zkEVM (旧 Polygon Hermez) などが含まれ、5 つのカテゴリ (1、2) に分類されます。 、2.5、3、4) バイタリック作。具体的な内容は Vitalik のブログでご覧いただけます。
zkEVM が必要な理由
この質問は 2 つの観点から考える必要があります。
最初の zk Rollup の試行では、zkSync Lite、Loopring などの比較的単純な転送およびトランザクション機能のみを実現できます。しかし、海が難しくなるとイーサリアム上のチューリング完全EVMが使われ、プログラミングでさまざまなアプリケーションを作ることができなくなると、L2上の仮想マシンが叫ばれるようになりました。スマートコントラクトを作成する必要性もその 1 つです。
EVM の一部の設計はゼロ知識証明/有効性証明の生成に適していないため、一部のプレーヤーは、Starknet の Cairo Assembly や zkSync のような最下層でのゼロ知識証明/有効性証明に適した命令セットを使用することを選択します。亜鉛の指導。しかし同時に、誰もが EVM の巨大なユーザー エコシステムを放棄したくないため、上位層の EVM (タイプ 3 および 4 の zkEVM) と互換性があることを選択します。一部のプレーヤーは依然として従来の EVM 命令セット オペコードを主張し、タイプ 1 およびタイプ 2 の zkEVM であるオペコードのより効率的なプルーフを生成することに重点を置いています。 EVM の巨大な生態は 2 つに分けられます。
カカロット: 仮想マシン上の仮想マシン?
仮想マシン上に別の仮想マシンを作成できるのはなぜですか?これはコンピュータの専門家にとっては当たり前のことですが、コンピュータを理解していないユーザーにとってはそれほど明白ではないかもしれません。実は、これはわかりやすいのですが、積み木と同じで、下層が十分強ければ（チューリング完全な実行環境であれば）、上層に積み木を無制限に積み上げることができます。ただし、構築されるレイヤーの数に関係なく、最終的な実行は依然として最下位レベルの物理ハードウェアによって処理される必要があるため、レイヤーの数が増えると効率の低下につながります。同時に、異なるビルディング ブロックの異なる設計 (異なる仮想マシンの設計) により、ビルディング ブロックがより高く構築されるほど、ビルディング ブロックが崩壊する (実行エラー) 可能性が高くなり、より高いレベルが必要になります。技術サポートの。
Kakarot は Starknet 上に Cairo 言語で実装された EVM で、Cairo スマート コントラクトを使用して EVM 内のスタック、メモリ、実行などをシミュレートします。 EVMの実装は比較的難しくなく、最も利用率の高いGo-EthereumではGolangで書かれたEVMのほか、Python、Java、Java、Rustで書かれたEVMも存在します。
Kakarot zkEVM の技術的な難しさは、プロトコルが Starknet チェーン上のコントラクトとして存在することであり、これが 2 つの重要な問題を引き起こします。
kakarot プロトコルは 5 つの主要コンポーネントで構成されます (4 つは GitHub ドキュメントに記載されています。EOA は含まれていません。この記事は読者の便宜のために調整されています)。
kakarot CEO Elias Tazartes からのフィードバックによると、チームの最新バージョンでは、Account Resister の設計が放棄され、代わりに、31 バイトの Starknet アドレスから 20 ビット EVM アドレスへのマッピングが、対応する関係を保存するために直接使用されました。 。将来的には、相互運用性を向上させ、Starknet コントラクトが独自の EVM アドレスを登録できるようにするために、Account Register の設計が再利用される可能性があります。
Starknet の EVM と互換性があります: Warp と kakarot の違いは何ですか
Vitalikによって定義されたzkEVMタイプによれば、ワープはタイプ4に属しますが、カカロットは現在タイプ2.5に属しています。
Warp は Solidity コードを Cairo コードに変換するトランスレーターですが、コンパイラーと呼ばれないのは、出力される Cairo が依然として高級言語であるためと思われます。 Warp を通じて、Solidity 開発者は新しい Cairo 言語を学習することなく、元の開発ステータスを維持できます。多くのプロジェクト関係者にとって、Warp は Starknet エコシステムに参入するための敷居を下げ、大量のエンジニアリング コードを書き直すために Cairo を使用する必要がありません。
翻訳のアイデアはシンプルですが、互換性も最悪で、一部の Solidity コードは Cairo にうまく翻訳できず、アカウント システム、暗号アルゴリズムなどを含むコード ロジックは、移行を完了するためにソース コードを変更する必要があります。サポートされていない特定の機能については、Warp のドキュメントを参照してください。たとえば、多くのプロジェクトでは EOA アカウントと契約アカウントの実行ロジックを区別しますが、Starknet のアカウントはすべて契約アカウントであり、コードのこの部分は翻訳前に変更する必要があります。
Warpは高級言語レベルで互換性があり、kakarotはEVMレベルで互換性があります。
EVM の完全な書き換えと、オペコードとプリコンパイルの 1 つずつの実装により、kakarot のネイティブ互換性が高くなります。結局のところ、同じ仮想マシン (EVM) での実行は、別の仮想マシン (Cairo VM) での実行よりも常に互換性が高くなります。アカウント レジストリとブロックハッシュ レジストリは、異なるシステムでの差異を巧みに保護し、ユーザー移行の摩擦を最小限に抑えます。
カカロットチーム
この記事に関して貴重なコメントをくれたkakarotチーム、特にエリアス・タザルテスに感謝します。ありがとうございます！