自九年前以太坊推出首个去中心化、可编程的区块链以来，加密货币在扩展去中心化应用至数十亿用户的过程中遭遇了多个障碍。为了开发解决这一问题的扩展解决方案，加密货币行业不断资助并开发全新类型的区块链来解决“性能问题”。

然而，“性能问题”被定义和量化的方式欠妥。合成的概念如“每秒交易次数”将实际上并不需要等同计算工作的交易进行了简单打包比较。这些指标缺乏细微差别，也遮蔽了我们评估区块链各个组件对性能影响的能力，使我们从原则性方法中分心，无法识别我们可以进行优化的一组问题，这些问题高度相互依赖。

尽管有这种困扰，我们在过去几年中看到了区块链可扩展性的可信赖、持续的改进。随着以太坊通过其以 Rollup 为中心的路线图，新一波的 Rollups、协处理器、数据可用性（DA）层和竞争的 L1 正在涌现，每个都带有独特的设计选择，为开发者提供更高性能的环境，用于建立可扩展、用户友好的去中心化应用程序（dapps）。

今天，EIP4844 的引入和备选 DA 层已经缓解了关键的 DA 瓶颈。尽管达到了这个关键里程碑，证据表明还需要解决其他重要的瓶颈。上个月，Base 在单日内收集了 157万美元的交易费用，而只支付了5000美元的以太坊数据可用性成本。这表明，验证和处理状态更新所需的计算工作仍然是一个关键的瓶颈和改进的机会。

本文将评估集成和模块化执行环境在解决更高性能，以及扩大链上应用程序范围的过程中所做的设计选择。

当今的挑战

执行层的性能可以根据执行节点相对于其链的区块时间所完成的计算工作来进行基准测试，或者叫作 “以秒计算的gas”。

‍有了这个思路，我们可以将执行层的瓶颈缩小到两个相互关联的因素：效率低下的状态访问和效率低下的计算。

效率低下的状态访问是指检索和更新区块链状态的开销，这可能会减慢交易处理速度。另一方面，效率低下的计算是由执行操作和状态转换的算法所带来的开销，这可能包括从简单的转账到复杂的智能合约和签名验证的所有内容。

这些瓶颈是相互强化的 - 状态访问的延迟可能会延长计算时间，而效率低下的计算实践可能会给状态管理带来压力。而且，解决这些问题的建议的改进通常需要系统性的改进，比如分片或者采用无状态架构，这些可以提高状态访问和计算效率，以提高执行性能。

瓶颈#1：低效的状态访问

访问区块链的状态所需的成本和速度是影响执行环境性能的关键瓶颈，可以归结为状态膨胀的问题。

在区块链中，世界的状态通过特定的数据结构——树（Tree） 来管理和更新。树对区块链至关重要，为执行节点外部的各方提供了一种安全而有效的方式，保证了对区块链正确状态的认证。树中的每次更新都会生成一个新的根哈希，轻节点（light client）可以参照这个哈希来验证交易和账户余额，无需维护整个链。

以太坊特别依赖一种名为 Merkle Patricia trie (MPT)的数据结构，它包含@chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">四个子树。

随着以太坊向其状态中添加更多的智能合约和代币，其状态树变得越来越大，越来越复杂。状态的增长需要更多的存储空间，更多的计算资源来处理，以及更多的带宽来传输。同时，节点的硬件限制大体保持不变。

这种状态增长直接影响了以太坊的性能，因为状态是存储在磁盘中的，磁盘操作产生了高额的开销。从CPU寄存器访问数据可能只需要0.1纳秒，而从磁盘访问数据可能需要10至100微秒——这是前者的100倍至1000倍，大致相当于在这段时间内可以执行的200,000个CPU指令。这等同于本可以进行的36次ERC-20转账！

区块链有许多低效的读取和写入状态的访问模式，这加剧了这个问题。例如，Merkle Patricia trie 的非顺序结构本质上导致了这些磁盘 输入/输出（I/O） 从磁盘上的各种不可预测的位置读取和写入的操作。交易输入的随机性以及它们触发的后续状态变化导致分散的数据访问模式，这显着减慢了验证和更新状态的过程，并且仅利用了硬件设备的容量的一部分。

总的来说，区块链的状态管理原语远未实现其绝对的潜力，可以通过许多方式提高计算效率。

瓶颈#2：效率低下的计算

执行层还面临计算效率低下的瓶颈，其表现形式多种多样。

首先，许多交易处理是顺序进行的，没有充分利用现代多核处理器同时处理多个操作的能力。这种顺序执行导致交易之间不可避免的CPU空闲时间，浪费了宝贵的计算资源。

其次，使用虚拟机涉及将高级智能合约操作翻译成字节码——一种更低级别、平台独立的代码——然后按指令执行。这种翻译和执行过程带来了大量的开销，特别是对于具有复杂且频繁重复的特定应用任务的应用程序。

这些效率低下的问题导致了计算资源的次优使用，阻碍了执行层的性能。

解决方案：低效的状态访问

团队们通过几种不同的方式提升了状态从执行节点的硬件中被检索和更新的速度，包括简化复杂的数据结构以及找到减少导致状态膨胀的昂贵的磁盘 I/O 操作的方法。

