并行区块链设计空间探索(第一部分)

中级3/29/2024, 7:04:00 PM
这篇研究报告概述了区块链并行设计架构,通过三个相关案例研究:Solana、Sei 以及 Monad 来进行说明。报告着重于Optimistic并行化与决定性并行化的对比,并深入分析了这些区块链在状态和内存访问方面的细节差异。

摘要:本研究报告提供了对区块链并行设计架构的全面概述,选取了Solana、Sei 和 Monad 三个案例进行分析。文中详细比较了Optimistic并行化与决定性并行化的不同之处,并对这些区块链系统中的状态和内存访问模式进行了细致考察。

介绍

1837年,计算机科学家和数学家查尔斯·巴贝奇设计了“分析机(Analytical Engine)”,为并行计算奠定了理论基础。在当今的加密技术领域,并行化成为了一个核心议题,这是因为区块链技术正努力突破处理速度、效率及吞吐量的限制。

并行宇宙

并行计算使得许多计算或进程能够同时执行,与串行执行或一个接一个地执行计算相反。并行计算指的是将较大的问题分解成较小的、独立的部分,这些部分可以由多个处理器通过共享内存进行通信来执行。并行系统有许多优势,例如提高效率和速度、可扩展性、提高可靠性和容错能力、更好的资源利用以及能够处理非常大的数据集。

然而,至关重要的是要认识到,并行化的有效性取决于底层架构和实现的具体情况。阻碍区块链的两个核心瓶颈是密码学函数(哈希函数、签名、椭圆曲线等)和内存/状态访问。在区块链中,设计高效并行系统的关键组成部分之一在于访问状态的细微差别。状态访问指的是交易读取和写入区块链状态的能力,包括存储、智能合约和账户余额。要使并行化区块链有效和高性能,必须优化状态访问。

目前关于优化并行化区块链的状态访问有两种思路:确定性并行化与Optimistic并行化。确定性并行化要求代码明确声明哪些区块链状态的部分将被访问和修改。这允许系统事先确定哪些交易可以并行处理而不会发生冲突。确定性并行化允许可预测性和效率(特别是当交易大多是独立的时候)。然而,它确实为开发者创建了更多的复杂性。

Optimistic并行化不要求代码事先声明其状态访问,而是假设不会有冲突地并行处理交易。如果发生冲突,Optimistic并行化将重新运行、重新处理或串行运行冲突的交易。虽然Optimistic并行化为开发者提供了更多的灵活性,但冲突需要重新执行,这使得这种方法在交易不冲突时最为高效。关于这些方法哪一个更好,并没有确切的答案。它们只是并行化的两种不同(且可行的)方法。

在本系列的第一部分,我们首先探索一些非加密并行系统的基础知识,随后将关注区块链的并行执行设计空间,重点是三个核心领域:

  1. 加密并行系统概述

  2. 内存与状态访问方法

  3. 并行设计的机会

非加密并行系统

根据我们上面刚刚读到的有关并行计算的功能和并行系统的优点的内容,很容易理解为什么近年来并行计算的采用已经开始兴起。仅在过去几十年里,并行计算的广泛采用就实现了许多突破。

  1. 医学影像:并行处理从根本上改变了医学成像,使得MRI、CT、X光和光学层析等各种模式的速度和分辨率显著提高。Nvidia站在这些进步的前沿,通过其并行处理工具包为放射科医生提供增强的人工智能能力,使成像系统能更有效地处理增加的数据和计算负载。
  2. 天文学: 一些新现象,例如理解黑洞,只有通过使用并行超级计算机才成为可能。
  3. Unity的游戏引擎:Unity的引擎利用GPU的能力——这些GPU为处理大量图形工作负载而构建——以帮助提高性能和速度。该引擎配备了多线程和并行处理功能,提供无缝的游戏体验,并创建复杂、详细的游戏环境。

接下来,让我们检视三个实施了并行执行环境的区块链。首先,我们将解析Solana,其次是两个基于EVM的链,Monad和Sei

并行设计概述 – Solana

