EIP-7577: EIP 版本控制方案
基于对其规范部分所做的更改，为 EIP 使用版本控制方案。
| Authors | danceratopz (@danceratopz), Ahmad Bitar (@smartprogrammer93) |
|---|---|
| Created | 2023-12-13 |
| Discussion Link | https://ethereum-magicians.org/t/add-eip-versioning-scheme-for-eips/17295 |
摘要
本 EIP 通过应用 Semantic Versioning 2.0.0，基于对 EIP 规范部分所做的更改，在其状态从 Draft 变为 Review 后，为 Standards Track EIP 引入版本控制方案。
动机
EIP 规范通常会随着更多人的审查而收到越来越多的修改，通常情况下，当客户端团队开始实施规范并且社区对规范与协议其余部分的交互有了更好的理解时，情况就是如此。这些更改可能难以跟踪。特别是，由于 EVM 参考测试通常不由客户端团队或 EIP 的作者维护（并且通常不发布），因此很难确定参考测试的版本是否足以测试最新版本的 EIP 规范，或者甚至是否有效，或者规范当前由客户端实施的情况。
本 EIP 提出了一种语义版本控制方案，并为 EIP 添加了一个 CHANGELOG 部分，以便在社区内实现更清晰的沟通，并允许乍一看就能确定更改的范围。此外，客户端实施和测试工具链可以查询 EIP 更改，并自动标记 EIP 当前规范与客户端和测试实施之间的不兼容性。
规范
本文档中的关键词“必须”、“禁止”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”应按照 RFC 2119 和 RFC 8174 中的描述进行解释。
一旦 EIP 移出“草案”状态，它必须使用下面概述的 EIP 版本控制方案。它可以在“草案”状态下已经使用该版本控制方案，如果规范正在积极实施，这可能很有用。如果多个团队正在实施该规范，建议将 EIP 的状态更改为“审查”。
EIP 版本控制方案必须应用以下 MAJOR.MINOR.PATCH 的语义版本控制方案，基于 Semantic Versioning 2.0.0：
MAJOR: 对规范的重大更改，需要实施更改和对参考测试的更改。MINOR: 对规范的添加，需要额外的实施和额外的测试覆盖率添加到参考测试中。PATCH: 对 EIP 的任何外观更改或重新表述，而无需更改规范。
在 EIP 移出草案状态并进行版本控制之前，版本号最初必须具有 MAJOR 版本 0。
对于通过对 ethereum/EIPs 的拉取请求 (PR) 对 EIP 所做的每次更改，必须将一个新条目添加到 EIP 的 CHANGELOG 部分，其中概述了 PR 中所做的更改。此 CHANGELOG 条目必须包括以下内容：
- 一个遵循上述语义版本控制方案的新版本号。
- 引入更改的日期。
- 实施更改的 ethereum/EIPs PR 编号。
- EIP 规范的每个更改行，包括更改的简短说明。
此外，必须将新版本添加到 EIP 的 markdown 文件的元数据标头（添加到新的“版本”字段），以便可以轻松解析它。
必须将工具添加到 ethereum/EIPs 存储库，以帮助 EIP 作者应用版本控制方案。此工具应自动执行以下操作：
- 更新 EIP 的 markdown 文件的元数据标头中的 EIP 版本。如果 EIP 的状态从“草案”更改为“审查”，则版本必须更新为
1.0.0。 - 根据 EIP 版本和 PR 的标题添加新的 CHANGELOG 条目。
为了允许该工具进行这些更改，EIP 作者必须在推送到 PR 分支的其中一条提交消息中指示更改的范围。范围通过以（“[Mm]ajor:”、“[Mm]inor:”或“[Pp]atch”）开头的一条提交消息来指示。多个提交消息可能包含范围；在这种情况下，将应用最严重的范围更改。如果在任何提交消息中都无法检测到范围，则阻止 PR 的合并，直到将此类提交消息推送到 PR。
理由
使版本在 EIP 的元数据标头中可用，允许参考测试或客户端团队中使用的工具对版本号进行编程解析。目前，execution-spec-tests 存储库（其中包含以太坊执行客户端的共识测试）实现了基本的 EIP 版本检查器：EIP 规范测试需要声明测试实施所基于的 EIP markdown 文件摘要 SHA。然后通过 Github API 轮询摘要 SHA 的当前值，以验证自测试实施以来是否发生了任何更改。虽然这为测试实施者提供了一个 EIP 已更改的警告，但显然用途有限。
如本 EIP 定义的，更丰富的版本控制方案可以为测试工具链提供很多价值。客户端团队可以提供一个接口，报告当前实施的 EIP 版本，并且参考测试可以在生成的测试中将它们实施的版本指定为元数据。这允许测试运行程序将测试标记为 xfail（预期失败）并发出警告，如果 MAJOR 或 MINOR 版本不匹配。甚至可以自动选择要针对客户端实施运行的参考测试的正确版本，但考虑到以太坊开发的步伐，维护和跟踪多个版本的测试可能是不切实际的。
案例研究
本节探讨如何将版本控制方案应用于撰写本文时最近正在积极开发的现有 EIP 作为示例。
EIP-4788 的历史记录包含对其规范的许多更改。EIP-4788 在 2023-11-28 更新为状态“审查”。但是，此案例研究假设 EIP 从 2023-04-11 起移至状态“审查”，并由于客户端团队实施的开始而更新为版本 1.0.0。
更新日志
- 9.0.1 - 2023-09-26：更新新环形缓冲区大小的环形缓冲区大小基本原理，#7786。
- 9.0.0 - 2023-09-26：审计后调整，#7672。
- 验证时间戳是否为非零。
- 使
HISTORY_BUFFER_LENGTH为质数 (8191)。 - 加载一次 calldata。
- 更新
BEACON_ROOTS_ADDRESS。
- 8.0.1 - 2023-08-28：4788 清理，#7532。
- 8.0.0 - 2023-08-24：首次尝试 v2，#7456。
- 要求时间戳输入正好为 32 字节。
- 如果时间戳输入与存储的值不匹配，则还原（而不是返回零字）。
- 删除预编译概念，使用带有提供的字节码的常规智能合约。
- 7.0.3 - 2023-08-01：提及没有现有信标块根案例的创世块，#7445。
- 7.0.2 - 2023-07-07：明确指定标头架构，#7297。
- 7.0.1 - 2023-07-07：修复拼写错误，#7293。
- 7.0.0 - 2023-07-05：绑定预编译存储，#7178。
- 6.0.1 - 2023-06-13：阐明标头和有效性部分，#7179。
- 6.0.0 - 2023-06-12：更新预编译地址，#7173。
- 5.0.0 - 2023-05-31：通过根键入信标根，#7107。
- 4.0.0 - 2023-05-24：偏向于有状态的预编译而不是操作码，#7065。
- 3.0.0 - 2023-05-17：从 CL 发送当前插槽以避免时间戳转换，#7037。
- 2.0.1 - 2023-05-15：修复拼写错误，#7005。
- 2.0.0 - 2023-05-03：更新操作码以避免冲突，#6980。
- 1.0.1 - 2023-04-13：小问题，#6870。
- 1.0.0 - 2023-04-11：使用区块根；更新为状态“草案”，#6859。
- 由于客户端实施（NethermindEth/nethermind#5476）而更新为“草案”。
- 使用区块根而不是状态根。
- 根存储由插槽键入。
- 在状态中使用环形缓冲区。
- 使用标头时间戳来派生插槽号，而不是消耗额外的标头空间。
- 0.2.1 - 2023-02-04：更新为状态“停滞”，#6432。
- 0.2.0 - 2022-06-29：将“信标块根”重命名为“信标状态根”，#5090。
- 0.1.1 - 2022-05-06：强制使用包含的 LICENSE 文件，#5055。
- 0.1.0 - 2022-02-17：添加 EIP-4788：EVM 中的信标状态根，#4788。
向后兼容性
没有必要追溯添加在本 EIP 引入之前版本的 EIP 的 CHANGELOG 或版本。在对 EIP 的规范部分进行下一次更改时，作者必须引入一个 CHANGELOG 部分和一个遵循上述语义版本控制方案的版本号。
安全考虑
无。
版权
版权及相关权利通过 CC0 放弃。
Citation
Please cite this document as:
danceratopz (@danceratopz), Ahmad Bitar (@smartprogrammer93), "EIP-7577: EIP 版本控制方案 [DRAFT]," Ethereum Improvement Proposals, no. 7577, December 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7577.