Partnered With:

EVM 並列化の重要性は何でしょうか、それとも EVM 覇権の終焉を意味するのでしょうか?

ChainFeeds

この記事を読むのに必要な時間は 29 分

Parallel EVM により、既存の分散アプリケーションでインターネットレベルのパフォーマンスを実現できますか?

元のソース: Chainfeeds

TL;DR

1. Parallel EVM のコンセプトは、Paradigm、Jump、Dragonfly など、いくつかの大手 VC によって支持されています。

2.代表的なプロジェクトはMonadで、他にSei、MegaETH、Polygon、Neon EVM、BSCなどがあり、L1のものもあればL2のものもあります。チーム間の具体的な違いについては、完全な公開情報はありません。

3. Parallel EVM は文字通り「並列化」を意味しますが、実際には EVM の各コンポーネントのパフォーマンスを特別に最適化したものなので、その取り組みは EVM 標準のパフォーマンス限界を表す可能性があります。

4.難しさ: テクノロジースタック全体の再構築に加えて、並列トランザクションが競合するかどうかを事前に予測する方法と、競合後の再実行の効率性という問題もあります。

5.課題: オープンソースエコシステムで差別化を構築する方法と、分散化とパフォーマンスのバランスを見つける方法。

コンセンサスアルゴリズム、DA（データ層）、ゼロ知識証明技術が広く研究され、反復されてきた後、次に注目されるハードコア技術は Parallel EVM です。資本市場もこの物語に数億ドルを投資し、ユニコーンレベルのスタートアップ企業がいくつか誕生しました。

Parallel EVM（EVM並列化）にコミュニティが注目し始めたのは、2023年末にGeorgios Konstantopoulos氏（ParadigmのCTO）とDragonflyのHaseeb Qureshi氏が2024年のトレンドを展望する際に同じキーワードに言及したためです。しかし、このトピックについて議論されている詳細はあまりなく、これは新しい概念ではないと考える人が多くいます。 EVM と並列コンピューティングはどちらも比較的成熟した概念です。なぜこれら 2 つの単語を組み合わせることが重要なトレンドなのでしょうか?

しかし、これはまだ非常にニッチなトピックであり、多くの研究機関の年次概要やトレンド予測を調べても、Parallel EVM については言及されていません。したがって、これはまだ大規模なコンセンサスが形成されていない新しい概念です。さらに、この概念は、コンセンサスアルゴリズムやDAなどの純粋に技術関連のトピックと似ているため、注目する人はさらに少なくなります。

Paralle EVM の最も直接的な利点は、既存の分散型アプリケーションでインターネットレベルのパフォーマンスを実現できることです。 Parallel EVM は、（多数の成熟した）既存のスマートコントラクトを活用できるだけでなく、高いパフォーマンスと並列パブリックチェーンのスループットを実現できる唯一の新しいテクノロジであるとも言えます。

Paradigm は長い間この市場への参入を期待しており、Jump は大きな賭けに出ました

Fortune によると、Paradigm は Monad の最新ラウンドを主導し、30 億ドルの評価額で 2 億ドルを調達する予定です。これは、Paradigm が投資を計画している最初の Parallel EVM コンセプトチームですが、実際には彼らは長年にわたってこのテクノロジに注目してきました。 2021 年に Georgios Konstantopoulos (Paradigm の CTO) がこの用語について言及しました。

Monad という言葉の由来も非常に興味深いです。哲学者ライプニッツの哲学体系では、モナドは宇宙を構成する基本要素です。それらは物理法則の影響を受けない、分割不可能な実体です。それぞれのモナドは宇宙全体を反映しており、かつては中国語で「モナド」と翻訳されていました。

コンピュータサイエンスにおいて、モナドは関数型プログラミング言語のデザインパターンであり、プログラマーが現実世界の複雑さに数学的な純粋さに近い形で対処できるようにし、コードをよりモジュール化して理解しやすく、保守しやすくします。

