交易扩展性一直是热门话题。在过去几周中，我们一直在探索 Monad 如何帮助扩展 TPS。

以下是由Saurabh Deshpande撰写的关于 Monad 工作原理的详细说明。

TPS 是我们非常关注的一个指标。我们希望我们的链能够支持更高的 TPS，因为它们可以支持更多的用户和应用程序。下面的图表显示了以太坊和 L2 的 TPS 数字。没有一条链曾经突破过 100 TPS 的标志。请注意，TPS 是一个通用的用于衡量规模的术语。TPS 是不准确的，因为并非所有交易都相同，它们在复杂性上有所不同。但出于简单起见，我们使用 TPS 作为衡量规模的指标。

如果我们想增加 TPS，我们该怎么办？

• 第一种方法是构建一个全新的系统，就像 Solana 所做的那样。它牺牲了与速度相比的 EVM 兼容性。它使用多线程执行而不是单线程执行（想想多核 CPU 与单核 CPU），进行并行化交易并使用了不同的共识机制。
• 第二种方法是使用链下执行，并使用中心化的排序器来扩展以太坊。
• 第三种方法是将 EVM 分解为单独的组件，并对其进行优化以提高可扩展性。

Monad 是一个新的与 EVM 兼容的 L1，最近筹集了 2.25 亿美元，它正在从头开始构建 EVM，而不是直接使用。它选择了这第三种方法来增加可扩展性。

我们讨论了 Monad 带来的几个重大变化。

并行执行

以太坊虚拟机（EVM）按顺序执行交易。在执行一个交易之前，下一个交易必须等待。可以这样想。假设在一个摩托车装配车间中有一个平台。多辆卡车运送摩托车零件（每辆卡车都有组装 50 辆摩托车所需的所有零件）。装配车间分别执行四种不同的功能：卸货、分类、组装和装货。

在当前的 EVM 设置中，只有一个平台，并且加载和卸载使用相同的位置。因此，当卡车停放时，摩托车部件被卸载、分类、组装和装载在同一辆卡车上。当分类团队在工作时，其他团队都在等待。因此，如果将它们的工作看作不同的插槽，每个团队仅在四个插槽中工作一次。这导致了显著的低效率，突出了需要更加流畅的方法。

现在，想象有四个不同的装载和卸载区域的平台。即使卸货团队一次只能与一辆卡车一起工作，他们也不需要等待下三个插槽。他们可以直接转移到下一辆卡车上。

分类、组装和装载团队也是如此。一旦卸货完成，卡车移动到装载区等待装载团队装载组装好的摩托车。因此，只有一个平台和加载/卸载区域的仓库按顺序执行所有操作，而具有 4 个平台和不同加载/卸载区域的仓库进行并行化。

将 Monad 视为基础设施，相当于拥有多个卡车平台的仓库。但并不简单。当卡车依赖时，复杂性增加。例如，如果一辆卡车没有所有零件来组装 50 辆摩托车会怎样？交易可能并不总是独立的。因此，当 Monad 并行执行它们时，它必须处理彼此依赖的交易。

怎么处理？它执行一种叫做乐观并行执行的方法。协议只能并行执行独立的交易。例如，考虑 4 笔交易，其中 Joel 的余额为 1 个ETH：

1. Joel 将 0.2 个以太发送给 Saurabh
2. Sid 铸造一个 NFT
3. Joel 将 0.1 个以太发送给 Sid
4. Shlok 购买 PEPE

所有这些交易都是并行执行的，待定结果逐一提交。如果待定结果的输出与任何交易的原始输入存在冲突，则重新执行交易。交易 2 和 4 没有与其他交易的输入冲突的待定结果，因为它们彼此独立。但交易 1 和 4 并不独立。

请注意，由于所有 4 个交易都从同一状态开始，所以关注的是 Joel 的余额为 1 个ETH。Joel 将 0.2 个ETH发送出去后，余额为 0.8 个ETH。在 Joel 将 0.1 个ETH发送给 Sid 后，他的余额为 0.9 个ETH。结果逐一提交，确保输出不与任何输入冲突。在提交了 1 的待定结果后，Joel 的新余额为 0.8 个ETH。

这个输出与第 3 个交易的输入冲突。所以现在 3 被重新执行，输入为 0.8 个ETH。在执行了 3 之后，Joel 的余额为 0.7 个ETH。

MonadDb

在这一点上，一个明显的问题是我们如何知道我们不必重新执行大部分交易。答案在于重新执行并不是瓶颈。瓶颈是访问以太坊的内存。事实证明，以太坊在数据库中存储状态的方式使得访问状态变得困难（耗时和因此昂贵）。这就是 Monad 的另一项改进：MonadDb。Monad 构建数据库的方式减少了与读取操作相关的开销。

当交易必须重新执行时，所有输入已经在缓存存储器中，与整体状态相比，这更加容易访问。

Solana 在其测试网上有 50k TPS，但现在在主网上只有大约1k TPS。Monad 声称在其内部测试网上已实现了 10k 实际 TPS。尽管这并不总是代表实际性能，但我们迫不及待地想看看 Monad 在实际应用中的表现。