Commit-Boost：安全地做出承诺的提议者平台 - 权益证明

_以下帖子是对一个名为 Commit-Boost 的社区工作的介绍和更新。其中大部分内容已经在各种公共领域/演示文稿/文档中讨论过。感谢所有已经为这项工作做出贡献/承诺做出贡献的无数团队，包括研究人员、验证者、构建者、中继者、客户端团队、咨询公司、构建承诺协议的团队、L2、再质押平台、共享排序器、钱包和无数其他人。如果你想为以太坊的这项工作做出贡献，请联系我们。_

\ Commit-Boost782×717 59.8 KB

TL;DR（太长不看版）

• 由于以太坊开发、核心开发及其验证者集合的风险，一群团队/个人正在开发一种名为 Commit-Boost 的公共产品
• Commit-Boost 是一个开源公共产品，与 MEV-Boost 完全兼容，但作为一个轻量级验证器平台，可以安全地做出承诺
• 具体来说，Commit-Boost 是一个新的以太坊验证器 sidecar，专注于标准化验证器和 proposer commitment 协议之间的最后一英里通信
• Commit-Boost 的设计核心是安全性和模块化，目标是不限制下游市场，包括利益相关者、流程、proposer commitment、执行机制等。
• 虽然我们应该始终对直接影响以太坊协议层附近基础设施的链下解决方案持怀疑态度，但如果我们真的要依赖这些解决方案，我们认为它们应该以一种包含社区先前表达的许多观点的方式进行开发、维护和管理。我们已尝试接受这一点，并努力将 Commit-Boost 效仿它

背景

• Proposer commitment 一直是以太坊历史的重要组成部分。今天，我们已经看到了承诺的力量，超过 90% 的验证者放弃了他们的自主权，并 wholesale commitment，将区块构建外包给一个名为区块构建者的复杂参与者
• 然而，大多数人开始认同一个共同点：未来，与今天他们看到的外部或本地 payload 相比，信标 proposer 将面临更广泛的选择，他们可以“承诺”什么——无论是包含列表还是 preconfs，还是其他类型的承诺，例如长期区块空间期货
• Barnabe 的一篇文章很好地捕捉到了这一点；在区块构建过程中，验证者“……创建规范或模板，由此必须创建最终区块，并且 proposer 聘用的构建者负责根据其规范交付区块”
• 虽然这一切看起来很棒，但挑战在于，许多构建承诺的团队正在创建新的 sidecar，从而加剧了以太坊的碎片化和风险
• 对于以太坊来说，如果验证者运行少量的 sidecar，那么在升级过程中将会面临重大挑战并增加风险
• 对于验证者来说，这些风险可能会将我们带到一个世界，在这个世界里，proposer 需要决定“押注”哪些团队，以及他们需要运行哪些 sidecar 才能参与这些团队提供的服务
• 对于自建者来说，这很困难，他们可能无法参与这些承诺中的多个
• 对于复杂的参与者来说，随着需要运行的 sidecar 越来越多，这会增加攻击向量和运营复杂性
• 另一个副作用是，由于有限的运营能力以及运行不同 sidecar 的转换成本（即供应商锁定），验证者在某种程度上被锁定在使用特定的 sidecar 中。转换成本越高，如果这些 sidecar 仅支持某些下游参与者/proposer commitment 协议，那么嵌入式网络效应就可能变得越强
• 这也可能会产生一种动态，即支持以太坊的核心链下基础设施（应该是一种公共产品）开始被用于货币化、分发或其他目的
• 由于这些动态，社区中的各个团队和个人正在推动开发和测试名为 Commit-Boost 的开源/公共产品软件。这项工作包括研究人员、验证者、构建者、中继者、客户端团队、咨询公司、构建承诺的协议、L2、再质押平台以及社区中无数的其他人员

Commit-Boost 概述

Commit-Boost 是一个社区驱动的开源项目，旨在开发一个不带主观色彩的验证器平台，以实现与承诺的安全交互。它的一些功能包括：

