避免基于预确认的意外活跃度故障 - Layer 2

避免基于预确认 (Based Preconfs) 的意外活性故障

感谢 Justin Drake, Jon Charbonneau, Ladislaus, Sébastien Rannou, sacha, Drew van Der Werff, 和来自 Aestus 的 Max Wilde 的思考和审查

.

.

tl;dr: 我们解决了提议者选择加入的基于预确认的最大问题之一：意外的活性惩罚。我们引入的机制不需要更改现有的基于预确认的协议设计，而且一直摆在我们面前。我们使用预确认链 (preconf chaining) 来保护单个提议者免受活性失败的惩罚。

.

.

背景

在今天的以太坊上，区块提议的活性问题在很大程度上是可以接受的，并且惩罚也很小。当我们引入基于预确认时，活性问题可能意味着不同的后果。

在处理预确认时：从用户的角度来看，活性故障（错过区块提议）和安全故障（提议的区块未履行预确认承诺）是同一件事。在这两种情况下，用户都会遇到他们的预确认未被履行的情况。

\ liveness faults are safety faults500×615 511 KB

现在，从提议者的角度来看，活性故障和安全故障是两个非常不同的概念。活性故障可能由多种外部的、偶然的情况（如停电、wifi 停机、重组、自燃）引起，而许多提议者根本没有为此做好准备。另一方面，安全故障仅当某些方（提议者或某些委托人）恶意行事时才会发生。

此外，归因活性故障也很困难。区块供应链中的许多参与者可能对发生的活性故障负责。最好避免涉及这种归因的复杂性。

为了使提议者更放心地投入潜在的大量抵押品，因意外活性故障而受到惩罚的情况应该非常罕见，甚至是不可能的。

预确认链 (Preconf Chaining)

简要假设：

• (这里我们讨论的是基于 preconfs，而不是 L1 preconfs)
• 惩罚条件具有表达性
• 预确认请求包括 L2 区块号
• “active preconfer” 指的是当前的预确认者（前瞻中的 L1 提议者或委托人），“next active preconfer” 指的是将成为下一个预确认者的实体。

惩罚条件构建：

我们假设一种类似于 预确认注册表 中提出的惩罚条件范例。具体来说，惩罚条件是“智能的”并且具有足够的表达能力来表示以下构造。

惩罚条件的设计使得预确认者在以下情况下受到惩罚：

• 他们签署了一个关于交易 A 和区块 B 的预确认请求，其中 B 是未来的 L2 区块。同时签署的还有一份“依赖项”列表，其中包含其他预确认者（按地址或其他 ID）。
• A 未在 B 中履行，或者未在 B 之前的区块中履行
• 所有依赖项都已签署相同的预确认请求（需要来自这些依赖项的承诺/签名），并且未受到惩罚（挑战/冷静期在这里很有用）。

这种依赖项设计使 presconfer 能够根据其他 preconfers 的选择有条件地预确认交易。

预确认流程

• Alice（一个基于 L2 的用户）想要一个交易 A 的包含预确认
• Alice 向 active preconfer 传递预确认请求
• 某些从 active preconfer 获得预确认承诺的实体（Alice、网关，甚至 active preconfer 本身）将 Alice 的预确认请求转发给 next active preconfer（添加了对 active preconfer 的依赖项），同时也转发了 active preconfer 的承诺。

\ diagram representing how any actor can send a chained preconf request to the next active preconfer1087×610 50.9 KB

任何可以访问预确认承诺的参与者都可以构建一个 preconf chaining 并将其转发给 next active preconfer。

请注意，这样做的动机各不相同：

• preconf RPC： 又名 预确认网关 可能会将 preconfs chaining 作为提议者的公益事业。
• 网关： 网关也可能将 preconfs chaining 作为提议者的公益事业，但也可能将其用作吸引提议者的功能（可能称为“活性故障保护”）。
• 提议者： 提议者（或节点运营商）也可以自己将 preconfs chaining。他们的动机显然是避免因活性故障而受到惩罚。

确定惩罚

• 如果 active preconfer 代表的提议者出现活性故障并且没有提议 L2 区块，他们将不会受到惩罚，因为预确认仍然可以由 next preconfer 来履行（并且预确认请求区块号将匹配）。
• 如果 active preconfer 提议了一个区块但没有履行预确认请求，他们将因安全故障而受到惩罚。
• 如果 active preconfer 没有提议区块，而 next preconfer 提议了一个区块但没有履行预确认请求，则 second preconfer 将因安全故障而受到惩罚。
• 如果两个 preconfers 都有活性问题，则两者都将因安全故障而受到惩罚。（这可以通过将 chaining 扩展到 2 个以上来避免。）

激励 Chaining

为了激励未来的 active preconfer 去 chain preconfs，active preconfer 可能会分享小费。此外，chain preconfs 的声誉期望可以鼓励更多的 chaining。

获得 chaining 采用的一种可能方法是简单地要求发生 chaining。为了使这成为现实，未来的 active preconfers 必须能够访问先前 preconfers 的预确认承诺。必须解决 DA 问题才能使之成为现实，这可以通过外部 DA 层来完成。值得注意的是，使用外部 DA 层会引入对另一个排序器的依赖：DA 排序器。待定不同的 DA 层的设计如何解决此问题以及可能发生的潜在审查。

结论

在这篇文章中，我们关注 chaining 对提议者的好处。广泛的 chaining 也增加了用户获得的预确认保证，从而使 preconfs 更有价值。这是一个双赢的局面！

无论是强制的还是选择加入的，preconf chaining 都可以保护提议者免受因意外活性故障而受到的惩罚。该系统可以帮助提议者更放心地选择加入更高的抵押品要求。

参考文献

• 预确认网关 by mteam (我) 提到了 chained preconfirmations，它可以为用户提供更好的活性保证。

• 基于预确认 by Justin Drake 介绍了一种基于 preconfs 的简单设计。

• 从提议者的角度来看，预确认活性惩罚 by Sébastien Rannou 涉及活性惩罚问题，并解释了它如何降低 preconfs 对提议者的经济可行性。

• Becoming Based: A Path towards Decentralised Sequencing

• 原文链接： ethresear.ch/t/avoiding-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～