交易扩展性一直是热门话题。在过去几周中，我们一直在探索Monad如何帮助扩展TPS。
以下是由SaurabhDeshpande撰写的关于Monad工作原理的详细说明。
TPS是我们非常关注的一个指标。我们希望我们的链能够支持更高的TPS，因为它们可以支持更多的用户和应用程序。下面的图表显示了以太坊和L2的TPS数字。没有一条链曾经突破过100TPS的标志。请注意，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在其测试网上有50kTPS，但现在在主网上只有大约1kTPS。Monad声称在其内部测试网上已实现了10k实际TPS。尽管这并不总是代表实际性能，但我们迫不及待地想看看Monad在实际应用中的表现。
以上就是Monad入门指南：快速理解并行EVM与性能提升的全部内容，望能这篇Monad入门指南：快速理解并行EVM与性能提升可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。