• 统一性：核心开发人员将能够在以太坊分叉/升级期间以及在出现问题时与一个标准进行交互和工作
• 向后兼容性 + 更多：Commit-Boost 不仅向后兼容 MEV-Boost，而且还将通过增加报告、遥测/验证者可以使用的其他现成工具来改善仅运行 MEV-Boost 的验证者的生活
• 无需运行更多 sidecar 即可选择加入：Commit-Boost 将允许想要选择加入其他承诺的 proposer 这样做，而无需运行多个 sidecar
• 强大的支持：Commit-Boost 软件由一个非营利实体支持。该团队将专注于通过政策和程序来确保安全性和稳健性，并采用 follow-the-sun 模式，在出现问题时提供 24/7 全天候支持。该团队还将专注于在硬分叉期间所需的测试和调整，并拥有一支团队来帮助采用、改进和维护
• 非风险投资支持的公共产品：该团队和工作不会获得风险投资的支持。没有货币化计划。该实体将无法出售自己，也不会开展任何可货币化的 side business

稳健性、可持续性和安全性

• Commit-Boost 正在作为一个完全开源的项目进行开发，来自以太坊技术堆栈的各个团队（包括验证者、客户端团队、中继者、构建者、咨询公司、研究人员等）都为其做出了贡献。这项工作通过来自这些团队的投入和支持，将有助于开发一个整合了许多观点的强大产品
• Commit-Boost 在完全开发完成后将进行代码审查和审计
• 如下所述，还将有一个全职团队，其核心重点是 100% 的正常运行时间，并在出现错误时，制定强大的流程来快速解决和修复，从而帮助维护和升级该软件
• 该软件堆栈也是以验证者为核心构建的，包括用于监控的现成工具，以及用于减少和主动解决可能出现的任何风险的工具
• 最后，这款公共产品软件将针对未来升级进行最小但至关重要的开放治理，并获得以太坊的投入

支持/管理 Commit-Boost 软件的团队

• 支持该软件的实体：非营利实体
• 多人团队：多个开发人员，专注于透明度、可持续性/开发和研究，最初侧重于 Commit-Boost 软件
• 透明度：开源 repo 和治理会议（见下文）
• 可持续性/开发：24/7 follow-the-sun 覆盖，并与客户端团队围绕升级/尽早获得测试网支持进行高度互动
• 研究：帮助以太坊的开源研究
• 治理：这仍然是一个 WIP，但至少会运行一个 Commit-Boost，类似于 ACD 的会议（第一次会议即将举行），以与利益相关者进行互动并推动对升级的共识/帮助协调硬分叉。一个信誉中立的社区成员将领导这些会议/此流程，该成员具有在以太坊社区内对关键软件运行治理流程的经验
• 资金：所有赠款

赠款将来自哪里

该团队正在申请来自整个生态系统的赠款。我们最初正在向社区中的一些组织申请赠款，这些组织支持研究机构和专注于 PBS 和质押的公司。如果团队有兴趣提供赠款，请随时在下面发表评论/联系我们。

技术路线图

Commit-Boost 目前处于 MVP 阶段，正在 Holesky 中进行测试，其中包含多个验证器。这包括实现 MEV-Boost 的 PBS 模块的全部功能，以及额外的遥测和指标收集。我们正在继续开发 Commit-Boost 的功能集，目标是在第三季度末启动生产就绪软件和审计。更多详细信息请参见 Commit-Boost repo，我们渴望获得反馈/与社区围绕这些内容进行互动。

路线图中的一些近期重点包括：

• 优化和功能正常的 MEV-Boost 模块，包括用于报告的多个指标，以及诸如 get_header/get_payload 调用的可配置计时之类的扩展
• Grafana 上所有核心服务的预制仪表板
• 改进的事件响应可靠性和集成
• R&D/规范签名机制，以适应尽可能多的验证器设置
• 扩展模块化和可选性（即支持不同类型的签名和模块）

Commit-Boost 设计原则

• 为验证者构建：该平台不仅可以帮助今天的验证者（即，即使他们只运行 MEV-Boost 模块，也可以改善验证者的生活），还可以让验证者为明天的市场做好准备（即 preconfs、包含列表等）
• 中立性：没有观点，该平台将与 proposer commitment 无关、与中继无关、与交易流无关等。目标是构建一个不限制下游设计空间，同时降低验证者和以太坊的碎片化风险的平台
• 统一性：验证者运行一个核心 sidecar，并能够选择加入许多不同的承诺
• 安全性：开源代码，由社区投入开发，并进行社区审查/审计
• 降低风险：模块化和透明度是降低 proposer 管理承诺及其更广泛运营流程的风险/开销的核心
• 价值观一致：没有货币化计划的公共产品。我们将不断问自己：Vitalik 会运行 Commit-Boost 吗？并且可以以一种增加以太坊区块构建去中心化的方式来设计它吗？

