来源：@ballsyalchemist X推文
作者：@ballsyalchemist
编译：Techub News-Gene
摘要：@ballsyalchemist针对@aztecnetwork中的部分提案进行分析并提出自己的优化建议。
证明者协调是大多数 ZK L2 最终都会面临的问题，而 @aztecnetwork一直在努力与其社区合作，致力于设计一种既能提供强大的抗审查特性又能提供有效性的解决方案。
今天，我想重点介绍并讨论一些拟议的解决方案及其背后的考虑因素！（非常精彩，敬请欣赏）
10 月 12 日 ，@cooper_kunz发布了一份征求建议书，为 Aztec 征集去中心化证明器协调机制的设计提出建议：
https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397
随后，大约有 7 个以上的提案涌现出来。在此，我将挑选一些有趣的提案，剖析其中的假设、考虑因素和可能的修改之处（每个提案都会省略一些细节，否则就太长了哈哈）。
1. Staking Proving Network（合作性模型）
创作者：@jaosef & @smpalladino
https://forum.aztec.network/t/proposal-staking-proving-network-for-fernet/2439
概述：
a. 验证委员会将从 VRF 与排序器相反的一端进行选择（Fernet 使用 VRF 超过 RANDAO 值来从库中选择排序器，即 VRF 值最高的排序器等）。因此，同样的 VRF 也将用于验证程序的选择。
b. 证明委员会与定序器来自同一个节点池，这意味着定序器的硬件要求可能会高到足以同时进行证明。
c. 作为 L2s p2p 网络的一部分，所有节点都有完全的状态访问权限。
d. 在证明阶段，通过 VRF 选出的证明者委员会将根据建议的证明树（本质上是根据 VRF 委托给不同证明者的证明工作树）进行证明，并在证明期结束前将证明交付给排序者。
请注意，证明节点 N 的数量为 N= Const. X * 任务所需的最小证明者数量。这样，证明者委员会将有 X 个冗余因子，以更好地保证有效性。
e. 这将需要对有效载荷的及时性达成共识，以防止序列器的数据扣留攻击。基本上，超过 2/3 的证明者必须通过 p2p 证明他们确实从排序器那里收到了有效载荷，从而可以按预期构建证明。
讨论与修改：
这里的关键优势之一是增加了冗余（但也增加了有效性成本），以及由于对有效载荷及时性达成共识而具有的抗审查能力。这种共识可以防止排序者和证明者的恶意攻击（证明者即使收到了数据，也无法提供证明）。随着有效性和 CR 特性的增加，协议的协调和通信开销也变得复杂起来。在 Aztec 10 分钟左右的时间限制内，这可能不是一个大问题，但如果必须及时达成共识，由于通信延迟，肯定会限制证明者网络的规模。 另一个考虑因素是 N 的大小。
如果 N 的大小 = 证明者总数，那么为了对证明的交付有信心，必须有超过多数（2/3）的证明者证明有效载荷的及时性。但是，如果我们限制 N 小于证明者总数的 2/3，情况可能就不是这样了。因为在这种情况下，即使有 1/3 的证明者没有证明，N 中足够高的 X（冗余）也能提供很高的证明交付概率。这里要注意的是，如果证明人的证明次数没有达到 2/3，证明就无法交付，那么排序器就会被砍掉。此外，这种关于有效载荷及时性的共识可以作为对 txs 排序的软承诺，这样就可以在选择下一个排序器时进行并行证明。
我们还可以启用背景选项，即采用竞争证明模式，在证明协调失败的情况下，外部证明者参与帮助生成证明。
还可以修改奖励分配，使被选中的证明者提交证明的速度越快，从奖励池中获得的奖励权重就越高，从而奖励延迟游戏。
2. Sidecar Proving（竞争性模型）
创作者：@cooper_kunz
https://forum.aztec.network/t/proposal-prover-coordination-sidecar/2428
概述：
上图说明了该模型总体流程（为我省去了很多字哈哈哈）
a. 本方案将证明协调的嵌入最小化，将证明者存款（proverDeposits）用于序列器对证明者的承诺。从本质上讲，序列发生器可以通过存款对区块做出承诺，从而获得证明者的来源。如果没有在时间窗口内交付证明，则可以削减押金。
b. 本设计旨在实现证明者拍卖机制的协议外实施，例如，序列发生器可以执行第一价格拍卖，以收集证明者的出价，其出价将转入证明者存款（proverDeposits）。
c. 奖励主要归排序器和证明者（在 L1 上提交证明的地址）所有。
讨论和修改：
本建议将大量协调任务交给排序器自行解决。这也意味着审查风险和扣押攻击可能会变得更容易执行。
就审查而言，一个验证者（假设排序器将其外包）可以出最高价，但直到插槽结束时才出价，这可能会导致排序器错过一个插槽。因此，有必要提供备用方案，例如在证明者选择机制（协议外）中增加冗余，并可能在不同证明者之间增加延迟竞争，以激励快速验证交付。这可以通过选择同时为证明者押金做出贡献的前 N 位竞标者来实现。
我们可以设计一个公式，通过以下方式分配奖励：
证明者 A 的奖励 = (出价/总出价) * (((A 的证明时间/最大证明时间)^-1 ) / SUM((X 的证明时间/最大证明时间)^-1))*总奖励
这将根据证明延迟和出价金额调整奖励。这里的假设是，如果出价金额不足，可以由排序器补贴。(注：这可能适用于为冗余而选择多个证明者的其他情况）
另一个考虑因素是排序器的扣留攻击和对这种攻击的防范。由于数据由定序器持有，而风险赌注可能不属于定序器，因此定序器可以扣留数据，同时让证明者履行证明者存款（proverDeposits）。由于在确定有效载荷是否已正确分发的有效载荷及时性方面没有达成共识，因此很难对潜在的扣留攻击进行问责。因此，即使使用侧车模型，也可能需要在序列发生器之间（至少）达成某种形式的有效载荷及时性共识，以便在序列发生器扣留数据的情况下，可以实现并惩罚该序列发生器。
3. Finet on the rock（0 Enshrinement）
创作者：@cooper_kunz
https://forum.aztec.network/t/proposal-fernet-on-the-rocks/2460
概述：
上图展示了该模型的整体流程。非常简单。
a. 序列发生器也同时扮演证明者的角色，如果证明没有正确提交，他们的利益就会受到威胁。
b. 他们也可以将证明者的工作外包给其他人，由外部人员进行协调和证明。
讨论与修改： 这种模式非常简单。此外，由于因扣留攻击而面临损失风险的是定序者的利益，因此这能更好地激励定序者防止此类攻击。即使将证明工作外包给外部证明者，扣留数据攻击也主要会损害排序器本身，尽管可能会导致网络停止，或者只是出现一个空槽，这也是一种公平的解决方案（参考 Eth 提议者）。
如果将证明工作外包给第三方，可能会出现证明者集中化的趋势，类似于侧车模型。不过，如果证明者的选择有足够的冗余机制，那么证明者的集中化在我看来并非坏事。这里要注意的是，证明者的集中化比构建者的集中化恶性要小，因为证明者不必被信任。
因此，优先考虑网络效率（更少的通信开销）而不是证明者分散化（在合作模型中）是一种公平的权衡。此外，由于这种设计的简单性，可能会给阿兹台克网络带来较少的安全成本。
一些看法：
在高层次上，有几个重要的考虑和讨论要进行。
1. Prover decentralization的收益是否值得付出这样的代价？它是否应该得到认可？
这是设计是否采用合作性证明者机制和竞争性证明者机制的核心问题。这里的主要考虑因素是有效性和去中心化。虽然合作模式可以提高有效性，但也可能会增加协议的复杂性，并增加通讯开销带来的网络延迟。增加的成本是否能证明从合作模式中获得的有效性优势是合理的？如果在竞争模式周围有足够好的冗余机制，我们也许就能提供足够强的有效性。当然，我想参考维塔利克最近发表的一篇关于最小可行性的文章，作为此类设计决策的思路。
2. 针对有效性的共识增加了在受到攻击时的问责措施。但我们能否在防止攻击的同时避免共识开销呢？
当我看到增加的共识（如有效载荷时效性共识）时，我确实会质疑这样的方法是否真的是最优方法。以Staking network（合作模式）为例，它将需要有效载荷时效性共识来确保定序者和证明者不能互相进行恶意攻击。即使他们实施了攻击，也可以借助共识结果进行惩罚。但这个模型通过将证明责任和风险完全转嫁给定序者，成功地避免了这一点。这就引出了下一个问题。
3. 越简单就越好吗？
这可能更取决于团队想要优先考虑什么。如果想增加预确认功能以加快软终结速度，那么增加一些共识开销可能是个不错的功能，在这种情况下，合作模式就有意义了。但如果不是因为区块时间过长，而是想优先考虑网络稳定性，我们可以选择更简单的模式。当然，还有一个很好的中间地带，可以像我之前提到的那样，将两种方法合并为一种混合模式（合作模式的备用方案）。
总之，@aztecnetwork 上有很多有趣的讨论。无论谁读到了这条推文，都一定要去看看其中的一些提案：
https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397
公开提交提案的截止日期是 11 月 3 日
在此也@一些可能对这类问题非常感兴趣的朋友：
@MaxResnick1 @malleshpai @barnabemonnot @toghrulmaharram @kobigurk @tarunchitra