无状态和内存计算

一些执行层通过短期内简单地接受状态膨胀来解决此问题。他们将状态数据存储从较慢的基于磁盘的系统转移到更快的随机访问内存（RAM）。在 RAM 中访问状态信息显著减少了与磁盘操作相关的开销，因为这些操作更慢且更消耗资源。

然而，这种方法挑战了去中心化的核心原则。在 RAM 中存储越来越大的状态数据需要更先进和昂贵的硬件，这可能限制个人作为节点操作者的能力。因此，随着硬件要求的升级，能够运行这些节点的实体数量将减少。

为了平衡内存计算的吸引力和信任最小化，L1（例如以太坊）和 L2 都在追求可扩展性路线图，该路线图依赖于将验证者的角色分解为具有许多验证节点的单独的集中式执行节点。在这个模型中，具有在内存中计算的硬件要求的高性能区块生产者负责生成区块，并通过验证节点来利用加密证明（欺诈和有效性证明）来让区块生产者承担责任。

因此，这些系统应该允许区块生产者最大化他们的速度，因为他们可以预期在内存中计算，完全消除执行期间的磁盘 I/O。由于 RAM 的延迟通常在 100 纳秒以下，相对于基于磁盘的实现，状态访问的延迟降低了近 1000 倍。

同时，欺诈性和有效性证明取代了去中心化的共识，以便随着系统吞吐量的扩大，也能扩展系统的信任最小化属性。因此，强大的、中心化的区块生成节点被可以在更便宜的硬件上运行的验证节点所平衡。这些节点执行着关键的功能，独立地验证状态转换（或无效的状态转换）的证明，以维持对状态的准确视图，而无需承担存储整个区块链状态的负担。

为了以信任最小化的方式促进这一过程，执行层必须实现一定程度的无状态性，最流行的是“弱无状态性”的概念。弱无状态性是通过要求区块生产者向验证节点提供一种称为见证的加密声明来实现的。这个见证封装了新区块提出的所有状态更改，使验证者可以验证这些更改，而无需额外的历史数据。

虽然这个概念可以应用各种树结构，但Verkle树通常比Merkle树更受欢迎，因为它们的效率更高。Merkle树需要包含从数据点（叶）到树根的路径上的所有兄弟节点哈希，以证明数据的完整性。这个要求意味着见证（完整性的证明）的大小随着树的高度增长，因为每个级别都需要额外的哈希。因此，在Merkle树中验证数据完整性变得计算密集和昂贵，特别是对于大型数据集。相比之下，Verkle树简化了这个过程，减少了在生成和验证新区块时与计算和存储相关的开销。

来自 Inevitable Ethereum 的“Verkle Tree”的扩展

Verkle 树优化了传统 Merkle 树的结构，简化了叶子节点与根节点之间的连接，并消除了在验证过程中需要包含兄弟节点的需求。在 Verkle 树中，验证一个证据只涉及到叶节点处的值，对根节点的承诺，以及基于多项式承诺的单一向量承诺，这替换了 Merkle 树中发现的多个基于哈希的承诺。这种转变使 Verkle 树能够保持固定大小的证人，不会随着树的高度或验证的叶子数量的增加而增加，显著提高了在数据验证过程中的存储和计算的效率。

在未来几年中，我们将看到在L1和L2级别上实现无状态性的实现，这些实现将具有多种配置。根据最新的以太坊路线图，验证者可以依靠区块构建者提供关于某些区块状态的Verkle证明，并验证这些轻量级证明，而不是直接维护以太坊的状态。

在L2级别，像MegaETH这样的团队正在积极将无状态性的概念应用到乐观性rollup的设计中。在他们的设计中，序列器节点为每一个区块生成一个包含必要的状态值和中间哈希的证人，同时发出表示状态变化的状态增量。然后，验证节点可以通过从DA层或点对点网络检索证人来重新执行任何区块，而无需存储全部状态。同时，全节点通过应用通过网络传播的状态增量来更新他们的状态，使他们能够保持同步，而无需重新执行交易或存储全部的状态历史。

然而，也值得指出的是，无状态性的好处以及由此产生的在内存中计算的能力并不是执行层性能的灵丹妙药。

来自 MegaETH 的”理解以太坊执行层性能”的实时TPS

正如 MegaETH 的联合创始人Yilong Li（李一龙）在他的以太坊执行研究报告中所指出的，区块链上的数据结构和访问模式仍存在其他的效率问题。

改进数据库

在执行层工作的团队正在寻找改进数据库结构的方法，以消除以太坊和其他与EVM兼容的区块链在处理低效率状态访问方面遇到的一些瓶颈，这对计算效率产生了连锁反应。

事实上，EVM现有的数据库设计的局限性促使了 Monad决定超越纯粹的优化计算效率，以实现并行化。Monad发现，即使实现了并行执行，他们也只看到了性能的微小提速，因为多线程的读写请求互相阻塞。因此，Monad实现了一个与*异步I/O（AIO）或并行访问兼容的数据库，作为解决方案的关键部分。

异步I/O（Async I/O）

