EVMの並列化にはどのような意味があるのか？あるいはEVM覇権下の終焉か？
TechFlow厳選深潮セレクト
EVMの並列化にはどのような意味があるのか？あるいはEVM覇権下の終焉か？
Parallel EVMは既存の分散型アプリケーションにインターネットレベルのパフォーマンスを実現させることができるか？
Web3業界の深掘り報道に専念し潮流を洞察著者：ZHIXIONG PAN
TL;DR
-
Parallel EVMのコンセプトは、Paradigm、Jump、Dragonflyなど複数の主要VCから注目を集めている。
-
代表的なプロジェクトにはMonad、Sei、MegaETH、Polygon、Neon EVM、BSCなどがある。一部はL1、一部はL2である。各チームの具体的な差異については、現時点では完全な公開情報が存在しない。
-
「Parallel（並列化）」という言葉だけを意味するParallel EVMだが、実際にはEVMの各コンポーネントのパフォーマンス最適化も含まれており、EVM標準における性能限界を追求している可能性が高い。
-
技術的課題：技術スタック全体の再構築に加え、並列処理される取引が衝突するかどうかを事前に予測し、衝突発生時の再実行効率をどう高めるか。
-
主な挑戦：オープンソースエコシステム内で差別化を図ること、分散性とパフォーマンスのバランスを見出すこと。
合意アルゴリズム、DA（データ層）、ゼロ知識証明技術が広く研究・改善されてきた後、次に注目されているハードコア技術はParallel EVMであり、資本市場はすでにこのストーリーに数億ドルを投資し、複数のユニコーン級スタートアップが誕生している。
コミュニティがParallel EVM（EVMの並列化）に注目し始めたきっかけは、Georgios Konstantopoulos（ParadigmのCTO）とDragonflyのHaseeb Qureshiが、2023年末に2024年のトレンドを展望する中で、偶然にも同じキーワードを口にしたことにさかのぼる。しかし、この話題に関する詳細な議論は少なく、また多くの人々がこれはまったく新しい概念ではなく、EVMと並列計算自体はどちらも比較的成熟した概念だと考えている。それならば、なぜこの二つを組み合わせたことが重要なトレンドになるのか？
しかしこれは依然として非常にニッチなテーマであり、多くの調査機関の年次レポートやトレンド予測を確認しても、Parallel EVMについての言及は見当たらない。つまり、まだ大規模なコンセンサスが形成されていない新興概念なのである。また、このテーマは合意アルゴリズムやDAと同様に純粋な技術分野に属しており、関心を持つ人々はさらに限られている。
Parallel EVMの最も直接的な利点は、既存の分散型アプリケーションに対してインターネットレベルのパフォーマンスを提供できる点にある。言い換えれば、Parallel EVMは、大量に蓄積された既存のスマートコントラクトを活用しつつ、高性能かつ並列処理可能なパブリックチェーンのスループットを実現できる唯一の新技術といえる。
Paradigmは参入を待ち望んでおり、Jumpは強力に注力
『Fortune』報道によると、ParadigmはMonadの最新ラウンドを主導し、30億ドルの評価額で2億ドルを調達する計画だ。これはParadigmが初めて投資するParallel EVMプロジェクトではないが、実際には彼らはこの技術に長年注目してきた。Georgios Konstantopoulos（Paradigm CTO）は、2021年からすでに言及していた。
Monadという語の由来も興味深い。哲学者ライプニッツの哲学体系において、「モナド」とは宇宙を構成する基本要素であり、分割不可能で物理的影響を受けない実体であり、それぞれが宇宙全体を反映しているとされる。中国語ではかつて「単子」と訳されていた。
一方、コンピュータサイエンスでは、モナドとは関数型プログラミング言語における一種のデザインパターンであり、現実世界の複雑さをほぼ数学的に純粋な形で扱うことを可能にし、コードをよりモジュール化され、理解・保守しやすくする。
もう一つ面白いのは、MonadとNomadがアナグラム（文字を並べ替えた語）の関係にあることだ。nomadは遊牧民を意味し、digital nomadはデジタルノマド（デジタル放浪者）を指す。
Monad以外にも、Georgiosがこの話題を議論する際に言及したのはSeiやPolygonである。彼がParallel EVMを高く評価するもう一つの理由は、彼らがRustで開発された高性能なイーサリアム実行層クライアント「Reth」を開発していることにある。Rethは急速に開発が進み、最近ベータ版に入ったばかりだ。彼らは将来的にReth上にParallel EVMを直接実装することを検討している可能性もあるが、工学的負荷を考えると、他のチームへの投資を通じてParallel EVMの進展を促す方がより現実的な選択だろう。なお、Monadの公式ドキュメントによれば、彼らの開発には主にC++とRustが使用されている。
Rethのリリース当初、ErigonチームのメンバーからAkulaのオープンソースコードを盗用したと非難され、その結果Akulaプロジェクトは資金不足により開発を停止した。これに対しGeorgiosは、Rethはいかなるクライアントのフォークでもなく、コードも他から借用したものではないと反論した上で、Geth、Erigon、Akulaからの影響とインスピレーションを受けていることは認めた。（https://thedefiant.io/paradigm-accused-copying-code）
もう一つの中心的存在がJump TradingおよびJump Capitalである。Monadの創業者はJump Trading出身で、ハイフリクエンシー取引（HFT）の豊富な経験を持つ。また、Seiの投資家にもJump Capitalが名を連ねており、JumpはSolanaエコシステムにも深く関与している。
また、Monadの初期投資家であるDragonflyも関連分野に注目しており、シャーディング技術に特化したNEARや、Aptos、Avalanche、Nervosなどのブロックチェーンに投資してきた。
合意アルゴリズムのアップグレードだけでは不十分。ついに実行層の番
過去の複数回のパブリックチェーンの争いの中では、実行層は常に軽視されてきた。コミュニティはほとんど合意アルゴリズムの革新にのみ注目してきた。Solana、Avalanche、EOSなどすべてがそうだ。確かにこれらは実行層でも多くの革新を遂げているが、一般にはその合意アルゴリズムだけが記憶に残り、これらの高性能チェーンの性能向上は合意アルゴリズムの改良によるものだと誤解されている。
しかし実際には、高性能パブリックチェーンを実現するためには、合意アルゴリズムと実行層の両方が整備されていなければならない。いわゆる「バケツの短板理論」に合致する。特にEVMベースでありながら合意アルゴリズムのみを改善したチェーンの場合、パフォーマンス向上にはより強力なノードが必要になる。例えばBSCはブロックあたりのGas上限を2000TPS程度に設定しているが、必要なマシン仕様はイーサリアムフルノードの数倍以上となる。Polygonは理論上1000TPSに到達可能だが、通常は数十～数百TPS程度にとどまる。
BSCアーカイブノードには最低でも16コアCPUと128GBメモリが必要であり、イーサリアムノードは最低4コアCPUと16GBメモリで動作する。
BSCチームもこうした問題を認識しており、NodeRealと共同開発してParallel EVM技術の導入を進めている。これにより、各ブロックが処理できる取引数をさらに増やし、より多くの取引を並列実行することで、TPSの上限を引き上げることが可能になる。
並列化：単一コアからマルチコアCPUへのアップグレード以上の意味
ほとんどのブロックチェーンシステムでは、取引は完全に順次的に実行される。これはシングルコアCPUに例えることができる。現在の計算が完了して初めて、次の計算に移行できる。この方式は遅いものの、シンプルでシステムの複雑度が低くなるという利点がある。
しかし、将来ブロックチェーンシステムがインターネットレベルのユーザー規模を取り込むには、シングルコアCPUでは明らかに不十分である。そこで、マルチコアCPUのような並列化仮想マシンにアップグレードすることで、複数の取引を同時に処理し、スループットを向上させる必要がある。ただし、これは工学的に多くの課題を伴う。例えば、同時に処理される二つの取引が同一のスマートコントラクトに対してデータ書き込みを行う場合、どのように対処するか？ こうした矛盾を解決するための新たなメカニズムを設計しなければならない。一方、完全に関連のないスマートコントラクトの並列実行であれば、スレッド数に応じてスループットを比例して拡張できる。
さらに、Parallel EVMは並列処理能力の向上だけでなく、シングルスレッド時の実行効率も最適化する。MonadのCEO Keone Honは述べている。「…（EVMの）真のボトルネックは、トランザクション処理における頻繁な状態の読み書きにある…」。彼はまた、並列実行はロードマップの一部にすぎず、Monadの真の使命はEVM全体を可能な限り効率的にすることだと強調している。
したがって、Parallel EVMという言葉は表面的には「並列化」を意味するが、実際にはEVMの各コンポーネントのパフォーマンス最適化を含んでおり、その取り組みはEVM標準における性能限界を示している可能性がある。
EVMはSolidityではない
スマートコントラクトの作成は、多くのブロックチェーン開発者の必須スキルとなっている。エンジニアはビジネス要件に応じて、Solidityまたは他のスマートコントラクト言語を使ってロジックを実装できる。しかし、EVMはSolidityのロジックを直接理解することはできず、まず「翻訳」（コンパイル）して、仮想マシンが理解できる低レベル言語（opcode操作コード／bytecodeバイトコード）に変換する必要がある。この翻訳プロセスについては、Solidity開発者が深く理解する必要はない。なぜなら、すでに成熟したツールがそれを自動で実行してくれるからだ。
「翻訳」であるため、そこにオーバーヘッド（余分なコスト）が発生する。しかし、低レベルコードに詳しいエンジニアは、Solidity内から直接操作コードを使ってロジックを記述でき、これにより最高のパフォーマンスを達成し、ユーザーのGas消費を節約できる。例えばOpenseaがリリースしたSeaportプロトコルでは、インラインアセンブリを多用して、ユーザーのGas支出を最小限に抑えている。
したがって、Parallel EVMが最終的に実現すれば、並列処理能力の向上だけでなく、EVMスタック全体のパフォーマンスが最適化される。普通のアプリ開発者は、わずかなGas節約のために膨大な最適化作業を行う必要がなくなる。なぜなら、基盤となる仮想マシンが十分に強力になり、こうした差異を吸収できるようになるからだ。
EVMのパフォーマンスはさまざまであり、「標準」と「工学的実践」は異なる
「仮想マシン」は「実行層」とも呼ばれる。これはスマートコントラクトがバイトコードにコンパイルされた後、実際に計算・処理されるエンジンである。イーサリアム仮想マシン（EVM）が定義する「バイトコード」は現在業界標準となっており、イーサリアムのレイヤー2ネットワークであろうと、他の独立したパブリックチェーンであろうと、まずEVM標準を完全に互換することが好まれる。開発者が一度書いたスマートコントラクトを複数のネットワークにデプロイできるため、費用対効果が非常に高い。
したがって、EVMの「バイトコード」標準を完全に互換していれば、それをEVMと呼ぶことができるが、その実装方法は大きく異なる可能性がある。たとえば、イーサリアムクライアントGethではGo言語でEVM標準を実装している。一方、イーサリアム財団の実行層研究チームIpsilonは、メンテナンスしているC++製の独立したEVM実装「evmone」を提供しており、他のイーサリアムクライアントはこれを直接呼び出してEVM実行に利用できる。
たとえば、多くの工業製品には国際規格が存在する。ある製品が販売される際には、細菌数が特定の値以下でなければならないといった要求がある。これが「標準」である。しかし、この出荷基準を満たす方法は、各工場が数十種類の殺菌方法の中から選択でき、中にはより費用対効果の高い方法を見つける工場もある。これが「実践」である。
このように、evmoneのような実装がある一方で、他の実装も可能である。つまりEVMの場合、EVM標準は加算・減算・乗算などの基本演算をサポートする「バイトコード」の基礎的操作を定義しており、各バイトコードは確定した入力を得たとき、確定した出力を返す。この標準を満たす範囲内で、実装（実践）方法には大きな自由度があり、多くのカスタマイズ空間と工学的最適化の余地が存在する。
Parallel EVMの共通点と相違点
Parallel EVM分野では、最も注目を集めるMonadのほかに、Sei、MegaETH、Polygon、Neon EVM、BSCなどが存在し、ParadigmのRethクライアントも並列化機能を実装しようとしている。
位置づけとしては、Monad、Sei、Polygon、BSCはすべてレイヤー1ブロックチェーンであるが、MegaETHはおそらくレイヤー2、Neon EVMはSolanaネットワーク上に構築されている。また、Rethはオープンソースのクライアントであり、MegaETHもその一部をRethの工学成果に基づいて開発すると見られる。
もちろん、これらのチーム間には競争関係もあり、技術的詳細や工学文書を完全に公開していないため、より詳しい比較は今後の公開情報を待つ必要がある。あるいは、BTCレイヤー2、Restaking、イーサリアムレイヤー2のように、技術的差異はわずか（かつオープンソース）であっても、エコシステムの独自性をどう構築するかが重要になってくるかもしれない。
Parallel EVMの技術的課題
逐次実行の取引においては、ボトルネックはCPUおよび状態の読み書きプロセスにある。しかし、その方式は十分にシンプルでエラーが少なく、すべてのトランザクションが順序立てて確実に実行できるという利点がある。一方、並列実行の仮想マシンでは、状態の衝突が発生する可能性があるため、実行前または実行後にその判断を追加する必要がある。
簡単な例として、仮想マシンが4つのスレッドでの並列実行をサポートし、各スレッドが同時に1つの取引を処理できるとする。もし4つの取引がすべてUniswapの同一ペアと取引を行う場合、取引ごとに価格が変動するため並列計算はできない。しかし、4つのスレッドがまったく無関係な処理を行う場合は問題ない。
ここには各チームの設計と工学的実装の違いが関わってくるが、少なくとも並列実行後には衝突を検出するモジュールが必要であり、衝突があれば再実行を行う。また、事前に衝突の可能性のある取引を予測・除外できれば、仮想マシン全体の並列効率をさらに高めることができる。
Parallel EVM自体の工学的差異に加えて、各チームは通常、状態データベースの読み書き性能を再設計・強化し、それに合わせて合意アルゴリズムも設計する。例えばMonadが開発したMonadDbおよびMonadBFTが該当する。
課題
Parallel EVMにとって、二つの潜在的課題がある：長期的な工学的価値がイーサリアムに吸収される可能性、およびノードの中央集権化。
各チームはParallel EVM技術の開発・テスト段階にあるため、まだすべての工学的詳細をオープンソース化していない。これが現時点でのバリューの源泉の一つである。しかし、テストネットやメインネットへ移行する段階で、これらの工学ファイルは公開され、イーサリアムや他のパブリックチェーンによって吸収される可能性もある。そのため、そのタイミングではエコシステム構築を加速し、エコシステム面での防衛線をさらに厚くする必要がある。
とはいえ、この問題はそれほど深刻ではない。第一に、Crypto開発者にとっては、現在より多くのオープンソースライセンスが利用可能である（例：Uniswapのライセンスのように、コードを公開しながらも商業目的でのフォークを禁止するタイプ）。第二に、Monad自体の位置づけはイーサリアムとは異なる。仮にイーサリアムが将来シングルスロットファイナリティ（SSF）を実現しても、取引のファイナリティは最低でも12秒はかかる。これはより高頻度のアプリケーションシーンでは到底不十分である。
もう一つの課題は、すべての高性能パブリックチェーンに共通するもので、信頼不要（trustless）、許可不要（permissionless）という基本要件を満たすために、より多くのノードを展開できるかどうか、つまり「分散化」の維持である。ここでは、たとえば「TPS ÷ ノードのハードウェア要件」といった指標を定量化し、一定のハードウェア条件下でどのパブリックチェーン／クライアントがより高いTPSを達成できるかを比較することも可能になるだろう。結局のところ、ノードのハードウェア要件が低ければ低いほど、ノード数は多くなり得る。
今後も、Parallel EVM各プロジェクトの進展を追い続け、その技術と相違点について詳しく検討していく予定である。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@ChainFeedsxyz
