作者：RachitSrivastava，Avail建设者；翻译：xiaozou

Monad是一个EVM兼容L1链，但围绕以太坊的核心支柱重新进行了一些重大思考。所以，Monad能够每秒处理高达10,000笔交易。最近Monad发布了他们的devnet。

它应用如下两个概念：Pipelining和异步I/O。Pipelining是一种通过将任务划分为一系列可以并行处理的小任务来实现并行性的技术。而异步I/O是一种输入/输出处理形式，允许CPU在通信进行时就可进行并发执行。

那么MonadBFT有什么不同之处呢？MonadBFT是一种具有乐观响应形式的pipelined两阶段BFT算法，在一般情况下采用线性通信开销，在超时情况下采用二次通信开销。

下面我们假设所有节点具有相同权益。

--MonadBFT需要2/3的节点达成共识。

--Leader发送一个新区块以及“QC”或“TC”（阈值签名是一种加密技术，它将生成数字签名的能力分配给多个参与方。没有任何一方可以代表整个团体签名，必须由各方的一个子集（“阈值”）协作来生成签名。）

--验证者验证区块，并向leader发送Yes或No的响应。Leader通过聚合Yes和No投票（通过阈值签名）派生QC（QuorumCertificate）。

--如果验证失败，验证者会广播一条经过签名的超时消息，发送给所有节点。此消息包括验证者观察到的最高QC。如果任何验证者累积的这些超时请求超过验证者数量的2/3，将生成一个TC（TimeoutCertificate）并将其发送给下一个leader。

--每个验证者在收到第k+1轮的QC后，才能最终确定在第k轮提议的区块。

--如果假设leader在第k+1轮中恶意作为，在第k+2轮中，至少有一个验证者将为第k+1轮生成TC，第k+2轮的leader将进行查验并生成该轮TC。

延迟执行

在以太坊中，执行是达成共识的先决条件，因此当节点就一个区块达成共识时，它们是就区块中的交易列表达成一致，也就执行该交易列表后总结所有状态的默克尔根达成一致。因此，leader必须在共享提议之前执行提议区块中的所有交易，验证节点必须在投票响应之前执行这些交易。

从上面可以看出，在交易顺序正式确定后，真实状态是完全确定的。揭示真实状态需要执行，但真实状态已经确定。这是Monad优化的基础。Monad利用了这一洞察，消除了共识达成前的节点执行要求。节点协议只关乎正式交易排序，各节点独立执行区块N中的交易，同时开始在区块N+1上达成共识。

以太坊的做法使用共识以非常严格的方式实施状态机复制：在节点达成共识后，我们知道绝对多数节点就正式排序以及该排序产生的状态达成一致。Monad稍稍放松了这种严格。

--Monad的最终确定性为单个slot（1秒）

--交易的执行结果（成功还是失败？之后的余额是多少？）的最终确定通常会在全节点上延迟不到1秒。

--任何想要在不运行完整节点的情况下安全查询交易结果的人都可以运行一个轻客户端使用默克尔证明查询完整节点余额。在这种情况下，查询将因默克尔根的延迟而延迟。

运载成本

在网络上以区块形式进行网络交易是有费用的。此项费用是与执行成本分开的。储备余额用于支付运载成本。而执行余额则用来支付交易执行。

并行执行

Monad使用乐观执行方式。这意味着Monad将在区块中较早一批交易完成之前开始执行交易。有时（但不总是），这会导致执行错误。

如果所有交易都依赖于前一个交易，乐观执行将通过跟踪执行交易2时使用的输入数据并将其与交易1的输出数据进行比较来解决这个问题。

如果两个数据不一致，而且我们检测到交易2在执行时使用了错误数据，就需要使用正确数据再次执行。当Monad并行执行交易时，每个交易的状态更新被按顺序“合并”。

MonadDb

MonadDb是用于存储区块链状态的自定义数据库。大多数以太坊客户端使用键值数据库，这些数据库被部署为B-Tree（例如LMDB）或LSM-Tree（例如LevelDB和RocksDB）数据结构。

MonadDb在磁盘上和内存中部署PatriciaTrie数据结构。Monad并行执行多个交易。当一个交易需要从磁盘读取状态时，不需要等待操作完成，而应发起读取操作，然后在此期间开始处理另一个交易。