Conflux CIP 机制启动

Conflux 改进提案（CIP）规定了 Conflux 平台的标准，包括核心协议规范、客户端 API 和合同标准。

贡献提案的方式

1.阅读 CIP-1。

2.点击右上角的“Fork”复刻存储库。

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

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

您的第一个 PR 应该是最终通过的 CIP 的草案（Draft），必须符合开发要求的格式标准（通常要在标头中包含正确的元数据）。CIP 编辑会人工审核每个新的 CIP 的首个 PR，并在合并前为其指定一个 CIP 编号。确保包含讨论链接，附带讨论论坛或开放 GitHub 的链接，以便人们可以讨论整个 CIP。

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

您的 PR 被合并后，我们会有机器人自动将 PR 合并至 CIP 中。为确保这一点，机器人需要能够确认您对当前 PR 的所有权，因此，请确保您提交的 CIP“作者”栏包含您的 GitHub 用户名或电子邮箱地址。如果您选择使用电子邮箱地址，该地址必须是您在 GitHub 个人资料上公开展示的地址。

当您认为自己的 CIP 已经成熟并且准备好通过草案（Draft）阶段时，可以发起请求将您的问题添加到即将举行的全体核心开发者会议（All Core Devs meeting）的议程中，可以在会议上讨论是否将其包含在将来的硬分叉中。如果执行者同意将其包含进去，CIP 编辑就会更新你的 CIP 状态为“认可（Accepted）”。

CIP 状态术语

· 草案（Draft）——快速迭代和更改状态下的 CIP。

· 公示（Last Call）——初步迭代阶段已经完成，准备好给更大范围评审者评审的 CIP。

· 认可（Accepted）——已经进入公示极阶段至少2周的 CIP，并且作者已经解决了所有必要的技术变更问题。核心开发者决定是否将一个 CIP 作为硬分叉的一部分编码进客户端的过程不属于 CIP 进程。如果做出了这样的决定，CIP 就会进入“最终生成（Final）”阶段。

· 最终生成（Final）——核心开发者决定执行并将在未来的硬分叉中发布，或已经在硬分叉中发布过的 CIP。

什么是 CIP？

CIP 全称是 Conflux Improvement Proposals，即 Conflux 改进提案。CIP 是一个设计文件，向 Conflux 社区提供信息，或规定 Conflux 的一些新功能、流程或环境。CIP 中应当简介该功能的技术规范以及基本原理。

我们计划将 CIP 作为提议新功能、收集社区对问题的意见以及记录已纳入 Conflux 的设计决策的主要机制。CIP 作者负责在社区内构建共识、记录有异议的观点。由于 CIP 在版本库中作为文本文件进行维护，因此 CIP 的修订历史记录就是功能提案的历史记录。

对于 Conflux 执行者来说，CIP 是一种很方便的追踪执行进程的方式。理想情况下，执行的维护者会列出他们已经执行过的 CIP 的清单，这为终端用户提供了一种便捷的途径来了解指定执行或库的当前状态。

CIP 分类

有 4 种不同类型的 CIP：

· 向后兼容变更：这种 CIP 中更新的客户端会完全兼容以前的旧版本，这种变更会引入另外的远程过程调用（RPC）API 或其他新功能。提交向后兼容变更时请采用以下步骤：

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

· 如果是复杂变更，首先要提交问题与核心开发团队沟通。

数据库/ RPC 变更：更新的客户端能够与以前的版本共存，但是它可以更新现有 RPC 的接口或行为，或者可以更改区块链数据库格式。需要根据这些 RPC 对应用程序进行修改和/或清理数据库以重新开始进行同步。要提交数据库/RPC变更，可以按照上述步骤进行操作，但必须先提交一个问题。

· 网络协议变更：这些更改不涉及 Conflux 协议的规范，需要更新 Conflux 或 Conflux-Rust 中的 P2P 网络协议。无需硬分叉即可实现更改，但需要特殊的协议版本处理和兼容性测试。要提交协议变更，请按照以下步骤操作：

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

·讨论该草案（Draft）直至草案认可。请注意，在 CIP 中，指定当前执行如何与先前协议版本保持兼容性是很重要的（通过版本控制或其他技术实现）。如果无法做到这一点，则应将变更划分为规范变更。

