Rollup序列生成器的去中心化：重新审视,我们在Optimism治理论坛上进行了简短的讨论。这不是我经常讨论的话题，因为它并不是那么重要——经过实战验证的证明和合约升级能力才更为重要。

首先，与整体化的L1不同，你只需要一个活跃的诚实的序列生成器。随着L1升级到PBS类型机制，它们的构建者也将具备这种诚实少数派的要求——同样适用于Rollup。无论如何，请不要将L1验证者与Rollup序列生成器混淆——与L1构建者相等的关系更为合适。

许多应用Rollup或较小社区、非金融类Rollup等最适合使用单个序列生成器。对于上述类型的Rollup，序列生成器实际上没有太大的动机离线或短期进行审查——这样做将损害他们的应用程序或社区，并且他们只会失去用户而转向竞争对手。然而，由于无能而不是恶意（证明已经解决了这个问题），序列生成器可能会失败。

在此基础上，我们可以通过一种储备序列生成器的机制进行扩展。在大多数情况下，主要的序列生成器处理所有排序任务。但是如果主要序列生成器离线或审查（参见：crLists），则可以使用另一个序列生成器。选择这些储备序列生成器有很多方法，甚至可以是自由选择自序列，但最好的选择是由治理简单地列入白名单的几个序列生成器。

以上系统的缺点可能是序列生成器切换之间的短暂停机时间，以及需要某种机制来处理被逆转的交易。再次强调，对于某些类型的用例，这并不是一个大问题。然而，对于金融应用等应用程序来说，这是不可接受的。

顺便说一句，所有的序列生成器都可以适用可惩罚的债券和惩罚机制。

像Arbitrum One、zkSync Era或OP Mainnet这样的通用Rollup及其金融生态系统具有更严格的要求。目前，Arbitrum One确实具有储备序列生成器的机制，但存在延迟。从长远来看，对于这些类型的链来说，单个序列生成器是不够的。

下一步是治理选举序列生成器集合。像Steem和EOS以及后来的Tron这样的Graphene衍生链设立了有趣的先例——它们拥有20-28个验证者和一长串的储备验证者。对于一个L1链来说，这是不可靠的，但对于一个Rollup来说，这已经足够了。我们还有来自Lido的大量数据——可靠、表现良好、非恶意的运营商是不会短缺的。因此，治理选举20个序列生成器，并在一段时间内轮换它们，或者通过某种最小BFT共识（尽管效率低于简单轮换，但可能是像Arbitrum One这样的大链的要求）使它们始终处于活跃状态。还可以有其他的储备序列生成器，虽然我不确定实际上需要多少个——也许再多20个？随着时间的推移，随着历史数据的积累，这个数量可以逐渐减少。

对于没有治理的Rollup来说，还可以有一个中间步骤，即运营主要序列生成器的人可以外包给多个序列生成器。

我仍然偏爱两年前提到的选项——算法式的序列生成器选择。开始时，治理选举一个起始集合，但从那以后，它将根据客观表现自动选择。拥有最高正常运行时间、最佳交易包含等等的序列生成器将获得更频繁的轮换。这还将激励序列生成器运营商继续改进其流程，而不是依靠某些鲸鱼的投票选出。正如我在两年前提到的，肯定存在一些主观标准——例如，序列生成器操作者可能非常高效，但却沉迷于各种不光彩的MEV（最大化营利值）——对于这种情况可以进行治理覆盖。另一个潜在的场景是一个操作者构建了一种更高效的专有序列生成器客户端。这将取决于治理的决定——有些Rollup可能对MEV不太在意，而其他的可能对此要求更严格。无论哪种方式，我相信这种方法将最大程度地减少治理，并且只需要在最坏情况下进行干预。

这与序列生成器拍卖有什么不同？区别在于系统可能会选择更高质量的序列生成器而不是更有利可图的序列生成器。再次强调，这取决于Rollup的治理，以确定这些特征的重要性。

与权益证明相比，权益证明中始终进行的是一个富豪选举。而在上述情况下，大部分时间都是根据功绩选择的，但在最坏情况下会回到富豪选举。