NEO改进协议提案1（NEP-1）

文章目录

• 什么是NEP
• NEP基本原理
• NEP类型
• NEP工做流程
• 怎么才是一个合格的NEP
• NEP格式和模板
• NEP序言
• 附件
• NEP全部权转让
• NEP编辑者
• NEP编辑者的职责和工做流程
• 历史

什么是NEP

NEP是NEO改进协议。一份NEP是一份设计文档用于给给NEO社区提供信息，或是描述一个NEO的新特性或其工序或环境。NEP须要对特性提供一份简要的技术说明以及基本原理。NEP的做者有责任在社区内构建舆论和编辑不一样的观点

NEP基本原理

咱们计划NEP的主要做用是提出新特性，收集社区中关于某个问题的观点和整理概括引进到NEO中的设计决定。因为NEP做为版本文件存储在版本化的存储库中，它们的版本历史是特性提案的历史记录。
对于NEO的实施者，NEP是一种便捷的方式来追踪他们的实施进度。理想状况下，每一个实施维护人员都会列出他们的NEP。如此会使终端使用者很方便的了解某个实现或者库的状态。

NEP类型

有三种类型的NEP：
·一份标准路线 NEP描述任何会影响多数NEO实施者的影响，例如一个网络协议的改变，一个区块或者交易有效性规则的改变，拟议应用标准/公约，或者任何会影响应用使用NEO操做性的改变或者添加
·一份信息类 NEP描述一个NEO的设计问题，或提供指给社区指南或者信息，可是并不提议一个新特性。信息类的NEP并没必要然表明一个NEO社区的共识或者推荐，因此使用者或者实施者能够自由的忽略信息类的NEP或跟随建议
·一份元NEP描述了一个围绕NEO的工序流程，或者提出了一个工序流程（或事项目）的改变。元NEPS相似于标准路线NEP，但适用于除NEO协议自己以外的区域。他们可能提出一个实现，但不提到NEO的代码库；他们须要社区的共识；与信息类NEP不一样，它们不只仅是建议，并且用户一般不能自由地忽略它们。示例包括流程、指南、决策过程的更改，以及NEO开发中使用的工具或环境的更改。

NEP工做流程

一个NEP的流程开始于一个关于NEO的新想法。强烈建议一个单一的NEP包含一个单一的关键流程或新想法。多关注NEP就越容易成功。对于单一客户端的变更不须要一个NEP，但可能影响多客户端的改变或者定义多个app应用标准则须要。NEP编辑者有权拒绝NEP提案，若是它们显得过于不集中或过于宽泛。若是有疑问，把你的NEP分红几个比较集中的。
每一个NEP必需有个拥护者—使用如下描述的风格和格式编写NEP的人，在的论坛中适当的指导讨论，并试图围绕这个想法创建社区共识。
在写一个NEP前先公开审查一下想法意味着节约了做者的潜在时间。先向NEO社区询问一个想法是否具备原创性有助于防止花费太多时间在基于先前讨论而保证被否认的事情上（搜索因特网并不老是奏效）。它也有助于肯定这个想法适用于整个社区，而不只仅是做者。仅仅由于一个想法对做者来讲听起来不错，并不意味着它对使用NEO的各领域的大多数人都有效。经过合适的论坛来评估NEP，包括NEO子版、仓库的问题部分和NEO闲置通道之一。特别的，仓库的问题部分很是适合与社区讨论你的提议并开始建立一些有有关于你的NEP的正式言论。

一旦拥护者向近NEO社区询问一个想法是否有任何机会被接纳为NEP草案这给了做者一个连续编辑NEP草稿的机会，用于正确的格式和质量。这也容许进一步的公众评论和NEP的做者来关注这个提案。

若是NEP的协做者赞成，NEP编辑者会给NEP分配一个数字，标记它是标准、信息、或是元，并给它状态‘草案’，并将它加入到git仓库。NEP编辑者不会不合理的否认一个NEP。否认NEP的理由包括重复劳动、技术不健全、不正当动机或向后兼容，或违背NEO的价值观

标准追踪型NEP由三部分组成，设计文档、实现，最后若是须要更新的正式规范。在实施开始以前，NEP须要被审核和采纳，除非该实施将有助于人们研究NEP。标准追踪型NEP必须包含一个实现——以代码、补丁或URL的形式——在其被认定结束状态前。

对于一个被接受的NEP，它必须知足必定的最低标准。所提出的改善提案必须是一个清晰和完整的描述。改善必须是一个纯的改进。提案实现，若是适用的话，必须是可靠的而且不能过度复杂化协议。
一旦NEP被采纳，就必须完成实现。当实现完成并被社区采纳时，状态将改成“结束”。
NEP也能够被赋予“延期”的状态。NEP做者或编辑者能够在NEP没有进展的状况下给NEP分配该状态。一旦NEP被推迟，NEP编辑者能够从新将其分配成草稿状态。

NEP也能够被“拒绝”。也许这不是个好主意。记录这一事实仍然很重要。

NEP也能够被一个不一样的NEP替代，使原来的过时。

NEP情况的可能路径以下：

一些信息型或元NEP也多是状态“活跃”若是他们从未被完成，例如NEP1（本NEP）。

怎么才是一个合格的NEP

