EVMのシリアル実行ボトルネックと並列化最適化の探求

誰もが知っているように、EVMはイーサリアムのコア実行エンジンであり、スマートコントラクト実行環境であり、イーサリアムの最も重要なコンポーネントの1つです。多数のノードで構成されたパブリックチェーンネットワークにおいて、スマートコントラクトが異なるノードで一貫した実行結果を得るためには、仮想マシン技術が非常に重要な役割を果たしています。

EVMは、さまざまなオペレーティングシステムやデバイス上で一貫した方法でスマートコントラクトを実行できるため、このクロスプラットフォームの互換性は、各ノードがコントラクトを実行した後に一貫した結果を得られることを保証します。これは、Java仮想マシンJVMの動作原理に似ています。

通常の場合、スマートコントラクトは最初にEVMバイトコードにコンパイルされ、次にブロックチェーンに保存されます。EVMがコントラクトを実行する際、これらのバイトコードを順番に読み取り、各命令は特定のGasコストに対応しています。EVMは各命令の実行過程でのGas消費を追跡し、具体的な消費量は操作の複雑さによって異なります。

Ethereumのコア実行エンジンとして、EVMはシリアル方式でトランザクションを処理します。すべてのトランザクションは単一のキューに並び、確定した順序で順次実行されます。シリアルを選択する理由は、ブロックチェーンの整合性要件を厳格に満たし、一連のトランザクションがすべてのノードで同じ順序で処理されることを保証するためです。

2014年から2015年にかけて、イーサリアムの創設チームは時間が限られているため、シンプルでメンテナンスが容易な直列実行方式を選択しました。しかし、ブロックチェーン技術の発展とユーザー層の拡大に伴い、TPSとスループットに対する要求はますます高まっています。特に、Rollup技術が成熟し実装された後、EVMの直列実行によるパフォーマンスのボトルネックはイーサリアムの第二層ネットワークでより明らかになりました。

Layer2の重要なコンポーネントとして、Sequencerは単一のサーバーの形態で全ての計算タスクを担います。もしSequencerと連携する外部モジュールの効率が十分に高ければ、最終的なボトルネックはSequencer自体の効率に依存することになり、その場合は直列実行が重大な障害となるでしょう。

あるチームがDAレイヤーとデータ読み書きモジュールを徹底的に最適化することで、Sequencerは1秒間に約2000件以上のERC-20送金を実行できるようになりました。この数字は非常に高く見えますが、より複雑な取引の場合、TPSの数値は必然的に大幅に低下します。したがって、取引処理の並列化は未来の必然的なトレンドとなるでしょう。

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

イーサリアム取引実行の2つのコアコンポーネント

EVMを除いて、取引実行に関連するもう一つのコアコンポーネントはstateDBであり、これはEthereum内のアカウント状態とデータストレージを管理するために使用されます。EthereumはMerkle Patricia Trieツリー構造をデータベースインデックスとして採用しており、EVMは毎回の取引実行でstateDB内のいくつかのデータを変更します。これらの変更は最終的にグローバルステートツリーに反映されます。

stateDBは、EOAアカウントとコントラクトアカウントを含むすべてのEthereumアカウントの状態を維持する責任があります。保存されるデータには、アカウント残高やスマートコントラクトコードなどが含まれます。取引実行中、stateDBは対応するアカウントのデータを読み書きします。取引実行が終了した後、stateDBは新しい状態を基盤となるデータベースにコミットして永続化処理を行う必要があります。

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

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

シリアル実行の具体的なプロセス

イーサリアムの取引タイプは、EOA送金とコントラクト取引の2種類に分けられます。EOA送金は最もシンプルな取引タイプであり、通常のアカウント間のETH送金で、コントラクト呼び出しは含まれておらず、処理速度は非常に速く、請求されるガス代は非常に低いです。

対照的に、契約取引はスマートコントラクトの呼び出しと実行を含みます。EVMは契約取引を処理する際、スマートコントラクト内のバイトコード命令を逐次解釈して実行する必要があります。契約ロジックが複雑であればあるほど、関与する命令が多くなり、消費されるリソースも増加します。

例えば、ERC-20の送金処理時間はEOAの送金の約2倍であり、DEX上の取引操作のようなより複雑なスマートコントラクトでは、EOAの送金の十数倍の時間がかかる可能性があります。これは、DeFiプロトコルが取引の際に流動性プール、価格計算、トークン交換などの複雑なロジックを処理する必要があり、大量の計算を行う必要があるためです。

シリアル実行モードにおいて、EVMとstateDBの2つのコンポーネントが協力してトランザクションを処理するプロセスは以下の通りです：

イーサリアムの設計では、ブロック内のトランザクションは順番に処理され、各トランザクションには具体的な操作を実行するための独立したインスタンスがあります。各トランザクションは異なるEVMインスタンスを使用しますが、すべてのトランザクションは同じ状態データベースstateDBを共有します。

取引実行プロセスでは、EVMはstateDBと継続的に相互作用し、stateDBから関連データを読み取り、変更されたデータをstateDBに書き戻す必要があります。

