Conflux CIP 介绍
Last updated
Last updated
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）”。
· 草案（Draft）——快速迭代和更改状态下的 CIP。
· 公示（Last Call）——初步迭代阶段已经完成，准备好给更大范围评审者评审的 CIP。
· 认可（Accepted）——已经进入公示极阶段至少2周的 CIP，并且作者已经解决了所有必要的技术变更问题。核心开发者决定是否将一个 CIP 作为硬分叉的一部分编码进客户端的过程不属于 CIP 进程。如果做出了这样的决定，CIP 就会进入“最终生成（Final）”阶段。
· 最终生成（Final）——核心开发者决定执行并将在未来的硬分叉中发布，或已经在硬分叉中发布过的 CIP。
CIP 全称是 Conflux Improvement Proposals，即 Conflux 改进提案。CIP 是一个设计文件，向 Conflux 社区提供信息，或规定 Conflux 的一些新功能、流程或环境。CIP 中应当简介该功能的技术规范以及基本原理。
我们计划将 CIP 作为提议新功能、收集社区对问题的意见以及记录已纳入 Conflux 的设计决策的主要机制。CIP 作者负责在社区内构建共识、记录有异议的观点。由于 CIP 在版本库中作为文本文件进行维护，因此 CIP 的修订历史记录就是功能提案的历史记录。
对于 Conflux 执行者来说，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 编辑者和 Conflux 核心开发者。
在开始编写正式的 CIP 之前，您应该先审视一下自己的想法。首先需要询问 Conflux 社区您的想法是否是独创的，避免因为之前已有过相关研究会被拒绝而浪费时间。因此建议您在此存储库的“问题（issue）”部分中打开一个讨论线程。
除了确保您的想法具有独创性之外，您还将作为作者向审稿人和相关方明确您的想法，并邀请编辑、开发人员和社区通过上述渠道提供反馈。您应该尝试衡量一下 CIP 的关注度是否与执行 CIP 所涉及的工作量以及有多少方必须遵守该 CIP 相一致。例如，执行规范变更 CIP 所需的工作量比执行向后兼容 CRC（循环冗余校验码）大得多，并且 CIP 需要 Conflux 客户端产品团队足够多的关注。负面的社区反馈将被考虑在内，可能影响您的 CIP 通过草案阶段。
由于 CIP 需要将客户端执行视为最终版标志（请参阅下面的“ CIP进程”），您需要提供客户端执行，或说服客户端执行您的 CIP。
总之，作为 CIP 拥护者，您需要用以下格式写 CIP，在对应论坛中引导 CIP 的讨论，并围绕这个想法建立社区共识。
成功通过的 CIP 流程如下：
· 想法阶段 -> 草案阶段 -> 公示（Last Call） -> 认可（Accepted） -> 最终版
每次状态变更都需要由 CIP 作者发起请求并且由 CIP 编辑审核。使用 PR 更新状态。请附带链接方便人们继续讨论您的 CIP。CIP 编辑会根据以下条件处理这些请求。
· 想法——如果 CIP 拥护者已经问过 Conflux 社区是否有任何通过的机会，他们会撰写一份 CIP 草案进行拉取请求（PR）。如果执行有助于人们研究 CIP，可以考虑提供一个执行。
· × 草案（Draft）——驳回草案的原因包括不够专注、过于宽泛、重复工作、技术上不够健全、没有提供适当的动机、没有解决向后兼容性问题，或者不符合 Conflux 理念。
· 草案（Draft）——合并第一份草案后，您可以提交后续的 PR，并对草案进行进一步更改，直到您认为 CIP 成熟并准备好进入下一阶段。
· × 公示（Last Call）——如果仍然需要对草案进行必要的更改，CIP 进入公示（Last Call）阶段的请求会被驳回。我们希望所有 CIP 都只需要进入公示（Last Call）阶段一次。
· 公示（Last Call）——该 CIP 将在网站上的显眼位置列出。
· × ——如果公示阶段发现需要必要的更改或未解决的技术问题，CIP 会被退回草案状态。
· 认可（Accepted）——此状态表明不需要进行必要更改，Conflux 客户端开发人员应考虑将此 CIP 包括在现实计划内。核心开发人员决定是否将 CIP 作为硬分叉的一部分编码进客户端的过程不属于 CIP 进程。
· 最终生成（Final）——此时的 CIP 代表了当前的最新水平。最终版的 CIP 只有在进行勘误时才可以更新。
其他异常状态包括：
· 激活——如果有些 CIP 本身是无法最终完成的，也可能会包含“激活”状态。如：CIP-1 （本 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 的底部。
必须使用 Markdown 格式写 CIP。图片文件应该放置在 CIP 资产文件夹的子目录中，如：
asset/cip-N（将 N 替换为 CIP 编号）。
链接到 CIP 中的某张图片的相关链如：…/assets/cip-1/image.png.
每个 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 的语言（拼写、语法、句子结构等）、标记符号（GitHub 偏好 Markdown 格式）和代码类型。
如果 CIP 还没有就绪，编辑会将其退回至作者进行修改，同时会给出具体指示。
如果 CIP 准备就绪可以入库了，CIP 编辑就会：
· 指定一个 CIP 编号（通常是 PR 编号，如果关于此 CIP 的库中的问题部分有讨论过这个问题，作者更倾向于使用问题编号的话，也可以使用问题编号）。
合并对应的 PR。
· 向 CIP 作者回信，告知下一步。
CIP 编辑会监视 CIP 的每一次变更，纠正所有遇见的结构、语法、拼写或标记符号错误。
编辑不会对 CIP 做出评判，只负责行政和编辑部分。
· 草案（Draft）——如果 CIP 可以接受，编辑会为该 CIP 分配一个编号（通常是与该 CIP 相关的问题或 PR 的编号）并合并您的 PR。CIP 编辑不会毫无理由地驳回 CIP。
· 公示（Last Call）——如果 CIP 可以接受，编辑会将 CIP 指定为公示（Last Call）阶段，并设置审核结束日期（review-period-end），通常为14天。
· 已接受——成功的公示，不需要做必要更改、没有未解决的技术问题的 CIP 将进入“认可”状态。
· 草案（Draft）——核心开发人员可以自行决定将此 CIP 退回草案状态。例如：在 CIP 中发现了一个但可纠正的缺陷。
· 被驳回——核心开发人员可以自行决定将此 CIP 标记为被驳回。例如：在 CIP 中发现了一个且不可纠正的缺陷。
最终版——在最终通过之前，CIP 必须要先被执行。执行完成并且被社区采用时，CIP 状态会被更改为“最终生成”。
· 草案（Draft）——作者或者想要采用该 CIP 的拥护者可以请求更改草案状态。
