跳转到内容
Aptos 文档

执行

在 Aptos 上，执行是验证者将有序交易区块应用到账本状态的步骤。输出必须是确定性的：从同一状态和同一区块出发的诚实验证者必须产生相同的写集。

超过三分之二的投票权必须对该结果达成一致，区块才能提交。参见 BFT 和共识。

执行速度体现为出块时间。Aptos 不等待固定槽位时钟；网络允许时就会提议下一个区块。主网出块时间通常为数十毫秒。参见区块。

为何需要并行执行？

Section titled “为何需要并行执行？”
flowchart TB
  subgraph sequential [顺序执行]
    direction LR
    S1[交易 1] --> S2[交易 2] --> S3[交易 3]
  end
  subgraph staticp [静态并行]
    direction LR
    D1[声明访问列表] --> D2[调度互不重叠的交易]
  end
  subgraph dynamicp [动态并行]
    direction LR
    P1[推测执行] --> P2[检测冲突] --> P3[按预设顺序重执行]
  end

按顺序逐笔执行区块很简单，但无法扩展。耗时长的交易会堵住后面的所有交易，负载升高时延迟上升、吞吐下降。

并行执行同时运行多笔交易。难点是冲突：读写同一资源的两笔交易，不能按错误顺序各自单独提交。

静态并行

Section titled “静态并行”

静态并行要求开发者（或运行时根据注解）声明每笔交易将访问哪些数据。调度器随后并行运行互不重叠的交易。

这把负担转给了应用作者。声明的集合往往宽于交易实际使用的数据，于是本可并行的工作被强制串行。

动态并行

Section titled “动态并行”

动态并行在运行时发现冲突。交易先推测执行；若两笔冲突，引擎重执行较后的一笔。已提交结果仍必须与按预设共识顺序执行该区块一致。

开发者不必声明访问列表。他们编写普通 Move，引擎会并行化互不冲突的部分。

Block-STM

Section titled “Block-STM”

Aptos 用 Block-STM 执行区块。这是一个多线程、内存中的引擎，将软件事务内存与协作式调度器结合。它以共识顺序为串行基准，并行执行交易，并只重执行因冲突而中止的交易。

Block-STM 是 Aptos Labs 最初构建的动态并行引擎。Polygon、Sei、Starknet 等链也采用了相同思路。

了解更多：