EVM並列化の最適化:Reddioを例にとり、パフォーマンス向上への道を議論します

誰もが知っているように、EVMはイーサリアムの最も重要なコンポーネントの一つであり、「実行エンジン」および「スマートコントラクト実行環境」として重要な役割を担っています。ブロックチェーンという数千のノードからなるオープンネットワークにおいて、異なるノードのハードウェア構成には大きな差異がある可能性があります。スマートコントラクトが各ノードで一貫した実行結果を得るためには、仮想マシン技術が理想的な解決策となります。

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

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

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

2014年から2015年にかけて、イーサリアムの創設チームは、時間の制約からシンプルで維持しやすい直列実行方式を選択しました。しかし、ブロックチェーン技術の進化とユーザー層の拡大に伴い、TPSやスループットへの要求はますます高まっています。Rollup技術が登場し成熟した後、EVMの直列実行によるパフォーマンスボトルネックがイーサリアムのレイヤー2ネットワーク上で明らかに浮き彫りになっています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EVMの直列実行モードのボトルネックは明らかです：トランザクションは順番にキューに入れて実行する必要があり、時間のかかるスマートコントラクトのトランザクションが発生した場合、それが処理されるまで他のトランザクションは待たざるを得ません。これは明らかにCPUなどのハードウェアリソースを十分に活用できず、効率が大きく制限されます。

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

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

直列実行と並列実行は、1つの窓口しかない銀行と複数の窓口がある銀行に例えることができます。並列モードでは、複数のスレッドを同時に起動して複数の取引を処理でき、効率が数倍向上しますが、厄介なのは状態の競合問題です。

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

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

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の将来の発展に重要な基盤を築くものです。

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