一文读懂 Monad

中级5/21/2024, 2:20:13 AM
交易扩展性一直是热门话题,本文探讨了 Monad 如何帮助扩展 TPS,并详细介绍了其工作原理。瓶颈并不是重新执行,而是访问以太坊的内存。事实证明,以太坊在数据库中存储状态的方式使得访问状态变得困难(耗时和因此昂贵),这是 Monad 的另一项改进

交易可扩展性一直是人们谈论的话题。在过去的几周里,我们一直在探索 Monad 如何帮助扩展 TPS。

以下内容详细介绍了 Monad 如何工作@desh_saurabh。如果您喜欢阅读与 Web3 的所有事物数据驱动相关的简介,可考虑注册Decentralized.co。愿我们在另一处能相见!

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

如果我们想提高TPS怎么办?

  1. 一种方法是构建一个全新的系统,就像 Solana 所做的那样。它牺牲了 EVM 兼容性以换取速度。它使用多线程而不是单线程执行(想想多核 CPU 与单核 CPU),并行化事务,并使用不同的共识机制。
  2. 第二种方法是使用链下执行并通过中心化排序器扩展以太坊。
  3. 第三是将EVM分解为单独的组件并对其进行优化以提高可扩展性。

Monad 是一款新的 EVM 兼容 L1,最近筹集了2.25亿美元,它正在从头开始构建 EVM,而不是按原样使用它。它选择使用第三种方法来提高可扩展性。

接下来,让我们讨论 Monad 带来的一些重大变化。

并行执行

以太坊虚拟机(EVM)串行执行交易。在一个事务执行之前,下一个事务必须等待。这样想吧。假设摩托车装配仓库中有一个平台。多辆卡车掉落摩托车零件(每辆卡车都拥有制造 50 辆摩托车所需的所有零件)。装配仓库由专门的团队执行四种不同的功能——卸载、分类、装配和装载。

在当前的 EVM 设置中,只有一个平台,并且使用同一位置进行加载和卸载。因此,当卡车停放时,摩托车部件会被卸载、分拣、组装并装载到同一辆卡车上。当分拣小组工作时,其他小组都在等待。因此,如果您将他们的工作视为不同的时段,那么每个团队在四个时段中只工作一次。这导致效率显著低下,凸显了需要效率更精简的方法。

现在,假设有四个平台,具有不同的装卸区域。即使卸货团队一次只能处理一辆卡车,他们也不需要等待接下来的三个槽位。他们可以直接移动到下一辆卡车。

分拣、组装和装载团队也是如此。卸货后,卡车移动到装货区,等待装载队装载组装好的摩托车。因此,只有一个平台和装卸区的仓库是有顺序地执行所有操作的,而拥有4个平台和不同装卸区的仓库则是并行执行的。

将 Monad 视为相当于具有多个卡车平台的仓库的基础设施,但并不那么简单。当卡车相互依赖时,就会更加复杂。例如,如果一辆卡车不具备制造 50 辆摩托车的所有零件,那能怎么办?交易可能并不总是独立的。因此,当 Monad 并行执行它们时,它必须处理相互依赖的事务。

那么,如何处理呢?它执行称为乐观并行执行的操作。该协议只能并行执行独立事务。例如,想象以下4笔交易:在 Joel 的余额为 1 ETH 时

  1. Joel 向 Saurabh 发送 0.2 ETH。
  2. Sid 铸造了 NFT。
  3. Joel 向 Sid 发送 0.1 ETH。
  4. Shlok 购买 PEPE。

所有这些事务都是并行执行的,并且结果一一提交。如果待处理结果输出与任何交易的原始输入冲突,则重新执行交易。事务 2 和 4 的待处理结果不会与其他事务的输入冲突,因为它们彼此独立。但1和3并不是独立的。

请注意,由于所有 4 笔交易均从同一状态开始,因此这里关注的是 Joel 的 1 ETH 余额。Joel 发送 0.2 ETH 的输出结果是 0.8 ETH。Joel 向 Sid 发送 0.1 ETH 后,他的余额为 0.9 ETH。结果一一提交,确保输出不会与任何输入冲突。提交待处理结果 1 后,Joel 的新余额为 0.8 ETH。

这个输出与 3 的输入冲突。所以现在以 0.8 ETH 的输入重新执行 3。执行3后,Joel的余额为0.7 ETH。

MonadDb

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

当必须重新执行事务时,所有输入都已经在缓存中,与整体状态相比,访问起来要容易得多。

Solana 在其测试网上具有 50k TPS,但现在在主网上的 TPS 约为 1k。Monad 声称在其内部测试网上实现了 10k 的真实 TPS。尽管这并不总能代表现实世界的性能,但我们期待看到 Monad 在外部世界是如何工作的。

声明:

  1. 本文转载自【chaincatcher】。原文标题为“Understanding Monad”。所有版权归原作者【Decentralised.Co】所有。若对本次转载有异议,请联系【Gate Learn】团队,他们会及时处理。
  2. 免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。
  3. Gate Learn 团队将文章翻译成其他语言。除非另有说明,否则禁止复制、分发或抄袭本译文。

并行执行

MonadDb

一文读懂 Monad

