Four Pillars研报：Monad 主网上线六个月都有哪些变化

作者：Rejamong，Four Pillars；编译：陶朱，金色财经

摘要

• Monad 应对区块链“不可能三角”挑战的方式并非提出一种全新模型，而是依靠极致的工程设计。它保留了 EVM 接口，同时对底层的共识、执行、网络传播和存储机制进行了重新设计与优化。MONAD_NINE 以及 MIP-3、MIP-4 和 MIP-5 等提案表明，Monad 运行的是一种高性能 EVM 变体，并通过调整资源定价和执行规则，使其适配自身的运行时环境。

• 高性能的代价是复杂性。异步执行、并行执行、预留余额（reserve balance）以及 RPC 层面区块状态的分离，都带来了 Monad 特有的复杂性。Monad 致力于通过 MIP 流程、开发工具、RPC 规范和预编译合约等手段，将这种复杂性抽象化，使其处于开发者和基础设施能够驾驭的范围内。换言之，Monad 的高性能是执行、内存、存储和网络传播等多个层面协同进行系统工程优化的结果。

• Monad 的下一阶段任务是超越“更快的 EVM”这一既有定位。其目标不仅仅是成为一条高速区块链，更在于构建一种全新的身份定位——在区块链需求持续增长的背景下，凭借长远的愿景，为构建者和用户提供留存的理由。

0. 引言

区块链三难困境，即如何同时解决安全性、可扩展性和去中心化问题，一直是区块链网络长期面临的难题。提高吞吐量通常需要减少验证节点数量或提高节点硬件要求，而这两种方法都会降低去中心化程度。

Monad 是一个追求高性能、去中心化和 EVM 兼容性的 Layer 1 区块链，于 2025 年 11 月 24 日正式上线。截至 2026 年 6 月，也就是上线六个月后，Monad 在实际环境中解决三难困境的进展如何？

本文将着眼于 Monad 上线六个月以来的成就，并非从代币价格或生态系统的角度，而是从协议的技术和基础设施层面进行分析，并探讨 Monad 的未来发展方向。

1. Monad 的核心假设

构建全新 Layer 1 的项目大致可分为两大阵营。一类项目（如 Aptos 和 Sui）设计了与以太坊截然不同的全新执行环境；另一类则力求尽可能保持与 EVM 的兼容性。

Monad 属于后者。它致力于确保开发者和用户所接触的接口尽可能与以太坊保持一致。其地址格式、交易结构、字节码兼容性以及 RPC 接口均与 EVM 生态系统保持高度相似。开发者几乎可以直接复用现有的 Solidity 代码和 EVM 工具链，而用户也能在很大程度上保留其熟悉的钱包和应用使用体验。

Monad 真正重构的是决定链性能的内部处理流程。其性能提升主要归功于以下五个方面：

• MonadBFT：基于流水线技术的快速 BFT 共识机制

• RaptorCast：利用纠删码实现高效区块传播

• 异步执行：将共识与执行分离，使区块生产无需等待执行完成

• 乐观并行执行与 JIT 编译：并行处理交易，并将频繁调用的合约编译为原生代码以优化执行效率

• MonadDB：专为在 NVMe SSD 上高效存储以太坊状态而设计的数据库

Monad 所改变的，实际上是 EVM 接口底层的实现，而非接口本身。其核心理念在于：在保持开发者与用户所见界面与以太坊完全一致的同时，为了提升性能，从零开始重构节点内部的共识、执行、状态访问及区块传播机制。

要实现这一愿景，必须同时满足三个条件：首先，在追求高性能的过程中，不能过度牺牲去中心化特性；其次，新设计的共识与执行架构必须在实际生产环境中真正达到预期的吞吐量与低延迟指标；最后，EVM 兼容性必须在开发者体验和工具支持层面得到切实保障。

本文旨在对照这一核心理念，审视 Monad 在问世后的头六个月里所进行的各项变革。

2. 协议变更的制度化流程：MIP

Monad 推出后引入的首个制度性机制是 MIP（Monad 改进提案）。MIP 是一套关于如何提出、讨论及记录协议变更的流程，相关讨论在 Monad 研究论坛上进行。

MIP-1 是一项定义 MIP 流程本身的元提案（meta-proposal）。它确立了针对 Monad 协议、生态系统标准及治理流程提出和讨论变更的正式框架。该机制参照了以太坊的 EIP-1，并根据 Monad 的架构进行了相应调整。2026 年上半年，已有数项提案通过了这一流程。其中一些已在主网上线（如 MIP-3、MIP-4、MIP-5），另一些则尚处于讨论或实施阶段（如 MIP-8、MIP-9、MIP-10 等）。

