读懂Monad及其生态项目一览

文章来源：ASXN；编译：金色财经xiaozou

1、前言

Monad是一个高性能优化的EVM兼容L1，具有10,000 TPS（每秒10亿gas）、500毫秒的出块频率和1秒的最终性。该链从零开始构建，旨在解决EVM面临的一些问题，具体来说：

*EVM按顺序处理交易，导致网络高活动期间的瓶颈，从而延长交易时间，尤其是在网络拥堵时。

*吞吐量低，仅为12-15 TPS，且出块时间长，为12秒。

*EVM要求每笔交易支付gas费用，费用波动较大，尤其是在网络需求高时，gas费用可能变得极其昂贵。

2、为什么扩展EVM

Monad提供完整的EVM字节码和以太坊RPC API兼容性，使开发者和用户无需更改现有工作流程即可集成。

一个常见的问题是，当存在像SVM这样性能更好的替代方案时，为什么还要扩展EVM。与大多数EVM实现相比，SVM提供更快的出块时间、更低的费用和更高的吞吐量。然而，EVM具有一些关键优势，这些优势源于两个主要因素：EVM生态系统中的大量资本和广泛的开发者资源。

（1）资本基础

EVM拥有大量资本，以太坊的TVL接近520亿美元，而Solana为70亿美元。L2如Arbitrum和Base各自持有约25-30亿美元的TVL。Monad和其他EVM兼容链可以通过与最小摩擦集成的规范桥和第三方桥从EVM链上的大资本基础中受益。这一庞大的EVM资本基础相对活跃，可以吸引用户和开发者，因为：

*用户倾向于流动性和高交易量。

*开发者寻求高交易量、费用和应用的可见性。

 （2）开发者资源

以太坊的工具和应用密码学研究直接集成到Monad中，同时通过以下方式获得更高的吞吐量和规模：

*应用

*开发者工具（Hardhat、Apeworx、Foundry）

*钱包（Rabby、Metamask、Phantom）

*分析/索引（Etherscan、Dune）

Electric Capital的开发者报告显示，截至2024年7月，以太坊有2,788名全职开发者，Base有889名，Polygon有834名。Solana以664名开发者排名第七，落后于Polkadot、Arbitrum和Cosmos。尽管有人认为加密领域的开发者总数仍然较少，因此应基本忽略（资源应集中在引入外部人才上），但很明显，在加密开发者这一“小”池中存在大量EVM人才。此外，鉴于大多数人才在EVM工作，且大多数工具在EVM中，新开发者很可能必须或选择在EVM中学习和开发。正如Keone在一次采访中提到的，开发者可以选择：

*为EVM构建可移植的应用，实现多链部署，但吞吐量有限且费用较高

*在特定生态系统（如Solana、Aptos或Sui）中构建高性能和低成本的应用。

 Monad旨在将这两种方法相结合。由于大多数工具和资源都针对EVM定制，其生态系统内开发的应用可以无缝移植。结合其相对的性能和效率——得益于Monad的优化——EVM显然是一个强大的竞争壁垒。

除了开发者，用户也更喜欢熟悉的工作流程。通过Rabby、MetaMask和Etherscan等工具，EVM工作流程已成为标准。这些成熟的平台促进了桥和协议的集成。此外，基本应用（AMM、货币市场、桥）可以立即启动。这些基本原语对于链的可持续性以及新颖应用至关重要。

3、扩展EVM

扩展EVM有两种主要方法：

*将执行移至链下：通过rollups将执行卸载到其他虚拟机，采用模块化架构。

*提高性能：通过共识优化和增加区块大小及gas限制来提高基础链EVM的性能。

（1）Rollup和模块化架构

Vitalik在2020年10月引入了rollups作为以太坊的主要扩展解决方案，符合模块化区块链原则。因此，以太坊的扩展路线图将执行委托给rollup，这些rollup是利用以太坊安全性的链下虚拟机。Rollup在执行方面表现出色，具有更高的吞吐量、更低的延迟和更低的交易成本。它们的迭代开发周期比以太坊短——在以太坊上需要数年的更新可能在rollup上只需数月，因为潜在成本和损失较低。

Rollup可以使用中心化的排序器运行，同时保持安全逃生舱，帮助它们绕过某些去中心化要求。需要注意的是，许多rollup（包括Arbitrum、Base和OP Mainnet）仍处于起步阶段（阶段0或阶段1）。在阶段1的rollup中，欺诈证明提交仅限于白名单参与者，且与链上可证明错误无关的升级必须为用户提供至少30天的退出窗口。阶段0的rollup在许可操作者宕机或审查时为用户提供不到7天的退出时间。

 在以太坊中，典型的交易大小为156字节，签名包含最多的数据。Rollup允许将多笔交易捆绑在一起，减少总体交易大小并优化gas成本。简而言之，rollup通过将多笔交易打包成批次提交到以太坊主网来实现效率。这减少了链上数据处理，但增加了生态系统的复杂性，因为rollup连接需要新的基础设施要求。此外，rollup本身也采用了模块化架构，将执行移至L3以解决基础rollup吞吐量限制，特别是游戏应用。

尽管rollup理论上通过成为以太坊之上的全面链消除了桥接和流动性碎片化，但当前的实现尚未成为完全“全面”的链。按TVL计算，三大rollup——Arbitrum、OP Mainnet和Base——保持不同的生态系统和用户群体，各自在某些领域表现出色，但未能提供全面的解决方案。

简而言之，用户必须访问多个不同的链才能获得与使用单一链（如Solana）相同的体验。以太坊生态系统中缺乏统一的共享状态（区块链的核心主张之一），这极大地限制了链上用例——特别是由于流动性和状态的碎片化，竞争rollup无法轻松了解彼此的状态。状态碎片化还带来了对桥和跨链消息协议的额外需求，这些协议可以将rollup和状态连接在一起，但伴随着一些权衡。单一区块链不会面临这些碎片化问题，因为有一个单一的账本记录状态。

每个rollup在优化和专注于其特定领域方面采取了不同的方法。Optimism通过Superchain引入了额外的模块化，因此依赖于其他L2使用其堆栈构建并收费竞争。Arbitrum主要专注于DeFi，特别是永续和期权交易所，同时通过Xai和Sanko扩展到L3。新的高性能rollup如MegaETH和Base已经出现，具有更高的吞吐量能力，旨在提供单一的大型链。MegaETH尚未推出，Base在实施方面令人印象深刻，但在某些领域仍然不足，包括衍生品交易（期权和永续）和DePIN领域。