I/O操作——如读取或写入存储设备——经常造成瓶颈，特别是在机械硬盘驱动器（HDD）中。这些驱动器需要物理移动读/写头来访问数据，这可能大大减慢数据处理速度。

AIO通过允许程序与其他进程并行执行I/O操作来解决这个挑战。本质上，一个程序可以启动一个I/O操作，然后继续执行，而不需要等待它完成。它通过注册一个回调函数或一个操作系统或I/O库在I/O操作完成后将兑现的承诺来实现这一点。这种异步方法允许主程序继续执行其他任务，通过不等待I/O任务完成来提高整体效率。

异步I/O可以在传统的HDD和固态驱动器（SSD）中实现，尽管在SSD中的效益更为明显。HDDs可以执行AIO，但由于它们的机械性质，它们本质上比SSD慢，SSD在闪存上存储数据，没有移动部件，导致更快的访问时间。

例如，Monad 利用针对 SSD 存储优化的自定义状态后端，支持高水平的并行数据处理并减少 I/O 延迟。这种设置比仅依赖传统的基于磁盘的存储或使用内存数据库的系统更有效，后者可能仍面临因频繁向较慢的存储介质写入和读取数据而导致的延迟。

类似地，Reth采用了将数据库操作与核心EVM执行引擎分离的方法。此设置允许 EVM 字节码在单个线程上顺序执行以保持一致性，同时将数据库 I/O 任务卸载到并行进程。 Reth 使用参与者（actor）模型（一种软件架构模式）来有效管理这些并行进程，确保 I/O 操作不会中断 EVM 解释器。

状态默克尔化频率（State Merklization Frequency）

另一个优化的向量是状态默克尔化的频率。以太坊当前在每个区块后默克尔化状态的模型引入了重要的开销，需要频繁地从磁盘读取和写入，并持续进行trie遍历。默克尔树通常通过将中间哈希分组到16个（称为节点）的集合中，并将它们存储在键值存储数据库中，其中键是节点哈希，值是节点本身。

遍历这棵树来查找和更新数据需要对树的每一层进行一次随机磁盘访问，而遍历一棵普通的 Merkle 树，每个条目大约需要八次顺序数据库查询。

Solana的方法是在每个epoch结束时更新状态提交，这允许在该期间的多个交易上摊销写入成本。如果在同一epoch中修改了多次状态条目，每次写入都不需要立即更新默克尔根。这减少了在epoch期间与状态更新相关的整体计算开销。因此，与状态相关的读取成本保持常数，或者是O(1)，因为可以直接读取状态，而不需要每次都遍历默克尔路径。

减少以太坊中默克尔化的频率可能会减少状态读取和写入的开销，提高性能。然而，轻客户端需要回放区块更改以跟踪epoch之间的状态或提交链上交易以进行状态验证，这种改变目前与以太坊不兼容。

高效和专用的数据结构

此外，现有以太坊客户端内的分层树结构通常会导致低效的状态访问模式，进一步加剧了状态膨胀。虽然以太坊的状态被构造为 MPT，但它也存储在以太坊客户端数据库中，例如水平数据库（LevelDB）, Pebble数据库 （由 go-ethereum 使用）或 MDBX（由 Erigon 使用），它们将数据存储在 Merkle 树中，例如B树 或者LSM树。

在这种设置中，一个数据结构被根入另一种类型的数据结构，创建了通过在基于另一个基于默克尔树的系统的客户端上操作的内部树结构来导航的”读放大”。读放大可以理解为在状态中访问或更新信息需要的多个步骤，这需要导航外部树以找到进入MPT的入口点，然后执行所需的操作。因此，对于随机读取，磁盘访问的数量乘以一个log(n)因素。

为了解决这个问题，Monad 在硬盘和内存中本地使用了 Patricia trie 数据结构。从技术角度来看，Patricia tries通常优于其他默克尔树结构，因为它们独特的空间效率，高效的前缀匹配和最小的节点遍历的结合。trie的设计使得单一子节点的节点崩溃并简化了查找，插入和删除，减少了需要的磁盘或网络I/O操作的数量。此外，Patricia trie在处理前缀匹配方面的熟练性提高了需要快速部分键搜索的应用程序的性能。

另一个特定于基于树的结构的瓶颈是，访问或更新数据需要遍历多个层次，导致许多顺序磁盘访问。Sovereign Labs通过倡导使用二叉默克尔树配置来解决这种低效率问题。这个关键的转变到二元结构大大减少了树遍历时的可能路径，直接减少了更新，插入和密码学证明所需的哈希运算。

来自Sovereign Labs的”几乎最优的状态默克尔化（Merklization）“的二元默克尔树配置

在这个类别中的另一个例子是Reth团队通过在执行过程中从磁盘预取中间trie节点来配置Reth，通过通知状态根服务触及的存储槽和账户。

状态过期

状态过期是一种通过移除一段设定时间内未被访问的数据来管理和减少区块链状态大小的机制。虽然过期经常被归类为“无状态”范畴，但在执行环境中区分这些概念非常关键。

无状态性通过提高执行节点在内存中计算的能力来改善执行，但是执行的改进源于在较少的执行交易的节点上对更强大的硬件要求。相比之下，状态过期可以应用于拥有少数或众多执行节点的区块链。