区块链本质上是由代码构成的协议；维持其运行并不断改进，意味着需要持续做出关键的设计决策。对于像 Monad 这样追求高性能的区块链而言，即便是微小的改动，也可能在多个层级引发连锁反应。将这些决策与讨论以 MIP 的形式公开记录，意味着协议变更不再局限于封闭的团队内部，任何人都可以对其进行追踪与验证。对于节点运营商和生态建设者来说，能够提前获知即将进行的变更及其缘由，具有极高的价值。

Monad 是一条由中心化力量主导、由 Category Labs 孵化启动的区块链。引入 MIP 这种开放式提案流程，是推动网络去中心化迈出的切实且可验证的第一步。然而，仅凭 MIP 流程本身并不等同于实现了去中心化治理。实际决策的核心权力仍掌握在创始团队手中，因此 MIP 应被视为这一进程的起点。

3. MONAD_NINE：首次重大升级

MONAD_NINE 是首个将通过 MIP（Monad 改进提案）流程讨论的提案落实为实际主网升级的案例。于 2026 年 3 月 19 日部署到主网的 Monad v0.13.0 版本是一次硬分叉，此次升级激活了 MONAD_NINE，其中包括 MIP-3（线性内存成本模型）、MIP-4（预留余额预编译合约）和 MIP-5（Fusaka 分叉及 CLZ 操作码激活）。

3.1 MIP-3：提高内存成本的可预测性

MIP-3（线性内存）改变了 Monad EVM 计算内存扩展成本的方式，将模型从二次方增长改为线性增长，并设定了单笔交易可使用的最大内存限制。以太坊 EVM 的设计使得成本随内存使用量的增加呈二次方增长，以此抑制过度使用内存的行为。Monad 将其改为线性增长以提高成本的可预测性，并通过明确的 8MB 上限规定了单笔交易可占用的内存量。这对并行处理大量交易的区块链至关重要：为了安全地管理并行执行，必须限制每笔交易在最坏情况下的内存使用量。

这也是对以太坊 Gas 成本模型的一次有意调整。对于相同的合约代码，同一项高内存消耗操作在以太坊和 Monad 上的 Gas 成本可能截然不同。Monad 保持了与 EVM 的兼容性，但并不追求资源定价等细节与以太坊完全一致。它通过重新调整经济参数以适应自身的执行架构，从而针对高吞吐量环境重新设定了 EVM 的定价机制。

3.2 MIP-4：检测合约内部异步执行的副作用

MIP-4（预留余额自检）引入了一个新的操作码，允许合约在执行过程中实时检查自身是否违反了预留余额规则。

要理解 MIP-4 的背景，首先需要了解 Monad 的异步执行机制。Monad 的异步执行将共识与执行分离开来。与以太坊节点先执行交易再达成共识的模式不同，Monad 先就交易顺序达成共识，随后再执行这些交易。这意味着执行不再是共识过程中的瓶颈，且可用于执行的时间也大幅增加。Monad 的异步执行机制将在 4.1 节中进行更详细的介绍。

然而，这种架构也带来了一个新问题：节点需要在无法完全获知最新执行状态的情况下，构建区块并就其达成共识。为了解决这一问题，系统引入了“预留余额”（reserve balance）规则。简单来说，预留余额机制确保每个外部账户（EOA）的余额不会降至特定阈值以下；这样一来，即使不完全掌握最新状态，共识层也能判断出“该账户有能力支付 Gas 费用”。

MIP-4 允许智能合约在执行过程中检查预留余额的状态。该提案在地址 `0x1001` 处新增了一个预编译合约，其中的 `dippedIntoReserve()` 方法用于返回预留余额是否已被动用的状态。借助这一功能，合约能够在执行中途检测到此类情况，并采取相应措施——例如恢复余额、切换至不同的执行路径，或者在抛出更有意义的错误信息的同时快速回滚交易。

这是 Monad 特有的操作码，以太坊（EVM）中并不存在。Monad 并未局限于单纯遵循 EVM 标准，而是根据自身架构的需求增加了自定义指令。

3.3 MIP-5：反映以太坊升级

MIP-5（Fusaka EIP 激活）将以太坊 Fusaka 硬分叉中的三项执行层 EIP 应用于 Monad。

• EIP-7823（设置 MODEXP 上限）：限制 MODEXP 预编译操作的输入大小（底数、指数和模数各限制为 8192 位）。

