预确认公平交换 - 共识

本文提出了一个用于分析协议的框架,该协议旨在强制执行预确认的及时公平交换。在L2中,由 L2 治理机构选举产生的中心化排序器是理想的候选者。在L1中,引入重复博弈预确认者需要考虑更多因素,例如网关设计和用户监控。

Conor McMenaminLin Oshitani 共同撰写,他们都来自 Nethermind Research

TL;DR (太长不看)

我们概述了一个框架,用于分析旨在强制及时公平交换预确认的协议。在这个框架内,我们概述了清晰占优的及时公平交换协议设计。我们讨论了这些最优协议在现有 L1 和 L2 设计方面的可行性,并将我们的框架应用于现有的预确认协议。

致谢与免责声明

本文已获得 PBS 基金会 的资助。非常感谢 Davide RezzoliEllie DavidsonChristian Matt 提供的有益评论。任何表达的观点均为作者观点,不一定代表 Nethermind、PBSF 或评论员。

介绍

预确认(preconfs)已成为以太坊生态系统中一个备受关注的话题,它可以为用户提供更快的确认时间,类似于 Web2 的近乎即时的用户体验。为了让 preconfs 能够落地,需要激励区块提议者支付机会成本,以便在其提议Slot中更早地确认状态,并成为 预确认者。这与在提议Slot结束时及时构建区块的现状相反。这种激励将以费用的形式出现,用户可以指定提供 preconf 的时间偏好,而预确认者可以选择接受或不接受该费用,以换取满足用户的时间和执行偏好。

本文档侧重于理解确保 preconfs 可以根据用户偏好及时提供的设计空间。我们将 preconfs 定义如下:

定义 1:预确认

交易预确认是指在交易包含在由 L1 提议者签名的 L1 区块中之前,对交易包含或执行的承诺。

它需要有机会提交给 L1。对于 L1 preconf,这可能意味着被以下对象预确认:

  • L1 提议者,
  • 受委托代表 L1 提议者进行预确认的人,
  • 有一定几率赢得拍卖的构建者,以获得构建由 L1 提议者提议的区块的权利,例如 mev-commit

可以通过上述任何方式给出 L2 preconf 设计,尤其是在 Based Rollup基于 Preconf 的情况下。但是,L2 preconfs 通常由 L2 的治理指定的中心化排序器提供,该排序器拥有在 L1 上提议 L2 区块的专有权利。

无论谁可以提供 preconf,用户都需要某种保证,即有能力有效预确认交易的实体将提供 preconf。由于 某些 preconfs/preconf 协议与简单确认交易相比,会导致指定的提议者收入减少,因此用户可能需要激励提议者预确认交易。在提议者是无需许可且没有义务提供 preconfs 的协议中,尤其如此。 正在考虑的激励提议者预确认交易的解决方案取决于 preconfs 的 及时公平交换。本文档的其余部分重点关注及时公平交换的这一属性;它是什么、如何强制执行、何时成立以及何时不成立。

作为独立的兴趣,我们展示了如何在 重复博弈 设置中实现交易的公平交换,而无需受信任的第三方,这在一次性博弈中是众所周知的。一种不可能的事情。尽管我们的框架中提供的公平交换保证是基于激励的,但这些激励与实体确认交易以打破公平交换的成本直接成比例。这些成本可能高得离谱。当提供 preconfs 的实体正在进行重复博弈时,为提供公平交换带来持续的正收益,以及为偏离带来一次负面的“末日”收益时,这一点就变得显而易见。这些激励分别对应于收取提供公平交换的费用,以及拥有大量代币,其价值与对底层区块链的信任相关。任何受这些成本限制的偏离的一次性激励都变得不合理。这与博弈论的结果一致,例如 民间定理

文章组织

我们首先介绍及时公平交换的概念,然后介绍一个框架,用于考虑和比较及时公平交换解决方案。该框架描述了任何及时公平交换协议所需的组件,以及任何此类协议的关键属性和期望。有了这个框架,我们就可以利用它来确定及时公平交换协议的最佳解决方案,具体取决于底层区块链的设计约束。然后,我们将我们的框架应用于现有和未来的 preconf 协议,包括讨论网关作为 L1 preconf 解决方案的总体适用性。

及时公平交换

传统文献中,公平交换属性定义如下:

