我是马克周，一个对数字加密货币和区块链深感兴趣的撰稿人；热衷编程学习和币价技术分析。
你可以在这里找到我
LinkedIn: www.linkedin.com/in/mark-zhou-ab01b637
TradingView: www.tradingview.com/u/xiucat
随着前天 (11月8日) Segwit2x 硬分叉紧急告停，比特币世界备受争议的区块扩容计划暂时告一段落。不过，如同我在前面 文章 里提到的，很多人觉得这个方案风险较大——有漏洞，扩容大小也有点激进——总之一句话，现在还不是时候。
其实对于大部分矿工、完整节点、开发者、投资者、区块链和比特币相关创业公司，之所以反对 Segwit2x，并不是因为扩容。事实上，恰恰是因为有扩容的需求，才有最初的分隔见证 (即 Segwit，没有 2x 后缀哦)，以及随之而来的 2x。大家在今年八月初的时候没觉得这个方案有什么问题。
人们反对的是，一下子扩太猛，可能会把自己搞死。扩不扩容不是一个值得讨论的问题了，扩是一定的。在过去几个月到几年的时间里，比特币交易量越来越大，未确认的交易 (也就是用户花了比特币，但尚未被足够数量的区块确认，所以还没到账的交易) 也越来越多 (写作本文的时候，比特币网络有超过5万未确认交易)。
现在每个区块最大不超过 2MB，所以单个区块能容纳的交易数量是有上限的，填满了 2MB ，你的交易就得移步下一个区块了。再加上比特币网络平均每十分钟才会挖出一枚区块；因此我们可以说，在目前的算力水平和区块大小限制下，比特币交易的平均确认速度是很难提高的。与此同时，比特币交易量在不断增长。这就导致一个必然结果：比特币的确认越来越慢，交易效率越来越低。
总而言之四个字，“早晚得扩”。现在最关键的是要解决这两个问题——怎么扩？什么时候扩？
Segwit2x 之所以不得人心，主要就是上面的两个问题没有解决好。不低于 2MB 的硬分叉计划略显偏激，今年底就开始执行也比较仓促。实际上，如果能在这两个问题上找到平衡点，扩容方案可能就会更容易被接受。
除了 Segwit2x 之外，我还看到过一些有趣的提议。
印象最深的，是在比特币核心开发团队 (Bitcoin Core) 的公开邮件系统中看到的。一位 Bitcoin Core 开发者建议，直接将比特币的目标区块大小设定为 32MB。乍一听，这比 Segwit2x 还不可理喻，32MB？疯了吧？不过，要达到这个目标需要分几个阶段，只要分段进行，这个方案其实很柔和。
32MB 的区块大小只是未来的目标。这位开发者建议，将这个目标的完成时间设定在两年之后的 2020 年。也就是说，在接下来的比特币网络共识规则中，只加上一句 “两年后的目标区块是 32MB”，而不是直接设计代码来实现这个结果。这个做法有两点好处——
第一，仅仅把该目标写入比特币网络的共识机制内，不会产生任何分叉；
第二，未来如果有人想扩容区块，只要不超过32MB，都是软分叉。
第一点能成立，是因为这个方案只建议设定一个未来目标，而不是实质性的扩容操作，所有新的区块大小仍然保持在现有的准许范围内，因此不会产生分叉；至于第二点，因为大家早已同意了区块最终会到达 32MB，所以不管你要扩到 4MB、8MB 还是 16MB，只要没有突破最终的目标，就只是让之前不合法的区块变得合法了——从这个定义上来讲，扩到 4MB、8MB、16MB 都是软分叉。相比硬分叉的不确定性和攻击性，这显然是更为安全的方案。
听上去，这是一个蛮有趣的方案。不过它也有值得商榷的地方：最明显的，就是 “两年后达到 32MB” 这个人为设定的期限。很快有不少人回复评论了这个方案，其中表达最多的反对意见是：你这个设计有点中心化，我不爽。
什么意思？如果说两年 (或者某个时间期限) 之后，比特币区块一定要扩充到 32MB，这就意味着每个人都要同意这个共同的结果。我们达到这个结果的方式未必相同；但不论你 “长征路” 怎么走，最后必须得走到延安。这就相当于给所有人规定了目标和方向，也就是所谓的中心化设计。
中心化设计有很多好处，比如能够快速有效地调动生产力投入到社会生产活动当中。但在标榜 “去中心化” 的比特币世界里，人们对于中心化设计还是比较敏感和警惕的 (虽然常常不能避免……)。因此，开发者对这一条 “两年后达到 32MB” 的最终目标颇为敏感，甚至不屑。
争议归争议，这个 32MB 方案仍然是我听过的最有趣的比特币扩容点子。假如人们可以去掉时间限制，只保留 “最终达到 32MB” 这一点，它或许会更具有吸引力。
- [ THE END ] -
你可以在这里找到我
LinkedIn: www.linkedin.com/in/mark-zhou-ab01b637
TradingView: www.tradingview.com/u/xiucat
上一篇
