交易可扩展性一直是人们谈论的话题。在过去的几周里,我们一直在探索 Monad 如何帮助扩展 TPS。
以下内容详细介绍了 Monad 如何工作@desh_saurabh。如果您喜欢阅读与 Web3 的所有事物数据驱动相关的简介,可考虑注册Decentralized.co。愿我们在另一处能相见!
TPS 是我们关注的一个指标。我们希望我们的链能够支持更高的 TPS,因为它们可以支持更多的用户和应用程序。下图显示了以太坊和 L2 的 TPS 数字。没有一条链突破过 100 TPS 大关。请注意,TPS 是测量规模的通用术语。 TPS 不准确,因为并非所有交易都是平等的,因为它们的复杂程度不同。但为了简单起见,我们使用 TPS 作为规模衡量标准。
如果我们想提高TPS怎么办?
Monad 是一款新的 EVM 兼容 L1,最近筹集了2.25亿美元,它正在从头开始构建 EVM,而不是按原样使用它。它选择使用第三种方法来提高可扩展性。
接下来,让我们讨论 Monad 带来的一些重大变化。
以太坊虚拟机(EVM)串行执行交易。在一个事务执行之前,下一个事务必须等待。这样想吧。假设摩托车装配仓库中有一个平台。多辆卡车掉落摩托车零件(每辆卡车都拥有制造 50 辆摩托车所需的所有零件)。装配仓库由专门的团队执行四种不同的功能——卸载、分类、装配和装载。
在当前的 EVM 设置中,只有一个平台,并且使用同一位置进行加载和卸载。因此,当卡车停放时,摩托车部件会被卸载、分拣、组装并装载到同一辆卡车上。当分拣小组工作时,其他小组都在等待。因此,如果您将他们的工作视为不同的时段,那么每个团队在四个时段中只工作一次。这导致效率显著低下,凸显了需要效率更精简的方法。
现在,假设有四个平台,具有不同的装卸区域。即使卸货团队一次只能处理一辆卡车,他们也不需要等待接下来的三个槽位。他们可以直接移动到下一辆卡车。
分拣、组装和装载团队也是如此。卸货后,卡车移动到装货区,等待装载队装载组装好的摩托车。因此,只有一个平台和装卸区的仓库是有顺序地执行所有操作的,而拥有4个平台和不同装卸区的仓库则是并行执行的。
将 Monad 视为相当于具有多个卡车平台的仓库的基础设施,但并不那么简单。当卡车相互依赖时,就会更加复杂。例如,如果一辆卡车不具备制造 50 辆摩托车的所有零件,那能怎么办?交易可能并不总是独立的。因此,当 Monad 并行执行它们时,它必须处理相互依赖的事务。
那么,如何处理呢?它执行称为乐观并行执行的操作。该协议只能并行执行独立事务。例如,想象以下4笔交易:在 Joel 的余额为 1 ETH 时
所有这些事务都是并行执行的,并且结果一一提交。如果待处理结果输出与任何交易的原始输入冲突,则重新执行交易。事务 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。
此时,一个明显的问题是我们如何知道我们不必重新执行大部分交易。答案在于,瓶颈制约并不是重新执行,而是访问以太坊的内存。事实证明,以太坊在数据库中存储其状态的方式使得访问状态变得困难(耗时且昂贵)。这就是 Monad 的另一项改进——MonadDb。Monad 以减少与读取操作相关的开销的方式构建其数据库。
当必须重新执行事务时,所有输入都已经在缓存中,与整体状态相比,访问起来要容易得多。
Solana 在其测试网上具有 50k TPS,但现在在主网上的 TPS 约为 1k。Monad 声称在其内部测试网上实现了 10k 的真实 TPS。尽管这并不总能代表现实世界的性能,但我们期待看到 Monad 在外部世界是如何工作的。
交易可扩展性一直是人们谈论的话题。在过去的几周里,我们一直在探索 Monad 如何帮助扩展 TPS。
以下内容详细介绍了 Monad 如何工作@desh_saurabh。如果您喜欢阅读与 Web3 的所有事物数据驱动相关的简介,可考虑注册Decentralized.co。愿我们在另一处能相见!
TPS 是我们关注的一个指标。我们希望我们的链能够支持更高的 TPS,因为它们可以支持更多的用户和应用程序。下图显示了以太坊和 L2 的 TPS 数字。没有一条链突破过 100 TPS 大关。请注意,TPS 是测量规模的通用术语。 TPS 不准确,因为并非所有交易都是平等的,因为它们的复杂程度不同。但为了简单起见,我们使用 TPS 作为规模衡量标准。
如果我们想提高TPS怎么办?
Monad 是一款新的 EVM 兼容 L1,最近筹集了2.25亿美元,它正在从头开始构建 EVM,而不是按原样使用它。它选择使用第三种方法来提高可扩展性。
接下来,让我们讨论 Monad 带来的一些重大变化。
以太坊虚拟机(EVM)串行执行交易。在一个事务执行之前,下一个事务必须等待。这样想吧。假设摩托车装配仓库中有一个平台。多辆卡车掉落摩托车零件(每辆卡车都拥有制造 50 辆摩托车所需的所有零件)。装配仓库由专门的团队执行四种不同的功能——卸载、分类、装配和装载。
在当前的 EVM 设置中,只有一个平台,并且使用同一位置进行加载和卸载。因此,当卡车停放时,摩托车部件会被卸载、分拣、组装并装载到同一辆卡车上。当分拣小组工作时,其他小组都在等待。因此,如果您将他们的工作视为不同的时段,那么每个团队在四个时段中只工作一次。这导致效率显著低下,凸显了需要效率更精简的方法。
现在,假设有四个平台,具有不同的装卸区域。即使卸货团队一次只能处理一辆卡车,他们也不需要等待接下来的三个槽位。他们可以直接移动到下一辆卡车。
分拣、组装和装载团队也是如此。卸货后,卡车移动到装货区,等待装载队装载组装好的摩托车。因此,只有一个平台和装卸区的仓库是有顺序地执行所有操作的,而拥有4个平台和不同装卸区的仓库则是并行执行的。
将 Monad 视为相当于具有多个卡车平台的仓库的基础设施,但并不那么简单。当卡车相互依赖时,就会更加复杂。例如,如果一辆卡车不具备制造 50 辆摩托车的所有零件,那能怎么办?交易可能并不总是独立的。因此,当 Monad 并行执行它们时,它必须处理相互依赖的事务。
那么,如何处理呢?它执行称为乐观并行执行的操作。该协议只能并行执行独立事务。例如,想象以下4笔交易:在 Joel 的余额为 1 ETH 时
所有这些事务都是并行执行的,并且结果一一提交。如果待处理结果输出与任何交易的原始输入冲突,则重新执行交易。事务 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。
此时,一个明显的问题是我们如何知道我们不必重新执行大部分交易。答案在于,瓶颈制约并不是重新执行,而是访问以太坊的内存。事实证明,以太坊在数据库中存储其状态的方式使得访问状态变得困难(耗时且昂贵)。这就是 Monad 的另一项改进——MonadDb。Monad 以减少与读取操作相关的开销的方式构建其数据库。
当必须重新执行事务时,所有输入都已经在缓存中,与整体状态相比,访问起来要容易得多。
Solana 在其测试网上具有 50k TPS,但现在在主网上的 TPS 约为 1k。Monad 声称在其内部测试网上实现了 10k 的真实 TPS。尽管这并不总能代表现实世界的性能,但我们期待看到 Monad 在外部世界是如何工作的。