·在 Conflux-Rust 中创建与该 CIP 相关的问题。

·提交 PR 执行该 CIP。

·审核、测试、和/或确认执行。PR 会被合并到主分支上。核心开发团队可能会选择将 PR 合并到其他分支，进行 Conflux-Rust 客户端发布。

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

· 规范变更：此类变更需要更新 Conflux 协议的规范，需要硬分叉才能实现变更，完全没有向后兼容性。进行规范变更的一般步骤如下：

·提交一个 CIP 草案。草案中应讨论如何在硬分叉中实现变更。

·讨论该草案直至草案认可。

·在 Conflux 协议库中创建与该 CIP 相关的问题。

·提交 PR 至 Conflux 协议库根据该 CIP 更改规范。

·在 Conflux Rust 库中创建与该 CIP 相关的问题。

·提交 PR 执行该 CIP。

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

·等待硬分叉以实现变更。更改 CIP 状态至“最终生成”。

注意：目前 Conflux-Rust 中的轻客户端模式是实验性的。仅影响轻客户端的所有变更目前都被视为“向后兼容变更”。

强烈建议单个 CIP 仅包含一个关键提议或想法，CIP 针对性越强，被通过的成功率就越高。仅涉及到一个客户端的更改不需要 CIP，会影响多个客户端或定义多个应用程序使用标准的更改需要 CIP。

一个成功的 CIP 必须满足一定的最低标准。它必须清晰、完整地描述了提议的改进功能，改进功能必须是净改进。提议的执行（如果适用）必须是可靠的，并且不能使协议过于复杂。

如果 CIP 提及或提议对虚拟机进行更改，则它应参考其指令助记符的说明，并定义至少一次这些助记符的操作码。首选方式如下：

· REVERT (0xfe)

CIP 工作流程

CIP 引导

参与此过程的各方包括您，也就是 CIP 贡献者或原作者，以及 CIP 编辑者和 Conflux 核心开发者。

在开始编写正式的 CIP 之前，您应该先审视一下自己的想法。首先需要询问 Conflux 社区您的想法是否是独创的，避免因为之前已有过相关研究会被拒绝而浪费时间。因此建议您在此存储库的“问题（issue）”部分中打开一个讨论线程。

除了确保您的想法具有独创性之外，您还将作为作者向审稿人和相关方明确您的想法，并邀请编辑、开发人员和社区通过上述渠道提供反馈。您应该尝试衡量一下 CIP 的关注度是否与执行 CIP 所涉及的工作量以及有多少方必须遵守该 CIP 相一致。例如，执行规范变更 CIP 所需的工作量比执行向后兼容 CRC（循环冗余校验码）大得多，并且 CIP 需要 Conflux 客户端产品团队足够多的关注。负面的社区反馈将被考虑在内，可能影响您的 CIP 通过草案阶段。

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

总之，作为 CIP 拥护者，您需要用以下格式写 CIP，在对应论坛中引导 CIP 的讨论，并围绕这个想法建立社区共识。

CIP 进程

成功通过的 CIP 流程如下：

· 想法阶段 -> 草案阶段 -> 公示（Last Call） -> 认可（Accepted） -> 最终版

每次状态变更都需要由 CIP 作者发起请求并且由 CIP 编辑审核。使用 PR 更新状态。请附带链接方便人们继续讨论您的 CIP。CIP 编辑会根据以下条件处理这些请求。

· 想法——如果 CIP 拥护者已经问过 Conflux 社区是否有任何通过的机会，他们会撰写一份 CIP 草案进行拉取请求（PR）。如果执行有助于人们研究 CIP，可以考虑提供一个执行。

· ➡️ 草案（Draft）——如果 CIP 可以接受，编辑会为该 CIP 分配一个编号（通常是与该 CIP 相关的问题或 PR 的编号）并合并您的 PR。CIP 编辑不会毫无理由地驳回 CIP。

· × 草案（Draft）——驳回草案的原因包括不够专注、过于宽泛、重复工作、技术上不够健全、没有提供适当的动机、没有解决向后兼容性问题，或者不符合 Conflux 理念。

· 草案（Draft）——合并第一份草案后，您可以提交后续的 PR，并对草案进行进一步更改，直到您认为 CIP 成熟并准备好进入下一阶段。

