ログイン/ 登録

モナドとそのエコ・プロジェクトの概要を読む

JinseFinance

2025/02/28 19:57

従う

記事ソース：ASXN; Compiled by Golden Finance xiaozou

1.序文

Monadは、10,000TPS（毎秒10億ガス）、500ミリ秒のブロックアウト周波数、1秒のファイナリティを持つ高性能最適化EVM互換L1です。

*EVMはトランザクションを順次処理するため、ネットワークアクティビティが高い時間帯にボトルネックとなり、特にネットワークの輻輳時にトランザクション時間が長くなります。

*スループットが12～15TPSと低く、ブロックアウト時間が12秒と長い。

*EVMはトランザクションごとにガス料金を必要としますが、これは変動するため、特にネットワーク需要が高いときには非常に高価になる可能性があります。

2.なぜEVMを拡張するのか

MonadはEVMバイトコードとEthernet RPC APIの完全な互換性を提供し、開発者とユーザーは既存のワークフローを変更することなく統合できます。既存のワークフローを変更することなく統合できます。

よくある質問は、ほとんどのEVM実装よりも高速なtime-to-block、低料金、高スループットを提供するSVMのような、よりパフォーマンスの高い代替手段があるのに、なぜEVMを拡張するのかということです。しかし、EVMには、2つの主な要因に由来するいくつかの重要な利点があります。

(1)資本基盤

EVMには多額の資本があり、EtherのTVLは520億ドルに迫り、Solanaは70億ドルです。Monadやその他のEVM互換チェーンは、最小限の摩擦で統合されたカノニカルブリッジやサードパーティブリッジを通じて、EVMチェーンの大規模な資本基盤から恩恵を受けることができます。

*ユーザーは流動性と高い取引量を好む。

*開発者は高い取引量、手数料、アプリの可視性を求めています。

(2) 開発者リソース

イーサネット・ツールや応用暗号研究はMonadに直接統合され、より高いスループットとスケールを実現します。

*アプリケーション

*開発者ツール(Hardhat、Apeworx、Foundry)

*財布 (Rabby、Metamask、Phantom)

*分析/インデックス作成 (Etherscan

エレクトリック・キャピタルの開発者レポートによると、2024年7月現在、Etherには2,788人、Baseには889人、Polygonには834人のフルタイムの開発者がいる。Solanaは664人の開発者で、Polkadot、Arbitrum、Cosmosに次いで7位である。暗号の開発者の総数はまだ少ないため、ほとんど無視すべきだ（そしてリソースは外部の才能を呼び込むことに集中すべきだ）という意見もあるが、暗号開発者の「小さな」プールの中に多くのEVMの才能があることは明らかだ。さらに、ほとんどの人材がEVMで働き、ほとんどのツールがEVMであることを考えると、新しい開発者はEVMで学習し開発する必要があるか、EVMを選択する可能性が高い。Solana、Aptos、またはSui)などの特定のエコシステムでマルチチェーン展開を可能にする、ポータブルなEVM向けアプリケーションを構築し、高性能で低コストのアプリケーションを構築します。

Monad はこれら2つのアプローチを組み合わせることを目指しています。ツールやリソースのほとんどがEVM用にカスタマイズされているため、そのエコシステム内で開発されたアプリケーションをシームレスに移植することができます。Monadの最適化のおかげで、その相対的なパフォーマンスと効率と相まって、EVMは明らかに強力な競争障壁となっている。

開発者だけでなく、ユーザーも使い慣れたワークフローを好みます。EVMワークフローは、Rabby、MetaMask、Etherscanのようなツールを通じて標準となっています。これらの成熟したプラットフォームは、ブリッジやプロトコルの統合を容易にする。加えて、基本的なアプリケーション（AMM、マネーマーケット、ブリッジ）を即座に立ち上げることができる。これらの基本的なプリミティブは、新しいアプリケーションだけでなく、チェーンの持続可能性にとっても重要です。

3.EVMの拡張

EVMを拡張する主な方法は2つあります；">*実行をチェーンの下に移動する:モジュール式アーキテクチャを使用して、ロールアップを介して他のVMに実行をオフロードします。

*パフォーマンスの向上:コンセンサスの最適化を行い、ブロックサイズとガスの上限を増やすことで、ベースチェーンEVMのパフォーマンスを向上させます。

(1)ロールアップとモジュラーアーキテクチャ

バイタリックは2020年10月、イーサネットの大幅な拡張としてロールアップを導入しました。ソリューションを導入した。その結果、Etherのスケーリングロードマップは、Etherのセキュリティを活用するオフチェーン仮想マシンであるロールアップに実行を委ねることになりました。ロールアップは、より高いスループット、より低いレイテンシ、より低いトランザクションコストで、実行に優れています。イーサでは数年かかるアップデートが、ロールアップでは数カ月で済むこともあります。

ロールアップは、特定の分散化要件を回避するための安全なエスケープハッチを維持しながら、集中型シーケンサーを使用して実行することができます。多くのロールアップ（Arbitrum、Base、OP Mainnetを含む）はまだ初期段階（ステージ0またはステージ1）であることに注意することが重要です。ステージ1のロールアップでは、不正行為の証明の提出はホワイトリストに登録された参加者に限定され、オンチェーンでの証明可能なエラーに関係ないアップグレードは、少なくとも30日間のオプトアウトウィンドウをユーザーに提供しなければなりません。ステージ0のロールアップでは、ライセンス運用者のダウンタイムまたはレビューが発生した場合、7日未満のオプトアウト期間をユーザーに提供します。

ethereum では、典型的なトランザクションのサイズは156バイトであり、署名が最も多くのデータを含んでいます。ロールアップでは、複数のトランザクションを一緒にバンドルすることで、トランザクション全体のサイズを縮小し、ガスコストを最適化することができる。要するに、ロールアップは複数のトランザクションをバッチにまとめてメインのイーサネット・ネットワークに送信することで効率化を実現する。これにより、オンチェーンでのデータ処理は軽減されるが、ロールアップ接続には新たなインフラ要件が必要となるため、エコシステムの複雑性は増す。さらに、ロールアップ自体は、特にゲーム・アプリケーションのための基本的なロールアップ・スループットの制約に対処するために、実行をL3に移すモジュラー・アーキテクチャを使用しています。

理論的には、ロールアップはイーサの上の完全なチェーンになることで、ブリッジングと流動性の断片化を排除しますが、現在の実装はまだ完全な「完全な」チェーンではありません。TVLによる3つの主要なロールアップ - Arbitrum、OP Mainnet、Base - は、それぞれ異なるエコシステムとユーザーベースを維持しており、特定の分野では優れていますが、包括的なソリューションを提供できていません。

要するに、ユーザーはSolanaのような単一のチェーンを使用しているのと同じ経験を得るために、複数の異なるチェーンにアクセスしなければなりません。イーサリアムのエコシステムには統一された共有ステート（ブロックチェーンの中核的命題の1つ）がないため、オンチェーンのユースケースが大幅に制限されます。特に、競合するロールアップがモビリティとステートの断片化によって互いのステートを容易に理解できないためです。ステートの断片化はまた、ロールアップとステートを結びつけることができるブリッジやクロスチェーン・メッセージング・プロトコルのさらなる必要性を生み出しますが、それにはいくつかのトレードオフが伴います。単一のブロックチェーンでは、状態を記録する単一の台帳があるため、こうした断片化の問題に直面することはありません。

各ロールアップは、最適化と特定分野への集中という点で異なるアプローチを取っています。OptimismはSuperchainを通じて追加のモジュール性を導入しているため、他のL2がそのスタックで構築し、競争するために課金することに依存しています。MegaETHやBaseのような新しい高性能ロールアップは、単一の大規模なチェーンを提供するように設計され、より高いスループット能力を持つようになりました。MegaETHはまだ利用可能ではなく、Baseはその実装の面で印象的ですが、特定の分野ではまだ不足しています。デリバティブ取引（オプションと永久）とDePINスペース。

(2) 初期のL2拡張

Optimism and Arbitrum

