这是一个探索性的提案，旨在提出一种确定性地识别 L2 上的排序器的方法，以便将交易路由到这些排序器，从而促进 L2 之间的通用同步可组合性。这种方法使用以太坊基础层作为通用且可信中立的排序器选择机制，旨在作为基于排序的备选方案，以应对某些 L2 可能不适合完全采用基于排序的情况。这很大程度上是一个初步提案，旨在征求一般的反馈、讨论和辩论。
提案
LimeChain 关于 Vanilla Based Sequencing 的提案描述了在 L2 上选择排序器的两种方法：主要选择，即当前 L1 提议者已选择成为 rollup 的 L2 排序器；以及备用选择，即当前 L1 提议者没有选择成为 rollup 的 L2 排序器，因此需要其他某种方法来选择 L2 排序器。
在 备用选择机制 中，L2 从其他选择加入的 L1 提议者中随机选择一个 L1 提议者作为 L2 排序器。这种方法可以很好地工作，但限制了 rollup 之间同步可组合性的可能性。一个同时也是多个 rollup 上指定排序器的 L1 提议者能够保证交易捆绑包将在各自的 rollup 上原子地执行。在备用选择机制中，不再有单个 L1 提议者同时为两个或多个 rollup 排序，而是有分离且不同的 L1 提议者，并且不再可能保证交易的原子执行。
为了应对这一挑战，我建议探索在 L1 上使用确定性排序器选择函数的想法，该函数可供任何 rollup 使用。这将允许钱包或预确认网关识别何时在哪个 rollup 上选择哪些排序器，从而允许它们相应地路由预确认请求。
总体的想法是，预确认网关可以接受一个交易捆绑包，通常是要在两个不同的 rollup 上执行的一对交易，并且可以将请求路由到各自 rollup 上的相关排序器，从而为用户获得预确认承诺。
需求
-
L2 上的排序器将需要通过 L1 上的一些中央注册表进行记录（可能是 L1 预确认注册表 的扩展），并且需要能够发布预确认。
-
预确认可能需要分两轮而不是一轮来确认。第一个请求是锁定预确认（在非常短的时间范围内，大约 100 毫秒），第二个请求是确认。这将允许预确认网关（或钱包）获得一个承诺，即各自 rollup 上的两个排序器都将发布预确认承诺，并且当排序器收到来自两者的承诺时，它可以确认预确认请求并收到来自两者的预确认承诺。这里的术语有点令人困惑，需要仔细考虑。或者，另一种可能不那么复杂但也安全性较低的方法是允许预确认网关仅在收到来自一个 L2 排序器的预确认承诺但未收到来自两个 L2 排序器的预确认承诺时取消预确认。
-
L1 上的智能合约中有一个确定性函数，可用于识别何时在哪个 rollup 上选择哪个 L2 排序器。这可以利用 prevrandao 通过 block.difficulty 提供前瞻性，L2 使用该前瞻性在 L2 上选择排序器。这可以是一个简单的函数，充当 PRF，它接受以 slot 为单位测量的前瞻大小 nn，以及对应于 L2 排序器数量的有界范围 rr，并引用 block.difficulty 来返回大小为 nn 的随机排序器 id 列表，该列表在范围 rr 内。
-
可能需要一些抵押品来激励 L2 排序器兑现预确认请求，并保持 L1 注册表的更新，尽管最后一点可能难以在 L2 之间协调，并且需要更多的思考。
理由
在有足够多的 L1 提议者选择加入基于排序之前，L2 将在开始时更频繁地采用备用排序器选择。
我们需要至少 20% 的以太坊验证者集合选择加入基于排序，以便每个 epoch 至少有 1 个提议者。此外，这些提议者需要选择成为许多 rollup 的排序器（假设有足够多的 rollup 在其排序器设计中为此做准备 - 待定）。所有这些都发生在众多 AVS 的背景下，这些 AVS 可以为提议者提供更具经济吸引力的选择方案。
假设我们确实达到了以太坊验证者集合中 20% 的人选择加入基于排序的所需阈值（大约 20 万个验证者），那么根据去中心化 L2 的设计，它们可能无法支持这么多排序器。对于可能寻求实施某种使用具有提议者选择机制的验证者集合的共识协议的 L2 来说，支持 20 万个验证者可能是不切实际的。在这种情况下，拥有一个可信中立的排序器选择机制将是有帮助的。
此外，在新的或较小的 rollup 构建足够多的 L1 提议者份额（这些提议者选择加入成为其 rollup 的排序器）之前，它们很可能会继续采用备用选择机制。同样，在这种情况下，可信中立排序器选择可能具有吸引力。
备用选择本身不支持通用同步可组合性，但是以一种可信中立的方式（通过使用 L1）跨 rollup 同步排序器选择可以促进 USC。
风险和权衡
用户将需要信任他们寻求原子执行交易预确认的各个 L2 的加密经济保证。即使 L2 排序器也是 L1 验证者（请注意，他们不需要是），用户仍然需要依赖 L2 的安全性。
在 vanilla based sequencing 方法的主要选择方法下，这些安全保证在某种程度上有所提高，因为我们处理的是两个 rollup 的单个 L1 提议者，因此他们提供跨 L2 原子交易执行保证的能力得到提高。
假设 L1 提议者将来自每个 rollup 的数据发布到 L1，那么我们还可以从这些交易的主观终结性中受益，因此我们可以在一个 slot 内知道各个交易是否已被包含。然而，这也是一个强假设，因为它取决于 L2 上的交易量，大多数 rollup 会等到它们有足够的交易来完全用压缩数据填充一个 blob，这可能不会在一个 L1 slot 内发生。因此，同样，这又回到了用户依赖 L2 本身的加密经济安全。
当然，这种方法将需要 L2 的一些支持，因为它们需要实施备用排序器选择，但基于排序总体上也是如此。
如上面的需求部分所述，主要的权衡是管理原子执行保证的复杂性增加。这可能需要在 L2 排序器和预确认网关（或用户的钱包）之间建立一个锁定确认机制，预确认网关要求排序器将预确认保留大约一秒钟，然后确认他们想要继续进行预确认。
未决问题
我不清楚如何激励 L2 或 L2 排序器保持注册表的更新。如果 L2 排序器停止作为 L2 排序器参与，则注册表将需要反映这一点。mteam 关于 Credibly Neutral Preconfirmation Collateral 的提案解决了这一挑战，并且可能可以使用相同的注册表用于 L2 排序器，但需要对这一点进行探索。使用单独的注册表可能会因管理基于排序的提议者的多个注册而导致生态系统膨胀并产生冗余开销。
如果 L1 上的预确认网关用于将交易路由到 L2 上的排序器，那么生态系统可能会产生可以理解的担忧。这将导致整个生态系统中更加的中心化，可能只有 2 或 3 个预确认网关在 L1 以及许多 L2 上路由交易。可以通过在每个 L2 上通过独立的网关路由到各个排序器来改进这一点，但还需要进一步探索。
就目前而言，该提案无法承受 L1 重组。排序器选择机制如何不受 L1 重组的影响是一个悬而未决的问题。
欢迎所有问题、反馈和批评。
