• 原文链接：blog.sei.io/research-64-...
• 译者：AI 翻译官，校对：翻译小组
• 本文链接：learnblockchain.cn/article…

特别感谢 Yannis、Gurnoor、Pavel、Ren、Lefteris 和 Evan 的反馈和讨论。

介绍

在这篇文章中，我们将阐明区块链中顺序、并发和并行执行的概念，突出依赖交易和独立交易之间的区别——无论是抽象上还是在以太坊的 EVM 中的具体表现——然后简要考察其他链如何处理并行化。

我们将分析每个区块中独立交易的平均数量，以衡量并行执行带来的潜在性能提升。

最后，我们将考察 Sei 协议的乐观并发控制（OCC）策略，展示它如何通过提供显著的吞吐量提升来扩展 EVM，同时保持简单明了的开发者体验。

依赖交易

如果两个或多个交易触及相同的状态，则它们是依赖的：

• 与相同地址交互
• 修改合约中的相同存储槽
• 存在读 / 写冲突（一个交易读取另一个交易写入的内容）

为了使区块链具有确定性，交易必须顺序执行。这些交易的执行顺序会影响最终状态，必须等待其中一个完成。

例如，考虑一个场景，你的余额为 0：

• tx1: Bob 向你发送 1 ETH
• tx2: 你向我发送 1 ETH

这些交易必须顺序执行。如果它们并行运行并且 tx2 首先执行，则它将无效；你的余额在 tx1 完成之前仍然是 0。

借贷也是如此：我们必须在释放借入资金之前处理抵押品锁定。

在单个 CPU 核心上顺序执行依赖交易

依赖交易的执行顺序很重要。即使有多个 CPU 核心，我们也无法利用它们来提高吞吐量。

然而，并非所有交易都有这样的依赖关系。当交易不与相同状态交互时，我们可以探索更高效的处理策略。这引出了独立交易的概念。

独立交易

如果两个或多个交易不修改（写入）相同的状态，并且一个交易的结果不影响另一个交易，则它们是独立的。

独立交易可以并发或并行执行，因为它们的执行路径不会相互阻塞或依赖。

例如：

• tx1: Bob 向 Alice 发送 1 ETH
• tx2: 我向你发送 1 ETH

这两个交易都不需要等待另一个完成，执行顺序也无关紧要。

具体来说，并发并不一定意味着并行。在只有一个 CPU 核心的情况下，独立交易可以在同一时间段内取得进展，但 CPU 仍然一次处理一个交易（或其一部分），并且在切换交易时必须更改上下文。

你可能会问，为什么我们要关注并发。

I/O 密集型的交易——即与硬盘或网络操作相关的交易——可能会导致延迟。并发确保 CPU 在等待其他交易处理时不会闲置。

换句话说，当 CPU 等待数据包通过慢速互联网电缆传输时，它可以切换到另一个交易，而不是无所事事。

在单个 CPU 核心上并发交易执行与上下文切换

然而，如果大多数交易是 CPU 密集型的——即主要瓶颈在于 CPU——那么由于上下文切换的开销，并发处理实际上可能比顺序处理更慢。

旧电脑只有一个 CPU 核心时，会通过在各种任务之间切换上下文来并发运行：控制鼠标、写入磁盘、从内存读取和显示图形。这创造了并行执行的错觉，但实际上是并发执行，不同任务在同一时间段内取得进展。

上下文切换发生得如此之快，以至于通常不被注意——直到你遇到蓝屏死机。

并行执行是并发执行的一个子集，仅在有两个或多个 CPU 核心时才能发生。大多数现代消费级处理器都配备多个核心。

在多个 CPU 核心上并行交易执行

EVM 目前是顺序的：它一个接一个地运行所有交易，即使其中一些是独立的。

在检查方法论和统计数据之前，让我们回顾一下并发执行的不同实现。

并行执行的实现方法

状态访问并行化

状态访问并行化是一种并行交易执行的方法，旨在在处理之前识别和利用独立交易。该方法的关键特征是通过分析状态访问模式来提前确定交易依赖关系。Solana（显式）和 Sui（隐式）是采用此技术的区块链之一。

