# EVMの並列化と最適化への道筋誰もが知っているように、EVMはイーサリアムの最も重要なコアコンポーネントの一つであり、「実行エンジン」と「スマートコントラクト実行環境」として重要な役割を果たしています。何千ものノードで構成されるパブリックチェーンネットワークにおいて、仮想マシンの存在はスマートコントラクトが異なるハードウェア構成のノード上で同様に実行されることを可能にし、結果の一貫性を保証します。このようなクロスプラットフォーム互換性は、Java仮想マシンJVMに非常に似ています。スマートコントラクトは、ブロックチェーンにアップロードされる前にEVMバイトコードにコンパイルされます。EVMがコントラクトを実行する際、これらのバイトコードを順番に読み取ります。各命令には対応するGasコストがあります。EVMは命令の実行中にGas消費を追跡し、消費量は操作の複雑さによって異なります。! [並列EVMの最適化パスを説明するために、例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-6618615055b17eadfa9646a0ea71fecd)Ethereumのコア実行エンジンとして、EVMは直列実行方式でトランザクションを処理します。すべてのトランザクションは単一のキューに並び、確定した順序で順次実行されます。この設計はシンプルで維持しやすいですが、ユーザー群が拡大し、技術が進化するにつれて、その性能のボトルネックがますます顕著になってきました。特に、Rollup技術が成熟した後、Ethereumのレイヤー2ネットワークで顕著に現れています。SequencerはLayer2の重要なコンポーネントであり、単一のサーバー形式で全ての計算タスクを担います。もし付随する外部モジュールの効率が十分高い場合、最終的なボトルネックはSequencer自体の効率に依存します。この時、直列実行が大きな障害となります。あるチームはDA層とデータ読み書きモジュールの徹底的な最適化を通じて、Sequencerが毎秒約2000件以上のERC-20トランザクションを処理できるようにしました。この数字は非常に高く見えますが、複雑な取引に対してはTPSの数値は必然的に大幅に減少します。したがって、取引処理の並列化は未来の必然的なトレンドとなるでしょう。## イーサリアム取引実行の二つのコアコンポーネントEVMを除いて、go-ethereumにおける取引実行に関連するもう一つのコアコンポーネントはstateDBであり、これはEthereum内のアカウントの状態とデータストレージを管理するために使用されます。EthereumはMerkle Patricia Trieツリー構造をデータベースインデックスとして採用しており、EVMは各取引実行のたびにstateDB内のいくつかのデータを変更します。これらの変更は最終的にグローバル状態ツリーに反映されます。stateDBは、EOAアカウントとコントラクトアカウントを含むすべてのEthereumアカウントの状態を維持する責任があります。保存されるデータには、アカウントの残高、スマートコントラクトコードなどが含まれます。取引の実行中、stateDBは対応するアカウントのデータを読み書きします。取引の実行が終了した後、stateDBは新しい状態を基盤となるデータベースに提出して永続化処理を行う必要があります。全体として、EVMはスマートコントラクトの命令を解釈し実行する責任があり、計算結果に基づいてブロックチェーン上の状態を変更します。一方、stateDBはグローバルな状態ストレージとして機能し、すべてのアカウントやコントラクトの状態変化を管理します。両者は協力してイーサリアムの取引実行環境を構築します。! [並列EVMの最適化パスを説明するために、例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-2c09413238e16d168c5f593e2923708b)## 直列実行の具体的なプロセスイーサリアムの取引タイプは、EOA送金とコントラクト取引に分かれます。EOA送金は最も単純な取引タイプであり、通常のアカウント間のETH送金であり、コントラクト呼び出しは関与せず、処理速度が非常に速く、ガス代が非常に低いです。契約取引は、スマートコントラクトの呼び出しと実行を含みます。EVMは契約取引を処理する際に、スマートコントラクト内のバイトコード命令を一つずつ解釈し実行する必要があります。契約のロジックが複雑であればあるほど、関与する命令が多くなり、消費されるリソースも増えます。例えば、ERC-20の送金処理時間はEOAの送金の約2倍であり、より複雑なスマートコントラクト、例えばあるDEXでの取引操作では、EOAの送金の十倍以上の時間がかかる可能性があります。これは、DeFiプロトコルが取引時に流動性プール、価格計算、トークン交換などの複雑なロジックを処理する必要があり、非常に複雑な計算を行う必要があるためです。シリアル実行モードでは、EVMとstateDBの協力プロセスは次のようになります。1. ブロック内のトランザクションは、先後の順序で逐次処理され、それぞれのトランザクションは具体的な操作を実行する独立したインスタンスを持っています。2. すべてのトランザクションは異なるEVMインスタンスを使用していますが、すべてのトランザクションは同じ状態データベースstateDBを共有しています。3. 取引の実行中に、EVMはstateDBと継続的に相互作用し、関連データを読み取り、変更されたデータをstateDBに書き戻す必要があります。4. すべての取引が処理された後、stateDB内のデータはグローバル状態ツリーにコミットされ、新しい状態ルートが生成されます。! [並列EVMの最適化パスを示す例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-404bb55ec4d21fe81783881149ac0ad6)EVMの逐次実行モードのボトルネックは明らかです:取引は順番にキューに並んで実行されなければならず、時間のかかるスマートコントラクト取引が発生すると、他の取引は待機せざるを得ず、ハードウェアリソースを十分に活用できず、効率が大きく制限されます。## EVMのマルチスレッド並行最適化ソリューション並行EVMは、複数のカウンターを持つ銀行に似ており、複数のスレッドを同時に開いて複数のトランザクションを処理できるため、効率は数倍向上します。しかし、厄介なのは状態の競合問題であり、調整処理が必要です。! [並列EVMの最適化パスを示す例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-fc9301b18b6299dc8f792e68961977cd)あるZKRollupプロジェクトのEVMに対する並行最適化の考え方は次のとおりです:1. マルチスレッドによる並行取引実行:複数のスレッドを設定して異なる取引を同時に処理し、スレッド間の干渉を防ぎ、取引処理速度を数倍に向上させることができます。2. 各スレッドに一時状態データベースを割り当てる:各スレッドは独立した一時状態データベース(pending-stateDB)を割り当てられます。各スレッドがトランザクションを実行する際、グローバルstateDBを直接変更するのではなく、状態の変化結果を一時的にpending-stateDBに記録します。3. ステータス変更の同期:1つのブロック内のすべてのトランザクションが完了した後、EVMは各pending-stateDBに記録されたステータス変更結果を順次グローバルstateDBに同期します。異なるトランザクションが実行中にステータスの競合が発生しなかった場合、pending-stateDBの記録を問題なくグローバルstateDBに統合できます。! [並列EVMの最適化パスを示す例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-c62d7268de0c9ada677dc15618b1e024)このプロジェクトは、トランザクションが状態データに正しくアクセスし、競合を回避できるように、読み書き操作の処理を最適化しました。- 読み取り操作:取引が状態を読み取る必要があるとき、EVMはまずPending-stateのReadSetを確認します。必要なデータが存在する場合は、pending-stateDBから直接読み取ります。ReadSetに対応するキーと値のペアが見つからない場合は、前のブロックの対応するグローバルstateDBから履歴の状態データを読み取ります。- 書き込み操作:すべての書き込み操作は直接グローバルstateDBに書き込まれるのではなく、まずPending-stateのWriteSetに記録されます。取引の実行が完了した後、競合検出を通じて状態変更結果をグローバルstateDBに統合しようとします。! [並列EVMの最適化パスを説明するためにReddioを例にとります](https://img-cdn.gateio.im/social/moments-75575d5ea4bfa2edcc71ad93d3277caf)状態競合問題を解決するために、競合検出メカニズムが導入されました:- コンフリクト検出:EVMは異なるトランザクションのReadSetとWriteSetを監視します。同じ状態項目を読み書きしようとする複数のトランザクションがある場合、それはコンフリクトが発生したと見なされます。- コンフリクト処理:コンフリクトが検出された場合、コンフリクトトランザクションは再実行が必要であるとマークされます。! [並列EVMの最適化パスを示す例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-6274c33f6c958750df5cf3e53949b7fb)すべての取引が実行された後、複数のpending-stateDBの変更記録がグローバルstateDBに統合されます。統合が成功した場合、EVMは最終状態をグローバル状態ツリーに提出し、新しい状態ルートを生成します。! [Reddioを例にとり、並列EVMの最適化パスを示します](https://img-cdn.gateio.im/social/moments-4966960247a4550afa25f04eaaabbbd8)マルチスレッド並列最適化は、特に複雑なスマートコントラクト取引を処理する際のパフォーマンス向上に顕著です。研究によると、低衝突のワークロードでは、ベンチマークのTPSが従来の直列実行に比べて3〜5倍向上しました。高衝突のワークロードでは、理論的にはすべての最適化手段を使えば、60倍の向上を達成できる可能性があります。! [並列EVMの最適化パスを示す例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-af377193cf86df94c08df49ba217e327)## まとめEVMのマルチスレッド並列最適化ソリューションは、各トランザクションに一時的な状態ライブラリを割り当て、異なるスレッドでトランザクションを並列実行することによって、EVMのトランザクション処理能力を大幅に向上させました。読み書き操作の最適化と競合検出メカニズムの導入により、EVM系パブリックチェーンは状態の一貫性を保ちながら、トランザクションの大規模な並列化を実現し、従来のシリアル実行モデルがもたらすパフォーマンスのボトルネックを解決しました。これは、イーサリアムのロールアップの未来の発展に重要な基盤を築きました。! [並列EVMの最適化パスを示す例としてReddioを取り上げます](https://img-cdn.gateio.im/social/moments-cd65f3332323ef44ea8f5f572cafd188)! [Reddioを例にとり、並列EVMの最適化パスを示します](https://img-cdn.gateio.im/social/moments-77a2eed7aad280b3028c93d8cb81f124)
EVM最適化:マルチスレッド並列処理による取引処理効率の向上
EVMの並列化と最適化への道筋
誰もが知っているように、EVMはイーサリアムの最も重要なコアコンポーネントの一つであり、「実行エンジン」と「スマートコントラクト実行環境」として重要な役割を果たしています。何千ものノードで構成されるパブリックチェーンネットワークにおいて、仮想マシンの存在はスマートコントラクトが異なるハードウェア構成のノード上で同様に実行されることを可能にし、結果の一貫性を保証します。このようなクロスプラットフォーム互換性は、Java仮想マシンJVMに非常に似ています。
スマートコントラクトは、ブロックチェーンにアップロードされる前にEVMバイトコードにコンパイルされます。EVMがコントラクトを実行する際、これらのバイトコードを順番に読み取ります。各命令には対応するGasコストがあります。EVMは命令の実行中にGas消費を追跡し、消費量は操作の複雑さによって異なります。
! 並列EVMの最適化パスを説明するために、例としてReddioを取り上げます
Ethereumのコア実行エンジンとして、EVMは直列実行方式でトランザクションを処理します。すべてのトランザクションは単一のキューに並び、確定した順序で順次実行されます。この設計はシンプルで維持しやすいですが、ユーザー群が拡大し、技術が進化するにつれて、その性能のボトルネックがますます顕著になってきました。特に、Rollup技術が成熟した後、Ethereumのレイヤー2ネットワークで顕著に現れています。
SequencerはLayer2の重要なコンポーネントであり、単一のサーバー形式で全ての計算タスクを担います。もし付随する外部モジュールの効率が十分高い場合、最終的なボトルネックはSequencer自体の効率に依存します。この時、直列実行が大きな障害となります。
あるチームはDA層とデータ読み書きモジュールの徹底的な最適化を通じて、Sequencerが毎秒約2000件以上のERC-20トランザクションを処理できるようにしました。この数字は非常に高く見えますが、複雑な取引に対してはTPSの数値は必然的に大幅に減少します。したがって、取引処理の並列化は未来の必然的なトレンドとなるでしょう。
イーサリアム取引実行の二つのコアコンポーネント
EVMを除いて、go-ethereumにおける取引実行に関連するもう一つのコアコンポーネントはstateDBであり、これはEthereum内のアカウントの状態とデータストレージを管理するために使用されます。EthereumはMerkle Patricia Trieツリー構造をデータベースインデックスとして採用しており、EVMは各取引実行のたびにstateDB内のいくつかのデータを変更します。これらの変更は最終的にグローバル状態ツリーに反映されます。
stateDBは、EOAアカウントとコントラクトアカウントを含むすべてのEthereumアカウントの状態を維持する責任があります。保存されるデータには、アカウントの残高、スマートコントラクトコードなどが含まれます。取引の実行中、stateDBは対応するアカウントのデータを読み書きします。取引の実行が終了した後、stateDBは新しい状態を基盤となるデータベースに提出して永続化処理を行う必要があります。
全体として、EVMはスマートコントラクトの命令を解釈し実行する責任があり、計算結果に基づいてブロックチェーン上の状態を変更します。一方、stateDBはグローバルな状態ストレージとして機能し、すべてのアカウントやコントラクトの状態変化を管理します。両者は協力してイーサリアムの取引実行環境を構築します。
! 並列EVMの最適化パスを説明するために、例としてReddioを取り上げます
直列実行の具体的なプロセス
イーサリアムの取引タイプは、EOA送金とコントラクト取引に分かれます。EOA送金は最も単純な取引タイプであり、通常のアカウント間のETH送金であり、コントラクト呼び出しは関与せず、処理速度が非常に速く、ガス代が非常に低いです。
契約取引は、スマートコントラクトの呼び出しと実行を含みます。EVMは契約取引を処理する際に、スマートコントラクト内のバイトコード命令を一つずつ解釈し実行する必要があります。契約のロジックが複雑であればあるほど、関与する命令が多くなり、消費されるリソースも増えます。
例えば、ERC-20の送金処理時間はEOAの送金の約2倍であり、より複雑なスマートコントラクト、例えばあるDEXでの取引操作では、EOAの送金の十倍以上の時間がかかる可能性があります。これは、DeFiプロトコルが取引時に流動性プール、価格計算、トークン交換などの複雑なロジックを処理する必要があり、非常に複雑な計算を行う必要があるためです。
シリアル実行モードでは、EVMとstateDBの協力プロセスは次のようになります。
! 並列EVMの最適化パスを示す例としてReddioを取り上げます
EVMの逐次実行モードのボトルネックは明らかです:取引は順番にキューに並んで実行されなければならず、時間のかかるスマートコントラクト取引が発生すると、他の取引は待機せざるを得ず、ハードウェアリソースを十分に活用できず、効率が大きく制限されます。
EVMのマルチスレッド並行最適化ソリューション
並行EVMは、複数のカウンターを持つ銀行に似ており、複数のスレッドを同時に開いて複数のトランザクションを処理できるため、効率は数倍向上します。しかし、厄介なのは状態の競合問題であり、調整処理が必要です。
! 並列EVMの最適化パスを示す例としてReddioを取り上げます
あるZKRollupプロジェクトのEVMに対する並行最適化の考え方は次のとおりです:
マルチスレッドによる並行取引実行:複数のスレッドを設定して異なる取引を同時に処理し、スレッド間の干渉を防ぎ、取引処理速度を数倍に向上させることができます。
各スレッドに一時状態データベースを割り当てる:各スレッドは独立した一時状態データベース(pending-stateDB)を割り当てられます。各スレッドがトランザクションを実行する際、グローバルstateDBを直接変更するのではなく、状態の変化結果を一時的にpending-stateDBに記録します。
ステータス変更の同期:1つのブロック内のすべてのトランザクションが完了した後、EVMは各pending-stateDBに記録されたステータス変更結果を順次グローバルstateDBに同期します。異なるトランザクションが実行中にステータスの競合が発生しなかった場合、pending-stateDBの記録を問題なくグローバルstateDBに統合できます。
! 並列EVMの最適化パスを示す例としてReddioを取り上げます
このプロジェクトは、トランザクションが状態データに正しくアクセスし、競合を回避できるように、読み書き操作の処理を最適化しました。
読み取り操作:取引が状態を読み取る必要があるとき、EVMはまずPending-stateのReadSetを確認します。必要なデータが存在する場合は、pending-stateDBから直接読み取ります。ReadSetに対応するキーと値のペアが見つからない場合は、前のブロックの対応するグローバルstateDBから履歴の状態データを読み取ります。
書き込み操作:すべての書き込み操作は直接グローバルstateDBに書き込まれるのではなく、まずPending-stateのWriteSetに記録されます。取引の実行が完了した後、競合検出を通じて状態変更結果をグローバルstateDBに統合しようとします。
! 並列EVMの最適化パスを説明するためにReddioを例にとります
状態競合問題を解決するために、競合検出メカニズムが導入されました:
! 並列EVMの最適化パスを示す例としてReddioを取り上げます
すべての取引が実行された後、複数のpending-stateDBの変更記録がグローバルstateDBに統合されます。統合が成功した場合、EVMは最終状態をグローバル状態ツリーに提出し、新しい状態ルートを生成します。
! Reddioを例にとり、並列EVMの最適化パスを示します
マルチスレッド並列最適化は、特に複雑なスマートコントラクト取引を処理する際のパフォーマンス向上に顕著です。研究によると、低衝突のワークロードでは、ベンチマークのTPSが従来の直列実行に比べて3〜5倍向上しました。高衝突のワークロードでは、理論的にはすべての最適化手段を使えば、60倍の向上を達成できる可能性があります。
! 並列EVMの最適化パスを示す例としてReddioを取り上げます
まとめ
EVMのマルチスレッド並列最適化ソリューションは、各トランザクションに一時的な状態ライブラリを割り当て、異なるスレッドでトランザクションを並列実行することによって、EVMのトランザクション処理能力を大幅に向上させました。読み書き操作の最適化と競合検出メカニズムの導入により、EVM系パブリックチェーンは状態の一貫性を保ちながら、トランザクションの大規模な並列化を実現し、従来のシリアル実行モデルがもたらすパフォーマンスのボトルネックを解決しました。これは、イーサリアムのロールアップの未来の発展に重要な基盤を築きました。
! 並列EVMの最適化パスを示す例としてReddioを取り上げます
! Reddioを例にとり、並列EVMの最適化パスを示します