比特币改进提案该怎么算”通过”?BIP-0001 规定了提案怎么写、怎么提交、状态词有哪些,但对”社区什么时候算接受了它”始终含糊。2015 年 8 月,Andy Chase 提交 BIP-132,试图把答案写成制度:成立委员会,分四段投票,按代表性加权,四段里三段达到七成认可即接受。这份 Type 为 Process 的提案最终 Closed,今天没人再执行它,但它是比特币治理史上少见的”把默会规则显式化”的完整尝试,读它仍然值得。
流程本身写得像行政条例。一份草案先 Submit for Comments,由提案发起人(champion)在开发邮件列表发帖触发,公开征集两周意见;随后进入意见汇总期,委员会须在提交后四周内给出表态,到点即裁决,结果只有 Accepted 或 Deferred 两种,没有否决票。委员会是裁决主体:按生态角色分四段——比特币软件、交易所与商户及支付服务、矿池运营商、用户社区——每个委员会必须声明并维持”至少代表百分之一比特币生态份额”的主张,证明方式按段位各不相同:软件方看所有权与用户基数、商户方看经济活动量、矿池方看算力占比、用户组织看可审计签名。裁决门槛设在 70%:四段中的三段认可其代表份额的七成以上,提案即被接受;委员会缺席表态按”拒绝接受”计。
这套设计的聪明与天真各占一半。聪明之处在于分段的切法:它承认比特币生态没有单一决策者,客户端作者决定代码是否进主干、矿工决定区块是否携带信号、商户和用户决定实际采用,四条腿缺一条都是瘸的。代表性主张靠委员会自己公示,用公开声明替代选举——权重由谁站出来、谁背书决定,全程留痕。天真是权重自证这个环节:文档自己在 Weaknesses 一节承认,委员会提交的是”声明”,证明多少代表性、以及读者是否采信,最终都回到主观判断;作者的回应是”反正 BIP 不能被强加给任何人,这个流程只是判断压倒性接受度的工具,若有争议即视为 Deferred”。
放回时间线更好理解它的命运。2015 年正是扩容大辩论的前夜,各方都在争夺”谁代表社区”的话语权,BIP-132 想要的恰是把话语权量化——这在技术上做不到,在政治上更做不到。后来的历史走向相反方向:软分叉激活彻底绕开”宣布接受”这个环节,改用 BIP9 版本位让节点在区块里持续表态,达到阈值自动锁定生效;所谓接受,变成一段可验证的信号曲线,而不是一份委员会公报。BIP-132 的裁决问题因此被釜底抽薪:不需要有人宣布通过,规则自己数票。今天再看,它的遗产是一个反面教材加一份问题清单——哪些角色有否决性的影响力?代表性如何量化才不沦为表演?流程裁决和技术裁决边界在哪?任何公链设计提案流程时,这三个问题都还得回答。
常见误区有三。其一,以为四分段各有否决权:门槛是”四段中三段过七成”,任何单段都可以被另外三段越过。其二,把 Accepted 和链上激活混为一谈:即便按此流程通过,也只是”社区认可”,代码合并与激活仍是另一套技术流程——这正是它被 BIP9 取代的伏笔。其三,以为这个流程还有效:它已 Closed,现行 BIP 状态词表里根本没有 Accepted 这个词。
快速问答。问:那今天 BIP 到底怎么算”被接受”?答:代码级看客户端实现与发布,共识级看 BIP8/BIP9 类信号激活曲线,社会级看讨论与采用,三个层面各自演化,不再有一个统一裁决。问:BIP-132 和 BIP-100 之类扩容提案什么关系?答:同一代争论的产物,那段历史推动了从”宣布式激活”向”信号式激活”的整体转向。
风险提示:本文是治理史科普,不构成投资建议,也不代表对任何链上治理机制的推荐。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。