（2）早期L2扩展

Optimism和Arbitrum

第一代L2相比以太坊提供了改进的执行，但落后于新的超优化解决方案。例如，Arbitrum每秒处理37.5笔交易（“TPS”），Optimism Mainnet为11 TPS。相比之下，Base约为80 TPS，MegaETH目标为100,000 TPS，BNB Chain为65.1 TPS，Monad目标为10,000 TPS。

 尽管Arbitrum和Optimism Mainnet无法支持像完全链上订单簿这样的极高吞吐量应用，但它们通过额外的链层——Arbitrum的L3和Optimism的超级链——以及中心化的排序器进行扩展。

Arbitrum专注于游戏的L3、Xai和Proof of Play，展示了这种方法。它们基于Arbitrum Orbit堆栈构建，使用AnyTrust数据可用性在Arbitrum上结算。Xai达到67.5 TPS，而Proof of Play Apex达到12.2 TPS，Proof of Play Boss为10 TPS。这些L3通过Arbitrum结算引入了额外的信任假设，而不是以太坊主网，同时面临去中心化数据可用性层较少的潜在挑战。Optimism的L2——Base、Blast和即将推出的Unichain——通过以太坊结算和blob数据可用性保持更强的安全性。

两个网络都优先考虑水平扩展。Optimism通过OP Stack提供L2基础设施、链部署支持和具有互操作性功能的共享桥接。Arbitrum将特定用例卸载到L3，特别是游戏应用，其中额外的信任假设比金融应用带来更低的资本风险。

（3）优化链和EVM性能

替代扩展方法专注于执行优化或目标权衡，通过垂直而非水平扩展来增加吞吐量和TPS。Base、MegaETH、Avalanche和BNB Chain体现了这一策略。

BaseBase宣布计划通过逐步增加gas目标达到1 Ggas/s。9月，他们将目标提高到11 Mgas/s，并将gas限制增加到33 Mgas。初始区块处理了258笔交易，保持约70 TPS五个小时。到12月18日，gas目标达到20 Mgas/s，出块时间为2秒，每块支持40M gas。相比之下，Arbitrum为7 Mgas/s，OP Mainnet为2.5 MGas/s。

 Base已成为Solana和其他高吞吐量链的竞争对手。截至今天，Base在活动方面已超越其他L2，具体表现为：

*截至2025年1月，其月度费用达到1560万美元——是Arbitrum的7.5倍，OP Mainnet的23倍。

*截至2025年1月，其交易量累计达到3.297亿笔，是Arbitrum（5790万笔）的6倍，OP Mainnet（2450万笔）的14倍。注意：交易量可能被操纵，可能具有误导性。

Base团队专注于通过优化速度、吞吐量和低费用提供更统一的体验，而不是Arbitrum和Optimism的模块化方法。用户表现出对更统一体验的偏好，正如Base的活动和收入数字所示。此外，Coinbase的支持和分发也起到了帮助作用。

MegaETH

MegaETH是一个EVM兼容的L2。其核心是通过使用专用排序器节点的混合架构处理交易。MegaETH在其架构中独特地将性能和安全任务分离，结合新的状态管理系统，取代传统的Merkle Patricia Trie，以最小化磁盘I/O操作。

该系统每秒处理100,000笔交易，延迟低于毫秒，同时保持完全的EVM兼容性和处理TB级状态数据的能力。MegaETH使用EigenDA进行数据可用性，将功能分布在三种专用节点类型上：

*排序器：一个高性能单节点（100核，1-4TB RAM）管理交易排序和执行，将状态保持在RAM中以快速访问。它以大约10毫秒的间隔生成区块，见证区块验证，并跟踪区块链状态变化的状态差异。排序器通过并行EVM执行和优先级支持实现高性能，在正常操作期间无需共识开销。

*证明者：这些轻量级节点（1核，0.5GB RAM）计算验证区块内容的加密证明。它们异步和乱序验证区块，采用无状态验证，水平扩展，并为全节点验证生成证明。系统支持零知识和欺诈证明。

*全节点：在中等硬件（4-8核，16GB RAM）上运行，全节点桥接证明者、排序器和EigenDA。它们通过点对点网络处理压缩的状态差异，应用差异而无需重新执行交易，使用证明者生成的证明验证区块，使用优化的Merkle Patricia Trie维护状态根，并支持19倍压缩同步。

 （4）Rollups的问题

Monad从根本上不同于rollup及其固有权衡。今天的大多数rollup依赖于中心化的单一排序器，尽管正在开发共享和去中心化的排序解决方案。排序器和提议者的中心化引入了操作漏洞。单一实体的控制可能导致活跃性问题和降低的抗审查性。尽管存在逃生舱，中心化的排序器仍能操纵交易速度或顺序以提取MEV。它们还创建了单点故障，如果排序器失败，整个L2网络将无法正常运行。

除了中心化风险外，rollup还带来了额外的信任假设和权衡，特别是围绕互操作性：

用户遇到多种不可互换的相同资产形式。三大rollup——Arbitrum、Optimism和Base——保持不同的生态系统、用例和用户群体。用户必须在rollup之间桥接以访问特定应用，或协议必须在多个rollups上启动，引导流动性和用户，同时管理桥接集成带来的复杂性和安全风险。

额外的互操作性问题源于技术限制（基础L2层的每秒交易量有限），这导致了进一步的模块化和将执行推至L3，特别是游戏。中心化带来了额外的挑战。

我们已经看到优化的rollup（如Base和MegaETH）通过中心化的排序器提高了性能并优化了EVM，因为交易在无需共识要求的情况下排序和执行。这允许通过使用单一高容量机器减少出块时间和增加区块大小，同时也创建了单点故障和潜在的审查向量。

Monad采取了不同的方法，与以太坊主网相比，需要更强大的硬件。虽然以太坊L1验证者需要2核CPU、4-8 GB内存和25 Mbps带宽，但Monad需要16核CPU、32 GB内存、2 TB SSD和100 Mbps带宽。尽管Monad的规格与以太坊相比显得庞大，但后者为了适应独立验证者，保持了最低的节点要求，尽管Monad推荐的硬件今天已经可以访问。

 除了硬件规格外，Monad正在重新设计其软件堆栈，以通过节点分布实现比L2s更大的去中心化。虽然L2s优先考虑增强单一排序器的硬件，牺牲了去中心化，但Monad在增加硬件要求的同时，修改了软件堆栈，以提高性能，同时保持节点分布。