定义 2:公平交换

当双方交换数字项目(例如,电子合同、付款或签名)时,要么双方都收到预期的项目,要么双方都没有收到。

但是,正如我们在介绍中看到的那样,对于 preconfs 而言,交换的及时性 是关键。为了捕捉这种直觉,我们引入了一个称为 及时公平交换 的属性,简称 TFE:

定义 3:及时公平交换 (TFE)

当两个参与者交换数字项目(例如,电子合同、付款或签名)时,要么双方都收到预期的项目,要么双方都没有收到。此外,关于交换的通知应在一方指定的某个目标时间范围内发生

TFE 中交换的项目是 preconf 小费,由 用户 提供,以及 preconf 本身,由预确认者提供。此外,目标时间由用户在 preconf 请求中指定。

TFE 参与者

在所有 TFE preconf 协议中,都需要考虑三个参与者:

  • 用户:请求及时 preconf 的实体。

  • 预确认者:提供 preconf 的实体。在本文中,我们假设预确认者是理性的,他们选择的行动可以在某个指定的时间范围内最大化其预期效用。特定惩罚的有效性取决于预确认者是:

    • 一次性预确认者:匿名、无需许可和/或仅在少量固定数量的 preconf Slot中进行预确认。
    • 重复博弈预确认者:众所周知、已许可和/或预计在大量 preconf Slot中/无限期地参与该协议。

尽管这些是多维分类,但它们仅用于概括目的。在这些分类中,以太坊验证器集通常被描述为一次性的,因为验证器目前被选出 预计每 140 天提议 1 个区块,而 当前加入或退出验证器集的等待时间不到 1 天。重复博弈预确认者的模板是 L2 上的中心化排序器,而 L1 上的委托网关 可能是重复博弈的,尽管有关网关设计的详细信息仍在不断涌现。

  • 监督者:监控 TFE 的实体(或多个实体),它具有一系列可以强制或激励预确认者提供 TFE 的操作。在“监督者”的分类中,许多监督者设计都是可能的。监督者——无论是单一实体还是一个群体——可以通过两种方式实施:正式方式,在协议中明确指定;或非正式方式,没有明确指定,如下所述。

    • 正式

    • 在 rollup 创世时决定。

    • 由治理选举产生。

    • 通过持有代币的要求选举产生,例如权益证明,以与以下一项或两项保持一致:

      • preconf 协议。
      • 底层共识协议。
    • 通过某种形式的主观间罚没的隐式监督者,底层共识协议的验证器可以协调以罚没恶意预确认者。有关主观间罚没的更多详细信息,请参见 此处此处此处。这种类型的解决方案实际上只需要用于基于监督者的 L1 preconf TFE。由于协调 L1 验证器进行罚没的适当性更多的是哲学辩论而不是技术辩论,因此我们从本文中省略了对该技术的进一步讨论。

    • 非正式:未在协议中明确指定的监督者。例如,它们是:

    • 用户,即钱包或代表用户行事的 L2 全节点,跟踪预确认者和/或在怀疑 TFE 时向其他用户传播消息(用户监控)。

需要监督者的原因是来自一个遗留的不可能性结果,该结果表明在没有引入监督者来调解争议的情况下,无法保证不信任的预确认者和用户之间的 TFE。考虑到这种不可能性,本文档中引入的任何 TFE 解决方案都将利用以下任一项:

  1. 一位受信任的监督者。我们将此类解决方案称为满足 受信任的 TFE
  2. 不受信任但经济上理性的监督者。我们将此类解决方案称为满足 经济 TFE

这些受信任或经济 TFE 的属性并未说明监督者可以在多大程度上影响底层共识协议的审查和活跃性,或者理性预确认者诚实行事的具体动机。这些属性的确切分类将基于协议逐个协议地进行解释,并在后续部分中进行总结。

为什么理性的预确认者会在经济 TFE 协议中偏离 TFE?

预确认者偏离 TFE 的动机来自底层交易或状态访问的价值随时间的变化。也就是说,某些类型的 MEV(例如 CEX-DEX 套利)已被证明在预期中会随着时间的推移而增长。不仅如此,随着 mempool 大小的增长,交易排序的组合也会增长,这对于能够延迟确认交易直到最后一刻的提议者和预确认者来说也是一种价值来源。

TFE 解决方案的属性

