共计 8199 个字符，预计需要花费 21 分钟才能阅读完成。
CIP，即 Conflux Improvement Proposal(Conflux 改良提案)。
CIP 针对 Conflux 网络的新性能或新的运行环境提供详细描述，包含全节点性能的改良提案，如新增 VM 指令等，亦蕴含周边开发的规范（类 ERC20）等。CIP 将外围代码降级规范化、凋谢化，为 Conflux 网络去中心化研发的有序高效率进行提供了根底。
比特币有闪电网络（Lightning Network）、Taproot/Schnorr 签名、Miniscripts 以及许多改良降级，以太坊同样也有 EIP20、EIP137、EIP1155、EIP1679 和 EIP1559 等提案，每一个提案都对其网络的运行产生了重大影响。
CIP 将成为 Conflux 网络提案新性能、收集社区倡议以及记录提案文档的次要机制。
CIP 提案共有四种状态，别离为草案（Draft）、公示（Last Call）、认可（Accepted）和最终生成（Final）。
所有波及外围代码、生态开发的内容，都能够在 CIP 上进行提案。提案会以“CIP-X”编号模式出现，提案一旦在 CIP 上被承受，提案施行必须实现，当提案施行实现并被社区承受时，状态将更改为“最终生成（Final）”。
目前在 CIP 上已有 11 个提案，内容笼罩 CIP 提案撰写标准、数据结构和如何解决执行中细节问题等。
通过 CIP 的提案，能够理解到 Conflux 网络参与者、关注者们的最新动向、如何布局 Conflux 网络的将来，并能感知到我的项目本身须要面对的挑战。
Conflux 认为，区块链技术最大的价值在于去中心化和安全性，而只有基于 PoW（工作量证实）的共识机制能力最大限度地保留这些长处。
对于 Conflux 来说，去中心化的抉择不仅局限于组织成立 DAO 分布式自治社区，还要将 Conflux 网络将来的技术走向从几个研发人员的权限交付到每个人手中。
CIP 为 Conflux 网络实现技术研发的去中心化提供了标准的提案规范，迈出了从中心化开发团队到去中心化开发的重要一步，也是 Conflux 践行去中心化理念的重要摸索之一。
志同，而气合。
Conflux 乐于与公众和社区成员分享这种摸索，与气味相投的搭档独特促成行业的提高和开放式倒退。
CIP 链接：github.com/Conflux-Chain/CIPs
————————————————————
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 <address@dom.ain
或（如果蕴含电子邮箱地址或 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 开发材料包
- conflux-chain github
- conflux-fans github
