编写 ERC 指南

• 原文链接：https://x.com/jtriley_eth/status/1803811612773781914
• 译者：AI翻译官，校对：翻译小组
• 本文永久链接：learnblockchain.cn/article…

编写 ERC 在理论上很简单，但需要深思熟虑、细致入微和极其清晰的写作。我们将探讨创建 ERC 规范的哲学、过程和其他有用的细节。

哲学

不言而喻，但值得重复的是，以太坊请求评论（ERC）的目的是什么。ERC 限制了智能合约的接口，它对该合约的形状、公开共享的信息、谁可以更改什么以及大致如何更改进行了限制。

ERC 应该尽量减少限制，也就是说，对合约施加的约束应该恰好是实现 ERC 愿景所必需的，不能多余。在讨论阶段（详见下文）中，预计会有来自不同领域的人物，从应用层开发人员到安全研究人员再到形式的无效讨论者。每个人都会提出更改或添加建议，重要的是要倾听和解决每个人的意见。然而，功能蔓延从未远离，因此必须有一个清晰的愿景，了解 ERC 应该实现什么，以及建议的更改是否支持这一愿景。没有约束的设计空间是无限的，每个约束都会减少它；实现者应该在设计空间内拥有最大的灵活性，以使他们的想法蓬勃发展。

模糊性影响每个人，一个开放式或不明确的约束可能导致巨大的后果。每个阅读规范的实现者、审计员和技术作家都会感受到定义不明确、约束不足或措辞不当的声明的影响。这可能是固有安全和不安全实现之间、一致性和碎片化之间、采用和放弃之间的区别。超越最低可行的清晰度，使用高度一致的措辞编写规范有助于为读者建立和使用直觉。当为了保持一致性而重新措辞时，可能看起来冗余或乏味，但这种冗余正是允许读者在没有因相同想法的不同措辞而产生疑虑的情况下匹配模式的原因。

过程

该过程在第一个以太坊改进提案中有所描述，EIP-1，但大致可以分解如下。

首先在 Ethereum Magicians 论坛上发帖，然后是 ERC 草案、迭代和更改、最终确定，然后是实施。

论坛讨论

论坛讨论将会很长，并且会一直延续到 ERC 最终确定。当然，它应该以一个哲学目标开始，这将作为决定应该包含什么和应该删除什么的参考点。如上所述，会有许多不同领域的参与者，他们对 ERC 的外观和行为有许多不同且经常相互冲突的想法。哲学介绍帖是这里的北极星。同样重申上述内容，在不妥协愿景的情况下最大化设计空间是关键。

ERC 起草

从 ERC 仓库中的 ERC 模板开始。

标题部分相当简单，然而，表格中的“requires”列应包含实现此 ERC 所需的任何其他 ERC。例如，ERC-721 需要 ERC-165 接口中的功能。

摘要部分包含 ERC 的高级摘要。摘要不应涉及 ERC 的理由或动机，它纯粹是一个摘要。同样，文档的其他地方不应有“摘要”部分，如果有需要总结的内容，应在此处。

动机部分是放置设计哲学、背景和为什么这应该成为标准的理由的地方。这是文档的核心和灵魂，它应该是宗教性的，它应该是宣言，它应该展示规范的天命。通常，标准是从其他标准或其他作品中派生或受到启发的，这些应在此提及。

规范部分是三明治的主要部分。它以以下内容为前缀。

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”应按照 RFC 2119 和 RFC 8174 中的描述进行解释。

RFC-2119

规范指出，MUST、REQUIRED 和 SHALL 是绝对要求，SHOULD 和 RECOMMENDED 是强烈建议，MAY 是完全可选的。

RFC-8174

仅要求这些关键词以全大写字母表示，以使其使用不模糊。请注意，任何属于 SHOULD、RECOMMENDED 或 MAY 的内容在实现合约中永远无法保证。这是一个重要的区别，通常应尽量少用。

函数和事件应占据各自的小节，包含其签名的规范以及相关行为。建议使用 YAML 来指定每个签名，如元 EIP 中定义的那样，

EIP-2069

这是一种干净且清晰的方式来指定接口，而不依赖于任何一种语言的语法，这些语法在最终确定后可能会发生变化。标准的扩展也应位于规范部分。

理由部分应包含规范部分中特定实现细节的原因。请注意，这与动机不同，动机部分是 ERC 的广泛理由，而理由则更具体到实现细节。

向后兼容性部分应包含任何兼容性影响，例如从旧标准迁移、更改现有标准以及如何处理同时适应两者的协议（如果适用）。

测试用例部分.. 🤷.. 个人建议省略这一部分。可能没有合理的方法来编写语言和框架无关的测试用例，准确捕捉每个约束，并保持规范的简洁性。一个定义明确的规范应该可以轻松转换为测试用例。

参考实现必须在创作共用许可（CC0-1.0）下，一般但不一定用 Solidity 实现，并且应优先优化可读性和清晰度。实现者将使用他们自己的实现或流行智能合约库的实现。

安全考虑部分应包含规范或外围的任何可能的陷阱、误用或边缘情况。安全研究人员几乎肯定会在论坛中提供一些值得添加的反馈。

迭代

迭代和更改通常应小而渐进。好的 git 提交消息在这里很有帮助。持续集成（CI）管道相当简单，它检查基本的内容，如格式、拼写和 EIP-1 中指定的其他规则。

在一个独立的仓库中实现 ERC 并进行广泛测试，允许其他人快速实验。然而，必须确保该仓库与规范保持一致。请记住，规范的任何更改也必须反映在参考实现部分。理想情况下，独立仓库应包含 ERC 中参考实现的复制粘贴版本。这最小化了断开连接，并允许进行彻底的测试和审查。

最终确定

在草稿阶段完成后，ERC 应该通过更改头部信息进入审查阶段。此时 CI 过程变得更加严格，ERC 审查员将根据文档本身的格式、措辞、布局和结构提供反馈并要求更改，而不是根据 ERC 本身的优点。这需要一些时间，因为他们需要管理很多 ERC。在审查之后是最后通牒阶段，这提供了 14 天的时间来请求任何其他更改，然后是最终阶段。

其他事项

创建一个成功的 ERC 远不止规范本身。一旦规范最终确定，就该开始实施和宣传了。实现应该存在于几种不同的编程语言中，每种语言根据库的不同有不同的权衡。这些权衡可能最大化模块化、gas 效率或可读性。联系流行智能合约库的维护者并协助实施和测试也是一个好主意。一旦有可用的实现，联系那些可能受益的团队。寻找那些希望进入该领域的新公司，并为他们提供获得潜在优势的手段。会有很多“拒绝”的回复和很多接近成功的情况，但只需要几个好的实施者就能成功。然而，虽然不言而喻，但在宣传时要合理地礼貌和尊重。不要像 Nick Mudge（EIP-2535作者，译者注）那样。

最后，对于那些主要为了品牌、社会资本或形式化而希望创建 ERC 的公司，这是可以的，但请记住，ERC 是为所有人服务的，它们是为了 EVM 上智能合约协议的模块化和可扩展性，而不是为了给某个应用程序带来流量或收入，这些文档应该得到应有的尊重。

结论

编写一个好的 ERC 需要很多工作，这里没有包括很多内容。有些东西必须在过程中学习，不过希望这有助于从高层次上分解这个过程，并为任何希望标准化想法的人提供机会。虽然这里有很多聪明的人在做很多事情，但即使在撰写本文时，也有很多高影响力的 ERC 的简单机会。

我是 AI 翻译官，为大家转译优秀英文文章，如有翻译不通的地方，在这里修改，还请包涵～