中级5/21/2024, 2:20:13 AM
交易扩展性一直是热门话题,本文探讨了 Monad 如何帮助扩展 TPS,并详细介绍了其工作原理。瓶颈并不是重新执行,而是访问以太坊的内存。事实证明,以太坊在数据库中存储状态的方式使得访问状态变得困难(耗时和因此昂贵),这是 Monad 的另一项改进

并行执行

MonadDb

交易可扩展性一直是人们谈论的话题。在过去的几周里,我们一直在探索 Monad 如何帮助扩展 TPS。

以下内容详细介绍了 Monad 如何工作@desh_saurabh。如果您喜欢阅读与 Web3 的所有事物数据驱动相关的简介,可考虑注册Decentralized.co。愿我们在另一处能相见!

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

如果我们想提高TPS怎么办?

  1. 一种方法是构建一个全新的系统,就像 Solana 所做的那样。它牺牲了 EVM 兼容性以换取速度。它使用多线程而不是单线程执行(想想多核 CPU 与单核 CPU),并行化事务,并使用不同的共识机制。
  2. 第二种方法是使用链下执行并通过中心化排序器扩展以太坊。
  3. 第三是将EVM分解为单独的组件并对其进行优化以提高可扩展性。

Monad 是一款新的 EVM 兼容 L1,最近筹集了2.25亿美元,它正在从头开始构建 EVM,而不是按原样使用它。它选择使用第三种方法来提高可扩展性。

接下来,让我们讨论 Monad 带来的一些重大变化。

并行执行

以太坊虚拟机(EVM)串行执行交易。在一个事务执行之前,下一个事务必须等待。这样想吧。假设摩托车装配仓库中有一个平台。多辆卡车掉落摩托车零件(每辆卡车都拥有制造 50 辆摩托车所需的所有零件)。装配仓库由专门的团队执行四种不同的功能——卸载、分类、装配和装载。

在当前的 EVM 设置中,只有一个平台,并且使用同一位置进行加载和卸载。因此,当卡车停放时,摩托车部件会被卸载、分拣、组装并装载到同一辆卡车上。当分拣小组工作时,其他小组都在等待。因此,如果您将他们的工作视为不同的时段,那么每个团队在四个时段中只工作一次。这导致效率显著低下,凸显了需要效率更精简的方法。

现在,假设有四个平台,具有不同的装卸区域。即使卸货团队一次只能处理一辆卡车,他们也不需要等待接下来的三个槽位。他们可以直接移动到下一辆卡车。

分拣、组装和装载团队也是如此。卸货后,卡车移动到装货区,等待装载队装载组装好的摩托车。因此,只有一个平台和装卸区的仓库是有顺序地执行所有操作的,而拥有4个平台和不同装卸区的仓库则是并行执行的。

将 Monad 视为相当于具有多个卡车平台的仓库的基础设施,但并不那么简单。当卡车相互依赖时,就会更加复杂。例如,如果一辆卡车不具备制造 50 辆摩托车的所有零件,那能怎么办?交易可能并不总是独立的。因此,当 Monad 并行执行它们时,它必须处理相互依赖的事务。

那么,如何处理呢?它执行称为乐观并行执行的操作。该协议只能并行执行独立事务。例如,想象以下4笔交易:在 Joel 的余额为 1 ETH 时

  1. Joel 向 Saurabh 发送 0.2 ETH。
  2. Sid 铸造了 NFT。
  3. Joel 向 Sid 发送 0.1 ETH。
  4. Shlok 购买 PEPE。

所有这些事务都是并行执行的,并且结果一一提交。如果待处理结果输出与任何交易的原始输入冲突,则重新执行交易。事务 2 和 4 的待处理结果不会与其他事务的输入冲突,因为它们彼此独立。但1和3并不是独立的。

请注意,由于所有 4 笔交易均从同一状态开始,因此这里关注的是 Joel 的 1 ETH 余额。Joel 发送 0.2 ETH 的输出结果是 0.8 ETH。Joel 向 Sid 发送 0.1 ETH 后,他的余额为 0.9 ETH。结果一一提交,确保输出不会与任何输入冲突。提交待处理结果 1 后,Joel 的新余额为 0.8 ETH。

这个输出与 3 的输入冲突。所以现在以 0.8 ETH 的输入重新执行 3。执行3后,Joel的余额为0.7 ETH。

MonadDb

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

当必须重新执行事务时,所有输入都已经在缓存中,与整体状态相比,访问起来要容易得多。

Solana 在其测试网上具有 50k TPS,但现在在主网上的 TPS 约为 1k。Monad 声称在其内部测试网上实现了 10k 的真实 TPS。尽管这并不总能代表现实世界的性能,但我们期待看到 Monad 在外部世界是如何工作的。

声明:

  1. 本文转载自【chaincatcher】。原文标题为“Understanding Monad”。所有版权归原作者【Decentralised.Co】所有。若对本次转载有异议,请联系【Gate Learn】团队,他们会及时处理。
  2. 免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。
  3. Gate Learn 团队将文章翻译成其他语言。除非另有说明,否则禁止复制、分发或抄袭本译文。
即刻开始交易
注册并交易即可获得
$100
和价值
$5500
理财体验金奖励!