目前讨论用于实现状态过期的常见方法有两种：

• 租金过期：这种方法涉及对维持状态数据库中活动账户的维护费用或“租金”进行收费。如果未支付租金，账户会被归档，直到支付费用将其恢复。
• 时间过期：在这里，如果账户在指定的时间段内未被访问（即无交易或互动），则视为不活动。

这两种方法的目标都是只在即时、可访问的状态中维护活动使用的数据，而将较老、较少访问的数据推送到不会给主系统带来负担的归档状态。

通过维护更小、更易管理的状态，状态过期减少了可能严重阻碍区块链性能的“状态膨胀”。较小的状态大小使节点可以快速导航和更新状态，这转化为更快的执行，因为节点花费更少的时间扫描，更多的时间处理。

执行分片

分片通过在有限数量的专用节点（并非每个节点都执行全局状态）之间分配任务和数据，优化资源利用率和性能。

在分片的区块链架构中，全局状态被划分为称为分片的明确部分。每个分片都维护其状态部分，并负责处理网络交易的一个子集。交易根据确定性分片函数分配到特定分片，该函数考虑各种因素，如发送方地址、接收方地址和交易数据的哈希。这最小化了跨分片通信的需求，并使得交易执行更加高效。

来自 Vitalik 的 “区块链可扩展性的限制” 的分片图

当探索NEAR协议的分片设计 Nightshade 时，这一点变得显而易见。Nightshade 实现了无状态性，以在不妥协信任最小化的情况下扩展分片。

在Nightshade中，区块链被构建为一个单一的逻辑链，每个区块由多个“块”组成，每个分片分配一个块。这些块包含每个分片特定的交易和状态转换。在一个区块中包含所有分片的块，可以对整个区块链状态有一个统一的视图，并简化跨分片通信的过程。

与以太坊的提案者- 构建者分离（PBS）类似，Nightshade 明确划分了有状态和无状态节点的角色。在NEAR上，有状态的验证者被分配到特定的分片，并负责收集交易，执行它们，并产生特定于分片的块。他们维护其分配分片的完整状态，并为验证者在验证过程中生成状态证明。

同时，无状态的验证者在每个区块的基础上被随机分配验证特定的分片。他们不需要维护完整的分片状态，并依赖其他分片的区块生成器提供的状态证明来验证一个块内的状态转换和交易。验证者到分片的随机分配有助于确保网络的安全性和完整性，因为它让恶意行为者合谋控制特定分片变得更加困难。

由于网络中的每个节点只需要处理其各自分片的数据，而不是整个网络的数据，所以降低了单个节点的存储和计算负担。

解决方案：效率低下的计算

并行化执行

是时候解决眼前的主要问题了：并行化。并行化交易执行可以同时利用多个计算资源并行处理多个交易。这在高需求时期可以通过扩展硬件资源来提高吞吐量。

然而，重要的是要考虑到可以并行化多个执行组件，其中许多已经由协处理器如Lagrange* 和替代区块链客户端如Firedancer 实现，以显著提高区块链的性能。具体来说，可以并行化以下操作：

• 并行状态访问
• 并行化特定操作
• 并行化共识和执行

并行化状态访问

并行化状态访问带来了两个关键的好处：

• 并行 EVM 将交易处理分布在多个 CPU 核心上。此设置允许同时处理多个交易，而不是强制它们排队等待单个资源。
• 当一个交易等待来自存储的数据——可能引入显著的延迟——系统不会处于空闲状态。相反，它可以切换到另一个准备执行的交易。这是可能的，因为多个核心可以独立并同时处理不同的任务。

并行化事务执行的主要挑战源于管理并发访问共享全局状态而不违反更新分布式系统的ACID规则。如果一个区块链有大量并行执行的交易，其中一些将会冲突。因此，主要的并行化状态访问方法在何时分配资源来解决冲突上有所不同：悲观执行（或内存锁）模型和乐观执行模型。

悲观执行模型（Pessimistic Execution）

悲观执行模型是一种处理交易的方式，要求交易在执行过程中声明它们将要访问（读取或写入）的状态变量。这些信息包含在交易的元数据中，使运行时可以在执行前分析访问模式。

通过检查读写访问模式，运行时可以识别出访问集不重叠的交易，从而使非重叠和只读交易并行执行，提高吞吐量。运行时为验证节点上的每个CPU线程创建并行交易队列，确保处理具有非冲突访问模式的交易时的并行性。

由于这种设计选择，悲观执行模型从对资源分配的细粒度控制中获益，允许对区块链的状态空间进行分段或划分。

并行化有效地在统一的安全模型支撑下创建了多个，同步可组合的独立执行分片。它通过精确的资源管理和动态费用市场，帮助解决网络拥塞和优化gas成本。通过识别状态访问的“热点”（高交易需求区域），系统可以实施针对性的优化，如差异化的费用定价，速率限制，或为高争用状态分配额外资源。需要注意的是，Solana当前对并行化的实现并未充分实现本地化费用市场的潜力。

