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 EVM

Stable EVM

Stable EVM 是 Stable 的以太坊兼容执行层。现有的以太坊工具和钱包，如 MetaMask，可以直接与 Stable 交互而无需修改。Stable EVM 结合了 EVM 的开发者体验和 Stable SDK 的模块化基础设施。

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

v1.4.0 中的乐观并行执行

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

Stable v1.4.0 通过 Block-STM 引入了乐观并行执行（Optimistic Parallel Execution, OPE）。事务在 CPU 核心之间并发执行，而固定的块内顺序保持最终状态的确定性。

Block-STM 如何工作

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

1. 多版本内存结构

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

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

Block-STM 的主要优势

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

Stable 上的 OPE

Optimistic Parallel Execution on Stable

Stable 将 OPE 与**乐观区块处理（Optimistic Block Processing, OBP）**相结合。这两种优化处理不同的工作。

关于 OBP

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

OPE 通过使用多个 CPU 核心来缩短执行时间。OBP 避免了在提案处理和最终确定过程中两次执行同一个区块。

提交后重新检查

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

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

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

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

未来路线图：StableVM++

尽管像乐观并行执行（OPE）和乐观区块处理（OBP）这样的工作着重于优化多个事务并发执行的方式，但还有另一个重要的性能杠杆：单个事务的处理效率。

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

接下来去哪里

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