共识之迷：一文读懂比特币升级社区进展

撰文：kevin He，Bitlayer 联合创始人

前言

关于比特币下一次升级的话题一直不绝于耳，然而到目前（DEC-2024）为止，社区对于要不要升级 / 升级要解决的问题 / 要带来的功能等话题并还没有达成一致，基本上是各执一词的情况，像极了某种政治僵局。

在这种僵局下，呈现了很多有趣的现象：

一部分社区成员积极推动升级，出于信息不对称或者商业利益，某些成员言必称某些 opcode，一些项目会依赖某些「可能会出现」的 opcode。
相当多务实的生态开发者基于不做协议升级的前提，做了大量的密码学和工程工作，来拓展比特币的潜力。
倡导缓慢升级或者反对升级的声音也不在少数。

这些现象的出现，说明升级的话题在比特币社区相当热门，但是也体现了相当部分的社区成员对于一次比特币升级完整过程并不了解，同时也缺乏对于创新密码学工具对发挥比特币潜力的作用。本文的核心写作目的正是打破这种信息不对称，让所有人的信息在同一水平线上，进而做更深入的讨论。

本文将对比特币的升级做相关定义，通过回溯历史来归纳某些规律，进而分析当前的升级提案和潜在的替代方案，最后为读者总结若干 takeaway。意图通过这些信息呈现，让读者掌握比特币升级的概念 / 历史 / 进展，为读者对比特币升级话题进行进一步的讨论奠定基础，为最终社区共识的形成做铺垫。

本文努力呈现事实，同时作者作为比特币生态开发者，期望比特币能有更多的可能性，因此作者会表达对于一些话题的明确的观点，请注意分辨。

升级简介：What and Why

什么是比特币升级

比特币白皮书定义了一个协议，由数以万计遵循比特币协议的节点组成了比特币区块链网络。

协议的实现（通常称为客户端）有很多个版本，根据 bitnodes 数据源显示，市占比最大的客户端是 Bitcoin Core，因此 Bitcoin-Core 的代码维护者（下称 Bitcoin-Core-Devs）在比特币生具备相当重要的影响力。

what-why-1

比特币节点软件有多个模块组成，比特币的相关升级提案由 BIP(Bitcoin Improvement Proposal) 来定义，人们为 BIP 做了若干分类。

通常情况下，当人们讨论比特币升级，一般是指「共识协议升级」，下文同理，由于共识协议升级需要全网络的大部分的节点形成一致的意见（否则就可能会导致分叉），因此需要特别的慎重。如下图所示，比特币系统中的共识协议相关的模块和 BIP 种共识层有关的提案，值得特别关注。

what-why-2

实际上，根据比特币 github 仓库的统计，修改非常活跃，由于大部分的变更都与共识协议无关，因此也没有引起人们的广泛关注。

Bitcoin-core-github-stats

共识协议升级类型

根据 BIP-123 的定义，共识协议的升级主要分为软分叉（soft fork）与硬分叉（hard fork）。

另外，还有一个不是那么直觉的方式来诠释和对比，也很有趣：

Soft fork：增加 / 加强规则（简单想象一下，增加了一个新功能，例如支持 taproot 地址）
Hard fork：移除 / 放松规则（简单想象一下，移除了一个限制，例如移除了区块奖励的限制）

BIP 和软分叉的流程

前两次成功的共识协议升级（Taproot/SegWit），均使用软分叉的方式，在不出现巨大的社区分裂的情况下，本文集中讨论 soft fork（软分叉），即是兼容老版本软件的情况下进行升级。

BIP 提案提交之后，经过的流程大概如下图：

bip-state，来源：https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

通常一个软分叉提案会聚合多个 BIP，例如 taproot 就包含了 3 个 BIP：

Schnorr Signature: BIP-340
Taproot: BIP-341
Tapscript: BIP-342

回顾一下 Taproot 的升级的时间表：

Taproot-timeline，Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

Taproot 软分叉的阶段里程碑包括：

对应的 BIP 被提出，实现方案通过 review
Bitcoin-Core 代码维护者发起升级 github pull request
Bitcoin-Core 代码维护者审核和合并 github pull request，决定激活方式
新版本 Bitcoin-Core 代码发布
矿工链上投票方式来批准 BIP 的激活区块高度
区块高度到达约定高度，完成升级

