EVMの並列化最適化:イーサリアムの取引処理効率を向上させる

EVMはイーサリアムのコア実行エンジンとして、"スマートコントラクト実行環境"という位置付けです。スマートコントラクトが異なるノードで一貫した結果を得られるように、EVMはJava仮想マシンJVMに似たクロスプラットフォームの仮想マシン環境を提供します。

スマートコントラクトはデプロイ時にEVMバイトコードにコンパイルされ、チェーン上に保存されます。EVMはコントラクトを実行する際にこれらのバイトコードを順に読み取り、各命令には対応するGasコストがあります。EVMは命令実行中のGas消費を追跡し、消費量は操作の複雑さに依存します。

! 並列EVMの最適化パスを説明するために、例としてReddioを取り上げます

従来のEVMは、取引を直列方式で処理し、すべての取引は単一のキューで順番に実行されます。この設計はシンプルでメンテナンスが容易ですが、ユーザー規模の拡大とRollup技術の適用に伴い、直列実行のパフォーマンスボトルネックがますます顕著になっています。

Rollupアーキテクチャでは、SequencerはLayer2の重要なコンポーネントとしてすべての計算タスクを担います。他の外部モジュールの効率が十分に高い場合、Sequencer自体の直列実行が最大のボトルネックとなります。あるチームは極限の最適化を通じて、Sequencerが1秒間に2000件以上のERC-20転送を実行できるようにしましたが、より複雑な取引ではTPSが大幅に低下します。したがって、取引処理の並列化が今後の発展のトレンドとなります。

EVMの他に、go-ethereumで取引実行に関連するもう一つのコアコンポーネントはstateDBで、アカウントの状態とデータストレージを管理します。イーサリアムはMerkle Patricia Trieツリー構造をデータベースインデックスとして使用し、EVMの各取引実行はstateDB内のデータを変更し、最終的にはグローバルステートツリーに反映されます。

stateDBはすべてのイーサリアムアカウントの状態を維持する責任があり、アカウントの残高やスマートコントラクトコードなどが含まれます。取引の実行中、stateDBは対応するアカウントデータの読み書きを行い、実行終了後に新しい状態を基盤となるデータベースに永続化します。

EVMとstateDBは協力してイーサリアムの取引実行環境を構築しています。EVMはスマートコントラクトの命令を解釈して実行し、計算結果に基づいてブロックチェーンの状態を変更します。一方、stateDBはグローバルな状態ストレージとして機能し、すべてのアカウントとコントラクトの状態変化を管理します。

! 並列EVMの最適化パスを説明するために、例としてReddioを取り上げます

シリアル実行モードでは、ブロック内のトランザクションは順番に処理されます。各トランザクションは独立したEVMインスタンスを使用しますが、すべてのトランザクションは同じstateDBを共有します。EVMは実行中にstateDBと継続的に相互作用し、関連データを読み取り、変更結果を書き戻す必要があります。

ブロック内のすべての取引が完了した後、stateDBのデータはグローバルステートツリーにコミットされ、新しいステートルートが生成されます。この直列モードの主なボトルネックは、取引がキューに並んで実行されなければならないため、ハードウェアリソースを十分に活用できず、特に複雑なスマートコントラクト取引に直面したときの効率が低いことです。

! 並列EVMの最適化パスを示す例としてReddioを取り上げます

取引処理効率を向上させるために、一部のプロジェクトはEVMのマルチスレッド並列最適化を試み始めています。これは、銀行が複数のカウンターを開設して同時に顧客にサービスを提供するのに似ており、処理速度を数倍向上させることができますが、発生する可能性のある状態衝突の問題を解決する必要があります。

あるZKRollupプロジェクトのEVMの並列最適化の考え方は、各スレッドに一時的な状態データベース(pending-stateDB)を割り当てることです。具体的な実装には:

1. マルチスレッドで並行して取引を実行し、互いに干渉しません。

2. 各スレッドには独立したpending-stateDBがあり、取引が実行されると、まずこの状態変化が記録されます。

3. すべての取引が完了した後、pending-stateDBの変更をグローバルstateDBに同期します。

! 並列EVMの最適化パスを示す例としてReddioを取り上げます

この提案は、読み書き操作を最適化しました:

• 読み取り操作の際は、まずpending-stateDBのReadSetを確認し、必要なデータがあれば直接読み取り、なければグローバルstateDBから履歴状態を読み取ります。

• 書き込み操作は直接グローバルstateDBに書き込まれるのではなく、まずpending-stateDBのWriteSetに記録されます。

! 並列EVMの最適化パスを示す例としてReddioを取り上げます

状態の競合を処理するために、競合検出メカニズムが導入されました。

• 異なる取引のReadSetとWriteSetを監視し、複数の取引が同じ状態項目を読み書きしている場合は衝突と見なします。

• コンフリクトトランザクションは再実行が必要であるとマークされます。

! 並列EVMの最適化パスを説明するためにReddioを例にとります

すべての取引が実行された後、複数のpending-stateDBの変更記録がグローバルstateDBに統合され、成功するとグローバル状態ツリーにコミットされて新しい状態ルートが生成されます。

研究によると、低コンフリクトのワークロードでは、並列EVMのTPSが従来のシリアル実行に比べて3-5倍向上しています。高コンフリクトのワークロードでは、理論上最大で60倍の向上が可能です。

! 並列EVMの最適化パスを示す例としてReddioを取り上げます

このマルチスレッド並列最適化ソリューションは、一時的な状態ストレージと並列実行を通じて、EVMの取引処理能力を大幅に向上させました。読み書き操作の最適化と衝突検出メカニズムの導入により、状態の一貫性を保証しながら取引の大規模な並列化を実現し、直列実行の性能ボトルネックを解決し、イーサリアムのロールアップの将来の発展の基盤を築きました。

! Reddioを例にとり、並列EVMの最適化パスを示します

! 並列EVMの最適化パスを示す例としてReddioを取り上げます

! 並列EVMの最適化パスを示す例としてReddioを取り上げます

! Reddioを例にとり、並列EVMの最適化パスを示します