• EIP-7883（提高 ModExp Gas 成本）：提高 MODEXP 的 Gas 成本，以匹配其实际计算开销。

• EIP-7939（CLZ 操作码）：新增 CLZ（计算前导零）操作码，用于统计 256 位字（word）中的前导零位数。

Fusaka 总共向以太坊引入了 13 个 EIP，而 Monad 仅采纳了其中的三个。原因在于，Monad 的共识机制（MonadBFT）、数据传播机制（RaptorCast）及数据可用性方案均为完全自主设计，与以太坊截然不同。为了保持与 EVM 字节码的兼容性，Monad 仅需跟进那些直接影响执行层（即 EVM 本身）的预编译合约及操作码（opcode）变更。无论如何，为了维持与以太坊的兼容，Monad 必须持续追踪 EVM 的变更，并不断评估哪些变更值得采纳。

3.4 Monad EVM 兼容性的方向

MONAD_NINE 包含的三项 MIP（Monad 改进提案）明确了 Monad 的发展方向。Monad 所主张的 EVM 兼容性并非简单地照搬 EVM。它特意修改了 Gas 成本模型以适配自身的执行引擎（MIP-3），在架构需要时增加自定义操作码（MIP-4），并有选择地跟进兼容性所需的以太坊变更（MIP-5）。Monad 并非原封不动地使用以太坊 EVM，而是运行一个经过重塑、以适配其自身执行环境的变体版本。

3.5 RPC 语义的转变

在 MONAD_NINE 中，开发者和基础设施提供商最直观感受到的变化在于 RPC 行为。

“最新区块”（latest block）的基准从“已最终确认”（Finalized）变更为“已提议”（Proposed）。因此，像 `eth_getBalance` 和 `eth_call` 这样的状态查询可以基于更新的区块进行响应，而 `eth_sendRawTransactionSync` 的基准也从“已投票”（Voted）提升至“已提议”（Proposed）。WebSocket 的 `newHeads` 和日志通知机制也从“已最终确认”变更为“已投票”基准。

这一变化有助于降低延迟。然而，对于开发者而言，这也增加了区分“最新状态”与“已确认状态”的负担。将 `latest` 返回为“已提议”状态而非“已最终确认”状态虽然能带来低延迟，但该状态更接近于尚未达成共识的“暂定执行状态”。为了平衡这一点，Monad 针对其他区块条件增加了新的标签：`safe` 对应投票完成的状态，而 `finalized` 对应完全确认的状态。对于任何涉及实际价值结算的场景——如跨链资产转移、充值入账或支付结算——建议基于 `finalized` 状态进行查询。在 MONAD_NINE 之后，在 Monad 上读取 `latest` 意味着读取速度最快的状态，而非不可逆转的已确认状态。

这一变化很好地体现了 Monad 的性能理念。追求快速用户体验（UX）的前端应用可以使用 `latest` 以获取更及时的状态；但索引器、跨链桥、支付系统及链下记账系统则必须明确区分 `latest`、`safe` 和 `finalized` 之间的差异。在高性能链上，不仅区块生成速度更快，区块状态的解读方式也变得更加精细。

4. 异步与并行执行的现实：EVM 兼容性背后的隐性成本

MIP-3 和 MIP-4 实际上源于 Monad 执行引擎的两大支柱：异步执行和乐观并行执行。这两者既是实现高性能 EVM 的核心，也是实现 EVM 兼容性所面临的最大障碍。本章将探讨这两大支柱的实际运作机制，以及维持“外观与以太坊一致的接口”所付出的代价。

4.1 异步执行：共识无需等待执行完成

在以太坊上，在提议区块之前，必须先执行区块内的所有交易并计算状态根。对于 Monad 而言，在 400 到 500 毫秒的区块时间内完成这些操作时间不足。因此，正如 3.2 节所述，Monad 将共识与执行分离开来。领导者（Leader）仅通过设定交易顺序来提议区块，而执行则在随后基于滞后的状态进行。系统先就交易顺序达成共识，随后才确认最终的状态结果。这是 Monad 高性能的核心所在。当共识无需等待执行完成时，区块生成速度便能大幅提升。正因如此，Monad 区块并不携带当前的状态根，而是携带滞后了 D 个区块的状态根（目前 D=3）。从协议的角度来看，执行总是滞后于共识三个区块。

