これは @megaeth_labs ホワイトペーパーの個人的な学習ノートの最初のバージョンです。興味があればご覧ください。イーサリアムはブロックチェーン革新の事実上のフロンティアとして非常に注目に値します。私の個人的なレベルに限界がありますので、間違いや漏れがあればご指摘ください。
1. 3 つの特徴と現在の制限ケース:
高いトランザクションスループット、高いスループット
最高の opBNB は 100MGas/s という非常に高いガス レートで際立っていますが、100MGas/s は 1 秒あたり 650 のユニスワップ スワップまたは 3700 の ERC20 転送に相当する Web2 サーバーの能力と比較すると、依然として非常に低いものです。秒 100 万を超えるトランザクションを実行できます。
豊富な計算能力、豊富な計算能力
複雑なアプリケーションはチェーンにアップロードできず、主にコンピューティング能力によって制限されます。EVM コントラクトを使用して n-フィボナッチ数を計算する場合、55 億の Gas が必要となり、55 秒かかる 100MGas/s の計算速度が必要になります。 opbnb チェーン全体の。従来、C 言語で書かれたプログラムには 30 ミリ秒しかかかりません。シングルコア CPU の速度が 1833 倍に向上
そして最もユニークなのは、高負荷下でもミリ秒レベルの応答時間です。
arb を除いて、他の主流の第 2 層ブロックチェーンでは、チェーンのステータスを更新するために 1 秒を超えるブロック生成時間が必要です。これは、高い更新レートと高速なフィードバック ループを必要とするアプリケーションには現実的ではありません。たとえば、チェーン上の自作ワールドやゲームでは 100 ミリ秒以内の応答時間が必要ですが、高頻度取引では注文またはキャンセルに 10 ミリ秒の応答時間が必要で、そうでないとこれらはいずれも達成できません。
2. パフォーマンスの限界を超えるには
現在のブロックチェーン アーキテクチャ (L1)
すべてのブロックチェーンは、コンセンサスと実行を含む 2 つの基本コンポーネントで構成されます。
コンセンサスによってユーザートランザクションの順序が決定され、実行は確立された順序でこれらのトランザクションを処理してブロックチェーンの状態を更新します。ほとんどの L1 ブロックチェーンでは、各ノードは特化することなく同じタスクを実行します。各ノードは分散プロトコルに参加し、合意に達した後、ローカルでトランザクションを実行します。各 L1 は、セキュリティや検閲耐性などのブロックチェーンの基本特性を損なうことなく、一般ユーザーがノードを操作するためのハードウェア要件をどこまで増やすことができるかを決定する必要があります。
したがって、フルノードの動作要件はセキュリティと検閲耐性に関連し、非常に重要です。
レイヤー 2 の新しいパラダイム
L2 ブロックチェーンの性質は異質であり、本質的に異なります。さまざまな L2 ノードは、特定のタスクをより効率的に実行するために特化されています。
megaETH はさらに一歩進んで、トランザクション実行タスクをフルノードから分離 (切断) します。具体的には、megaETHにはシーケンサー（シーケンサー）、証明者（認証者）、フルノード（フルノード）の3つの役割があります。
最初の鍵は強力な集中型ソーターです
シーケンサー: トランザクションの順序付けと実行を担当しますが、megaeth は、常にアクティブなシーケンサーが 1 つだけであるため、通常の実行時のコンセンサス オーバーヘッドが排除される点で異なります。ほとんどのフルノードは、この順序付け者から p2p ネットワーク経由で状態の差分を受け取り、その差分を直接適用してローカル状態を更新しますが、トランザクションは再実行せず、証明者が提供する証明を通じて間接的にブロックを検証します。上級ユーザー (ブリッジ オペレーターやマーケット メーカー) は、各トランザクションを実行してできるだけ早くファイナリティを達成することができますが、これにはシーケンサーに追いつくためにより高いハードウェア要件が必要です。最後に、証明者はステートレス検証スキームを使用して、ブロックを非同期かつ順不同で検証します。
ノードの特殊化は非常に重要です。ブロックの生成はより集中化されていますが、ブロックチェーンはより分散化されています。たとえば、シーケンサーにはハイエンドのサーバーが必要ですが、フル ノードに必要なサーバーは非常に安価です。
強力な集中サーバーに加えて、より複雑なエンジニアリング実装もあります
強力なサーバーのみに依存する場合、Reth は実験で 1000TPS しか達成できず、これは約 100MGas/s です。これは主に、各ブロックの MPT (イーサリアムで使用されるデータ構造) の更新の制限によるもので、これはより高速です。トランザクション自体の実行コストは 10 倍になります。
したがって、私たちは依然として多くの複雑な状況に直面しています。
3. メガETHの設計
測定してから構築し、最初に測定して実際の問題やパフォーマンスの制約を見つけてから、すべての問題を同時に解決する新しいシステムを設計します。
ハードウェアの限界に達するようにシステムを設計するよう努めますが、インクリメンタルな設計を好まず、理論上の限界に近い新しい設計を好みます。
以下は、設計プロセス中に遭遇するいくつかの課題と解決策です。
トランザクションの実行 トランザクションの実行
シーケンサーから始めましょう。L2 のパフォーマンスの低下と tps の低下の原因は EVM にあると多くの人が言いますが、これは間違いです。megaeth のテストによると、evm はすでに非常に高い 14,000 tps に達する可能性があります。
しかし、これはリアルタイム ブロックチェーンには十分ではありません。従来の EVM 実装には、次の 3 つの非効率性の問題があります。
状態アクセスの待ち時間が長い: ブロックチェーン状態はハードディスクに保存されており、複数回の読み取りが必要なため、アクセスと読み取りに時間がかかります。
解決策: 注文者ノードには、ブロックチェーン全体の状態を保存するのに十分な RAM が装備されています。現在、イーサリアムの RAM は約 100 GB であり、この方法により SSD の読み取り遅延が排除され、状態へのアクセスが大幅に高速化されます。
並列実行の欠如: トランザクションは状態の一貫性と二重支出を確保するために順次実行されるため、並列実行が困難です。
解決策: このシナリオにはすでに回避策がありますが、たとえ解決されたとしても、実際の運用環境で達成できる実際の高速化は、ワークロードで利用可能な並列処理によって本質的に制限されます。テストによると、最近のイーサリアムの実際の並列処理の中央値は 2 未満であり、並列処理が限られていることを示しています。実際、イーサリアムの異なるトランザクションには多くの依存関係があり、同じ状態でオブジェクトの読み取りと書き込みさえ行われるため、並列処理で競合が発生するという問題が解決されなければなりません。
インタープリターのオーバーヘッド: スマート コントラクトの実行時に仮想マシンまたはインタープリターによって発生する追加のオーバーヘッド。
解決策: 比較的高い割合のオペコードがすでに Rust にネイティブであるため、コンパイルによる高速化は最大でも 2 倍にとどまる可能性があります。
これら 3 つの一般的な高性能ブロックチェーンが直面する問題に加えて、10 ミリ秒レベルのリアルタイム ブロックチェーンを実現するには、まだ 2 つの課題があります。1 つ目は、ブロックを高頻度で一貫して生成することです。たとえば、1 つのブロックが生成されることです。 2 つ目は、混雑のピーク時でも重要なトランザクションをキュー遅延なく処理できるように、並列実行エンジンがトランザクションの優先順位付けをサポートする必要があることです。
状態の同期
状態の同期は、完全なノードをシーケンサーの速度に合わせるプロセスであり、高性能ブロックチェーン設計の最も困難な側面の 1 つです。
転送とユニスワップ トランザクションが 1 秒あたり 100,000 回送信される場合、それぞれ 152.6Mbps と 476.1Mbps の帯域幅が必要になります。これは、ノード全体の 100Mbps の帯域幅をはるかに超えています。さらに、この 100Mbps は 3 分の 1 しか使用されない可能性があります。同期に使用される実際の帯域幅はわずか 25Mbps である可能性があり、これは実際の要件とは大きく異なります。
ステートルートを更新する
MPT のデータ構造は非常に複雑で、ステート ルートを更新するには、多数のリーフ ノードと子ノードの読み取りと書き込みが必要になります。読み取りだけを計算すると、約 600 万回の転送が必要になります。すべてのデータベース読み取りが 1 つのディスク I/O で処理できると仮定したとしても、600 万 IOPS は現在のコンシューマ SSD の能力をはるかに超えており、この計算には書き込みも必要ありません。運用を考慮して。
ディスク I/O を削減するための一般的な最適化戦略は、複数のトライ ノードをサブツリーにグループ化し、4KB のディスク ページに格納することです。しかし、それでも私たちが求めた金額の6分の1です。
ブロックガス制限
ブロックチェーンのセキュリティと信頼性を確保するには、妥当なガス制限を設定する必要があります。
インフラストラクチャー
最後に、ユーザーはシーケンサー ノードと直接対話することはなく、ほとんどの人は自宅で完全なノードを実行しません。代わりに、ユーザーはサードパーティの RPC ノードにトランザクションを送信し、dApp または http://etherscan.io/ の Web フロントエンドなどのブロックチェーン エクスプローラーを利用してトランザクション結果を確認します。
したがって、ブロックチェーンの実際のユーザー エクスペリエンスは、RPC ノードやインデクサーなどのサポート インフラストラクチャに大きく依存します。リアルタイム ブロックチェーンの実行速度がいかに速くても、RPC ノードがピーク時間帯に大量の読み取りリクエストを効率的に処理できない場合、トランザクションをソーター ノードに迅速に伝播できない場合、またはインデクサーがアプリケーション ビューを十分な速さで更新できない場合は、それは問題ではありません。
原則に基づいたアプローチによるブロックチェーンのスケーリング
研究開発に対する総合的かつ原則に基づいたアプローチに取り組んでいます。早期に詳細なパフォーマンス分析を実施することで、ユーザーに真の利益をもたらす問題の解決に集中し続けることができます。実際、鍵となるのは全体的で詳細なユーザーの視点です。
4. 想定されるアプリケーションの種類
• ゲーム
• リアルタイム コンピューティングを必要とする分散型物理インフラストラクチャ (dePin)
• 自律世界エンジン
• 分散型VPNネットワーク
• 国境を越えた支払い
• レイテンシーが極めて低い高頻度取引を活用します (オンチェーン Binance?)。
実際のところ、アプリケーションの部分には想像の余地がたくさんあるはずです。私は関連するスペースをたくさん聞いてきましたが、皆さんの考えがまだ十分ではないと感じています。