MegaETH = 最初のリアルタイムブロックチェーン

## はじめに

**MegaETH**は、従来のWeb2レベルのリアルタイムパフォーマンスを初めて暗号世界に持ち込むEVM互換のブロックチェーンです。MegaLabsの目標は、EthereumのL2のパフォーマンスをハードウェアの限界まで押し上げ、ブロックチェーンと従来のクラウドコンピューティングサーバーとのギャップを埋めることです。

![](https://storage.googleapis.com/zenn-user-upload/68f7c568f048-20241217.png)

MegaETHは、高トランザクションスループット、豊富な計算能力、そして最もユニークな点として、重負荷時でもミリ秒単位の応答時間を提供します。これにより、開発者は制約なく最も要求の厳しいアプリケーションを構築・構成することが可能となります。

## なぜ新たなブロックチェーンが必要なのか？

ブロックチェーンフレームワークの進化により、新しいチェーン（L1およびL2）の作成障壁が大幅に低下しました。その結果、最近では50以上のL2プロジェクトが存在しています。しかし、単に新しいチェーンを作成するだけでは、ブロックチェーンのスケーラビリティ問題は解決されません。各チェーンは、それがホストするdAppsに対して依然として大きな制約を課しています。

例えば、以下の表は2024年時点での主要なEVMチェーンのガスパラメータを比較したものです（出典：Paradigm）。

![](https://storage.googleapis.com/zenn-user-upload/457e88d985b6-20241217.png)

この表から明らかなように、既存のEVMチェーンは以下の点で大きな制約を抱えています。

1. **低トランザクションスループット**: 例えば、opBNBは100 MGas/sと高いガスレートを誇りますが、これは現代のWeb2サーバーの能力と比較すると依然として低いです。具体的には、100 MGas/sは約650のUniswapスワップまたは3,700のERC-20転送に相当します。一方、現代のデータベースサーバーはTPC-Cベンチマークで既に1,000,000以上のトランザクションを処理しています。

2. **限られた計算能力**: 複雑なアプリケーションをオンチェーンで実行することが困難です。例えば、単純なEVMコントラクトで10^8番目のフィボナッチ数を計算するには約55秒を要し、これはopBNBチェーン全体を使い切る計算です。対照的に、C言語で書かれた同様のプログラムは30ミリ秒で完了します。

3. **長いブロックタイム**: 高頻度の更新や迅速なフィードバックループを必要とするアプリケーションは、現在のブロックタイムでは実現が困難です。例えば、Autonomous Worldのような高度なオンチェーンdAppは、リアルタイムの戦闘や物理シミュレーションを行うために、100ミリ秒未満のブロック間隔が必要です。

しかし、これらの制約はEVMチェーンにとって克服不可能ではありません。技術的な進歩により、リアルタイムブロックチェーンを構築し、これらの可能性を解き放つ時が来ています。リアルタイムブロックチェーンとは、トランザクションが到着すると即座に処理され、結果の更新がリアルタイムで公開されるブロックチェーンを指します。さらに、ピーク時のユーザー需要にも耐えうる高トランザクションスループットと豊富な計算能力をサポートする必要があります。

## L2：パフォーマンス重視の設計へのパラダイムシフト

ブロックチェーンのスケーラビリティは長年にわたって研究されてきました。では、どのようにして現状の技術水準をはるかに上回るパフォーマンス向上を突然達成できるのでしょうか？答えは意外にも単純です。セキュリティと検閲耐性をEthereumやEigenDAのようなベースレイヤーに委任することで、L2は積極的なパフォーマンス最適化を実現するための広大な設計空間を探索できるのです。

### ブロックチェーンの基本構造

現在のブロックチェーンは、主に以下の2つの基本コンポーネントで構成されています：

1. **コンセンサス**: ユーザートランザクションの順序を決定します。
2. **実行**: 決定された順序でトランザクションを処理し、ブロックチェーンの状態を更新します。

多くのL1ブロックチェーンでは、各ノードが特定のタスクに特化せず、同一の作業を行います。これは、パフォーマンスと分散化の間に根本的なトレードオフをもたらします。各L1は、ノードを運用するためのハードウェア要件をどの程度にするかを慎重に決定しなければなりません。

![](https://storage.googleapis.com/zenn-user-upload/9e998ebdf75d-20241217.png)

### L2のアプローチ

L2は、ノードのハードウェア要件を一律にする必要がないため、設計において新たなパラダイムを提供します。L2ブロックチェーンは本質的に異種であり、異なるL2ノードが特定のタスクをより効率的に実行するように専門化されています。例えば、ほとんどのL2は、トランザクションの順序を決定する専用のシーケンサーノードを使用しています。

### MegaETHのアーキテクチャ

MegaETHは、L2の概念をさらに進化させ、トランザクションの実行をフルノードから分離することで、性能を最大限に引き出しています。具体的には、MegaETHには以下の3つの主要な役割があります：

1. **シーケンサー（Sequencers）**  
   ユーザートランザクションの順序付けと実行を担当します。MegaETHでは、常に1つのアクティブなシーケンサーが存在し、通常の実行中のコンセンサスオーバーヘッドを排除します。

2. **プローバー（Provers）**  
   ブロックを非同期かつ順不同で検証します。プローバーは、stateless validation scheme を用いてブロックを検証し、フルノードが状態の差分を適用する際に証明を提供します。

3. **フルノード（Full Nodes）**  
   シーケンサーから状態の差分を受信し、ローカル状態を更新します。フルノードはトランザクションを再実行するのではなく、プローバーが提供する証明を用いてブロックを間接的に検証します。これにより、計算コストを削減しつつ、信頼性を維持します。

### MegaETHのノード専門化

MegaETHでは、ノードの専門化を徹底することで、各ノードタイプごとに最適なハードウェア要件を設定できます。以下の表は、MegaETHの各ノードタイプに対する予測されるハードウェア要件を示しています。

| ノードタイプ     | CPU       | メモリ   | ネットワーク | ストレージ | 例VM（価格/時）              |
|------------------|-----------|----------|--------------|------------|------------------------------|
| シーケンサー     | 100コア   | 1-4 TB   | 10 Gbps      | SSD        | AWS r6a.48xlarge ($10)        |
| プローバー (OP)  | 1コア     | 0.5 GB   | 低速         | なし       | AWS t4g.nano ($0.004)         |
| フルノード       | 4-8コア   | 16 GB    | 100 Mbps     | SSD        | AWS Im4gn.xlarge ($0.4)       |

ノードの専門化により、シーケンサーノードは高性能なサーバー上で運用され、フルノードのコストはEthereumのL1ノードと比較しても競争力を持つものとなります。これにより、シーケンサーは20倍以上のコストがかかるものの、Solanaのバリデーターよりも5-10倍の性能を持ち、フルノードはEthereum L1ノードと同等のコストで運用可能です。

## リアルタイムブロックチェーンのエンジニアリング

ノードの専門化は強力な概念ですが、MegaETHの背後には単なる強力な中央シーケンサーがあるわけではありません。リアルタイムブロックチェーンの構築には、既存のEthereum実行クライアントを単に強力なハードウェアに置き換える以上の、複雑な研究とエンジニアリングが必要です。

### トランザクション実行

シーケンサーは、トランザクションの順序付けと実行を担当します。EVMは、EVMベースのL2のパフォーマンスが低いとしばしば非難されてきましたが、これは必ずしも真実ではありません。MegaETHのパフォーマンス測定によれば、revmは最近のEthereumブロックにおいて歴史同期設定で約14,000 TPSを達成しています。しかし、リアルタイムブロックチェーンにはまだ不足があります。伝統的なEVM実装には以下の3つの非効率が存在します。

1. **高い状態アクセス遅延**  
   MegaETHでは、シーケンサーノードに豊富なRAMを搭載し、全ブロックチェーン状態（現在約100GB）をメモリ内に保持することで、SSDからの読み取り遅延を排除し、状態アクセスを大幅に高速化しています。

2. **並列実行の欠如**  
   現在のEVM実装では、並列実行が十分に活用されておらず、依存関係の多いトランザクションがパフォーマンスを制約しています。MegaETHでは、これを克服するための新しい並列実行エンジンを開発しています。

3. **インタープリタオーバーヘッド**  
   EVMインタープリタは、ネイティブコードに比べて1-2オーダー遅れています。MegaETHでは、AOT/JITコンパイルを活用して、EVMの実行速度をネイティブに近づける取り組みを行っています。

#### 並列EVMの限界

Parallel EVM（並列EVM）は最近注目を集めており、多くのチームがMoveVMで実装されたBlock-STMアルゴリズムをEVMに移植しようとしています。しかし、実際のスピードアップはワークロードに依存し、MegaETHの測定では、最新のEthereumブロックにおける中央値の並列性は2未満です。ブロックを大きなバッチに人工的に結合しても、中央値の並列性は2.75にしかなりません。これは、現在のEthereumのワークロードでは長い依存チェーンが蔓延しているためです。これにより、Block-STMの利点は限定的となり、MegaETHではさらなる技術的な工夫が必要となります。

#### AOT/JITコンパイルの限界

AOT（Ahead-Of-Time）やJIT（Just-In-Time）コンパイルは、EVMの実行速度を向上させる手法として注目されています。例えば、revm、evm-mlir、IL-EVMなどのプロジェクトが競合しています。しかし、これらのプロジェクトは計算集約的なコントラクトに対しては有望な結果を示していますが、実際のプロダクション環境ではスピードアップが限定的です。ほとんどのコントラクトは計算集約的ではなく、歴史同期中のオペコードの約50％が「ホスト」および「システム」オペコードに費やされているため、コンパイルによるスピードアップの恩恵を受けにくいのです。これにより、プロダクション環境での最大スピードアップは2倍に制限されます。

### 状態同期

状態同期は、フルノードをシーケンサーに追いつかせるプロセスです。これは高性能ブロックチェーン設計において非常に挑戦的な側面ですが、しばしば見過ごされがちです。

#### 状態同期の課題

例えば、100,000 ERC-20転送を1秒間に同期する場合、必要な帯域幅は約152.6 Mbpsに達します。これは既存の帯域幅予算を超えるものであり、Uniswapスワップの場合は476.1 Mbpsにも達します。したがって、状態同期には19倍の圧縮率が必要となります。

さらに、インターネットプロバイダーは実際の持続可能な帯域幅を過大評価することが多く、同一ノード上のアプリケーションが帯域幅を共有する必要があります。また、新規フルノードがネットワークに参加する際には十分な余裕を確保する必要があります。ピアツーピアネットワークプロトコル自体もオーバーヘッドを生じさせるため、状態同期の帯域幅効率を高めることは容易ではありません。

### 状態ルートの更新

ほとんどのブロックチェーンは、Merkle Patricia Trie（MPT）のようなツリー構造の認証データ構造を使用して各ブロック後に状態ルートをコミットします。状態ルートの更新は依然として高コストであり、特にIO集約型のプロセスです。

#### MPTの更新プロセス

例えば、バイナリMPTの葉ノードを更新する場合、内部ノードも更新する必要があり、これにより読み取りおよび書き込みのIO操作が増加します。具体的には、バイナリMPTで1つのキー値ペアを更新するには、約68回の読み取り操作と34回の書き込み操作が必要となります。MegaETHでは、NOMT（Nested Ordered Merkle Tree）を用いてツリーノードのグループ化を行い、ディスクページあたりの読み取り操作数を削減していますが、実際の実装ではまだ目標のスループットに達していません。

### ブロックガスリミット

ブロックガスリミットは、ブロック内で消費できる最大ガス量を定義し、ブロックタイムとともにブロックチェーンの最大速度を制限します。これはセキュリティと信頼性を確保するために不可欠です。並列EVMやJITコンパイルのスピードアップがあっても、ガスモデルの再設計がなければブロックガスリミットを積極的に引き上げることはできません。

### サポートインフラストラクチャ

ユーザーは直接シーケンサーノードとやり取りするわけではなく、ほとんどのユーザーは自宅でフルノードを運用していません。ユーザー体験は、RPCノードやインデクサーなどのサポートインフラストラクチャに大きく依存します。これらのインフラが高負荷時に効率的に動作しなければ、リアルタイムブロックチェーンの速さは意味を持ちません。

![](https://storage.googleapis.com/zenn-user-upload/0d72ca7de21f-20241217.png)

## 原則に基づくスケーリングアプローチ

ブロックチェーンは多くの移動部分を持つ複雑なシステムであり、パフォーマンス向上には単一の技術だけでは不十分です。成功している高性能L1ブロックチェーン（例：Solana、Aptos）は、システム全体のほぼすべての側面で印象的なエンジニアリング努力を行っています。

MegaETHは、最初から包括的かつ原則に基づいた研究開発（R&D）アプローチを採用しています。これにより、ユーザーに実際の利益をもたらす問題の解決に常に焦点を当てることができます。具体的には、以下のような設計哲学を採用しています：

1. **計測してから構築する（Measure, then Build）**  
   深いパフォーマンス計測を行い、既存システムの実際の問題を特定します。その上で、同時に複数の問題を解決するための新しい技術を設計・実装します。

2. **ハードウェア限界に達する設計（Design to Reach Hardware Limits）**  
   既存システムの漸進的な改善ではなく、理論上の上限に近づくクリーンスレート設計を優先します。これにより、暗号インフラストラクチャのさらなるパフォーマンス向上の余地を極力残さず、業界全体が他の課題にリソースを集中できるようにします。

## リアルタイムパフォーマンスを数十億のユーザーに

リアルタイムブロックチェーンは、Web2サーバーとブロックチェーンの境界を曖昧にします。MegaETHにより、エンドユーザーは前例のないリアルタイムパフォーマンスを体験でき、開発者は制約なく最も野心的なアイデアを探求することができます。十年にわたる実験の末、ついにWeb2規模のアプリケーションをオンチェーンで実現することが可能となります。

## 参考資料

[MegaETH: Unveiling the First Real-Time Blockchain](https://megaeth.systems/research)


MegaETH = 最初のリアルタイムブロックチェーン