为了在并发访问中确保数据一致性，悲观执行模型使用了锁定机制。在交易可以访问特定的状态变量之前，它必须在该变量上获得一个锁。该锁为交易提供对该变量的专有访问，防止其他交易同时修改它。一旦交易执行，锁就会被释放，允许其他交易访问变量。

在Solana 的 Sealevel 运行时中，实现了这种悲观执行模型，交易在执行期间指定它们将读取或写入的账户。Sealevel 分析访问模式，并为验证器节点上的每个CPU线程构建并行交易队列。如果一个账户被多次访问，它会在一个队列中按顺序列出，以防止冲突。未在领导者节点的块时间内处理的交易会被打包并转发到下一个计划的领导者进行处理。

未消费的交易输出(UTXO)基础的系统类似地提高了计算效率。UTXO涉及与个人钱包相关的特定货币单位—UTXO。对于该钱包的每一笔交易，UTXOs被消耗并被新的替换；为接收者创建一个或多个UTXO，代表支付，通常也为发起者创建另一个UTXO，代表找零。

通过定义哪些合约会被触及，可以并行执行触及不相交合约集的交易。这可以通过在“账户”数据模型中设定严格的访问列表来实现。然而，为了与以太坊风格的智能合约保持兼容，像Fuel这样的UTXO方案对区块生产节点执行具有重叠访问列表的交易的顺序进行了限制。

然而，悲观执行模型也存在局限性。交易必须预先准确声明其访问模式，这对于那些访问模式可能依赖于输入数据或条件逻辑的复杂或动态交易来说，可能是个挑战。不准确或不完整的访问模式声明可能导致性能下降和潜在的运行时错误。此外，当许多交易争夺相同状态变量时，锁定机制可能会导致延迟并降低并发性。这种竞争可能形成性能瓶颈，因为交易可能会花费大量执行时间等待获取高需求状态变量的锁。

更重要的是，这种模型给开发人员带来了相当大的负担，他们必须深入了解合约的数据依赖关系，才能准确地预先指定必要的状态访问。这种复杂性可能会带来挑战，特别是在设计具有动态和复杂状态交互的应用程序时，例如去中心化交易所或自动化做市商。

乐观执行（Optimistic Execution）

相比之下，乐观执行模型采用了一种“推测性”的交易执行方式，允许交易在不需要预先声明状态访问的情况下并行执行。

这种模型并不是在冲突发生之前就阻止它们，而是乐观地并行执行交易，假定它们是独立的。运行时采用了如多版本并发控制（MVCC）和软件交易内存（STM）等技术来在执行过程中跟踪读写集。执行后，运行时检测任何冲突或依赖关系。它采取纠正措施，例如中止并重新执行冲突的交易，但可以通过从内存而不是磁盘读取来识别冲突的交易。

乐观执行模型简化了开发过程，让程序员可以专注于编写合约逻辑，而不必担心声明状态访问模式。由于交易不需要预先声明其状态交互，因此开发人员在设计智能合约时拥有更多自由，从而允许与区块链状态进行更复杂和动态的交互。乐观执行模型特别适合支持大量交易和复杂 dapp 的平台，因为它可以提供比悲观模型更高的吞吐量和可扩展性。

这个模型的一个显著实现在 Aptos 和 Movement Labs 的 MoveVM 中，它采用了一种名为 Block-STM 的技术。在 Block-STM 中，交易首先并行执行；然后，识别冲突的交易，并根据检测到的依赖关系安排重新执行。这种方法确保了处理资源的连续利用，提高了吞吐量，同时保持了交易工作流的完整性。

Aptos的Block-STM来自”通过将排序诅咒（_Ordering Curse）转变为性能祝福来扩展区块链执行（Performance Blessing）”_

尽管乐观执行模型具有优势，但也带来了挑战。需要进行运行时冲突检测，存在交易中止和重试的可能性，这增加了计算开销和复杂性。此外，还需要维护状态的多个版本，并管理与冲突解决相关的开销，需要复杂的系统设计和强大的并发控制机制来确保区块链的完整性和性能。

Block-STM利用MVCC（多版本并发控制）有效地管理并发写操作并维护数据的多个版本，从而防止同时进行的写操作之间发生冲突。它结合一个协作调度器在多个线程之间协调执行和验证任务，确保交易按照启动的顺序进行提交。这种设置通过使用动态依赖估计来最小化交易中止，使得具有依赖关系的交易可以在继续执行之前有效地等待并解决这些依赖关系。

此外，MoveVM使用的账户模型与以太坊的EVM不同，这导致碰撞更少。在以太坊中，通常由单一的智能合约管理一个代币，可能导致多个代币交易通过相同的合约地址交互，增加了冲突的可能性。相比之下，MoveVM将代币分配给个人用户账户，减少了这种冲突的可能性，因为每个交易通常与不同的账户地址交互。

在Monad中，可以将并行执行的初始交易集合视为一个I/O阶段，这可能产生立即可提交的结果，以及随后的“重试”阶段，这需要少量的工作来清除剩余的有冲突的交易。这些冲突转换被发现并拉入缓存，允许执行开销减少，因为它们存在于内存中。虽然大部分状态都存在于磁盘上，但在执行时可以快速访问冲突的交易。