然而，这种架构也伴随着代价。共识层必须在无法完全获知最新执行状态的情况下构建区块——这正是 EVM 兼容性所带来的隐性成本所在。表面上看，执行的是同样的交易和合约，但实际上，共识与执行之间存在时间差。为了安全地处理这一时间差，Monad 必须针对 Gas 计费、余额预留（reserve balance）以及 RPC 状态模型进行专门设计。在以太坊上能顺利处理的交易，在 Monad 上可能会因余额预留规则而被回滚；此外，轻客户端或某些跨链桥系统也必须考虑到：Monad 区块携带的状态根（state root）并非当前状态，而是三个区块之前的状态。

4.2 并行执行

Monad 采用乐观并行策略来执行区块中的交易。它首先假设交易之间不存在冲突并同时运行它们，同时追踪每笔交易的读写集；一旦发现冲突（例如两笔交易涉及同一状态），系统便会利用正确的数据仅重新执行受影响的交易。最终状态与以太坊串行执行的结果一致，因此实际可见的执行结果不会发生变化。

当交易彼此独立时，并行执行的优势最为显著。然而，当出现资源争用——即大量交易同时涉及同一状态——时，问题便随之而来。当所有交易蜂拥至同一个热点（如热门 AMM 池、Meme 币铸造或 NFT 发售）时，冲突和重新执行的频率就会上升。问题在于，链上加密资产的需求往往恰好呈现这种聚集特征。在吞吐量至关重要的峰值时刻，往往也是并行执行效率最低的时刻。因此，常被引用的 Monad 10,000 TPS（每秒交易数）这一可扩展性指标需结合具体条件来看待：这是一个基于交易具有高度并行化潜力的理想条件下的数值，而非实测数值。

4.3 Gas 费用按上限（Limit）而非实际用量收取

以太坊与 Monad 之间最明显的区别体现在 Gas 费用的收取方式上。习惯于以太坊的开发者通常认为费用是根据“实际消耗的 Gas”来计算的。但在 Monad 上，交易费用是根据设定的 Gas 上限（Gas Limit）收取的，而非实际消耗的 Gas 量。这种变化源于 Monad 的异步执行机制。

回顾 Monad 的异步执行机制，原因便不难理解。在异步执行模式下，Leader（领导者节点）和验证者节点会在执行交易之前先构建区块并进行投票。如果仅按实际消耗的 Gas 收费，攻击者可能会提交一笔 Gas 上限极高的交易，占用区块中大量的 Gas 空间，而在实际执行时却消耗极少的 Gas，从而以低廉的成本完成交易。这将成为一种攻击手段，使攻击者能以远低于正常价格的成本占用区块空间；若被滥用，甚至可能引发拒绝服务（DoS）攻击。为了防止这种情况，Monad 采取按提交的 Gas 上限收费的策略，而不是按交易实际消耗的 Gas 收费。这直接影响了开发者体验和用户体验。在 Monad 上，设置过高的 Gas 上限（gas limit）成本高昂。因此，钱包、前端、后端及 Bundler（打包器）在处理 Gas 上限设置时必须更加谨慎。

4.4 EVM 兼容性并非没有代价

Monad 致力于保持与 EVM 尽可能高度一致的接口层（包括智能合约和工具），以确保兼容性。然而，为了提升性能，Monad 改变了内部执行结构，而解决由此引发的问题也带来了一些差异。这些差异正是实现 EVM 兼容性所付出的隐性代价。应用程序越复杂——尤其是在那些对状态实时性和最终性要求极高的领域（如跨链桥、支付、衍生品、高频交易、账户抽象及索引基础设施）——开发者就越需要深入理解 Monad 的内部机制并加以留意。

鉴于此，Monad 需要将高性能执行机制所带来的不可避免的复杂性进行抽象，将其简化至开发者和基础设施能够轻松应对的程度。从这个角度来看，过去六个月的更新至关重要：MIP-3 重新调整了资源定价机制，MIP-4 允许合约检测异步执行过程中的异常情况，而 RPC 规范也开始更明确地区分区块状态与暂定数据（tentative data）。

5. MIP-8：将状态访问下沉至实际硬件单元

MIP-8（基于页面的存储状态）目前尚未在主网上线，仍处于 MIP（Monad 改进提案）讨论阶段。Monad 早期专注于实现快速共识、并行执行和异步执行。然而，对于生产环境而言，仅优化共识机制和执行引擎并不足以构建一条真正的高性能区块链。交易最终涉及对合约状态的读写，而这些状态存储在节点的存储层中。因此，随着区块链吞吐量的提升，状态读写的速度便成为了关键瓶颈。