要注意的是，这个过程是回看历史总结出来的，实际上对这个里程碑也不存在成文的共识。

在整个过程中，Bitcoin Development Mailing List 起到了凝结各方共识的关键作用。

为什么要升级

如文章开头所述，对于升级当前社区主要是有三类声音：

积极推动派：提出了大量的提议，下面会进行分析。
务实建设派：基于现有协议实现 Fraud Proof（BitVM 及其扩展），函数加密（通过 Bitcoin PIPEs 实现的契约和 zk 证明）和哈希碰撞（通过 ColliderScript 实现的契约）等。
维持不变派：他们认为升级应该非常缓慢稳妥（10 年为周期）的 TeamSlowAndSteady，和除非出现量子攻击不要升级的 Ossifiers（参考）

作者做了一下更新与不更新的利弊分析：

作为一个务实的比特币生态开发者，作者认为在现有协议框架下，通过密码学或者工程创新，充分挖掘比特币的潜力是必不可少的，同时从「可持续性」与「适应性」等角度来看，在充分评估影响范围和安全风险的情况下，根据需要来持续升级，是可取的。

升级深入

升级的利益相关方

比特币历史上的香港共识（签署于 2016 年 2 月的比特币圆桌活动，参考）主要参与方是：

Bitcoin-Core-Devs
矿池
用户和生态开发者（主要是交易所 / 芯片厂商等）

随着比特币的采用率的快速提升，比特币升级的利益相关方也从最早简单的三权分立逐步发展演变，进入了列王纷争局面，参考报告 Analyzing Bitcoin Consensus: Risks in Protocol Upgrades。

stakeholders

这里面几个角色值得重点介绍一下：

Economic Nodes：主要是指主流的 CEX 交易所 / 支付机构 / 托管服务商等，他们的在 soft fork 种的态度决定哪种是合法的比特币，会对采用率有重要影响。
Investors：在比特币策略（EFT/ 机构储备 / 国家储备等）在全球盛行的大背景下，投资者这个角色本身变得更加复杂。
User&Ecosystem Developer：在 Taproot 升级之后，比特币生态蓬勃发展，出现了 Ordinals 等资产协议，也涌现了一大批原生应用 / 扩容协议。

对于这些角色，有一些有趣的结论：

不同的利益相关方在不同的阶段发挥不同作用：例如 Ecosystem Developer 对于提案有比较大的积极性，Protocol Developer 经常行使对于 BIP 审核权限，矿池和经济节点对于激活有比较大的影响力
不同的 Ecosystem Developer 倾向提出和支持与自己商业利益相关的提案

升级的历史和总结

根据公开资料，从比特币网络启动以来，发生过多次 soft fork 升级。

soft forks，数据来源：https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/、https://www.drivechain.info/media/slides/mit-2023.pdf

从上图中可以总结出一些有趣的结论：

比特币的协议出现了某种僵化，随着时间推移， softfork 的频次降低
升级的共识达成需要的时间越来越长

Soft Fork 关注方面

分析过往的 soft fork 包含的 BIP，可以总结出有如下的关注方面：

何为好的升级提案

根据前面的各方面列举的事实和分析，我们尝试定义一个好的升级提案：

坚持比特币作为支付系统的核心定位：比特币是有独特定位的
应用潜力 / 带来风险之间取得优雅的平衡：使得大部分人都喜欢，没有人强烈反对
合适的升级规模：不能太简单（不值得大动干戈），也不能太复杂（推动很困难）
合理的时机：需要有强烈的需求，解决特定的问题。例如在 SegWit 升级阶段，扩容是强需求

升级展望

提案归类

作者收集了大部分活跃的提案，尝为他们打上关注方面标签，同时放到四象限中，便于读者进行可视化理解。

对于归类的需要注意：

四个关注方面不完全相互隔离，例如有利于增强可编程性的 BIP 实际上某种程度可能也会有助于可扩展性。
一个提案可能会有多方面的关注，例如 OP_CAT 本身是增强可编程性，但是实际更多人推动是因为它有助于实现 validity rollup。
对于一个提案的关注哪些方面这个话题，就需要某种的「共识」（政治本身），要注意这里并没有唯一的定义，因为不同的参与者会有不同的角度
第二个 diagram 不是坐标系，根据标签进行归类划分，圆圈属性（大小 / 位置 / 颜色等）不具有特殊意义

