Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

执行

Stable 使用 Block-STM 并发执行 EVM 事务，同时保持确定性的最终状态。预编译将执行层连接到 Stable SDK 模块。

Stable EVM

Stable EVM

Stable EVM 是 Stable 的以太坊兼容执行层。现有的以太坊工具和钱包（如 MetaMask）与 Stable 的交互方式保持不变。Stable EVM 将 EVM 的开发者体验与 Stable SDK 的模块化基础设施相结合。

为了弥合 Stable EVM 和 Stable SDK 之间的鸿沟，Stable EVM 引入了一组预编译。这些预编译将原生的 Stable SDK 模块功能暴露给 EVM 智能合约，使它们能够安全、原子地调用核心链逻辑。智能合约随后可以执行特权操作，例如代币转移、质押或参与治理。

v1.8.0 中的乐观并行执行

历史上，区块链系统一直依赖顺序执行，即每个事务依次处理，以确保所有节点的状态确定性。虽然这种设计保证了一致性，但它严重限制了吞吐量和可扩展性，尤其是在现代区块链旨在支持每秒数万笔事务的情况下。

Stable v1.8.0 通过 Block-STM 运行乐观并行执行 (OPE)。事务在 CPU 核心上并发执行，同时固定的块内顺序保持最终状态的确定性。

Block-STM 的工作原理

Block-STM 使用乐观并发控制机制：事务首先在假设它们不会冲突的情况下并行执行。然后，在验证阶段，检测并处理任何冲突，通过重新执行来解决。该过程依赖于以下五种关键技术：

1. 多版本内存结构

Block-STM 存储每个内存键的多个版本：

  • 每个事务读取先前事务提交的最新版本。
  • 在执行期间，读取和写入都进行版本控制。
  • 随后，在验证期间，检查这些版本的一致性以检测冲突。
2. 基于读集/写集的验证
  • 在执行期间，每个事务都会将它读取的键和版本记录在读集中。
  • 执行结束时，它将其写集记录到多版本内存中。
  • 在验证期间，如果另一个事务修改了读集中的任何键，则该事务被标记为冲突。然后它被中止并以递增的化身号重新执行。
3. 使用 ESTIMATE 标记快速检测冲突
  • 当事务失败时，其写集会用 ESTIMATE 标志标记。
  • 如果另一个事务读取了 ESTIMATE 标记的值，它会立即停止并等待重新执行（由 READ_ERROR 触发）。
  • 这有助于通过快速识别依赖关系来减少开销，而无需重新执行整个事务集。
4. 预设事务顺序
  • 块中的所有事务都按照预设的确定性顺序执行。
  • 验证和提交阶段也遵循相同的顺序。
  • 这确保了即使是并行执行，所有节点也能达到相同的最终状态。
5. 协作调度器
  • 协作调度器以线程安全的方式在执行和验证工作程序之间分配任务。
  • 它优先处理索引较低的事务，以加速早期提交并最大程度地减少重新执行。
  • 调度器管理事务化身，以进行重复尝试，直到它们成功提交。

Block-STM 的主要优势

  • 无锁并行：通过利用 MVCC（多版本并发控制），Block-STM 允许多个事务并发读写，而无需互斥锁。冲突只在执行后检查，从而在初始处理阶段实现最大吞吐量。
  • 通过 ESTIMATE 标记实现最小开销：失败的事务会用 ESTIMATE 标记其写集，指示依赖事务提前暂停，避免浪费执行。这会加快有效执行路径的收敛。
  • 高效调度和优先提交：使用协作调度器，系统通过首先提交索引较低的事务来最大程度地减少重试。这提高了整体吞吐量并缩短了执行周期。
  • 确定性和共识兼容性：因为每个事务都遵循固定的顺序，即使是重新执行的事务最终也会以相同的顺序提交。这确保了所有节点之间安全且确定性的状态一致性，即使在并行化环境中也能保持共识完整性。

Stable 上的 OPE

Stable 上的乐观并行执行

Stable 将 OPE 与乐观块处理 (OBP) 结合使用。这两种优化解决了不同的工作。

关于 OBP

  • OBP 与并行性无关，而是与执行时间有关。
  • 在 ProcessProposal 阶段，Stable 在块被传播到其他节点时预先执行这些块。
  • 生成的状态被缓存在内存中，并在 FinalizeBlock 期间重用，从而节省时间并减少重复计算。

OPE 通过使用多个 CPU 核心来减少执行时间。OBP 避免在提案处理和最终确定过程中两次执行相同的块。

提交后重新检查

块提交后，CometBFT 通常会重新检查内存池中仍在等待的每个事务。这种重复的工作会消耗节点 31–34% 的 CPU。

Stable v1.8.0 包含选择性 RecheckTx。应用程序返回块的状态更改增量，节点仅重新检查受影响账户的事务。CometBFT 检测应用程序支持，并在选择性重新检查不可用时回退到完全重新检查。

在最佳情况基准测试中，有 10,000 个来自唯一发送者的待处理事务，吞吐量从 700 提高到 1,400 TPS。更典型的工作负载预计提高 1.5–1.7 倍。

此处节省的 CPU 可供 OPE 工作人员使用。MemIAVL 消除了可能限制这些执行增益的存储瓶颈。

未来路线图：StableVM++

虽然乐观并行执行 (OPE) 和乐观块处理 (OBP) 等工作侧重于优化如何并发执行多个事务，但还有另一个重要的性能杠杆：每个事务的处理效率。

Stable 目前正在探索替代 EVM 实现以提高执行速度。在候选方案中，EVMONE（用 C++ 编写的高性能 EVM）作为替代现有基于 Go 的 EVM 的有力竞争者脱颖而出。根据理论基准测试，预计这种切换将使 EVM 执行性能提高 6 倍。

下一步

  • 存储 (StableDB)：了解分离的状态提交如何在不阻塞磁盘 I/O 的情况下支持执行。
  • 高性能 RPC：了解将执行结果呈现给客户端的分路径 RPC。
  • 以太坊兼容性：使用标准 EVM 工具将现有合约移植到 Stable。
  • 网络升级：查看 v1.8.0 发布范围和激活详情。