两个关键属性决定了 TFE 解决方案的有效性:

  • 惩罚:什么信任假设或经济机制可以确保 TFE 像用户期望的那样成立?
  • 监督者的活跃性依赖性:监督者引入了哪些与审查和活跃性相关的额外信任假设或风险?

惩罚

所有 TFE 惩罚都由 TFE 违规行为触发,违规行为对应于预确认者违反 preconf 请求的目标时间范围。 TFE 保证的可能强度几乎与惩罚的强度直接对应,我们将在下面以近似的强度顺序(从最强到最弱)概述。

  1. 实时惩罚:已许可的监督者处理所有 preconf 请求,并强制每个请求对应的 preconfs 满足 TFE。这可以按照以下方式完成:

a. 仅当监督者签署 preconf 时,preconf 才有效。

b. 请求必须由监督者转发给预确认者。

c. 仅当监督者签署 preconf 时,preconf 小费才有效。

  1. 事后惩罚

a. 罚没:预确认者损失 preconf 协议规定的预定金额。尽管违规行为意味着一个或多个请求未进行 TFE,但用户获得了 TFE 的间接保护,因为理性的预确认者会避免因违反 TFE 而使他们的质押抵押品面临风险。需要已许可的监督者来调解 TFE 违规行为。

b. 列入黑名单:在指定的持续时间内,预确认者被列入黑名单,无法进行预确认。需要已许可的监督者来更新黑名单。

c. 短期 orderflow 损失:如果预确认者违反 TFE,则预确认者会在当前 preconf Slot的剩余时间内(可以跨越多个以太坊共识Slot)失去来自用户的 preconf orderflow。这种 orderflow 损失可以通过用户监控或某些已许可的监督者来触发。

d. 长期 orderflow 损失:如果预确认者违反 TFE,则预确认者会在所有未来的 preconf Slot中失去 preconf orderflow。同样,这种 orderflow 损失可以通过用户监控或某些已许可的监督者来触发。

我们已经以这样一种方式对这些事后 TFE 惩罚进行了排序,即任何实施惩罚 2.x 的协议 2.x 也可以实施 2.(x+1) 2.(x+1), ∀x ∈ {a,b,c} 在协议中进行最少的额外更改,例如,任何具有有能力进行 b 的许可实体的协议。将预确认者列入黑名单,可以使用这些许可实体来向用户和钱包发出信号,以停止将 c. 短期和 d. 长期 orderflow 发送给违规的预确认者。

监督者的活跃性依赖性

TFE 的这一属性旨在识别预确认协议和底层区块链协议对监督者的依赖程度。尽管影响活跃性的威胁可以用来阻止预确认者的不当行为,但它也可能改变提供 preconfs 的链的审查和活跃性属性。

使监督者处于活跃性的关键依赖路径上的 TFE 会认为 TFE 协议不适合部署在具有严格的活跃性要求的协议上。

image \ image1171×361 82 KB

一个可能的用于比较监督者签名活跃性依赖性的指标。

为简单起见,在本文档中,我们避免进一步限定“活跃性依赖性”或“无活跃性依赖性”之外的活跃性依赖性。

用于比较 TFE 解决方案的框架

有了前一部分的属性和分类,我们现在就可以根据惩罚的强度和预确认者的类别来比较 preconf 协议。回顾一下我们已经概述的组件,TFE 解决方案必须定义以下组件。以 粗体 高亮显示表示各个组件的理想实现,在其他条件相同的情况下:

  1. 监督者定义

a. 监督者是正式的吗?

  • :无需管理和补贴监督者。

  • 是:需要治理和/或补贴来选择和监督监督者。

b. (对于特定实现)监督者如何识别和报告 TFE 失败?

  1. 执行和惩罚:对 TFE 违规者处以什么惩罚?我们已将这些惩罚分类为:

a. 实时执行

b. 罚没

c. 列入黑名单

d. 短期 orderflow 损失

e. 长期 orderflow 损失

对于每个 TFE 解决方案,我们主要对两个属性感兴趣。以 粗体 高亮显示表示各个属性的理想满足,在其他条件相同的情况下:

  1. 惩罚的有效性:预期惩罚在保证 TFE 方面的效果如何?我们尝试将此属性的满足程度作为第三个变量:

a. :惩罚非常有效。