proposal category-2

proposal category-1

社区呼声

从上图可以看到，社区对于升级要解决的问题有一定的共识，即围绕支付系统所需要的功能扩展，可以归类为如下 2 大类：

可编程性：使得 UTXO 的更强的编程能力，例如 covenant/vault/ 交易自省 / 条件支付 /script 增强等
扩展性：对于 L2 的扩展，整体方案又分为链上验证和链下验证两大类，都有一些积极主推的提案

共识之谜

作者认为，比特币社区对于下一次升级陷入共识的迷宫，原因如下：

僵化：接近 $2T FDV 的软件系统，相当部分的利益相关方倾向于保持稳定，没有哪一方愿意承担事故责任
利益相关方高度分化：不同利益相关的诉求不一样，在不同的阶段能发挥的作用不一样；政府也成了利益相关者
治理机制不完善：比特币作为最早的区块链，缺乏非常完善的治理的机制；社区对于软分叉激活方式也没法达成共识
Protocol Developer 角色本身是动态变化的：即便他们也的确会否决一些提案，但无法用简单的守旧 / 追新来形容
缺乏紧迫性：区块链基础设施发展日趋完善，对于比特币的升级没有非常强的需求

总结&Takeaway

本文通过介绍比特币升级的基础概念，对历史升级进行了深入分析，最后展望了下一次升级的活跃提案，归纳出当前存在的共识之迷的原因。

经过回顾和展望，相信读者已经对于当前升级所处的状态有一定了解，最后总结若干 takeaway。

务实建设同时稳妥推进升级，软分叉更可取
利益相关高度分化，社区倾向于保守
必须在坚持比特币核心价值定位的前提下谈升级
扩展性只是其中一个升级的关注方面
需要一个更好的时机，好的升级提案会快速获得共识
社区需要探索更好的治理机制

致谢

本文调研 / 写作 / 审校过程中，得到了大量的帮助，包括考虑各种因素不愿意署名社区成员，在这里一并致谢。值得注意的是：考虑到文中观点部分带有个人偏好，下列感谢列表不代表他们完全同意文中的内容，本文也无意将这些社区的热心人卷入到任何的争执之中。

协同编辑和审稿（字母排序）：Adrien Lacombe、Bob Bodily、Bitlayer Research Team、Domo、Jeffrey Hu、Red、Ren Zhang、Scott Odell、Super Testnet、Will Foxley

提供了反馈和帮助（字母排序）：Ajian、Andrew Fenton、Ben77、David Tse、Eli Ben-Sasson、Mi Zeng

参考文献

https://bitcoinops.org/

https://opnext.dev/

https://groups.google.com/g/bitcoindev

https://github.com/TABConf/6.tabconf.com

https://petertodd.org/2024/covenant-dependent-layer-2-review

https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/

https://blog.bitmex.com/bitcoins-consensus-forks/

https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki

https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

https://bitnodes.io/nodes/

https://github.com/bitcoin/bitcoin/pulse/monthly

https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

https://trustmachines.co/learn/bitcoin-taproot-upgrade-basic-breakdown/

https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

https://github.com/bitcoin-cap/bcap

https://newsletter.blockspacemedia.com/p/four-takeaways-from-op-next

https://blog.bitfinex.com/education/is-ossification-good-or-bad-for-bitcoin/

https://arxiv.org/abs/2305.04079

https://www.allocin.it/uploads/placeholder-bitcoin.pdf

https://eprint.iacr.org/2024/1802

https://en.bitcoin.it/wiki/Covenants_support

撰文：kevin He，Bitlayer 联合创始人

前言

在这种僵局下，呈现了很多有趣的现象：

一部分社区成员积极推动升级，出于信息不对称或者商业利益，某些成员言必称某些 opcode，一些项目会依赖某些「可能会出现」的 opcode。
相当多务实的生态开发者基于不做协议升级的前提，做了大量的密码学和工程工作，来拓展比特币的潜力。
倡导缓慢升级或者反对升级的声音也不在少数。

本文努力呈现事实，同时作者作为比特币生态开发者，期望比特币能有更多的可能性，因此作者会表达对于一些话题的明确的观点，请注意分辨。

升级简介：What and Why

什么是比特币升级

比特币白皮书定义了一个协议，由数以万计遵循比特币协议的节点组成了比特币区块链网络。

