Monad区块链技术架构

要点总结

• 高吞吐量和可扩展性：Monad 的架构通过并行执行和超标量流水线支持高达 10,000 TPS，从而优化了性能。

• EVM 兼容性：与 Ethereum 完全兼容，使开发者可以轻松移植 dApp 并利用 Monad 的可扩展性。

• MonadBFT 共识：一种高效的流水线共识机制，可确保快速的区块最终确认性并提高整体网络吞吐量。

• 优化的执行：结合了延迟和并行执行策略，以提高速度和交易效率，从而减少网络拥塞和成本。

Monad 技术架构特点

Monad 旨在对抗 Layer 2 的效率低下问题，并忠于 Monad 作为 Layer 1 的精神。为了实现这一目标，该网络提供了许多优势。这些包括：

• 高交易吞吐量： Monad 能够处理每秒 10,000 笔交易 (TPS)，这个数字大大优于大多数现有的区块链迭代。高交易吞吐量对于需要快速交易处理的应用至关重要。

• 并行执行： 通过实现并行执行，Monad 能够并发处理多个交易，从而显着提高网络效率，同时与本质上是顺序的传统执行方法相比，最大限度地减少延迟。

• 即时最终性： MonadBFT 流水线共识允许交易实现即时区块最终性，确保更快、更可靠的交易结算。

• Ethereum 兼容性： Monad 的 EVM 兼容性允许 Ethereum 开发者将其应用移植到 Monad，同时还提供对 Ethereum 界面和工具系统的熟悉度。

• 针对可扩展性进行了优化： Monad 最先进的并行执行和超标量流水线共识架构专门用于解决可扩展性瓶颈，使该平台能够支持不断增长的交易和用户数量。

• 更低的运营成本： Monad 平台的高效率确保了比大多数区块链系统低得多的交易费用，从而确保网络对用户和开发者而言便宜、易于使用且在经济上可行。