主要特征：

• 在执行之前分析交易的状态访问需求
• 调度程序通过绘制潜在冲突来识别可以并行运行的交易
• 专注于状态访问级别的细粒度依赖跟踪

优点：

• 允许创建局部费用市场
• 提供清晰的交易执行调度机制
• 允许更可预测的并行处理

缺点：

• 增加开发者的复杂性
• 需要复杂的依赖跟踪机制
• 可能在交易预处理时引入额外开销

局部费用市场

为了防止一个合约堵塞整个网络（如 2017 年 CryptoKitties 的情况，曾占据所有网络交易的 11%），Solana 使用局部费用市场。这是通过每个区块和每个账户的计算单位（CU）限制实现的：

每区块限制：~48M CUs，动态调整基于网络条件

每账户每区块限制：~12M CUs，这是一个软上限，可以通过支付更高费用来超出

计算单位成本根据每个程序定义，基于交易复杂性。简单转账的 CU 成本较低，而复杂的 DeFi 交易成本较高。

如果一个合约因交易热点达到其软 CU 上限，进一步的交易将被限制，除非支付额外费用以超过该上限。这会产生局部拥堵，而无关的交易仍然可以在未使用的区块空间中进行，没有费用飙升。

Sui 处理此问题的方法是通过共享对象拥堵控制，这是一种限制对单一共享对象的交易速率的机制，防止因热点执行时间过长而导致网络过载。

通过控制在每个检查点中接触拥堵或热门共享对象的交易数量，系统确保一致的处理时间，从而防止延迟。该机制还通过确保支付更高 gas 费用的交易优先包含在检查点中，从而促进交易公平。用户希望更成本高的交易能更快处理。

乐观并发控制

乐观并发控制 (OCC) 是一种并行执行策略，允许交易在假设冲突不太可能频繁发生的情况下继续进行。与严格的顺序处理不同，OCC 允许交易并行运行，然后在执行后验证它们的兼容性。采用此技术的区块链包括 Sei 协议、Aptos 和 Monad。

该过程如下：交易最初在并行中执行。执行后，系统检查是否存在任何冲突或状态不一致。如果检测到冲突，则某些交易将回滚并顺序重新执行。没有冲突的交易将被提交到区块链状态。

特征：

• 假设大多数交易是独立的
• 依赖于执行后的验证
• 允许潜在的显著性能提升

优点：

• 可以显著提高交易吞吐量，因为没有跟踪依赖关系的前期开销
• 当大多数交易是独立时表现良好
• 减少交易处理的初始等待时间

缺点：

• 如果发生冲突，需要重新运行交易，这会导致用户体验不佳。Sei 协议对每个交易的重试总次数进行限制以缓解这一风险。
• 验证和可能的重新执行带来的性能开销
• 由于需要检查和可能回滚交易（在高度依赖交易的生态系统中），速度略慢

基于分片的并行性

分片涉及将区块链的状态和交易集划分为多个独立的“分片”或“子链”。每个分片可以独立处理自己的交易子集，并与其他分片并行处理。

分片将区块链划分为多个子链（分片），每个子链独立处理自己的交易

特征：

• 将网络划分为更小的组（分片）
• 每个分片处理一部分交易
• 允许并行处理

优点：

• 提高可扩展性
• 降低节点硬件需求
• 可能带来更好的去中心化
• 允许特定于分片的优化

缺点：

• 增加系统复杂性
• 跨分片交易开销
• 数据可用性挑战
• 可能减少网络效应
• 难以在现有网络上实现
• 分片不平衡的风险

分片是一种有前景但复杂的扩展解决方案。以太坊 2.0（尚未推出）正在探索这一方案，但面临重大实施挑战。NEAR 实现了 Nightshade，这一分片机制在两方面与以太坊提议的实现不同：

• 提供异步（跨分片）组合性
• 每个区块内进行分片，从而实现跨分片交易的 1-2 秒最终确认

在以太坊虚拟机上识别依赖交易的方法论