ブロック内のすべての取引が完了すると、stateDBのデータはグローバルステートツリーにコミットされ、新しいステートルートが生成されます。ステートルートは各ブロックの重要なパラメータであり、ブロック実行後の新しいグローバルステートの「圧縮結果」を記録しています。

明らかに、EVMの直列実行モードには明らかなボトルネックがあります：トランザクションは順番に待機して実行されなければならず、時間がかかるスマートコントラクトのトランザクションがある場合、他のトランザクションは待つしかなく、ハードウェアリソースを十分に活用できず、効率が大きく制限されます。

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

EVMのマルチスレッド並列最適化ソリューション

生活の例えで言えば、シリアル実行は一つの窓口しかない銀行のようなもので、パラレルEVMは複数の窓口がある銀行に似ています。パラレルモードでは、複数のスレッドを立ち上げて同時に複数の取引を処理することができ、効率が数倍向上する可能性がありますが、状態の競合問題を解決する必要があります。

複数の取引が同時に特定のアカウントのデータを変更しようとすると、競合が発生します。たとえば、あるNFTは1つしか鋳造できないのに、取引1と取引2の両方がそのNFTを鋳造しようとした場合、両方のリクエストが満たされると明らかにエラーが発生します。実際の操作では、状態の競合がより頻繁に発生するため、並行処理には状態競合に対処する手段が必要です。

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

EVMの並列最適化原理に関するプロジェクト

あるZKRollupプロジェクトのEVMに対する並列最適化の考え方は、各スレッドにトランザクションを割り当て、各スレッドに一時的な状態データベースを提供することであり、これをpending-stateDBと呼びます。具体的な詳細は以下の通りです：

1. マルチスレッド並行取引実行：複数のスレッドを設定して同時に異なる取引を処理し、スレッド間で干渉しないことで、取引処理速度を数倍向上させることができます。

2. 各スレッドに一時的な状態データベースを割り当てる：各スレッドには独立した一時的な状態データベース（pending-stateDB）を割り当てます。各スレッドは取引を実行する際に、グローバルなstateDBを直接変更するのではなく、状態変化の結果を一時的にpending-stateDBに記録します。

3. 同期状態の変更：1つのブロック内のすべての取引が完了した後、EVMは各pending-stateDBに記録された状態変更の結果を順次グローバルstateDBに同期します。異なる取引が実行中に状態の競合が発生しなかった場合、pending-stateDBにある記録は問題なくグローバルstateDBに統合されます。

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

このプロジェクトは、取引が状態データに正しくアクセスし、競合を回避できるように、読み書き操作の処理方法を最適化しました。

• 読み取り操作：トランザクションが状態を読み取る必要がある場合、EVMはまずPending-stateのReadSetをチェックします。ReadSetに必要なデータが存在する場合、直接pending-stateDBから読み取ります。ReadSetに対応するキーと値のペアが見つからない場合は、前のブロックに対応するグローバルstateDBから履歴の状態データを読み取ります。

• 書き込み操作：すべての書き込み操作（すなわち状態の変更）は、直接グローバルstateDBに書き込まれるのではなく、まずPending-stateのWriteSetに記録されます。取引の実行が完了した後、競合検出を通じて、状態変更結果をグローバルstateDBに統合しようとします。

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

並行実行の重要な問題は状態の競合であり、複数のトランザクションが同じアカウントの状態を読み書きしようとする際に、この問題は特に顕著になります。これを解決するために、競合検出メカニズムが導入されました：

• コンフリクト検出：取引の実行中、EVMは異なる取引のReadSetとWriteSetを監視します。複数の取引が同じ状態項目を読み書きしようとした場合、それはコンフリクトが発生したと見なされます。

• 衝突処理：衝突が検出された場合、衝突取引は再実行が必要であるとマークされます。

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

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

マルチスレッドの並列最適化は、特に複雑なスマートコントラクト取引を処理する際のパフォーマンス向上において顕著です。研究によると、低い競合負荷の下で、ベンチマークのTPSは従来の直列実行と比較して約3〜5倍向上しました。高い競合負荷の下では、理論的にはすべての最適化手段を適用すれば、60倍の向上が達成される可能性さえあります。

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

サマリー

EVMのマルチスレッド並列最適化ソリューションは、各トランザクションに一時的な状態ライブラリを割り当て、異なるスレッドでトランザクションを並列実行することで、EVMのトランザクション処理能力を大幅に向上させました。読み書き操作の最適化と衝突検出メカニズムの導入により、EVM系のパブリックチェーンは状態の一貫性を保証しながら、トランザクションの大規模並列化を実現し、従来の直列実行モデルがもたらす性能ボトルネックを解決しました。これは、イーサリアムのRollupの将来の発展に重要な基盤を築くものです。

今後は、ストレージ効率を最適化してパフォーマンスを向上させる方法、高い競合状況下での最適化ソリューション、そしてGPUを活用した最適化に関する内容をさらに探求することができます。

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