EVMの並行化：イーサリアムの性能ボトルネックを解決する鍵

EVMはイーサリアムの実行エンジンおよびスマートコントラクト実行環境として、その最も重要なコンポーネントの一つです。スマートコントラクトが異なるノードで同じ結果を得られるように、一貫性の要件を満たすために、仮想マシン技術が最適な選択となりました。EVMは異なるオペレーティングシステムやデバイス上で同じ方法でスマートコントラクトを実行でき、クロスプラットフォームの互換性を保証します。

スマートコントラクトは、チェーンに載せる前にEVMバイトコードにコンパイルされます。EVMがコントラクトを実行する際、これらのバイトコードを順番に読み取り、各命令には対応するガスコストがあります。EVMは、各命令の実行過程におけるガス消費を追跡し、消費量は操作の複雑さによって異なります。

コア実行エンジンとして、EVMはシリアル方式でトランザクションを処理し、すべてのトランザクションが単一のキューに待機し、確定した順序で実行されます。この設計はシンプルでメンテナンスが容易ですが、ユーザー群が拡大し、技術が発展するにつれて、その性能ボトルネックがますます顕著になり、特にLayer2での表现が明らかです。

Layer2の重要なコンポーネントであるSequencerに関して、周辺モジュールの効率が十分に高い場合、最終的なボトルネックはSequencer自体の効率に依存します。あるチームは徹底的な最適化を行い、Sequencerは毎秒約2000件以上のERC-20転送を実行可能にしました。しかし、より複雑な取引に対しては、TPSは必ず大幅に低下します。したがって、取引処理の並列化は未来の必然的なトレンドとなります。

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

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

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

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

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

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

シリアル実行の限界

イーサリアムの取引はEOA送金と契約取引の二つのカテゴリに分かれます。EOA送金は最もシンプルな取引タイプで、処理速度が速く、ガス代が低いです。一方、契約取引はスマートコントラクトの呼び出しと実行を含み、EVMは契約内のバイトコード命令を逐次解釈・実行する必要があり、複雑さとリソース消費が高くなります。

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

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

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

EVMのマルチスレッド並列最適化

シリアル実行の制限を突破するために、業界はEVMのマルチスレッド並行最適化ソリューションを提案しました。このソリューションは、複数のカウンターが同時にサービスを提供する銀行に似ており、同時に複数の取引を処理でき、効率を大幅に向上させます。しかし、並行実行が直面する主要な課題は状態の競合問題であり、特別な対策を講じる必要があります。

あるプロジェクトのEVMの並行最適化の考え方は以下の通りです:

1. 複数のスレッドを設定して異なる取引を同時に処理し、スレッド間で干渉しないようにします。

2. 各スレッドに独立した一時状態データベース（pending-stateDB）を割り当てます。各スレッドがトランザクションを実行する際には、状態の変化をpending-stateDBに一時的に記録し、グローバルstateDBを直接変更しません。

3. ブロック内のすべてのトランザクションが完了した後、各pending-stateDBの状態変更を順次グローバルstateDBに同期します。もし衝突がなければ、記録を順調にマージできます。

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

このソリューションは、読み書き操作を最適化しました:

• 読み取り操作：まずはPending-stateのReadSetをチェックし、必要なデータがあれば直接読み取る；そうでなければ前のブロックのグローバルstateDBから履歴状態を読み取る。

• 書き込み操作：すべての変更はまずPending-stateのWriteSetに記録され、トランザクションの実行が完了した後にグローバルstateDBに統合されることを試みます。

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

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

• 異なるトランザクションのReadSetとWriteSetを監視し、複数のトランザクションが同じ状態項目を読み書きしようとする場合、それを衝突と見なします。
• コンフリクトトランザクションを再実行する必要があるとマークします。

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

すべてのトランザクションの実行が完了した後、複数のpending-stateDBの変更記録がグローバルstateDBに統合されます。統合が成功した後、最終的な状態がグローバル状態ツリーにコミットされ、新しい状態ルートが生成されます。

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

研究によると、低競合のワークロードでは、並行実行のTPSが従来の直列実行に比べて3〜5倍向上しました。高競合のワークロードでは、理論的に十分に最適化されれば、最大60倍の向上が可能です。

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

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

まとめ

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

将来的には、ストレージ効率を最適化し、高い競合状況に対処し、GPUを利用して最適化を行う方法をさらに探求し、EVMの性能を向上させることができます。

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

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