what-why-1

比特币节点软件有多个模块组成，比特币的相关升级提案由 BIP(Bitcoin Improvement Proposal) 来定义，人们为 BIP 做了若干分类。

what-why-2

实际上，根据比特币 github 仓库的统计，修改非常活跃，由于大部分的变更都与共识协议无关，因此也没有引起人们的广泛关注。

Bitcoin-core-github-stats

共识协议升级类型

根据 BIP-123 的定义，共识协议的升级主要分为软分叉（soft fork）与硬分叉（hard fork）。

另外，还有一个不是那么直觉的方式来诠释和对比，也很有趣：

Soft fork：增加 / 加强规则（简单想象一下，增加了一个新功能，例如支持 taproot 地址）
Hard fork：移除 / 放松规则（简单想象一下，移除了一个限制，例如移除了区块奖励的限制）

BIP 和软分叉的流程

BIP 提案提交之后，经过的流程大概如下图：

bip-state，来源：https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

通常一个软分叉提案会聚合多个 BIP，例如 taproot 就包含了 3 个 BIP：

Schnorr Signature: BIP-340
Taproot: BIP-341
Tapscript: BIP-342

回顾一下 Taproot 的升级的时间表：

Taproot-timeline，Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

Taproot 软分叉的阶段里程碑包括：

对应的 BIP 被提出，实现方案通过 review
Bitcoin-Core 代码维护者发起升级 github pull request
Bitcoin-Core 代码维护者审核和合并 github pull request，决定激活方式
新版本 Bitcoin-Core 代码发布
矿工链上投票方式来批准 BIP 的激活区块高度
区块高度到达约定高度，完成升级

要注意的是，这个过程是回看历史总结出来的，实际上对这个里程碑也不存在成文的共识。

在整个过程中，Bitcoin Development Mailing List 起到了凝结各方共识的关键作用。

为什么要升级

如文章开头所述，对于升级当前社区主要是有三类声音：

积极推动派：提出了大量的提议，下面会进行分析。
务实建设派：基于现有协议实现 Fraud Proof（BitVM 及其扩展），函数加密（通过 Bitcoin PIPEs 实现的契约和 zk 证明）和哈希碰撞（通过 ColliderScript 实现的契约）等。
维持不变派：他们认为升级应该非常缓慢稳妥（10 年为周期）的 TeamSlowAndSteady，和除非出现量子攻击不要升级的 Ossifiers（参考）

作者做了一下更新与不更新的利弊分析：

升级深入

升级的利益相关方

比特币历史上的香港共识（签署于 2016 年 2 月的比特币圆桌活动，参考）主要参与方是：

Bitcoin-Core-Devs
矿池
用户和生态开发者（主要是交易所 / 芯片厂商等）

stakeholders

这里面几个角色值得重点介绍一下：

Economic Nodes：主要是指主流的 CEX 交易所 / 支付机构 / 托管服务商等，他们的在 soft fork 种的态度决定哪种是合法的比特币，会对采用率有重要影响。
Investors：在比特币策略（EFT/ 机构储备 / 国家储备等）在全球盛行的大背景下，投资者这个角色本身变得更加复杂。
User&Ecosystem Developer：在 Taproot 升级之后，比特币生态蓬勃发展，出现了 Ordinals 等资产协议，也涌现了一大批原生应用 / 扩容协议。

对于这些角色，有一些有趣的结论：

不同的利益相关方在不同的阶段发挥不同作用：例如 Ecosystem Developer 对于提案有比较大的积极性，Protocol Developer 经常行使对于 BIP 审核权限，矿池和经济节点对于激活有比较大的影响力
不同的 Ecosystem Developer 倾向提出和支持与自己商业利益相关的提案

升级的历史和总结

根据公开资料，从比特币网络启动以来，发生过多次 soft fork 升级。

soft forks，数据来源：https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/、https://www.drivechain.info/media/slides/mit-2023.pdf

从上图中可以总结出一些有趣的结论：

比特币的协议出现了某种僵化，随着时间推移， softfork 的频次降低
升级的共识达成需要的时间越来越长

Soft Fork 关注方面

分析过往的 soft fork 包含的 BIP，可以总结出有如下的关注方面：

何为好的升级提案

根据前面的各方面列举的事实和分析，我们尝试定义一个好的升级提案：