（5）Monad的EVM早期的以太坊分叉主要修改了共识机制，如Avalanche，同时保持了Go Ethereum客户端用于执行。尽管存在多种编程语言的以太坊客户端，但它们基本上复制了原始设计。Monad通过从第一原则和零开始重建共识和执行组件而有所不同。

Monad优先考虑最大化硬件利用率。相比之下，以太坊主网对支持独立质押者的重视限制了性能优化，因为它需要与较弱的硬件兼容。这一限制影响了区块大小、吞吐量和出块时间的改进——最终，网络的速度取决于其最慢的验证者。

与Solana的方法类似，Monad采用更强大的硬件来增加带宽并减少延迟。这一策略利用所有可用的核心、内存和固态硬盘来提高速度。鉴于强大硬件的成本不断下降，优化高性能设备比限制低质量设备的能力更为实际。

 当前的Geth客户端通过单线程顺序处理执行。区块包含线性排序的交易，将前一个状态转换为新状态。此状态包括所有账户、智能合约和存储的数据。状态变化发生在交易被处理和验证时，影响账户余额、智能合约、代币所有权和其他数据。

交易通常独立运行。区块链状态由不同的账户组成，每个账户独立进行交易，这些交易通常不会相互交互。基于这一想法，Monad使用乐观并行执行。

乐观并行执行尝试并行运行交易以获得潜在的性能优势——最初假设不会有冲突。多个交易同时运行，最初不担心它们的潜在冲突或依赖关系。执行后，系统检查并行交易是否实际相互冲突，并在存在冲突时进行纠正。

4、协议机制并行执行

（1）Solana的并行执行

当用户想到并行执行时，通常会想到Solana和SVM，它允许通过访问列表并行执行交易。Solana上的交易包括头、账户密钥（交易中包含的指令地址）、区块哈希（交易创建时包含的哈希）、指令和基于交易指令所需的所有账户签名数组。

每笔交易的指令包括程序地址，指定调用的程序；账户，列出指令读取和写入的所有账户；以及指令数据，指定指令处理程序（处理指令的函数）以及指令处理程序所需的额外数据。

每条指令为每个涉及的账户指定三个关键细节：

*账户的公共地址

*账户是否需要签署交易

*指令是否会修改账户的数据

Solana使用这些指定的账户列表提前识别交易冲突。由于所有账户都在指令中指定，包括它们是否可写的详细信息，如果交易不包含写入相同状态的任何账户，则可以并行处理交易。

过程如下：

*Solana检查每笔交易中提供的账户列表

*识别哪些账户将被写入

*检查交易之间的冲突（它们是否写入相同的账户）

*不写入任何相同账户的交易并行处理，而具有冲突写入操作的交易按顺序处理

EVM中存在类似的机制，但由于以太坊不需要访问列表，因此未使用。用户需要预先支付更多费用，因为他们在交易中包含此访问列表。交易变得更大，成本更高，但用户因指定访问列表而获得折扣。

（2）Monad的并行执行与Solana不同，Monad使用乐观并行执行。与识别哪些交易影响哪些账户并基于此并行化（Solana的方法）不同，Monad假设交易可以并行执行而不会相互干扰。

当Monad并行运行交易时，它假设交易从同一点开始。当多个交易并行运行时，链为每个交易生成待定结果。在这种情况下，待定结果指的是链为跟踪交易的输入和输出以及它们如何影响状态所做的记账。这些待定结果按交易的原始顺序提交（即基于优先费用）。

为了提交待定结果，检查输入以确保它们仍然有效——如果待定结果的输入已更改/修改（即如果交易由于访问相同账户而无法并行工作，并且会相互影响，则交易按顺序处理（稍后的交易重新执行））。重新执行仅是为了保持正确性。结果不是交易耗时更长，而是需要更多的计算。

在第一次执行迭代中，Monad已经检查了冲突或对其他交易的依赖。因此，当交易第二次执行（第一次乐观并行执行失败后），区块中的所有先前交易都已执行，确保第二次尝试成功。即使Monad中的所有交易相互依赖，它们也只是按顺序执行，产生与另一个非并行化EVM相同的结果。

Monad在执行期间跟踪每笔交易的读取集和写入集，然后按原始交易顺序合并结果。如果并行运行的交易使用了过时的数据（因为较早的交易更新了它读取的内容），Monad在合并时检测到这一点，并使用正确的更新状态重新执行该交易。这确保了最终结果与区块的顺序执行相同，保持了以太坊兼容的语义。这种重新执行的开销最小——昂贵的步骤如签名验证或数据加载无需从头开始重复，通常所需的状态已在第一次运行时缓存在内存中。

示例：

在初始状态下，用户A有100 USDC，用户B有0 USDC，用户C有300 USDC。

有三笔交易：

*交易1：用户A向用户B发送10 USDC

*交易2：用户A向用户C发送10 USDC

串行执行过程使用串行执行，过程更简单，但效率较低。每笔交易按顺序执行：

*用户A首先向用户B发送10 USDC。

*之后用户A向用户C发送10 USDC。

在最终状态下，对于串行执行（非Monad）：

*用户A剩下80 USDC（分别向B和C发送了10 USDC）。

*用户B有10 USDC。

*用户C有310 USDC。

并行执行过程

使用并行执行，过程更复杂，但效率更高。多个交易同时处理，而不是等待每个交易按顺序完成。虽然交易并行运行，但系统会跟踪它们的输入和输出。在顺序“合并”阶段，如果检测到某个交易使用了被较早交易更改的输入，则该交易将使用更新后的状态重新执行。

逐步过程如下：

*用户A最初有100 USDC，用户B最初有0 USDC，用户C最初有300 USDC。

*通过乐观并行执行，多个交易同时运行，最初假设它们都从相同的初始状态开始工作。

*在这种情况下，交易1和交易2并行执行。两个交易都读取用户A初始状态为100 USDC。

*交易1计划从用户A向用户B发送10 USDC，将用户A的余额减少到90，用户B的余额增加到10。

*同时，交易2也读取用户A的初始余额为100，并计划向用户C转移10 USDC，试图将用户A的余额减少到90，用户C的余额增加到310。

