在2018年11月的BCH 分叉中，Bitcoin SV 阵营希望将区块大小在现有的基础上继续增加，增加到 128MB 大小。而 Bitcoin ABC 阵营认为 32MB 大小已经足够。和比特币最初的 1MB 大小相比，一年多来分叉链对区块大小的调整就像是一场大跃进一样。这么做真的没问题吗？我们从学术研究的结论中为您寻找答案。
区块扩容的历史
我们都知道，在比特币创世时，采用了1MB 区块大小的限制。在最初的几年，比特币受到的关注有限， 1MB 大小被填满的次数也不多，大家似乎没有觉得 1MB 有很大问题。
随着比特币受到的关注越来越多，比特币的吞吐率局限性日益凸显。按平均一笔交易250 字节计算，比特币每秒只能处理不到 7 笔交易。
为了缓解效率问题，隔离见证，2M 区块大小的等方案被提出。2017年8月，BCH 从比特币分叉，并且将区块定到了 8MB 大小，今年 5 月将区块大小调整到 32MB。在本次分叉中，Bitcoin SV 更是提出了 128MB 的巨大区块。
区块大小对安全性的影响
早在2015年的时候，学术界就对区块大小和出块时间对安全性的影响进行了研究。其结论简单来说，在最长链规则下，区块大小和出块速度的对安全性的影响可以用一个比值概括：
区块传遍全网时间/ 出块间隔时间
这个比值会影响双花攻击需要的算力。比值越大，进行双花攻击需要的算力越小，安全性越低。
（注：如果诚实的矿工们算力相对集中，也会提高安全性。区块传遍全网的时间可以把长尾切掉，比如说，传遍95%的算力节点视为传遍全网。）
比特币对提高传播速度的不懈努力
和十年前的网络环境相比，如今的网速大大提高。发送同样大小的数据需要的时间更少。不仅如此，在2016年的时候，比特币还通过实现紧凑区块(Compact Block)来降低传输时间。
与保留全部交易信息的完整区块不同，紧凑区块中只保留交易的短ID（仅6个字节）。当一个节点挖出区块时，只在网络中传播紧凑区块。收到紧凑区块的节点先尝试从自己的交易池中恢复完整区块，当恢复失败时，再尝试向邻居节点请求冲突或丢失的交易。
对于1MB 大小的完整区块，紧凑区块仅有 15KB 的大小。据报道，直接恢复完整区块的成功率高达 86%. 这大大降低了比特币区块传遍全网的时间。统计数据显示，2016 年 12 月的区块传播时间只有 1 月的不到六分之一。
那么，调大区块到底安全吗？
和比特币运行初期相比，如今区块传遍全网时间已经大大降低。就安全性而言，1M 的区块大小已经非常地保守了。即使将区块大小增加到 8MB , 也可以获得近似于 3 到 5 年前比特币的安全性。
然而，对于32MB 这样大的区块，其安全性就需要谨慎考量了。虽然使用紧凑区块技术依然可以做到大约 500KB 大小的实际传输量。但当网络中的交易越来越多的时候，可能有大量交易堵在路上，导致完整区块的恢复成功率大大降低，最终导致传输时间过长。
而128MB 区块大小就近乎疯狂了，更可怕的是，这个方案的拥护者们似乎完全没有考虑过上述问题。笔者粗略估计，除非算力集中，否则 128MB 区块可能面临严重的安全性问题。但如果算力真的集中起来，它和一个中心化系统的区别又有多少呢？
概括来说，适当地调大区块可以缓解吞吐率问题，但是无底线地调大区块，势必会造成严重的安全性问题。
最重链规则：降维打击式解决安全与效率两难问题
上面所述的问题，只局限在最长链规则之下，所以我们可以从另一个维度去考虑。GHOST 共识协议设计了最重链规则，无论区块大小和出块速度怎么调整，双花攻击都需要 50% 的算力。
Conflux 基于 GHOST 协议改进和实现，通过有向无环图结构，在保证安全性的前提下，在跨大洲模拟实验中实现了每秒 1.6MB 数据的吞吐，相当于 6400 笔交易。这一表现为打造高效率的 PoW 公链提供了坚实的共识基础。
参考文献：
[1] Sompolinsky, Yonatan, and Aviv Zohar. "Secure high-rate transaction processing in bitcoin." International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2015.
[2] Li, Chenxing, et al. "Scaling Nakamoto Consensus to Thousands of Transactions per Second." arXiv preprint arXiv:1805.03870 (2018).
作者：李辰星(lylcx2007@gmail.com), 公链项目 Conflux 研究成员
本文允许非商业目的规范转载，请注明作者及出处。
