比特币区块容量悬崖

本文将讨论通不通过扩大区块容量的方式提高比特币网络处理交易能力的一些提议，特别是Lightning网络（Lightning network）提议。但是这些讨论都是通用的，也适用于其它提议。

首先，介绍一下背景。

多年以前，中本聪对比特币源代码做了一项突然的修改。他人为地限制了比特币处理交易的能力，以此避免流氓矿工的恶意行为对人们造成不良影响（即区块过大问题），要知道在那时候使用比特币意味着需要使用缓慢和未被优化的客户端下载整个区块链。

这一区块容量限制（即每个区块容量上限是1MB）本应该被消除的。事实上，当SPV钱包（即普通用户不再需要下载区块链即可使用比特币）开发完成后，中本聪本人打算解除这个限制。

我知道中本聪的想法，因为在2010年末，我给他发送了邮件，询问此事。下面是他的回复：

一旦比特币的交易数量接近区块容量限制，一个更大的区块容量限制应该被制定，确保网络交易处理顺利进行。

最终当我们有了纯钱包（client-only implementation）时，区块链的大小就将不再重要了。在那一阶段以前，因为所有的用户仍然需要下载整个区块链才能使用比特币，所以如果我们能将区块的容量限制在一个合理的水平，这是一个很好的事情。

他所说的纯钱包（client-only）就是为安卓开发的比特币钱包、MultiBit、BreadWallet等。那时候还没有SPV（Simplified Payment Verification，简单支付验证）钱包这一术语，这是我在开发第一个此类钱包时提出的术语。

根据中本聪的最初想法，区块容量限制在几年以前就应该提高。但是，我们却一直将这项工作拖到了最后。根据我的粗略计算，比特币的交易数量在冬天会增长，在夏天停滞。如果按照目前的趋势进行下去，在2016年冬季初，比特币的交易处理能力将达到上限，这一天也很可能提前数月到来。因为升级需要花费时间，所以我们需要现在就为提高区块容量上限做准备。因此，加文·安德森发起了这一讨论。

一些人相信我们可以通过其它方式增加比特币的交易处理能力，避免改变现有的容量上限。这些人不是实干者（implementor）。我认为其它的方式是不可行的，在本文我将解释它们为什么不可行。

最后，向那些不了解我的人介绍下我的背景。在过去的五年，我一直在开发比特币钱包，在这之前，我在谷歌工作近八年。其中三年时间在谷歌的地理团队（Geo Team），那时候我是世界上最繁忙网络的一名专业性能规划者（capacity planner）。就像现在一样，性能规划需要提前很久就开始做。在谷歌世界，因为我们需要制造实体的设备和建造数据中心。在比特币世界，因为升级需要花费用户的时间。所以，我对目前的困境并不陌生。

Lightning网络

什么事Lightning网络？它是一个老理念的最新名字：为了传输支付信息，在不同的低信任度的中介之间使用的支付通道。实际上，它是一个运行在区块链之上的清算网络。

这一技术的首要用途是微支付。但是，可以在客户端/服务器和服务器/服务器之间建立支付通道网络，使得双方之间可以进行快速、低信任的支付。

这样的一个清算网络应该比大多数清算网络要好，因为运行在区块链上的要求将保持中介的诚实。理论上，与比特币自身相比，它可以处理更多的交易，因为区块链只看到聚合的支付。

它是一个有吸引力的理念，吸引了许多人的注意力，一家来自瑞典、被称为StrawPay的创业公司正在开发它。

StrawPay设计了一个被称为Stroem的协议。它定义了钱包、交易中心（hub）和商家如何交互，并在他们之间设置了支付通道。他们也开发了一个跨平台的图形界面钱包。

Stroem协议并不与Lightning完全一样，在一些技术细节上有不同之处。Stroem与现有的比特币协议一起工作，它详细说明了Lightning白皮书忽略的所有细节。

我欣赏StrawPay的开发者们，祝他们顺利。我认为Stroem有潜力使得微支付通道更加快捷和简单。它很可能会在比特币生态系统中找到自己的位置。但是，使用它并不是必须的。