软件工程就是权衡。每个区块中的独立交易数量越高，来自并行执行的潜在性能提升就越大。然而，如果大多数交易是依赖的，那么并行执行可能比顺序执行更慢。

关键问题是每个区块的独立交易平均有多少，因此我们可以计算并行执行的潜在性能影响。

地址 / 账户有两种类型：

• EOAs（外部拥有账户），可以修改的部分：
• 余额（通过价值转移和支付给验证者的 gas 进行修改）
• Nonce（每个交易递增）
• 合约：
• 地址与内部存储槽之间的映射
• 用于计算的内部变量
• 余额
• Nonce（合约创建其他合约时递增）
• 内部存储槽（组织为 256 位键值对）
• 代码（部署后不可变）

交易始终由 EOAs 发起。这会递增 EOA 的 nonce 并由于 gas 成本（支付给验证者）而减少其余额，因此 EOA 的状态始终被修改。EOAs 可以：

• 向另一个 EOA 发送 ETH（价值转移）
• 发送者的 EOA 余额减少，nonce 增加
• 接收者的 EOA 余额增加
• 调用合约（合约调用）
• 从自己的存储或另一个合约的存储中读取
• 写入 / 修改自己的存储或另一个合约的状态
• 向 EOAs 或其他合约发送 ETH
• 发送者的 EOA 余额因 gas 而减少，nonce 增加
• 执行合约代码，可以：
• 创建一个新合约
• 发送者的 EOA 余额减少，nonce 增加
• 新合约被部署，并包含其代码和初始存储

合约不能发起交易；它们只能在 EOAs 或其他合约调用其函数时进行响应。当被调用时，它们可以：

• 向 EOA 发送 ETH
• 进行另一个合约调用
• 创建其他合约

此过程可以递归继续，始终由发起的 EOA 支付 gas。

来自外部拥有账户（EOA）的用户交易调用合约 A 中的一个函数，而合约 A 又内部调用合约 B

为了确定交易的依赖性，我们分析交易跟踪以识别基于其对区块链状态修改的潜在交易依赖性。我们使用 callTracer 获取交易的详细执行跟踪，包括内部调用。

对于每笔交易，我们识别四种类型的修改：

1. ERC20 代币转移（通过函数选择器 0xa9059cbb 检测）

2. 向外部拥有账户（EOA）的 ETH 转账

3. 合约函数调用

4. 直接 ETH 转账

如果交易之间存在以下任何冲突，我们认为它们是相互依赖的：

1. 多个交易从同一源地址进行 ETH 转账

2. 多个交易影响同一地址的同一 ERC20 代币余额

3. 多个交易向同一 EOA 转移价值

4. 多个交易在同一合约上调用相同的函数（通过函数选择器识别）

以太坊交易冲突分析

总体统计数据

总区块数：14,400

总交易数：2,490,744

依赖交易数：875,100

每区块平均数

每区块交易数：172.9

每区块依赖交易数：60.77

冲突率

平均区块冲突率：35.15%

每区块依赖与独立以太坊交易的分布

关键发现

对 2,490,744 笔交易和 14,400 个区块的分析显示：

• 35.15% 的交易与其区块中的其他交易存在依赖
• 每个区块平均有 60.77 笔依赖交易，表明并行执行优化的潜在空间很大

* 冲突率指标具有指示性。分析没有考虑跨链依赖。例如，一个以太坊上的智能合约通过一个 oracle 调用另一个区块链上的智能合约。这是一个被忽视的边缘案例，在撰写本文时。

通过 OCC 提升以太坊速度

为了估算并行执行的性能提升，我们可以利用并行计算中的一个著名原则：阿姆达尔法则。该法则表明，从并行化中获得的最大可能加速由以下公式确定：

• P = 可以并行化的任务比例
• N = 并行执行单元的数量（例如，CPU 核心数量）
• (1-P) = 0.35

如果我们假设以太坊的乐观并发控制，并接受 64.9% 的交易可以并行化（即 64.9% 是独立的），那么我们有：

