什么是 CIP
Canton Improvement Proposal（CIP）介绍与索引。
Canton 改进提案 (CIP) 的正式结构、生命周期和治理机制
Canton 改进提案 (CIP) 是正式的设计文件，描述了Canton Network的标准、协议变更、治理程序和指南。它们是社区提出和批准网络变更的主要机制。
CIP 流程以已建立的改进提案框架（例如以太坊的 EIP 和 Python 的 PEP）为模型，并在 CIP-0000 中正式定义。所有 CIP 均维护在由 Global Synchronizer Foundation 管理的公共 GitHub 存储库 中。
有关 CIP 的介绍性概述及其重要性，请参阅 CIP 简介。
CIP 类型
每个 CIP 属于以下五个类别之一：
- 标准跟踪 — 影响全局同步器实现的技术规范和协议更改。在达到最终状态之前，这些需要设计文档和参考实现。
- 治理 - 定义或修改超级验证者权利、投票权重或基本治理规则（包括链上投票流程）的提案。
- Tokenomics — 奖励结构、Canton Coin 费用或同步器流量定价的更改。
- 流程 — 对工作流程、工具或有关 CIP 流程本身的元 CIP 进行调整。社区共识通常适用。
- 信息性 — 一般设计指南或建议。信息性 CIP 不需要采用，也不具有约束力。
CIP 生命周期
CIP 会经历一组定义的阶段：
- 草稿 — 作者制定提案并在
cip-discuss邮件列表上收集反馈。现阶段，CIP 尚未有正式数字。 - 提议 - 在获得两名超级验证者的赞助后，作者将 CIP 提交到
cip-vote邮件列表以供正式考虑。 CIP 编辑此时分配正式编号。 - 批准 — CIP 在 10 天的投票窗口中获得超级验证者权利持有者的三分之二多数票。
- 有效 - 对于不需要链上实施的已批准 CIP（例如流程或信息 CIP），提案在批准后立即生效。
- 最终 - 对于需要链上采用的已批准 CIP（通常是标准跟踪、治理或代币经济 CIP），一旦三分之二的超级验证者在链上实施了变更，该提案就会进入最终阶段。
CIP 还可能达到正常进展之外的三种最终状态之一：撤回（作者撤回提案）、推迟（推迟以供将来考虑）或拒绝（未能达到三分之二投票阈值）。已被后续提案取代的 CIP 标记为 已替换 — 例如，CIP-0073 被 CIP-0096 替换。
编号约定
作者不会自行分配 CIP 编号。在草稿阶段，您可以使用描述性别名（例如，CIP-johndoe-token-lockup）。一旦提案通过编辑审查，CIP 编辑就会分配官方序列号。数字使用四位补零格式：CIP-0000、CIP-0056、CIP-0103 等。编号是严格顺序的，并且不会编码类型或类别信息 - 您可以根据其前导码元数据而不是其编号来确定 CIP 的类型。
谁可以提出 CIP
任何公众都可以撰写 CIP。您可以通过 lists.sync.global 加入 cip-discuss 邮件列表并在那里开始讨论。实际上，CIP 作者包括超级验证器运营者、应用程序开发者和生态系统贡献者。
并非所有变更都需要 CIP。对特定软件项目的小幅增强通过该项目自己的开发工作流程进行。当更改影响验证器之间的互操作性、修改治理规则、更改代币经济学参数或建立多方必须实施的网络范围标准时，您需要 CIP。如果有疑问，请在cip-discuss列表上展开讨论——社区和编辑将建议是否需要正式的 CIP。要从讨论进入正式投票，您需要两名超级验证者的赞助。赞助表明至少有两家 SV 运营商认为该提案值得进行全网络投票。这并不意味着赞同该提案的内容。
审核批准
CIP 编辑管理审阅过程。他们的职责包括验证技术可靠性、确认社区讨论已在邮件列表上进行、验证格式合规性以及分配官方 CIP 编号和类别。编辑可以独立进行编辑更正，但不能决定是否应批准 CIP——该决定属于超级验证者投票。当前的编辑团队列于 CIP-0000。
在 CIP 进行投票之前，cip-discuss 邮件列表适用最短讨论时间：
- 标准跟踪：3个月
- 治理和代币经济学：各 1 个月
- 流程：1个月
- 信息性：2 周
这些最低限度的存在是为了确保提案得到与其影响相关的充分审查。标准跟踪 CIP 改变协议行为比信息指南需要更长时间的讨论。
一旦讨论期结束并且两名超级验证者同意赞助该提案，就可以使用 GitHub 团队投票对 cip-vote 列表进行投票。投票窗口持续10天。批准需要超级验证人权利持有者三分之二多数投票赞成。
与链上治理的关系
对于需要链上变更的提案，通过投票流程获得 CIP 批准并不是最后一步。一旦 CIP 获得批准，超级验证者必须通过链上治理行动来采用它——与 SV 治理参考 中描述的相同 BFT 投票机制。只有三分之二的超级验证者在链上实施了更改后，CIP 才会达到最终状态。
这种两阶段结构将设计共识（链下 CIP 投票）与运营承诺（链上采用）分开，确保批准的提案在成为权威之前得到实际部署。链上实施结果通过 Canton Coin Scan API 可见，因此您可以通过检查超级验证器的采用情况来验证给定的 CIP 是否已达到最终状态。
CIP文档结构
CIP 遵循一致的格式，以便审核者可以有效地评估提案，实施者可以找到他们需要的信息。每个 CIP 必须包括以下部分：
- 序言 — 元数据标头：CIP 编号、标题、作者、状态、类型、日期和许可证
- 摘要 — 大约 200 字的问题摘要和建议的解决方案
- 规范 — 详细的技术或治理变更，编写得足够精确，以便超级验证者验证合规性
- 动机 - 为什么当前状态不充分以及提案所解决的问题
- 基本原理 — 设计决策、考虑的权衡以及拒绝的替代方案
- 向后兼容性 - 任何重大更改和迁移路径（如果适用）
- 参考实施 — 标准轨道 CIP 达到最终状态之前需要
- 版权 — 已批准许可证下的许可条款
CIP 存储库包含一个可以用作起点的模板。有关创作和提交 CIP 的分步过程，请参阅下面的如何提议 CIP。
著名的 CIP
以下 CIP 说明了该流程涵盖的主题范围。
CIP-0056：Canton Network 代币标准（标准轨道，最终版）——定义 Canton Network 上代币操作的六个标准化 API，涵盖元数据、持有、点对点转账和货银两账结算。 Canton Coin 实现了所有标准 API。 CIP-0056 借鉴了 ERC-20 的思想，但适用于 Canton 的 UTXO 模型和隐私架构。如果您要在 Canton Network 上构建代币，这就是您需要实施的标准。CIP-0078：取消 Canton Coin 费用（Tokenomics，Final）— 消除 Canton Coin 转账的交易费用。持有费仅在硬币到期时保留，以防止经济上不可行的灰尘硬币的积累。这一变化简化了以前需要费用资助逻辑的开发人员工作流程，并且是可行的，因为大约 95% 的主网消耗已经来自流量购买而不是转账费用。
CIP-0073：加权验证者活跃度奖励（Tokenomics，已被 CIP-0096 取代）——将验证者活跃度奖励扩展到任何一方，并引入了治理可调的奖励权重乘数。该 CIP 后来被 CIP-0096 取代，后者改进了奖励模型。
CIP-0103：dApp 标准（标准跟踪，已批准）- 指定供应商中立的 dApp API，将网络连接和密钥管理与应用程序逻辑解耦。该标准支持同步和异步操作模型，允许任何 dApp 与任何钱包实现配合使用。
资源
- GitHub 上的 CIP 存储库 — 所有 CIP 文档和规范的 CIP-0000 流程定义
- CIP-0000: CIP流程 — CIP流程的权威规范，包括编辑团队、投票规则和格式要求
- GSF 邮件列表 — 进行 CIP 讨论和投票的
cip-discuss和cip-vote列表 - SV治理参考 - CIP在批准后纳入的链上治理机制
如何提出 CIP
任何人都可以编写 CIP。在提案成为 Canton Network 标准的可接受部分之前，该过程会经历几个阶段：
- 草案——作者撰写提案并提交社区审核
- 讨论——社区审查、辩论并提出更改建议
- 审核——根据反馈完善提案并正式审核
- 接受——超级验证人通过链上治理对提案进行投票
- 实施——构建并部署已接受的更改
并非每个 CIP 都能获得接受。提案可以由作者撤回、推迟以供将来考虑或由超级验证者投票拒绝。
编写 CIP
CIP 作为拉取请求提交到 GitHub 上的 CIP 存储库。每个 CIP 都位于其自己的目录中（例如，cip-0056/cip-0056.md）。
CIP 文件应包括以下部分：
- 序言 — CIP 编号、标题、作者、状态、类型和创建日期
- 摘要 — 对提案的简短（200 字或更少）描述
- 动机——为什么需要这种改变，它解决了什么问题，以及谁受益
- 规范 — 拟议变更的精确技术细节，写得足够清楚，以便实施者可以根据
- 基本原理——为什么规范是这样设计的，包括考虑和拒绝的替代方案
- 向后兼容性 — 更改如何影响现有部署、合同或集成
- 参考实现 — 如果适用，工作实现的链接或描述
- 安全考虑 — 该提案的任何安全影响
规格部分是最重要的。它应该明确且足够完整，以便两个独立的团队可以实施它并得出兼容的结果。
CIP 类型
CIP 通常属于以下类别之一：
- 标准跟踪 — 对网络协议、Daml 包、API 或影响互操作性的其他规范的更改
- 流程 — 对 CIP 流程本身或治理程序的更改
- 信息性——不需要治理投票的指南、建议或设计原理
讨论阶段
提交拉取请求后，提案进入社区讨论。这是通过以下方式发生的：* 对 GitHub 拉取请求的评论
- CIP 讨论邮件列表 上的主题
- 相关 Slack 频道中的对话（#gsf-global-synchronizer-appdev、#gsf-outreach）
作者应该期待反馈并准备修改提案。常见反馈包括要求更精确的规范语言、有关向后兼容性的问题以及额外安全分析的建议。
讨论期没有固定的持续时间。当作者和社区达成粗略共识，认为提案已明确说明且未解决的问题已得到解决时，CIP 就已准备好进行正式审查。
正式审核及验收
一旦 CIP 被认为成熟，就会进入正式审查阶段。在此阶段：
- CIP 在存储库中标记为“审核”状态。
- 超级验证者根据自己的运营和业务需求评估提案。
- 通过 SV Web UI 发起治理投票。接受需要获得法定数量的超级验证者（大约 2/3 已加入的 SV）的批准。
如果投票通过，CIP 状态将更新为“已接受”并且可以继续实施。如果投票失败，作者可以修改提案并重新提交，或者撤回。
接受后
接受的 CIP 成为 Canton Network 标准的一部分。实施可能涉及：
- 对 Splice 代码库的更改 (github.com/canton-network/splice)
- Canton 或 Daml SDK 组件更新
- 在超级验证器集中协调配置更改
- 通过标准升级流程部署新的 Daml 包
CIP 存储库跟踪每个已接受提案的实施状态。
有效提案的技巧
- 首先搜索现有 CIP 和讨论档案，以确保您的想法尚未被提出或解决。
- 尽早与社区交谈。在编写完整的 CIP 之前在讨论渠道中提出想法可以节省时间并改进提案。
- 在规格部分具体说明。含糊的语言会导致长时间的讨论和延误。
- 明确解决向后兼容性问题，即使您认为更改是完全向后兼容的。审稿人会问这个问题。
- 考虑与 CIP 一起编写参考实现。具有工作代码的提案往往会更快地通过审查。
本文由 CC Privacy Club 根据 Canton Network 官方文档（CC-BY-4.0）整理翻译，仅供学习；实现细节以官方最新版本为准。