*当链按顺序验证这些交易时，首先检查交易1。由于其输入值与初始状态匹配，因此提交，用户A的余额变为90，用户B收到10 USDC。

*当链检查交易2时，发现了一个问题：交易2计划时假设用户A有100 USDC，但用户A现在只有90 USDC。由于这种不匹配，交易2必须重新执行。

*在重新执行期间，交易2读取用户A更新后的状态为90 USDC。然后成功从用户A向用户C转移10 USDC，用户A剩下80 USDC，用户C的余额增加到310 USDC。

*在这种情况下，由于用户A有足够的资金进行两次转账，两个交易都能成功完成。

 在最终状态下，对于并行执行（Monad）：

结果是相同的：

*用户A剩下80 USDC（分别向B和C发送了10 USDC）。

*用户B有10 USDC。

*用户C有310 USDC。

*用户D有100 USDC减去NFT成本和铸造的NFT。

5、延迟执行

当区块链验证并达成交易共识时，全球的节点必须相互通信。这种全球通信遇到物理限制，因为数据需要时间在东京和纽约等远距离点之间传输。

大多数区块链使用顺序方法，其中执行与共识紧密耦合。在这些系统中，执行是共识的前提——节点必须在最终确定区块之前执行交易。

以下是具体详情：

执行先于共识，以便在开始下一个区块之前最终确定区块。节点首先就交易顺序达成共识，然后对执行交易后的状态摘要的默克尔根达成共识。Leader必须在共享提议的区块之前执行其中的所有交易，验证节点必须在达成共识之前执行每笔交易。这个过程限制了执行时间，因为它发生了两次，同时允许多轮全球通信以达成共识。例如，以太坊有12秒的出块时间，而实际执行可能只需100毫秒（实际执行时间因区块复杂性和gas使用情况而有很大差异）。

一些系统尝试通过交错执行来优化这一点，交错执行将任务分成较小的段，这些段在进程之间交替。虽然处理仍然是顺序的，任何时刻都是单任务执行，但快速切换创造了明显的并发性。然而，这种方法仍然从根本上限制了吞吐量，因为执行和共识仍然是相互依赖的。

 Monad通过将执行与共识解耦来解决顺序和交错执行的限制。节点在不执行交易的情况下就交易顺序达成共识——即两个并行进程发生：

*节点执行已达成共识的交易.

*共识继续进行下一个区块，而不等待执行完成，执行跟随共识.

这种结构使系统能够在执行开始之前通过共识承诺大量工作，允许Monad通过分配额外的时间来处理更大的区块和更多的交易。此外，它使每个进程能够独立使用整个区块时间——共识可以使用整个区块时间进行全球通信，执行可以使用整个区块时间进行计算，两个进程互不阻塞。

为了在将执行与共识解耦的同时保持安全性和状态一致性，Monad使用延迟的默克尔根，其中每个区块包含N个区块前的状态默克尔根（N预计在启动时为10，在当前测试网中设置为3），允许节点在执行后验证它们是否达到了相同的状态。延迟的默克尔根允许链验证状态一致性：延迟的默克尔根充当检查点——N个区块后，节点必须证明它们到达了相同的状态根，否则它们执行了错误的内容。此外，如果节点的执行产生了不同的状态根，它将在N个区块后检测到这一点，并可以回滚并重新执行以达成共识。这有助于消除节点恶意行为的风险。生成的延迟默克尔根可用于轻客户端验证状态——尽管有N个区块的延迟。

由于执行被延迟并在共识之后发生，一个潜在的问题是恶意行为者（或普通用户意外地）不断提交最终会因资金不足而失败的交易。例如，如果总余额为10 MON的用户提交了5笔交易，每笔交易单独尝试发送10 MON，可能会导致问题。然而，如果不进行检查，这些交易可能会通过共识，但在执行期间失败。为了解决这个问题并减少潜在的垃圾邮件，节点在共识期间通过跟踪在途交易实施保护措施。

对于每个账户，节点检查N个区块前的账户余额（因为这是最新的已验证的正确状态）。然后，对于该账户的每笔“在途”的待处理交易（已通过共识但尚未执行），它们减去正在转移的价值（例如发送1 MON）和最大可能的gas成本，计算为gas_limit乘以maxFeePerGas。

这个过程创建了一个运行的“可用余额”，用于在共识期间验证新交易。如果新交易的价值加上最大gas成本超过此可用余额，则在共识期间拒绝该交易，而不是让它通过后在执行期间失败。

由于Monad的共识以略微延迟的状态视图进行（由于执行解耦），它实施了一种保护措施，以防止包含发送者最终无法支付的交易。在Monad中，每个账户在共识期间都有一个可用或“储备”余额。随着交易被添加到提议的区块中，协议从该可用余额中扣除交易的最大可能成本（gas * 最大费用 + 转移的价值）。如果账户的可用余额将降至零以下，则该账户的进一步交易不会包含在区块中。

这种机制（有时被描述为向储备余额收取运输成本）确保只有可以支付的交易被提议，从而防御攻击者试图用0资金淹没网络的无用交易的DoS攻击。一旦区块最终确定并执行，余额将相应调整，但在共识阶段，Monad节点始终对未决交易的可花费余额进行最新检查。

6、MonadBFT

（1）共识

HotStuff

MonadBFT是一种低延迟、高吞吐量的拜占庭容错（“BFT”）共识机制，源自HotStuff共识。

Hotstuff由VMresearch创建，并由Meta前区块链团队的LibraBFT进一步改进。它实现了线性视图更改和响应性，意味着它可以有效地轮换Leader，同时以实际网络速度而不是预定的超时时间进行。HotStuff还使用阈值签名以提高效率，并实现了流水线操作，允许在提交前一个区块之前提议新区块。

然而，这些好处伴随着某些权衡：与经典的两轮BFT协议相比，额外的轮次导致更高的延迟和流水线期间分叉的可能性。尽管有这些权衡，HotStuff的设计使其更适合大规模区块链实现，尽管它导致比两轮BFT协议更慢的最终性。

以下是HotStuff详解：

*当交易发生时，它们被发送到网络的一个验证者，称为Leader。

*Leader将这些交易编译成一个区块，并将其广播给网络中的其他验证者。

*验证者然后通过投票验证区块，投票发送给下一个区块的Leader。