· ➡️ 公示（Last Call）——如果 CIP 可以接受，编辑会将 CIP 指定为公示（Last Call）阶段，并设置审核结束日期（review-period-end），通常为14天。

· × 公示（Last Call）——如果仍然需要对草案进行必要的更改，CIP 进入公示（Last Call）阶段的请求会被驳回。我们希望所有 CIP 都只需要进入公示（Last Call）阶段一次。

· 公示（Last Call）——该 CIP 将在网站上的显眼位置列出。

· × ——如果公示阶段发现需要必要的更改或未解决的技术问题，CIP 会被退回草案状态。

· ➡️已接受——成功的公示，不需要做必要更改、没有未解决的技术问题的 CIP 将进入“认可”状态。

· 认可（Accepted）——此状态表明不需要进行必要更改，Conflux 客户端开发人员应考虑将此 CIP 包括在现实计划内。核心开发人员决定是否将 CIP 作为硬分叉的一部分编码进客户端的过程不属于 CIP 进程。

· ➡ 草案（Draft）——核心开发人员可以自行决定将此 CIP 退回草案状态。例如：在 CIP 中发现了一个但可纠正的缺陷。

· ➡️ 被驳回——核心开发人员可以自行决定将此 CIP 标记为被驳回。例如：在 CIP 中发现了一个且不可纠正的缺陷。

➡ 最终版——在最终通过之前，CIP 必须要先被执行。执行完成并且被社区采用时，CIP 状态会被更改为“最终生成”。

· 最终生成（Final）——此时的 CIP 代表了当前的最新水平。最终版的 CIP 只有在进行勘误时才可以更新。

其他异常状态包括：

· 激活——如果有些 CIP 本身是无法最终完成的，也可能会包含“激活”状态。如：CIP-1 （本 CIP）。

· 遗弃——原作者不再采用该 CIP，或者不再将它作为（技术上）的首选项。

· ➡ 草案（Draft）——作者或者想要采用该 CIP 的拥护者可以请求更改草案状态。

· 被驳回——被核心开发人员从根本上驳回的 CIP，并且不会被执行。进入此阶段的 CIP 不会再更新为其他状态。

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

成功的 CIP 包含什么？

每一个 CIP 都需要包含以下部分：

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

· 摘要——对要解决的技术问题的简短描述（约200字）。

· 动机（*可选）——对于想要更改 Conflux 协议的 CIP 至关重要。应该清楚地解释为什么现有协议规范不足以解决 CIP 应该解决的问题。没有足够动机的 CIP 可能会被完全驳回。

· 规范——技术规范应规定所有新功能的语法和语义。该规范应足够详细，以允许当前所有的 Conflux 平台（conflux-rust）可以进行竞争性、互操作性的执行。

· 基本原理——通过描述设计产生的动机以及做出特定设计决策的原因来完善规范。应该描述所考虑的替代设计和相关工作，例如：其他语言如何支持该功能。基本原理部分还可以提供社区内达成共识的证据，并应讨论在讨论过程中提出的重要异议或关切。

· 向后兼容性——所有引入向后不兼容性的 CIP 必须包含一部分描述这些不兼容性及其严重性。CIP 中必须解释作者建议如何处理这些不兼容问题。没有足够向后兼容性讨论的 CIP 可能会被完全驳回。

· 测试案例——对于影响共识变更的 CIP 来说，执行的测试案例是必须的。如果适用，其他 CIP 也可以选择附带测试案例的链接。

· 执行——在所有 CIP 的状态更改为“最终版”之前必须完成执行，但在将 CIP 合并为草稿之前不必完成。尽管可以在编写代码之前就规范和基本原理达成共识，但在进行许多 API 细节讨论时，“粗略共识和运行代码”的原则仍然很有用。

· 安全注意事项——所有 CIP 必须包含的部分，讨论与提议变更相关的安全影响/注意事项。包括对安全性讨论可能很重要的信息、暴露风险，可以在提案的整个生命周期中使用。例如：包括与安全性相关的设计决策、关注点、重要讨论、指向执行的指南和陷阱、威胁和风险概述以及如何解决这些威胁和风险。缺少“安全注意事项”部分的 CIP 将被驳回。审阅者认为没有足够的安全注意事项讨论的 CIP 无法进入“最终版”阶段。

