Alert Source Discuss
Meta

EIP-7329: ERC/EIP 仓库拆分

将 ERC 规范从 EIP 仓库中分离到一个新的仓库中，以便只保留核心协议 EIP

Authors Lightclient (@lightclient), Danno Ferrin (@shemnon)
Created 2023-07-13
Requires EIP-1

Table of Contents

摘要

描述了将 EIP 仓库拆分为一个针对以太坊核心变更的 EIP 仓库和一个针对应用层规范的 ERC 仓库的动机和理由。

动机

很久以前，当创建 EIP 仓库时，有一个愿景是为所有与以太坊相关的标准提供一个统一的家。当时的社区很小，大多数人都在生态系统的各个层面进行互动。将应用标准与核心共识变更结合起来是有意义的。

此后，生态系统不断发展。今天，应用开发和核心开发之间的鸿沟越来越大。参与整个生态系统的人越来越少（无论好坏）；但仓库仍然是统一的。

多年来，我们一直在考虑分离仓库。这将使 ERC 和 EIP 规范能够更自然地发展，因为它们是独立的。但要达到实现这种改变的关键阈值总是很困难。每次我们都会迷失在迁移的细节中，争论使进展停滞不前。

现在共识层也在使用 EIP 流程，裂缝变得越来越明显。我们可以对流程进行一些更改，这可能会使它们受益更多，但是由于我们还需要确保 ERC 的质量，因此我们受到了限制。

还有更多的努力来促进围绕 ERC 流程的应用。已经尝试为某些 ERC “类别” 开发工作组和审查组（由于统一的仓库，这种区分在技术上甚至不存在）。

规范

本规范仅详细说明拆分的初始机制。每个仓库如何管理自身的细节超出了本 EIP 的范围，因为本 EIP 的动机是社区的不同需求将需要高度不同的方法。

  1. 从此仓库中删除所有 ERC 和 Interface 类别的 EIP，并迁移到新的仓库。历史记录应保持完整，以便该仓库应从此仓库派生，并删除非 ERC。
  2. 新的 ERC 仓库上线，并包含脚本中的更改。
  3. 设置 ercs.ethereum.org 子域名，并更新 CI 以指向 ERC 仓库。
  4. 在 eips.ethereum.org 上设置 ERC 重定向到新网站。
  5. 创建一个统一的文档，供编辑分配 EIP/ERC 编号。EIP 和 ERC 将不再基于初始 PR 编号，而是基于 EIP 编辑在其各自仓库中递增的编号。EIP 将被分配偶数，ERC 将被分配奇数。此迁移的确切时间是编辑的策略决定。

EIP 仓库将与核心协议更改相关联，特别是那些将在 AllCoreDevs 调用中讨论的那种；而 ERC 仓库将与所有剩余领域相关联，例如智能合约应用程序接口、钱包标准、DeFi 协议标准以及所有其他不需要核心协议更改的改进。

这种关联将在 EIP 编辑可能引入的任何其他流程更改中持续存在，例如工作组、主题组、专家组、特殊利益集团、流程拆分或其他此类更改。任何包含核心协议更改的子组将与 EIP 仓库相关联，其他子组将与 ERC 仓库相关联。任何此类流程更改均超出本 EIP 的范围，并且独立于本 EIP 中指定的仓库的结构更改。

仓库布局可能存在进一步的结构更改，以适应更多的子组。此类提案超出本 EIP 的范围。

理由

EIP 流程服务于两个主要的社区，它们的需求高度不同且差异很大。

让我们考虑一下规范歧义的影响，这些影响因社区而异。核心协议社区对实现的差异容忍度很低，并且对规范歧义的惩罚很高。新规范中未正确实现的部分可能会导致以太坊主网分裂，可能导致节点运营商以及使用以太坊协议提供的服务的社区成员损失数百万甚至数十亿的价值。然而，一个规范不佳的 solidity 接口可以在任何选择实现它的智能合约中以多种兼容的方式进行调整和实现。缺少 RPC API（例如指定链原生货币中小数位数的配置选项）对不选择使用该钱包的社区的其余部分的影响可能有限甚至为零。

交付功能的时间范围也同样不同。调整交易数据的 gas 成本的核心协议 EIP 需要在整个网络中以特定的时间统一推出。而支持 gas 估算新语义的新 RPC 不需要在以太坊客户端上统一推出，事实上，还需要由为以太坊网络提供 RPC 服务的服务提供商推出。钱包可以使用早期支持作为其吸引社区成员的差异化因素。

为了解决这种差异，AllCoreDevs 调用已采用与 EIP 仓库的 Draft -> Review -> Last Call -> Final 生命周期不同的 EIP 生命周期。最好将其描述为 Draft -> Eligible for Inclusion -> Considered for Inclusion -> Testnet -> Mainnet。EIP 还在第三步中为 fork 安排了位置，这是一种根本不适用于智能合约或钱包标准的考虑因素。

已经提出了几种替代方案，但是实际的实现只会进一步强调拆分的每一方遇到的专业化。

替代方案：工作组

编辑们反复担心的一个问题是，他们经常缺乏足够的技术经验来充分判断 EIP 是否完整和合理。考虑到 EIP 涵盖了广泛的主题，例如椭圆曲线密码学、VM 性能、DeFi 市场动态、压缩协议、NFT 版税和共识协议，单个编辑不可能对所有这些主题提供明智的反馈。

但是，当检查核心协议和 ERC 社区将如何处理工作组流程时，它强调了它们将如何以不同的方式处理它。对于核心协议更改，工作组将是两个 AllCoreDevs 会议之一，即 AllCoreDevs-Execution 或 AllCoreDevs-Consensus。有时两者都是。没有 EIP 会在主网上发布，而没有首先由这两个组之一进行广泛考虑。

