集成化公链Solana和Monad性能优化方案对比

概述

不同于以太坊的模块化扩容线路，Monad主要对区块链集成化架构进行优化，更接近于Solana和Sui的方案,本文主要通过对比Monad和Solana的技术架构，来探讨下新一代高性能集成化公链的主要优化思路。

对比

mempool

传统的区块链如bitcoin和ethereum使用了全局内存池，即每个节点都需要在内存中缓冲全网待处理的交易，节点之间通过gossip协议进行交易广播同步，这种方式在交易量增大的时候会对节点内存和带宽造成压力，从而影响交易处理性能。Solana使用GulfStream取代了内存池，直接将交易转发给leader节点处理，因为leader节点是提前选定的，同时设置了约1分钟的交易超时时间，超时的交易会被丢弃，这样不仅加快了交易处理速度，同时减轻了网络带宽和验证节点压力。但引入的一个问题就是流量大时容易造成leader节点过载，这也是solana之前经常出现宕机的原因，这个问题当前通过SWQoS机制来缓解。

Monad的优化方案类似，因为使用的同样也是提前选定好leader节点的共识机制，交易直接转发给leader节点的本地内存，根据文档，当前设置的是转发给未来3轮的leader节点。 <!--StartFragment-->

<!--EndFragment-->

另外solana使用了QUIC网络协议，一种结合TCP和UDP有点的协议，为了更加快速稳定的传输交易。 可以看到通过优化或取消交易缓冲池，直接将交易提交给出块节点处理，提升交易处理速度并节省网络带宽和内存的消耗。但这种方式也只能使用在出块节点是预先选定并且顺序固定的共识方案中，并且牺牲了一部分去中心化。

共识

solana采用的是POS+PBFT混合共识，结合了创新的POH，POH相当于节点之间的加密同步时钟，使节点不需要相互同步消息就可以独立处理交易和共识相关的功能，提供交易时间戳、透明有序地进行领导者轮换，同时使改进的PBFT共识TBFT显著减少了通信轮次和通信复杂度，提升了共识效率。 Monad采用的是优化自Hotstuff的MonadBFT,参考FastHostuff将3阶段提交优化为2阶段，减少了共识达成时延，却增加了一定的通信复杂度。 这种BFT共识的优势是能提供即时的最终性，缺点是需要网络满足拜占庭条件，所以以太坊并没有直接使用BFT，而是使用POS+BFT结合的GASPER,在完成POS交易共识的基础上又叠加了一层BFT最终性共识。 共识机制会直接影响网络吞吐量和交易的最终确认时间，可以看到solana的改进相对比较激进，通过牺牲一部分去中心化去换取性能，例如公开固定的leader顺序，以及POH和GulfSteam对验证者节点硬件的高，。 单从共识算法性能的角度看，目前优化最好的应该是Sui的Mysticeti，交易最终性时间可以达到600多毫秒，几乎接近web2体验。这是一种DAG+BFT的共识方案，也可以看到结合BFT的高性能混合共识几乎已经算是新一代公链的主流方案了。

执行

二者虽然采用不同的VM方案，但都采用了并行执行提升速度，Solana会在交易中由开发者指定参与账户的地址和读写权限，对比Monad的乐观执行(发生冲突再重新执行)，显然并行效率会更高。 除了并行执行，Monad还采用了异步执行，即先对交易排序共识后才执行，这个算是Monad的创新，虽然提高了共识性能以及实现文档里声称的单时隙最终性，但却给交易预确认和MEV带来一定的复杂度。 另外Sui和Aptos也是并行执行的代表公链，从实现角度来看，Sui和Solana的并行机制更接近，而Monad和Aptos更接近，但由于Move语言的类似utxo的对象模型设计，在并行方面效率会更高。

状态存储

相对其他几个因素来说，状态存储目前依然是高性能公链的主要瓶颈，Solana没有使用传统数据库，而是利用了操作系统的机制，通过自定义的数据结构和索引布局，利用内存映射文件，实现了高并发、水平扩展的读写。MonadDB是经过优化的异步MPT结构化数据库，同样支持高并发下的顺序写随机读，但是为了兼容以太坊，也无法采用类似Solana的CloudBreak方案，理论上也达不到Solana状态存储的性能。 另一个比较直觉的优化就是状态缓冲，在Solana中是称为银行的阶段，缓冲了区块的当前状态，等共识完成才会持久化存储，Monad由于是乐观执行，为方便冲突后重新执行，状态缓冲也是必要的。

消息传输

网络传输的消息主要包含数据和控制两个平面，数据主要是交易和区块，控制主要是共识机制需要的元数据信息（这里主要讨论数据，控制平面的消息量相比数据平面可以忽略）。 在同步区块方面，Solana使用Turbine， <!--StartFragment-->

<!--EndFragment-->

而Monad使用RaptorCast， <!--StartFragment-->

<!--EndFragment--> 二者都是类似bitTorrent的方案，分片后进行纠删码编码，然后根据节点质押权重进行分级广播，最后在接收端重新组装，这么做都是为了尽量快速而稳定地将区块广播到全网。

总结

总结起来，影响区块链性能的几个瓶颈:传输协议、共识机制、交易执行以及状态读写，Solana和Monad都在这几个方面进行了极致优化，通过对比可以看到，Solana的很多实现还是比较激进，也有很多创新，而Monad就显得比较中规中矩，更多是在工程层面的优化。但是Monad兼容以太坊，更容易吸引以太坊生态的开发者，由于以太坊在分片方面进展比较缓慢，大量L2基础设施给生态带来的割裂，Monad也许会成为对TPS要求较高的EVM应用首选的公链。