协议演进 / BIP/比特币改进提案 / BIP-123
BIP-123
按互操作要求把标准类 BIP 分入共识、对等服务、接口、应用四层，并给出每层的归属判据。本 BIP 目前处于已部署状态。
一、档案卡
| 编号 | BIP-123 |
|---|---|
| 标题 | BIP Classification |
| 作者 | Eric Lombrozo <[email protected]> |
| 指定日期 | 2015-08-26 |
| 类型 | Process（流程类） |
| 状态 | Deployed（已部署） |
| 阅读版 | https://bips.dev/123 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki |
注：本 BIP 原文没有 Layer 字段——它定义的正是“层”本身；本站按其流程类属性归入流程层。
二、放在哪一族
BIP 流程与分类族，是给所有 BIP 贴“系统层”标签的元文档。BIP-1 定下了提案的类型（标准类／信息类／流程类）与流程，现行流程由 BIP-3 承接；BIP-123 补的是另一维：每份标准类 BIP 属于哪个系统层。
这一维至今写在每份新 BIP 的文件头里（Layer 字段）。本档案站每篇解读“档案卡”中的层级、以及 lede 开头的“共识层（软分叉）”“应用层”等字样，用的就是这套分类：例如 BIP-115 至 BIP-119 标为 Consensus (soft fork)，BIP-120 至 BIP-122 标为 Applications，都是按本 BIP 的定义归层的。
原文末尾还附了一张当时已有 BIP 的分类总表，把 1 号到 152 号之间的提案逐一归层（该表状态为当时的快照，如其中 BIP-1 仍标 Active、不少后来定稿的提案仍标 Draft；现行状态以仓库为准）。
三、它要解决什么
比特币不是单一标准，而是一叠标准：有些是互操作不可缺的绝对要求，有些是可选的，实现者可以自行取舍。若不加区分地走同一套提案流程，轻重缓急全被抹平——改一行应用约定的文档，和改共识规则的文档，看起来分量相同，实际风险与推广难度天差地别。
原文的出发点是：让 BIP 流程更贴合各自的互操作要求，就必须先按层分类。层号越低，互操作要求越精细、越苛刻，标准被接受与部署的挑战也越大。分类不是贴标签比赛，而是给每份提案标明“动的是系统的哪一层、出问题会出多大的问题”。
四、规则本身
标准类 BIP 必须归入四层之一；非标准类 BIP 可以归入这些层，也可以不归层。
4.1 第一层：共识层（Consensus）
定义密码学承诺结构。其职责是让任何人都能在本地判定某个状态与历史是否有效，提供结算保证，并确保最终收敛。共识层不关心消息如何在网络上传播。
这一层的分歧会造成网络分裂（分叉）：不同节点可能接受互不兼容的历史。共识层变更再细分为：
- 软分叉：旧规则下有效的某些结构在新规则下不再有效；旧规则下无效的结构在新规则下仍然无效（规则只收紧）；
- 硬分叉：旧规则下无效的某些结构在新规则下变为有效（规则放松）。
4.2 第二层：对等服务层（Peer Services）
规定节点如何彼此发现、如何传播消息。基本节点互操作只要求其中一个子集，其余服务是可选扩展。
这一层的演进方式也最温和：可以先加新服务而不破坏与既有服务的兼容，再逐步弃用旧服务，整个网络能平滑升级，不必冒服务中断的风险。
4.3 第三层：接口层（API/RPC）
规定供应用调用的高层接口。支持这一层的 BIP 不是基本网络互操作的前提，但某些客户端应用会期待它存在。
这一层容得下竞争性标准并存：几套接口方案互相竞争，也不会破坏基本的网络互操作。
4.4 第四层：应用层（Applications）
规定高层结构、抽象与约定，让不同应用能支持相似的功能、共享数据。地址格式、钱包结构、URI 方案这类“应用之间说得通”的约定属于这一层。应用层约定错了，代价通常限于应用之间不兼容，不会动摇网络本身。
4.5 归层的判据
综合原文定义，判断一份标准类 BIP 归哪层，看三点：它改的对象是什么（有效性规则／节点间消息／应用接口／应用间约定）；不支持它会破坏什么级别的互操作（全网分裂／节点互通／应用预期／应用间兼容）；它能否与同类方案并存（接口层可以，越往低层越不行）。
五、谁必须动
普通持币人：无直接动作。它不改协议，只改“怎么给提案归类”。
BIP 作者：写标准类提案时须按本分类在文件头标明 Layer；归层错误会误导评审对风险与部署难度的判断。
BIP 编辑与评审者：按本 BIP 给出的各层定义与判据核定归属，尤其要分清共识层的软／硬分叉。
节点与钱包实现者：不必为本 BIP 本身改代码；它的作用是帮实现者一眼看清每份提案动的是哪一层、与自己的实现有多大关系。
六、现在算不算数，以及一个常见误读
状态为 Deployed（已部署）。四层分类（Consensus／Peer Services／API/RPC／Applications，以及共识层下软／硬分叉的再分）已是 BIP 仓库沿用至今的文件头惯例，本站每篇 BIP 解读的层级标注即源于此。它“部署”的方式不是激活某个协议规则，而是成为提案写作与阅读的共同语言。
常见误读：“层号越低越重要，应用层的 BIP 就可以不认真看。”不对。原文说的是层号越低、互操作要求越精细、部署越难，并非价值排序。应用层的约定（如地址与钱包标准）恰恰是用户每天直接接触的部分；分类标明的是风险类型与推广方式，不是轻重等级。
七、延伸
- 阅读版：https://bips.dev/123
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki
- 相关：BIP-1 BIP 的目的和指南、BIP-3 现行 BIP 流程
- 仓库总目录：https://github.com/bitcoin/bips