悲观和乐观执行模型提供了处理区块链中交易执行和状态管理的不同方案。选择这两种模型涉及在预设的状态访问规范的复杂性和动态冲突解决相关的计算成本之间做出权衡。

数据和任务并行

数据并行和任务并行主要通过将计算负载分布到多个处理器来优化性能：数据并行将数据集进行切分以实现同时处理，而任务并行将不同的任务分配给多个处理器以并行操作。

这些优化与状态访问并行性有所不同但互相依赖，状态访问并行管理和同步对共享资源（如内存或数据库）的访问，以防止在多个进程或线程同时操作时发生冲突，并确保数据完整性。

数据并行性

数据并行涉及到在多个数据元素上并行执行特定操作。这种方法在需要对大型数据集应用相同操作或对多个输入值执行计算密集型操作时特别有益。关键的突破在于将数据分布在多个处理单元上，并同时对不同的数据元素执行相同的操作。

数据并行的一种常见技术是单指令，多数据（SIMD），它允许一条指令同时在多个数据元素上执行。现代CPU通常具有内置的SIMD能力，使其能够在多个数据点上执行并行操作。通过利用SIMD指令，开发者可以对某些类型的操作，如数学计算，数据转换或信号处理，实现显著的加速。

例如，考虑一个场景，您必须将复杂的数学函数应用于大量数字。 SIMD 可以同时处理多个数字，而不是按顺序处理每个数字。这种同步处理是通过将数字子集加载到 CPU 的 SIMD 寄存器中、对所有加载的数字并行执行数学函数、然后将结果存储回内存来实现的。通过一次处理多个数字，SIMD 可以大大减少总体执行时间。

Firedancer关于ED25519 签名验证的工作展示了SIMD在优化复杂计算方面的威力。签名验证过程涉及伽罗华域（Galois Fields）内的算术运算，这可能是计算密集型的。通过利用SIMD指令，Firedancer可以同时对多个数据元素进行这些操作，从而实现显著的性能提升。这些优化将对改善Solana的性能至关重要，Solana已经实现了状态访问的并行化。

任务并行性

任务并行涉及在程序的多个处理单元中并行化不同的任务或操作。当程序由多个可以并发执行的独立任务组成时，这种方法很有用。通过将每个任务分配给单独的处理单元，如CPU核心或GPU，可以减少总体执行时间。

任务并行通常用于程序需要同时执行多个复杂操作的场景。例如，考虑一个需要实时对视频流应用不同滤镜和效果的视频处理应用。任务并行可以将工作负载分布在多个处理单元，而不是使用每个计算单元集体顺序地应用每个滤镜。一个处理单元可以负责应用模糊滤镜，而另一个单元应用色彩校正滤镜，依此类推。通过并行执行这些任务，应用程序可以实现更快的处理并保持流畅的用户体验。

Lagrange的@lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR)利用数据并行和任务并行来有效地并行化和生成大数据集上分布式计算的证明。在映射阶段，输入数据集被划分为更小的块，每个块被一个独立的映射器工作器或机器并行处理（任务并行）。”映射”操作可以在每个映射任务的多个核或处理器上并行化（数据并行）。同样，在规约阶段，每个键关联的值的”规约”操作可以在每个规约任务中并行化（数据并行）。相反，规约任务在多个工作器上并行执行（任务并行）。

通过结合数据并行和任务并行，ZKMR可以在保持零知识保证的情况下，通过递归证明组合实现大规模数据集上复杂计算的高效扩展和性能。

Lagrange在其“Introducing ZK MapReduce”一文中，阐述了如何在ZK中验证任意的MapReduce过程

Lagrange成功实现了在1分钟20秒内为@lagrangelabs/announcing-testnet-euclid-ethereum-s-first-verifiable-database-and-zk-coprocessor-cc4a5595365c">888,888个存储槽的SQL计算生成存储证明，这充分展示了ZKMR的强大能力，以及支持它的任务和数据并行性。此外，Lagrange最近的Reckle Trees论文强调了并行性的必要性，它确保了链上数据的批量证明也可以在𝑂(log𝑛)内计算，与批量大小无关。

并行化共识和执行

虽然这篇文章并未讨论共识，但区块链也可以并行化共识和执行的过程。传统的区块链通常顺序处理交易，在对一个区块的交易（区块N）达成共识后再执行它们。像Monad这样的系统就是并行处理共识和执行阶段的典型例子，它显著提高了执行效率。在网络达成区块N的共识的同时，它并行地执行前一个区块（N-1）的交易。

这种策略确保了计算资源的持续、有效利用，有效减少了空闲时间，提高了网络处理交易的能力。这些改进提高了系统的吞吐量和对抗网络垃圾信息的资本成本。

解释器与减少开销

当智能合约用如Solidity这样的语言编写时，首先被编译成较低级别的字节码。然后，EVM使用解释器执行这个字节码。解释器逐个读取并执行指令，类似于在外语被说出的同时实时进行翻译。Paradigm的最新文章Reth指出，这导致了开销，因为在运行时每个指令都必须单独处理并从字节码转换为机器指令。

Reth 通过引入即时（JIT）编译器来解决EVM的效率问题。这个编译器在执行前不久将字节码翻译成本地机器代码，规避了在运行时通常需要的资源密集型的解释过程。