*为了防止恶意行为者或通信故障，区块必须经过多轮投票才能最终确定状态。

*根据具体实现，区块只有在成功通过两到三轮后才能提交，确保共识的健壮性和安全性。

 尽管MonadBFT源自HotStuff，但它引入了独特的修改和新概念，可以进一步探索。

交易协议

MonadBFT专门设计用于在部分同步条件下实现交易协议——意味着即使在消息延迟不可预测的异步期间，链也可以达成共识。

最终，网络稳定并传递消息（在已知的时间范围内）。这些异步期源于Monad的架构，因为链必须实施某些机制以提高速度、吞吐量和并行执行。

双轮系统

与最初实现三轮系统的HotStuff不同，MonadBFT使用类似于Jolteon、DiemBFT和Fast HotStuff的双轮系统。

“一轮”包括以下基本步骤：

*在每轮中，Leader广播一个新区块和前一轮的证书（QC或TC）。

*每个验证者审查区块，并将签名投票发送给下一轮的Leader

*当收集到足够的投票（2/3）时，形成QC。QC表示网络的验证者已达成共识以附加区块，而TC表示共识轮失败并需要重新启动。

 “双轮”具体指的是提交规则。在双轮系统中提交一个区块：

*第1轮：初始区块被提议并获得QC

*第2轮：下一个区块被提议并获得QC 如果这两轮连续完成，则可以提交第一个区块。

DiemBFT过去使用三轮系统，但升级为两轮系统。两轮系统通过减少通信轮次实现更快的提交。它允许更低的延迟，因为交易可以更快地提交，因为它们不需要等待额外的确认。

具体过程

MonadBFT中的共识过程如下：

*Leader操作和区块提议：当当前轮的指定Leader启动共识时，过程开始。Leader创建并广播一个包含用户交易的新区块，以及前一轮共识的证明，形式为QC或TC。这创建了一个流水线结构，其中每个区块提议都携带前一个区块的认证。

*验证者操作：一旦验证者收到Leader的区块提议，他们开始验证过程。每个验证者根据协议规则仔细审查区块的有效性。有效的区块收到发送给下一轮Leader的签名YES投票。然而，如果验证者在预期时间内没有收到有效区块，他们通过广播包括他们已知的最高QC的签名超时消息来启动超时程序。这种双路径方法确保即使区块提议失败，协议也能取得进展。

*证书创建：协议使用两种类型的证书来跟踪共识进展。当Leader从三分之二的验证者收集到YES投票时，创建QC，证明对区块的广泛共识。或者，如果三分之二的验证者在没有收到有效提议的情况下超时，他们创建TC，允许协议安全地进入下一轮。两种证书类型都作为验证者参与的关键证明。

*区块最终确定（两链提交规则）：MonadBFT使用两链提交规则进行区块最终确定。当验证者观察到来自连续轮的两个相邻认证区块形成一个链B ← QC ← B' ← QC'时，他们可以安全地提交区块B及其所有祖先。这种两链方法在保持性能的同时提供了安全性和活跃性。

本地内存池架构

Monad采用本地内存池架构，而不是传统的全局内存池。在大多数区块链中，待处理交易被广播到所有节点，这可能很慢（许多网络跳）并且由于冗余传输而带宽密集。相比之下，在Monad中，每个验证者维护自己的内存池；交易由RPC节点直接转发给接下来的几个预定Leader（目前是接下来的N = 3个Leader）以包含。

这利用了已知的Leader时间表（避免不必要的广播给非Leader），并确保新交易快速到达区块提议者。即将到来的Leader执行验证检查并将交易添加到他们的本地内存池中，因此当验证者轮到领导时，它已经有相关的交易排队。这种设计减少了传播延迟并节省了带宽，实现了更高的吞吐量。

（2）RaptorCast

Monad使用一种称为RaptorCast的专用多播协议，以快速将区块从Leader传播到所有验证者。Leader不是将完整区块串行发送给每个对等方或依赖简单的广播，而是使用纠删码方案（根据RFC 5053）将区块提议数据分解为编码块，并通过两级中继树高效分发这些块。在实践中，Leader将不同的块发送给一组第一层验证者节点，然后这些节点将块转发给其他人，这样每个验证者最终都会收到足够的块以重建完整区块。块的分配按权益加权（每个验证者负责转发一部分块），以确保负载平衡。这样，整个网络的上传容量被用来快速传播区块，最小化延迟，同时仍然容忍可能丢弃消息的拜占庭（恶意或故障）节点。RaptorCast使Monad即使在大区块的情况下也能实现快速、可靠的区块广播，这对于高吞吐量至关重要。

BLS和ECDSA签名

QC和TC使用BLS和ECDSA签名实现，这是密码学中使用的两种不同类型的数字签名方案。

Monad结合使用BLS签名和ECDSA签名以提高安全性和可扩展性。BLS签名支持签名聚合，而ECDSA签名通常验证速度更快。

ECDSA签名

虽然无法聚合签名，但ECDSA签名速度更快。Monad将它们用于QC和TC。

QC创建：

*Leader提议一个区块

*验证者通过签名投票表示同意

*当收集到所需的投票部分时，它们可以组合成一个QC。

*QC证明验证者同意该区块

TC创建：

*如果验证者在预定时间内没有收到有效区块

*它向对等方广播签名的超时消息

*如果收集到足够的超时消息，它们形成一个TC。

*TC允许即使当前轮失败也能进入下一轮

BLS签名Monad将BLS签名用于多重签名，因为它允许签名逐步聚合成单个签名。这主要用于可聚合的消息类型，如投票和超时。

投票是验证者在同意提议的区块时发送的消息。它们包含表示批准区块的签名，并用于构建QC。

超时是验证者在预期时间内没有收到有效区块时发送的消息。它们包含带有当前轮号、验证者的最高QC和这些值的签名的签名消息。它们用于构建TC。

投票和超时都可以使用BLS签名组合/聚合以节省空间并提高效率。如前所述，BLS比ECDSA签名相对较慢。

Monad结合使用ECDSA和BLS以受益于两者的效率。尽管BLS方案较慢，但它允许签名聚合，因此特别适用于投票和超时，而ECDSA更快但不允许聚合。

7、Monad MEV

简单来说，MEV指的是通过重新排序、包含或排除区块中的交易，各方可以提取的价值。MEV通常被分类为“好的”MEV，即保持市场健康高效的MEV（例如清算、套利）或“坏的”MEV（例如三明治攻击）。