Solana的设计哲学核心在于,随着硬件技术的进步,区块链创新也应相应发展。这一理念基于摩尔定律,即硬件的性能和可扩展性将随时间不断提高,Solana致力于充分利用这一趋势。Solana的联合创始人Anatoly Yakovenko于五年前最初设计了其并行架构,现在,这种基于并行性的区块链设计原则正在快速普及。

Solana采纳了基于Anatoly在嵌入式系统领域工作经验的决定性并行化策略,在那里,通常需要 upfront(提前)声明所有状态。这一做法让CPU能够预知所有依赖关系,并提前获取所需的内存部分,优化了系统执行性能。但值得注意的是,这种方法要求开发者 upfront(提前)进行额外工作。在Solana上,程序的所有内存依赖都必须 upfront(提前)声明,在构造交易时需要指明访问列表,这样运行时系统就能高效地并行调度和执行多个交易。

Solana架构的另一个关键组成部分是Sealevel VM,这是Solana的并行智能合约执行环境。Sealevel VM天生就支持根据验证者所拥有的核心数量并行处理多个合约和交易。在区块链中,验证者负责验证交易、提议新的区块以及维护区块链的完整性和安全。通过 upfront(提前)声明哪些账户需要读取和写入锁定,Solana的调度器能够确定哪些交易可以并行执行。因此,对于验证者来说,作为“区块生产者”或领导者,可以对数以千计的待处理交易进行排序,并并行调度非重叠的交易。

Solana的另一个设计特点是其“流水线”处理方式。流水线处理发生在数据需要经过一系列处理步骤时,由不同的硬件负责每个步骤。其核心思想是把需要串行处理的数据通过流水线技术实现并行化。这些流水线能够并行运行,每个流水线阶段能够并行处理不同批次的交易。

这些优化使得Sealevel可以组织并同时执行独立的交易,借助硬件的能力,通过单个程序同时处理多个数据点。Sealevel通过程序ID对指令进行排序,并在所有相关账户上并行执行相同指令。

综上所述,Solana的设计创新明确旨在支持并行化处理,充分展示了其设计理念的先进性和对硬件发展趋势的深刻理解。

并行设计概述 – Sei

Sei 是一个针对数字资产交换专门化的通用、开源的一级区块链。Sei V2 利用Optimistic并行化,因此,与其确定性对手相比,对开发者更为友好。在Optimistic并行化中,智能合约可以更顺畅、更并发地执行,而无需开发者 upfront 声明他们的资源。这意味着链Optimistic地并行运行所有交易。但是,当存在冲突时(即,多个交易访问同一状态),区块链将跟踪每个冲突交易影响的特定存储组件。

Sei 的区块链使用“Optimistic并发控制(OCC)”来执行交易。当系统中同时存在多个交易时,就会发生并发交易处理。这种交易方法有两个阶段:执行和验证。

在执行阶段,交易被Optimistic地处理,所有读/写操作临时存储在交易特定的存储中。之后,每个交易都会进入验证阶段,此时,临时存储操作中的信息会与之前交易所做的任何状态改变进行检查。如果一个交易是独立的,那么该交易并行运行。如果一个交易读取了由另一交易修改的数据,这将产生冲突。Sei 的并行系统会通过比较交易的读取集合与多版本存储中的最新状态改变(这些由交易顺序索引)来识别每个冲突。Sei 将重新执行和重新验证出现冲突的实例。这是一个包括执行、验证和重新运行的迭代过程,以解决冲突。下面的图表说明了 Sei 在出现冲突时处理交易的方法。


来源:https://blog.sei.io/sei-v2-the-first-parallelized-evm/

Sei 的实现导致更低的Gas费用和更广泛的设计空间,为EVM开发者提供。历史上,EVM环境限制在小于50 TPS,这迫使开发者创建遵循反模式的应用程序。Sei V2 使开发者能够涉足通常需要高性能和低费用的领域,如DeFi、DePIN和游戏。

并行设计概述 – Monad

