MegaETHは本当にリアルタイムのブロックチェーンなのか？

この記事の大部分は、MegaETHのホワイトペーパーに関する私の個人的な考えである。この記事がどのようなものになるにせよ、そこから何か新しいことを学んでほしい。

MegaETHのウェブサイトは、メカニカルなウサギが描かれ、目立つ配色でクールだ。

MegaETHのウェブサイトは、目立つ配色で機械的なウサギが描かれていてクールです。

私はMegaETHのGithubを閲覧し、彼らがある種の実行レイヤーに取り組んでいることを知った。本当のところ、私はMegaETHについて十分に知らない。

私は、クールな人たちが見ているのと同じ技術を見ていることを確認するために、すべてを知る必要がある。

MegaETHのホワイトペーパーによると、EVM互換のリアルタイムブロックチェーンで、暗号の世界にWeb2のようなパフォーマンスをもたらすことを目指している。毎秒10万件以上のトランザクション、ミリ秒未満のブロック時間、1セントの取引手数料などの属性を提供することで、イーサリアムL2の体験を強化することを目指している。

彼らのホワイトペーパーは、暗号世界におけるL2の増加（以前の記事で取り上げたが、その数は50以上に上り、さらに多くのL2が「アクティブな開発」中である）とPMFの不足を強調している。

私は、L2の数が多すぎることが悪いことだとは思いません。

オッカムの剃刀によれば、VCは、次のL2（またはL1）王を作るチャンスがあることを実感し、これらのプロジェクトに投資することで満足感を得ている。どちらの言い分も正しいかもしれないが、どちらがより正しいかという結論は関係なく、現在のインフラ・エコシステムを客観的に見て、今あるものを活用するのがベストだ。

現在利用可能なL2の性能は高いですが、十分ではありません。MegaETHのホワイトペーパーによると、opBNBの（比較的）高い100 MGas/sでも、これは1秒あたり650のユニスワップ・トランザクションを意味するだけです。-最新の、あるいはweb2のインフラは、毎秒100万トランザクションが可能です。

暗号の利点は非中央集権的な性質とパーミッションレス決済を可能にすることにありますが、それでもかなり遅いことは分かっています。Blizzardのようなゲーム開発者がオーバーウォッチをチェーンに持ち込もうとしても、それはできません。Web2ゲームが自然に提供するリアルタイムのPvPやその他の機能を提供するには、はるかに高いクリックスルー率が必要です。

L2の泥沼に対するMegaETHの解決策の1つは、セキュリティと検閲への耐性をそれぞれイーサリアムとEigenDAに委ねることで、MegaETHをトレードオフなしで世界最高性能のL2に変えることです。

L1は通常、特殊化の余地がなく、同じタスクを実行する同型のノードを必要とします。この場合、特殊化とは、ソートや証明などのタスクを指します。L2は、異種ノードの使用を許可することでこの問題を回避し、タスクを分離してスケーラビリティを向上させたり、これらの負担の一部を軽減したりします。これは、AstriaやEspressoのような共有シーケンサーの人気の高まりや、SuccinctやAxiomのような特殊化されたzk証明サービスの台頭に見ることができる。

「リアルタイムのブロックチェーンを作成するには、既製のイーサリアム実行クライアントを使用し、シーケンサー・ハードウェアを追加するだけでは不十分です。例えば、私たちのパフォーマンス実験によると、512GB RAMを搭載した強力なサーバーを使用しても、Rethは最近のイーサブロックのリアルタイム同期セットアップで約1000 TPSしか達成できず、これは約100 MGas/sに相当します。strong>100MGas/sに相当します。"

