基于提议者的承诺:以太坊提议者承诺的市场 - 权益证明/区块提议者

文章介绍了Commitment Boost的概念,旨在为以太坊的proposer commitments提供一个标准化的通信机制,以减少碎片化和开发复杂性。

一如既往地,以太坊社区愿意审查/提供反馈令我感到荣幸。感谢 Barnabe, Chris, Conor, Ellie, Jason, Jonas, Justin, Julian, Kubi, Kydo, Mike, Pascal, 和 Sam 提供的反馈和审查。

介绍:

在过去的一年中,proposer commitments(提议者承诺)受到了更广泛的讨论。我个人在基于排序 / preconf 帖子以及 Justin 举办的每周电话会议 以及关于 blockspace futures(区块空间期货)的讨论和研究 的支持下,接受了 proposer commitments 的概念。随着这种兴趣的产生,我深入了这个兔子洞,并且像往常一样在以太坊社区中,我发现许多其他人已经在那里或愿意加入。我希望这篇文章能为已经存在的想法做出贡献,并继续推动围绕 proposer commitments 的讨论以及整个社区的参与。

下面我们介绍一个概念,该概念侧重于标准化 proposer(提议者)和第三方之间的最后一公里通信,以及 proposer 如何注册和发出/接收 commitments。我们将 proposer commitments 视为以太坊原始核心愿景的另一个有希望的演变,它将扩展无限花园,使其不仅成为可信区块空间的市场,而且成为可信 proposer commitments 的市场。我们概述了一些背景和动机、设计原则、最初的高级设计以及一些悬而未决的问题。我们计划在收集更多反馈和意见后,继续扩展此内容,并提供更详细的规范!