Monad 正在构建一个具有完全字节码兼容性的并行 EVM 第 1 层。Monad 独特之处不仅在于其并行引擎,还在于他们为优化该引擎所做的底层建设。Monad 采取了独特的整体设计方法,包括管道化、异步 I/O、分离共识和执行,以及 MonadDB。

Monad 设计中的一个关键创新是带有微小偏移的管道化。这种偏移使得通过同时运行多个实例,可以并行化更多的过程。因此,管道化用于优化许多功能,如状态访问管道化、交易执行管道化、共识与执行中的管道化,以及共识机制本身内的管道化。

接下来,我们将深入探讨 Monad 的并行化部分。在 Monad 中,交易在区块内线性排序,但目标是通过利用并行执行来更快地达到这一最终状态。Monad 使用一种Optimistic 的并行算法来设计其执行引擎。Monad 的引擎同时处理交易,然后进行分析,以确保如果交易依次执行,结果会相同。如果存在任何冲突,就需要重新执行。这里的并行执行是一个相对简单的算法,但与 Monad 的其他关键创新结合起来,使得这种方法显得新颖。需要注意的一点是,即使重新执行,通常也是低成本的,因为无效交易所需的输入几乎总是保留在缓存中,因此它将是一个简单的缓存查找。重新执行是有保证的成功,因为你已经执行了区块中的前一个交易。

Monad 还通过分离执行和共识来提高性能,类似于 Solana 和 Sei,此外还有延迟执行。这里的想法是,如果你放宽执行完成的条件到共识完成的时间,你可以并行运行两者,从而为两者提供额外的时间。当然,Monad 使用一个确定性算法来处理这个条件,以确保这些中的一个不会跑得太远而没有赶上的可能性。

独特的状态访问与内存方法

如我在本文开头所提到的,状态访问是区块链的典型性能瓶颈之一。状态访问和内存的设计选择最终决定了并行系统的特定实现是否能在实践中提升性能。这里,我们将解析并比较Solana、Sei和Monad采取的不同方法。

Solana状态访问:AccountsDB / Cloudbreak

Solana采用横向扩展来分布和管理状态数据,跨多个SSD设备。今天许多区块链使用通用数据库(例如,LevelDB)来处理大量并发读写状态数据时的限制。为了避免这一点,Solana构建了自己的定制AccountsDB,利用Cloudbreak。

Cloudbreak是为跨I/O操作的并行访问而设计的,而不是仅仅依赖于RAM,后者本质上是快速的。I/O操作(输入/输出)指的是从外部源(如磁盘、网络或外围设备)读取数据或写入数据。最初,Cloudbreak采用了一个在RAM中的索引,用于映射公钥到持有余额和数据的账户。然而,截至撰写本文和版本1.9,索引已经从RAM移出,存放到SSDs上。这一转变允许Cloudbreak同时处理队列中的32个I/O操作,提高了跨多个SSDs的吞吐量。因此,如同使用内存映射文件一样,区块链数据(如账户和交易)可以高效地被访问,尽管RAM更快,但它的容量较少且通常更昂贵:


说明性的内存层次结构图

通过水平扩展并在多个设备上分布状态数据,Cloudbreak降低了延迟并提高了效率、去中心化和网络弹性,这些都是Solana生态系统内的重要改进。

状态访问:SeiDB

Sei重新设计了其存储系统SeiDB,以解决几个问题:写放大(维护数据结构所需的元数据量,更小=更好)、状态膨胀、操作缓慢以及随时间性能降低。新的设计现在分为两个部分:状态存储和状态提交。任何对数据变更的记录和验证都由状态提交处理,而记录任何时点所有数据的数据库由状态存储(SS)处理。

在Sei V2中,状态提交使用内存映射IAVL树架构(MemIAVL)。内存映射IAVL树存储的元数据较少,这减少了状态存储和状态同步时间,并且使运行全节点变得更加容易。内存映射IAVL树表示为磁盘上的三个文件(kv, branch, leaves);因此,需要追踪的元数据较少,这有助于将状态存储减少50%以上。新的MemIAVL结构有助于减少写放大因子,因为它减少了维护数据结构所需的元数据。