もう一つ興味深いのは、Monad と Nomad がお互いのアナグラムであることです。 Nomad は遊牧民を意味し、digital nomad はデジタル遊牧民/デジタル遊牧民を意味します。

このトピックについて議論する際に、Georgios は Monad に加えて、Sei と Polygon についても言及しました。しかし、彼が Parallel EVM に非常に楽観的な理由は他にもあります。それは、彼らが Ethereum クライアント Reth を開発しているということです。これは、Rust 言語で実装された高性能な Ethereum 実行層クライアントとして位置付けられています。 Reth は急速に開発が進められており、ベータ段階に入ったばかりです。おそらく彼らは Parallel EVM を Reth に直接実装することを検討するでしょうが、研究開発作業の量を考慮すると、他のチームに投資して Parallel EVM を推進する方がよい選択肢かもしれません。 Monad のドキュメントによると、エンジニアリングでは主に C++ と Rust が使用されています。

Reth が最初にリリースされたとき、Erigon チームのメンバーから Akula のオープンソースコードを盗用していると非難され、Akula プロジェクトへの資金不足により開発が中止されることにもなりました。 Georgios 氏は、Reth は他のクライアントのフォークではなく、コードも他のクライアントから来たものではないが、確かに Geth、Erigon、Akula の影響を受け、インスピレーションを受けていると答えました。

もう一つの主要参加者は、Jump Trading と Jump Capital です。 Monad の創設者は Jump Trading 出身で、高頻度取引の豊富な経験を持っています。 Seiの投資家にはJump Capitalが含まれており、Jumpもインフラストラクチャやプロジェクトを含むSolanaエコシステムに深く関わっています。

Monadの初期投資家であるDragonflyも関連分野に注目しており、シャーディング技術に重点を置くNEARや、Aptos、Avalanche、Nervosなどのパブリックチェーンに投資しています。

コンセンサスアルゴリズムのアップグレードだけでは不十分で、最終的には実行レイヤーの番です

過去数回のパブリックチェーン戦争では、実行レイヤーは常に無視されてきました。彼らは、Solana、Avalanche、EOS など、コンセンサスアルゴリズムの革新についてのみほとんど話します。実行レベルでは多くの革新が行われていますが、コミュニティは依然として使用しているコンセンサスアルゴリズムを覚えており、コミュニティ全体も、これらの高性能パブリックチェーンがこれらのパフォーマンスを達成できるのはコンセンサスアルゴリズムの革新によるものだと考えています。

しかし、実際には、高性能なパブリックチェーンを獲得したい場合、コンセンサスアルゴリズムと実行層を一致させる必要があり、これも木樽のショートボード効果と一致しています。コンセンサスアルゴリズムのみを改善する EVM ベースのパブリックチェーンの場合、パフォーマンスを向上させるには、より強力なノードが必要です。たとえば、BSC ではブロックが処理できる Gas が 2000 TPS に制限されており、必要なマシン構成は Ethereum フルノードの投資の数倍になります。 Polygon は理論上 1000 TPS を達成できますが、通常は数十から数百しか達成できません。

BSC アーカイブノードには少なくとも 16 コアの CPU と 128G のメモリが必要ですが、Ethereum ノードには少なくとも 4 コアの CPU と 16G のメモリのみが必要です。

BSC チームはこれらの問題を以前から認識しており、NodeReal と協力して Parallel EVM テクノロジーの開発にも取り組んでいます。この方法でのみ、各ブロックで処理できるトランザクションの数をさらに増やし、より多くのトランザクションを並行して実行できるようにし、TPS 上限を上げることができます。

並列処理: シングルコア CPU からマルチコア CPU へのアップグレードだけではありません

ほとんどのブロックチェーンシステムでは、トランザクションは完全に順次実行されます。シングルコアCPUと考えることができます。次の計算は、現在の計算が完了した後にのみ実行できます。この方法は遅いですが、シンプルでシステムの複雑さが少ないという利点があります。

