StarkNet性能路线图：如何攻克排序器难题？

路线图中的并行化、Rust 等改进，都是为接下来 StarkNet 提升 TPS 所做的准备。

rollups 的有效性不受限于L1的吞吐量，使得 L2 的 TPS 可以很高。

在 StarkNet 的性能路线图中，解决了系统中的一个关键因素——排序器。

性能的改进主要有以下几点：

• 排序器（Sequencer）的并行化

• 为 Cairo 虚拟机（Cairo-VM）提供 Rust 语境下的实现

• 在 Rust 语境下的排序器

• 证明者（Provers）并不是瓶颈，他们可以处理比现在更多的东西。

简介

大约一年前，StarkNet Alpha 正式上线了以太坊主网，这时，我们将重心放在了功能的构建上，现在，我们决定将重点转移到提高性能之上，并计划通过一系列的步骤来提高 StarkNet 上的用户体验。

在这篇文章中，我将解释为什么有很多优化措施只适用于有效性汇总（Validity Rollups），并分享 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 证明，而且这种验证需要的计算资源呈指数级下降。重点是，链上全节点状态的验证同步没有涉及到执行；一个节点可以从另

推荐阅读