从 Proposer 的角度来看

有关作为节点运营商运行 Commit-Boost 需要执行的操作的更多详细信息，请参见此处。请注意，这尚未最终确定，并且在接下来的几周内，我们将进行更新（请参见上面的路线图/里程碑）。

• 运行一个支持 MEV-Boost 和其他 proposer commitment 协议（例如 precons/其他承诺）的 sidecar
• 开箱即用的指标报告和仪表板支持，可以通过 Grafana 等仪表板清楚地了解验证器中发生的情况
• 插入系统以添加自定义模块，例如，如果中继未能交付区块。则在 Telegram 上收到通知
• 提供签名以选择加入承诺的标准化方法
• 创建约束/条件集并将这些约束传递到下游

从 Proposer Commitment 协议/模块创建者的角度来看

有关构建模块/指标需要执行的操作的更多详细信息，请参见此处。请注意，这尚未最终确定，并且在接下来的几周内，我们将最终确定影响模块创建者的移动部分（请参见上面的路线图/里程碑）。

• 用于开发和分发 proposer commitment 协议的模块化平台
• 与验证者交互的单个 API
• 对硬分叉和新协议要求的支持

Commit-Boost 的架构

更多详细信息请参见 Commit-Boost documentation。但是，以下是 Commit-Boost 的示意图。这种建议的架构允许 proposer 运行一个 sidecar，但仍然保留选择加入 proposer commitment 模块网络的能力。更具体地说，借助此中间件，proposer 仅需要（在委托/轻量级承诺的情况下）运行一个 sidecar，并将其职责限制为仅选择他们想要订阅的模块/proposer commitment 协议。

重要的是要注意，下面的描述仅包含一些可以在 Commit-Boost 上运行的 proposer commitment 模块的示例。模块的设计空间是完全开放的/不受 Commit-Boost 软件的限制，并且 proposer 将负责选择他们希望订阅的承诺（即，proposer 负责他们将订阅的模块）。

术语

• Proposer：有权提议下一个区块的实体、质押池 NoOp 或 DVT 集群
• 承诺：proposer 选择并通过签名同意的约束或条件
• 密钥管理器：一些 proposer 使用密钥管理器或远程签名者作为其 proposer/验证者职责的一部分。请注意，Commit-Boost 的设计方式使其不需要验证者运行密钥管理器，并且正在为单体设置开发解决方案
• 共识客户端：例如，Lighthouse 或 Teku（有关更多详细信息，请参见此处）
• Commitment 模块：社区构建的模块，允许 proposer 做出承诺，包括 proposer commitment 协议的某些逻辑
• 签名者 API：签名者 API 是围绕 Commit-Boost 的核心组件之一。它用于将签名从 proposer 提供给 proposer commitment 协议。这仍在设计中，但在几乎所有情况下都将使用代理签名（有一些异常情况）。有关该 API 的更多详细信息，请参见此处。有关如何与签名者 API 通信的示例，请参见此处

\ Schematic865×516 44 KB

使用它作为中间件而不是直接修改共识客户端或为每个承诺运行一个 sidecar，将允许每个组件独立维护，并将提供跨 proposer commitment 兼容性。这也将为市场发挥作用提供一些时间，但通过公共产品，标准化最后一英里的通信，以帮助解决上述背景部分中讨论的开发风险。一旦市场发挥作用，并且社区能够观察到一些动态（好的和坏的），我们就可以并且应该推动 CL 更改。

资源

• Commit-Boost Repo

• Commit-Boost documentation

• 演示文稿列表

• ETH Research 上的原始帖子，请在此处阅读更多信息：here

• 社区的第一次演示文稿可以在此处找到

• zuBerlin 的第二次演示文稿可以在此处找到

• zuBerlin Devnet 概念可以在此处找到

• Mev-Boost 社区电话此处

• Espresso/One Balance Sequencing day 在这里（链接准备好后会更新）

• Gattaca MEV Day 在这里（链接准备好后会更新）

• Becoming Based: A Path towards Decentralised Sequencing

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