EVMの並列最適化への道筋

誰もが知っているように、EVMはイーサリアムのコア実行エンジンおよびスマートコントラクト実行環境です。多くのノードを含むオープンネットワークとして、パブリックチェーンはハードウェアパラメータの差が大きいデバイス上で一貫した実行を実現するという課題に直面しています。仮想マシン技術は、この問題を解決するための可能性を提供し、スマートコントラクトが異なるオペレーティングシステムやデバイス上で同じ方法で実行され、結果の一貫性を確保することを可能にします。

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

従来、EVMは直列方式でトランザクションを処理しており、すべてのトランザクションが単一のキューに並び、決まった順序で実行されます。この設計はシンプルで維持管理が容易ですが、ブロックチェーン技術の発展とユーザー層の拡大に伴い、TPSとスループットの要求が常に高まっています。Rollup技術が成熟した後、EVMの直列実行の性能ボトルネックはイーサリアムの第2層ネットワークで特に顕著になりました。

SequencerはLayer2の重要なコンポーネントとして、単一のサーバー形式で全ての計算タスクを担います。もし関連モジュールの効率が十分に高ければ、最終的なボトルネックはSequencer自体の効率に依存することになります。この場合、直列実行が重大な障害となるでしょう。したがって、取引処理の並列化は未来の必然的なトレンドとなります。

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

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

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

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

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

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

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

イーサリアムの取引は、EOA送金と契約取引の2種類に分かれます。EOA送金は最もシンプルな取引タイプで、通常のアカウント間のETH送金を指し、契約呼び出しは関与せず、処理速度が速く、ガス代が低いです。

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

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

シリアル実行モードにおけるEVMとstateDBの協力プロセスは以下の通りです。

1. ブロック内のトランザクションは順番に1件ずつ処理され、各トランザクションは独立したインスタンスで具体的な操作を実行します。
2. すべての取引は同じ状態データベースstateDBを共有します。
3. 取引が実行される過程で、EVMはstateDBと絶えず相互作用し、関連データを読み取り、変更されたデータをstateDBに書き戻します。
4. ブロック内のすべてのトランザクションが完了した後、stateDB内のデータがグローバル状態ツリーにコミットされ、新しい状態ルートが生成されます。

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

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

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

並行実行モードでは、複数のスレッドを同時に起動して複数の取引を処理でき、効率が数倍向上する可能性がありますが、状態の競合問題に直面します。複数の取引が同時にあるアカウントのデータを書き換えようとする場合、競合が発生し、調整処理が必要になります。

並列最適化の原理

ZKRollupプロジェクトReddioの並列最適化アプローチを例にとると、その主な特徴は次のとおりです：

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

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

3. ステータスの同期変更：ブロック内のすべてのトランザクションが完了した後、各pending-stateDBに記録されたステータス変更の結果を順次グローバルstateDBに同期します。

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

Reddioは読み書き操作の処理を最適化しました：

• 読み取り操作：まず、Pending-stateのReadSetを確認します。必要なデータが存在する場合は、直接pending-stateDBから読み取ります。それ以外の場合は、前のブロックに対応するグローバルstateDBから履歴状態データを読み取ります。

• 書き込み操作：すべての書き込み操作は、最初に保留状態のWriteSetに記録され、取引の実行が完了した後、衝突検出を通じて状態変更結果をグローバルstateDBに統合しようとします。

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

状態の競合問題を解決するために、Reddioは競合検出メカニズムを導入しました：

• コンフリクト検出：異なるトランザクションのReadSetとWriteSetを監視し、複数のトランザクションが同じ状態項を読み書きしようとした場合、コンフリクトが発生したと見なします。

• コンフリクト処理：コンフリクト取引は再実行が必要なものとしてマークされます。

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

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

マルチスレッド並列最適化は、特に複雑なスマートコントラクト取引を処理する際に、パフォーマンスを大幅に向上させました。研究によると、低衝突ワークロードでは、ベンチマークのTPSは従来の直列実行と比較して3〜5倍向上しています。高衝突ワークロードでは、理論的にはすべての最適化手段を用いることで、最大60倍の向上が達成できる可能性があります。

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

まとめ

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

今後、Reddioの実装の詳細についてさらに議論することができます。これには、ストレージ効率のさらなる最適化、高い競合状況下での最適化計画、GPUを利用した最適化方法などが含まれます。