Monad的延迟执行影响了链上MEV的工作方式。在以太坊上，执行是共识的前提——意味着当节点就一个区块达成一致时，它们就交易列表和顺序以及结果状态达成一致。在提议新区块之前，Leader必须执行所有交易并计算最终状态，允许搜索者和区块构建者可靠地针对最新确认的状态模拟交易。

相比之下，在Monad上，共识和执行是解耦的。节点只需要就最近区块的交易顺序达成一致，而状态的共识可能稍后达成。这意味着验证者可能基于较早区块的状态数据工作，这使得它们无法针对最新区块进行模拟。除了缺乏确认的状态信息带来的复杂性外，Monad的1秒出块时间可能对构建者模拟区块以优化构建的区块具有挑战性。

访问最新的状态数据对搜索者是必要的，因为它为他们提供了DEX上的确认资产价格、流动性池余额和智能合约状态等——这使他们能够识别潜在的套利机会和发现清算事件。如果最新的状态数据未确认，搜索者无法在下一个区块产生之前模拟区块，并面临状态确认之前交易回滚的风险。

鉴于Monad区块存在延迟，MEV格局可能与Solana类似。

作为背景，在Solana上，区块每约400毫秒在一个槽中产生，但区块产生到“根化”（最终确定）之间的时间更长——通常为2000-4000毫秒。这种延迟不是来自区块生产本身，而是来自收集足够的权益加权投票以使区块最终确定所需的时间。

在这个投票期间，网络继续并行处理新区块。由于交易费用非常低，并且可以并行处理新区块，这创造了一个“竞争条件”，搜索者会发送大量交易希望被包含——这导致许多交易被回滚。例如，在12月期间，Solana上的31.6亿笔非投票交易中有13亿笔（约41%）被回滚。Jito的Buffalu早在2023年就强调，“Solana上98%的套利交易失败”。

由于Monad上存在类似的区块延迟效应，最新区块的确认状态信息不存在，并且新区块并行处理，搜索者可能会被激励发送大量交易——这些交易可能会失败，因为交易被回滚，确认的状态与它们用于模拟的状态不同。

8、MonadDB

Monad选择构建一个自定义数据库，称为MonadDB，用于存储和访问区块链数据。链扩展性的一个常见问题是状态增长——即数据大小超过节点的容量。Paradigm在四月份发布了一篇关于状态增长的简短研究文章，强调了状态增长、历史增长和状态访问之间的区别，他们认为这些通常被混为一谈，尽管它们是影响节点硬件性能的不同概念。

正如他们所指出的：

*状态增长指的是新账户（账户余额和随机数）和合约（合约字节码和存储）的积累。节点需要有足够的存储空间和内存容量来适应状态增长。

*历史增长指的是新区块和新交易的积累。节点需要有足够的带宽来共享区块数据，并且需要有足够的存储空间来存储区块数据。

*状态访问指的是用于构建和验证区块的读写操作。

如前所述，状态增长和历史增长都会影响链的扩展性，因为数据大小可能会超过节点的容量。节点需要将数据存储在永久存储中以构建、验证和分发区块。此外，节点必须在内存中缓存以与链同步。状态增长和历史增长以及优化的状态访问都需要链来适应，否则会限制区块大小和每个区块的操作。区块中的数据越多，每个区块的读写操作越多，历史增长和状态增长就越大，对高效状态访问的需求也就越大。

尽管状态和历史增长是扩展性的重要因素，但它们并不是主要问题，特别是从磁盘性能的角度来看。MonadDB专注于通过对数数据库扩展来管理状态增长。因此，增加16倍的状态只需要每次状态读取时多一次磁盘访问。关于历史增长，当链具有高性能时，最终会有太多数据无法本地存储。其他高吞吐量链，如Solana，依赖Google BigTable等云托管来存储历史数据，这虽然有效，但由于依赖中心化方，牺牲了去中心化。Monad最初将实施类似的解决方案，同时最终致力于去中心化解决方案。

（1）状态访问

除了状态增长和历史增长，MonadDB的关键实现之一是优化每个区块的读写操作（即改进状态访问）。

以太坊使用Merkle Patricia Trie（“MPT”）来存储状态。MPT借鉴了PATRICIA（一种数据检索算法）的特性，以实现更高效的数据检索。

Merkle树Merkle树（“MT”）是一组哈希值，最终缩减为一个单一的根哈希值，称为Merkle根。数据的哈希值是原始数据的固定大小加密表示。Merkle根是通过反复哈希数据对直到剩下一个哈希值（Merkle根）而创建的。Merkle根的有用之处在于它允许验证叶子节点（即被反复哈希以创建根的单个哈希值），而无需单独验证每个叶子节点。

这比单独验证每笔交易要高效得多，特别是在每个区块中有许多交易的大型系统中。它在各个数据片段之间创建了可验证的关系，并允许“Merkle证明”，即通过提供交易和重建根所需的中间哈希值（log(n)个哈希值而不是n笔交易），可以证明交易包含在区块中。

Merkle Patricia Trie

Merkle树非常适合比特币的需求，其中交易是静态的，主要需求是证明交易存在于区块中。然而，它们不太适合以太坊的用例，以太坊需要检索和更新存储的数据（例如，账户余额和随机数，添加新账户，更新存储中的键），而不仅仅是验证其存在，这就是为什么以太坊使用Merkle Patricia Trie来存储状态。

Merkle Patricia Trie（“MPT”）是一种修改后的Merkle树，用于在状态数据库中存储和验证键值对。虽然MT获取一系列数据（例如交易）并仅成对哈希它们，但MPT像字典一样组织数据——每个数据（值）都有一个特定的地址（键）来存储。这种键值存储是通过Patricia Trie实现的。

以太坊使用不同类型的键来访问不同类型的Trie，具体取决于需要检索的数据。以太坊使用4种类型的Trie：

*世界状态Trie：包含地址和账户状态之间的映射。

*账户存储Trie：存储与智能合约相关的数据。

*交易Trie：包含区块中包含的所有交易。

*收据Trie：存储带有交易执行信息的交易收据。

*Trie通过不同类型的键访问值，这使得链能够执行各种功能，包括检查余额、验证合约代码是否存在或查找特定账户数据。