坚持比特币作为支付系统的核心定位：比特币是有独特定位的
应用潜力 / 带来风险之间取得优雅的平衡：使得大部分人都喜欢，没有人强烈反对
合适的升级规模：不能太简单（不值得大动干戈），也不能太复杂（推动很困难）
合理的时机：需要有强烈的需求，解决特定的问题。例如在 SegWit 升级阶段，扩容是强需求

升级展望

提案归类

作者收集了大部分活跃的提案，尝为他们打上关注方面标签，同时放到四象限中，便于读者进行可视化理解。

对于归类的需要注意：

四个关注方面不完全相互隔离，例如有利于增强可编程性的 BIP 实际上某种程度可能也会有助于可扩展性。
一个提案可能会有多方面的关注，例如 OP_CAT 本身是增强可编程性，但是实际更多人推动是因为它有助于实现 validity rollup。
对于一个提案的关注哪些方面这个话题，就需要某种的「共识」（政治本身），要注意这里并没有唯一的定义，因为不同的参与者会有不同的角度
第二个 diagram 不是坐标系，根据标签进行归类划分，圆圈属性（大小 / 位置 / 颜色等）不具有特殊意义

proposal category-2

proposal category-1

社区呼声

从上图可以看到，社区对于升级要解决的问题有一定的共识，即围绕支付系统所需要的功能扩展，可以归类为如下 2 大类：

可编程性：使得 UTXO 的更强的编程能力，例如 covenant/vault/ 交易自省 / 条件支付 /script 增强等
扩展性：对于 L2 的扩展，整体方案又分为链上验证和链下验证两大类，都有一些积极主推的提案

共识之谜

作者认为，比特币社区对于下一次升级陷入共识的迷宫，原因如下：

僵化：接近 $2T FDV 的软件系统，相当部分的利益相关方倾向于保持稳定，没有哪一方愿意承担事故责任
利益相关方高度分化：不同利益相关的诉求不一样，在不同的阶段能发挥的作用不一样；政府也成了利益相关者
治理机制不完善：比特币作为最早的区块链，缺乏非常完善的治理的机制；社区对于软分叉激活方式也没法达成共识
Protocol Developer 角色本身是动态变化的：即便他们也的确会否决一些提案，但无法用简单的守旧 / 追新来形容
缺乏紧迫性：区块链基础设施发展日趋完善，对于比特币的升级没有非常强的需求

总结&Takeaway

本文通过介绍比特币升级的基础概念，对历史升级进行了深入分析，最后展望了下一次升级的活跃提案，归纳出当前存在的共识之迷的原因。

经过回顾和展望，相信读者已经对于当前升级所处的状态有一定了解，最后总结若干 takeaway。

务实建设同时稳妥推进升级，软分叉更可取
利益相关高度分化，社区倾向于保守
必须在坚持比特币核心价值定位的前提下谈升级
扩展性只是其中一个升级的关注方面
需要一个更好的时机，好的升级提案会快速获得共识
社区需要探索更好的治理机制

致谢

协同编辑和审稿（字母排序）：Adrien Lacombe、Bob Bodily、Bitlayer Research Team、Domo、Jeffrey Hu、Red、Ren Zhang、Scott Odell、Super Testnet、Will Foxley

提供了反馈和帮助（字母排序）：Ajian、Andrew Fenton、Ben77、David Tse、Eli Ben-Sasson、Mi Zeng

参考文献

https://bitcoinops.org/

https://opnext.dev/

https://groups.google.com/g/bitcoindev

https://github.com/TABConf/6.tabconf.com

https://petertodd.org/2024/covenant-dependent-layer-2-review

https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/

https://blog.bitmex.com/bitcoins-consensus-forks/

https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki

https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

https://bitnodes.io/nodes/

https://github.com/bitcoin/bitcoin/pulse/monthly

https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

https://trustmachines.co/learn/bitcoin-taproot-upgrade-basic-breakdown/

https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

https://github.com/bitcoin-cap/bcap

https://newsletter.blockspacemedia.com/p/four-takeaways-from-op-next

https://blog.bitfinex.com/education/is-ossification-good-or-bad-for-bitcoin/

https://arxiv.org/abs/2305.04079

https://www.allocin.it/uploads/placeholder-bitcoin.pdf

https://eprint.iacr.org/2024/1802

https://en.bitcoin.it/wiki/Covenants_support