比特币的扩展性解决方案反映了其在保持去中心化和安全性的同时提升性能的不断发展方法。

撰文：Chakra Research

比特币是世界上最早出现、最安全、最去中心化、最高价值的区块链。然而，比特币的 TPS 过低与编程能力不足也时常为人所诟病，难以支撑大规模应用，在很大程度上阻碍了比特币生态的发展。作为比特币生态的建设者，Chakra 将带领大家了解比特币扩容方案的过去、现在与未来。

本文为 Bitcoin Scalability 系列的第一篇，主要介绍历史上比特币主网上的原生扩容方案。

增加区块大小上限

2010 年，中本聪在 bitcoin-core 中引入了 1MB 的区块大小限制。十余年后，这个显式限制仍未被修改。

有趣的是，中本聪实际并未公开说明为何提出区块大小限制，该限制也被「隐藏」在代码合并的 PR 中，未得到详细说明。在中本聪离开的几年后，社区对区块大小限制产生了严重分歧，对大区块的需求引发了广泛讨论。

更大的区块，意味着能够容纳更多的交易。在共识时间不变的前提下，更大的区块就意味着更高的 TPS。

为什么 TPS 如此重要？因为按照 1MB 的区块限制，按照当时的交易大小，每秒能容纳的交易数仅为 3-7，这很难满足大规模应用的需求，无法实现比特币「点对点的电子交易系统」的愿景。

但同时，大区块也会带来不同程度的问题。

首先，大区块从存储、计算、带宽等方面提出了更高的硬件要求，导致全节点的运营成本提高。比特币的历史将迅速膨胀，这使得新加入网络的全节点需要更长的时间完成同步。种种要求都导致用户运营全节点的意愿降低，这将导致去中心化程度的降低。

其次，大区块增加了节点间同步时间，提高了孤块产生概率，将会带来更多的区块重组问题，分叉风险增加，显著降低了安全性。

后来，该问题被 Vitalik 描述为区块链的不可能三角，即区块链不能同时满足去中心化、可拓展性与安全性。更大的区块提升了 Scalability，但同时减弱了 Decentralization 与 Security。

最重要的是，对区块大小限制的修改需要通过硬分叉来实行，但硬分叉需要全网的节点在同一时间完成升级，否则会导致网络的分裂，这对于依赖于去中心化共识的比特币而言并非一个好选项。在中本聪的影响下，不能硬分叉似乎已经成为了比特币的 de facto 原则。

不幸的是，分裂确实发生了。尽管社区没有达成共识，部分矿工与开发者还是在客户端中改变了区块大小限制，最终导致了网络的分裂。 Bitcoin Classic 于 2016 年采用 BIP 109 将区块大小限制分叉至 2MB；Bitcoin XT 客户端 于 2016 年采用 BIP 101，将区块大小提升至 8MB。但绝大多数矿工与用户留在了我们现在所知道的 Bitcoin Mainnet 上。

通过硬分叉显式提升区块大小的努力，失败了。

SegWit

不接受硬分叉，能否通过软分叉实现呢？SegWit 就是这样的一个方案。

Witness 是解锁 UTXO 的一种凭证，长时间内，见证被放置在 UTXO 的 input signature_script 字段来完成交易。然而，这种做法会导致潜在的循环依赖、第三方交易篡改、第二方交易篡改等问题。

早在 2011 年，开发者就注意到了该问题，提出了 Segregated Witness (SegWit) 的解决方案，将见证与交易的其他数据分离，但当时的硬分叉方案并未获得支持，直到 2015 年 SegWit 软分叉的方案提出，才使得最终合并的完成。

SegWit 如何实现软分叉的向后兼容？向后兼容主要包括以下两点：

1. 新版本节点能够识别和接受旧版本节点产生的区块和交易。
2. 旧版本节点虽然无法识别新版本引入的新规则和功能，但仍将新版本产生的区块视为有效。

SegWit 软分叉让新版交易使用空的输入脚本，并在区块结构中新增了 Witness Structure，用于存储 Witness。由于升级前 Bitcoin core 中支持空的输入脚本，所以旧版本节点不会拒绝新版本产生的区块。同时，通过 version 字段进行区分，旧版本交易类型仍然能够使用，节点在处理时会根据 version 进行不同的处理。

SegWit 中的扩容是通过权重的形式实现的，对 Witness 字节权重为 1，对其他数据字节权重为 4，限制每个块最高的权重和为 400 万。为何对不同类型的数据给予不同的权重？一个比较符合直觉的想法是，witness 数据仅在被使用时发挥验证作用，不需要长期保留在存储中，因此开销相对较小，所以赋予一个较低的权重。

这实际上变相提升了区块的大小限制，块大小理论大小限制提升至 4MB（全为 Witness），平均来看块可以达到 2MB 的水平。从旧版本的区块结构来看，也遵守了中本聪所设置的区块大小不高于 1MB 的限制。

Taproot

利用比特币中的 OP_IF 等 opcode，我们可以为比特币的支出脚本设置复杂的条件，例如时间锁、多重签名等。然而，复杂的支出条件往往需要多个输入和签名进行验证，增加区块负载，降低交易速度，同时暴露了所有支付条件的信息，泄露隐私。

Taproot 使用 MAST 来扩展比特币，用户将支出条件用 Merkle Trie 表示，每个叶子节点代表一个支出脚本，在支出时只需要提供自己实际执行的脚本与对应的 Merkle Path，而无需透露其他条件，这使得交易所消耗的区块空间更小。并且改善了隐私性。

Taproot 升级中还引入了 Schnorr 签名，具备加法同态特性，能够聚合签名，支持批量验证，提高了整体 TPS 水平。Schnorr 签名支持聚合签名的优势使得验证多签的逻辑大大简化了，原先 ECDSA 签名中的多签需要通过将多个签名发送到链上与脚本进行匹配，而 Schnorr 签名只需将链下聚合后的单个签名发送上链即可，降低了多签支付对链上空间的使用。

结合 Schnorr 签名与 MAST，利用 Pay to Contract (P2C) 的思想，通过承诺 MAST root 来承诺复杂的合约代码，调整后得到一个普通的比特币公钥，能够根据支持单个 Schnorr 签名支付。

更有趣的是，由于 Schnorr 签名中单个签名与多重在链上的表现是相同的，复杂的脚本、多签、单签的逻辑在链上都无法区分了，隐私性进一步提升。

总结

比特币的扩展性解决方案反映了其在保持去中心化和安全性的同时提升性能的不断发展方法。

最初，曾考虑增加区块大小，这直接解决了低交易速率的问题，但也引发了与节点成本和网络分叉有关的问题，挑战了社区共识。隔离见证（SegWit）的引入标志着一个重要的进步，通过软分叉优化了区块容量，确保了向后兼容性，避免了分裂性的硬分叉。随后，Taproot 通过 MAST 和 Schnorr 签名进一步优化了扩展性和隐私性，减少了交易空间并提高了验证效率。

Chakra 所取得的一切成就都是建立在这些原生扩展性解决方案之上的。

然而，这些扩展性解决方案的影响尚不足以实现「点对点电子现金系统」的愿景。在我们的比特币扩容系列下一篇中，我们将讨论具有更高扩展性的链下扩展解决方案，敬请期待。