MIP-8 的设计灵感源于 EVM 抽象模型与底层硬件实际运作方式之间的差异。对于智能合约而言，存储表现为一长串 32 字节的存储槽（slot）；但在实际硬件和数据库层面，数据的读写单位要大得多。例如，SSD（固态硬盘）以 4KB 的“页”（page）为单位进行读写，而一个页可容纳 128 个 32 字节的存储槽。当 Monad 节点读取内存中不存在的某个存储槽时，底层磁盘实际上会加载该槽所属的整个 4KB 页。这意味着，在读取一个存储槽的同时，相邻的另外 127 个存储槽实际上也被一并读取了。

问题在于，现有的 EVM 存储模型并未体现这一特性。EVM 按单个存储槽处理状态，而以太坊的 Merkle 树（Merkle trie）通过对槽的键（key）进行哈希处理来存储数据。这种做法虽有助于保持树结构的平衡，却导致逻辑上相邻的数据在物理磁盘上被分散存储。结果，即使是读取同一合约内的连续存储槽，也可能需要反复读取不同的页，从而降低了效率。

为了解决这一问题，Category Labs 提出了 MIP-8。该提案的核心思想是将底层硬件使用的 4KB 页提升为 EVM 状态访问中的“一等公民”概念。该协议将每 128 个连续的存储槽归为一页，并在 Gas 计费规则和存储布局中明确支持这一页的概念；同时，Merkle 树的结构也进行了重组，改为以页为单位而非以单个存储槽为单位进行提交（commit）。

在 Gas 费用方面，用户仅在首次访问某个页时需支付较高的“冷访问”成本，而对于同一笔交易中该页内的其他存储槽，则只需支付较低的“热访问”成本。换言之，对于已从磁盘加载到某个“页”（page）中的数据，该协议会识别出其“已在内存中”的状态，从而降低收费。因此，使用连续槽位（如数组、结构体、紧凑排列的状态变量）的数据模式，其成本自然会降低。

即便实施了 MIP-8，EVM 的 32 字节槽位模型依然保持不变，这意味着 Monad 开发者仍可编写 Solidity 代码，且现有合约能照常运行。发生变化的是底层的状态存储与计费方式：EVM 接口保持原样，而内部的状态访问单元则更贴近真实的硬件特性。

对于开发 Monad 应用的开发者而言，合约优化的范畴不仅限于减少存储访问次数，还包括尽可能将经常一起读取的状态数据放置在同一个“页”内。这种做法将 EVM 开发者熟悉的存储优化问题，与硬件层面的数据访问单元联系了起来。为了实现基本兼容性，您无需重写以太坊合约代码，但若要针对性能和成本进行优化，则可能需要修改代码。

Monad 追求“在不牺牲去中心化的前提下实现高性能”的路径，更倾向于将区块链视为一个高性能系统工程问题来解决，而非引入 ZK（零知识证明）、新型虚拟机（VM）或分片等新模型。从共识与执行流水线，到基于磁盘页（disk-page）层级的 Gas 计费模型，Monad 充分借鉴了 CPU 和分布式系统工程领域的技术，并将其调整至契合硬件实际运行特性的状态。

6. RaptorCast 与网络层

6.1 RaptorCast

区块链本质上是一个点对点（P2P）网络。无论共识与执行机制优化得多么出色，如果区块无法快速到达各个节点，一切都将失去意义。Monad 的出块时间仅为 400 毫秒，而这短暂的时间窗口中，大部分都消耗在分布于全球各地的验证者之间的通信上。对于这种追求极短出块时间的链而言，区块传播本身便成了共识过程中的核心瓶颈。以太坊采用 libp2p (GossipSub) 作为其共识层的消息传递基础设施；然而，Monad 不仅在出块时间上与以太坊不同，其共识结构也存在差异，因此它采用了专有的区块传播协议——RaptorCast。

RaptorCast 是 MonadBFT 协议中由领导者（Leader）使用的专用组播协议，用于将区块提案传播给验证者。领导者利用纠删码（erasure coding）技术将区块提案拆分为多个数据分片，并通过一个两级广播树将这些分片分发给验证者。非领导者验证者充当特定分片组的一级转发节点，而每个验证者被分配的分片份额则取决于其质押权重。由于每个数据分片仅需两跳（hop）即可覆盖整个网络，因此传播时间将收敛至单次往返时间（RTT）——即网络中距离最远的两个节点之间的通信耗时。