![截至撰写本文时，Monad 是业内唯一将 EVM 兼容性与并行执行相结合的区块链。（图片来源：Keone Hon via Monad Twitter)](https://img.learnblockchain.cn/2025/09/13/31909713_image.jpg)

截至撰写本文时，Monad 是业内唯一将 EVM 兼容性与并行执行相结合的区块链。(图片来源: Keone Hon via Monad Twitter)

Ethereum 性能瓶颈和 Monad EVM 兼容性

在当今的 Ethereum 格局中，Ethereum 区块链容易受到与其执行限制（每秒 125 万 gas）相关的几个性能挑战，包括：

• 存储访问模式不足

• 单线程执行（相对于多线程）

• 考虑到没有执行就无法实现共识，执行预算极其有限

• 与状态增长及其对未来状态访问成本的影响相关的问题

Monad 旨在通过算法改进和架构修改来解决这些约束，从而率先进行了多项创新，这些创新有可能在不久的将来在 Ethereum 上实现标准化。

Monad 旨在通过在四个重要领域（MonadBFT、延迟执行、并行执行和 MonadDb）中的流水线和优化来解决与状态存储、交易处理和分布式共识相关的瓶颈。这种设计通过从根本上推进去中心化/可扩展性的权衡来增强 EVM 性能。

此外，当前区块链格局中的许多网络都表现出极高的可扩展性，但缺乏 Ethereum 兼容性，这意味着它们的开发环境不允许 Ethereum 开发者轻松地将其应用移植到其链上。为了解决这个问题，Monad 通过实现完全的 EVM 字节码兼容性来解决开发者 (通过实现完全的 EVM 字节码兼容性) 和用户 (通过 Ethereum RPC API 兼容性) 的许多现有瓶颈。

通过这种设计，Ethereum 影响深远的工具系统和应用密码学的多方面格局能够以各种方式通过无缝插入 Monad 的开发者堆栈：

• 应用 允许与构建在 Ethereum 上的应用完全兼容，反之亦然

• 开发者工具 提供与各种 Ethereum 开发者工具系统（如 Hardhat、Apeworx 和 Foundry）的连接

• 钱包 能够与大多数 Ethereum 钱包类型（包括 MetaMask 等）实现跨系统功能

• 分析/索引 允许与各种分析和索引工具（如 Etherscan 和 Dune Analytics）完全集成

![Monad 利用超标量流水线来创建工作阶段，然后在并行执行这些阶段，从而大大提高了平台上的交易吞吐量。上面的图表将流水线与洗衣服进行了比较，说明使用该模型可以在更短的时间内完成更多的工作。（图片来源：Monad 有什么不同？通过 Monad 文档）](https://img.learnblockchain.cn/2025/09/13/19105470_image.png)

Monad 利用超标量流水线来创建工作阶段，然后在并行执行这些阶段，从而大大提高了平台上的交易吞吐量。上面的图表将流水线与洗衣服进行了比较，说明使用该模型可以在更短的时间内完成更多的工作。(图片来源: Monad 有什么不同? via Monad documentation)

超标量流水线和异步 I/O 概述

除了许多额外的创新之外，Monad 还利用超标量流水线和异步 I/O来帮助平台保持其超可扩展性。

超标量流水线是一种补充多线程和多核并行执行框架的流程，该框架允许通过按顺序阶段完成任务以并行方式执行交易（同时仍按最初的预期顺序提交结果）。

通过超标量流水线，在最初开始之前的阶段完成之前启动计算阶段，因此呈指数级地提高了整个系统的性能。流水线通常用于计算机处理器中，通过按顺序执行一组基于时间的指令来显着提高吞吐量。

异步 I/O 是一种输入输出处理机制，使 CPU 能够在通信进行时继续同时执行。通常，磁盘和网络订单比 CPU 慢得多。

因此，CPU 无需启动输入/输出操作并等待结果，而是能够在知道需要特定数据时立即启动输入/输出操作，同时执行不依赖于输入/输出操作结果的其他指令。

![巧妙地，Monad 通过四种主要方式实现流水线，以指数级地提高网络的可扩展性和交易吞吐量。这些包括在共识级别、交易执行期间、执行和共识阶段之间以及状态访问级别进行流水线。（图片来源：Monad Twitter 帖子通过 Monad Twitter）](https://img.learnblockchain.cn/2025/09/13/33824607_image.jpg)

巧妙地，Monad 通过四种主要方式实现流水线，以指数级地提高网络的可扩展性和交易吞吐量。这些包括在共识级别、交易执行期间、执行和共识阶段之间以及状态访问级别进行流水线。(图片来源: Monad Twitter post via Monad Twitter)

Monad 共识的相互关联的方面

Monad 共识利用了四个相互关联的组件，我们将在本节中更详细地介绍这些组件。这些是：

• Monad BFT 共识 - 一种 拜占庭容错 (BFT) 共识机制，通过部分同步条件实现对任意有效负载达成一致，以维持 BFT 容错。

• 延迟执行 - 通过将执行从共识的热路径中移除，从而实现对实现共识机制的主要优化。

• 共享 Mempool - 实现与共识有效负载相关的实质性优化，该优化允许协议按哈希引用交易，同时还确保交易事先通过 mempool 传播。

• Carriage Cost 和 Reserve Balance - 实现对交易定价的行为修改，这是防御垃圾邮件所必需的，因为共识是通过延迟的执行视图完成的。

![图片来源：SkillovuU 通过 Monad](https://img.learnblockchain.cn/2025/09/13/43504516_image.png)

图片来源: SkillovuU via Monad

Monad BFT 共识简介

Monad BFT 通过部分同步条件在 Byantine actor 的影响下实现交易协议。共识本身是HotStuff 共识的衍生产品，它实现了类似于 Joltean、DiemBFT 和 Fast HotStuff 等迭代的 2 轮，而不是通过在 leader 超时时实现二次通信复杂度的过程进行 3 轮。

MonadBFT 是一种两阶段流水线 BFT 算法，利用乐观响应性和线性通信开销以及超时事件中的二次通信。与大多数 BFT 算法类似，通信按阶段处理。

在每个阶段的开始，leader 在投票者对以下 leader 签署响应时向投票者发送签名消息。流水线使特定区块的仲裁证书 (QC) 或超时证书 (TC) 能够 piggyback 在该区块的提案上。

如果在此实例中显示仲裁证书，则表示网络的验证者同意附加该区块，而超时证书表示共识轮超时并且必须重新启动。

![拜占庭容错 (BFT) 是一种众所周知的共识机制，用于许多区块链系统中。MonadBFT 消除了早期以 BFT 为中心的网络容易受到影响的许多挑战。（图片来源：Zetrix 通过 Zetrix 文档）](https://img.learnblockchain.cn/2025/09/13/53343719_image.png)

拜占庭容错 (BFT) 是一种众所周知的共识机制，用于许多区块链系统中。MonadBFT 消除了早期以 BFT 为中心的网络容易受到影响的许多挑战。(图片来源: Zetrix via Zetrix documentation)

Monad BFT 共识概述

MonadBFT 利用流水线共识机制，该机制利用基于时间的共识轮（或时期）来处理交易并将区块附加到链上。与大多数 BFT 框架类似，在 Monad 上，2/3 的验证者节点必须是非对抗性的（被接受为合法且非恶意的），并且具有相等的投票stake权重。在 Monad 上，共识过程执行如下：

1. 在每轮共识中，leader 广播一个新区块以及来自上一轮的超时证书或仲裁证书。

2. 接下来，每个验证者审查该区块以确定是否应将其添加到链中。一旦达成一致，验证者会向下一轮的 leader 发送签名的 YES 投票。然后，leader 通过汇总来自系统中至少 2/3 的验证者的 YES 投票（通过阈值签名）来创建仲裁证书（本质上是对所有验证者都同意添加该区块的确认）。在这种情况下，通信是线性的，leader 将区块发送给验证者，而验证者将投票直接发送给下一个 leader。

• 相反，如果验证者在预定的时间内未收到区块，则它会向对等方广播签名的超时消息，该消息包括验证者观察到的最重要的仲裁证书。如果验证者从网络中诚实的验证者那里收集到超时消息 (至少 2/3 必须是诚实的)，它会将这些 (通过阈值签名再次) 汇总到超时证书 (TC) 中，并将其直接发送给下一个 leader。

3. 最后，每个网络验证者在收到来自以下共识轮（轮 2）的仲裁证书 (QC) 后，通过来自即将到来的共识轮 (轮 3) 的 leader 的通信，最终确定在初始共识轮（轮 1）中提议的区块。特别是：

• 轮 1 的 leader (Abby) 向每个validator发送一个新区块。

• 如果 2/3 的验证者通过将投票发送给轮 2 的 leader (George) 来投票 YES，则轮 2 中的区块将包括轮 1 的仲裁证书。尽管如此，在此实例中观察到轮 1 的仲裁证书不足以让 Beth 知道轮 1 中的区块是否已传播，因为（例如）轮 2 的 leader (George) 可能是恶意的，并且仅将区块发送给 Beth。Beth 唯一能做的就是通过将其投票发送给轮 3 的 leader (James) 来对轮 2 中的区块进行投票。

• 如果 2/3 的验证者对轮 2 中的区块投票 YES，则轮 3 的 leader (James) 会发送轮 2 的仲裁证书和轮 3 的区块提案。一旦 Beth 收到此区块，就很明显轮 1 中的区块 (Abby 的区块) 已最终确定。

• 如果轮 2 的 leader (George) 采取恶意行动，例如在轮 2 中发送无效的区块提案，或者将其发送给少于 2/3 (需要 2/3 的诚实验证者才能进入下一个共识阶段) 的网络验证者。然后，至少最大数量的拜占庭节点 +1 验证者将超时，因此触发其他非拜占庭 (非恶意的) 验证者超时，从而导致至少一个验证者为轮 2 生成超时证书 (TC)。接下来，轮 3 的 leader (James) 将在其提案中发布轮 2 的超时证书 (这是必需的，因为没有可用于轮 2 的仲裁证书)。

• 此提交过程称为 2 链提交规则，因为一旦验证者观察到 2 个相邻的经过认证的区块（区块 1 和区块 2），他们就能够提交区块 1 及其所有祖先。

![要生成 BLS 签名，必须将消息的哈希乘以私钥。（图片来源：Boneh-Lynn-Shacham 签名通过 Golden）](https://img.learnblockchain.cn/2025/09/13/58246573_image.png)

要生成 BLS 签名，必须将消息的哈希乘以私钥。(图片来源: Boneh–Lynn–Shacham signatures via Golden)

为了提供安全保证并提高可扩展性，Monad 结合使用了 Boneh-Lynn-Sachum (BLS) 签名和 椭圆曲线数字签名算法 (ECDSA) 签名。

虽然证书（即，仲裁证书和超时证书）可以通过 secp256k1 曲线用作 ECDSA 签名的向量，因为它们是显式且易于构造和验证的，但证书的大小与签名者的数量成线性比例。这掩盖了扩展的限制，因为证书包含在大多数共识消息中，投票消息除外。

为了解决这个问题，Monad 通过将 BLS 多重签名与 BLS12-381 曲线 (一种 BLS 签名椭圆曲线表示) 配对来使用它们。这允许将签名增量聚合为单个签名。验证单个有效的聚合签名证明，连接到公钥的 stake 已正确签署消息。

由于 BLS 签名比 ECDSA 签名明显慢，因此 MonadBFT 利用混合签名方案，其中 BLS 签名仅在可聚合消息类型 (通常是投票和超时) 中使用，而消息的完整性和合法性由 ECDSA 签名提供。

延迟执行

Monad 区块链被设计为一个将共识与执行分离的网络。延迟执行是一个过程，该过程利用在阶段中进行流水线共识执行。

回想一下，共识是 Monad 节点就网络上交易的官方排序达成一致的过程。另一方面，执行是实际执行这些交易以更新系统状态的过程。

具体而言，在 Monad 上，节点在 leader 或验证节点实际在网络上执行这些交易之前，就网络上交易的官方排序达成一致。

最终结果是，leader 提出特定的交易排序，而不知道状态根的结果，而验证节点在不确定区块内的所有交易是否将在不恢复到其初始状态的情况下执行的情况下，对区块的有效性进行投票。这种设计是使 Monad 具有超可扩展性的基本组件之一。

在 Ethereum 上，执行是共识的前提条件，这意味着当节点就区块达成共识时，他们同意区块内的交易列表以及封装了在执行该特定交易列表后状态的新版本的 merkle 根。

这意味着 leader 需要在提交提案之前执行提案区块中的交易，而验证节点需要在响应投票之前之前执行这些交易，以决定是否拒绝或接受该区块。

总而言之，Ethereum 上的交易执行效率极低，因为执行的时间预算特别有限，因为这两个过程必须在区块最终确定之前完成，同时还要留出足够的时间来完成几轮跨全球共识通信。

此外，由于执行将阻止共识，因此 gas 限制必须相当保守，以确保在发生灾难性情况时，所有节点中的计算都在预算内完成。

![图片来源：Monad 网站](https://img.learnblockchain.cn/2025/09/13/17107734_image.png)

图片来源: Monad website

共享 Mempool

Monad 在每个验证者的独立 mempool 中存储挂起的交易，然后再将它们包含在最终确定的区块中。此过程的工作方式是：通过擦除编码交易然后通过广播树进行通信来与其他验证者 mempool 共享交易，以提高效率。

MonadBFT 是实现与任意有效负载相关的协议的有效框架。尽管如此，区块传播瓶颈仍然很重要；例如，具有 10,000 笔交易和 500 字节交易的区块通常为 5MB，这意味着由于高带宽，这种大小的区块将限制验证者。为了解决这个问题，区块提案通过哈希独立地引用交易，以节省大量的网络带宽，因为哈希只有 32 字节。

Carriage Cost 和 Reserve Balance

延迟执行允许网络上的执行和共识并行发生，从而以指数方式扩展了执行的时间预算。在此过程中的某些时候，共识节点没有最新的状态视图，并且存在错误地包含来自已用完所有 gas 的帐户的交易的可能性，从而导致拒绝服务攻击媒介。

为了消除这种可能性，Monad 引入了在区块内通过网络发送交易的成本（即，carriage cost），为每个在共识期间更新的帐户实施储备金余额帐户，并针对储备金余额收取 carriage cost。在 Monad 上，对于每个地址，节点维护两种余额类型：

• 储备金余额用于支付 carriage cost

• 执行余额用于支付与交易执行相关的成本

通过此模型，carriage cost 将在该交易包含在区块中时（在共识期间）记入储备金余额。或者，carriage cost 在执行时从执行余额中扣除（作为双重收费），然后在区块延迟期过去后（10 秒后）偿还给储备金余额。

储备金余额代表“正在处理中”的订单（即，正在最终确定的交易）的预算，并且存在以确保只有已支付的交易才包含在区块中。目标储备金余额基于每个帐户参数，默认值通常是 carriage cost 的很大倍数 (200 倍)，使用户可以潜在地提交大量正在处理中的订单，而不会遇到问题。

还可以通过链上交易来增加储备金余额。这与做市商等可能每个区块提交大量订单的人员有关。

Monad 区块链执行

为了使 Monad 协议实现超高效的交易执行，网络使用了两个主要组件：

• 并行执行 - 构建在并行化 (或并行处理) 上的执行框架

• MonadDb - 允许存储和优化区块链状态的数据库

![图片来源：SkillovuU 通过 Monad](https://img.learnblockchain.cn/2025/09/13/81483395_image.png)

图片来源: SkillovuU via Monad

并行执行

作为关键的定义特征，Monad 利用并行执行以并发方式处理网络上的交易，以指数方式提高网络吞吐量和可扩展性。此模型与大多数传统区块链系统中通常使用的顺序方法不同。

在基础级别上，Monad 采用乐观执行，这意味着协议在区块中较早的交易实际完成之前开始交易执行。有时，这可能会导致不正确的执行。

这可能意味着在最初发送的交易之前执行错误的交易；因此，理论上具有错误地更新帐户余额的能力。

为了防止提交不正确的结果，乐观执行通过跟踪每个交易的输入和输出并在将结果提交到区块之前重新安排冲突来解决此问题。如果交易的输入与区块中前一个交易的输出不同，则很明显第二个交易在执行期间使用了不正确的数据，并且需要使用来自前一个交易的正确数据输出再次执行。

虽然有时需要重新执行，但不需要重新加载相关的交易数据。实际上，花费在执行上的绝大部分时间都花费在数据库读取上以加载此交易数据，因此当重新执行交易时，重新执行的开销很小，对每个需要重新执行的交易增加了约 1.5% 的额外开销。 [1]

因此，将乐观执行视为一个两阶段执行过程很有用，其中在第一阶段，交易数据被加载到内存中（有时正确执行），第二阶段保证正确执行。虽然在最坏的情况下，每个交易可能会被执行两次，但这只会对执行增加 1.5% 的开销，同时避免了复杂的调度和依赖性分析算法，而其他执行方法在有界的时间间隔内努力应对这些算法。

此外，Monad 的执行引擎旨在充分利用系统资源，同时在可能的情况下对重新执行做出明智的决策。虽然 Monad 始终会优先考虑已完成的操作，但在存在多个选项的情况下，它将按其自然的区块顺序安排重新执行。

例如，假设你有两个具有挂起的数据库操作的 TX：Tx2、Tx3。有 3 种情况：

• Tx2 返回，一个线程变得可用，Tx3 返回 → Tx2 首先执行。

• Tx3 返回，一个线程变得可用，Tx2 返回 → Tx3 首先执行。在 Tx2 执行后，可能需要重新安排 Tx3。

• Tx2 和 Tx3 在线程变得可用之前返回，然后一个线程变得可用 → 在这种情况下，我们按其区块顺序执行它们，因此 Tx2 在 Tx3 之前执行，即使 Tx3 在技术上首先返回。

[1] https://x.com/keoneHD/status/1744091485471948869?s=20

MonadDb

MonadDb 是一个用于存储区块链状态的自定义数据库，可极大地帮助提高链的交易执行系统的可扩展性。

大多数 Ethereum 客户端（形成节点的两个不同的软件）都以 B-Tree 或 LSM-Tree 数据结构的形式利用键值数据库。也就是说，Ethereum 使用 Merkle Patricia Trie (MPT) 数据结构来存储状态。这种组合导致了一种劣质的解决方案，其中一种数据结构被植根于另一种类型的数据结构中。相比之下，Monad 在磁盘上和内存中都原生利用 Patricia Trie 数据结构。

Monad 以并行方式执行多个交易。因此，当一个交易需要从磁盘读取状态时，另一个交易不应等待该过程完成。相反，交易应启动读取并同时开始处理另一个交易。为了解决这个问题，数据库应利用异步输入/输出 (async i/o) 模型。

我们上面提到的 Ethereum 客户端键值数据库缺乏正确的异步 i/o 支持。相反，MonadDb 利用最新的内核对异步 i/o 的支持，避免了依赖创建大量内核线程来管理挂起的 i/o 请求以异步执行所需计算的挑战。

资源

网站

文档

博客

Twitter

Discord

Telegram

DAIC 提供的信息，包括但不限于研究、分析、数据或其他内容，仅供参考，不构成投资建议、财务建议、交易建议或任何其他类型的建议。DAIC 不建议购买、出售或持有任何加密货币或其他投资。

• 原文链接： daic.capital/blog/monad-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～