* discussions-to:指向官方接头线程的链接

Conflux Improvement Proposals

·Backward Compatible Changes: The updated client under this CIP will be fully compatible with older versions. Such changes may introduce additional RPC APIs or other new features. To submit a backward compatible change, please follow this process:

· 复刻 Conflux Rust 库，提交拉取请求（PR）；

·??? Draft -- Authors or new champions wishing to pursue this CIP can ask for changing it to Draft status.

·执行——在所有 CIP 的状态变动为“最终版”之前必需完成执行，但在将 CIP 归并为草稿之前不必完成。尽量可以在编写代码之前就类型和根基道理告竣共鸣，但在举办很多 API 细节接头时，“大致共鸣和运行代码”的原则仍然很有用。

需求标头

Random J. User (@username)

superseded-by and replaces headers

所有涉及焦点代码、生态开拓的内容，都可以在 CIP 长举办提案。提案会以“CIP-X”编号形式泛起，提案一旦在 CIP 上被接管，提案实施必需完成，当提案实施完成并被社区接管时，状态将变动为“最终生成（Final）”。

When you believe your CIP is mature and ready to progress past the draft phase, you should ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the CIP editors will update the state of your CIP to Accepted.

·Create an issue in Conflux-Rust corresponding to the CIP.

For each new CIP that comes in, an editor does the following:

办理方案标头

·前导码——RFC 822 样式标题，包括有关 CIP 的元数据，包罗 CIP 编号、简短的描写性标题（最多 44 个字符）和作者具体信息。详细细节如下。

·草案（Draft）——归并第一份草案后，您可以提交后续的 PR，并对草案举办进一步变动，直到您认为 CIP 成熟并筹备好进入下一阶段。

每个 CIP 必需以 RFC 822 样式的前导码开头，并在其后跟三个连字符（-）。此标头在 Jekyll 中被称为“前件”（front matter）。标头必需凭据以下顺序分列：标有“ *”的标题是可选的，如下所述。其他所有的标头都是必选的。

There are four types of CIPs:

·Accepted - a CIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a CIP into their clients as part of a hard fork is not part of the CIP process. If such a decision is made, the CIP will move to Final.

·安详留意事项——所有 CIP 必需包括的部门，接头与提议改观相关的安详影响/留意事项。包罗对安详性接头大概很重要的信息、袒露风险，可以在提案的整个生命周期中利用。譬喻：包罗与安详性相关的设计决定、存眷点、重要接头、指向执行的指南和陷阱、威胁和风险概述以及如何办理这些威胁和风险。缺少“安详留意事项”部门的 CIP 将被驳回。审阅者认为没有足够的安详留意事项接头的 CIP 无法进入“最终版”阶段。

假如 CIP 筹备停当可以入库了，CIP 编辑就会：

乐成通过的 CIP 流程如下：

When linking to an image in the CIP, use relative links such as../assets/cip-1/image.png.

CIP Header Preamble

链接到 CIP 中的某张图片的相关链如：../assets/cip-1/image.png.

* resolution:a url pointing to the resolution of this CIP

由于 CIP 需要将客户端执行视为最终版符号（请参阅下面的“ CIP历程”），您需要提供客户端执行，或说服客户端执行您的 CIP。

当您认为本身的 CIP 已经成熟而且筹备好通过草案（Draft）阶段时，可以提倡请求将您的问题添加到即将进行的全体焦点开拓者集会会议（All Core Devs meeting）的议程中，可以在集会会议上接头是否将其包括在未来的硬分叉中。假如执行者同意将其包括进去，CIP 编辑就会更新你的 CIP 状态为“承认（Accepted）”。

if the email address is not given.

CIP 编辑责任

Random J. User <address@dom.ain>

· If it is a complicated change, please submit an issue to communicate with the core developer team first.

·?? 草案（Draft）——作者可能想要回收该 CIP 的拥护者可以请求变动草案状态。

Auxiliary Files

CIP 大概包括一个需求标头，，表白 CIP 编号。

·激活——假如有些 CIP 自己是无法最终完成的，也大概会包括“激活”状态。如：CIP-1 （本 CIP）。

·??? Accepted -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.

Accepted -- This status signals that material changes are unlikely and Conflux client developers should consider this CIP for inclusion. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the CIP process.

·Security Considerations - All CIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. CIP submissions missing the "Security Considerations" section will be rejected. A CIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

· 假如是巨大改观，首先要提交问题与焦点开拓团队相同。

附件

or

总之，作为 CIP 拥护者，您需要用以下名目写 CIP，在对应论坛中引导 CIP 的接头，并环绕这个想法成立社区共鸣。

* superseded-by:CIP number(s)

一个乐成的 CIP 必需满意必然的最低尺度。它必需清晰、完整地描写了提议的改造成果，改造成果必需是净改造。提议的执行（假如合用）必需是靠得住的，而且不能使协议过于巨大。

author:a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.