利用这种方法扩展比特币的处理能力并不是一个很好选择的原因有好几个。

第一个原因是，实施它所带来复杂性将危害到比特币的去中心化特性。

复杂杀死猫

人们关注仍未解决的问题，忽视运行良好的事情，这是很正常的。所以比特币社区成员倾向于担忧挖矿、交易所和支付处理的中心化问题。我们没有思考已经取得的成功，钱包市场取得了去中心化的巨大成功。

现在，可能存在数百种不同的比特币钱包，利用了几十种不同的底层算法。没有一种具有明显的优势。他们都在为争取用户而竞争。这一点非常重要：如果用户只使用一种或者两种钱包，那么这些钱包就将成为比特币系统的守门人，可以随意改变比特币的规则。区块链将无关紧要，因为人们通过他们的钱包体验区块链。

开发一种比特币钱包并不容易。我知道这一点，因为我在过去的五年内，一直在开发bitcoinj（一种可重复使用的“钱包引擎”，多个比特币应用和服务的核心使用它）。但是，没有大型开发团队的个人仍然可能利用业余时间开发出新的钱包。比特币钱包与HTML5不同，HTML5只能由大公司进行开发。比特币协议并不像看起来的那样简单，但是也不是令人难以接受的复杂。比特币协议的简单性是多种钱包并存的关键。

不幸的是，支付通道并不简单。特别是，一旦你引入Lightning提出的更加先进的特性，代码将更加复杂和庞大。有少数开发者创建了玩具版的支付通道，但是只有bitcoinj才是真正可用的产品。玩具版的支付通道没有考虑许多事情，例如文档、单元测试、用户界面整合、错误管理等等。玩具和真正产品的区别是：是否被用于为非技术人员开发的应用之中。

Bitcoinj中的支付通道被用于制作PayFile（让你可以对下载的文件按KB支付费用）和用于StrawPay中。StrayPay的底层是完全建立在bitcoinj之上的，它们的图形用户界面是利用了MultiBit HD钱包的界面。所以，我们知道StrawPay的代码可以运行。这意味着我们也知道开发它需要多少精力。幸运的是，大多数开发工作有公司资金的支持。

你可能会认为我会对明年夏季初每个人都将被迫实施支付通道的想法感到高兴。许多开发者可能得出结论：他们自己的代码将很快被bitcoinj/StrawPay取代，我将获得更多的用户。但是我并希望人们马上被迫使用我的代码。更多人的使用bitcoinj，也会给我带来开发支持难题，我不希望它有损于去中心化，即使分叉bitcoinj非常容易。开发者将怨恨被“要求”使用我的软件，这也不是我所希望的。

所以，如果我们使得开发钱包更加困难，那么钱包的数量将会大幅减少。StrawPay的开发者说：

我们有一个用Java写的库，钱包可以使用它，目前正在开发中。还没有对iOS钱包的支持。

即使拥有库，钱包开发者仍有许多图形用户界面工作和其它工作需要做。

最终，钱包市场可能只剩下几个钱包引擎，就像游戏行业的做法。但是，我们不需要加速这一不必要的趋势。它是不必要的，因为它在解决一个不存在的问题：比特币的核心技术可以扩展性能，不需要任何外部的帮助。

问题举例

引自Lightning白皮书：

如果一个人没有在正确的时间广播一笔交易，对方（counterparty）可能盗窃资金。这一问题可以通过设置一个指定的第三方发送资金的方法解决。一笔输出费用可以被加到交易中，以此激励第三方观察网络。

这类问题似乎太学术化，但是“没有在正确的时间广播”可能是其它问题引起的，例如你的手机没电了，或者进入信号较弱的地方。这个问题可以通过增加一个半可信（semi-trusted）的第三方解决…，但是这再次增加了复杂性。

对于一些特殊情况，例如极为快速的微账单，没有其它的解决方案，我们只能忍受它带来的复杂性。对于我们能够避免它的情况，我们应该不使用它。

另一种问题：

当一方丢失数据时，对方有可能盗窃资金。

另一个问题：