更新后的SeiDB允许状态存储层支持灵活的数据库后端。Sei认为,不同的节点操作者将有不同的需求和存储需求。因此,SS被设计为能够适应不同的后端,为操作者提供自由和灵活性,即PebbleDB、RocksDB、SQLite等。

状态访问:MonadDB

Monad的状态访问有一些重要的细微差别。首先,大多数以太坊客户端利用两种类型的数据库:B-Tree数据库(例如LMDB)或日志结构合并树(LSM)数据库(例如RocksDB, LevelDB)。这两种都是通用数据结构,并非专为区块链设计。此外,这些数据库没有利用Linux技术最新的进步,特别是关于异步操作和I/O优化。最后,以太坊本身使用Patricia Merkle Trie管理状态,专注于加密、验证和证明。主要问题是,客户端必须将这种特定的Patricia Merkle Trie整合到更通用的数据库(即B-Tree / LSM)中,导致显著的性能缺点,如过度的磁盘访问。

上述所有这些都为Monad决定创建专门设计的MonadDB数据库铺平了道路,这个数据库旨在更高效地处理区块链数据和状态访问。MonadDB的一些关键特性包括并行访问数据库、针对Merkle Trie数据优化的自定义数据库、高效的状态访问与标准RAM使用之上、去中心化与可扩展性。

MonadDB专门为区块链设计,比利用通用数据库更为高效。定制的MonadDB专为高效管理Merkle trie型数据而量身定做,使得可以同时并行访问多个trie节点。尽管MonadDB与上述某些通用数据库的单次读取成本相同,但关键在于MonadDB可以并行进行多次读取,从而大幅提速。

MonadDB通过并行访问数据库,实现了状态的同时访问。由于Monad从零开始构建这个数据库,它能够利用最新的Linux内核技术和SSD的全部能力进行异步I/O。通过异步I/O,如果交易需要从磁盘读取状态,这不应该阻止等待完成的操作。相反,它应该开始读取,并同时继续处理其他交易。这就是异步I/O显著加速MonadDB处理的方式。Monad通过优化SSD的使用并减少对过量RAM的依赖,从硬件中提取了更好的性能。这还有助于与去中心化和可扩展性保持一致。

对Solana、Sei与Monad的比较总结

结论

通过 Solana、Sei 和 Monad 的视角探索区块链中的并行化,为理解不同架构和方法如何提高性能和可扩展性提供了全面的认识。Solana 的确定性并行化通过 upfront 声明状态访问,提供了可预测性和效率,使其成为需要高吞吐量应用的有力选择。另一方面,Sei 的Optimistic 并行化方法优先考虑开发者灵活性,非常适合事务冲突不频繁的环境。Monad 通过其独特的Optimistic 并行化和定制的 MonadDB,提出了一个创新解决方案,利用最新技术优化状态访问和性能。

每个区块链都呈现出独特的并行化挑战应对方法,拥有自己的权衡。Solana 的设计旨在最大化硬件利用率和吞吐量,而 Sei 关注于简化开发过程,Monad 强调为区块链数据定制的数据库解决方案。这些差异凸显了区块链生态系统的多样性及基于应用特定需求选择合适平台的重要性。

随着区块链领域的持续发展,Solana、Monad 和 Sei 所展示的并行化技术进步无疑将激发进一步的创新。朝着更高效、可扩展和开发者友好的区块链前进的旅程正在进行中,从这些平台学到的经验将在塑造区块链技术未来中发挥关键作用。

在本系列的第二部分,我们将深入探讨这些并行设计系统相关的经济含义和权衡。

声明:

  1. 本文转载自[Reciprocal Ventures],所有版权归原作者[Ali Sheikh]所有。如果对此转载有异议,请联系Gate Learn团队,他们将及时处理。
  2. 责任免责声明:本文中表达的观点和意见仅代表作者本人,并不构成任何投资建议。
  3. 文章的其他语言翻译由 Gate Learn 团队完成。除非另有说明,否则禁止复制、分发或抄袭翻译文章。

并行区块链设计空间探索(第一部分)