しかし、将来ブロックチェーンシステムがインターネットレベルのユーザーにアクセスする必要がある場合、シングルコアCPUでは明らかに不十分になります。そのため、マルチコア CPU を搭載した並列化仮想マシンにアップグレードすることで、複数のトランザクションを同時に処理できるようになり、スループットが向上します。しかし、エンジニアリングの実装には多くの課題があります。たとえば、同時に処理されている 2 つのトランザクションが同じスマートコントラクトにデータを書き込む場合はどうすればよいでしょうか?この矛盾を解決するには、新しいメカニズムを設計する必要があります。完全に無関係な他のスマートコントラクトを並列実行する場合には、並列処理スレッドの数に応じてスループットを大規模に増加できます。

さらに、Parallel EVM は並列機能を向上させるだけでなく、シングルスレッド実行効率も最適化します。 Monad の CEO である Keone Hon 氏は、「(EVM の) 本当のボトルネックは、処理中に状態を頻繁に読み書きすることです」と述べ、並列実行はロードマップの一部に過ぎず、Monad のより大きな使命は EVM を中心に据えて、それを可能な限り効率的にすることだと述べました。

したがって、Parallel EVM の文字通りの意味は「並列化」のみを表しますが、実際には EVM の各コンポーネントのパフォーマンスを特別に最適化するため、その取り組みは EVM 標準のパフォーマンス限界を表す可能性があります。

EVM は Solidity と同じではありません

スマートコントラクトの作成は、ほとんどのブロックチェーン開発者にとって不可欠なスキルです。エンジニアは、ビジネスニーズに基づいて、Solidity またはスマートコントラクトの他の高水準言語で対応するロジック実装を記述できます。ただし、EVM は Solidity のロジックを直接理解することはできません。仮想マシンで実行するには、何らかの「翻訳」を経て、マシンが理解できる低レベル言語 (オペコードオペレーションコード / バイトコードバイトコード) に変換 (コンパイル) する必要があります。成熟したツールが実装されているため、Solidity 開発者はこの変換プロセスを理解する必要はありません。

結局は「翻訳」なので、多少のオーバーヘッドは発生します。低レベルコードの経験があるエンジニアであれば、オペコードを直接使用してSolidityでプログラムロジックを記述することができ、最高の効率を実現できます。つまり、ユーザーは取引時にガスを節約できます。たとえば、Opensea が立ち上げた Seaport プロトコルは、スマートコントラクトでインラインアセンブリを広範に使用して、ユーザーのガス費用を最小限に抑えます。

したがって、Parallel EVM が最終的に実現されれば、並列化機能をもたらすだけでなく、EVM スタック全体のパフォーマンスも最適化されます。通常のアプリケーション開発者は、少しのガスを節約するためだけに最適化に多くの労力を費やす必要はありません。基盤となる仮想マシンは、これらの違いを解消できるほど強力だからです。

EVM のパフォーマンスはさまざまであり、「標準」は「エンジニアリングの実践」と同じではありません

「仮想マシン」は「実行層」とも呼ばれ、スマートコントラクトがオペコードにコンパイルされた後に最終的に計算され、処理されるエンジンです。 Ethereum Virtual Machine (EVM) によって定義された「バイトコード」は現在、業界標準となっています。イーサリアムに基づく第 2 層ネットワークであっても、他の独立したパブリックチェーンであっても、まず EVM 標準と直接かつ完全に互換性を持つことを望んでいます。開発者はスマートコントラクトを一度記述して複数のネットワークに展開できるため、コスト効率が非常に高くなります。