While a CIP is a draft, a discussions-to header will indicate the mailing list or URL where the CIP is being discussed. No discussions-to header is necessary if the CIP is being discussed privately with the author.

·宣布版本实现改观后，将 CIP 状态更新为“最终版”。

·标题必需可以或许精确地归纳综合内容。

Your first PR should be a first draft of the final CIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new CIP and assign it a number before merging it. Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the CIP as a whole.

Conflux 认为，区块链技能最大的代价在于去中心化和安详性，而只有基于 PoW（事情量证明）的共鸣机制才气最大限度地保存这些利益。

·??? 被驳回——焦点开拓人员可以自行抉择将此 CIP 标志为被驳回。譬喻：在 CIP 中发明白一个且不行更正的缺陷。

·向后兼容改观：这种 CIP 中更新的客户端会完全兼容以前的旧版本，这种改观会引入别的的长途进程挪用（RPC）API 或其他新成果。提交向后兼容改观时请回收以下步调：

CIP 分类

·Discuss the CIP until it is Accepted. Note that in the CIP, it is important to specify how the implementation can maintain compatibility with previous protocol versions (via versioning or other techniques). If this cannot be done, the change should be classified and treated as a spec breaking change instead.

·查抄 CIP 的语言（拼写、语法、句子布局等）、标志标记（GitHub 偏好 Markdown 名目）和代码范例。

·??? Rejected -- The Core Devs can decide to mark this CIP as Rejected at their discretion. E.g. a major, but uncorrectable, flaw was found in the CIP.

转让 CIP 所有权

孝敬提案的方法

·?Submit a pull request implementing the CIP.

Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft CIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your CIP contains either your GitHub username or your email address inside. If you use your email address, that address must be the one publicly shown on your GitHub profile.

·公示（Last Call）——劈头迭代阶段已经完成，筹备好给更大范畴评审者评审的 CIP。

·Final - a CIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.

乐成的 CIP 包括什么？

·Rejected -- A CIP that is fundamentally broken or rejected by the Core Devs and will not be implemented. A CIP cannot move on from this state.

The CIP editors monitor CIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.

4.请求 Conflux CIP 库拉取你的提交（Pull Request，PR）。

·Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Conflux platform (conflux-rust).

·?Create an issue in the Conflux-Protocol repo corresponding to the CIP.

对付 Conflux 来说，去中心化的选择不只范围于组织创立 DAO 漫衍式自治社区，还要将 Conflux 网络将来的技能走向从几个研发人员的权限交付到每小我私家手中。

Merge the corresponding pull request

updated header

·?Wait for a hard-fork to enable the change. Change the CIP status to Final.

您的第一个 PR 应该是最终通过的 CIP 的草案（Draft），必需切合开拓要求的名目尺度（凡是要在标头中包括正确的元数据）。CIP 编辑会人工审核每个新的 CIP 的首个 PR，并在归并前为其指定一个 CIP 编号。确保包括接头链接，附带接头论坛或开放 GitHub 的链接，以便人们可以接头整个 CIP。

·?× 草案（Draft）——驳回草案的原因包罗不足专注、过于宽泛、反复事情、技能上不足健全、没有提供适当的念头、没有办理向后兼容性问题，可能不切合 Conflux 理念。

作者标头

·Implementations - The implementations must be completed before any CIP is given status “Final”, but it need not be completed before the CIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.

CIP Formats and Templates

CIP 引导

·Assign a CIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this CIP)

·?Submit a pull request to the Conflux-Protocol repo to change the spec according to the CIP.

2.Fork the repository by clicking "Fork" in the top right.

CIPs may also have a superseded-by header indicating that a CIP has been rendered obsolete by a later document; the value is the number of the CIP that replaces the current document. The newer CIP must have a replaces header containing the number of the CIP that it rendered obsolete.

强烈发起单个 CIP 仅包括一个要害提议或想法，CIP 针对性越强，被通过的乐成率就越高。仅涉及到一个客户端的变动不需要 CIP，会影响多个客户端或界说多个应用措施利用尺度的变动需要 CIP。

type:Backward Compatible | Database/RPC Breaking | Protocol Breaking | Spec Breaking

Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).

编辑不会对 CIP 做出评判，只认真行政和编辑部门。

·被代替——之前的最终版 CIP，可是不再是当前的最新程度。会有新的 CIP 进入最终版状态，并引用被代替的 CIP。进入此阶段的 CIP 不会再更新为其他状态。

对付 Conflux 执行者来说，CIP 是一种很利便的追踪执行历程的方法。抱负环境下，执行的维护者会列出他们已经执行过的 CIP 的清单，这为终端用户提供了一种便捷的途径来相识指定执行或库的当前状态。

* requires:CIP 编号