中级3/29/2024, 7:04:00 PM
这篇研究报告概述了区块链并行设计架构,通过三个相关案例研究:Solana、Sei 以及 Monad 来进行说明。报告着重于Optimistic并行化与决定性并行化的对比,并深入分析了这些区块链在状态和内存访问方面的细节差异。

摘要:本研究报告提供了对区块链并行设计架构的全面概述,选取了Solana、Sei 和 Monad 三个案例进行分析。文中详细比较了Optimistic并行化与决定性并行化的不同之处,并对这些区块链系统中的状态和内存访问模式进行了细致考察。

介绍

1837年,计算机科学家和数学家查尔斯·巴贝奇设计了“分析机(Analytical Engine)”,为并行计算奠定了理论基础。在当今的加密技术领域,并行化成为了一个核心议题,这是因为区块链技术正努力突破处理速度、效率及吞吐量的限制。

并行宇宙

并行计算使得许多计算或进程能够同时执行,与串行执行或一个接一个地执行计算相反。并行计算指的是将较大的问题分解成较小的、独立的部分,这些部分可以由多个处理器通过共享内存进行通信来执行。并行系统有许多优势,例如提高效率和速度、可扩展性、提高可靠性和容错能力、更好的资源利用以及能够处理非常大的数据集。

然而,至关重要的是要认识到,并行化的有效性取决于底层架构和实现的具体情况。阻碍区块链的两个核心瓶颈是密码学函数(哈希函数、签名、椭圆曲线等)和内存/状态访问。在区块链中,设计高效并行系统的关键组成部分之一在于访问状态的细微差别。状态访问指的是交易读取和写入区块链状态的能力,包括存储、智能合约和账户余额。要使并行化区块链有效和高性能,必须优化状态访问。

目前关于优化并行化区块链的状态访问有两种思路:确定性并行化与Optimistic并行化。确定性并行化要求代码明确声明哪些区块链状态的部分将被访问和修改。这允许系统事先确定哪些交易可以并行处理而不会发生冲突。确定性并行化允许可预测性和效率(特别是当交易大多是独立的时候)。然而,它确实为开发者创建了更多的复杂性。

Optimistic并行化不要求代码事先声明其状态访问,而是假设不会有冲突地并行处理交易。如果发生冲突,Optimistic并行化将重新运行、重新处理或串行运行冲突的交易。虽然Optimistic并行化为开发者提供了更多的灵活性,但冲突需要重新执行,这使得这种方法在交易不冲突时最为高效。关于这些方法哪一个更好,并没有确切的答案。它们只是并行化的两种不同(且可行的)方法。

在本系列的第一部分,我们首先探索一些非加密并行系统的基础知识,随后将关注区块链的并行执行设计空间,重点是三个核心领域:

  1. 加密并行系统概述

  2. 内存与状态访问方法

  3. 并行设计的机会

非加密并行系统

根据我们上面刚刚读到的有关并行计算的功能和并行系统的优点的内容,很容易理解为什么近年来并行计算的采用已经开始兴起。仅在过去几十年里,并行计算的广泛采用就实现了许多突破。

  1. 医学影像:并行处理从根本上改变了医学成像,使得MRI、CT、X光和光学层析等各种模式的速度和分辨率显著提高。Nvidia站在这些进步的前沿,通过其并行处理工具包为放射科医生提供增强的人工智能能力,使成像系统能更有效地处理增加的数据和计算负载。
  2. 天文学: 一些新现象,例如理解黑洞,只有通过使用并行超级计算机才成为可能。
  3. Unity的游戏引擎:Unity的引擎利用GPU的能力——这些GPU为处理大量图形工作负载而构建——以帮助提高性能和速度。该引擎配备了多线程和并行处理功能,提供无缝的游戏体验,并创建复杂、详细的游戏环境。

接下来,让我们检视三个实施了并行执行环境的区块链。首先,我们将解析Solana,其次是两个基于EVM的链,Monad和Sei

并行设计概述 – Solana

