其实以太坊也在研究并行化的方案，但是推进速度会慢很多。在明年的 Glamsterdam 升级中，大概率会包含 EIP-7928（Block-Level Access Lists），这是并行化的第一步。 该方案强制在区块层收集一个完整、可验证的 BAL（区块可访问列表），包含了「这个区块所有读写的边界」，这样就有机会了解到哪些交易完全不冲突，那就可以并行执行了。 接下来就看执行层客户端的开发进度了，比如 Reth（由 Monad 的投资人 Paradigm 维护）、Nethermind、Erigon 等，都在积极做并行化的研究，但离生产上线还有一些距离的。 而 Monad 的技术，算是更快落地的，他们自下而上完全重构了整个链的技术架构： 1. 共识慢怎么办？ 基于 HotStuff 改进了一套低延迟的 BFT 共识协议 MonadBFT，把共识做成流水线，减少分叉和确认时间。 2. 区块在网络里传得慢怎么办？用 RaptorCast：先用 erasure coding 把区块切成很多小块，再通过分层广播的方式传输，只要收集到足够多的小块，就能还原完整区块，同时不会把单个节点的带宽打爆。 3. EVM 单线程速度慢怎么办？把同一个区块里的交易并行执行，先同时跑多个交易，记录各自读写了哪些状态；最后再按原本顺序依次提交，有冲突的交易就回滚重算，在保证结果与单线程一致的前提下吃满多核。 4. 共识和执行挤在同一个时间窗口里怎么办？把它们拆开做异步流水线：共识层快速确定交易顺序和基本合法性，执行层在后面慢几拍按顺序并行计算，这样既能高频出块，又给执行留足时间。 5. 状态读写拖后腿怎么办？Monad 自研了状态数据库 MonadDb，把 EVM 状态直接放进为区块链访问模式优化的 KV 存储里，并配合异步 I/O，尽量减少每次执行时的磁盘瓶颈。 6. 解释执行 EVM 还是慢怎么办？对高频合约做 JIT，把 EVM 字节码编译成本地机器码，后续调用这些合约时直接用原生指令执行，进一步压缩 CPU 开销。 总体来看，Monad 并不是在创造新的语言或虚拟机，而是在探寻现有 EVM 标准下的物理极限。它与以太坊殊途同归，只是选择了不同的工程路径：以太坊需要在承载巨量资产的「飞行途中」更换引擎，必然稳字当头；而 Monad 作为一个新启动的 Layer 1，则拥有「推倒重来」的后发优势，得以用现代数据库和分布式系统的最新成果，彻底重写底层的每一行代码。 但 Monad 最终如何，不看 TPS 跑分数据，而是看这台高性能引擎上，能不能真正长出那些在老架构上跑不动的杀手级生态。或者短期来说，还是看套利空间和是否有流动性溢价吧。(Zhixiong Pan)