EVMの並列化最適化: パフォーマンスのボトルネックを突破する鍵

誰もが知っているように、EVMはイーサリアムの最も重要なコアコンポーネントの一つであり、"実行エンジン"および"スマートコントラクト実行環境"として位置付けられています。パブリックチェーンは大量のノードを含むオープンネットワークであるため、異なるノードのハードウェアパラメータには大きな違いがあります。スマートコントラクトが複数のノードで同じ結果を得るためには、"一貫性"の要件を満たす必要があり、仮想マシン技術は異なるデバイス上に同じ環境を構築することができます。

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

私たちがブロックチェーンブラウザで見るスマートコントラクトは、最初にEVMバイトコードにコンパイルされ、その後チェーンに保存されます。EVMがコントラクトを実行する際は、これらのバイトコードを順番に読み取り、各命令には対応するGasコストがあります。EVMは各命令の実行過程でのGas消費を追跡し、消費量は操作の複雑さに依存します。

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

Ethereumのコア実行エンジンとして、EVMはシリアル方式でトランザクションを処理します。すべてのトランザクションは単一キューに並び、確定した順序で実行されます。並列処理方式を採用しない理由は、ブロックチェーンが一貫性を厳密に満たす必要があるためで、一連のトランザクションはすべてのノードで同じ順序で処理されなければなりません。トランザクション処理を並列化すると、トランザクションの順序を正確に予測することが難しく、複雑なスケジューリングアルゴリズムを導入しない限り、正確な予測はできません。

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

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

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

次に、従来のEVMの限界と並行EVMの利点について深く掘り下げます。

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

コードモジュールのレベルでは、EVMを除いて、go-ethereumにおけるトランザクション実行に関連するもう一つのコアコンポーネントはstateDBであり、Ethereumにおけるアカウントの状態とデータストレージを管理します。EthereumはMerkle Patricia Trieと呼ばれるツリー構造をデータベースインデックスとして採用しています。EVMはトランザクション実行のたびにstateDB内の特定のデータを変更し、これらの変更は最終的にグローバルステートツリーに反映されます。

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

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

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

直列実行の具体的なプロセス

イーサリアムの取引は2つのカテゴリに分かれます: EOA送金とコントラクト取引。EOA送金は最もシンプルな取引タイプで、通常のアカウント間のETH送金を指し、コントラクトの呼び出しは含まれず、処理速度が非常に速く、発生するガス料金は極めて低いです。

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

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

シリアル実行モードでは、EVMとstateDBの協力による取引処理プロセスは次のようになります:

イーサリアムの設計において、1つのブロック内の取引は順番に逐次処理され、各取引は独立したインスタンスで具体的な操作を実行します。各取引は異なるEVMインスタンスを使用しますが、すべての取引は同じ状態データベースstateDBを共有します。

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

コードの観点から見ると、EVMとstateDBが協力してトランザクションを実行する大まかな流れは以下の通りです:

1. processBlock()関数は、Process()関数を呼び出して、ブロック内のトランザクションを処理します。

2. Process()関数内でforループが定義されており、取引は逐次実行されます。

3. すべてのトランザクションが処理されたら、writeBlockWithState()関数processBlock()関数を呼び出してから、statedbを呼び出します。 Commit() ステータス変更結果を送信する機能。

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

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

EVMの直列実行モードのボトルネックは明らかです: 取引は順番にキューに並べて実行する必要があり、時間がかかるスマートコントラクト取引が発生すると、他の取引は待つしかなく、CPUなどのハードウェアリソースを十分に活用できず、効率が大きく制限されます。

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

直列実行と並列実行を比較すると、前者は1つの窓口しかない銀行に似ており、並列EVMは複数の窓口がある銀行のようです。並列モードでは複数のスレッドを同時に開いて複数の取引を処理でき、効率は数倍向上する可能性がありますが、直面する課題は状態の競合問題です。

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

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

あるプロジェクトのEVMにおける並列最適化の原理

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

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

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

3. ステータスの同期変更: ブロック内のすべてのトランザクションが完了した後、EVMは各pending-stateDBに記録されたステータス変更結果を順次グローバルstateDBに同期します。異なるトランザクションの実行中にステータスの競合がなければ、pending-stateDBの記録をグローバルstateDBにスムーズに統合できます。

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

このプロジェクトは、読み書き操作の処理を最適化し、取引が状態データに正しくアクセスし、競合を避けられるようにしています:

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

書き込み操作: すべての書き込み操作(は、状態変更)を直接グローバルstateDBに書き込むのではなく、まずPending-stateのWriteSetに記録されます。トランザクションの実行が完了した後、衝突検出を通じて状態変更の結果をグローバルstateDBに統合しようとします。

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

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

コンフリクト処理:コンフリクトが検出された場合、コンフリクトトランザクションは再実行が必要とマークされます。

すべての取引が完了した後、複数のpending-stateDBの変更記録がグローバルstateDBに統合されます。統合が成功した場合、EVMは最終状態をグローバル状態ツリーに提出し、新しい状態ルートを生成します。

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

マルチスレッド並行最適化は性能向上に顕著で、特に複雑なスマートコントラクト取引を処理する際に効果的です。研究によると、低衝突ワークロードでは、ベンチマークのTPSは従来の直列実行に比べて3〜5倍向上しました。高衝突ワークロードでは、理論的にはすべての最適化手段を採用すれば、最大60倍の向上が可能です。

サマリー

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

今後の研究方向には、性能を向上させるためのストレージ効率のさらなる最適化、高い競合状況に対処するための最適化方案、そしてGPUを利用した最適化の方法などが含まれます。

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