Solana的设计哲学核心在于,随着硬件技术的进步,区块链创新也应相应发展。这一理念基于摩尔定律,即硬件的性能和可扩展性将随时间不断提高,Solana致力于充分利用这一趋势。Solana的联合创始人Anatoly Yakovenko于五年前最初设计了其并行架构,现在,这种基于并行性的区块链设计原则正在快速普及。

Solana采纳了基于Anatoly在嵌入式系统领域工作经验的决定性并行化策略,在那里,通常需要 upfront(提前)声明所有状态。这一做法让CPU能够预知所有依赖关系,并提前获取所需的内存部分,优化了系统执行性能。但值得注意的是,这种方法要求开发者 upfront(提前)进行额外工作。在Solana上,程序的所有内存依赖都必须 upfront(提前)声明,在构造交易时需要指明访问列表,这样运行时系统就能高效地并行调度和执行多个交易。

Solana架构的另一个关键组成部分是Sealevel VM,这是Solana的并行智能合约执行环境。Sealevel VM天生就支持根据验证者所拥有的核心数量并行处理多个合约和交易。在区块链中,验证者负责验证交易、提议新的区块以及维护区块链的完整性和安全。通过 upfront(提前)声明哪些账户需要读取和写入锁定,Solana的调度器能够确定哪些交易可以并行执行。因此,对于验证者来说,作为“区块生产者”或领导者,可以对数以千计的待处理交易进行排序,并并行调度非重叠的交易。

Solana的另一个设计特点是其“流水线”处理方式。流水线处理发生在数据需要经过一系列处理步骤时,由不同的硬件负责每个步骤。其核心思想是把需要串行处理的数据通过流水线技术实现并行化。这些流水线能够并行运行,每个流水线阶段能够并行处理不同批次的交易。

这些优化使得Sealevel可以组织并同时执行独立的交易,借助硬件的能力,通过单个程序同时处理多个数据点。Sealevel通过程序ID对指令进行排序,并在所有相关账户上并行执行相同指令。

综上所述,Solana的设计创新明确旨在支持并行化处理,充分展示了其设计理念的先进性和对硬件发展趋势的深刻理解。

并行设计概述 – Sei

Sei 是一个针对数字资产交换专门化的通用、开源的一级区块链。Sei V2 利用Optimistic并行化,因此,与其确定性对手相比,对开发者更为友好。在Optimistic并行化中,智能合约可以更顺畅、更并发地执行,而无需开发者 upfront 声明他们的资源。这意味着链Optimistic地并行运行所有交易。但是,当存在冲突时(即,多个交易访问同一状态),区块链将跟踪每个冲突交易影响的特定存储组件。

Sei 的区块链使用“Optimistic并发控制(OCC)”来执行交易。当系统中同时存在多个交易时,就会发生并发交易处理。这种交易方法有两个阶段:执行和验证。

在执行阶段,交易被Optimistic地处理,所有读/写操作临时存储在交易特定的存储中。之后,每个交易都会进入验证阶段,此时,临时存储操作中的信息会与之前交易所做的任何状态改变进行检查。如果一个交易是独立的,那么该交易并行运行。如果一个交易读取了由另一交易修改的数据,这将产生冲突。Sei 的并行系统会通过比较交易的读取集合与多版本存储中的最新状态改变(这些由交易顺序索引)来识别每个冲突。Sei 将重新执行和重新验证出现冲突的实例。这是一个包括执行、验证和重新运行的迭代过程,以解决冲突。下面的图表说明了 Sei 在出现冲突时处理交易的方法。


来源:https://blog.sei.io/sei-v2-the-first-parallelized-evm/

Sei 的实现导致更低的Gas费用和更广泛的设计空间,为EVM开发者提供。历史上,EVM环境限制在小于50 TPS,这迫使开发者创建遵循反模式的应用程序。Sei V2 使开发者能够涉足通常需要高性能和低费用的领域,如DeFi、DePIN和游戏。

并行设计概述 – Monad

Monad 正在构建一个具有完全字节码兼容性的并行 EVM 第 1 层。Monad 独特之处不仅在于其并行引擎,还在于他们为优化该引擎所做的底层建设。Monad 采取了独特的整体设计方法,包括管道化、异步 I/O、分离共识和执行,以及 MonadDB。

