透過 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 <admin@chaindaily
或（如果包含電子郵箱地址或 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 做出評判，只負責行政和編輯部分。