· 版权豁免——所有的 CIP 必须适用于公共领域。版权豁免的示例请参阅此 CIP 的底部。

CIP 格式与模板

必须使用 Markdown 格式写 CIP。图片文件应该放置在 CIP 资产文件夹的子目录中，如： 

asset/cip-N（将 N 替换为 CIP 编号）。 

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

CIP 标头前导码

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

cip: CIP 编号（由 CIP 编辑指定）

title: CIP 标题

author: 作者姓名和/或用户名列表，或作者姓名和邮箱地址列表具体细节如下。

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

status: 草案（Draft）/公示（Last Call）/认可（Accepted）/最终版/激活/遗弃/被驳回/被取代

* review-period-end: 审核结束日期

type: 向后兼容变更/数据库/RPC变更/协议变更/规范变更

created: 创建日期

* updated: 逗号分隔的日期列表

* requires: CIP 编号

* replaces: CIP 编号

* superseded-by: CIP 编号

* resolution: 指向此 CIP 解决方案的链接

包含列表的标头必须用逗号分隔不同元素。

包含日期的标头必须采用 ISO 8601（yyyy-mm-dd）格式。

作者标头

作者标头可以选择列出 CIP 作者/所有者的姓名、电子邮件地址或用户名。喜欢匿名的作者可以只使用用户名，也可以使用姓名和用户名。作者标头值的格式必须为：

Random J. User<[email protected]

或（如果包含电子邮箱地址或 GitHub 用户名）

Random J. User (@username)

和（如果没有提供电子邮箱地址）

Random J. User

解决方案标头

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

讨论链接标头

当 CIP 是草案时，讨论链接标头指示正在讨论 CIP 的邮件列表或URL。如果正在与作者私下讨论该 CIP，则无需讨论链接标头。

一个例外情况是，讨论链接标头不能指向 GitHub PR。

类型标头

类型标头指定 CIP 的具体类型：向后兼容变更、数据库/RPC变更、协议变、规范变更

创建日期标头

创建日期标头记录了 CIP 被指定编号时的日期。两个标头都应采用 yyyy-mm-dd 的格式，例如 2001-08-14。

更新日期标头

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

需求标头

CIP 可能包含一个需求标头，表明 CIP 编号。

被取代和替换标头

CIP 可能还会有一个被取代标头，表示该 CIP 已被更高版本的文档淘汰；该值是替换当前文档的 CIP 的编号。新的 CIP 必须具有替换标头，包含已被取代的 CIP 的编号。

附件

CIP 可以包含附件，如图表等。附件命名格式必须是：CIP-N-Y.ext，N 是指 CIP 编号，Y 是序列号码，从1开始，将 ext 替换为实际的文件拓展名，如 “png”。

转让 CIP 所有权

有时有必要将 CIP 的所有权转让给新的拥护者。通常情况下，我们希望保留原作者作为所有权已转让的 CIP 的联合作者，但实际上是否保留由原作者决定。转移 CIP 所有权的较好的原因是原作者不再有时间或兴趣来更新 CIP 或遵循 CIP 流程，或者已经失去网络联系（即无法联系到原作者或作者未回复电子邮件）。转移所有权的不太好的原因包括原作者不同意 CIP 的发展方向等。我们会尝试建立关于 CIP 的共识，但是如果无法达成共识，您永远都可以选择提交一份竞争性的 CIP。

如果你有意获得某个 CIP 的所有权，可以向原作者和 CIP 编辑发信息申请接管。如果原作者没有及时回复信息，CIP 编辑会做出单方面决定（但这个决定是可能会逆转的）。

CIP 编辑责任

对于每一个新的 CIP，编辑都有如下责任：

· 阅读 CIP 并检查是否已经就绪：CIP 需要合理、完善。即使不一定能走到最终版阶段，想法也一定要有技术意义。

· 标题必须能够准确地概括内容。

· 检查 CIP 的语言（拼写、语法、句子结构等）、标记符号（GitHub 偏好 Markdown 格式）和代码类型。

如果 CIP 还没有就绪，编辑会将其退回至作者进行修改，同时会给出具体指示。

如果 CIP 准备就绪可以入库了，CIP 编辑就会：