MegaETHは、トランザクション実行をフルノードから抽象化することで、この分割を拡張し、「アクティブ」なシーケンサーのみを使用することで、典型的なトランザクション実行のコンセンサスオーバーヘッドを排除します。典型的なトランザクション実行のコンセンサスオーバーヘッドを排除するために、"アクティブ "なシーケンサーのみを使用したトランザクション実行。"ほとんどのフルノードは、p2pネットワークを介してこのシーケンサーから状態の差分を受け取り、ローカル状態を更新するために差分を直接適用する。注目すべきは、彼らはトランザクションを再実行しないことである。その代わりに、彼らは証明者（prover）が提供する証明を使って間接的にブロックを検証する。"

「速い」「安い」というコメントのほかは、メガテックについてあまり読んだことがない。だから、そのアーキテクチャを注意深く分析して、他のL2と比較してみようと思う。

MegaETHはEigenDAを使ってデータの可用性を処理している。ConduitのようなRollup-as-a-Service（RaaS：ロールアップ・アズ・ア・サービス）プラットフォームでは、ロールアップのデータ可用性プロバイダーとして、Celestia、EigenDA、あるいは（お好みで）Ethereumを選択することができます。この2つの違いはかなり技術的なものであり、まったく関連性があるわけではなく、どちらかを選ぶかどうかは何よりも共鳴に基づいているようです。

シーケンサーは、トランザクションを命令し、最終的に実行しますが、ブロック、ウィットネス、ステート差異の投稿も担当します。L2 コンテキストでは、証人はシーケンサー・ブロックを検証するために証明者によって使用される追加データです。

状態差はブロックチェーンの状態に対する変更であり、基本的にチェーン上で起こることであれば何でもあり得る - ブロックチェーンはその状態に追加される新しい情報を継続的に追加し、検証するように機能する。トランザクションを再実行することなく、そのトランザクションを確認することを可能にすることです。

プローバは、ブロックの内容を検証するための暗号証明を計算する特別なハードウェアで構成される。また、ノードが重複実行を避けることもできます。ゼロ知識証明と不正証明（あるいはオプティミスティック証明？）がありますが、その違いは今は重要ではありません。

これらすべてをまとめるのが、証明者、シーケンサー、EigenDAの間のアグリゲーターのような役割を果たし、（うまくいけば）MegaETHマジックを現実のものにするComplete Node Networkの仕事です。

MegaETHの設計は、EVMに対する根本的な誤解に基づいている。もしEVMでないなら、何が原因なのでしょうか？

2, 現在のスケーラビリティの問題

性能のボトルネックにつながるEVMの3つの主な非効率性は、並列実行の欠如、インタープリターのオーバーヘッド、高い状態アクセスレイテンシです。.

Etherの正確なRAMが100GBであるのに対し、MegaETHはRAMが豊富なため、ブロックチェーン全体の状態を保存することができます。

SSDの読み取りレイテンシについてはよく知りませんが、おそらくいくつかのオペコードは他のものよりも密度が高く、問題にもっとRAMを投資すれば抽象化できます。それでも規模が大きくなればうまくいくのでしょうか？よくわからないが、この記事の目的上、事実として受け止めておこう。チェーンがスループット、トランザクション・コスト、レイテンシーを同時に決定できるのか、私はまだ懐疑的だが、私は積極的に学ぼうとしている。

もうひとつ言っておきたいのは、あまり批判的になりたくないということです。

私の考えは、あるプロトコルを他のプロトコルよりも支持したり、あるいは最初から同じ重みを与えたりすることは決してしないということです。

EVMの並列化の流れはご存じかと思いますが、問題があると言われています。Block-STM アルゴリズムの EVM への移植は進んでいますが、「実稼働時に達成可能な実際の高速化は、ワークロードで利用可能な並列性によって本質的に制限される」と言われています。これは、たとえ並列EVMがリリースされ、最終的にメインネットワーク上のEVMチェーンに導入されたとしても、ほとんどのトランザクションは並列に実行する必要がないかもしれないという基本的な現実によって、技術が制限されることを意味します。

