排序归并

StarkNet性能路线图：如何解决排序器难题？

路线图并行化、Rust等改进为下一个StarkNet提高TPS做好了准备。

rollups的有效性不限于L1的吞吐量，并且可以提高L2的TPS。

starknet的性能路线图解决了作为系统关键元素之一的——可编程控制器。

性能的改善主要有以下几点。

可编程控制器Sequencer的并行化

为Cairo虚拟机Cairo-VM提供Rust上下文下的实现

rust上下文中的排序

证明方Provers现在可以处理更多的东西，而不是瓶颈。

个人资料

约一年前，StarkNet Alpha正式连接到以太网主机时，我们将重点关注功能的构建，目前将重点关注性能的提高，并计划通过一系列步骤改善StarkNet上的用户体验。

这篇文章解释了为什么有很多只适用于有效性摘要的优化措施，并与StarkNet分享了实施这些措施的计划和步骤，一些计划已经通过StarkNet Alpha 0.10.2实现。 在讨论具体细节之前，让我们先回顾一下限制链性能的理由。

块限制： Validity Rollups和L1一种提高块链可扩展性和TPS的方法是在解除块限制(例如，GAS和块大小限制)的同时保持块生成时间恒定。 这需要块生产者(L1上的验证器)、L2的排序器)为了提供更高效的服务，需要更高效地运行这些组件。 因此，详细内容将侧重于后面提到的StarkNet排序器的优化。

这里有个问题中选择所需的族。 为什么排序器优化只对Validity Rollups有效呢？ 换句话说，为什么不能在L1中用同样的方法进行改进，使“有效性聚合”(Validity Rollups )没有复杂性呢？ 在下一节中回答这样的问题。

为什么L1的吞吐量有限

当L1的块限制解除时，链的高吞吐量导致链上块的高增长率，不同的节点是最新的全部需要添加更多的完整节点。 另外，由于L1所有节点必须记录所有的历史记录，块大小的大幅增加给所有节点运营者带来了很大的压力，部分所有节点由于机器性能落后而退出系统，结果导致，能够运营全节点的是比较大的实体，最终用户无法用不可信的姿态验证状态，加入网络。

这也意味着在某种意义上是对L1吞吐量的限制实现了真正的中心化和相对安全的网络系统。

上述问题为什么不出现在Validity Rollups之上？

仅在考虑全节点问题时可以看到Validity Rollups的好处。 通常，一个L1完整节点需要重新运行整个链的历史记录以确保当前状态的准确性，而StarkNet节点只需验证STARK证书而且，该验证所需的计算资源呈指数减少。 重要的是，链上所有节点状态的验证同步不参与执行； 一个节点只需通过STARK证明验证其状态是否有效，就可以从其他所有节点接收当前状态的转储。 这样可以在不增加节点总数的情况下提高网络吞吐量。

因此，在L2中可以通过可编程控制器的优化来提高系统整体的性能，但这在L1中无法实现。

StarkNet未来性能路线图

本节介绍当前用于优化StarkNet排序器的计划。

可编程控制器并行化

性能路线图的第一步是在事务的执行中引入并行化。 此建议已在StarkNet alpha 0.10.2中正式引入。 这个版本于11月29日在以太网上发布。 现在让我们详细讨论一下什么是并行化。

一般来说，不能同时执行多个交易块，因为不同的交易可能是相互依赖的。 以下示例说明了一个包含来自同一用户的三个事务的块。

Tx A (事务a，以下将相同() USDC更换为ETH

Tx C )将向某个NFT支付eth费用的[ xy 002 ] [ xy001 ] tx c ) USDT更换为BTC [ xy 002 ] [ xy001 ]明显交易可以并行执行。 如果每个事务需要在1秒钟内执行，则引入并行处理可以将块生产时间从3秒减少到2秒。

问题的关键是事先不知道不同交易之间的依赖性。 在实践中，只有在执行了示例Tx B的情况下，才能看到这是依赖于Tx A进行的更改。 更准确地说，该依赖性是由从写入Tx A的存储单元读出Tx B的动作引起的。 可以将不同的Tx视为从事务a到事务b的边缘所在的依赖关系图。 b只有在a写入由b读取的存储单元时才能执行。 下图显示了这种依赖关系。

在

上面的示例中，每列都可以并行执行。

为了克服无法预先确定的不同事务之间的依赖关系，Aptos Labs推出了BLOCK-STM，将OP并行化引入StarkNet排序器。 在此模式下，乐观地并行处理事务，并在发现冲突时重新执行。 例如，在上述例子的图中另外，我们可以并行地执行TX1-4，但是由于在之后发现Tx 4依赖于Tx1，所以这次的执行是无效的(应该在Tx1执行之后执行Tx 4 )，在这种情况下，再次执行Tx 4。

请注意，在上述乐观并行化的基础上，增加一些优化措施。 例如，如果找到要禁用运行结果的依赖关系，则可以中止运行，而不是等待每个运行的结束。

优化的另一个示例是选择要重新执行的事务。 假设上述示例图中包含所有事务的块被发送到具有5个CPU的序列器。 首先，让我们并行运行tx 1-5。 按Tx2、Tx3、Tx4、Tx1的顺序完成后，最后为Tx5在中，在Tx4已经运行之后发现依赖关系Tx1Tx4。 这表明应该重新执行。 直观上，考虑到Tx4的重新运行，Tx5也必须重新运行，但可以遍历由已完成执行的事务构建的依赖关系图，只重新运行依赖于Tx4的事务，而不是重新运行Tx4失效后的所有事务。 在

Rust上下文中实现Cairo-VM [ xy 002 ] [ xy001 ] stark net中的智能约定是用cairo语言编写的并在Cairo-VM虚拟机上运行。 目前，可编程控制器使用python语言在Cairo-VM上运行。 为了优化虚拟机实施性能，我们以前开始在Rust中重写Cairo-VM虚拟机。

目前，Cairo-rs可以执行本机cairo码，下一步是处理智能合约的执行和与pythonic可编程控制器的集成，与Cairo-rs集成时，可编程控制器

Rust上下文中的排序器

通过从python迁移到rust来提高网络性能，不仅是Cairo-VM，StarkNet也在rust中改写了排序器相关的代码。 这除了Rust的内部优点外，还可以进行可编程控制器的其他优化。 例如，可以聚合cairo-rs的优点，而不需要python-rust通信开销，或者完全重新设计状态存储和访问方法。

证明方[provers]

在整篇文章中没有提到有效性摘要Validity Rollups的中心要素之一——证明方[provers]。 作为体系结构中最复杂的组件，证明方(Provers )是瓶颈，也是优化点。 但是，目前StarkNet的瓶颈是更“标准”的组件，可以在证明中包含当前测试网/主网上的更多交易，特别是对于递归证明。 事实上StarkNet区块与StarkEx交易一起获得了有效的市场证明，后者有时会有数十万NFT的铸造事件。

总之，并行化、Rust等的改善为下一个StarkNet提高TPS做准备。