· 指定一个 CIP 编号（通常是 PR 编号，如果关于此 CIP 的库中的问题部分有讨论过这个问题，作者更倾向于使用问题编号的话，也可以使用问题编号）。

合并对应的 PR。

· 向 CIP 作者回信，告知下一步。

CIP 编辑会监视 CIP 的每一次变更，纠正所有遇见的结构、语法、拼写或标记符号错误。

编辑不会对 CIP 做出评判，只负责行政和编辑部分。

Conflux Improvement Proposals

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

Contributing

1.Review CIP-1.

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

3.Add your CIP to your fork of the repository. There is a template CIP here.

4.Submit a Pull Request to Conflux's CIPs repository.

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.

If your CIP requires images, the image files should be included in a subdirectory of the assets folder for that CIP as follows: assets/CIP-N (where N is to be replaced with the CIP number). When linking to an image in the CIP, use relative links such as ../assets/CIP-1/image.png.

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.

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.

CIP Status Terms

· Draft - a CIP that is undergoing rapid iteration and changes.

· Last Call - a CIP that is done with its initial iteration and ready for review by a wide audience.

· 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.

· 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.

What is a CIP?

CIP stands for Conflux Improvement Proposal. A CIP is a design document providing information to the Conflux community, or describing a new feature for Conflux or its processes or environment. The CIP should provide a concise technical specification of the feature and a rationale for the feature.

We intend CIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Conflux. The CIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the CIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

For Conflux implementers, CIPs are a convenient way to track the progress of their implementation. Ideally implementation maintainers would list the CIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or Library.

CIP Types

There are four types of CIPs:

· 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:

· Fork the conflux-rust repository and submit a pull request.

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

· Database/RPC Breaking Changes: The updated client will be able to co-exist with previous versions, but it updates the interface/behavior of an existing RPC or it changes the blockchain database format. This would require modifications for applications depending on these RPCs and/or clean up the database to sync from the scratch. To submit a Database/RPC breaking change, you can follow the above process but you must submit an issue first.

· 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:

· Submit a Conflux Improvement Proposal (CIP) draft.

·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.

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

·Submit a pull request implementing the CIP.

·Audit, test, and/or verify the implementation. The PR will be merged into the master branch. The core developer team may choose to also merge the PR to other branches for Conflux-Rust client releases.

·Once a release enables the change, update the CIP status to Final.

· Spec Breaking Changes: These changes require an update to the specification of the Conflux protocol. It would require a hard-fork to enable the change. It has no backward compatibility at all. The general process for making spec breaking changes is as follows:

· Submit a Conflux Improvement Proposal (CIP) draft. The draft should discuss how to enable this change in a hard-fork.

· Discuss the CIP until it is Accepted.

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

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

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

· Submit a pull request implementing the CIP.

· Audit, test, and/or verify the implementation. The PR will be merged into the master branch.

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

NOTE: Currently light client modes in Conflux-Rust are considered experimental. All changes that only affecting light clients will be considered as Backward Compatible for now.

It is highly recommended that a single CIP contains a single key proposal or new idea. The more focused the CIP is, the more successful it tends to be. A change to one client doesn't require a CIP; a change that affects multiple clients, or DeFines a standard for multiple apps to use, does.

A successful CIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

If a CIP mentions or proposes changes to the Virtual Machine, it should refer to the instructions by their mnemonics and define the opcodes of those mnemonics at least once. A preferred way is the following:

· REVERT (0xfe)

CIP Work Flow

Shepherding a CIP

Parties involved in the process are you, the champion or CIP author, the CIP editors, and the Conflux Core Developers.

Before you begin writing a formal CIP, you should vet your idea. Ask the Conflux community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread in the Issues SECtion of this repository.

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.

Given that CIPs require client implementations to be considered Final (see "CIPs Process" below), you will need to either provide an implementation for clients or convince clients to implement your 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.

CIP Process

Following is the process that a successful CIP will move along:

· [ IDEA ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]

Each status change is requested by the CIP author and reviewed by the CIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your CIP. The CIP editors will process these requests as per the conditions below.

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.

· ➡️ 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.

· ❌ 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.

· Draft -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the CIP to be mature and ready to proceed to the next status.

· ➡️ Last Call -- If agreeable, the CIP editor will assign Last Call status and set a review end date (review-period-end), normally 14 days later.

