本文提出了改进以太坊核心开发者会议(ACD)、网络升级流程(NUP)和Ethereum Magicians的建议,包括引入提案状态(PFI、CFI、SFI),改进EIP审查流程,优化ACD会议结构,以及改进Ethereum Magicians平台的分类和管理,旨在提高效率和社区参与度。
PFI
、CFI
、SFI
: 起草了 EIP-7723discussion-to
模板接续 Nyota ACD 流程分组讨论,以下是一些改进 AllCoreDevs、网络升级流程和 Ethereum Magicians 的具体提案。这些提案都是多次个人和小组对话的结果,但以下所有内容均由我撰写,不应假定已被其他任何人按原样认可。
考虑到 ACD 会议持续时间相对较短且参与人数众多,我们希望优先进行与 L1 客户端和测试团队处理协议变更相关的高情境对话。也就是说,ACD 也是更广泛的社区与“核心开发者”互动的最显眼的论坛之一,我们应确保它对他们保持开放。
如今,有人在 ACD 上提出一个之前很少有人审查过的主题的情况并不少见,导致人们在会议上“立即跟进”。这是一个来自 ACD#188 的例子。
为了改进这一点,我们可以在 ACD 议程中引入“审查请求”,即默认情况下不直接在会议上讨论某个主题,而是将其标记给核心团队进行审查。一旦该项目已由至少一个客户端团队异步审查,如有必要,则可以在下次会议上更彻底地讨论。
这些后续的同步讨论可能会受到客户端团队提议在会议上讨论该主题的限制。
分组会议被广泛认为是就特定主题进行更深入讨论的一种方式,也是从客户端团队外部引入专家讨论特定主题的最佳场所。到目前为止,它们还没有被非常“模板化”。在它们之间添加一个通用结构可以帮助更好地将信息从分组会议传播回 ACD。
展望未来,分组会议可能需要:
分组会议已经混合了部分/大多数/全部这些内容,但是拥有一个通用模板(在 ethereum/pm
中解释?)将有助于保存记录并有效地在 AllCoreDevs 会议中传达要点。
在规划 Pectra 时,一些团队开始在 ACD 会议之前异步地表达他们对特定 EIP 的偏好。人们普遍认为这样做很有价值,但需要注意的是,我们希望确保治理过程仍然锚定在“大致共识”(而不是正式投票或一致同意)上,并且我们允许个人继续表达他们的意见,即使它与他们团队的大多数观点不同。
本着“大致共识”的精神,这感觉是我们应该鼓励但不形式化的事情。团队提前分享他们对重要主题的看法(理想情况下在会议前 >24 小时)使所有参与者都能进行更高情境的讨论。也就是说,我们应该允许每个团队以他们喜欢的格式/媒介来做到这一点。同样,我们应该为定性讨论留下充足的空间,而不是简单地试图量化对提案的支持/反对。
PFI
、CFI
、SFI
注意:已起草 EIP 正式提议这一点。请参阅此处的讨论。
几年前,以太坊的执行层开始使用“考虑纳入”状态来高亮显示客户端团队正在认真考虑用于网络升级但不想做出完全承诺的 EIP。该术语的灵感来自比特币核心中的 “概念 ACK”。
虽然团队仍然认为 CFI
是一种有价值的状态(CL 团队现在已经开始使用它!),但它远非完美:围绕何时应该将某些内容 CFI 化缺乏明确性,一些 EIP 从
“已提议”(这不是一种正式状态)变为“已包含”(这是),导致混乱,等等。
如今,EIP 的大致流程如下:
为了改进这一点,我提议引入一种新状态“建议纳入”,并将“已包含”重命名为“计划纳入”。
EIP 作者可以使用“建议纳入”来表示他们希望他们的 EIP 被考虑用于网络升级。要正式提议将 EIP 纳入,只需打开一个 PR 到网络升级的元 EIP 并将其列在那里即可。这消除了某人(通常是我!)在多个地方跟踪提案的需要,并为 EIP 作者提供了提案的“人工制品证明”,即到元 EIP 的 PR。
“考虑纳入”将主要保持与今天的使用方式相同,即客户端开发人员可以用来表示他们希望看到哪些 EIP 可能包含在网络升级中。
同样,对于何时应该将某些内容 CFI 化一直存在困惑。如果我们想要此状态的正式阈值,我建议“>1 个受影响的客户端团队认为这值得考虑进行网络升级”。
我们目前有一个软规则“不要在首次展示的 ACD 上将某些内容 CFI 化”。如果 PFI
是一种正式状态,这可能会放宽为“不要将尚未 PFI'd
超过 7 天的内容 CFI 化”。
“计划纳入”将取代“已包含”,以高亮显示客户端团队已承诺实施并包含在网络升级中的 EIP,除非出现重大的意外技术问题。从历史上看,由于技术问题,在实施和测试阶段已删除了一些“已包含”的 EIP。SFI
更好地传达了这种情况可能会发生。
或者,一旦网络升级上线,SFI
EIP 可能会被分类为“已包含”。
注意:已提出 EIP 的 discussion-to
线程的模板 来解决此问题。
如果能够收集和跟踪 EIP 上的审查,将使 EIP 审查请求 更好。EIP 当前具有 discussions-to
链接,这些链接指向一个难以跟踪且“隐藏”重要但未解决问题的单个论坛线程。
拥有一种让 EIP 作者和审查者征求/高亮显示/跟踪 EIP 上更正式的“审查”的方式可以帮助使异步流程更有效率。
一种简单的方法是为 EthMagicians discussion-to
线程创建默认模板,这使得 EIP 作者可以轻松地在一个地方跟踪各种审查、审计、批评等。
一个非正式完成此操作的示例是 EIP-1153 上海/坎昆线程。该模板的可能部分包括:
随着 EIP 和 ERC 存储库的分离,有机会修改 EIP 流程,以更好地满足以太坊网络升级的需求。例如,PFI
、CFI
、SFI
可以添加到 EIP 的标头中,并且可以在 eips.ethereum.org 上公开每种状态下的 EIP 列表。
这里最大的障碍是带宽:只有少数 EIP/ERC 编辑,他们很难做到超出维持流程运行的最低限度。
解决此问题的一个想法是,每个参与网络升级流程的 L1 客户端团队都自愿提供一名兼职 EIP 编辑来帮助完成该流程。
对于更广泛的以太坊社区来说,最大的问题之一是了解他们是否以及何时应该关注 AllCoreDevs。虽然 EIP 倡导者通常会尝试联系受其提案影响的利益相关者,但从历史上看,这通常会导致许多相关团队在网络升级过程中相当晚的时候才意识到某项提案。
需要更深入讨论和社区参与的提案的一个很好的代理是“导致分组会议的提案”。然后,一个简单的改进可能是在 Ethereum Magicians 上宣传过去和即将到来的分组会议,可能有一种方式让用户专门订阅这些帖子。
例如,该网站可以显示一个横幅,其中包含即将到来的分组会议及其主题,或者每周/每两周/每月的帖子可以链接到所有最近的分组会议以及后续对话发生的地方。
Ethereum Magicians 帖子类别 需要一些改进。虽然许多类别被定期使用并且被很好地理解(例如,EIPs
、last-call
等),但其中一些类别已过时(Working Groups
、Ethereum 1.x
等),含糊不清(Primordial Soup
),或者根本未使用(Sharding
、Address Space Extension
)。
创建一套新的类别,使 Ethereum Magicians 的常规用户和更普通的 Casual 用户都觉得有用,将有助于使 Ethereum Magicians 成为这两种类型用户的中心枢纽。理想情况下,用户还可以通过各种方式“关注”这些类别,例如通过每个类别的电子邮件通知/摘要,甚至像自定义 Lens/Farcaster 频道或 Twitter 机器人等,这些频道或机器人会分享其中的新活动。
与 EIP 流程类似,维护人员带宽是使 Ethereum Magicians 变得更好的主要障碍。为了反映 Ethereum Magicians 既是更广泛的以太坊社区的资源,也是核心 L1 研发贡献者的资源,我们应该考虑制定一个开放流程来添加可以代表这些不同利益相关者群体的维护人员。
- 原文链接: ethereum-magicians.org/t...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!