b. 中等:可以对惩罚进行参数化以使其具有高或低有效性,并且确切的实施细节将很重要。

c. 低:惩罚无效。

  1. 监督者的活跃性依赖性:监督者会影响底层区块链的抗审查性和活跃性吗?

a. :理想情况下,不应对监督者有活跃性依赖性。

b. 是:存在依赖性,这不是最佳选择。

在定义具体协议之前,我们现在提供一个高级理解,即每种 TFE 执行机制在一次性预确认者和重复博弈预确认者的情况下如何运行。为此,对于提议者类型和执行机制的每个组合,我们指定一个三元组,该三元组描述了:

( 1. 监督者的活跃性依赖性,

2. 对正式监督者的需求

3. 惩罚的有效性 )

惩罚 重复博弈预确认者 一次性预确认者
长期 orderflow 损失 (1. , 2. , 3. ) (1. , 2. , 3. 低)
短期 orderflow 损失 (1. , 2. , 3. ) (1. , 2. , 3. 低-中等*)
列入黑名单 (1. , 2. 是, 3. ) (1. , 2. 是, 3. 低)
罚没 (1. , 2. 是, 3. ) (1. , 2. 是, 3. 低-)
实时执行 (1. 是, 2. 是, 3. ) (1. 是, 2. 是, 3. )

表 1:对提议者类型和执行机制的组合的分析。粗体 条目表示各个属性的大范围内的首选满足,即:

1. 对监督者没有活跃性依赖性。

2. 不需要正式监督者。

3. 执行和惩罚的高有效性。

*取决于 preconf Slot中剩余 orderflow 的预期值。

**取决于罚没金额。

我们框架中的最佳 TFE 解决方案

如果我们只关注所有以粗体显示的元组条目,那么今天就有一种通用类型的 TFE 解决方案可以部署并以最佳方式满足所有属性。这就是表 1 中的“具有短期和长期 orderflow 损失的重复博弈预确认者”。

对于 L2,由 L2 治理选出的中心化排序器是理想的候选者。在 L1 上,在充当提议者的去中心化验证器集存在的情况下,引入重复博弈预确认者并不那么明显。我们将关于网关的讨论(网关是 L1 上重复博弈预确认者的潜在实现)推迟到讨论部分。

image \ image692×399 56.1 KB

用于中心化排序器 L2 的用户监控。

专注于 L2,由 L2 治理选举产生的中心化排序器在与我们设想的治理选举产生的监督者相同的方式中是“最大程度对齐”的。我们可以非常有信心地认为中心化排序器不会违反 TFE,因为在存在用户监控的情况下,这样做会冒着用户外流和排序器/治理代币持有量贬值的风险:在我们的框架中是最大程度的长期 orderflow 损失。

但是,中心化排序器会在短期审查和活跃性的关键路径上创建一个单点故障。尽管这种故障模式在 TFE 框架中是可以接受的,但中心化排序器 L2 用户必须求助于延迟收件箱进行排序,这可能会导致延迟 24 小时 或更长时间,具体取决于 rollup 的 延迟收件箱设计

那么,在没有中心化排序器的环境中,最佳解决方案是什么?

没有中心化排序器的预确认的最佳 TFE 解决方案

我们现在概述了在中心化排序器设置之外使用 preconfs 的主要环境,以及每种环境最合适/最有效的 TFE 解决方案。

具有去中心化 L2 提议者集的 L2 预确认

此设置包括基于 L2 的协议,例如 TaikoSurge

建议:具有罚没能力的正式监督者。这对应于表 1 中“具有罚没的一次性预确认者”的情况。

为什么?:执行机制的高有效性,对监督者没有活跃性依赖,监督者可以由 rollup 治理选择,以与 L2 的长期成功最大程度地对齐。

image \ image692×527 73.4 KB

让我们回顾一下这些组件:

  • 监督者
    • :监督者可以是单个 TTP、多个 TTP、选择加入的预确认者、独立的 AVS 或选择加入的验证器。建议监督者由 rollup 治理管理,因为 rollup 会受到激励,以提供良好的 UX 来换取短期收入损失。
    • 故障检测机制:监督者将形成关于及时发布 preconfs 的共识。
  • 执行和惩罚

    • 如果未及时发布,则可以将委员会的共识发送给钱包作为警告信号,或者发布到 L1 以:
    • 将预确认者列入黑名单。
    • 罚没预确认者。