Monad 设计中的一个关键创新是带有微小偏移的管道化。这种偏移使得通过同时运行多个实例,可以并行化更多的过程。因此,管道化用于优化许多功能,如状态访问管道化、交易执行管道化、共识与执行中的管道化,以及共识机制本身内的管道化。

接下来,我们将深入探讨 Monad 的并行化部分。在 Monad 中,交易在区块内线性排序,但目标是通过利用并行执行来更快地达到这一最终状态。Monad 使用一种Optimistic 的并行算法来设计其执行引擎。Monad 的引擎同时处理交易,然后进行分析,以确保如果交易依次执行,结果会相同。如果存在任何冲突,就需要重新执行。这里的并行执行是一个相对简单的算法,但与 Monad 的其他关键创新结合起来,使得这种方法显得新颖。需要注意的一点是,即使重新执行,通常也是低成本的,因为无效交易所需的输入几乎总是保留在缓存中,因此它将是一个简单的缓存查找。重新执行是有保证的成功,因为你已经执行了区块中的前一个交易。

Monad 还通过分离执行和共识来提高性能,类似于 Solana 和 Sei,此外还有延迟执行。这里的想法是,如果你放宽执行完成的条件到共识完成的时间,你可以并行运行两者,从而为两者提供额外的时间。当然,Monad 使用一个确定性算法来处理这个条件,以确保这些中的一个不会跑得太远而没有赶上的可能性。

独特的状态访问与内存方法

如我在本文开头所提到的,状态访问是区块链的典型性能瓶颈之一。状态访问和内存的设计选择最终决定了并行系统的特定实现是否能在实践中提升性能。这里,我们将解析并比较Solana、Sei和Monad采取的不同方法。

Solana状态访问:AccountsDB / Cloudbreak

Solana采用横向扩展来分布和管理状态数据,跨多个SSD设备。今天许多区块链使用通用数据库(例如,LevelDB)来处理大量并发读写状态数据时的限制。为了避免这一点,Solana构建了自己的定制AccountsDB,利用Cloudbreak。

Cloudbreak是为跨I/O操作的并行访问而设计的,而不是仅仅依赖于RAM,后者本质上是快速的。I/O操作(输入/输出)指的是从外部源(如磁盘、网络或外围设备)读取数据或写入数据。最初,Cloudbreak采用了一个在RAM中的索引,用于映射公钥到持有余额和数据的账户。然而,截至撰写本文和版本1.9,索引已经从RAM移出,存放到SSDs上。这一转变允许Cloudbreak同时处理队列中的32个I/O操作,提高了跨多个SSDs的吞吐量。因此,如同使用内存映射文件一样,区块链数据(如账户和交易)可以高效地被访问,尽管RAM更快,但它的容量较少且通常更昂贵:


说明性的内存层次结构图

通过水平扩展并在多个设备上分布状态数据,Cloudbreak降低了延迟并提高了效率、去中心化和网络弹性,这些都是Solana生态系统内的重要改进。

状态访问:SeiDB

Sei重新设计了其存储系统SeiDB,以解决几个问题:写放大(维护数据结构所需的元数据量,更小=更好)、状态膨胀、操作缓慢以及随时间性能降低。新的设计现在分为两个部分:状态存储和状态提交。任何对数据变更的记录和验证都由状态提交处理,而记录任何时点所有数据的数据库由状态存储(SS)处理。

在Sei V2中,状态提交使用内存映射IAVL树架构(MemIAVL)。内存映射IAVL树存储的元数据较少,这减少了状态存储和状态同步时间,并且使运行全节点变得更加容易。内存映射IAVL树表示为磁盘上的三个文件(kv, branch, leaves);因此,需要追踪的元数据较少,这有助于将状态存储减少50%以上。新的MemIAVL结构有助于减少写放大因子,因为它减少了维护数据结构所需的元数据。