Reth文章提到，在基于解释器的系统中，EVM执行时间的50%用于JIT理论上可以优化的过程，这暗示了用JIT实现可以使执行速度加倍的可能性。然而，正如Yilong在此演示中指出的，JIT可以显著减少处理特定操作码所需的时间，但可能不会大幅影响总体执行时间。这是因为JIT占用的EVM执行时间的50%中的大部分涉及到“主机” 和 “系统” 操作（第13页），由于它们的非计算性质，这些操作不适合进行JIT优化，如”算术”或”控制”。

虽然解释器可能会限制性能，但它们确实创造了“翻译”的机会，增加了可以利用新虚拟机的代码的范围，降低了开发者使用设计师区块空间的开销。例如，Movement Labs开发了Fractal，使开发者能够在MoveVM上部署他们基于Solidity的合约。Fractal的工作方式是将Solidity编译成包含用EVM操作码表达的指令的中间语言，然后将这些指令映射到它们在MoveVM字节码中的对应物，从而让Solidity合约在MoveVM环境中运行。

专业化和定制化的状态机

定制执行层涉及设计专门针对特定应用优化的状态机。这不仅意味着执行环境可以完全放弃虚拟机的需要，而且还使应用可以根据其特定需求来定制指令集架构（ISA）、数据结构和执行模型。定制一个ISA以适应特定应用的主要性能优势来自于减少将应用的计算模式翻译成传统ISA的通用指令的开销。通用CPU使用基本指令集（如：加、载、分支）来支持运行不同类型的软件。然而，当应用频繁地重复相同的多步操作时，使用简单指令的序列实现这些模式变得效率低下。

例如，数据库应用可能需要不断地遍历树形数据结构，查找条目，更新值和重新平衡树。在普通的CPU上，将这些高级操作映射需要将它们分解为长序列的低级微操作，如负载、存储、分支和算术，在普通硬件上单独执行。相比之下，为数据库定制的ISA可以将这些反复出现的模式合并到优化的更宽指令中，利用专门设计的并行比较电路。”TraverseTree” 指令可能会计算内存地址，加载相关节点，并使用专门为该操作设计的比较键。”UpdateEntry”可能直接从优化的数据库存储布局中获取条目，修改它，并在一个指令中提交新状态。

这消除了从高级操作向简单指令翻译的冗余开销。它还允许硬件以更少但更宽的，明确并行的指令，精确地满足其需求来最优化地执行应用。

LayerN的Nord通过他们特定用例的可验证订单簿来展示专业化执行环境和数据结构的性能优势。LayerN的方法主要是优化将交易放入订单簿数据结构的位置，同时他们的流水线机制被设计为高效地在订单簿的数据树内插入新的订单。通过将数据结构和插入算法定制到订单簿的特定要求，LayerN实现了低延迟订单放置和高吞吐量。

另外，也可以倾向于通用执行环境，使应用可以插入任意可编程的模块以优化其性能。这种方法优先考虑开发者体验而不是原始性能。

Fluent 和CWD采用了一种策略，平衡了优化原始计算性能与提高开发者体验和生态系统兼容性之间的权衡。这种方法的核心是使用WebAssembly（Wasm）作为虚拟机来执行代码。由于Wasm的广泛语言支持和广泛采用程度，Wasm已经成为web开发的首选。

开发者选择使用Wasm而不是本地客户端执行反映了对通用执行环境的广泛可用性和多功能性的战略优先考虑。尽管本地执行（直接在硬件上运行代码，无需虚拟机）可以提供更好的性能，但它限制了跨平台的兼容性，对开发者来说不够方便。相比之下，Wasm确保了在不同平台上的统一和安全的执行环境，尽管没有达到与本地执行相同的原始速度。这种权衡符合Fluent和CWD的设计理念，优先考虑开发者的生产力和更广泛的生态系统集成，而不是最大的性能效率。

特別地，CosmWasm 部署（CWD）不仅采用Wasm执行智能合约，还将其融入到一个更广泛的框架中，以支持区块链操作的复杂性。这个框架丰富了”周边逻辑”，提供了高级账户管理、可定制的gas机制和优化的交易排序。这些功能为开发者提供了一个灵活、高效、安全的开发环境，使开发者可以更轻松地构建出可扩展、复杂的去中心化应用程序（dapps）。

Stackr* 采用了不同的方法，通过结合定制执行环境的优点和传统智能合约平台的灵活性。Stackr允许开发者将应用编码为rollups，使他们可以定义自己的交易排序、执行和配置规则。在Stackr模型中，开发者可以选择最适合其应用需求的ISA、数据结构和执行模型。

来自“介绍Stackr SDK”的Stackr的微型Rollup设计

借助Stackr，开发者可以直接在应用程序的运行时应用状态转换规则，而不受通用虚拟机规则的限制，使他们能够简化指令集以提高效率，并重新定义运行时环境中可以执行的操作集。

这导致了更轻量级、更高效的执行，因为业务逻辑在客户端级别实现，消除了需要昂贵的智能合约调用和验证的必要性。因此，开发者可以在不牺牲性能的情况下，扩展应用程序的配置可能性，包括可以为单个应用程序使用的不同类型的语言、数据结构和签名。