したがって、EVM の「バイトコード」標準と完全に互換性がある限り、EVM と呼ぶことができますが、実装方法は大きく異なる場合があります。たとえば、Ethereum クライアント Geth は、Go 言語を使用して EVM 標準を実装します。ただし、Ethereum Foundation のエグゼクティブリサーチチームである Ipsilon は、C++ で開発された EVM の独立した実装を維持しています。他の Ethereum クライアントは、このライブラリを直接呼び出して 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、Ethereum レイヤー 2 のような軍拡競争のようなものです。テクノロジ間には微妙な違いがありますが (オープンソースです)、より重要なのは、エコシステムの独自性をどのように構築するかです。

並列 EVM の技術的な難しさ

順次実行されるトランザクションの場合、ボトルネックとなるのは CPU と、ステータスの読み取りおよび書き込みのプロセスです。しかし、この方法の利点は、非常にシンプルで、間違いがなく、すべてのタスクを段階的に完了できることです。並列実行される仮想マシンの場合、状態の競合が発生する可能性があるため、この判断部分は実行前または実行後に追加する必要があります。

簡単な例としては、仮想マシンが 4 つのスレッドの並列実行をサポートし、各スレッドが同時にトランザクションを処理できる場合、これらの 4 つのトランザクションがすべて Uniswap 上の同じトランザクションプール内にあると、各トランザクションがこのトランザクションプールのトランザクション価格に影響を与えるため、並列で計算することはできません。しかし、これら 4 つのスレッドが同時にまったく無関係な 4 つの処理を実行している場合は、問題はありません。

これには、さまざまなチームの設計とエンジニアリングの実装が含まれますが、少なくとも、並列実行後に競合を検出し、競合が発生した場合に再実行するためのモジュールが必要であることを確認する必要があります。もちろん、競合する可能性のあるトランザクションを事前に予測して選別できれば、仮想マシン全体の並列効率も向上できます。

Parallel EVM 仮想マシンのエンジニアリング実装の違いに加えて、各チームは通常、状態データベースの読み取りおよび書き込みパフォーマンスを再設計して強化し、Monad が設計した MonadDb や MonadBFT など、それに合わせたコンセンサスアルゴリズムを設計します。

課題

Parallel EVM には、長期的なエンジニアリング価値が Ethereum によって獲得されるかどうかという 2 つの課題が考えられます。ノードの集中化。

各チームはまだ Parallel EVM テクノロジの開発とテストの段階にあるため、現在の堀の 1 つであるすべてのエンジニアリングの詳細をオープンソース化することを選択したチームはありません。ただし、テストネットワークとメインネットワークに参加した後、これらのプロジェクトファイルは公開され、Ethereum やその他のパブリックチェーンに吸収される可能性もあります。したがって、その時点で、生態建設をより迅速に進め、より多くの生態堀を築く必要があります。

しかし、この問題はそれほど深刻ではありません。一方、暗号通貨開発者にとっては、より多くのオープンソースライセンスの選択肢が生まれました（コードの公開は許可されているものの、商用プロジェクトへのフォークは許可されていない Uniswap のライセンスなど）。一方、Monadの位置づけはEthereumとは異なります。将来、イーサリアムがシングルスロットファイナリティ（SSF）を実現できたとしても、トランザクションのファイナリティは少なくとも12秒であり、高頻度のアプリケーションシナリオには到底不十分です。

もう 1 つの課題は、すべての高性能パブリックチェーンに共通しており、ユーザーの基本的な許可なしおよび信頼なしの要件を満たすために、より多くのノードを展開する方法、つまり分散化です。おそらく、「TPS をノードのハードウェア要件で割った値」などのいくつかの指標を定量化することで、特定のハードウェア要件の基準の下でどのパブリックチェーン/クライアントの TPS がより高いかを比較するための制御変数を実現できます。結局のところ、ノードのハードウェア要件が低いほど、ノードの数を増やすことができます。

次に、さまざまな Parallel EVM プロジェクトの進捗状況を引き続き追跡し、それらのテクノロジと違いについて詳しく説明します。