属性

  • 保证强度
    • 作为用户,你发送的任何 preconf 请求仅具有 TFE 的经济保证。但是,只要监督者委员会是诚实的,预确认者就应该受到激励来维护 TFE 以避免被罚没。
  • 监督者的活跃性依赖性
    • 无,因为罚没仅具有追溯性。

L1 预确认

与 L2 preconfs 的情况不同,没有明显的 L1 preconfs 推荐协议,因为每个协议都带来了不同的权衡。因此,我们根据以下要求提出两项建议

  1. “快速通道”建议:我们希望立即启用和激励 L1 preconfs,尽管引入了不由底层协议选举产生的正式监督者。
  2. “慢而稳”的建议:我们不将正式监督者引入 L1 区块构建管道,而是等到对网关委托和/或证明者-提议者分离的研究成熟后再进行。届时,可以实施“保护措施”(在附录中讨论)以防止垄断,并且用户监控和预确认者声誉的组合可以作为 TFE 解决方案。

“快速通道”建议:利用一个或多个外部监督者协议来强制执行 TFE 违规行为的罚没。此协议的描述与上一节中描述的协议相同:具有去中心化 L2 提议者集的 L2 预确认,尽管正式监督者的设计不太明显。

为什么?:执行机制的高有效性,并且对监督者没有活跃性依赖。

为什么不?:关于 L1 上正式监督者的实施存在开放性问题。

image \ image692×527 78.7 KB

与 L2 对应方相比,正式的 L1 监督者设计更加复杂,并且无法利用治理或原生对齐的代币,其价值会随着监督者的不当行为而发生巨大变化。相反,监督者可能需要是信誉良好的半信任实体。目前尚不清楚这种设计是否适合于在 L1 上强制执行排序偏好。

“慢而稳”的建议:利用某种形式的非正式用户监控 TFE 来识别 TFE 违规行为并向更广泛的社区发出信号。

为什么?:对监督者没有活跃性依赖,也不需要正式监督者。

为什么不?:在没有重复博弈预确认者的情况下,执行机制的有效性较低。

image \ image692×399 56.1 KB

在 L1 当前的一次性预确认者范例中,用户监控的有效性有限。但是,如果 L1 提议者角色过渡到更高资源、信誉良好且重要的是 重复博弈,正如通过证明者-提议者分离所承诺的那样,这种情况可能会改变。

让我们回顾一下这些组件:

  • 监督者
    • :preconf 协议的最终用户。
    • 故障检测机制:在本地监控 preconfs 的及时发布。实际上,监控将由他们的钱包或他们连接到的全节点完成。
  • 执行和惩罚

    • 如果检测到 TFE 违规,则停止将用户 orderflow 发送给预确认者。
    • 损害预确认者对于非 preconf orderflow 的声誉。

属性

  • 保证强度
    • 作为用户,你发送的 preconf 请求将没有 TFE 保证。但是,如上所述的惩罚机制的威胁提供了一些经济保证,即预确认者会维护 TFE。预确认者通过执行机制失去的 orderflow 越有价值,TFE 保证就越强。当预确认者具有声誉、可能再次当选以及请求在Slot中较早时,通过用户监控获得的 TFE 保证会更强,因为与替代方案相比,这些都需要更高的机会成本来打破 TFE;没有声誉,不太可能再次当选进行预确认,预确认者Slot中几乎没有剩余 oderflow。
  • 监督者的活跃性依赖性
    • 无。

将我们的框架应用于现有协议

我们概述了一些当今正在使用/拟议使用的最著名的 preconf 协议,以及这些协议如何适应我们的 TFE 框架。

Mev-commit

Mev-commit 的描述如下。

image \ image818×338 83.5 KB

mev-commit 中的委员会从预确认者那里收到 preconfs,并就时间戳达成共识,以确定要从用户那里支付给预确认者的 preconf 小费。如果预确认者违反提供的 preconf,委员会也可以用来罚没预确认者。

让我们回顾一下这些组件:

属性

  • 保证强度
  • 监督者的活跃性依赖性
    • Preconf 活跃性依赖性:是。如果监督委员会出现活跃性问题或开始审查,则无法结算 preconfs。
    • 常规交易活跃性依赖性:否。预确认者没有义务使用 mev-commit,并且可以从 mev-commit 外部获取常规交易。