由于区块传播会同时利用整个网络的上传带宽，因此无论验证者数量多少，单个验证者所需的带宽都固定在区块大小的约三倍。无论是有 100 个还是 500 个验证者，单个节点所需的网络带宽都不会增加。这正是 Monad 能够实现“基于普通网络连接的大规模分布式验证者集”与“高性能、高吞吐量”并存这一主张的基础。

RaptorCast 运行在 UDP 而非 TCP 协议之上。由于 TCP 的重传机制和队头阻塞（head-of-line blocking）问题会直接导致延迟，RaptorCast 将丢包视为常态而非异常，并通过节点运营者可配置的纠删码（erasure coding）冗余级别来处理丢包问题。作为权衡，每个数据包都携带了领导者（leader）的签名和证明，从而在允许丢包的同时防止了数据被篡改。此外，一级中继节点在转发接收到的数据块时，不会对其进行重新编码。

RaptorCast 的用途不仅限于验证者之间的区块传播。领导者向活跃验证者集分发区块提议的过程被称为“主 RaptorCast”（Primary RaptorCast）；此外还有“次级 RaptorCast”（Secondary RaptorCast），即每个验证者将其区块传播给下游的全节点。次级 RaptorCast 的原理类似，但它将所有参与节点视为同等权重，而不考虑质押量。在推荐配置下，每个验证者可以维护一个包含约 150 个全节点的次级 RaptorCast 组；这意味着若有 200 个验证者，网络总容量可达 30,000 个全节点。考虑到冗余因素，该架构在全网范围内可支持约 15,000 个全节点。对于高性能区块链而言，网络核心的性能固然重要，但用户直接交互的全节点能否可靠地接收区块并同步链的最新状态，同样至关重要。次级 RaptorCast 这一网络设计，确保了像 Monad 这样的高性能链上全节点的参与保持稳定。

无论是有意为之还是巧合，RaptorCast 的架构本身就缓解了因网络地理分布不均（geographic skew）而带来的问题。以太坊的 GossipSub 采用的是基于网状拓扑（mesh-based）的多跳传播机制。由于消息在点对点之间经过多次跳转（hop）进行传播，传播延迟会随跳转次数累积，导致节点的跳转计数及其在网状网络（mesh）中的位置取决于其地理位置和连接状况。节点评分机制进一步加剧了这种偏差，使得距离消息源较远的节点在系统层面处于不利地位。Monad 的 RaptorCast 机制通过将跳转次数固定为两次，规避了这一问题。无论节点位于亚洲还是非洲，都不会再因跳转次数累积而处于劣势。这并不意味着 Monad 在技术上优于以太坊；这种差异源于两者共识算法的结构性前提不同。以太坊的 GossipSub 协议假设节点之间互不了解，而 MonadBFT 运行在一组已知的验证者集合之上，且各验证者的质押权重也是已知的。因此，Monad 能够在协议层面规划由哪个节点转发哪个数据块。

然而，RaptorCast 并未彻底解决节点地理分布分散的问题。Monad 的消息传播时间最终收敛于距离最远的两个节点之间的往返时间（RTT），这意味着节点的地理距离决定了出块时间的下限。验证者集合的地理分布越广泛，最坏情况下的 RTT 就越大，从而使得 400 毫秒的出块时间预算变得更加紧张。随着 Monad 扩大验证者集合规模并向真正的无许可网络演进，这一问题可能会变得日益突出。

6.2 MIP-10

MIP-10（确定性 RaptorCast）是一项旨在主网启动后改进 RaptorCast 的提案。MIP-10 将 RaptorCast 的编码过程绑定到一个可公开计算的种子（seed）上。这意味着验证者在接收到单个已验证数据分片（piece）时，无需等待重构整个区块，即可立即对 Merkle 根进行投票。其目标是将完整的区块解码过程从共识的关键路径中剥离出来。这样，即便前一个区块的数据分片仍在网络中传播，下一任领导者（leader）也能收集投票以生成法定人数证书（QC）并开始生产下一个区块；从而使区块时间不再受限于整个区块的传播耗时。

进一步解释 MIP-10：在现有方案中，领导者可以自由选择纠删码（erasure coding）的种子，且编码承诺是按每 32 个数据包为一批来生成一个 Merkle 根的。这种灵活性虽然带来了性能上的优势，但也给恶意领导者留下了可乘之机——例如，他们可以向特定验证者仅发送不利于重构的数据分片，或者制造歧义，使同一个 Merkle 根可能对应多个不同的有效载荷（payload）。MIP-10 规定编码种子必须是确定性的，并要求每一轮记录其接收到的第一个有效的“Merkle 根与领导者签名”组合；这种安全加固措施有效缩小了攻击面。