トランザクションBがトランザクションAの結果に依存している場合、同時に2つのトランザクションを実行することはできません。このケースのように、ブロックトランザクションの50%が相互に依存している場合、並列実行は主張されているほど大きな改善にはなりません。これは少し単純化しすぎではあるが（そして少し間違っているかもしれない）、私はこれが正鵠を射ていると思う。

revmとネイティブ実行の間のギャップは非常に明確で、特にrevmはスタンドアロンのVM環境として価値があるには、まだ1-2 OOMsが遅すぎます。また、revmの使用を正当化できるほど、計算集約的な契約は多くないことも判明した。たとえば、履歴の同期中にオペコードごとに費やされた時間を分析したところ、revm の時間の約 50% が「ホスト 」と「システム 」に費やされていることがわかりました。strong>と "system "のオペコードに費やされていることがわかりました。"

状態の同期となると、MegaETHはさらに多くの問題を見つける。状態の同期とは、簡単に言うと、シーケンサーのアクティビティとフルノードを同期させるプロセスで、MegaETHのようなプロジェクトの帯域幅をすぐに消費してしまうタスクです。1秒間に100,000ERC20の転送を同期させることを目標とする場合、約152.6Mbpsの帯域幅を消費することになる。この152.6MbpsはMegaETHの予測（または性能）を超えると言われており、本質的に不可能なタスクを導入することになる。

これは単純なトークン転送のみを考慮したもので、トランザクションがより複雑な場合、より高い消費量になる可能性も無視しています。MegaETHは、Uniswapトランザクションは8つのストレージスロットを変更する（一方、ERC20転送は3つのストレージスロットしか変更しない）と書いている。

100kTPSの高性能ブロックチェーンを実現するためのもう1つの問題は、ライトクライアントへの保管証明の送信を管理するタスクであるチェーンステートルートの更新を解決することにあります。特化したノードを使っても、フルノードはステートルートを維持するためにネットワークのシーケンサーノードを使う必要がある。1秒間に100,000のERC20の転送を同期させるという上記の問題の例として、これは1秒間に300,000の鍵を更新するコストが発生することになります。

EtherはMPT（Merkle Patricia Trie: Merkle Prefix Tree）データ構造を使用して、各ブロックの後の状態を計算します。1秒間に30万個のキーを更新するためには、Etherは「キャッシュされていないデータベースの読み取りを600万回変換」する必要がある。これは、現在の消費者向けグレードのSSDでは不可能なことであり、MegaETHの書き込み、そしてこの見積もりには書き込み（またはUniswapトランザクションのようなオンチェーン・トランザクションの見積もり）さえ含まれていないため、この挑戦はよりSisypheanな挑戦となっている。

ブロックガスの限界に達するという問題もある。ブロックチェーンの速度は、ブロックチェーンのセキュリティと信頼性を高めるために設計された自らに課した障壁であるブロックガスの限界によって実際に制限されている。"ブロックガス制限を設定する際の経験則は、この制限内のどのブロックもブロック時間内に安全に処理できるようにすることが重要であるということです。"ホワイトペーパーでは、ブロックガス制限は、ノードが最小限のハードウェア要件を満たしていることを前提に、確実にペースを維持できるようにする「スロットリング機構」であると説明している。

また、ブロックガス制限は最悪のシナリオから保護するための保守的な選択であり、最新のブロックチェーンアーキテクチャがスケーラビリティよりもセキュリティを重視するもう一つの例だと言う人もいます。スケーラビリティがセキュリティよりも重要であるという考えは、ブロックチェーン間で毎日どれだけの資金が移動しているか、そしてスケーラビリティをわずかに高めるためにその資金が失われ、核の冬につながったらどうなるかを考えると、破綻してしまいます。

ブロックチェーンは、高品質な消費者向けアプリの誘致には向いていないかもしれないが、ライセンスを必要としないピアツーピアの決済には非常に優れている。誰もそれを台無しにしたくはない。