ERC 提案没有这样的常设组。影响钱包的更改可能会通过 AllWalletDevs 组进行，但是钱包或一组钱包完全有可能在 AllWalletDevs 之外协作开发协议。智能合约 API 没有这样的常设会议。

但是，工作组模型对于 ERC 社区将是一个重要的社会信号。如果足够多的专家可以聚集在一起同意审查一组更改，它将为特定的提案问题发出临界质量的信号。

虽然工作组对于 ERC 社区来说非常出色，但对于核心协议社区来说，这是一种开销，只会给已经建立的具有已知治理检查点的流程增加摩擦。

替代方案：专业编辑

此替代方案已通过引入 eip-editors.yml 文件来实现。这允许不同的编辑组审查不同类型的 EIP。

对社区的分歧没有产生可衡量的影响。大多数类别与其他类别有显着的重叠。

此替代方案没有解决核心协议开发人员想要实施的治理和工作流程问题。所有子组仍将受到与其他组相同的工作流程的约束。

替代方案：与流程差异无关的痛苦

这是许多提案的总称，从允许在 discussion-to 中使用 discord 链接到允许在外部链接中拥有更大的自由度。

虽然理论上这可能会减少用户和编辑所感受到的痛苦总量，从而使痛苦程度降低到更可接受的水平，但这并不能解决核心分歧问题。无论 EIP 仓库是否拆分，许多这些缓解痛苦的提案都应该完成。

替代方案：用 AI 聊天机器人替换 EIP 编辑

在这个提案中没有人会赢。我们最终将争论训练集、竞争性实现以及是否使用商业提供商。如果事情进展顺利，那也就算了。

但是，如果所有裁决都由一个模型或一个聊天会话处理，那么 AI 聊天机器人将无法区分多个组的不同需求。如果为每个主要功能区域使用单独的培训仓库，则将收到更高质量的输出。

替代方案不是互斥的

重要的是要注意，大多数讨论的替代方案都具有优点并且解决了重要的痛点。采用拆分不应被视为拒绝这些替代方案。用一句著名的互联网 meme 来说“为什么不两者兼得？”

反对意见：这将分裂以太坊社区

一种反对意见是，拆分仓库将导致社区无法再说“我们都是以太坊魔法师”。

首先，重要的是要注意到这种拆分已经发生。AllCoreDevs 调用已拆分为共识层和执行层调用。ACD 调用不再讨论像钱包 apis 这样的客户端问题，AllWalletDevs 调用已经采用了这些问题，并且已经发展成为用户体验问题。跨链问题已被 Chain Agnostic Improvement Process (CAIP) 组采用。

与其说这是分裂，不如说应该将其视为“分片”，其中有共同兴趣的子社区围绕一个共享的子问题聚集在一起，并通过聚集能够增加社区的总范围。CAIP 是一个完美的例子，它表明独立于 EIP 运作使他们能够加强以太坊社区。

当一个单细胞生物长大然后分裂成两个时，它会变弱吗？当细胞分裂并专门用于不同的任务时，动物会变弱吗？正是这种分裂和专门化的行为使它能够完成作为单个统一细胞不可能完成的事情。

反对意见：这应该是一个 EIP-1 提案

由于这直接影响 ERC 流程，因此应首先在 EIP-1 中记录。

正如旧的编程格言所说：“在添加任何新功能之前先进行重构。” 添加特定于拆分后管理文档的新流程只会混淆现有流程，为一类不适用于另一类的 EIP 添加特殊情况。这正是拟议拆分旨在改变的那种问题。

这也是 Meta 类别 EIP 的有效理由，因为在多少个以及哪个仓库中放置提案是“程序、指南、[和]决策过程的更改”的核心。

核心协议 EIP 中可能预期的一些流程更改可能包括：

  • 更改工作流程以将“Eligible for Inclusion/Considered for Inclusion”阶段添加到 pre-last-call EIP。
  • 将测试网和主网步骤添加到生命周期
  • 向 RFC 部分添加“fork”标头，用于在特定 fork 中实现（或将要实现）的 EIP
  • 将测试部分更改为引用测试的标头链接

ERC 可能想要采用的一些流程更改：

  • 强大的工作组模型并添加一个可选的“组建工作组” 编辑可能需要的步骤。
  • 为未来规范废止的 EIP 添加“过时”或“已替换”生命周期步骤。
  • 委派单个 eip 审查员来审查特定的 EIP

反对意见：对仓库的结构性更改和流程更改无需捆绑在一起。

可以将仓库的结构与与此相关的任何 EIP 流程更改分开拆分。捆绑更改是不必要的，并且此类结构和流程更改应独立处理。

为了适应此反对意见，本 EIP 已被修改为仅解决仓库中的结构性更改，并且可以适应任何其他独立的流程更改并映射到这些结果。

向后兼容性

旧链接

指向旧网址 https://eips.ethereum.org/ 的旧 ERC 链接将继续有效。将实施重定向说明，以将其重定向到其相应位置的新 ERC 仓库。

走失的提案

ERC 社区成员可能会继续在 EIP 提案中发布新的 ERC。编辑将能够将它们重定向到新的仓库。无论如何，不响应编辑请求的 ERC 都不会被合并。

安全注意事项

本提案仅涉及 EIP 和 ERC 提案流程，预计不会因其采用而暴露任何新的攻击面。

版权

在 CC0 下放弃版权及相关权利。

Citation

Please cite this document as:

Lightclient (@lightclient), Danno Ferrin (@shemnon), "EIP-7329: ERC/EIP 仓库拆分," Ethereum Improvement Proposals, no. 7329, July 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7329.