注意：以太坊计划从MPT转向Verkle树，以“升级以太坊节点，使其能够停止存储大量状态数据而不失去验证区块的能力”。

Monad DB: Patricia Trie

与以太坊不同，MonadDb在磁盘和内存中本地实现了Patricia Trie数据结构。

如前所述，MPT是Merkle树数据结构与Patricia Trie的结合，用于键值检索：其中两种不同的数据结构被集成/结合：Patricia Trie用于存储、检索和更新键值对，而Merkle树用于验证。这导致了额外的开销，因为它增加了基于哈希的节点引用的复杂性，并且Merkle需要在每个节点上为哈希值提供额外的存储。

基于Patricia Trie的数据结构使MonadDB能够：

*拥有更简单的结构：每个节点没有Merkle哈希，节点关系没有哈希引用，它只直接存储键和值。*直接路径压缩：减少到达数据所需的查找次数。*本地键值存储：虽然MPT将Patricia Trie集成到单独的键值存储系统中，但Patricia Trie的本地功能就是键值存储，这允许更好的优化。*无需数据结构转换：无需在Trie格式和数据库格式之间进行转换。这些使MonadDB具有相对较低的计算开销，需要更少的存储空间，实现更快的操作（无论是检索还是更新），并保持更简单的实现。

异步I/O

交易在Monad上并行执行。这意味着存储需要适应多个交易并行访问状态，即数据库应该具有异步I/O。

MonadDB支持现代异步I/O实现，这使得它能够处理多个操作而无需创建大量线程——与其他传统的键值数据库（例如LMDB）不同，后者必须创建多个线程来处理多个磁盘操作——由于需要管理的线程较少，因此开销较小。

在加密领域中输入/输出处理的简单示例是：

*输入：在交易前读取状态以检查账户余额*输出：在转账后写入/更新账户余额异步I/O允许输入/输出处理（即读取和写入存储），即使先前的I/O操作尚未完成。这对于Monad来说是必要的，因为多个交易正在并行执行。因此，一个交易需要在另一个交易仍在从存储中读取或写入数据时访问存储以读取或写入数据。在同步I/O中，程序按顺序一次执行一个I/O操作。在同步I/O处理中请求I/O操作时，交易会等待直到前一个操作完成。例如：

*同步I/O：链将tx/block #1写入状态/存储。链等待其完成。然后链可以写入tx/block #2。*异步I/O：链同时将tx/block #1、tx/block #2和tx/block #3写入状态/存储。它们独立完成。

（2）StateSync

Monad拥有一个StateSync机制，帮助新节点或落后节点高效地赶上最新状态，而无需从创世开始重放每笔交易。StateSync允许一个节点（“客户端”）从其同行（“服务器”）请求到目标区块的最近状态快照。状态数据被分割成块（例如账户状态的部分和最近的区块头），这些块分布在多个验证者同行中以分担负载。每个服务器响应请求的状态块（利用MonadDb中的元数据快速检索所需的Trie节点），客户端组装这些块以构建目标区块的状态。由于链在不断增长，一旦同步完成，节点要么执行另一轮更接近顶端的StateSync，要么重放少量最近的区块以完全赶上。这种分块状态同步大大加速了节点引导和恢复，确保即使Monad的状态增长，新的验证者也可以加入或重启并完全同步，而无需数小时的延迟。

9、生态系统

（1）生态系统努力

Monad团队专注于为其链开发一个强大而稳健的生态系统。过去几年，L1和L2之间的竞争已经从主要关注性能转向面向用户的应用程序和开发者工具。链仅仅吹嘘高TPS、低延迟和低费用已经不够了；它们现在必须提供一个包含各种不同应用程序的生态系统，从DePIN到AI，从DeFi到消费者。这变得越来越重要的原因是高性能L1和低成本L1的激增，包括Solana、Sui、Aptos和Hyperliquid，它们都提供了高性能、低成本的开发环境和区块空间。Monad在这里的一个优势是它使用了EVM。

如前所述，Monad提供完整的EVM字节码和以太坊RPC API兼容性，使开发者和用户能够集成，而无需更改其现有工作流程。那些致力于扩展EVM的人经常受到的一个批评是，有更高效的替代方案可用，例如SVM和MoveVM。然而，如果一个团队可以通过软件和硬件改进来最大化EVM性能，同时保持低费用，那么扩展EVM是有意义的，因为存在现有的网络效应、开发者工具和可以轻松访问的资本基础。

Monad的完整EVM字节码兼容性使应用程序和协议实例可以从其他标准EVM（如ETH主网、Arbitrum和OP Stack）移植，而无需更改代码。这种兼容性既有优点也有缺点。主要优点是现有团队可以轻松将其应用程序移植到Monad。此外，为Monad创建新应用程序的开发者可以利用为EVM开发的丰富资源、基础设施和工具，如Hardhat、Apeworx、Foundry、Rabby和Phantom等钱包，以及Etherscan、Parsec和Dune等分析和索引产品。

易于移植的协议和应用程序的一个缺点是，它们可能导致懒惰、低效的分叉和应用程序在链上启动。虽然链拥有许多可用的产品很重要，但大多数应该是无法在其他链上访问的独特应用程序。例如，尽管大多数链都需要Uniswap V2风格或基于集中流动性的AMM，但链还必须吸引一类新的协议和应用程序，以吸引用户。现有的EVM工具和开发者资源有助于实现新颖和独特的应用程序。此外，Monad团队实施了各种计划，从加速器到风险投资竞赛，以鼓励链上的新颖协议和应用程序。

（2）生态系统概述

Monad提供高吞吐量和最低的交易费用，使其非常适合特定类型的应用程序，如CLOB、DePIN和消费者应用程序，这些应用程序非常适合从高速、低成本的环境中受益。

在深入探讨适合Monad的特定类别之前，了解为什么应用程序会选择在L1上启动，而不是在L2上启动或启动自己的L1/L2/应用链，可能会有所帮助。

 一方面，启动自己的L1、L2或应用链可能是有益的，因为你不必面对嘈杂的邻居问题。你的区块空间完全由您拥有，因此你可以在高活动期间避免拥塞，并保持一致的性能，无论整体网络负载如何。这对于CLOB和消费者应用程序尤为重要。在拥塞期间，交易者可能无法执行交易，而期望Web2性能的日常用户可能会发现由于速度变慢和性能下降而无法使用应用程序。