L2の第一世代は、Etherと比較して改善された実行を提供しましたが、より新しい超最適化ソリューションに遅れをとっていました。例えば、Arbitrumは1秒あたり37.5トランザクション（「TPS」）を処理し、Optimismメインネットは11TPSです。これは、約80TPSのBase、100,000TPSを目標とするMegaETH、65.1TPSのBNB Chain
Arbitrum とOptimism Mainnetは、完全なオンチェーン・オーダーブック・アプリケーションのような極めて高いスループットをサポートすることはできません。アービトルムとオプティミズム・メインネットは、完全なオンチェーン・オーダーブック・アプリケーションのような非常に高いスループットをサポートすることはできませんが、アービトルムのL3やオプティミズムのハイパーチェーンといった追加のチェーン・レイヤーや中央集中型のシーケンサーによって拡張することができます。
ゲームに特化したアービトルムのL3、Xai、Proof of Playは、このアプローチを実証しています。これらのL3はArbitrum Orbitスタック上に構築され、AnyTrust Data Availabilityを使用してArbitrum上で決済されます。OptimismのL2であるBase、Blast、そして今後登場するUnichainは、Etherを経由して決済されます。OptimismのL2であるBaseとBlast、そして今後予定されているUnichainは、より強固なセキュリティを維持するために、決済とブロブデータの利用可能性を介して決済されます。
両ネットワークは水平方向のスケーリングを優先しています。オプティミズムはOPスタックを通じて、L2インフラ、チェーン展開サポート、相互運用性機能を備えた共有ブリッジを提供しています。アプリケーションは、より低い資本リスクをもたらします。
(3)チェーンとEVMのパフォーマンスの最適化
代替のスケーリングアプローチは、水平方向ではなく垂直方向にスケーリングすることで、スループットとTPSを向上させる最適化または目的トレードオフの実行に重点を置いています。Base、MegaETH、Avalanche、BNB Chainはこの戦略を体現しています。トランザクションを処理し、約70TPSを5時間保持した。12月18日までに、ガス・ターゲットは20メガ・ガス/秒に達し、ブロック・アウト時間は2秒、1ブロックあたり40メガ・ガスがサポートされた。
Base はソラナや他の高スループットチェーンの競合として台頭してきた。
* 2025年1月現在の月間手数料は1,560万ドルで、Arbitrumの7.5倍、OPメインネットの23倍。
*2025年1月時点の累積取引量は3億2970万件で、アービットラム（5790万件）の6倍、OPメインネット（2450万件）の14倍。注：取引量は操作される可能性があり、誤解を招く可能性があります。
Baseチームは、ArbitrumやOptimismのモジュール式アプローチではなく、スピード、スループット、低手数料を最適化することで、より統一されたエクスペリエンスを提供することに注力しています。Baseのアクティビティと収益の数字が示すように、ユーザーはより統一されたエクスペリエンスを好むことを示している。さらに、Coinbaseのサポートと流通も後押ししている。
MegaETH
MegaETHはEVM互換のL2です。その中核では、専用のシーケンサーノードを使用するハイブリッドアーキテクチャによってトランザクションを処理します。MegaETHは、そのアーキテクチャにおいてパフォーマンスとセキュリティのタスクを独自に分離し、従来のMerkle Patricia Trieに代わる新しいステート管理システムを組み込んで、ディスクI/Oオペレーションを最小限に抑えます。
このシステムは、EVMとの完全な互換性とテラバイト級の状態データを扱う能力を維持しながら、ミリ秒以下のレイテンシーで毎秒10万件のトランザクションを処理します。
MegaETHはデータの可用性のためにEigenDAを使用し、3つの専用ノードタイプに機能を分散しています。style="text-align: "left;">*シーケンサー：高性能シングルノード（100コア、1～4テラバイトのRAM）は、トランザクションのシーケンスと実行を管理し、状態をRAMに保持して高速にアクセスします。約10ミリ秒間隔でブロックを生成し、ブロックの検証に立ち会い、ブロックチェーンの状態変更のために状態の違いを追跡する。シーケンサーはEVMの並列実行とプライオリティ・サポートによって高性能を実現し、通常運用時のコンセンサス・オーバーヘッドを不要にしている。
*Proofers:これらの軽量ノード（1コア、0.5GB RAM）は、ブロックコンテンツを検証する暗号証明を計算します。非同期かつカオス的にブロックを検証し、ステートレス検証を使用し、水平方向に拡張し、フルノード検証用の証明を生成します。システムはゼロ知識証明と不正証明に対応しています。
*フルノード：中規模のハードウェア（4～8コア、16GB RAM）で動作するフルノードは、プローバ、シークエンサ、EigenDAの橋渡しをします。ピアツーピアのネットワーク上で圧縮された状態の差分を処理し、トランザクションを再実行することなく差分を適用します。ブロックはプルーバーによって生成された証明を使用して検証され、ステートルートは最適化されたMerkle Patricia Trieを使用して維持され、19倍の圧縮同期がサポートされています。
(4) ロールアップの問題点
モナドは、ロールアップやその固有のトレードオフとは根本的に異なります。今日、ほとんどのロールアップは中央集権的な単一のシーケンサーに依存していますが、共有および分散型のシーケンサー・ソリューションが開発されています。シーケンサーとプロポーザーの集中化は、運用上の脆弱性をもたらす。単一のエンティティによる制御は、アクティビティの問題や検閲耐性の低下につながる可能性がある。エスケープハッチの存在にもかかわらず、集中型シーケンサーはMEVを抽出するためにトランザクションの速度や順序を操作することができます。また、シーケンサーに障害が発生した場合、L2ネットワーク全体が正常に機能しなくなるという単一障害点が発生します。
集中化のリスクに加えて、ロールアップは、特に相互運用性に関して、さらなる信頼の仮定とトレードオフを導入します。
ユーザーは、同じ資産の複数の、腐敗しない形態に遭遇します。Arbitrum、Optimism、Baseという3つの主要なロールアップは、それぞれ異なるエコシステム、ユースケース、ユーザーグループを維持しています。ユーザーは、特定のアプリケーションにアクセスするためにロールアップ間をブリッジしなければなりません。あるいは、複数のロールアップ上でプロトコルを立ち上げなければなりません。
さらなる相互運用性の問題は、技術的な制約（ベースとなるL2レイヤーの1秒あたりのトランザクションの制限）から生じています。中心性は、さらなる課題を提起します。
私たちは、最適化されたロールアップ（BaseやMegaETHなど）がパフォーマンスを向上させ、集中型シーケンサーでEVMを最適化するのを見てきました。これにより、単一の大容量マシンを使用することで、ブロックアウト時間を短縮し、ブロックサイズを大きくすることができます。
Monadは、メインのEtherネットワークと比較して、より強力なハードウェアを必要とし、異なるアプローチを取ります。Ether L1ベリファイアが2コアのCPU、4～8GBのRAM、25Mbpsの帯域幅を必要とするのに対し、Monadは16コアのCPU、32GBのRAM、2TBのSSD、100Mbpsの帯域幅を必要とします。MonadのスペックはEtherと比べると巨大に見えるが、Etherは独立した検証者を収容するために、Monadの推奨ハードウェアが今日アクセス可能であるにもかかわらず、ノードの要件を最小限に抑えている。
ハードウェアスペックに加えて、Monadはソフトウェアスタックを再設計し、ノード分散によってL2よりも大きな分散化を可能にしています。L2が分散化を犠牲にして単一のシーケンサーへのハードウェア強化を優先したのに対し、Monadはハードウェア要件を高めつつノード分散を維持しながらパフォーマンスを向上させるためにソフトウェアスタックを変更しました。
(5)モナドのEVM 初期のイーサリアムフォークは、実行のためにGoイーサリアムクライアントを維持しながら、主にアバランチなどのコンセンサスメカニズムを修正しました。monadは、コンセンサスと実行コンポーネントを第一原理からゼロから再構築することで、異なっています。
モナドはハードウェアを最大限に活用することを優先しています。これとは対照的に、イーサリアムのメインネットは独立した誓約者をサポートすることに重点を置いているため、性能の最適化が制限されています。この制限は、ブロックサイズ、スループット、ブロックアウト時間の改善に影響し、最終的にネットワークの速度は最も遅い検証者に依存します。
Solanaのアプローチと同様に、Monadはより強力なハードウェアを使用して帯域幅を増やし、待ち時間を減らします。この戦略では、利用可能なすべてのコア、メモリ、SSDを活用して速度を向上させる。強力なハードウェアのコストが低下していることを考えると、低品質のデバイスの能力を制限するよりも、高性能なデバイスを最適化する方がより現実的です。
The current Geth client executes via single-threaded sequential processing.ブロックには、前の状態を新しい状態に変換する線形順序のトランザクションが含まれます。この状態には、すべてのアカウント、スマートコントラクト、保存データが含まれる。トランザクションが処理され、検証されると、アカウント残高、スマートコントラクト、トークンの所有権、およびその他のデータに影響を与え、状態の変更が発生します。
取引は通常、独立して実行されます。ブロックチェーンの状態は異なるアカウントで構成され、それぞれが独立してトランザクションを実行し、これらのトランザクションは通常相互に作用しません。これを念頭に置いて、Monadは楽観的並列実行を使用します。
楽観的並列実行は、潜在的なパフォーマンス上の利点のためにトランザクションを並列に実行しようとするもので、最初は競合がないと仮定します。複数のトランザクションが同時に実行され、最初は潜在的な競合や依存関係を気にせずに実行される。実行後、システムは並列トランザクションが実際に互いに競合するかどうかをチェックし、競合が存在する場合はそれを修正します。strong>
ユーザーが並列実行を思い浮かべるとき、通常はアクセスリストを介してトランザクションを並列実行できるSolanaとSVMを思い浮かべるだろう。Solana上のトランザクションは、ヘッダ、アカウントキー（トランザクションに含まれる命令のアドレス）、ブロックハッシュ（トランザクションの作成時に含まれるハッシュ）を含む、命令、およびトランザクション命令に基づいて必要とされるすべてのアカウント署名の配列が含まれる。
各トランザクションの命令には、呼び出されるプログラムを指定するプログラムアドレス、命令が読み書きするすべてのアカウントをリストするアカウント、命令ハンドラ（命令を処理する関数）と命令ハンドラが必要とする追加データを指定する命令データが含まれます。
各命令は、関係する各アカウントについて、次の3つの重要な詳細を指定します。
*命令がアカウントのデータを変更するかどうか
Solanaは、これらの指定されたアカウントのリストを使用して、トランザクションの競合を事前に識別します。書き込み可能かどうかの詳細を含め、すべてのアカウントがコマンドで指定されるため、同じ状態に書き込むアカウントがない場合、トランザクションは並行して処理できる。
プロセスは以下の通りです。
*ソラーナは、各トランザクションで提供されたアカウントのリストを調べます
*どのアカウントが書き込まれるかを特定します。
*トランザクション間の競合をチェックする（同じアカウントに書き込むかどうか）
*同じアカウントに書き込まないトランザクションは並行して処理され、競合する書き込み操作を持つトランザクションは順次処理される
EVMにも同様のメカニズムが存在するが、イーサはアクセスリストを必要としないため、使用されていない。このアクセスリストをトランザクションに含めるため、ユーザーはより多くの前払いをする必要があります。トランザクションは大きくなり、コストも高くなりますが、ユーザーはアクセスリストを指定することで割引を受けることができます。
(2) Monadの並列実行 Solanaとは異なり、Monadは楽観的な並列実行を使用します。どのトランザクションがどのアカウントに影響するかを特定し、それに基づいて並列化する（Solanaのアプローチ）のとは異なり、Monadはトランザクションが互いに干渉することなく並列に実行できることを前提としています。
Monadがトランザクションを並列実行する場合、それらが同じ時点から開始されると仮定します。複数のトランザクションが並行して実行されると、チェーンは各トランザクションに対して保留中の結果を生成します。この場合、保留結果とは、トランザクションの入力と出力を追跡し、それらがステートにどのように影響するかを追跡するためにチェーンが行うブックキーピングを指す。これらの保留結果は、トランザクションの本来の順序で（つまり優先コストに基づいて）表示される。
保留中の結果を提出するために、入力がまだ有効であることを確認するためにチェックされます。保留中の結果の入力が変更/修正されている場合（つまり、トランザクションが同じ口座にアクセスするために並行して動作せず、互いに影響し合うような場合）、トランザクションは順次処理されます。処理される（後のトランザクションが再実行される）。再実行は正しさを維持するためだけに行われる。その結果、トランザクションに時間がかかるのではなく、より多くの計算が必要になる。
最初の実行反復において、Monadはすでに他のトランザクションとの競合や依存関係をチェックしている。したがって、トランザクションが2回目に実行されるとき（最初の楽観的並列実行が失敗した後）、ブロック内の以前のトランザクションはすべて実行済みであり、2回目の試みが成功することが保証される。モナド内のすべてのトランザクションが互いに依存している場合でも、それらは単に順次実行され、並列化されていない別のEVMと同じ結果を生成します。
Monadは実行中に各トランザクションの読み取りセットと書き込みセットを追跡し、結果を元のトランザクションの順序でマージします。並行して実行されているトランザクションが（以前のトランザクションが読み取ったものを更新したために）古いデータを使用している場合、Monadはマージ中にこれを検出し、正しい更新された状態でトランザクションを再実行します。これにより、最終結果はブロックの逐次実行と同じになり、イーサネット互換のセマンティクスが維持されます。この再実行には最小限のオーバーヘッドしかありません。署名検証やデータロードのような高価なステップを最初から繰り返す必要はありませんし、多くの場合、必要な状態は最初の実行時にすでにメモリにキャッシュされています。
例:
初期状態では、ユーザーAは100 USDC、ユーザーBは0 USDC、ユーザーCは300 USDCを持っています
3つのトランザクションがあります。
*トランザクション1：ユーザーAはユーザーBに10 USDCを送ります
*トランザクション2：ユーザーAはユーザーCに10USDC
シリアル実行プロセス シリアル実行を使用すると、プロセスは単純になりますが、効率は悪くなります。
*ユーザーAはまずユーザーBに10 USDCを送ります。
*その後、ユーザーAはユーザーCに10 USDCを送ります。
シリアル実行プロセスはよりシンプルですが、効率的ではありません。align:center">
最終状態では、シリアル実行（非モナド）の場合:
*ユーザーAには80 USDCが残ります（BとCにそれぞれ10 USDCを送りました）。
*ユーザーBには10 USDCがあります。
*ユーザーCには310 USDCがあります。
並列実行プロセス
並列実行では、プロセスはより複雑になりますが、より効率的です。各トランザクションが順番に完了するのを待つのではなく、複数のトランザクションが同時に処理されます。トランザクションは並行して実行されるが、システムはそれらの入出力を追跡する。逐次的な "マージ "段階で、トランザクションが以前のトランザクションによって変更された入力を使用していることが検出された場合、トランザクションは更新された状態で再実行される。
ステップバイステップのプロセスは次のとおりです：
*ユーザーAは最初に100 USDCを持ち、ユーザーBは最初に0 USDCを持ち、ユーザーCは最初に300 USDCを持ちます。
*ユーザーBは最初に0 USDCを持ちます。align: left;">*楽観的並列実行により、複数のトランザクションが同時に実行され、最初はすべて同じ初期状態から動作すると仮定します。
*この場合、トランザクション1とトランザクション2が並行して実行される。
*トランザクション1はユーザーAからユーザーBに10 USDCを送るようにスケジュールされており、ユーザーAの残高は90に減り、ユーザーBの残高は10に増える。
*同時に、トランザクション2もユーザーAの初期残高を100と読み取り、ユーザーAの残高を90に、ユーザーCの残高を310に減らすために、ユーザーCに10 USDCを送金する予定である。
*チェーンがこれらのトランザクションを順次検証する際、まずトランザクション1をチェックする。
*チェーンがトランザクション2を検証すると、問題が見つかる。トランザクション2はユーザーAが100 USDCを持っていると仮定して計画されたが、ユーザーAは現在90 USDCしか持っていない。は再実行されなければならない。
*再実行中に、トランザクション2はユーザーAの更新されたステータスを90 USDCと読み取ります。
*トランザクション2はユーザーAの更新されたステータスを90 USDCと読み取ります。align: left;">*この場合、ユーザーAには両方の送金を行うのに十分な資金があるため、両方の取引が正常に完了します。
並列実行(Monad)の最終状態:
結果は同じです:
*ユーザーAには80 USDCが残ります（10 USDCがそれぞれBとCに送られます）。
*ユーザーBには10 USDCが残ります。
*ユーザーCには310 USDCが残ります。
*ユーザーDには100 USDCが残ります！
5.実行の遅延
ブロックチェーンが取引を検証してコンセンサスに達するとき、世界中のノードが互いに通信しなければなりません。このグローバルな通信は、東京とニューヨークのような長距離の地点間をデータが移動するのに時間がかかるため、物理的な制約にぶつかる。
ほとんどのブロックチェーンは、実行とコンセンサスが緊密に結びついた逐次的なアプローチを採用している。これらのシステムでは、ノードはブロックを確定する前にトランザクションを実行しなければなりません。
以下はその詳細です：
次のブロックを始める前にブロックを確定するために、コンセンサスに先立って実行が行われます。リーダーは提案されたブロックを共有する前にそのブロック内のすべてのトランザクションを実行しなければならず、検証ノードはコンセンサスを得る前に各トランザクションを実行しなければならない。このプロセスは、コンセンサスを得るために複数ラウンドのグローバル通信を行いながら2回行われるため、実行時間が制限される。例えば、イーサのブロックアウト時間は12秒ですが、実際の実行時間はわずか100ミリ秒です（実際の実行時間はブロックの複雑さやガスの使用量によって大きく異なります）。
システムによっては、タスクをより小さなセグメントに分割し、プロセス間で交互に実行するインターリーブ実行によって、これを最適化しようとしています。処理は依然としてシーケンシャルであり、任意の時点で単一のタスクが実行されますが、高速な切り替えにより重要な並行性が生まれます。しかし、このアプローチでは、実行とコンセンサスが依然として相互に依存しているため、スループットが根本的に制限されます。
Monad は、コンセンサスから実行を切り離すことで、逐次実行とインターリーブ実行の制限を解決します。つまり、2つの並列処理が行われます。
*ノードはコンセンサスが得られたトランザクションを実行します。
*コンセンサスは、実行の完了を待たずに次のブロックに進み、コンセンサスに従って実行する。
この構造により、システムは実行開始前にコンセンサスを通じて大量の作業をコミットすることができ、Monadは追加の時間を割り当てることで、より大きなブロックとより多くのトランザクションを処理できるようになる。さらに、各プロセスがブロック時間全体を独立して使用できるようになります。コンセンサスはブロック時間全体をグローバル通信に使用でき、実行はブロック時間全体を計算に使用でき、2つのプロセスが互いにブロックすることはありません。
コンセンサスから実行を切り離しながらセキュリティと状態の一貫性を維持するために、Monadは遅延Merkle根を使用します。各ブロックはN個のブロック前状態Merkle根を含み（Nは起動時に10になると予想され、現在のテストネットワークでは3に設定されています。を実行後に検証することができる。遅延Merkleルートはチェックポイントとして機能し、Nブロック後にノードは同じステートルートに到達したことを証明しなければならない。さらに、ノードの実行により異なるステートルートが生成された場合、Nブロック後にこれを検出し、ロールバックして再実行し、コンセンサスを得ることができます。これにより、ノードによる悪意のある行動のリスクを排除することができる。生成された遅延Merkleルートは、Nブロックの遅延にもかかわらず、状態の軽いクライアント検証に使用することができます。
実行が遅延し、コンセンサス後に発生するため、潜在的な問題は、悪意のある行為者（または偶然の一般ユーザー）が、資金不足のために最終的に失敗するトランザクションを送信し続けることです。例えば、総残高が10モンのユーザーが5つのトランザクションを提出し、各トランザクションが個別に10モンを送信しようとした場合、これは問題を引き起こす可能性がある。しかし、チェックを行わないと、これらのトランザクションはコンセンサスを通過しても、実行中に失敗する可能性がある。この問題に対処し、潜在的なスパムを減らすために、ノードはコンセンサス中のトランザクションを追跡することで保護手段を実装する。
各アカウントについて、ノードはNブロック前のアカウント残高をチェックする（これは検証された最新の正しい状態であるため）。
ノードはNブロック前のアカウント残高をチェックします（これが検証された最新の正しい状態です）。"text-align: left;">このプロセスは、コンセンサス中に新しいトランザクションを検証するために使用される実行中の「利用可能残高」を作成します。新しいトランザクションの値と最大ガスコストがこの利用可能残高を超えた場合、トランザクションはコンセンサス中に拒否される。
モナドのコンセンサスは（実行のデカップリングにより）少し遅れたステートビューで行われるため、送信者が最終的に支払うことができないトランザクションを含むことに対する保護を実装している。モナドでは、各アカウントはコンセンサス期間中、利用可能な、あるいは「リザーブ」残高を持つ。トランザクションが提案されたブロックに追加されると、プロトコルはこの利用可能残高からトランザクションの可能な最大コスト（gas * max fee + value transferred）を差し引く。アカウントの利用可能残高がゼロ以下になると、そのアカウントの取引はブロックに含まれなくなります。
この仕組み（予備残高に輸送コストを課すと表現されることもある）により、支払い可能な取引のみが提案されるようになり、無駄な取引のために0資金でネットワークを溢れさせようとする攻撃者によるDoS攻撃を防御することができます。ブロックが確定して実行されると、それに応じて残高が調整されますが、Monadノードはコンセンサスフェーズの間、保留中のトランザクションの使用可能残高を常に最新の状態でチェックすることができます。
6.モナドBFT
(1)コンセンサス
HotStuff
MonadBFTは、低レイテンシー、高スループットのビザンチンフォールトトレラント（「BFT」）コンセンサスメカニズムです。HotStuffコンセンサスから派生したものです。
HotstuffはVMresearchによって作成され、Metaの元ブロックチェーンチームのLibraBFTによってさらに改良されました。HotStuffはまた、効率化のために閾値署名を使用し、パイプライン操作を実装して、前のブロックがコミットされる前に新しいブロックが提案されることを可能にします。
しかしながら、これらの利点はある種のトレードオフを伴います：余分なラウンドは、古典的な2ラウンドBFTプロトコルと比較して、より高い待ち時間とパイプライン中にフォークする可能性をもたらします。これらのトレードオフにもかかわらず、HotStuffの設計は、2ラウンドのBFTプロトコルよりも最終的な処理が遅くなるにもかかわらず、大規模なブロックチェーンの実装に適しています。
以下がHotStuffの詳細です：
*トランザクションが発生すると、リーダー（Leader）と呼ばれるネットワーク上の検証者に送られます。align: left;">*リーダーはこれらのトランザクションをブロックにまとめ、ネットワーク上の他のバリデータにブロードキャストする。
*検証者は投票によってブロックを検証し、次のブロックのリーダーに送られます。
*悪意のあるアクターや通信障害から守るため、ブロックは最終的な状態を決定するために何度も投票を繰り返さなければなりません。
*特定の実装にもよりますが、ブロックは2ラウンドから3ラウンドを通過した後にのみ提出することができ、強固で安全なコンセンサスを保証します。
MonadBFT は HotStuff から派生したものですが、独自の修正や新しい概念を導入しており、さらに探求することができます。
トランザクションプロトコル
MonadBFTは特に、部分的な同期条件下でトランザクションプロトコルを実装するように設計されています。-つまり、メッセージの待ち時間が予測できない非同期期間中であっても、チェーンはコンセンサスに達することができます。
最終的にネットワークは安定し、（既知の時間枠内で）メッセージを配信します。これらの非同期期間はMonadのアーキテクチャに起因しており、チェーンは速度、スループット、並列実行を向上させるために特定のメカニズムを実装する必要があります。
DiemBFT
当初3ラウンドシステムを実装していたHotStuffとは異なり、MonadBFTはJolteonのようなものを使用しています、DiemBFTとFast HotStuffの2輪システムを採用しています。
「ラウンド」は以下の基本的なステップで構成されます：
*各ラウンドで、リーダーは新しいブロックと前のラウンドの証明書（QCまたはTC）をブロードキャストします。TC)をブロードキャストする。
*各検証者はブロックをレビューし、次のラウンドで署名票をリーダーに送る
*十分な票（2/3）が集まると、QCが形成される。一方、TCはコンセンサスラウンドが失敗し、再開する必要があることを示す。
"Dual-round" は特に提出ルールを指します。
*第1ラウンド: 最初のブロックが提案され、QCを受ける
*第2ラウンド: 次のブロックが提案され、QCを受ける
両方のラウンドが連続して完了した場合、最初のブロックを提出することができます。.
DiemBFTはかつて3ラウンド制を採用していたが、2ラウンド制にアップグレードした。2ラウンドシステムは、通信ラウンド数を減らすことでコミットの高速化を可能にする。トランザクションは追加の確認を待つ必要がないため、より速く送信することができ、待ち時間を短縮することができる。
正確なプロセス
MonadBFTのコンセンサスプロセスは以下の通りです：
*リーダーは、QCまたはTCの形で、前のラウンドのコンセンサスの証明とともに、ユーザーのトランザクションを含む新しいブロックを作成し、ブロードキャストする。これは、各ブロック提案が前のブロックの証明を運ぶパイプライン構造を作成する。
プロセスは以下のとおりである。
*バリデーターの作業：バリデーターはリーダーのブロックオファーを受け取ると、バリデーションを開始する。各バリデータはプロトコルのルールに従ってブロックの有効性を精査する。有効なブロックは、署名されたYES票を受け取り、次のラウンドのリーダに送られる。しかし、有効なブロックを期待された時間内に受信できなかった場合、 Validatorは既知の最高QCを含む署名タイムアウトメッセージをブロードキャストすることで、タイムアウトプロセスを開始する。このデュアルパスアプローチは、ブロックプロポーザルが失敗してもプロトコルが進行できることを保証します。
*証明書の作成：プロトコルは、コンセンサスの進捗を追跡するために2種類の証明書を使用する。QCは、リーダーがバリデータの3分の2からYESの票を集めたときに作成され、ブロックに関する広範なコンセンサスを証明する。あるいは、バリデータの3分の2が有効な提案を受け取らずにタイムアウトした場合、TCが作成され、プロトコルは安全に次のラウンドに進むことができる。どちらの証明書も、バリデータの参加を証明する重要な役割を果たす。
*ブロックファイナライズ（2チェーン提出ルール）: MonadBFTはブロックファイナライズに2チェーン提出ルールを使用する。検証者は、連続するラウンドの隣接する2つの認証ブロックがB←QC←B'←QC'の連鎖を形成していることを確認すると、ブロックBとそのすべての先祖を安全に提出することができます。この2チェーンのアプローチは、パフォーマンスを維持しながら、セキュリティとアクティビティを提供します。
ローカルメモリプールアーキテクチャ
モナドは従来のグローバルメモリプールの代わりにローカルメモリプールアーキテクチャを採用しています。ほとんどのブロックチェーンでは、保留中のトランザクションはすべてのノードにブロードキャストされますが、これは冗長な送信のために時間がかかり（ネットワークホップが多い）、帯域幅を消費します。対照的にMonadでは、各検証者が独自のメモリプールを維持し、トランザクションはRPCノードによって、次に予定されている数人のリーダー（現在は次のN = 3リーダー）に直接転送され、取り込まれます。
これにより、既知のLeaderのスケジュールを利用し（Leader以外への不要なブロードキャストを回避）、新しいトランザクションが迅速にブロック提案者に到達することが保証される。次のLeaderはバリデーションチェックを行い、そのトランザクションをローカルメモリプールに追加する。この設計は伝播レイテンシーを減らし、帯域幅を節約し、より高いスループットを可能にする。
(2)ラプターキャスト
モナドはラプターキャスト（RaptorCast）と呼ばれる特殊なマルチキャストプロトコルを使用して、リーダーからすべての検証者にブロックを迅速に伝達します。完全なブロックを各ピアに連続的に送ったり、単純なブロードキャストに頼ったりするのではなく、Leaderは修正符号化スキーム（RFC 5053による）を使ってブロック・プロポーザルのデータを符号化されたブロックに分割し、これらのブロックを2レベルのリレーツリーを通して効率的に配布します。実際には、Leaderは異なるブロックを第1層の検証ノードに送信し、検証ノードはそのブロックを他のノードに転送することで、各検証ノードは最終的に完全なブロックを再構築するのに十分なブロックを受信する。ブロックの割り当ては、負荷分散を確実にするため、公平性によって重み付けされる（各検証者はブロックの一部を転送する責任を負う）。このようにして、ネットワーク全体のアップロード容量が、メッセージをドロップする可能性のあるビザンチン(悪意のある、または欠陥のある)ノードに寛容でありながら、待ち時間を最小限に抑え、ブロックを迅速に伝播するために使用されます。
BLSとECDSA署名
QCとTCは、2つの異なるタイプの暗号方式であるBLSとECDSA署名を使用して実装されています。デジタル署名方式を使用して実装されています。
Monadはセキュリティとスケーラビリティを高めるためにBLS署名とECDSA署名の組み合わせを使用します。BLS署名は署名の集約をサポートし、ECDSA署名は一般的に検証が高速です。
ECDSA署名
署名を集約することはできませんが、ECDSA署名ははるかに高速であり、MonadはQCとTCの両方にECDSA署名を使用します
QCは以下のように作成されます：
*リーダーがブロックを提案する
*検証者が署名による投票で同意する
*必要な部分の票が集まったら、それらを組み合わせてQCを形成することができる。
*QCは検証者がブロックに同意したことを証明する
TCが作成される:
*あらかじめ決められた時間内にベリファイアが有効なブロックを受け取らなかった場合
*署名されたタイムアウトメッセージをピアにブロードキャストする
*タイムアウトメッセージを十分に集めると、そのメッセージはピアに送信される。
*TCは現在のラウンドが失敗しても次のラウンドに進むことができます
BLS署名Monadはマルチ署名にBLS署名を使用します。シグネチャを徐々に単一のシグネチャに集約することができます。これは主にポーリングやタイムアウトのような集約可能なメッセージタイプに使用されます。
投票は、ベリファイアが提案されたブロックに同意したときに送信されるメッセージである。
タイムアウトは、バリデータが有効なブロックを予定時間内に受け取れなかった場合に送るメッセージである。タイムアウトには、現在のラウンド番号、ベリファイアの最高QC値、そしてそれらの値に対する署名が含まれる。
ポーリングとタイムアウトの両方は、スペースを節約し効率を高めるために、BLS署名を使用して結合/集約することができます。先に述べたように、BLSはECDSA署名よりも比較的遅い。
MonadはECDSAとBLSを組み合わせて使用し、両方の効率性の恩恵を受けています。BLSスキームはより遅いですが、署名の集約が可能であるため、ポーリングやタイムアウトに特に適しています。
7.モナドMEV
簡単に言えば、MEVとは、ブロックからトランザクションを並べ替えたり、含めたり、除外したりすることで、当事者が抽出できる価値のことです。MEVはしばしば「良い」MEV、つまり市場を健全かつ効率的に保つMEV（清算、裁定取引など）と「悪い」MEV（サンドイッチ攻撃など）に分類されます。
モナドの遅延実行は、MEVがオンチェーンでどのように機能するかに影響します。イーサでは、実行はコンセンサスの前提条件です。つまり、ノードがブロックに合意するとき、彼らはトランザクションのリストと順序、そして結果の状態に合意します。新しいブロックを提案する前に、リーダーはすべてのトランザクションを実行し、最終的な状態を計算する必要があります。これにより、検索者やブロックビルダーは、最近確認された状態に対するトランザクションを確実にシミュレートできるようになります。
対照的に、モナドではコンセンサスと実行は切り離されている。ノードが合意する必要があるのは、最新のブロックにおけるトランザクションの順序だけであり、状態に関する合意は後で得られるかもしれない。このことは、バリデータが以前のブロックの状態データに基づいて動作する可能性があり、最新のブロックに対するモデリングができないことを意味する。確認された状態情報の欠如に伴う複雑さに加えて、Monadの1秒のブロック外時間は、構築者が構築されたブロックを最適化するためにブロックをシミュレートすることを困難にするかもしれない。
最新の状態データへのアクセスは、確定した資産価格、流動性プールの残高、DEX上のスマートコントラクトの状態などを提供するため、検索者にとって必要です。イベント。最新のステータスデータが確認されていない場合、サーチャーは次のブロックが生成される前にブロックをシミュレートすることができず、ステータスが確認される前に取引をロールバックするリスクがあります。
モナドブロックの遅延を考えると、MEVの状況はソラナと似ている可能性が高い。
背景として、ソラナでは、ブロックは400ミリ秒ごとにスロットで生成されますが、ブロック生成から「ルーティング」（確定）までの時間ははるかに長く、通常は2000～4000ミリ秒です。-通常2000-4000ミリ秒。この遅延は、ブロック生成そのものからではなく、ブロックを確定するのに十分な株式加重票を集めるのにかかる時間から生じます。
この投票期間中、ネットワークは新しいブロックを並行して処理し続けます。取引コストが非常に低く、新しいブロックを並行して処理できるため、検索者は自分が含まれることを期待して大量のトランザクションを送信する「底辺への競争」が生じ、その結果、多くのトランザクションがロールバックされることになる。例えば、12月中にソラナ上の31.6億の議決権のない取引のうち13億（約41％）がロールバックされ、ジトのバファルは2023年に「ソラナ上の裁定取引の98％は失敗する」と強調した。
モナドでも同様のブロック遅延効果があり、最新のブロックの確認状況情報が利用できず、新しいブロックが並行して処理されるため、検索者は大量の取引を送信するインセンティブが働く可能性があります。取引はロールバックされ、シミュレーションに使用した状態とは異なる状態で確認されるため、失敗する可能性があります。
8.MonadDB
モナドは、ブロックチェーンのデータを保存しアクセスするために、MonadDBと呼ばれるカスタムデータベースを構築することを選択しました。Paradigmは4月、状態成長に関する短い研究論文を発表し、状態成長、履歴成長、状態アクセスの違いを強調した。これは、ノードのハードウェア性能に関する異なる概念であるにもかかわらず、しばしば混同されていると主張しています。
彼らが指摘するように、
*状態の成長は、新しいアカウント（アカウント残高と乱数）とコントラクト（コントラクトバイトコードとストレージ）の蓄積を指します。ノードは状態の成長に対応するために十分なストレージとメモリ容量を持つ必要があります。
*履歴の増加は、新しいブロックと新しいトランザクションの蓄積を指す。ノードには、ブロックデータを共有するための十分な帯域幅と、ブロックデータを保存するための十分なストレージ容量が必要です。
*ステートアクセスは、ブロックの構築と検証に使用される読み取りと書き込み操作を指します。
前述したように、データのサイズがノードの容量を超える可能性があるため、状態の増大と履歴の増大の両方がチェーンのスケーラビリティに影響します。ノードは、ブロックを構築、検証、配布するために、永続的なストレージにデータを保存する必要があります。さらに、ノードはチェーンと同期するためにメモリにキャッシュする必要がある。ブロックのサイズやブロックごとの操作に制限があるチェーンでは、状態の増加や履歴の増加、状態へのアクセスの最適化に対応する必要があります。ブロック内のデータが増え、ブロックごとの読み取りと書き込みの操作が増えれば増えるほど、履歴の増大と状態の増大は大きくなり、効率的な状態アクセスの必要性も高まります。
ステートの増加と履歴の増加はスケーラビリティにとって重要な要素ですが、特にディスク性能の観点からは大きな問題ではありません。その結果、ステートを16倍に増加させても、ステートの読み取りごとにディスクアクセスが1回増えるだけです。履歴の増加に関しては、チェーンが高性能である場合、ローカルに保存するデータが多すぎることになります。Solanaのような他の高スループット・チェーンは、履歴データを保存するためにGoogle BigTableのようなクラウド・ホスティングに依存しています。これは効果的ですが、中央集権的なパーティに依存しているため、分散化を犠牲にしています。
(1)状態アクセス
状態の成長と履歴の成長に加え、MonadDBの重要な実装の1つは、各ブロックの読み取りと書き込み操作を最適化することです（つまり、状態アクセスを改善する）。アクセスの改善）である。
イーサリアムは、状態を保存するためにMerkle Patricia Trie（「MPT」）を使用しています。MPTは、より効率的なデータ検索を可能にするために、データ検索アルゴリズムであるPATRICIAから機能を借用しています。
メルクル・ツリー メルクル・ツリー（「MT」）は、最終的にメルクル・ルートと呼ばれる単一のルート・ハッシュに還元されるハッシュの集合である。データのハッシュは、元のデータの固定サイズの暗号表現です。メルクル・ルートは、単一のハッシュ（メルクル・ルート）が残るまで、データのペアを繰り返しハッシュ化することで作成されます。メルクル・ルートの有用性は、各リーフ・ノードを個別に検証する必要なく、リーフ・ノード（すなわち、ルートを作成するために繰り返しハッシュ化される個々のハッシュ）の検証を可能にすることです。
これは、特にブロックごとに多くのトランザクションがある大規模なシステムにおいて、各トランザクションを個別に検証するよりもはるかに効率的です。個々のデータ間に検証可能な関係を作り出し、トランザクションとルートを再構築するのに必要な中間ハッシュ（n個のトランザクションの代わりにlog(n)個のハッシュ）を提供することで、トランザクションがブロックに含まれていることを証明できる「Merkle証明」を可能にします。
メルクルパトリシアトライ
メルクルツリーは、トランザクションが静的であるビットコインのニーズに適しています。トランザクションがブロック内に存在することを証明することである。しかし、Etherのユースケースにはあまり適していません。Etherは、保存されたデータ（例えば、口座残高や乱数、新しい口座の追加、保存されているキーの更新など）を取得・更新する必要があり、単にそれが存在することを検証するだけではありません。
Merkleパトリシア・トライ（「MPT」）は、状態データベースのキーと値のペアを格納し検証するための修正Merkleツリーです。MTがデータの範囲（トランザクションなど）を取り、それらをペア単位でのみハッシュするのに対して、MPTはデータを辞書のように整理する - 各データ（値）には、それを格納する特定のアドレス（キー）がある。このキー・バリュー・ストレージは、Patricia Trieによって実装されています。
イーサネットは、取得する必要があるデータに応じて、異なるタイプのキーを使用して、異なるタイプのTrieにアクセスします。
*State-of-the-world Trie: アドレスとアカウント状態のマッピングを含みます。
*Account Storage Trie: スマートコントラクトに関連するデータを格納します。
*Transaction Trie: ブロックに含まれるすべてのトランザクションが含まれます。
*Receipt Trie: トランザクションの実行に関する情報を含むトランザクションのレシートを格納します。
*Trie は、さまざまなタイプのキーを介して値にアクセスし、残高の確認、契約コードの存在の確認、特定の口座データの検索など、チェーンがさまざまな機能を実行できるようにします。
注：イーサネットは、「イーサネットノードをアップグレードして、ブロックを検証する能力を失うことなく、大量の状態データの保存を停止する」ために、MPTからバークルツリーへの移行を計画しています。
Monad DB: Patricia Trie
イーサとは異なり、MonadDbはディスク上とメモリ上にローカルに実装しています。Patricia Trieデータ構造を実装しています。
前述したように、MPTはMerkle Treeデータ構造とキー値検索のためのPatricia Trieを組み合わせたもので、2つの異なるデータ構造が統合/結合されています。検証。これは、ハッシュベースのノード参照の複雑さを増加させ、Merkleは各ノードでハッシュのための追加のストレージを必要とするため、追加のオーバーヘッドにつながります。
パトリシア・トライ・ベースのデータ構造により、MonadDBは以下のことが可能になります:
*よりシンプルな構造: ノードごとにMerkleハッシュがなく、ノード関係にはハッシュ参照がありません。キーと値のみを直接格納する。*直接パスの圧縮：データに到達するために必要なルックアップの回数を減らす。*ローカル・キーバリュー・ストレージ：MPTはPatricia Trieを別のキーバリュー・ストレージ・システムに統合していますが、Patricia Trieのローカル機能はキーバリュー・ストレージであり、より良い最適化が可能です。*データ構造の変換が不要：Trieフォーマットとデータベース・フォーマット間の変換が不要です。これらにより、MonadDBは比較的低い計算オーバーヘッドを持ち、より少ないストレージスペースを必要とし、より高速な操作（検索または更新）を可能にし、実装をよりシンプルに保つことができます。
非同期I/O
トランザクションはMonad上で並列に実行されます。
MonadDBは最新の非同期I/O実装をサポートしており、多数のスレッドを作成することなく複数のオペレーションを処理することができます
MonadDBは最新の非同期I/O実装をサポートしています。-複数のディスク操作を処理するために複数のスレッドを作成しなければならない他の伝統的なキー・バリュー・データベース（LMDBなど）とは異なり、管理するスレッドの数が少ないため、オーバーヘッドが少なくなります。
暗号化領域における入出力処理の簡単な例は次のとおりです：
*入力：取引前に口座残高を確認するためにステータスを読み込む*出力：送金後に口座残高を書き込む/更新する非同期I/Oにより、入出力処理（読み取りと更新など）が可能になります。非同期I/Oは、前のI/O操作が完了していなくても、入出力処理（ストレージへの読み書き）を可能にする。モナドでは複数のトランザクションが並行して実行されるため、これが必要である。そのため、あるトランザクションがデータの読み書きのためにストレージにアクセスする必要がある一方で、別のトランザクションがまだストレージからの読み書きを続けている。同期I/Oでは、プログラムは一度に1つのI/O操作を順次実行する。同期I/O処理でI/O操作が要求されると、トランザクションは前の操作が完了するまで待つ。例えば、
*同期I/O: チェーンはtx/ブロック#1をstate/storageに書き込む。チェーンはその完了を待つ。非同期I/O：チェーンはtx/ブロック#1、tx/ブロック#2、tx/ブロック#3を同時にステート/ストレージに書き込む。これらは独立して行われる。
(2) StateSync
MonadにはStateSyncメカニズムがあります。StateSyncは、ノード（「クライアント」）がピア（「サーバー」）からターゲットブロックへの最新の状態のスナップショットを要求することを可能にします。ステートデータはブロック（アカウントステートの一部や最新のブロックヘッダなど）に分割され、複数のバリデータピアに分散して負荷を分担する。各サーバーは要求されたステートブロックに応答し（MonadDbのメタデータを使用して、必要なトライノードを素早く取得する）、クライアントはこれらのブロックを組み立ててターゲットブロックのステートを構築する。チェーンは成長しているため、同期が完了すると、ノードはトップに近いところで再度StateSyncを実行するか、最近のブロックを少数再生して完全に追いつく。このチャンク化されたStateSyncは、ノードのブートストラップとリカバリーを大幅に加速し、Monadの状態が大きくなっても、新しいバリデータが何時間も遅れることなく、参加または再開して完全に同期できることを保証します。
9.エコシステム
(1)エコシステムの努力
モナド・チームは、そのチェーンのために強力で堅牢なエコシステムを開発することに注力しています。ここ数年、L1とL2の競争は、パフォーマンスへの主眼から、ユーザー向けのアプリケーションや開発者ツールへとシフトしています。チェーンはもはや、高TPS、低遅延、低料金を売り物にするだけでは十分ではなく、DePINからAIまで、DeFiからコンシューマーまで、多種多様なアプリケーションを網羅するエコシステムを提供しなければならなくなっている。これがますます重要になっている理由は、Solana、Sui、Aptos、Hyperliquidなど、高性能で低コストの開発環境とブロックスペースを提供する高性能L1や低コストL1が急増していることです。ここでのMonadの強みの1つは、EVMを使用していることです。前述したように、MonadはEVMバイトコードとEthernet RPC APIの完全な互換性を提供しており、開発者とユーザーは既存のワークフローを変更することなく統合することができます。EVMの拡張に取り組んでいる人々に対するよくある批判は、SVMやMoveVMのような、より効率的な代替手段があるということです。しかし、もしチームが費用を抑えながら、ソフトウェアとハードウェアの改善を通じてEVMのパフォーマンスを最大化できるのであれば、既存のネットワーク効果、開発者ツール、および簡単にアクセスできる資本基盤があるため、EVMの拡張は理にかなっています。
Monadの完全なEVMバイトコード互換性により、ETH Main、Arbitrum、OP Stackなどの他の標準EVMからアプリケーションやプロトコルインスタンスをコード変更なしで移植することができます。この互換性には利点と欠点の両方があります。主な利点は、既存のチームが自分のアプリケーションを簡単にMonadに移植できることです。さらに、Monad向けに新しいアプリケーションを作成する開発者は、Etherscanだけでなく、Hardhat、Apeworx、Foundry、Rabby、Phantomのウォレットなど、EVM向けに開発された豊富なリソース、インフラ、ツールを利用することができます、Parsec、Duneなどの分析およびインデックス作成製品があります。
簡単に移植可能なプロトコルやアプリの欠点の1つは、チェーン上で怠惰で非効率的なフォークやアプリの起動につながる可能性があることです。チェーンが多くの製品を利用できるようにすることは重要だが、ほとんどは他のチェーンではアクセスできない独自のアプリケーションであるべきだ。例えば、ほとんどのチェーンがUniswap V2スタイルや集中流動性ベースのAMMを必要とする一方で、チェーンはユーザーを惹きつけるために新しいクラスのプロトコルやアプリケーションも惹きつけなければならない。既存のEVMツールと開発者リソースは、斬新でユニークなアプリケーションを可能にするのに役立ちます。加えて、Monadチームは、チェーン上の斬新なプロトコルやアプリケーションを奨励するために、アクセラレーターからベンチャーキャピタルコンペティションまで、様々なプログラムを実施してきました。
(2)エコシステムの概要
Monadは高いスループットと最も低い取引手数料を提供し、CLOBなどの特定のタイプのアプリケーションに最適です、Monadは、高いスループットと最低の取引手数料を提供し、CLOB、DePIN、コンシューマー・アプリケーションなど、高速で低コストの環境から利益を得るのに理想的な特定のタイプのアプリケーションに最適です。
Monadに適した特定のカテゴリーを掘り下げる前に、アプリケーションがL2ではなくL1で起動したり、独自のL1/L2/アプリケーションチェーンを起動したりする理由を理解することが役に立つかもしれません。
一方では、うるさい隣人に対処する必要がないため、独自のL1、L2、またはアプリチェーンを始めることは有益かもしれません。ブロックスペースはすべて自分のものなので、アクティビティの多い時間帯の混雑を避け、ネットワーク全体の負荷に関係なく安定したパフォーマンスを維持することができます。これはCLOBやコンシューマーアプリケーションにとって特に重要です。混雑時には、トレーダーはトランザクションを実行できないかもしれませんし、Web2のパフォーマンスを期待している日常的なユーザーは、速度低下やパフォーマンス低下のためにアプリケーションを使用できないかもしれません。
一方、独自のL1チェーンやアプリチェーンを立ち上げるには、バリデータのセットをブートストラップする必要があり、さらに重要なのは、チェーンを利用するために流動性と資本を橋渡しするインセンティブをユーザーに与えることです。Hyperliquidは独自のL1を立ち上げ、ユーザーを集めることに成功したが、そうできなかったチームも多い。オンチェーンを構築することで、チームはネットワーク効果の恩恵を受けることができ、二次的、三次的な流動性効果を提供し、他のDeFiプロトコルやアプリケーションと統合することができる。また、効率的かつ効果的に行うことが難しいインフラやスタックの構築に注力する必要もなくなる。アプリやプロトコルの構築は、L1やアプリチェーンの構築とは大きく異なることに注意することが重要です。
独自のL2を開始することで、これらのプレッシャーの一部を軽減することができます。特に、クリックトゥデプロイのロールアップ・アズ・ア・サービス・プロバイダーが存在するため、バリデータセットのブートストラップとインフラ構築に関連する技術的な問題を軽減することができます。しかし、これらの L2 は一般的に特に効率的ではなく（大半はまだコンシューマアプリケーションや CLOB の TPS をサポートしていない）、集中化に伴うリスクを抱えていることが多い（大半はまだステージ 0 である）。さらに、低いアクティビティやユーザー操作/秒 (UOPS) のような、モビリティやアクティビティの断片化に関連する欠点にもまだ直面しています。
*CLOB
完全にオンチェーンのオーダーブックは、DEX業界のベンチマークとなっています。以前はネットワークレベルの制約やボトルネックのために不可能でしたが、最近の高スループットと低コスト環境の急増は、オンチェーンCLOBが可能になったことを意味します。以前は、高いガス料金（オンチェーンでの注文は高価）、ネットワークの混雑（必要な取引量による）、レイテンシーの問題により、オンチェーン・オーダー・ブックのみで取引を行うことは現実的ではありませんでした。加えて、CLOBマッチングエンジンで使用されるアルゴリズムは多大な計算資源を消費するため、オンチェーンでの実装は困難でコストがかかります。
完全にオンチェーンのオーダーブックに基づくモデルは、従来のオーダーブックの利点と、取引の執行とマッチングの完全な透明性を兼ね備えています。すべての注文、取引、マッチングエンジン自体がブロックチェーン上に存在するため、取引プロセスのあらゆるレベルで完全な可視性が確保される。このアプローチにはいくつかの重要な利点がある。第一に、取引の決済だけでなく、すべての取引がチェーン上に記録されるため、完全な透明性が確保され、完全な監査が可能になります。
第二に、注文の発注と取消しのレベルで先取り取引の機会を減らすことでMEVを緩和し、システムをより公正で不正操作に強いものにします。
最後に、オーダーブックとマッチングプロセス全体がオンチェーンに存在するため、信頼の前提がなくなり、操作のリスクが低減します。対照的に、オフチェーンのオーダーブックはこれらの点で妥協しており、注文の発注とマッチングプロセスの完全な透明性がないため、インサイダーが取引やオーダーブックオペレーターの操作を先取りできる可能性があります。
オンチェーンオーダーブックはオフチェーンオーダーブックを上回る利点がありますが、AMMを上回る大きな利点もあります：
AMMは通常、LVRやILの結果として流動性プロバイダーを失うことによる価格スリッページに悩まされます。AMMは通常、LVRやILの結果、流動性供給者を失うことによる価格変動に悩まされ、古い価格設定による裁定取引を利用されやすいのですが、オンチェーン・オーダー・ブックは流動性供給者がILやLVRにさらされることを排除します。そのリアルタイムのオーダー・マッチングは、時代遅れの価格設定を防ぎ、効率的な価格発見を通じて裁定取引の機会を減らす。しかし、AMMは無許可取引とアセット・リスティングを可能にし、新規で流動性の低いトークンの価格発見を可能にするため、リスクが高く流動性の低いアセットには利点がある。前述したように、Monadのブロック時間が短いことから、LVRはいくつかの代替案よりも問題が少ないことに注意することが重要です。
注目すべきプロジェクトにはKuru、Yamata、Composite Labsなどがあります。
*DePIN
ブロックチェーンは、検閲に強いグローバルな共有状態と、高速なトランザクションと決済時間のため、本質的に決済の処理に適しています。しかし、決済や価値移転を効率的にサポートするためには、チェーンは低額で予測可能な手数料と迅速な最終処理を提供する必要がある。高スループットのL1として、MonadはDePINアプリケーションのような新たなユースケースをサポートすることができます。DePINアプリケーションは、大量の支払いだけでなく、効率的にハードウェアを検証し管理するためのオンチェーン・トランザクションも必要とします。
歴史的に見て、DePINアプリケーションの大半がSolana上でローンチされるのを見てきました。ローカライズされた手数料市場により、他のチェーンが混雑しているときにソラーナは低コストの取引を提供できる。さらに重要なのは、ソラナが多くのDePINアプリの誘致に成功しているのは、ネットワーク上に既存のDePINアプリが多数存在するからである。歴史的に、DePINアプリは決済が遅く手数料が高いため、イーサ上で起動しなかった。DePINの人気が高まるにつれ、Solanaはここ数年、低手数料で高スループットの競合として台頭し、DePINアプリがそこでローンチすることを選択するようになりました。より多くのDePINアプリケーションがSolana上で起動することを選択するにつれて、DePIN開発者やアプリケーション、ツールキットやフレームワークの比較的大きなコミュニティが形成された。これにより、より多くのDePINアプリが、技術や開発リソースがすでに利用可能な場所での立ち上げを選択するようになりました。
しかし、高スループットで低料金のEVMベースの競合として、MonadにはDePINの注目とアプリを引きつけるチャンスがあります。そのためには、チェーンとエコシステムにとって、既存および新規のDePINアプリケーションを惹きつけるフレームワーク、ツールキット、エコシステム計画を開発することが重要である。DePINアプリは（L2またはL1として）独自のネットワークを構築しようとすることができますが、Monadは、ネットワーク効果、他のアプリとのコンポーザビリティ、深いモビリティ、および堅牢な開発者ツールを可能にする高スループットのベースレイヤーを提供します。
注目すべき点：SkyTrade
*ソーシャルおよび消費者向けアプリ
過去数年間、金融アプリが暗号空間を支配してきた一方で、消費者向けアプリやソーシャルアプリは近年ますます注目を集めています。これらのアプリは、クリエイターやソーシャル・キャピタルを活用したい人々に、別の収益化手段を提供している。また、検閲に強く、コンポーザブルで、ますます金融化されたバージョンのソーシャルグラフや体験を提供し、ユーザーが自分のデータをよりコントロールできるようにし、少なくともそこからより多くの利益を得られるようにすることを目指しています。
DePINのユースケースと同様に、ソーシャルアプリやコンシューマーアプリは、支払いや価値の移転を効率的にサポートできるチェーンを必要とします。ここで重要なのは、遅延と最終性である。現在、ウェブ2の体験は高度に最適化されているため、ほとんどのユーザーは同様の低遅延体験を期待している。決済、ショッピング、ソーシャル・インタラクションの遅い体験は、ほとんどのユーザーにとってフラストレーションとなる。分散型のソーシャルメディアや消費者向けアプリは、一般的に既存の中央集権型のソーシャルメディアや消費者向けアプリに負けていることを考えると、ユーザーと注目を集めるためには、同等かそれ以上のエクスペリエンスを提供する必要があります。
Monadの高速ファイナリティ・アーキテクチャは、ユーザーに低レイテンシで低コストのエクスペリエンスを提供するのに理想的です。
注目すべきプロジェクトは以下の通り: Kizzy、Dusted
Monadで構築されたCLOB、DePIN、Consumer/Socialアプリに加え
CLOB、DePIN、Monad上で構築されたConsumer/Socialアプリに加えて、アグリゲーターやLSD、AI製品のような新世代の基盤アプリにも期待しています。
ユニバーサル・チェーンは、ユーザーを引き付け、維持するために、幅広い製品ベースを持つ必要があります。これまでのところ、L2がそうであった。先に述べたように、ユーザーはArbitrumでオプション取引や永久契約のニーズを満たす必要があるかもしれないが、同時にソーシャルアプリケーションやコンシューマーアプリケーションに参加するためにBaseへのブリッジが必要かもしれない。