作者:Decentralised.Co 来源:X,@Decentralisedco 翻译:善欧巴,金色财经
交易可扩展性一直是业内讨论的热点话题。过去几周,我们一直在探讨 Monad 如何帮助提升交易处理速度 (TPS)。本文详细解释了 Monad 的运作原理。
TPS 是我们一直关注的衡量标准。我们希望区块链能够支持更高的 TPS,从而容纳更多用户和应用程序。下图显示了以太坊和 L2 的 TPS 数字。目前为止,没有一条链突破过 100 TPS 的大关。需要注意的是,TPS 是一个用于衡量可扩展性的通用术语。由于并非所有交易都一样复杂,因此单纯的 TPS 数据并不够准确。但为了方便起见,我们仍将 TPS 视为衡量可扩展性的指标。
提高 TPS 的方法有哪些?
一种方法是像 Solana 一样,从头开始构建一个全新的系统。Solana 牺牲了与 EVM 的兼容性来换取速度。它使用多线程执行而不是单线程执行(可以类比多核 CPU 和单核 CPU),并行处理交易,并使用不同的共识机制。
第二种方法是使用链下执行并使用中心化排序器来扩展以太坊。
第三种方法是将 EVM 分解成单独的组件并进行优化以提高可扩展性。
Monad 是一个新近筹集了 2.25 亿美元的 EVM 兼容 L1 区块链,它选择从头开始构建 EVM 而不是直接使用现有版本。Monad 采用了第三种方法来提高可扩展性。
下面我们将讨论 Monad 引入的一些重大改变。
并行执行
以太坊虚拟机 (EVM) 串行执行交易。在上一个交易执行完成之前,下一个交易必须等待。可以举个例子:想象一个摩托车组装仓库的平台。多辆卡车运来摩托车零件(每辆卡车都装有制造 50 辆摩托车所需的所有零件)。装配仓库有四个不同的功能,每个功能都由专门的团队负责 - 卸载、分类、组装和装载。
在当前的 EVM 设置中,只有一个平台,同一个地点用于装卸货物。因此,当卡车停下来时,摩托车零件会在同一个卡车上卸载、分类、组装和装载。当分类团队工作时,其他团队都在等待。因此,如果把他们的工作视为不同的插槽,那么每个团队每四个插槽中只会工作一次。这导致了严重的效率低下,凸显了需要一种更加简化的方式。
现在想象有四个拥有独立装卸区域的平台。即使卸载团队一次只能处理一辆卡车,他们也不必等待接下来的三个插槽才能进行工作。他们可以直接移到下一辆卡车旁开始工作。
分类、组装和装载团队也是如此。当卡车完成卸载后,它会驶向装载区,等待装载团队装载组装好的摩托车。因此,只有一个平台和装卸区域的仓库会按顺序执行所有操作,而拥有 4 个平台和不同装卸区域的仓库则可以并行处理任务。
可以将 Monad 视为拥有多个卡车平台的仓库基础设施,但它比这个例子复杂得多。当卡车之间存在依赖关系时,复杂性就会增加。例如,如果一辆卡车上没有制造 50 辆摩托车所需的所有零件怎么办?交易并不总是独立的。因此,当 Monad 并行执行它们时,它必须处理相互依赖的交易。
如何做到这一点?它执行一种称为乐观并行执行的操作。该协议只能并行执行独立的交易。例如,考虑 4 笔交易,其中乔尔 (Joel) 的余额为 1 ETH:
所有这些交易都并行执行,具有挂起的待确认结果,这些结果将逐个提交。如果待处理的结果输出与任何交易的原始输入冲突,则会重新执行交易。交易 2 和 4 彼此独立,因此它们的待处理结果不会与其他交易的输入冲突。但 1 和 4 不是独立的。
请注意,由于所有 4 笔交易都从相同的初始状态(乔尔余额为 1 ETH)开始,因此这里关注的是乔尔的余额。发送 0.2 ETH 后乔尔的余额变为 0.8 ETH。在向西德发送 0.1 ETH 后,他的余额变为 0.9 ETH。结果逐个提交,确保输出不会与任何输入冲突。在 1 的待处理结果提交后,乔尔的新余额变为 0.8 ETH。
这个输出与 3 的输入冲突。因此,现在用 0.8 ETH 的输入重新执行 3。执行完 3 之后,乔尔的余额变为 0.7 ETH。
MonadDb
至此,一个明显的问题是,我们如何知道不必重新执行大部分交易?答案在于重新执行并不是瓶颈。瓶颈在于访问以太坊的内存。事实证明,以太坊在数据库中存储其状态的方式使得访问状态变得困难(耗时且昂贵)。这就是 Monad 另一项改进发挥作用的地方 - MonadDb。Monad 以一种减少读取操作相关开销的方式构建了其数据库。
当一个交易需要重新执行时,所有输入都已经缓存在缓存内存中,与访问整体状态相比,缓存内存的访问速度要快得多。
Solana 在测试网上拥有 5 万 TPS,但在主网上只有约 1 千 TPS。Monad 声称在其内部测试网上实现了 1 万个实际 TPS。尽管这并不总是代表实际性能,但我们迫不及待地想看看 Monad 在实际应用中的表现。