原文標題：《比特幣改進提案的運作流程 | 觀點》
撰文：kant
比特幣是去中心化的和開源的，這意味著沒有集中的許可權來決定協議升級。因此，任何人都可以參與到其程式碼修改，變更的議程中。本文介紹了什麼是 bip （bitcoin improvement proposals，比特幣改進提案），以及詳細展示 bip 協議的治理是如何運作的？
為什麼需要 bip？
在比特幣發展早期，並沒有一個讓社羣成員共同討論、提出有效建議並得到認可、實施的系統的存在。
比特幣的維護與迭代更新落到了核心開發者的身上。中本聰在初始階段為比特幣寫下了基礎的框架，但系統可能出現的執行問題以及為了適應現實需求所要進行的升級卻是無可避免。早期出現這些情況時，往往是中本聰自己進行處理，當中本聰退出後，維護與迭代更新的任務落到了當初的比特幣核心開發者身上。
由於社羣的擴充套件，社羣討論將會導致技術分歧。當時比特幣核心開發者只是一個小團體，有要修改的地方就直接內部討論併發布，但當社羣發展壯大時，這種方式就容易引發技術分歧，有開發者認為比特幣核心團隊對比特幣協議有過多的控制，這將會是導致比特幣失敗的最終原因。因此，提出了 bip （比特幣改進建議）。
bip 的兩個版本
2011 年 8 月 19 號 bip0001 開始實施。bip （bitcoin improvement proposals，比特幣改進提案），這個概念最先由 amir taaki 在 2011 年 8 月 19 號提出，這個提案也就成為了第一個 bip。bip0001 定義了 bip 的基本流程。
2016 年 2 月 3 日 luke dashjr 提出 bip0002。bip0001 基本滿足當時社羣對於開發流程正式化的需求，但由於其中很多的細節沒有描述詳細，且有部分的規範已經過時，而 bip0002 在此基礎上進行迭代，最後得到實施並替代了 bip0001 成為目前在使用的 bip 規範。
提交 bip 前應該做什麼？
當你有了一個具體的針對比特幣的新的想法後，確認你的想法適用於 bip，一些小的更新或者漏洞修復，直接到特定的專案開發提交問題即可，並不足以成為一個 bip。
首先，在各大相關論壇上公開驗證想法，以節省時間。在編寫 bip 之前，先在適當的地方公開想法，可以是比特幣郵箱列表（[email protected]）或 bitocoindev irc 或相關技術論壇，讓大家提出意見。這樣的好處在於可以節省自己的潛在時間，能在大量的工作之前發現自己的想法是否存在問題。
另外，需要詢問的是這個想法是否是之前沒有人提出過的。很多人都提出過很多關於比特幣的想法，但最後都因為種種原因被否決了。所以你的想法可能之前就有人提過出類似的內容但沒有成功被實現。如果存在這種情況，發掘出沒有被實現的原因是什麼，如果不能解決則不要花費太多時間在註定要被拒絕的事情上了。
同時，需要確保的是你的想法是適用於整個社羣的。有些時候這個想法自己看起來不錯，但是並不適用於比特幣社羣的大部分人，這種想法最終也是要被拒絕的。
bip 的格式要求
當你在社羣發表了這個想法並覺得有被接受的可能性時，你就可以著手撰寫 bip 草案了。但是，bip 有嚴格的格式要求，不根據格式撰寫會被直接退回。
一個合格的 bip 草案需要包含以下內容：
- 序言：包 含 bip 的基本資料的序言，需要按照特定格式寫
- 摘要：對要解決的技術問題的簡短的描述（約 200 個字）
- 版權：需要根據特定版權條款獲得明確許可
- 動機：清楚地解釋為什麼現有的協議不足以解決本 bip 要解決的問題
- 規範：技術規範應足夠詳細地描述任何新功能的語法和語義。
- 原理：描述設計的動機和為什麼要做出這個特定的設計決策用以補充規範
- 向後相容：所有引入向後不相容的 bip 都必須包含描述這些不相容及其嚴重程度的部分。bip 必須寫明作者建議怎樣處理這些不相容問題。如果沒有足夠的向後相容性論述，bip 提交可能會被直接拒絕。
- 參考實現：參考實現必須在賦予「最終」狀態之前完成，但是在 bip 被接受之前不需要完成。
一個合格的 bip 草案還需要注意格式
序言格式需要注意：
- bip: //bip 編號，如果是草案階段就填寫「？」
- * layer: // 記錄 bip 作用於哪個層級，在 bip123 有不同層級的定義
- title: //bip 的標題，最多是 44 個字元
- author: // 作者的名字與電子郵件地址
- * discussions-to: // 討論 bip 的郵件列表地址
- * comments-summary: //bip 得到的評論的總結
- comments-uri: // 檢視 bip 評論的 wiki 地址
- status:
- withdrawn | final | replaced | obsolete> // 標明當前的 bip 處於什麼狀態
- type: // 標明 bip 所屬型別
- created: //bip 被分配標號的日期
- license: // 使用的許可證書
- * license-code: // 許可碼
- * post-history: // 釋出的時間（釋出到比特幣郵件列表）
- * requires: // 所依賴的 bip 編號
- * replaces: // 代替了的 bip 編號
- * superseded-by: // 被哪個 bip 所替代了
除帶 *號的內容其他都是必需的
bip 的附件格式需要注意。bip 可能包括圖表等附件，附件應包含在該 bip 的子目錄中，且必須命名為 bip-xxxx-y.ext，其中「 xxxx」是 bip 編號，「 y」是序列號（從 1 開始），「 ext」被實際的副檔名替換（例如「 png」 」）。
bip 的稽覈流程
bip 草案撰寫完畢後，就需要將完整的文件提交到比特幣開發郵件列表，所有訂閱了該郵件列表的人都能接收到你的提案。
在社羣中將 bip 草案公開，對完整提案再次進行討論。此時你需要針對這個 bip 草案再次在社羣進行公開討論。上次進行的公開討論僅僅是一個想法，本次是針對完整的提案進行討論。
對 bip 草案進行再次修訂，傳送給編輯。嘗試引導社羣成員成為你的 bip 的擁護者並積極聽取社羣成員的意見，然後對你的 bip 進行再次修訂。當你感覺準備好了，就可以把你的 bip 傳送給 bip 編輯了。當前的 bip 編輯是 luke dashjr，可以透過 [email protected] 聯絡到他。
bip 編輯的職能
當 bip 編輯收到新的 bip 草案之後，他會執行以下操作：
- 檢查 bip 整體是否準備就緒。已經準備就緒的 bip 有兩個特性：完整與健全。就是說草案的內容是完整的滿足規範的且沒有漏洞、經得起推敲的。
- 檢查標題是否準確描述了內容
- 檢查是否有事前發到比特幣開發郵件列表進行公開討論
- 檢查動機是否有被完整描述、向後相容性是否有被解決
- 檢查是否按照規範正確分配序言中的 layer 標籤
- 檢查許可證是否在規定範圍內
如果 bip 編輯認為你的 bip 還沒有準備好，會說明原因併發回給你，你針對 bip 編輯給的說明重新編輯修訂後，再次傳送即可。
經過完善後，你可以拉取請求提交到 bips git 倉庫中。收到拉取請求後，bip 編輯將會進行以下操作：
- 給你的 bip 分配一個 bip 編號，這樣你的 bip 算是正式誕生了！
- 標記你的 bip 型別（標準跟蹤、資訊性、流程）
- 合併你的拉取請求，此時 bip 就加入了 bip 倉庫
- 在 readme.mediawiki 中列出你的 bip，大家都能方便檢視動態
到此為止，你的 bip 會再次公開，從而得到進一步的社羣反饋。
bip 的型別共有三種：
- 標準跟蹤 bip：描述了影響大多數或所有比特幣實現的任何更改，例如網路協議的更改，塊或交易有效性規則的更改，或任何影響使用比特幣的應用程式互操作性的更改或增加。
- 資訊性 bip：描述了比特幣設計問題，或向比特幣社羣提供了常規準則或資訊，但未提出新功能。資訊性 bip 不一定代表比特幣社羣的共識或建議，因此使用者和實施者可以自由地忽略資訊性 bip 或遵循其建議。
- 流程 bip：描述了圍繞比特幣的流程，或提出流程的更改（或其中的事件）。流程 bip 類似於「標準跟蹤 bip」，但作用於比特幣協議本身以外的區域。流程 bip 可能會提出實施方案，但不會是針對比特幣的程式碼庫的；他們經常也需要社羣的共識；與資訊 bip 不同，它們不僅僅是建議，而且使用者通常不能隨意忽略它們。過程，指南，決策流程的更改以及比特幣開發中使用的工具或環境的更改這些都是屬於流程 bip。
bip 的最終實現流程
當你的 bip 透過稽覈並併入到 bip 倉庫後，抓緊時間推進你的 bip，畢竟自己的想法得以實現並作用於社羣會給你會帶來很大的成就感。
流程 bip 和資訊 bip 將會討論月餘時間，若無反對意見，就即可生效。那麼就如果是流程 bip、資訊 bip，只要在郵件列表上討論超過一個月後，沒有任何未解決的的反對意見，我們就可以判定這個 bip 達成了大部分共識，這個 bip 的狀態將會更改為「啟用」，真正作用於比特幣社羣了。
而標準追蹤 bip，則會更加複雜和謹慎。你的目標會是把 bip 狀態從「草案」變為「最終實現」。
在 bip123 中把標準 bip 分成了四層共五類：
- 共識層（軟分叉、硬分叉）
- 對等服務層
- api/rpc 層
- 應用層
不同分類的 bip 達到「最終實現」狀態所需要達到的條件不一致。
- 軟分叉 bip 嚴格要求需要礦工的大部分投票。考慮到礦池的存在，一般情況下需要 95% 的絕大多數投票贊同。
- 硬分叉 bip 則更嚴格，需要比特幣整個社羣的成員的採納，特別包括使用比特幣來買賣商品、儲存交易比特幣的人。基本上說需要比特幣社羣的全部成員的認可才有可能實現硬分叉，達成這樣的共識是極度困難的，因此在比特幣歷史上沒發生過真正的針對比特幣的硬分叉升級。
- 對等服務 bip 則要求應監控到至少 1% 的公共監聽節點採用該 bips 一個月
- api/rpc 和應用層 bip 則至少由兩個獨立的、相容的軟體實現。
以上流程都是很複雜且漫長的，往往是多方的博弈的結果。作為 bip 的擁有者，在這階段你要做的就是不斷推動你的 bip，接觸更多的社羣人員，努力宣揚自己的設計理念，闡述你的 bip 將會如何對比特幣社羣產生積極的影響，爭取更多的社羣人員成為你的 bip 的擁護者，一步一步把你的 bip 實現。
bip 的狀態改成「最終實現」將是對你最大的獎勵。
來源連結：mp.weixin.qq.com