结论

实现最佳执行层性能的途径有多种。

在试图吸引去中心化应用时，状态访问或并行优化中没有一项突出成为执行层之间的技术差异化点。正如我们所探讨的，Solana上的基于资源的并行化的好处可以同样应用到Fuel的UTXO模型上。任何人都可以使用Amazon的通过分片提高水平扩展性的深思熟虑的解决方案来提升执行层性能。

虽然执行层性能是赢得去中心化应用开发者的关键向量，但新的L1s和L2s以改进执行为中心必须在其他变量上进行竞争，包括安全性、互操作性和与现有工具的兼容性。因此，新的互操作性层——从Nebra到Statenet到Polygon的AggLayer——对开发者购买定制的区块空间至关重要，因为他们可以在不牺牲传统的、通用的L1的同步组合性和共享流动性的前提下，构建或购买专用的区块空间。

状态管理和计算效率的改进是相互依赖的。

在设计新执行层的社区中，状态访问的并行化已经成为他们承诺带来性能改进的一个定义性特征。这有充分的理由，因为它可能导致EVM执行的提升5倍。然而，从Monad早期的并行化实验中得到的证据表明，如果不同时开发其他的改进，如异步I/O，那么并行化的作用就被过分强调了。

基于此，我们可以得出结论，只有在改善状态的访问和存储方式时，才能实现计算效率的显著提高。高效的状态管理减少了访问和操纵数据所需的时间和资源，加快了处理速度，减轻了计算负荷。

深入一步，现有的区块链可能会做出路径依赖的选择，这会阻碍他们与重新设计状态管理和更新方式的新区块链设计竞争，因为硬分叉带来的惯性。因此，专门的、模块化的执行层和其他的L1可能能够围绕更有效的状态存储和读写协议的设计选择创建防御性。这些设计决策提供了竞争优势，因为现有的区块链可能在不进行硬分叉的情况下，遇到更新数据库结构的惯性。

归根结底，一个区块空间的价值观影响了执行层的设计空间。

在了解如何改进执行层时，我们现在可以根据两个关键设计选择来描述优化类别的不同：谁在执行交易，以及需要涉及多少节点？解决执行瓶颈的技术对于开发人员来说，根据团队对这些问题的初始答案，差别显著。

一方面，像Solana和Monad这样的单一L1不接受将验证者的角色分离成强大和弱小的节点以提高性能。短期内“接受”状态膨胀并不是可行的解决方案，因此他们依赖于数据库层和块生产引擎的其他组件（如共识）的改进，以弥补广大数目的执行节点被视为网络的关键组件和核心价值。因为这些L1的安全模型依赖于更分散的一组具有较弱硬件要求的验证者的共识，他们的数据需要写入落在磁盘上的数据库，这对于无需许可和最大程度去中心化的区块链来说必然更加便宜。

另一方面，像以太坊及其 L2 的项目正在追求一条路线图，通过集中执行节点中的块构建者，通过欺诈或有效性证明让弱小的验证者节点对其负责。

假设交易和状态转换的集中“执行者”在追求去中心化未来中被认为是可接受的。那么，物理定律表明，那些可以1）不需要多个参与者重新执行交易就能在链上添加区块，2）增加验证者要求以最大化内存计算（并忽略状态膨胀问题），3）减少延迟和共识瓶颈的系统，明显胜过依赖广泛去中心化和节点之间共识的系统。

在寻求可伸缩性和信任最小化之间的平衡时，显然执行层的目标不应该是盲目地优化去中心化，也不必总是完全无需许可的执行。

随着我们开发和实施更广泛的加密工具，如有效性和欺诈证明，我们实际上减少了抵抗审查和维护安全性和活力所必需的节点数量。然而，这个方法涉及到权衡，可能会由于执行者可能集中化，影响审查抗性、排序完整性和活力保证。

正如 Sreeram 所指出的，”最小可行的去中心化”并不意味着”验证应该是无需许可的”，而是应该”正确地被激励”。这意味着在一个受到严密监控的系统中，验证者如果行为不当会面临严重的后果，可以在不需要过度去中心化的情况下维持安全性和活力（感谢Sreeram）。

这样的治理模型已经在实际应用中被测试。例如，像Arbitrum这样的rollups正在探索基于治理或委员会的系统来执行交易排序和领导者选择规则，他们正在考虑使用链上数据的序列器来维护交易排序策略。

尽管有这些进步，但在平衡去中心化与性能之间并没有明确的”帕累托最优边界（pareto optimal frontier）”。

出于意识形态和技术考虑，仍然倾向于去中心化执行节点以验证状态。虽然集中节点可以减少共识开销，升级硬件也可以显著提高性能，但这些优化措施能否吸引开发人员专注于创建抗审查应用程序，以及抗审查在多大程度上仍是行业的核心价值，都还有待观察。

*表示 Archetype 投资组合的公司

声明：

1. 本文转载自[镜子]，转发原标题《Designer Blockspace：执行环境的未来》，所有版权归原作者所有[本杰明·冯克]。若对本次转载有异议，请联系Gate Learn团队，他们会及时处理。

2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。

3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。