イーサリアムの EVM は、シングルスレッド アーキテクチャのため、特に大量の同時トランザクションを処理する場合に、深刻なパフォーマンスの問題に直面します。このシリアル実行方式ではネットワークのスループットが制限され、処理速度が増大するユーザーのニーズを満たすには程遠いものになります。 EVM シリアル実行のプロセス全体を段階的に分析することで、イーサリアムが並列実行を実現するための 2 つの主要なソフトウェア問題を発見しました。 1. 状態の識別 2. データ アーキテクチャと IPOS の消費 これら 2 つの問題に対処するために、各企業は独自の課題を抱えています。独自のソリューションは、EVM と互換性があるかどうか、楽観的並列処理を使用するか悲観的並列処理を使用するか、データベースのデータ アーキテクチャ、よりメモリ効率の高いチャネルを使用するかハードディスク上で高同時実行チャネルを使用するかなど、複数のトレードオフに直面します。開発者の開発経験、ハードウェア要件、モジュラーまたはモノリシック チェーン アーキテクチャなど、これらすべてを慎重に比較検討する価値があります。
また、並列実行によりブロックチェーンが飛躍的に拡張されるように見えますが、P2P ネットワークやデータベース自体のスループットなどの問題を含め、分散システムには依然としてボトルネックが存在することにも気付きました。ブロックチェーン コンピューティングが従来のコンピューターの計算能力に達するまでには、まだ長い道のりがあります。現時点では、並列実行自体もいくつかの問題に直面しています。たとえば、並列実行のためのハードウェア要件がますます高くなっていること、ノードの専門化が進むことによってもたらされる集中化と検閲のリスク、メモリ、中央クラスタ、またはノードに依存するメカニズム設計も含まれます。ダウンタイムのリスクをもたらすと同時に、並列ブロックチェーン間のクロスチェーン通信も問題となります。これは、さらに多くのチームが検討する価値があります。
各社のアーキテクチャと EVM の互換性についての考え方から、破壊的イノベーションは過去に妥協しないことから生まれることがわかります。ブロックチェーン技術はまだ初期段階にあり、パフォーマンスの改善は最終的なものにはほど遠いですが、妥協を望まず、ルールに従わない、より強力で興味深い製品を構築する起業家がさらに増えるのが待ちきれません。
イーサリアムのシングルスレッドの問題
イーサリアム EVM は、主にその後進的なアーキテクチャ設計により、そのパフォーマンスについて常に批判されてきましたが、中でも並列化をサポートしていないという問題が最も深刻です。トランザクションの並列化の場合、これは道路を複数の滑走路に変えることに相当し、道路上で対応できる交通量を飛躍的に向上させることができます。
イーサリアムをさらに深く掘り下げると、現在の実行層とコンセンサス層の分離を背景に、EVM のすべてのトランザクション処理がシリアル実行であることがわかります。
イーサリアムのトランザクション実行プロセス
Ethereumのトランザクションでは、まずユーザーがRPCでMempoolにトランザクションを送信し、次にBuilderが利益を最大化するトランザクションを選択してソートします。この時点でトランザクションの順序は決まっています。プロポーザーはトランザクションをコンセンサス層にブロードキャストし、コンセンサス層は、有効な送信者からのブロックなどのブロックの有効性を判断し、ブロック内のトランザクションが実行ロードとして実行層に送信され、実行層がトランザクションを実行します。トランザクションを実行する簡単なプロセスは次のとおりです: (例として、アリスがボブに 1 ETH を送信します)。
1. 実行ノードの EVM では、NO.0 トランザクション命令を EVM が認識できる OPcode コードに変換します。
2. 次に、OPcode のハードコーディングに基づいて、このトランザクションに必要な Gas を決定します。
3. トランザクションの実行中、データベースにアクセスしてアリスとボブの残高ステータスを取得し、トランザクション オペコードを実行してアリスの残高がマイナス 1 でボブの残高がプラス 1 であることを確認し、書き込み/更新する必要があります。このバランスステータスをデータベースに保存します。
4. ブロックからトランザクション No.1 を取り出し、ブロックのトランザクションが完了するまでループで順次実行し続けます。
5. データベース内のデータは、ブロック内のすべてのトランザクションが最終的に順番に実行された後、ステート ルート (アカウント ステータスの保存)、トランザクション ルート (トランザクションの順序の保存) の形式で主に保存されます。データベース内の領収書 ルート (成功ステータスやガス料金など、トランザクションに関する付随情報を保存する) がコンセンサス層に送信されます。
6. コンセンサス層は、状態ルートを受信した後、トランザクションの信頼性を簡単に証明でき、実行層は検証データをコンセンサス層に送信し、ブロックは検証済みとみなされます。
7. コンセンサス層は、ブロックを自身のブロックチェーンの先頭に追加して証明し、その証明をネットワーク上でブロードキャストします。
これは、ブロック内のトランザクションの順次実行を伴うプロセス全体であり、主な理由は、各トランザクションに独自の NO があり、各トランザクションがデータベース内のステータスを読み取ってステータスを書き換える必要があるためです。一部のトランザクションは相互の状態に依存しているため、それらが順番に実行されないと、状態の競合が発生します。これが、MEV がシリアル実行を選択する理由です。
MEV の単純さは、シリアル実行のパフォーマンスが非常に低いことも意味します。これが、イーサリアムの TPS が 2 桁しかない主な理由の 1 つです。コンシューマ アプリケーションに焦点を当てた現在の開発コンテキストでは、EVM は後進的な設計パラダイムとして、緊急に改善する必要があるパフォーマンスの問題に直面していますが、現在の EVM は完全にレイヤ 2 中心のロードマップに移行していますが、次のような EVM の問題があります。 MPT のトライ構造や LevelDB などのデータベースの非効率性などを早急に解決する必要があります。
この問題が進行するにつれて、イーサリアムの古い設計パラダイムを解決するために、多くのプロジェクトが並列高性能 EVM を構築し始めています。 EVM プロセスを通じて、高性能 EVM によって解決される 2 つの主な問題があることがわかります。
1. トランザクション ステータスの分離: ステータスの相互依存のため、独立したステータスを持つトランザクションは分離され、依存関係のあるトランザクションは引き続き実行される必要があります。その後、複数のコアに分散して並列処理を行うことができます。
2. データベース アーキテクチャの改善: Ethereum は MPT ツリーを使用します。トランザクションには多数の読み取り操作が含まれるため、通常、これにより非常に高いデータベース読み取りおよび書き込み操作、つまり非常に高い IOPS (IO Per Second) 要件が発生します。通常の消費者向け SSD では、この需要を満たすことができません。
一般に、現在の主流のブロックチェーン構築ソリューションでは、ソフトウェアの最適化は、多くの場合、並列トランザクションを構築するためのトランザクション ステータスの分離と、高度な同時トランザクション ステータスの読み取りをサポートするためのデータベースの最適化が主になります。高性能への要求に伴い、ほとんどのプロジェクトのハードウェア要件も増加しています。イーサリアムは、レイヤー 1 のパフォーマンス拡張については、集中化と不安定性を意味するため、常に非常に慎重です。ただし、現在の高性能 EVM は多くの場合、これらの束縛を放棄し、極端なソフトウェアの改善、P2P ネットワークの最適化、データベースの再構築、エンタープライズ レベルのプロフェッショナル ハードウェアを導入しています。
派生データベースの IOPS の問題
並列実行の識別と分離は、実際には理解するのが難しいことではありません。主な難点は、データベースの IOPS の問題です。この記事では、ブロックチェーンデータベースが直面する複雑な問題を読者に感じてもらうために、実践的な例も紹介します。
イーサリアムでは、フルノードには実際に仮想マシンがインストールされており、これは通常のコンピュータと考えることができ、データは専門的なソフトウェアであるデータベースに保存されます。膨大なデータを管理するにはこのソフトウェアを使用します。業界データが異なれば、データベースの種類も異なります。たとえば、ベクトル データベースは、さまざまな種類のデータが存在する AI などの分野でよく使用されます。イーサリアムなどのブロックチェーン分野では、比較的単純なキーと値のペアのデータベースが使用されます。
Ethereum データ構成の概略図、出典: Github
通常、データベース内のデータは抽象的な方法でまとめられており、イーサリアムは MPT ツリーの形式になっています。 MPT ツリーの最終的なデータ状態はルート ノードを形成します。したがって、MPT を使用すると、データの整合性を簡単に検証できます。
現在のデータベースのリソース消費を確認する例を示します。
n 個のリーフ ノードを持つ k フォーク マークル パトリシア ツリー (MPT) では、単一のキーと値のペアを更新するには、O(klog kn) 読み取り操作と O(log kn) 書き込み操作が必要です。たとえば、160 億のキー (つまり 1 TB のブロックチェーン状態) を持つバイナリ MPT の場合、これは約 68 回の読み取り操作と 34 回の書き込み操作に相当します。ブロックチェーンが 1 秒あたり 10,000 件の転送トランザクションを処理する必要があり、ステート ツリー内の 3 つのキーと値を更新する必要があるとします。合計 10,000 x 3 x 68 = 2,040,000 回、つまり 2M IOPS (I/O Per) 2 番目) 操作 (実際には、圧縮とキャッシュによって約 200,000 IOPS まで一桁削減できますが、拡張はしません)。現在の主要なコンシューマー向け SSD はこれをサポートできません (Intel Optane DC P 580 0X 800 GB はわずか 100,000 IOPS)。
MPT ツリーは現在、次のような多くの問題に直面しています。
● パフォーマンスの問題: MPT は階層ツリー構造のため、データを更新するときに複数のノードを横断する必要があることがよくあります。各状態更新 (転送やスマート コントラクトの実行など) には大量のハッシュ計算が必要であり、多くのノード層にアクセスする必要があるためパフォーマンスが低下します。
● 状態の拡大: 時間の経過とともに、ブロックチェーン上のスマート コントラクトやアカウント残高などの状態データは増加し続け、MPT ツリーのサイズは拡大し続けます。これにより、ノードはますます多くのデータを保存することになり、ストレージスペースと同期ノードに課題が生じます。
イーサリアム状態の拡張 (状態プルーニングを含む)、出典: Etherscan
● 部分的な更新を効率的に処理できない: ツリー構造内のリーフ ノードが変更されると、パス全体に沿ったノードが影響を受けます。 Ethereum MPT はリーフ ノードからルート ノードまですべてのハッシュ値を再計算する必要があるため、ローカルな状態の変更であっても多数のノードで更新する必要があり、パフォーマンスに影響します。
イーサリアムは現在、MPT の下でさまざまな問題に直面していることがわかります。また、状態拡張のための状態枝刈りや、MPT のパフォーマンス問題に対する新しい Verkel ツリーの構築など、さまざまな解決策も提案しています。新しい Verkel ツリー構造データベースを構築し、ツリーの深さを減らして部分更新時のデータベース アクセス数を削減し、ベクトル コミットメント (主に KZG コミットメント) を使用して証明のサイズとデータベース アクセスの量を削減します。
つまり、過去の MPT ツリーは古くなりすぎ、多くの新たな課題に直面しているため、Verkel ツリーの使用など、データの保存方法の変更がロードマップに含まれています。ただし、これは非常に弱い変更にすぎず、並列実行や、高い同時実行性の下で必要とされる高い IOPS のソリューションはまだ含まれていません。
新しいパブリック チェーンには並列実行が標準装備されています
前のパートで述べたように、並列実行とは、単一車線から複数車線に変更することを意味し、複数車線の交差点では、各車線がスムーズに通過できるように信号調整などのミドルウェアが必要になることがよくあります。並列トランザクションでも同じことが当てはまります。並列実行によってもたらされる高い TPS は、無関係な状態のトランザクションを分離できるように、状態を識別するミドルウェアを介してユーザー トランザクションを渡す必要があります。基礎となるデータベースの場合。ほぼすべての新しいレイヤー 1 には、標準機能として並列実行が備わっています。
並列実行ソリューションを分類する方法は数多くあり、基盤となる仮想マシンに応じて、EVM (sei、MegaETH、Monad) と None-EVM (Solana、Aptos、Sui) に分類されます。トランザクションステータスの分離方法に応じて、楽観的実行（すべてのトランザクションを実行する必要はないと仮定し、ステータスが矛盾する場合、トランザクションのこの部分はロールバックして再実行されます）と早期実行に分けることができます。宣言 (開発者はアクセスされたステータス データをプログラム内で宣言する必要があります)。これらの分類にはトレードオフも含まれます。
次に、EVMかどうかで分けるのではなく、単純に各パブリックチェーンの状態分離とデータベースの改善を比較してみます。
メガETH
MegaETH は厳密にはパフォーマンスを主な目標とする異種ブロックチェーンであり、EigenDA をコンセンサス層と DA 層として使用するイーサリアムのセキュリティに依存しています。実行層としてハードウェアのパフォーマンスを最大化し、TPS を向上させます。
トランザクション処理の最適化方法には次の 3 種類があります。
1. 状態の分離: トランザクションの優先順位を使用したストリーミング ブロックの構築。このモデルは Solana の POS に似ています。実際、Solana のトランザクションもストリーミング方式で構築されていますが、Solana には優先順位はなく、すべてが速度で競争されます。そして、MegaETH は、トランザクション用に何らかの優先順位付けアルゴリズムを構築できるようにしたいと考えています。
2. データベース: MPT Trie の問題を解決するために、より高い IOPS を提供する新しいデータ構造を構築しました。 MegaETHのコードベースを確認したところ、Verkel Trieの設計手法も参照していることが分かりました。
3. ハードウェアの特化: ソーターを集中化および特化することで、インメモリ コンピューティングが実装され、IO 効率が大幅に向上します。
実際、MegaETH は、セキュリティと検閲耐性をレイヤー 2 としてイーサリアムに委ねることで、ノードを最大限に最適化し、POS の経済的セキュリティを通じてシーケンサーが悪さをしないようにしたいと考えています。ここには、挑戦する価値のある点が数多くあります。 . ただし、拡張は行いません。 MegaETH は並列実行用のトランザクションを構築していますが、実際には、単一のソーター ノードのパフォーマンスを最大化し、ハードウェアで最大限のパフォーマンスを拡張し、並列実行を通じてパフォーマンスを拡張することを望んでいます。
モナド
MegaETH とは異なり、Monad は別個のチェーンであり、並列実行、並列実行の状態分離、およびデータベースの再構築のために最適化する必要がある、紹介した 2 つの重要な点を満たしています。 Monad で使用される特定のメソッドについて簡単に説明します。
● 楽観的な並列実行: トランザクションの識別において、すべてのトランザクションの最も古典的なデフォルト ステータスは、ステータスの競合が発生した場合、トランザクションが再実行されます。この方法は現在、Aptos の Block-STM メカニズムで使用されています。素晴らしい作品です。
● データベースの再構築: データベースの IOPS を向上させるために、Monad は EVM 互換のデータ構造 MPT (Merkel Patricia Tree) を再構築し、Patricia Tree 互換のデータ構造を実装し、最新のデータベース非同期 I/O をサポートします。データへの書き込みの完了を待たずに特定の状態を読み取ることをサポートします。
● 非同期実行: イーサリアムでは、特定のコンセンサス層と実行層を厳密に識別していますが、コンセンサス層と実行層 (実行層としてのレイヤ 2 の概念とは異なります) は、ここではイーサリアムを指します。 (イーサリアム上でトランザクションを実行するための) 実行ノードは依然として結合されており、実行によりコンセンサスに対する実行後に更新されたメルケル ルートが与えられるため、コンセンサス層はコンセンサスに達するために投票することができます。モナドは、ソートが完了した瞬間に状態が解決されたと見なすため、ソートされたトランザクションに関するコンセンサスのみが必要であり、この結果を明らかにするために実行さえ必要ありません。この考え方により、Monad はコンセンサス層と実行層を巧みに分離して、同時コンセンサス実行を実現できます。ノードは、ブロック N でのコンセンサス投票を維持しながら、ブロック N-1 でトランザクションを実行できます。
もちろん、Monad には、新しいコンセンサス アルゴリズム MonadBFT など、他の多くのテクノロジもあり、これらを組み合わせて高性能の並列 EVM レイヤ 1 を構築します。
アプトス
Aptos は Facebook の Diem チームから分離され、両者は共同で Move デュオと見なされていますが、両者の技術的概念に一貫性がないため、全体として 2 つの Move 言語は大きく異なっています。アプトス ディエムのオリジナルデザインをより忠実に踏襲しており、スイはデザインに大幅な変更を加えました。
並列実行のために解決する必要がある問題:
● 状態の識別: オプティミスティックな並列実行 Aptos は、デフォルトでトランザクションをオプティミスティックに実行する Block-STM 並列実行エンジンを開発しました。現在、この技術は一般に受け入れられており、Polygon、Monad、sei、StarkNet はすべてこの技術を使用しています。
● IO の改善: Block-STM はステータスの競合を避けるためにマルチバージョンのデータ構造を使用します。たとえば、残りのメンバーがデータベースを作成しているとします。通常、データの競合を避ける必要があるため、データベースにアクセスすることはできませんが、マルチバージョンのデータ構造により過去のバージョンにアクセスできるようになります。問題は、この解決策ではスレッドごとに表示可能なバージョンを生成する必要があるため、大量のリソースが消費されることです。
● 非同期実行: Monad と同様に、トランザクションの伝播、トランザクションの順序付け、トランザクションの実行、状態の保存、ブロックの検証がすべて同時に実行されます。
現在、Block-STM はほとんどのパブリック チェーンで受け入れられており、Monad 氏は、このテクノロジーの登場により、開発者へのプレッシャーを効果的に軽減できると述べています。しかし、Aptos が直面している問題は、Block-STM のインテリジェンスが低下していることです。過剰なノード要件の問題が発生しました。この問題を解決するには、特殊なハードウェアと集中管理が必要です。
スイ
Ai は、Aptos と同様に、Diem プロジェクトから継承されています。対照的に、Sui はペシミスティックな並列化を使用し、トランザクション間の状態の依存関係を厳密に検証し、実行中の競合を防ぐためにロック メカニズムを採用します。アプトスは開発者の開発負担を軽減したいと考えている。
● 状態識別: Aptosb とは異なり、悲観的な並列化が採用されているため、開発者は並列状態識別をシステムに処理に任せるのではなく、独自の状態アクセスを宣言する必要があります。これにより、開発者の開発負担が増加し、システム設計の複雑さが軽減されます。並列化能力が向上します。
● IO の改善: IO の改善は現在、アカウントベースのモデルを使用しており、各アカウントがデータを保持していますが、Sui ではこのアーキテクチャが大幅に改善されます。ピークパフォーマンスでの並列実装の難しさに影響します。
Sui には EVM の歴史的な遺産がなく、互換性の問題もないため、アカウント モデルに関しては、革新的なアイデアも提案されています。この種の抽象レベルでの革新は、実際にはより困難です。ただし、そのオブジェクト モデルは並列処理に多くの利点をもたらしますが、理論的には無限に拡張できる非常にユニークなネットワーク アーキテクチャを構築できるのもオブジェクト モデルのおかげです。
ソラナ - ファイアダンサー
Solana は、並列コンピューティングのパイオニアと見なされています。Solana の哲学は常に、ブロックチェーン システムはハードウェアの進歩とともに進歩するものであるということです。Solana の現在の並列処理方式は次のとおりです。
● 状態認識: SUI と同様に、Solana も決定論的並列処理を使用します。これは、通常、すべての状態が事前に宣言される組み込みシステムを扱う Anatoly の過去の経験から来ています。これにより、CPU はすべての依存関係を認識できるようになり、メモリの必要な部分をプリロードできるようになります。その結果、システムの実行が最適化されますが、やはり開発者は事前に追加の作業を行う必要があります。 Solana では、プログラムのすべてのメモリ依存関係が必要であり、構築されたトランザクション (つまり、アクセス リスト) で宣言されるため、ランタイムは複数のトランザクションを効率的にスケジュールし、並行して実行できます。
● データベース: Solana は Cloudbreak を使用して、アカウントをモデルとして使用する独自のカスタム アカウント データベースを構築しました。アカウント データは、ライブラリを複数のレイヤーに分割するのと同様に、複数の「シャード」に分散されており、それに基づいて作成する必要があります。負荷分散のためのレイヤーの数を増減します。 SSD 上のメモリにマッピングされるため、パイプライン設計により SSD をメモリ経由で高速に操作でき、複数のデータへの並列アクセスもサポートし、同時に 32 の IO 操作を処理できます。
Solana では、開発者は決定論的な並列処理を通じてアクセスする必要がある状態を宣言する必要があります。これは、プログラムの構築という点では、開発者自身が並列アプリケーションを構築する必要があるのに対し、プログラムのスケジューリングとランタイム パイプラインの非同期並列処理は、実際に必要となります。プロジェクトが構築する必要があるもの。データベースに関しては、IPOS を向上させるためにデータを並列化するための独自の DataBase を構築します。
同時に、その後の Solana イテレーションのクライアントである Firedancer は、非常に強力なエンジニアリング能力を持つ量的大手である Jump Trading によって推進および開発されました。これは、ソフトウェアの非効率性を排除し、パフォーマンスを向上させるという目標を掲げ、Solana と同じビジョンを共有しています。ハードウェアの限界。その改善は主に、P2P 伝播、ハードウェア SIMD データ並列処理などを含む、基盤となるハードウェアの改善を目的としています。これは、MegaETH のアイデアと非常に似ています。
セイ
セイが現在使用している
● オプティミスティックな並列実行: Aptos の Block-STM 設計を参照。 Sei V1 バージョンでは、Sui や Solana と同様の受動的並列スキームが使用されており、開発者が使用するオブジェクトを宣言する必要があります。ただし、sei V2 以降は、Aptos のオプティミスティック並列スキームに変更されました。これにより、開発者が不足している可能性がある Sei が EVM エコシステムからより簡単に契約を移行できるようになります。
SeiDB デザイン、ソース: Sei
● SeiDB: データベース ソリューション全体は Cosmos の ADR-065 提案に基づいて構築されており、そのエンティティはデータをアクティブ データと履歴データに分割するように設計されています。SSD ハードディスク内のデータはメモリにマッピングされます。同時に、SSD データは MemIAVL ツリー構造を使用し、メモリ データはステート コミットメントに IAVL ツリー (Cronos によって発明) を使用します。これにより、コンセンサスを実行するためのステート ルートが提供されます。 MemIAVL の抽象的な概念は、新しいブロックがコミットされるたびに、そのブロックのトランザクションからすべての変更のセットを取得し、それらの変更を現在のメモリ内の IAVL ツリーに適用することで、新しいバージョンのツリーを生成するというものです。最新のブロックの場合、ブロックコミットのマークルルートハッシュを取得できるようになります。したがって、これはホット アップデートにメモリを使用することと同等であり、ほとんどの状態アクセスを SSD ではなくメモリに配置できるため、IOPS が向上します。
SeiDB の主な問題は、最新のアクティブ データがメモリに保存されている場合、ダウンタイム中にデータが失われることです。そのため、MemIAVL では WAL ファイルとツリー スナップショットが導入されています。一定期間内にメモリ内のデータのスナップショットを作成し、それをローカル ハード ディスクに保存して、メモリ上のデータ拡張による OOM の影響をタイムリーに制御するために、一定の時間のスナップショット間隔を制御する必要があります。
並べて比較
フルノードの要件
フルノードを実行するための要件
FireDancer はノードの動作要件が最も高く、パフォーマンス モンスターと言えます。 MegaETH の主なパフォーマンス要件は、100 以上のコアのシーケンサー要件に重点を置いています。集中ノード シーケンサーが存在するため、他のフル ノードの要件は高くありません。現在、SSD の価格は比較的低いため、一般的には CPU とメモリのパフォーマンス要件のみを検討します。フルノードのパフォーマンス要件を高から低の順にランク付けします: Firedancer > Sei > Monad > Sui > Aptos > MegaETH > Ethereum。
プラン
現在の並列処理ソリューションの場合、一般的に、ソフトウェア レベルでの最適化は、1. データベース IOPS 消費の問題、2. 状態識別の問題、3. パイプラインの非同期の問題に主に焦点を当てており、これら 3 つの側面がソフトウェア レベルの最適化に使用されます。状態認識は現在、楽観的並列実行と宣言的プログラミングの 2 つの陣営に分かれています。これらの両方には長所と短所があります。その中で、オプティミスティック並列実行は主に Aptos の Block-STM ソリューションに基づいており、その主な採用者には Monad と Sei V2 が含まれますが、Sui、Solana、および Sei V1 はすべて宣言型プログラミングです。従来の同時プログラミングまたは非同期プログラミング パラダイムに似ています。データベースの IPOS 消費の問題に関しては、各社が異なる解決策を持っています。
プラン比較
データ構造に関しては、Monad を可能な限り SSD 上に配置するという興味深い点が見られます。ただし、ハードディスクの読み取り速度は Memory に比べてはるかに遅いですが、価格ははるかに安価です。 Monad は、価格、ハードウェアのしきい値、並列処理の程度を考慮して SSD に配置されました。これは、SSD が 32 チャネルの I/O 操作をサポートして、より多くの並列機能を向上できるためです。対照的に、Solana と Sei は、メモリが SSD よりもはるかに高速であるため、メモリ マッピングを選択します。 1 つは並列チャネルを水平に拡張することであり、もう 1 つは垂直に拡張して I/O 消費を削減することです。これが、Monad のノード要件が 32 GB であるのに対し、sei と Solana はさらに多くのメモリを必要とする理由です。
さらに、イーサリアムのデータ構造は、Patrci Tree から進化した Merkel Patric Tree から派生しているため、EVM 互換のパブリック チェーンは Merkel Trie と互換性がある必要があるため、Aptos のような資産についての抽象的な考え方を構築することはできません。 Sui、Solana など。イーサリアムはアカウント モデルに基づいていますが、Sui はオブジェクト モデル、Solana はデータとコードを分離したアカウント モデルであり、イーサリアムは確かに結合されています。
破壊的イノベーションは、過去への妥協を許さないことから生まれます。確かに、開発者コミュニティと過去の互換性を考慮する必要があります。
見通し
現在の並列実行の主な最適化コンポーネントには、比較的明確な目標があり、状態を識別する方法と、データの読み取りと保存の速度を向上させる方法に主に焦点を当てています。これは、これらのデータの保存方法により、データの読み取りまたは保存に追加の時間がかかるためです。データのオーバーヘッドと消費、特に Merkel トライではルート検証が導入されますが、非常に高い IO オーバーヘッドが生じます。
並列実行によりブロックチェーンは飛躍的に拡大しましたが、P2P ネットワーク、データベース、その他の問題を含む分散システムには依然としてボトルネックが存在します。ブロックチェーン コンピューティングが従来のコンピューターの計算能力に達するまでには、まだ長い道のりがあります。現時点では、並列実行自体もいくつかの問題に直面しています。たとえば、並列実行のためのハードウェア要件がますます高くなっていること、ノードの専門化が進むことによってもたらされる集中化と検閲のリスク、メモリ、中央クラスタ、またはノードに依存するメカニズム設計も含まれます。ダウンタイムのリスクをもたらすと同時に、並列ブロックチェーン間のクロスチェーン通信も問題となります。
並列実行には依然として特定の問題がありますが、各企業は、MegaETH が主導するモジュラー設計アーキテクチャや Monad が主導するモノリシック チェーン設計アーキテクチャなど、エンジニアリングのベスト プラクティスを模索しています。現在の並列実行最適化スキームは、ブロックチェーンテクノロジーが常に従来のコンピューター最適化スキームに近づきつつあり、特にデータストレージ、ハードウェア、パイプライン、その他のテクノロジーの詳細な最適化など、最下位レベルでの最適化がますます進んでいることを証明しています。しかし、この文にはまだボトルネックや問題があり、起業家にとってはまだ非常に広い探索の余地が残されています。
破壊的イノベーションは過去に妥協しないことから生まれ、より強力で興味深い製品を構築するために妥協を望まない起業家がさらに増えることを待ちきれません。
免責事項:
上記の内容は参考用であり、アドバイスとして考慮されるべきではありません。投資する前に必ず専門家のアドバイスを求めてください。
ゲートベンチャーズについて
Gate Venturesは Gate.io のベンチャー キャピタル部門で、Web 3.0 時代に世界を再構築する分散型インフラストラクチャ、エコシステム、アプリケーションへの投資に重点を置いています。 Gate Ventures は世界的な業界リーダーと協力して、社会と金融の相互作用モデルを再定義する革新的な思考と能力をチームやスタートアップに与えます。
公式サイト： https://ventures.gate.io/ Twitter： https://x.com/gate_ventures媒体： https://medium.com/gate_ventures