P=0.649

    P=0.649（可以并行化的交易比例）

    N = 并行执行单元的数量（CPU 核心）

    (1−P) = 0.351

当我们代入 N ∈ {4,8,16,32,64} 时：

• 对于 N = 4，Speedup(4) = 1.95x
• 对于 N = 8，Speedup(8) = 2.31x
• 对于 N = 16，Speedup(16) = 2.55x
• 对于 N = 32，Speedup(32) = 2.69x
• 对于 N = 64，Speedup(64) = 2.77x
• 对于 N = 128，Speedup(128) = 2.81x

使用消费者级别的核心数量，你可以看到大约 2 倍的加速。随着更先进硬件的使用，加速可能接近 3 倍。

Sei 协议交易冲突分析

尽管以太坊的分析显示出 35.1% 的直接冲突率，Sei 协议使用乐观并发控制（OCC）系统，通过交易重试来衡量冲突。在 Sei 协议中，我们最好的近似来自 scheduler_incarnations 指标，它衡量交易因冲突需要重新执行的次数。在过去的 24 小时内，我们观察到：

• 平均重试率：2.68（表明交易通常在发生冲突时需要 2-3 次重试）
• 冲突 ≈ 尝试 - 1（初始） ≈ 每个区块 1.68

这些指标表明，虽然 Sei 协议中确实发生冲突，但 OCC 系统通过重试来有效地处理这些冲突。

冲突率越低，OCC 的性能提升越高

随着 Sei 协议的不断增长，以及越来越多的智能合约被部署和使用，我们预计交易冲突将增加，这主要是由于状态交互复杂性的提高。然而，根据我们对以太坊状态访问模式和 Sei 协议当前指标的分析，我们预计即使在网络重负载的情况下，冲突率也不会超过 50%。

这进一步支持了乐观并发控制（OCC）是 Sei 协议合适的架构选择，因为即使在适度的冲突率下，它也能提供显著的性能提升。OCC 相较于其他并行执行方法的关键优势在于它对开发者友好——开发者可以专注于商业逻辑而无需担心复杂的并行执行模式或状态访问规范。当发生冲突时，系统会自动处理重试，通常每次冲突的交易仅需要进行 2-3 次重试。

这使得 Sei 协议成为一个多功能的平台，适用于所有类型的区块链应用，从 DeFi 和游戏到 NFT 和社交平台。开发者的生产力和简洁的系统行为对生态系统的增长至关重要，Sei 通过高效的并行执行保持高吞吐量。

要检查代码并复现结果，请访问 GitHub 仓库：https://github.com/vangelisandr/evm-conflict-rate

参考文献

《以太坊智能合约中的投机并发实证研究》，Vikram Saraph，Maurice Herlihy，2020-03-17

《区块链的操作级并发交易执行》，Haoran Li，Yajin Zhou，Lei Wu，2022-11-17

《区块链中的分片技术》，Vo Truong Trung Hieu，2023-10-19

《Block-STM：通过将排序诅咒转变为性能祝福来扩展区块链执行》，Rati Gelashvili，Alexander Spiegelman，Zhuolun Xiang，George Danezis，Zekun Li，Dahlia Malkhi，Yu Xia，Runtian Zhou，2022-08-25

加入 Sei 研究计划

我们邀请开发者、研究人员和社区成员加入我们的使命。这是一个开放的邀请，旨在通过开源协作构建一个更具可扩展性的区块链基础设施。查看 Sei 协议的 文档，并探索 Sei 基金会的资助机会（Sei 创作者基金 ，日本生态系统基金）。请与我们联系 - collaborate[at]seiresearch[dot]io

我是 AI 翻译官，为大家转译优秀英文文章，如有翻译不通的地方，在这里修改，还请包涵～

登链社区是一个 Web3 开发者社区，通过构建高质量技术内容平台和线下空间，助力开发者成为更好的 Web3 Builder。

• 登链社区网站 : learnblockchain.cn

• 开发者技能认证 : decert.me

• B 站 : space.bilibili.com/581611011

• YouTube : www.youtube.com/@upchain