Espresso

Espresso 不一定是为了处理 TFE 而构建的,但可以很容易地对其进行调整以启用 TFE。我们现在描述 Espresso 架构以及它如何处理 TFE。

image \ image818×338 83.5 KB

与 mev-commit 类似,Espresso 中的委员会从预确认者那里收到 preconfs。与 mev-commit 不同,Espresso 委员会需要签署交易,交易才被认为是共识有效的。如果 TFE 中断,或者区块与提供的 preconfs 不匹配,Espresso 委员会将不会签署该区块,并且该区块无法作为共识提出。

让我们回顾一下 Espresso 组件:

  • 监督者(Overseer):
    • 谁(Who): 监督者是一个选择加入的重新质押的验证者委员会。
    • 故障检测机制(Failure Detection Mechanism): 该委员会将形成共识,并且该共识将决定预确认是否按时发布。
  • 执行与惩罚(Enforcement & Punishment):

    • 如果 TFE 被违反,那么 L2 交易本身不能包含在 L2 区块中,因为来自监督委员会的法定人数证书是 L2 区块有效性的必要条件。

属性(Properties):

  • 保证强度(Strength of Guarantee)
    • 只要委员会中的拜占庭多数是诚实的,就可以确保用户,除非及时发布相应的预确认,否则不会执行交易。
  • 对监督者的活跃性依赖(Liveness Dependency on Overseer)

    • 预确认活跃性依赖(Preconf liveness dependency): 是的。

    • 一般交易活跃性依赖(General transaction liveness dependency): Espresso 有两种可能的rollup设计,可以选择加入 Espresso 预确认。这些设计包括带或不带逃生舱口,以应对活跃性失败的情况(自从rollup区块提交到 L1 以来已经过去了太长时间)。

    • 在没有逃生舱口的情况下,一般交易依赖于监督委员会的活跃性。

    • 有了逃生舱口,最终的交易活跃性得以维持。然而,短期活跃性(逃生舱口时间限制之前的活跃性)和抗审查性依赖于监督委员会。

L1 网关设计(L1 Gateway Designs)

网关有望成为复杂且有信誉的实体,L1 提议者可以选择外包给这些实体。 由于需要成为复杂、技术先进和有信誉的实体所需的投资,网关几乎肯定可以归类为重复博弈预确认者。 尽管这在理论上可能类似于 L2 上的中心化排序器,但在面对行为不端的网关时,目前缺乏强制纳入机制,使得执行机制从根本上有所不同。 这在 TFE 的执行以及相应的执行有效性方面尤其明显。

如果用户监控用于监督来自网关的 TFE,那么面对行为不端的网关,用户目前将没有其他替代机制将交易提交到 L1。 面对垄断网关,这个问题变得至关重要,考虑到该角色的中心化性质(详见附录),垄断网关是完全有可能出现的。

考虑到这一点,似乎对于网关 TFE 或来自网关的任何需要执行的主观要求,都需要一个正式的监督者。 主动验证服务 (AVSs) 是实施此类监督者的可行候选者。 然而,一个有能力主观削减 L1 预确认者(包括提议者)的正式监督者是一个有争议的设计领域。 允许正式监督者在多大程度上主观削减 L1 预确认者尚不清楚,并且超出了本文档的范围。 此外,我们认为在 L1 上实现重复博弈预确认者保证的更可行途径是通过采用某种形式的证明者-提议者分离,这是另一个开放的研究领域。

结论(Conclusion)

TFE 解决方案的设计空间总是在发展,就像 L1 和 L2 空间总是在发展一样。本文建立了一个理解、评估和比较 TFE 解决方案的框架。该框架的核心要点之一是,任何 TFE 解决方案都需要明确监督者、监督者如何执行 TFE 以及监督者如何影响底层区块链上交易的审查和活跃性。

对于 Rollup,我们推荐使用“有切身利益”的监督者的 TFE 解决方案,这些监督者根据其 Rollup 的成功(或退出)而获得或失去很多。 这样的监督者非常适合处理预确认及时公平交换的主观性质。

