了解什么是比特币改进提案以及它是如何运作的。

原文标题：《比特币改进提案的运作流程 | 观点》
撰文：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 之前，先在适当的地方公开想法，可以是比特币邮箱列表（bitcoindev@lists.linuxfoundation.org）或 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，可以通过 luke_bipeditor@dashjr.org 联系到他。

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 的状态改成「最终实现」将是对你最大的奖励。