另一方面，启动自己的L1或应用链需要引导一组验证者，更重要的是，激励用户桥接流动性和资本以使用您的链。虽然Hyperliquid成功启动了自己的L1并吸引了用户，但有许多团队未能做到这一点。在链上构建使团队能够受益于网络效应，提供二级和三级流动性效应，并使他们能够与其他DeFi协议和应用程序集成。它还消除了专注于基础设施和构建堆栈的必要性——这很难高效和有效地完成。需要注意的是，构建应用程序或协议与构建L1或应用链大不相同。

启动自己的L2可以缓解其中一些压力，特别是与引导验证者集和构建基础设施相关的技术问题，因为存在点击部署的rollup-as-a-service提供商。然而，这些L2通常并不是特别高效（大多数仍然没有支持消费者应用程序或CLOB的TPS），并且往往存在与中心化相关的风险（大多数仍处于第0阶段）。此外，它们仍然面临与流动性和活动碎片化相关的缺点，例如低活动和每秒用户操作（UOPS）。

*CLOB

完全链上的订单簿已成为DEX行业的基准。虽然由于网络级别的限制和瓶颈，这以前是不可能的，但最近高吞吐量和低成本环境的激增意味着链上CLOB现在成为可能。以前，高gas费用（使得在链上下单昂贵）、网络拥塞（由于必要的交易量）和延迟问题使得完全基于链上订单簿的交易不切实际。此外，CLOB匹配引擎中使用的算法消耗大量计算资源，使得在链上实现它们具有挑战性且成本高昂。

完全基于链上订单簿的模型结合了传统订单簿的优势和交易执行和匹配的完全透明性。所有订单、交易和匹配引擎本身都存在于区块链上，确保在交易过程的每个级别都具有完全可见性。这种方法提供了几个关键优势。首先，它提供了完全透明性，因为所有交易都记录在链上，而不仅仅是交易结算，允许完全的可审计性。

其次，它通过在订单放置和取消级别减少抢先交易的机会来减轻MEV，使系统更加公平和抗操纵。

最后，它消除了信任假设并减少了操纵风险，因为整个订单簿和匹配过程都存在于链上，消除了对链下操作者或协议内部人员的信任需求，并使任何一方操纵订单匹配或执行变得更加困难。相比之下，链下订单簿在这些方面做出了妥协，由于订单放置和匹配过程缺乏完全透明性，可能允许内部人员抢先交易和订单簿操作者操纵。

链上订单簿与链下订单簿相比具有优势，但它们与AMM相比也具有显著优势：

虽然AMM通常由于LVR和IL导致流动性提供者损失，遭受价格滑点，并且容易受到过时价格的套利利用，但链上订单簿消除了流动性提供者对IL或LVR的暴露。其实时订单匹配防止了过时定价，通过高效的价格发现减少了套利机会。然而，AMM对于风险较高、流动性较低的资产确实具有优势，因为它们实现了无需许可的交易和资产上市，为新和流动性差的代币实现了价格发现。需要注意的是，如前所述，鉴于Monad上的区块时间较短，LVR与一些替代方案相比问题较小。

值得关注的项目有：Kuru、Yamata、Composite Labs等。

*DePIN

区块链本质上非常适合处理支付，因为它们具有抗审查的全球共享状态和快速的交易和结算时间。然而，为了高效地支持支付和价值转移，链需要提供低且可预测的费用和快速最终性。作为高吞吐量的L1，Monad可以支持新兴用例，如DePIN应用程序，这些应用程序不仅需要高支付量，还需要链上交易以有效验证和管理硬件。

历史上，我们看到大多数DePIN应用程序在Solana上启动，原因有很多。本地化的费用市场使Solana能够在链的其他部分拥塞时提供低成本交易。更重要的是，Solana成功吸引了许多DePIN应用程序，因为网络上有许多现有的DePIN应用程序。历史上，DePIN应用程序没有在以太坊上启动，因为结算速度慢且费用高。随着DePIN变得越来越受欢迎，Solana在过去几年中作为低费用高吞吐量的竞争对手出现——导致DePIN应用程序选择在那里启动。随着越来越多的DePIN应用程序选择在Solana上启动，形成了一个相对较大的DePIN开发者和应用程序社区，以及工具包和框架。这导致更多的DePIN应用程序选择在已经有技术和开发资源的地方启动。

然而，作为一个基于EVM的高吞吐量低费用竞争对手，Monad有机会吸引DePIN的关注和应用程序。为此，链和生态系统开发框架、工具包和生态系统计划以吸引现有和新的DePIN应用程序将至关重要。虽然DePIN应用程序可以尝试构建自己的网络（无论是作为L2还是L1），但Monad提供了一个高吞吐量的基础层，可以实现网络效应、与其他应用程序的可组合性、深度流动性和强大的开发者工具。

值得关注的项目有：SkyTrade

*社交与消费者应用

尽管过去几年金融应用在加密领域占据了主导地位，但最近一年消费者和社交应用越来越受到关注。这些应用为创作者和希望利用其社交资本的人提供了替代的货币化途径。它们还旨在提供抗审查、可组合且日益金融化的社交图谱和体验版本，使用户能够更好地控制自己的数据——或至少从中获得更多利益。

与DePIN用例类似，社交和消费者应用需要一个能够高效支持支付和价值转移的链——因此要求基础层提供低且可预测的费用和快速最终性。这里最重要的是延迟和最终性。由于Web 2体验现在已经高度优化，大多数用户期望类似的低延迟体验。支付、购物和社交互动的缓慢体验会让大多数用户感到沮丧。鉴于去中心化社交媒体和消费者应用通常已经输给了现有的中心化社交媒体和消费者应用，它们需要提供同等或更好的体验以吸引用户和关注。

Monad的快速最终性架构非常适合为用户提供低延迟和低成本的体验。

值得关注的项目有：Kizzy、Dusted

除了构建在Monad之上的CLOB、DePIN和消费者/社交应用之外，我们还对新一代基础应用感到兴奋，例如聚合器和LSD以及AI产品。

通用链需要拥有广泛的基础产品，以吸引并留住用户——使用户无需从一个链跳到另一个链来满足他们的需求。到目前为止，L2就是这种情况。如前所述，用户可能需要在Arbitrum上满足他们的期权交易或永续合约需求，同时需要桥接到Base以参与社交和消费者应用，