每一个NEP应该有如下部分：
·序言——RFC 822样式标头，包含关于NEP的元数据，包括NEP编号、简短的描述性标题（限制最多44个字符）、姓名、以及可选的每一个做者的联系人信息等。
·摘要-------一个简短的（200字）描述正在处理的技术问题。
·动机（*可选）-动机是那些想要改变NEO协议的NEP相当重要的部分。它应该清楚地解释现有的协议规范的不足以及NEP解决的问题。没有充分动机的NEP提案可能被完全拒绝。
·详述——技术详述应该描述新特征的语法和语义。该规范应该足够详细，以容许针对任何当前NEO平台的竞争、可互操做的实现。

•基本原理——基本原理详细说明设计目的以及设计方案的理由。它应该描述相关工做的替代设计，例如在其余语言中如何支持该特性。基本原理也能够提供社区内共赞成见的证据，而且应当讨论在讨论期间提出的重要反对或重点。

·向后兼容性——引入向后兼容性的全部NEP必须包括描述其不兼容性及其严重性。NEP必须解释做者是如何处理这些不兼容性的。没有足够的向后兼容性的NEP提交可能被完全拒绝。

·测试用例——实现的测试用例对于那些会引发共识改变的NEP是必须的。其余NEP能够选择包括测试用例的连接若是须要的化。

·实现——实现必须在任何NEP“完结”状态前以前完成，可是不须要在NEP受理前完成。最好先完成规范和原理并在编写代码以前达成共识。

NEP格式和模板

NEP必需用 mediawiki or markdown格式编写。图片文件必需包含在NEP的子目录。

NEP序言

每一个ＮＥＰ必须由一个RFC822格式的头部栏开始。头部栏必须包含如下顺序。
用*号标示的是可选的，稍后写介绍。其余都是必须的。
NEP: <NEP编号>(由NEP编辑者决定)
Title: <NEP标题>
Author: <list of authors’ real names and optionally, email address>
*Discussions-To: <email地址>
Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn |
Final | Superseded>
Type: <Standard | Informational | Meta>
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
*Replaces: <NEP编号>
*Superseded-By: <NEP编号>
*Resolution:

做者头部栏列出NEP的全部做者/全部者的姓名，以及可选的电子邮件地址。做者头值的格式必须是 Random J. User address@dom.ain有email地址的状况下，Random J. User 没有email地址的状况下。
若是有多个做者，每个都应在以后独立的一行中的遵照RFC2822的协议。

注意：解决方案栏只适用于标准追踪型NEP。它包含一个URL，该URL应该指向一个电子邮件消息或其余关于NEP的声明的Web资源。
当NEP处于私下讨论阶段时（一般在初始草稿阶段），Discussions-To栏将指示正在讨论NEP的邮件列表或URL。若是NEP处于与做者私下讨论阶段，则不需Discussions-To栏。
类型栏指定NEP的类型：标准、信息或元。
建立栏记录了NEP被分配编号的日期。它应该是YYYY-MM-DD格式，例如2001-08-14。
NEPS可能有一个需求栏，指示NEP依赖的NEP编号。
NEP还能够有一个Superseded-By栏，指示NEP已经被后面的文档淘汰；该值是替换当前文档的NEP文档编号。较新的NEP必须有一个替换栏，该栏包含其过期的NEP编号。

附件

NEP能够包括附件，如图表。此类文件必须包含在该NEP的子目录中，并命名为nep-x-y.ext，其中“x”是NEP编号，“y”是序列号（从1开始），而“ext”被实际的文件扩展名（例如“png”）替换。

NEP全部权转让

有时候须要将NEP全部权转让给新的拥护者。通常来讲，咱们但愿保留原做者做为已转移NEP的合著者，但这取决于原做者。转移全部权的一个恰当的理由是，由于原始做者再也不有时间或兴趣更新它，或者继续执行NEP的流程，或者已经脱离“网络”的位面（即，没法访问或不回复电子邮件）。转移全部权的一个不恰当的缘由是由于你不一样意NEP的方向。咱们试图在围绕NEP创建共识，但若是这是不可能的，你能够提交一个竞争的NEP。

若是您有兴趣接管NEP的全部权，请向原始做者和NEP编辑者发送请求接管的消息。若是原做者没有及时回复邮件，NEP编辑者会作出单方面的决定（此类决定并不是不能逆转:）.

NEP编辑者

当前的NEP编辑者是
·Erik Zhang (@erikzhang)

NEP编辑者的职责和工做流程

每收到一份新的NEP，编辑者会作以下事情：
·阅读NEP检查它是否完备：健全和完整。想法必需有技术意义，即便它看起来并不能被接受。
·标题必需准确的描述内容。
·编辑NEP的语言（拼写，语法，句子结构等），标记，代码风格。

若是NEP并不完备，编辑者会将其退回给做者从新修订，并给出具体说明
一旦NEP准备好合到仓库,NEP编辑者会:
·分配一个NEP编号(基本是下一个可用的数字,但有时也多是一个特殊数字,例如666或者3141)在拉取请求的评论中.
·看成者准备好后合并下拉请求(容许有进一步的同行评审时间).
·在README.mediawiki中列出NEP.
·回复NEP做者告知下一步操做.
NEP编辑者旨在履行管理和编辑的职责.NEP编辑者收集NEP的变化,并改正任何咱们看到的结构、语法、拼写或标记上的额错误。

历史

本文档是根据Amir Taaki从Python版PEP-0001衍生出的比特币的BIP-0001文档编写的。在许多地方仅是简单复制和修改。虽然PEP-0001文档是由Barry Warsaw, Jeremy Hylton, and David Goodger编写，可是他们并不负责其在NEO改善过程当中的使用，而且不用回答任何NEO或者NEP的技术问题。请把全部意见评论直接提交给NEP编辑者。

原文：来自 github.com/neo-project…