验证节点负责对区块进行验证，并将其验证结果（肯定或否定）发送给领导节点。领导节点通过汇总这些肯定或否定的投票（使用阈值签名）来形成QC（Quorum Certificate，法定人数证书）。

若验证未通过，验证节点会广播一条签名的超时信息，并发送给所有对等节点。该信息包含验证节点所观察到的最高QC。如果超时请求的累计数量超过了验证节点总数的三分之二，则将形成一个TC（Timeout Certificate，超时证书），并发送给下一任领导节点。

每个验证节点在接收到第k+1轮的QC后，会对第k轮提议的区块进行最终确认。

假设第k+1轮的领导节点行为恶劣，在第k+2轮，至少有一个验证节点会生成第k+1轮的TC，随后第k+2轮的领导节点将检查该TC，并为那一轮生成一个TC而非QC。

在以太坊中，执行共识是先决条件，因此当节点就某个区块达成共识时，它们同时达成一致意见关于（1）区块中的交易列表和（2）执行这些交易后的所有状态的默克尔根。

因此，领导节点必须在分发提案前执行提案区块中的所有交易，而验证节点必须在进行投票响应前执行这些交易。

根据上述描述，一旦给定官方的交易顺序，真实状态就被完全确定了。执行揭示了真实状态，尽管这一真实已被固定。这是Monad优化的基础。

Monad利用了这种洞察，通过取消在达成共识前执行交易的要求。节点协议纯粹关于官方顺序；每个节点在独立执行区块N中的交易的同时，开始处理对区块N+1的共识。

以太坊的做法使用共识来严格执行状态机复制：节点达成共识后，大多数人同意官方顺序及其产生的状态。Monad则在这种严格性上做了适当的放宽。

在Monad中，终结性是单时隙（1秒）。

交易执行的结果（是否成功？之后的余额是多少？）在完整节点上通常会在终结性后不到1秒的时间内被确定。

任何希望安全查询交易结果而无需运行完整节点的个体，都可以运行轻客户端，并查询完整节点上的余额和默克尔证明。在这种情况下，查询将滞后于默克尔根更新。

交易成本：区块链中传输交易会产生费用，这是执行成本之外的单独收费项。保留余额用于支付这些传输成本；执行余额用于支付交易执行费用。

Monad采用乐观执行策略。这意味着Monad将在区块中较早的交易完成之前开始执行交易。这有时（但不总是）可能导致执行错误。

如果某交易依赖于前一交易的结果，乐观执行通过对比执行交易2时使用的输入与交易1的输出来解决依赖问题。

若两者不匹配，我们检测到交易2在执行过程中使用了错误的数据，需要用正确的数据重新执行。尽管Monad并行执行交易，每笔交易的更新状态会按顺序合并。

MonadDb是一个为存储区块链状态设计的定制数据库。大多数以太坊客户端使用的是基于B-Tree（如LMDB）或LSM-Tree（如LevelDB和RocksDB）的键值数据库结构。与之不同，MonadDb原生实现了Patricia Trie数据结构，这种结构既适用于磁盘也适用于内存存储。

Monad实现了多交易的并行执行。当某笔交易需要从磁盘读取状态数据时，不应该阻塞等待读取完成，而应该并行地启动读取操作并处理其他交易。

通过这种方式，Monad优化了交易处理流程，减少了单个交易执行中的延迟，并提高了整体系统的效率和响应速度。