对于 L1,没有明确的更优 TFE 解决方案可以推荐。 在当前 L1 设计中,无许可的验证者兼任提议者,可能需要正式监控。谁将成为受信任的正式监督者,以及他们应具有多大的惩罚能力尚不清楚。 我们关于 L1 预确认和 TFE 的主要建议是实施必要的保障措施,以保护 L1 的审查和活跃性,防止出现占主导地位的提议者和网关。

附录(Appendix)

扩展的网关讨论(Extended Gateway Discussion)

在当前 L1 提议者的设计中,提议者是从验证者集中伪随机选出的,这些提议者对网关的选择几乎肯定类似于“网关市场”,其中网关竞争他们可以向提议者承诺的预期收入金额; 实际上是一场提前进行的拍卖。

对提议者收入的竞争取决于网关的复杂性(区块构建和 MEV 提取能力、风险承受能力、连接性、总体基础设施)和声誉,以确保用户将他们的订单流发送给网关。 一旦当选,网关将获得提供执行预确认的独家访问权。 这创建了一个自我维持的飞轮:

声誉 → 订单流 → 区块价值 → 盈利能力 → 选举概率 → 声誉…

这是一个中心化的系统:

  1. 拍卖的提前性质意味着网关正在长期竞争平均提议者收入

a. 在任何时间段内,只能有一个具有最高平均提议者收入的网关。 尽管预确认一个 slot 的预期提议者收入最高的网关最终可能会发生变化,但这不会在短期和中期(几个月到几年)内发生变化,这是因为竞争对手获得技术优势可能需要时间。 这在现代高频交易市场中已经反复出现(此处此处此处讨论过),其中速度和执行质量是可以比较的,如果不是直接与网关的要求相关。

b. 除非较小的网关能够说服用户专门为其保留订单流——即使这意味着延迟执行——或者说服验证者尽管提供较低的收入也委托给他们,否则任何网关市场最终都将成为赢者通吃的市场。

  1. 新进入者需要进行重大的技术投资才能与占主导地位的网关竞争。 这创造了一场只有少数高资源个人才能参与的技术军备竞赛。

在这种赢者通吃的模式中,L1 网关解决方案最接近中心化排序器的 L2 分类。 理性的 L1 提议者会选择收入最高的网关。 这使得单个实体对整个 L1 进行排序,从而产生明显的审查和活跃性依赖性。 最赚钱的网关可以随意选择审查个人,甚至停止生成区块,例如在维护期间。 只要占主导地位的网关比其最接近的竞争对手更有利可图,用户就会被迫将交易发送到该网关,或者以相当糟糕的条件进行排序(例如,等待下一个未选择加入该网关的提议者)。

防御垄断网关(假设采用网关)

可以采取保障措施来限制网关赢者通吃性质的负面后果,我们在下面列出了一些:

  1. 包含列表(Inclusion lists): 包含列表将极大地限制占主导地位的网关审查和影响活跃性的能力。 即使如此,只有通过某种方式明确惩罚网关(通过正式的监督者,请参阅下一点)或减少网关订单流,才能强制执行 TFE。 如果有占主导地位的网关,减少订单流意味着迁移到另一个区块链生态系统。
  2. 正式监督者(Formal Overseer): 鉴于占主导地位的网关出现,鉴于目前缺乏向 L1 提交交易的替代方式,仅靠用户监控可能不足以强制执行 TFE 违规行为。 拥有列入黑名单或削减网关能力的正式监督者可能是一种可接受的保护措施。 然而,正如本文前面提到的,尚不清楚如何选择正式监督者作为管理 L1 排序的机制。 L1 监督者的多样性/分层 L1 监督者,每个都有自己的削减能力,可能在这方面是一个有趣的研究领域。
  3. 加速证明者-提议者分离(Acceleration of Attestor-Proposer Separation): 虽然不是直接的保障措施,但证明者提议者分离是协议内对网关委托的实施,网关将依赖于此。 此未来的任何协议内解决方案都将使去中心化的证明者集与提议的最大化利润的性质隔离开来。 未来的任何提议者选举机制都需要有协议内保障措施,以处理占主导地位的提议者出现的情况。

总之,L1 网关解决方案在短期内可能看起来可以接受。 然而,如果没有明确的保护措施来防止垄断网关对 L1 进行排序,则应非常谨慎地采用网关预确认解决方案。

  • 原文链接: ethresear.ch/t/preconfir...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文, 用中文传播以太坊的最新进展