それから、並列EVMの速度は作業負荷に依存し、ブロックチェーンの機能を最小化することで過度に「加速」された「長い依存関係チェーン」によって性能がボトルネックになるという指摘もある。ボトルネックこの問題を解決するには、多次元ガス・プライシング（MegaETHはSolanaのローカル料金市場を指す）を導入するしかないが、これはまだ実装が難しい。専用のEIPがあるのか、そのようなEIPがEVMでどのように機能するのかはわからないが、技術的にはこれが解決策なのだろう。

最後に、ユーザーはシーケンサー・ノードと直接対話することはありませんし、ほとんどのユーザーは自宅でフルノードを実行することはありません。その結果、ブロックチェーンの実際のユーザーエクスペリエンスは、RPCノードやインデクサなど、その基礎となるインフラに大きく依存します。RPCノードがピーク時に大量の読み取り要求を効率的に処理できなかったり、トランザクションを素早くシーケンサー・ノードに伝搬できなかったり、インデクサがチェーンに追いつくのに十分な速さでアプリケーション・ビューを更新できなかったりするのでは、リアルタイム・ブロックチェーンがどれだけ高速に実行されても意味がありません。"

冗長すぎるかもしれませんが、非常に重要です。私たちは皆、Infura、Alchemy、QuickNodeなどに依存しており、それらはおそらく私たちのトランザクションをすべてサポートするインフラを運営しています。この依存関係の最も単純な説明は、経験から来るものだ。あるL2エアドロップの後、最初の2-3時間以内にエアドロップを要求しようとしたことがあれば、RPCがこの混雑を管理するのがどれほど難しいか理解できるでしょう。

3、結論

以上、MegaETHのようなプロジェクトが到達したい高みに到達するためには、飛び越えなければならないハードルがたくさんあることをお伝えしました。ある投稿によると、異種ブロックチェーンアーキテクチャと超最適化されたEVM実行環境を使用することで、高性能な開発を実現できたという。"今日、MegaETHは高性能なリアルタイム開発ネットワークを持ち、ハードウェアによってのみ制限される最速のブロックチェーンになるべく着実に前進している。"

MegaETHのGithubには、EVMバイトコード → ネイティブコードコンパイラ、大メモリシーケンサノード専用実行エンジン、および以下を含むがこれらに限定されない、主な改善点のいくつかが記載されている。EVMバイトコード/ネイティブコード・コンパイラーは現在evmoneとして利用可能で、そのコアな働きを知るほどコーディングに精通しているわけではないが、私はそれを理解するために最善を尽くした。

evmoneはEVMのC++展開で、EVMC APIを取得し、イーサネット・クライアント用の実行可能モジュールに変換します。そのデュアル・インタプリタ・アプローチ(ベースラインとアドバンスド)やintxとethashライブラリなど、私が理解していない他のいくつかの機能について言及しています。要するに、evmoneは（より高速なスマートコントラクトの実行による）より高速なトランザクション処理、より高い開発柔軟性、より高いスケーラビリティ（異なるEVMデプロイがブロックごとにより多くのトランザクションを処理できると仮定して）の機会を提供します。

他にもいくつかのコードベースがありますが、そのほとんどはかなり標準的で、MegaETH（reth、geth）とは特に関係ありません。MegaETHの次はどうなるのか？有効な拡張コードを実装することは本当に可能なのか？その実現にはどれくらいの時間がかかるのでしょうか？

ブロックチェーンユーザーとして、私はこれがすべて可能かどうかを目撃することに興奮している。

メインネットの取引手数料にお金を使いすぎました。

この記事の内容は主にアーキテクチャの改善とスケーラビリティを中心としていますが、ロールアップAとロールアップBの経験を一致させるためには、内部ロールアップがモビリティとクロスチェーンツールを共有する必要性がまだあります。我々はまだそこに到達していないが、おそらく2037年までには、誰もが我々がいかにスケーラビリティの問題を「修正」することに執着していたかを思い出しながら座っていることだろう。