[\\ 750×500 54.1 KB](https://ethresear.ch/uploads/default/original/3X/f/9/f9246140c4556cd087cf9de5c5a0f5e363ada4b4.jpeg "")

TL;DR(太长不看):

  • Proposer commitments 一直是以太坊历史的重要组成部分,并且可以继续成为以太坊的强大解锁
  • Proposer commitments 的潜在影响最好用 Barnabe 最近的帖子 中的一句话来概括;“……proposer 创建了规范或模板,由此必须创建生成的区块,并且 proposer 聘用的构建者负责根据其规范交付区块”
  • 在过去的一年中,围绕 proposer commitments 出现了多个想法。例如,即使在很短的时间内,我们也看到了与 preconf 相关的 proposer commitments 的多种实现
  • 虽然功能强大,但如果围绕 proposer 如何注册和发出/接收 commitments 出现多个标准,我们可能会面临碎片化的风险,这可能会增加以太坊的风险
  • 我们提出了一个潜在的设计,称为“Commitment Boost”[1],其灵感来自围绕 PEPC、EigenLayer 和更广泛的以太坊社区的研究
  • 这设想利用现有管道,允许 proposer 注册和发出/接收 commitments,并保持完全的向后兼容性
  • 我们为此采用的原则要求开源/公开开发,考虑模块化和自我包含以确保安全,集成一套强大的测试/现成警报/数据 API,并且具有高性能/效率
  • 我们以一些关于风险/我们希望与社区讨论的额外问题结束

最后,我们想指出的是,这篇文章侧重于最后一公里的通信,以允许 proposer 注册/发送/接收 commitments。我们不讨论 proposer commitment 协议如何工作或如何执行。

相关工作:

关于 preconfs 的演示文稿幻灯片

背景:

大约五年前,发布了 Flashboys 2.0,强调了 arbitrage bots(套利机器人)如何挑战区块链的承诺。在此基础上,一些作者和社区成员开始了一个研究集体,以提供解决方案来应对这些挑战。最终,这些努力创造了一种更广为人知的产品,称为 MEV-boost

MEV-boost 是一种中间件,允许 proposer 做出批发承诺,即将区块构建外包给一个名为 block builder(区块构建者)的复杂参与者。作为回报,这些区块构建者会打包一个区块,以为 proposer 赚取最高的费用。今天,超过 90% 的区块 是通过 proposer commitments 构建的。

Proposer Commitments:

在一些发展[2]和 EF[3] 的一些研究之后,proposer commitments 的概念已开始被更普遍地讨论,从而引发了一个问题:proposer 是否可以做出解锁以太坊重要设计空间的 commitments?并且,这是否可以作为一种机制,允许验证者“……为区块生产提供投入,即使他们决定委托构建。”[4] 在过去的一年中,提出了多个依赖于 proposer commitments 或可以从中受益匪浅的提案,一些示例包括:

  • Inclusion lists(包含列表):Proposer commitment,其中区块的一部分/一组交易将被包含/不能被第三方审查或删除,包括 proposer
  • Preconf:Proposer commitment 提前保证在区块中包含数据/某些交易或一组交易
  • Partial block auctions(部分区块拍卖):Proposer commitment 用于拍卖 top-of-block(区块顶部)和 rest-of-block(区块剩余部分)
  • Blockspace / blob futures(区块空间/blob 期货):Proposer commitment 现在出售其区块的一部分,但在将来交付该部分区块

这些提案的复杂程度各不相同,但都基于相同的简单想法——proposer 承诺与第三方一起做某事或为第三方做某事。我们还注意到,proposer 可能不需要在此粒度级别上做出 commitments(即,继续使用批发区块拍卖)。但是,我们认为这是一个值得探索的途径,因为它可能有助于维护链中立性,方法是“允许他们为区块生产提供投入,即使他们决定委托构建”[4],并且如果他们选择,可以将一些自主权还给 proposer。

挑战:

从表面上看,这一切似乎都很棒,并且是非常令人兴奋的发展。但是,在暗流中,如果我们无法就 proposer 如何注册和发出/接收 commitments 达成标准,我们可能会走上一条危险的道路。我们看到多种风险,包括但不限于:

  • 碎片化加剧:虽然标准的多样性可以解锁更多的创新,但多个标准(尤其是在最后一公里的通信中)可能会通过 proposer commitment 协议如何与 proposer 通信的碎片化来损害整个以太坊网络的安全完整性(即,proposer 可能需要为 proposer commitments 的每个变体进行客户端调整)
  • 开发复杂性:如果没有标准,团队可能会更频繁地进行客户端调整以选择加入 proposer commitments。这可能会成倍增加核心开发人员的负担,这些核心开发人员的任务是执行/测试主要的网络升级,从而增加网络围绕硬分叉的风险
  • 透明度有限:使用多种软件和标准,当出现问题时,了解 proposer 选择加入的内容以及快速识别错误并采取快速行动的透明度可能会具有挑战性

随着越来越多的 proposer commitments 被提出和采用,这些风险可能会增加。我们还注意到,从长远来看,有一些潜在的想法可以确保各种机制有助于降低这些风险。

提议:

我们提出一种链外、开源的公共产品,该产品向后兼容,以帮助标准化 proposal commitments 最后一公里的通信机制。目标是开发、采用和维持一种标准软件,该软件将限制碎片化并降低核心开发人员的复杂性。我们目前将其称为“Commitment Boost”。

设计原则:

以下是最初设想 Commitment Boost 时的一些设计原则。

  • 开源/开放开发:这应该在开放环境中并在 MIT / Apache-2.0 等开源许可下进行开发
  • 安全并降低风险:应该向后兼容,不要更改支持当前 proposal commitments 的现有管道,并且应该构建为隔离每个 proposal commitment。我们还注意到,应该不断管理 Commitment Boost,以用于以太坊生态系统中未来的 forks(分叉)/升级
  • 与今天相同的开销:该软件的运行开销不会超过现有的 proposal commitments(理想情况下,它甚至更有效!)。注意:促进实际的 proposal commitments 可能需要额外的开销,但这不是本次讨论的重点,并且将取决于 proposal commitment 协议本身如何潜在地外包任何复杂性
  • 透明度:将需要强大的功能来了解 proposer 选择加入哪些 commitments,以及执行严格的测试以快速识别错误。还应该有数据 API 来提高社区的信息和透明度,并加强出现错误时的警报系统

Commitment Boost 的最初高级潜在设计:

  • 希望注册 commitments 的 proposer 运行 Commitment Boost。这将与使用当今存在的相同消息传递机制的共识客户端向后兼容。Commitment Boost 仅专注于标准化 proposer 选择注册然后在 proposer commitment 协议之间发送/接收消息的最后一公里通信
  • 运行 Commitment Boost 后,proposer 需要为他们希望做出的每个 commitment 注册
  • Commitment Boost 堆栈中的每个 proposer commitment 都可能是模块化的和隔离的。理由是,如果一个模块中存在错误,则不会影响其余的 proposer commitments/区块构建。我们还注意到,应采取保障措施来保护共识(即,回退到本地区块构建的机制等)

\ 1018×592 164 KB

近期重点:

如上所述,Commitment Boost 应该倾向于模块化,以潜在地允许任何 proposer commitment。但是,我们最初计划专注于设计 Commitment Boost 的标准,以使其向后兼容并支持诸如 preconf 协议和包含列表之类的 commitments。如果其他项目需要 proposer commitments 并且有兴趣考虑设计,请联系。

开放性问题:

以下是我们需要考虑和参与讨论的问题列表。我们注意到,其中一些问题并非特定于 Commitment Boost,而是更广泛地适用于 proposal commitments。

  • 增加的风险:虽然在启用 proposer commitment 协议方面存在一般风险和问题,但我们特别有兴趣参与讨论 Commitment Boost 额外风险/初步高级设计,以及该设计是否可以降低任何可能影响共识的 commitment 的风险
  • 标准化并不总是好的:虽然在大多数情况下,标准化有助于统一市场并降低碎片化的风险,但由于我们所处的早期阶段以及我们今天对 proposer commitments 的了解,它也可能限制创新并创建可能限制设计空间的“技术债务”
  • 如何添加模块:目前尚不清楚如何添加新 proposer commitment 模块的最佳路径(围绕流程)或缺乏流程
  • 以太坊升级期间的协调:可能需要协调一个小组,以确保有一个执行与 forks 相关的测试/更改的过程
  • 升级 Commitment Boost:与上面的直接观点类似,如果我们发现需要一些升级,我们将需要测试和管理所需的任何代码更改
  • 经济学:是否有关于如何向 proposer 支付承诺的费用以及这可能如何影响以太坊的任何考虑因素/这些是否可以在将来内部化到以太坊
  • 中心化:Commitment Boost 可能对中心化产生什么影响,它是否会影响在家质押者或验证者的地理分散

结论:

以太坊的花园是无限的,proposer commitments 的潜力可能会引发一波使用以太坊的方式。Proposer commitments 可以实现基于排序的关键 preconf 等功能,以及目前尚未设想的其他应用程序。为了帮助社区和企业家在以太坊上构建,Commitment Boost 是一个初步的想法,旨在标准化 proposer 注册以及发送和接收 commitments 的方式。我们期待与社区讨论、完善、开发并合作以进行 proposer commitments。我们计划在此帖子之后继续收集反馈,并继续与社区合作以推动这一想法,并协助进行与 proposer commitments 相关的其他工作。

参考文献:

[1] 有趣的事实:Commitment Boost 的首字母缩写与 CB Radios 共享,“一种允许个人之间进行短距离一对多双向语音通信的系统。”

[2] 随着 Justin Drake 提出的 基于排序 的兴奋,一些团队 推动构建 proposer commitments,例如 preconf。EigenLayer 和 restaking 等发展通常也扩大了开发人员/团队对 proposer 可以围绕哪些内容做出 commitments 的想象力。

[3] 一般而言,我们指的是 PEPC 和包含列表研究,如本文“相关工作”部分所述。

[4] 不可拥堵的包含列表:链中立性、预确认和 Proposer Commitments 之间的张力

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

0 条评论

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