用于点对点通信的网络层至关重要，它深刻影响着区块链的性能与去中心化程度。Monad 没有简单地沿用常规的 Gossip（流言）协议来进行区块传播，而是针对 MonadBFT 的架构在协议层面重新设计了传播机制。不过，RaptorCast 并不能解决所有问题。随着验证者集合的扩大及其地理分布的日益广泛，维持 400 毫秒的区块时间将变得愈发困难。因此，随着 Monad 的不断演进，网络层也必须持续进行相应的调整与优化。

7. 迈向去中心化的方向

迄今为止，我们已经探讨了 Monad 如何在主网上线后的六个月内，在实际运行环境中不断优化其核心技术前提——即高性能区块链与 EVM 兼容性。然而，Monad 并非仅仅追求高性能；从创立之初，其愿景便是同时实现高性能、EVM 兼容性与去中心化。

对于高性能区块链而言，去中心化是一个极具挑战性的难题。随着出块时间的缩短，网络质量、硬件性能及运行稳定性对节点的要求也随之提高，这不可避免地限制了能够参与的验证者范围。尽管性能优化在技术层面提升了吞吐量，但在实际运营层面却可能给去中心化带来压力。本章将审视 Monad 主网上线以来去中心化的实际状况，并探讨该项目如何应对这一挑战。

7.1 Monad 去中心化的现状

Monad 是一条采用委托权益证明（DPoS）机制的区块链。注册成为验证者本身是无需许可的，但若要实际参与共识，验证者必须满足特定条件并被纳入活跃验证者集合。

成为活跃验证者需要满足三个条件：首先，验证者的认证地址（auth address）必须至少自抵押 10 万枚 MON；其次，验证者收到的委托总额必须至少达到 1000 万枚 MON；最后，按抵押权重计算，其排名必须进入“活跃验证者集合规模”（ACTIVE_VALSET_SIZE）的前列。目前，ACTIVE_VALSET_SIZE 设定为 200。未能满足上述条件的验证者将在下一个纪元（epoch）被移出活跃集合。虽然任何人都可以参与，但能否跨越门槛则取决于资本实力。

Monad 验证者所获得的委托资金究竟来自何处？探究这一资金来源，会让关于其去中心化进程的叙事变得更为复杂。Monad 基金会一直通过“验证者委托计划”（VDP）将其持有的代币委托给验证者。在第一轮计划中，基金会向 170 个验证者委托了约 93 亿枚 MON 代币（约占总供应量的 9.3%）；此外，基金会还向入选的验证者提供了一笔 10 万枚 MON 的一次性拨款，以满足最低自质押要求。这种机制意味着，基金会的选择在很大程度上决定了哪些验证者能进入活跃验证者集合。在第二轮 VDP 中，基金会将其委托规模削减了 25%，这显示出一种逐渐降低对基金会依赖的趋势；然而，Monad 验证者能否成功入选，依然在很大程度上取决于基金会的委托。

对于采用 DPoS（委托权益证明）机制的区块链而言，这是一个经典的困境。在“质押即共识权重、共识权重决定链安全”的架构下，网络在早期阶段就需要一个值得信赖的验证者集合以及充足的委托资金。因此，大多数基金会都会预先铸造代币，并将其委托给稳健的验证者。尽管这是提升新兴公链在启动阶段安全性和稳定性的最务实手段，但它也将挑选网络参与者的权力集中在了基金会手中。

大多数区块链都预期这一问题会随着时间的推移自行解决：随着基金会的质押份额被稀释，以及技术进步使得在维持同等性能的前提下能够容纳更多活跃验证者（从而降低准入门槛），问题便有望化解。但这仅仅是一种乐观的预期，而非系统性的保障。最关键的是，即便活跃验证者的数量远超当前水平，网络性能仍需保持稳定。Monad 早期的去中心化进程正处于两种诉求的博弈之中：既要确保网络在预期性能下稳定运行，又要减少对基金会的依赖，从而吸纳更多的外部委托和验证者。

7.2 MIP-9 与增加活跃验证者数量

在上述背景下，主网上线六个月后，首个旨在推动去中心化的提案是 MIP-9（活跃验证者集扩容）。MIP-9 提议将活跃验证者数量（`ACTIVE_VALSET_SIZE`）从 200 个增加到 300 个，该提案目前处于草案阶段。增加活跃验证者数量虽不直接影响执行守护进程（execution daemon），但会影响共识层 MonadBFT，因为活跃验证者集的规模直接决定了每轮共识中参与节点的数量。根据 MIP-9 提案，增加 100 个节点意味着 50% 的显著扩容，但这一增幅尚不足以剧烈改变 MonadBFT 投票轮次中的消息复杂度。