有时有须要将 CIP 的所有权转让给新的拥护者。凡是环境下，我们但愿保存原作者作为所有权已转让的 CIP 的联相助者，但实际上是否保存由原作者抉择。转移 CIP 所有权的较好的原因是原作者不再有时间或乐趣来更新 CIP 或遵循 CIP 流程，可能已经失去网络接洽（即无法接洽到原作者或作者未回覆电子邮件）。转移所有权的不太好的原因包罗原作者差异意 CIP 的成长偏向等。我们会实验成立关于 CIP 的共鸣，可是假如无法告竣共鸣，您永远都可以选择提交一份竞争性的 CIP。

·审核、测试、和/或确认执行。PR 会被归并到主分支上。焦点开拓团队大概会选择将 PR 归并到其他分支，举办 Conflux-Rust 客户端宣布。

接头链接标头

Random J. User (@username)

·念头（*可选）——对付想要变动 Conflux 协议的 CIP 至关重要。应该清楚地表明为什么现有协议类型不敷以办理 CIP 应该办理的问题。没有足够念头的 CIP 大概会被完全驳回。

·Copyright Waiver - All CIPs must be in the public domain. See the bottom of this CIP for an example copyright waiver.

更新日期标头记录了 CIP 有更新时的日期。此标头仅对“草案”和“激活”状态下的 CIP 有效。

· Submit a Conflux Improvement Proposal (CIP) draft.

Transferring CIP Ownership

·Preamble - RFC 822 style headers containing metadata about the CIP, including the CIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details. See below for details.

·提交 PR 执行该 CIP。

·The title should accurately describe the content.

Idea -- Once the champion has asked the Conflux community whether an idea has any chance of support, they will write a draft CIP as a pull request. Consider including an implementation if this will aid people in studying the CIP.

status:Draft | Last Call | Accepted | Final | Active | Abandoned | Rejected | Superseded

建设日期标头

·Protocol Breaking Changes: These changes do not touch the specification of the Conflux Protocol, but require an update to the P2P network protocol in Conflux/Conflux-Rust. It is possible to enable the change without a hard-fork but it would require special protocol version handling and compatibility testing. To submit a protocol breaking change, please follow this process:

CIP 将成为 Conflux 网络提案新成果、收集社区发起以及记录提案文档的主要机制。

The resolution header contains a URL that should point to an email message or other web resource where the pronouncement about the CIP is made.

假如您的 CIP 需要图片，图片应该放在 CIP assets 文件夹的子目次中，如：assets/CIP-N（N 是指 CIP 编号）。链接到 CIP 中的某张图片时，链接路径如：../assets/CIP-1/image.png.

·承认（Accepted）——已经进入公示极阶段至少2周的 CIP，而且作者已包办理了所有须要的技能改观问题。焦点开拓者抉择是否将一个 CIP 作为硬分叉的一部门编码进客户端的进程不属于 CIP 历程。假如做出了这样的抉择，CIP 就会进入“最终生成（Final）”阶段。

每一个 CIP 都需要包括以下部门：

范例标头指定 CIP 的详细范例：向后兼容改观、数据库/RPC改观、协议变、类型改观

Conflux Improvement Proposals (CIPs) describe standards for the Conflux platform, including core protocol specifications, client APIs, and contract standards.

As a single exception, discussions-to cannot point to GitHub pull requests.

title:CIP 标题

被代替和替换标头

* superseded-by:CIP 编号

·??? Draft -- If agreeable, CIP editor will assign the CIP a number (generally the issue or PR number related to the CIP) and merge your pull request. The CIP editor will not unreasonably deny a CIP.

assets/cip-N(where N is to be replaced with the CIP number).

CIP 名目与模板

If the CIP isn't ready, the editor will send it back to the author for revision, with specific instructions.

和（假如没有提供电子邮箱地点）

·Active -- Some CIPs may also have a status of “Active” if they are never meant to be completed. E.g. CIP-1 (this CIP).

created header

CIP Work Flow

In addition to making sure your idea is original, it will be your role as the author to make your idea clear to reviewers and interested parties, as well as inviting editors, developers and community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your CIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Spec Breaking CIP will be much greater than for a Backward Compatible CRC and the CIP will need sufficient interest from the Conflux client team(s). Negative community feedback will be taken into consideration and may prevent your CIP from moving past the Draft stage.

·?× 公示（Last Call）——假如仍然需要对草案举办须要的变动，CIP 进入公示（Last Call）阶段的请求会被驳回。我们但愿所有 CIP 都只需要进入公示（Last Call）阶段一次。

CIP 事情流程

1.Review CIP-1.

一个破例环境是，接头链接标头不能指向 GitHub PR。

* updated:comma separated list of dates

办理方案标头要包括一个URL，指向发出有关 CIP 的声明的电子邮件或其他网页资源。

In short, your role as the champion is to write the CIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.

·Submit a pull request implementing the CIP.

·?? Draft -- Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Conflux philosophy.

CIP Editor Responsibilities

·Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

CIP Process

·审核、测试、和/或确认执行。PR 会被归并到主分支上。

志同，而气合。

·提交一个 CIP 草案（Draft）。

* discussions-to:a url pointing to the official discussion thread

3.将您的提案添加至您的存储库复刻。点击此处查察模板 CIP。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。