交易扩展性一直是热门话题。在过去几周中，我们一直在探索 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：
Joel 将 0.2 个以太发送给 Saurabh
Sid 铸造一个 NFT
Joel 将 0.1 个以太发送给 Sid
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。
在这一点上，一个明显的问题是我们如何知道我们不必重新执行大部分交易。答案在于重新执行并不是瓶颈。瓶颈是访问以太坊的内存。事实证明，以太坊在数据库中存储状态的方式使得访问状态变得困难（耗时和因此昂贵）。这就是 Monad 的另一项改进：MonadDb。Monad 构建数据库的方式减少了与读取操作相关的开销。
当交易必须重新执行时，所有输入已经在缓存存储器中，与整体状态相比，这更加容易访问。
Solana 在其测试网上有 50k TPS，但现在在主网上只有大约1k TPS。Monad 声称在其内部测试网上已实现了 10k 实际 TPS。尽管这并不总是代表实际性能，但我们迫不及待地想看看 Monad 在实际应用中的表现。
以上是Monad入门指南：快速理解并行EVM与性能提升的详细内容。更多信息请关注PHP中文网其他相关文章！
