しかし、いまだにニッチな話題であるため、多くの研究機関の年間サマリーやトレンド予測を見ても、パラレルEVMについては触れられていません。パラレルEVMは言及されておらず、これはまだ大規模なコンセンサスに達していない新しい概念です。コンセンサス・アルゴリズムやDAと同様、純粋に技術的なものなので、注目している人の数はさらに少ない。
Rethはまた、Erigonチームのメンバーによって、Akulaのオープンソースコードを盗用していると非難されました。Georgiosは、Rethは他のクライアントのフォークでもなければ、他のクライアントのコードでもないが、確かにGeth、Erigon、Akulaから影響を受け、インスパイアされていると回答した。(https://thedefiant.io/paradigm-accused-copying-code)
もう1つの中心的参加者は、ジャンプ・トレーディングとジャンプ・キャピタルだ。 Monadの創設者はジャンプ・トレーディング出身で、高頻度取引の経験が豊富だ。Seiの投資家にはジャンプ・キャピタルが含まれ、ジャンプはソラーナのエコシステムに深く関わってきた。ジャンプはまた、インフラやプロジェクトなど、ソラーナのエコシステムにも深く関わっている。
Monadの初期投資家であるDragonflyもまた、関連トラックに注力しており、シャーディング技術に注力するNEARや、Aptos、Avalanche、Nervosといったパブリックチェーンに投資している。
コンセンサスアルゴリズムのアップグレードだけでは不十分で、最終的には実行レイヤー
実行レイヤーは、ここ数回のパブリックチェーン戦争では軽視されてきた分野であり、ソラナ、アバランチ、EOSなど、コンセンサスアルゴリズムの革新についてほぼ独占的に語られてきました。アバランチ、EOSなど。彼らは実行レイヤーに多くのイノベーションを持っていますが、コミュニティは彼らが使用したコンセンサスアルゴリズムをより多く覚えており、コミュニティ全体として、これらの高性能なパブリックチェーンはコンセンサスアルゴリズムのイノベーションからそのパフォーマンスを得ていると仮定しています。
しかし、そうではありません。高性能のパブリックチェーンを望むなら、コンセンサスアルゴリズムと実行レイヤーは補完的である必要があります。EVMをベースとし、コンセンサスアルゴリズムだけを改良したパブリックチェーンでは、パフォーマンスを向上させるために、より強力なノードが必要となる。例えば、BSCはブロックが処理できるガス量を2000TPSに制限しているが、これはEtherChannel.Polygon 理論的には1000TPSに達することができますが、これは通常数十から数百です。
BSCアーカイブノード少なくとも16コアのCPUと128GのRAMが必要Ether ノード少なくとも 4 コア CPU と 16G の RAM だけが必要です。
BSCチームはこれらの問題を長い間認識しており、NodeReal パラレルEVMテクノロジーで共同運営しています。これは、ブロックごとに処理できるトランザクション数をさらに増やす唯一の方法であり、より多くのトランザクションを並行して実行し、TPSの上限を増やすことができます。
並列:シングルコアCPUからマルチコアCPUへのアップグレードだけではない
ほとんどのブロックチェーンシステムでは、トランザクションはフルシーケンスで実行されます。これはシングルコアCPUと考えることができ、次の計算が行われる前に現在の計算が完了します。次の計算が行われる前に現在の計算が完了します。この方法は遅いですが、シンプルでシステムの複雑性が低いという利点があります。
しかし、将来的にブロックチェーンシステムがインターネットレベルのユーザー規模にアクセスする必要がある場合、シングルコアCPUでは間違いなく不十分です。そこで、マルチコアCPUを搭載した並列化仮想マシンにアップグレードすることで、複数のトランザクションを同時に処理できるようになり、スループットが向上する。例えば、同時に処理される2つのトランザクションが同じスマートコントラクトにデータを書き込む場合はどうなるのか?この矛盾を解決するためには、新しいメカニズムを設計する必要がある。また、全く関係のない他のスマートコントラクトの並列実行については、並列処理されるスレッド数に応じてスループットをスケールアップすることが可能だろう。
さらに、パラレルEVMは並列性を向上させるだけでなく、シングルスレッド実行の効率も最適化します。 Monad CEOのKeone Hon は、「....(EVMの)本当のボトルネックは、物事を処理する際の状態の頻繁な読み書きにある...」。彼はまた、並列実行はロードマップの一部に過ぎず、Monadのより大きな使命は、EVMをその周辺で可能な限り効率的にすることだと述べた。
つまり、Parallel EVMは、文字通り「並列化」を意味するだけですが、実際にはEVMのさまざまなコンポーネントのパフォーマンスを最適化することに特化しているため、その取り組みはEVM標準のパフォーマンスの限界を表している可能性が高いのです。
EVMはSolidityと同じではありません
スマートコントラクトを書くことは、ほとんどのブロックチェーン開発者にとって不可欠なスキルです。エンジニアは、ビジネス要件に基づいて、スマートコントラクトのロジック実装を Solidity やその他の高レベル言語で書くことができます。しかし、EVMはSolidityのロジックを直接読むことはできず、仮想マシンで実行する前に、マシンが理解できる低レベル言語(オペコード/バイトコード)に翻訳(コンパイル)する必要がある。そして、この翻訳プロセスは、Solidityの開発者が理解する必要はありません。
結局のところ、「翻訳」なので、多少のオーバーヘッドはあります。例えば、OpenseaのSeaportプロトコルは、スマートコントラクトでインラインアセンブリを多用し、ユーザーのガス消費を最小限に抑えています。
つまり、パラレルEVMが最終的に実装されれば、並列化能力をもたらすだけでなく、EVMスタック全体のパフォーマンスも最適化されます。一般的なアプリ開発者は、わずかなガスを節約するためだけに、膨大な手間をかけて最適化する必要はないでしょう。
EVMのパフォーマンスはさまざまであり、「標準」は「エンジニアリングプラクティス」と同じではありません
「実行レイヤー」とも呼ばれる「仮想マシン」は、スマートコントラクトがオペコードにコンパイルされると、最終的に計算され処理されるエンジンです。イーサネット・バーチャルマシン(EVM)によって定義された「バイトコード」は現在、業界標準となっており、イーサネットベースの第2層ネットワークも、その他の独立したパブリックチェーンも、まずEVM標準と直接かつ完全に互換性があることを好むため、開発者はスマートコントラクトを一度書けば、複数のネットワークに展開することができ、非常に費用対効果が高い。
つまり、EVMの「バイトコード」標準に完全に準拠している限り、EVMと呼ぶことができますが、その実装方法は大きく異なります。例えば、EVM標準はGo言語のイーサネットクライアントGethに実装されている。しかし、Ipsilon イーサネット財団の実行レイヤ研究チームであるIpsilonは、C++によるEVMのスタンドアロン実装を維持しており、他のEtherClientクライアントから直接呼び出してEVMとして実行することができます。
例えば、工業的に生産される製品の多くには、工場で販売する前にコロニー数が特定の値以下である必要がある特定の製品のような、独自の国際標準があります。基準 "である。しかし、この工場基準をどのように満たすか、各工場は何十種類もの滅菌方法から選択することができ、工場によっては「実践」であるこの要件を満たすために、より費用対効果の高い方法を見つけることができる。
evmone これの実装があるので、他の実装もできます。実装することもできます。つまり、このEVMの例では、EVMの基準は「バイトコード」の基本的な操作方法(例えば、足し算、引き算、掛け算などの最も基本的な演算をサポートする)を定義することであり、各バイトコードは、定義された入力を持つとき、定義された出力を持ちます。この標準を満たすことになると、実装(プラクティス)は千差万別で、カスタマイズの余地やエンジニアリングの最適化の可能性もあります。
パラレル EVM の類似点と相違点
パラレル EVM トラックには、最もホットな Monad に加えて、 パラレル EVM があります。Sei、MegaETH、Polygon、Neon EVM、BSC および Paradigm の Reth クライアントも並列化を実装しようとしています。
位置づけから言えば、Monad、Sei、Polygon、BSCはすべてレイヤー1のブロックチェーンで、MegaETHはおそらくレイヤー2、Neon EVMはソラナネットワークをベースにしています。加えて、Rethはオープンソースのクライアントであり、MegaETHはRethのエンジニアリングの一部に基づいて開発が続けられる。
もちろん、これらのチーム間にはまだ競争があり、技術的な詳細やエンジニアリング文書のすべてを完全に開示しているわけではないので、より多くの比較はそれらが公開されるまで待たなければならない。もしかしたら、BTCレイヤー2、Restaking、Etherレイヤー2のような軍拡競争のようなもので、技術(とオープンソース)の微妙な違いにもかかわらず、生態学的な独自性を構築することがより重要なのかもしれません。
並列EVMの技術的な難しさ
逐次的に実行されるトランザクションの場合、ボトルネックはCPUと状態の読み書きのプロセスです。しかし、このアプローチの利点は、エラーが発生しないほどシンプルで、すべてのトランザクションが逐次的に完了まで実行されることです。並列に実行されるVMの場合、ステートの競合が発生する可能性があるため、実行前または実行後にこの判定部分を追加する必要があります。
単純な例として、仮想マシンが4つのスレッドの並列実行をサポートし、各スレッドが同時に1つのトランザクションを処理できる場合、4つのトランザクションがすべてUniswap上の同じトランザクションプールである場合、各トランザクションがプールのトランザクション価格に影響を与えるからである。しかし、これらの4つのスレッドが同時に4つの全く関係のないことに取り組んでいるのであれば、問題はない。
これには、さまざまなチームが実装を設計し、エンジニアリングする必要がありますが、少なくとも私たちができることは、並列実行後に競合を検出し、競合が発生した場合に再実行するモジュールがあることを確認することです。もちろん、競合する可能性のあるトランザクションを事前に予測し、スクリーニングすることができれば、VM全体の並列効率を高めることもできます。
VMとしての並列EVMのエンジニアリング実装の違いに加えて、チームは通常、Monadによって設計されたMonadDbやMonadBFTなどのコンセンサス アルゴリズムを使用して、ステートフル データベースの読み取り/書き込みパフォーマンスを再設計し、強化します。
課題
パラレルEVMには2つの課題が考えられます。
パラレルEVM技術のチームはまだ開発とテストの段階にあるため、エンジニアリングの詳細をすべてオープンソースにすることを選択したチームはまだありません。しかし、テスト・ネットワークやメイン・ネットワークに入ると、これらのエンジニアリング・ファイルは公開され、イーサや他のパブリック・チェーンに吸収される可能性もある。だから、その時点では、より早くエコロジー建設を進め、より多くのエコロジーレベルの堀を構築する必要があるだろう。
しかし、Crypto開発者が利用できるオープンソースライセンスは増えており(Uniswapのように、コードの公開は可能だが商用プロジェクトへのフォークを許可していない)、Monadの位置づけはEtherのそれとは異なるため、問題はそれほど深刻ではない。一方、モナドの位置づけはすでにイーサとは異なっている。イーサが将来的にシングルスロット最終性(SSF)を達成できたとしても、トランザクションの最終性は少なくとも12秒であり、高頻度のシナリオには十分ではない。
すべての高性能パブリックチェーンに共通するもう1つの課題は、基本的な許可なし、信頼なしのユーザー要件である分散化を満たすために、いかに多くのノードを配置するかということです。おそらくこれは、「TPSをノードのハードウェア要件で割ったもの」などのメトリクスで定量化できるはずで、特定のハードウェア要件基準に対して、どのパブリック・チェーン/クライアントがより高いTPSを持つかを比較するための制御変数ができるはずだ。結局のところ、ノードのハードウェア要件が低ければ低いほど、ノード数は多くなる可能性が高いのです。
次回は、さまざまなパラレルEVMプロジェクトの進捗状況を追跡し、その技術と相違点についてさらに詳しく説明します。