我是马克周，一个对数字加密货币和区块链深感兴趣的撰稿人；热衷编程学习和币价技术分析。
你可以在这里找到我
LinkedIn:www.linkedin.com/in/mark-zhou-ab01b637
TradingView:www.tradingview.com/u/xiucat
最近几个月，“比特币区块扩容”成为比特币世界最棘手的问题。中本聪在2009年设计比特币系统时，将每个区块的大小上限设定在 1MB 。随着比特币网络交易量的大量增加，越来越多被搁置的转账出现，比特币交易确认的速率也越来越低。按照比特币网络的设计，平均每十分钟有一个区块被挖出来——区块被挖出来，就等同于这个区块内所有的转账都被确认了。因此，区块的大小成为瓶颈，直接决定了每十分钟被确认的转账数量——区块大小“掐”着交易确认量的脖子死死不放手。
从用户角度来说，区块扩容是一个好事，因为它可以加快转账速度，而且由于转账变快了，每笔转账所需的手续费也能相应降低。之所以在比特币网络中转账费用有高有低，原因很简单，那就是因为比特币网络是作为一个金融系统被设计出来的；转账交易费用已经形成了一个内在的市场 (Fee Market)。转账费用越高，比特币网络就会把它设置得更优先，通过安装了比特币软件的计算机 (网络节点，Notes) 向整个比特币网络传播的时候，费用较高的转账，会更容易被传播出去。因此这些转账组成区块，被矿工挖出来的几率也更高。但是从另一个角度来看，如果区块扩容，转账变快了，用户提高转账速度的需求就没有那么迫切了——因为已经通过扩容的方式提速了。因此，用户就会倾向少付转账费用。
这便是为什么，区块扩容对于使用比特币交易的用户来说是个好事情。
对于矿工而言，则略显复杂。随着比特币越挖越少，用户转账费在矿工的收入中所占的比例会越来越高。所以笼统的说，转账费降低，对于矿工不是好事情。然而，扩容本身意味着单个区块能够容纳的转账变多了。尽管单笔转账费用下降，但转账总量上来了，矿工所能获得的转账费用总额仍是上涨的。
那么是否可以说，区块扩容对矿工就是好事呢？不尽然。原因在于，挖更高容量的区块，对于矿工的成本要求也相应提高。矿工可能需要升级设备、增加维护次数，以及升级挖矿技术，来应对更高容量的区块。虽然转账费用相应提升，但如果不能抹掉由此带来的成本上升，区块扩容对于矿工仍然是一场灾难。
所以对于最近几年的众多区块扩容方案而言，不同群体有不同的态度。几年前，有比特币核心开发团队的成员建议，将比特币区块大小的上限提高到 20MB 。Bitcoinwiki 网站上就此方案统计了不同矿池公司、比特币钱包APP公司和专业开发者的立场。其中，服务于用户的公司往往赞同扩容方案，理由前面也提到过，因为扩容对用户是好事。开发者从维护比特币网络生态的角度，认为扩容是迟早的事，毕竟比特币网络是一个金融系统，交易久久不能确认，谁还会用？
矿工就比较纠结了，大矿池公司赞同扩容方案，小矿池和个体矿工则对于扩容到 20MB 非常谨慎甚至抵触。理由很简单，扩容到这种程度，对于矿工设备的要求较高，从而导致成本激增，利润骤减。大公司由于拥有较大的体量和较多可周转资金，可以在一定时期内抗住成本上升的压力，因而能够在中长期阶段享受扩容的好处；小矿池和个体矿工显然就抗不住了。
争论了一段时间，扩容的方案提了又提，人们逐渐意识到一件事情，区块扩容是一定要扩的，但不能太冒进。这也是为什么，目前比特币网络能够承受扩容到 2MB 的 Segwit 方案。
说了这么多，为什么中本聪最初会将区块上限设定在 1MB 呢？
这样设计有几个原因。第一，是为了方便比特币流通。一种金融“货币”，有人用才有意义。为了能让更多人加入到比特币网络，加速比特币的传播；考虑到2009年互联网的普遍带宽，中本聪刻意将区块大小压缩到 1MB 以下，以便在网络传输过程中，区块不会占据过多流量，从而提高传播效率。
第二点，是防范包括 DoS 攻击在内的恶意攻击。区块链作为去中心化的系统，是没有统一的防火墙设计的。由于比特币网络的信任机制本身就是“无需信任 (Trustlessness)”，因此这个网络中必然充斥着多种多样的黑客攻击行为。其中一个最常见的网络攻击，便是 DoS 攻击 (Denial of Service，即恶意发送超过承受能力的大量数据给特定网络节点，令这个节点崩溃当机，从而达到攻击目的)。将比特币区块设置在 1MB 以下，是一个预防 DoS 攻击的有效手段。限制区块大小也就限制了每一次可发送的数据量大小，从而降低了被攻击成功的可能性。
一言以蔽之，对于用户、矿工和比特币网络开发者，提高单个区块的大小都是必将经历的过程。
- [ THE END ] -
你可以在这里找到我
LinkedIn:www.linkedin.com/in/mark-zhou-ab01b637
TradingView:www.tradingview.com/u/xiucat