即便 MIP-9 最终在主网上实施，使活跃验证者数量从 200 个增至 300 个，也不意味着去中心化程度有了质的飞跃。参与门槛必须进一步降低，基金会的委托影响力也需进一步减弱。如果 Monad 志在成为通用区块链并声称已解决“不可能三角”难题，那么在这一点上便不容妥协。MIP-9 表明 Monad 并不单纯追求高性能，但这并非 Monad 去中心化进程的终点。

7.3 缺乏自动惩罚机制（Slashing）

Monad 目前没有自动惩罚机制。在权益证明（PoS）区块链中，惩罚机制（Slashing）是确保攻击成本高于防御成本的最强有力安全工具。针对双重签名或违反共识规则等行为，协议应当自动削减违规验证者的质押资产，从而确保恶意行为的预期成本超过其预期收益。

Monad 通过日志记录来追踪验证者的恶意行为并明确责任归属，但目前尚未在协议层面实现自动惩罚。虽然系统能够检测到违规行为，但执行经济惩罚则交由协议之外的社会层处理。是否引入惩罚机制以及何时引入，将成为 Monad 安全性从启动阶段过渡到自我维持安全阶段的一个重要标志。

8. 结语：Monad 的未来展望

正如我们所见，Monad 解决所面临问题的方式，是逐一将各个系统瓶颈推向极限。它重构了运行 EVM 的物理基础，消除了共识对执行过程的依赖，并针对内存、存储和网络进行了深度调优以加速验证。Monad 解决去中心化与性能之间权衡（trade-off）的手段，正是彻底的系统工程实践。

这彰显了 Monad 工程团队的实力，但也构成了其局限与风险。Monad 依然建立在现有区块链的基本范式之上，并未从根本上跳出“通过重新执行（re-execution）进行验证”的既有架构。未来或许会出现某个项目，采用截然不同的模型以更简洁的方式解决同样的问题；届时，Monad 费尽心力优化和解决的性能瓶颈，可能会被另一种技术路径所取代。

EVM 兼容性也是一把双刃剑。这是 Monad 最显著的优势：开发者可以沿用现有的 Solidity 代码与工具链，用户也能保留熟悉的钱包与应用体验。对于生态系统而言，这意味着极低的准入门槛，能够轻松吸纳来自以太坊及更广泛 EVM 生态的流动性与开发者资源。然而，同样的特性也意味着用户和开发者极易流失。既然构建者能轻易迁移至 Monad，那么一旦 Monad 无法提供足够的性能、流动性、用户群或创收机会，他们同样可以轻易转投其他 EVM 链。对于 EVM 兼容链而言，必须创造出让用户留下的充分理由——仅仅做到“更快的 EVM”是远远不够的。

过去六个月里，Monad 成功展示了兼具高性能与一定程度去中心化的 EVM 的潜力。然而，仅凭速度优势就能称霸区块链的时代已经终结。区块链用户群体正从最初宣扬密码朋克（cypherpunk）理想的早期采用者，扩展至更广泛的大众及机构用户；随之而来的，是网络需求的变化。随着用户群体的扩张，需求本身的性质也在发生演变。

顺应这一转变，Monad 必须重新定义其所要解决的问题。而这一进程的起点，已经就绪。正如我们在第二章所见，Monad 在上线后建立了 MIP（Monad 改进提案）机制，过去六个月的大部分重大改进都是基于该机制实现的。协议变更的讨论变得规范化且公开透明，这意味着 Monad 不再仅仅是一个由封闭团队内部主导的项目；不过，目前的 MIP 仍主要由核心开发团队和基金会提出并主导。

展望未来，Monad 必须超越单纯解决工程瓶颈的阶段，明确阐述其长期的发展愿景，即最终要构建一个什么样的网络。同时，认同这一愿景的各类生态参与者，也应能够基于各自的视角，通过 MIP 机制提出发现的问题。参与 MIP 流程的群体必须从基金会和核心团队扩展至整个生态系统。

Monad 当前需要的是重新定义问题，并转变发展模式，不再局限于通过系统工程手段解决技术瓶颈。如果说过去六个月展示了 Monad 的能力，那么接下来的阶段则要展示 Monad 的长远愿景与发展目标。