比特币标准文件里有一份几乎没人日常提及、却被邻国整个抄走的元规则：2015 年 8 月领号、状态为 Deployed 的 BIP-123。它不改进任何协议，只做一件事——给标准类提案分层。层只有四层：共识、对等服务、API/RPC、应用。规则一句话：层号越低，互操作性要求越苛刻，达成与部署的难度越大。以太坊在当年 11 月用 EIP-4 直接移植了这套框架，可见其解释力。
共识层：分歧的代价是分链
原文给共识层的职责定义得非常窄也极重：定义密码学承诺结构，目的是让任何人能本地评估一段特定的状态与历史是否有效、提供结算担保、保证最终收敛。它特意加了一句边界声明：共识层不关心消息如何在网络上传播。判据的威力在后果段：共识层的分歧会造成网络割裂，不同节点接受互不兼容的历史——也就是分叉。提案还把共识层变更再细分：旧规则下有效的结构中有一部分在新规则下失效，是软分叉；旧规则下无效的变得有效，是硬分叉。读懂这两句，你就能预判任何一份标着 Consensus 层的提案将面对的审查强度。
对等服务层：无损换件的缓冲区
第二层规定节点如何发现彼此、如何传播消息。这一层的工程美感在于它明确允许渐进：全部对等服务中只有子集是基础互操作必需的，节点可以支持可选扩展；新服务可以在不破坏既有服务兼容性的前提下添加，旧服务可以随后逐步废弃——整个网络因此能「不带严重服务中断风险」地升级。换句话说，层二的设计目标是让标准竞争以毫秒和带宽为赌注，而不是以资产安全为赌注。
API/RPC 层：允许标准打架
第三层是应用可直接调用的高层接口。原文对它的态度是实用主义：基础网络互操作不需要它们，但某些客户端应用会期待；这一层容许竞争性标准并存而不破坏互操作。矿机与矿池之间的建块接口就落在这一带——两套接口并存多年，谁也没把谁挤死，因为钱包不关心。
应用层：跨软件的共同语言
最上层规定让不同应用支持相似功能、共享数据的高层结构、抽象与惯例——钱包派生路径、收付款 URI、PSBT 这些都是常客。应用层提案失败的成本是「又一个没人用的标准」，与共识层提案失败的成本完全不可同日而语。
附带伤害：那张存量归类表
BIP-123 在规范之外附了一张长表，把当时已存在的 BIP 逐个标上层、类型与状态。这份好意制造了一个长期副作用：表里的快照与后续演化不完全同步，例如部分条目仍用着后来废弃的类型词，表格颜色编码反映的是写入当年的状态。今天查某个旧提案的归类，应以该提案文件的头部字段为准，表格只当历史索引读。这个细节也是「文档即快照」与「流程即活体」张力的教科书案例。
快速问答
问：一个提案改的东西横跨两层怎么办？ 答：以互操作性要求的最高层归类，或拆成多份各归各层；拆层写作正是这套框架鼓励的做法。
问：信息类提案也要分层吗？ 答：只有标准类必须落入四层之一；非标准类可以选层，也可以不属任何层。
问：这套分层怎么影响新提案的命运？ 答：分层本身不设门槛，但它公开了默认预期：标成共识层等于自愿接受最严的审查、最慢的周期和最保守的兼容承诺。
一条直觉线
可以把四层想成一栋楼的安全等级：地下室（共识）承重，动一根钢筋都要全楼复核；管道井（对等服务）可以边住边换；插座（API）各房间自己选标准；家具（应用层）不喜欢可以整个扔掉。BIP-123 的全部智慧就是把「改动该多谨慎」翻译成「改动在几楼」。
常见误区
一是把层号当成重要性排名，实际是谨慎度排名；二是拿旧表当现行数据库查归类；三是以为分层能阻止一份提案同时改动多层行为，分类管文档归档，设计一致性要靠评审把关。
风险提示：本文解释标准分类框架，不构成投资建议；具体提案的层级以其文件头声明为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。