更新后的SeiDB允许状态存储层支持灵活的数据库后端。Sei认为,不同的节点操作者将有不同的需求和存储需求。因此,SS被设计为能够适应不同的后端,为操作者提供自由和灵活性,即PebbleDB、RocksDB、SQLite等。

状态访问:MonadDB

Monad的状态访问有一些重要的细微差别。首先,大多数以太坊客户端利用两种类型的数据库:B-Tree数据库(例如LMDB)或日志结构合并树(LSM)数据库(例如RocksDB, LevelDB)。这两种都是通用数据结构,并非专为区块链设计。此外,这些数据库没有利用Linux技术最新的进步,特别是关于异步操作和I/O优化。最后,以太坊本身使用Patricia Merkle Trie管理状态,专注于加密、验证和证明。主要问题是,客户端必须将这种特定的Patricia Merkle Trie整合到更通用的数据库(即B-Tree / LSM)中,导致显著的性能缺点,如过度的磁盘访问。

上述所有这些都为Monad决定创建专门设计的MonadDB数据库铺平了道路,这个数据库旨在更高效地处理区块链数据和状态访问。MonadDB的一些关键特性包括并行访问数据库、针对Merkle Trie数据优化的自定义数据库、高效的状态访问与标准RAM使用之上、去中心化与可扩展性。

MonadDB专门为区块链设计,比利用通用数据库更为高效。定制的MonadDB专为高效管理Merkle trie型数据而量身定做,使得可以同时并行访问多个trie节点。尽管MonadDB与上述某些通用数据库的单次读取成本相同,但关键在于MonadDB可以并行进行多次读取,从而大幅提速。

MonadDB通过并行访问数据库,实现了状态的同时访问。由于Monad从零开始构建这个数据库,它能够利用最新的Linux内核技术和SSD的全部能力进行异步I/O。通过异步I/O,如果交易需要从磁盘读取状态,这不应该阻止等待完成的操作。相反,它应该开始读取,并同时继续处理其他交易。这就是异步I/O显著加速MonadDB处理的方式。Monad通过优化SSD的使用并减少对过量RAM的依赖,从硬件中提取了更好的性能。这还有助于与去中心化和可扩展性保持一致。

对Solana、Sei与Monad的比较总结

结论

通过 Solana、Sei 和 Monad 的视角探索区块链中的并行化,为理解不同架构和方法如何提高性能和可扩展性提供了全面的认识。Solana 的确定性并行化通过 upfront 声明状态访问,提供了可预测性和效率,使其成为需要高吞吐量应用的有力选择。另一方面,Sei 的Optimistic 并行化方法优先考虑开发者灵活性,非常适合事务冲突不频繁的环境。Monad 通过其独特的Optimistic 并行化和定制的 MonadDB,提出了一个创新解决方案,利用最新技术优化状态访问和性能。

每个区块链都呈现出独特的并行化挑战应对方法,拥有自己的权衡。Solana 的设计旨在最大化硬件利用率和吞吐量,而 Sei 关注于简化开发过程,Monad 强调为区块链数据定制的数据库解决方案。这些差异凸显了区块链生态系统的多样性及基于应用特定需求选择合适平台的重要性。

随着区块链领域的持续发展,Solana、Monad 和 Sei 所展示的并行化技术进步无疑将激发进一步的创新。朝着更高效、可扩展和开发者友好的区块链前进的旅程正在进行中,从这些平台学到的经验将在塑造区块链技术未来中发挥关键作用。

在本系列的第二部分,我们将深入探讨这些并行设计系统相关的经济含义和权衡。

声明:

  1. 本文转载自[Reciprocal Ventures],所有版权归原作者[Ali Sheikh]所有。如果对此转载有异议,请联系Gate Learn团队,他们将及时处理。
  2. 责任免责声明:本文中表达的观点和意见仅代表作者本人,并不构成任何投资建议。
  3. 文章的其他语言翻译由 Gate Learn 团队完成。除非另有说明,否则禁止复制、分发或抄袭翻译文章。
即刻开始交易
注册并交易即可获得
$100
和价值
$5500
理财体验金奖励!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.