可能有办法解决发送者和接收者被攻击的威胁，中介节点必须在线，并自动处理交易。出于这个原因，中介节点将面临风险，不应该在“热钱包”中存放大量比特币。

在长期中，具有更好安全性的中介节点将能够胜出，能够处理更多的交易量，因为它的费用更低。传统金融费用的最主要的一部分来自于各种形式的对手风险–比特币金融费用的最主要部分将来自与安全风险溢价。

轮辐模式支付通道网络（hub and spoke payment channel networks)需要拥有签名钥匙的服务器一直在线运行。这显著不同于平常的比特币使用，即只有发送者需要签名，进行线下签名是可能的，而且也是司空见惯的事情。StrawPay/Lightning增加了复杂性，从而增加成本。

比特币节点比交易中心更加简单

人们对扩展比特币性能的抱怨之一是，它将使得运行一个完全节点更加困难。这些抱怨者认为支付通道是一种解决方案，却忽略了它只是通过将需要做的工作转移到到不同种节点（更加难以设置和运行的节点）上使得运行一个全节点变得更加简单。

主要原因是支付通道网络中的交易中心是有状态的（stateful），所以你不得不确保它们非常可靠并一直在线运行。与此相反，比特币节点几乎是无状态的（stateless），所有连接P2P网络的软件都知道如何从一个节点恢复。这样的事情一直发生，对用户也是透明的。

这使得运行一个全节点非常容易和安全：如果你用10美元购买的VPS出问题了，没人会注意到或者抱怨。如果它丢失了大量数据，你只需重新安装节点，它将重新计算所有的数据。如果它被攻击了，没有东西可以被偷窃。支付通道 和节点的这些特性完全不同。

性能风险高

StrawPay没有使用普通人直觉想象到的设计，即通道将发送者和处理中心（hub），处理中心和处理中心，处理中心和接收者连接起来。相反，处理中心向接收者发行本票（promissary notes）。设计者如此说：

我一直在等待这个问题。这可能是我们遇到的最长的讨论。原因如下：

1）安全：保持支付通道服务器一直运行是一件复杂的事情。它必须安全。大多数商家对此了解很少，钱包可能被黑。我们设计的本票不能被除了此商家意外的人使用，所以盗窃本票是没有意义的。

2）性能：我们担心，在一个交易中心的网络中，从交易中心到交易中心的微支付过程不够迅速。最好告诉商家消费者已经尽可能快地付款了，并让商家持有本票。

非常困难的选择。

我们已经解释过安全问题了，所以关于安全的问题并不令人意外。但是你可能对它的性能不够好感到意外。不必意外，因为支付通道协议包括许多往返消息，签名创建/确认。单个步骤并不慢：以毫秒计。但是如果每个步骤耗时200毫秒，你需要经过十个步骤，那么支付也就变得有点迟钝了。

在比特币网络中广播一笔比特币交易所不会比StrawPay更快，但是它还有大量优化空间。一笔交易可以在本地极为迅速地被确认，只受传播延迟的影响。经过轮辐模式网络的支付与此不同。StrawPay的支付速度比不上现有的支付系统。

可能是StrawPay的开发者过于保守了－－问题在于，还没有人知道，因为没人尝试建立和部署这样的一个网络。因此，许多重要的问题还有待回答。

时间不多了

让我们忽略以上所有的提议，假定支付通道网络是最好的东西。但是，它再好也没用了，因为最迟在明年年中，我们需要一个解决方案，但是上面提到的网络到时候还不存在。

我们没有时间了。在未来的12个月中，除了提高区块容量上限以外（这是目前每个人都理解的方式），没有其它的技术方法可以被广泛应用。

我喜欢Stroem／Lightning微支付快速通道的理念。我喜欢发送者／接收者之间微账单（micro-billing）支付通道的理念。我们可能有一天会使用支持这些系统钱包。但是，这些解决方案对我们目前面临的困难是没有用的。

一些人似乎认为，如果我们到达了比特币交易处理能力的上限，交易费用将会平稳上升，自由市场将会解决这个问题。这是不正确的。在下一篇文章中，我将会写如果我们不及时解决这个问题，实际上将会发生什么。