IIRC rust vm 将在年底包含在 1.0 版本中
定序器并行化#
我们路线图的第一步是将并行化引入交易执行。这是在昨天在主网上发布的 StarkNet alpha 0.10.2 中引入的。我们现在深入了解什么是并行化。
那么 “交易并行化” 是什么意思呢？天真地，并行执行一个交易块是不可能的，因为不同的交易可能是相互依赖的。这在以下示例中进行了说明。考虑一个包含来自同一用户的三笔交易的区块：
- 交易 A：将 USDC 换成 ETH
- 交易 B：为 NFT 支付 ETH
- 交易 C：USDT 换 BTC
显然，Tx A 必须在 Tx B 之前发生，但 Tx C 完全独立于两者并且可以并行执行。如果每笔交易需要 1 秒来执行，那么通过引入并行化，出块时间可以从 3 秒减少到 2 秒。
问题的症结在于我们事先并不知道交易的依赖关系。实际上，只有当我们从示例中执行事务 B 时，我们才能看到它依赖于事务 A 所做的更改。更正式地说，这种依赖性源于事务 B 从事务 A 写入的存储单元中读取这一事实。我们可以将交易视为形成一个依赖图，其中存在从交易 A 到交易 B 的一条边，当且仅当 A 写入一个由 B 读取的存储单元，因此必须在 B 之前执行。下图显示了一个这种依赖图的示例：
在上面的示例中，每一列都可以并行执行，这是最佳安排（天真地，我们会顺序执行事务 1-9）。
为了克服事先不知道依赖图的事实，我们本着 Aptos Labs 开发的BLOCK-STM的精神，将乐观并行化引入到 StarkNet 定序器中。在这种范式下，我们乐观地尝试并行运行事务并在发现冲突时重新执行。例如，我们可以并行执行图 1 中的交易 1-4，之后才发现 Tx4 依赖于 Tx1。因此，它的执行是无用的（我们相对于运行 Tx1 所针对的相同状态运行它，而我们应该针对应用 Tx1 所产生的状态运行它）。在这种情况下，我们将重新执行 Tx4。
请注意，我们可以在乐观并行化之上添加许多优化。例如，与其天真地等待每次执行结束，我们可以在发现使它无效的依赖项时中止执行。
另一个例子是优化重新执行哪些交易的选择。假设包含图 1 中所有事务的块被送入具有五个 CPU 内核的定序器。首先，我们尝试并行执行交易 1-5。如果完成顺序是 Tx2，Tx3，Tx4，Tx1，最后是 Tx5，那么只有在 Tx4 已经执行完之后，我们才会发现依赖 Tx1→Tx4—— 说明应该重新执行。天真地，我们可能也想重新执行 Tx5，因为考虑到 Tx4 的新执行，它的行为可能会有所不同。然而，我们可以遍历由执行已经终止的交易构建的依赖图，只重新执行依赖于 Tx4 的交易，而不是仅仅重新执行现在无效的 Tx4 之后的所有交易。
Cairo-VM 的新 Rust 实现#
StarkNet 中的智能合约是在 Cairo 中编写的，并在 Cairo-VM 中执行，该规范出现在Cairo 论文中。目前，排序器正在使用 Cairo-VM 的python 实现。为了优化 VM 实现性能，我们发起了用 Rust 重写 VM 的工作。感谢 Lambdaclass 的出色工作，他们现在是 StarkNet 生态系统中一个非常宝贵的团队，这项工作很快就会取得成果。
VM 的 rust 实现cairo-rs现在可以执行原生 Cairo 代码。下一步是处理智能合约的执行和与 pythonic 排序器的集成。一旦与 cairo-rs 集成，音序器的性能有望显着提高。
Rust 中的定序器重新实现#
我们从 python 到 rust 以提高性能的转变不仅限于 Cairo VM。除了上述改进之外，我们还计划用 Rust 从头开始重写音序器。除了 Rust 的内部优势之外，这还为序列器的其他优化提供了机会。举几个例子，我们可以享受 cairo-rs 的好处，而无需 python-rust 通信的开销，我们可以完全重新设计状态的存储和访问方式（今天是基于Patricia-Trie 结构）。
其他问题
1.starknet 测试网的应用有执行轨迹限制 (执行计算步骤)，目前限制在 100 万，后续会开放更高限制。
2.stark 定制化应用 (类似于 starkex) 可开发，但目前还没发现生态项目方使用，因为目前生成证明代码仍然是一个黑匣子，并未开源。要待 starkware 后续开源，这类应用才好进入市场。