· ❌ Last Call -- A request for Last Call status will be denied if material changes are still expected to be made to the draft. We hope that CIPs only enter Last Call once.

· Last Call -- This CIP will be listed prominently on the website.

· ❌ -- A Last Call which results in material changes or substantial unaddressed technical complaints will cause the CIP to revert to Draft.

· ➡️ 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.

· ➡️ Draft -- The Core Devs can decide to move this CIP back to the Draft status at their discretion. E.g. a major, but correctable, flaw was found in the CIP.

· ➡️ 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.

· ➡️ Final -- CIPs must be implemented before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”.

· Final -- This CIP represents the current state-of-the-art. A Final CIP should only be updated to correct errata.

Other exceptional statuses include:

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

· Abandoned -- This CIP is no longer pursued by the original authors or it may not be a (technically) preferred option anymore.

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

· 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.

· Superseded -- A CIP which was previously Final but is no longer considered state-of-the-art. Another CIP will be in Final status and reference the Superseded CIP. A CIP cannot move on from this state.

What belongs in a successful CIP?

Each CIP should have the following parts:

· 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.

· Abstract - A short (~200 word) description of the technical issue being addressed.

· Motivation (*optional) - The motivation is critical for CIPs that want to change the Conflux protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the CIP solves. CIP submissions without sufficient motivation may be rejected outright.

· 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).

· 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.

· Backwards Compatibility - All CIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The CIP must explain how the author proposes to deal with these incompatibilities. CIP submissions without a sufficient backwards compatibility treatise may be rejected outright.

· Test Cases - Test cases for an implementation are mandatory for CIPs that are affecting consensus changes. Other CIPs can choose to include links to test cases if applicable.

· 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.

· 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.

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

CIP Formats and Templates

CIPs should be written in markdown format. Image files should be included in a subdirectory of the assets folder for that CIP as follows: 

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

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

CIP Header Preamble

Each CIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (---). This header is also termed "front matter" by Jekyll. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.

cip: CIP number (this is determined by the CIP editor)

title: CIP title

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

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

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

* review-period-end: date review period ends

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

created: date created on

* updated: comma separated list of dates

* requires: CIP number(s)

* replaces: CIP number(s)

* superseded-by: CIP number(s)

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

Headers that permit lists must separate elements with commas.

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

author header

The author header optionally lists the names, email addresses or usernames of the authors/owners of the CIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be:

Random J. User

or

Random J. User (@username)

if the email address or GitHub username is included, and

Random J. User

if the email address is not given.

resolution header

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.

discussions-to header

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.

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

type header

The type header specifies the type of CIP: Backward Compatible, Database/RPC Breaking, Protocol Breaking, Spec Breaking.

created header

The created header records the date that the CIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.

updated header

The updated header records the date(s) when the CIP was updated with "substantial" changes. This header is only valid for CIPs of Draft and Active status.

requires header

CIPs may have a requires header, indicating the CIP numbers that this CIP depends on.

superseded-by and replaces headers

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.

Auxiliary Files

CIPs may include auxiliary files such as diagrams. Such files must be named CIP-N-Y.ext, where N is the CIP number, Y is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”).

Transferring CIP Ownership

It occasionally becomes necessary to transfer ownership of a CIP to a new champion. In general, we'd like to retain the original author as a co-author of the transferred CIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the CIP process, or has fallen off the face of the 'net (i.e. is unreachable or isn't responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the CIP. We try to build consensus around a CIP, but if that's not possible, you can always submit a competing CIP.

If you are interested in assuming ownership of a CIP, send a message asking to take over, addressed to both the original author and the CIP editor. If the original author doesn't respond to email in a timely manner, the CIP editor will make a unilateral decision (it's not like such decisions can't be reversed :)).

CIP Editor Responsibilities

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

· Read the CIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.

· The title should accurately describe the content.

· Check the CIP for language (spelling, grammar, sentence structure, ETC.), markup (GitHub flavored Markdown), code style

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

Once the CIP is ready for the repository, the CIP editor will:

· 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)

Merge the corresponding pull request

· Send a message back to the CIP author with the next step.

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

The editors don't pass judgment on CIPs. We merely do the administrative & editorial part.