比特币交易容量难题——为什么我们不能用花哨的技巧来避免它

本文分析了一些提高比特币网络交易容量的替代方案，尤其是闪电网络。但所提出的论点具有普遍性，也适用于其他提出的替代方案。

（作者：Mike Hearn）

首先，先讲一些背景。

很多年前，中本聪在比特币的源代码上增加一个限制。他人为地限制了比特币的交易容量，以防止有矿工恶意搞破坏制造客户下载整个比特币区块链时会非常慢。

该限制本来是有计划删除的。事实上，只要开发出SPV钱包，中本聪就计划删除它。

我知道这一点是因为我在2010年底给他发邮件问了。他是这样回应的：

可以分阶段实行更高的区块限制，一旦我们有接近该限制的实际使用量，确保它凑效。

最终，当我们有了纯客户用钱包（client-only）时，区块的大小限制就无关紧要了。在此之前，因为所有的用户仍然需要下载整个块链来使用比特币，我们还是保持其合理大小为好。

我们讨论的纯客户用钱包（client-only），是如安卓端钱包、 MultiBit、BreadWallet等，当时还没有可供使用的SPV的钱包—-这个短语是我首次使用的。（译者注：作者指SPV钱包这个命名是他先发明的。）

根据中本聪的初始意思，区块大小的限制本应该在几年前就增加。但是我们却把它留到了最后一刻。据我粗略计算，比特币使用量会在冬季增长和夏季停滞。如果目前的趋势继续下去，比特币的容量应该在2016冬初用完，而且很可能在几个月前。因为升级需要时间，现在我们需要为此做好准备。因此，加文提出补丁，并且开始讨论。

有些人倾向于相信我们可以避免更改此限制，依靠另一种方式按比例增加比特币。这些人是典型的不现实者。我认为它不会凑效，我将在这篇文章中解释它为什么不行。

最后，给那些不了解我的人简单说明下我自己的背景。我过去五年是在为实施比特币钱包工作，而在此之前，我在谷歌工作了近8年。其中三年我在地理小组 （地图/地球），它是世界上最繁忙的网站之一，在那里我是一个专业的容量规划师。就像现在一样，做容量规划需要很长时间。在谷歌的世界里，这是因为我们必 须在物理上制造机器和物理上建立数据中心。在比特币的世界里，这是因为人们需要时间进行升级。因此，对于我们目前的困境，我很有经验。

闪电网络

什么是闪电网络？它是一个旧想法的最新名称：使用支付渠道在各种低信任度的中介之间发送付款。支付通道本质上是建立在 区块链技术基础上的一些比特币（译者注：此处的“一些比特币”译的可能不准确，原文是“apot of bitcoins”，直译是“一壶比特币”），它可以在比特币区块链网络外传递消息。但最终的结算还是要落定在比特币链上。有多种比特币协议特征可用来实 现这种低信任度的方式支付。

这种技术首要和主要用途是小额支付：支付信息传播可以比在比特币链上传递更快更廉价，因为这种支付只是发生在两个人之间。早期观察到这是可以在客户 /服务器和服务器/服务器之间建立低信任度快速支付。有效地，一个结算网络会运行在这个区块链（译者注：指闪电网络之类）之上，并且随时可实现种结算层结 算。

这样的结算网络应该其他网络更好，因为只有这样才能保证这个区块链（译者注：指闪电网络之类）上的支付是诚实的。理论上，它可以比比特币本身处理更多的交易，因为比特币区块链上只需要看到总的汇款金额。

这是一个整洁而有吸引力的想法。如此的吸引力，尽管搞闪电网络的那些家伙正在得到所有人的关注，他们的想法早已经被名为StrawPay的瑞典公司实施。

StrawPay设计了一种称为Stroem协议（实际上 STRöM 但是很多人不知道如何输入和发音）。它定义了钱包，枢纽中心（hubs）和交易商，以及设定好了他们之间的支付通道。他们还实施了实际上可以做到跨平台使用的图形用户界面钱包，以让用户确实可操作。

Stroem协议与闪电网络不一样的是-他们在一些技术细节上有区别，值得注意的是，Stroem根据今天的比特币协议工作，并接受了闪电网络没有 接受的警告。Stroem指定了所有其他闪电网络协议忽略的细节，例如如何真正以向后兼容的方式进行这样的支付（比特币地址不能用在这些方案中）。

我喜欢StrawPay的家伙，我希望他们都好。我认为Stroem很有潜力让小额支付路由更快更容易。它很有可能会在比特币生态系统中找到一席之地。但是不应强制性使用它。

使用这种方法来达到扩容的效果不好，这存在几个原因。

第一，实现的复杂度会伤害去中心化。

复杂性会淘汰菜鸟

人的本性是注意到问题而忽略事情进展顺利的方面，-毕竟值得称赞之处只有这么多。所以比特币使用者倾向于强调挖矿，交易，支付处理等。我们很少花时间来反思我们的成功，而钱包市场是去中心化的巨大成功。

目前为止可能有数百种不同的钱包支付方式，使用几十钟不同的实现支付的基本算法。没有一种钱包支付方式是明显占主导地位的。他们在一个充满活力的市 场中争夺用户。这一点非常重要：如果只有一两种钱包支付方式，那么这些钱包支付方式就成了钱包支付系统的控制者，更糟糕的是，他们会突发奇想地改变比特币 的规则。区块链就会无足轻重，因为人们几乎完全通过他们的钱包支付方式使用区块链。

设立一种钱包支付方式绝不像在公园里散步一样容易。我应该知道-我已经花了过去五年时间编写bitcoinj，它是一款可重复使用并占据比特币许多应用和服务核心的“钱包引擎”。但是，仍然有人可能在没有强大团队的情况下利用他们的业余时间编写bitcoinj。只有大公司才可实现的HTML5与它进行对照。比特币协议并不像它看起来那么简单，但已经足够简单。这种简单是目前使用的钱包支付方式多样性的关键。

不幸的是，支付通道并不简单。特别是一旦你引入了如闪电网络建议的功能等更先进的支付通道，其结果是你会有一个更大，更复杂的代码块。一些人已经制 造出像玩具一样的支付通道的实现方式，但只有bitcoinj有真实的保证产品级质量的实现方式。而玩具不必考虑像文档，序列化的状态到磁盘，单元测试， 用户界面集成，错误管理等等的问题。玩具和真实物品之间的区别是它能否被给一个非书呆子用来做应用程序。

Bitcoinj的支付通道可用来制作PayFile，它可以让为下载文件按每千字来付费，也可以 实现WiFi微支付计费的多种安卓端原型…以及StrawPay本身。整个StrawPay实现是建立在这个基础上，bitcoinj 和图形用户界面钱包是一个MultiBit HD的分叉。所以我们知道这个代码是有效的。这意味着我们也知道我们为它付出了多少努力。幸运的是，这项工作大部分获得了公司的资金援助。

你也许能想象到，一想到从明年夏天开始每个人都被迫在支付通道时完成支付，我就会很高兴。许多开发商断定必然会很快就有bitcoinj/ StrawPay替换他们自己的代码，我会得到更多的用户。但我不想让人们被迫匆忙使用我的代码。那会给我带来巨大的开发支持难题，我不想看到去中心化遭 受打击，尽管bitcoinj分叉很容易。加上开发人员不愿意被“要求”使用我的软件，而我也不想这样。

因此，如果我们使得设计钱包更难，我们有理由相信钱包支付方式将更少。StrawPay开发商说：

我们有一个java写的钱包应使用的库，但它正在开发中。还没有人支持iOS的钱包（他们甚至没有支付通道实现的AFAIK）。

对钱包开发商来说，在钱包能（译者注：这句里有一个单词“Stroem”，暂不知道如何译，全句原文是“before the wallet isStroem enabled.”）工作前，即使开发者掌握了库，库里有许多图形用户界面工作和常见的问题要做。

无论如何，正如游戏行业发展的那样，钱包市场可能会巩固在少数几个引擎上。但我们不必加速这一趋势。没有这个必要，因为这一切都是在解决一个根本不存在的问题：比特币的核心技术不用借助任何外部援助就能扩大交易容量。

菜鸟被淘汰的例子

来自闪电网络白皮书：

如果一个人不在正确的时间传递交易信息，交易对手可能会窃取资金。这一问题可以通过一个指定的第三方发送资金来缓解。增加输出费，为监视网络的第三方创造动力。

这种问题似乎属于学术性问题，但导致出现“不在正确的时间传递信息”问题，可能由于你的手机电池耗尽了或漫游到一个弱信号的地区这样的普遍性问题。通过增加更多非完全信任的第三方解决…但是这样就再次上升到复杂性的问题上了！

对于特别的情况，如没有其他方式可实现的极其快速的微计费，我们只需要忍受此类事情。我们应在能避免的情况下避免。

另一个案例：

一方丢失数据时，对方可能会窃取资金。

另一个…

尽管可能有方法来减轻[黑客]对发送者和接收者的威胁，中间节点必须是在线的，并有可能会自动处理事务。因此， 中间节点可能处在危险中，不要在这个“热钱包”中留一大笔钱。

由于费用较低，从长远来看，安全性更好的中间节点会超过其他中间节点并能进行更大的交易量。从历史上看，费用/利益最大的组成部分其中之一是各种形式的交易对手风险-比特币费用的最大组成部分可能来自安全风险溢价。

中心辐射型支付通道网络要求服务器永远在线，该服务器有敏感的签名密钥。这完全不同于普通的比特币使用，只有发送者需要签署，而且离线做所有签署司空见惯。这提高了其复杂性进而提高了其成本。

比特币的节点比枢纽中心更容易

比特币扩大规模的常见抱怨是，运行一个完整的节点会变得更难。有这种抱怨的人然后指向支付通道寻求解决方案，而忽略了这种转换只是通过不同的节点运行一个完整的节点更容易…更难建立和运行的节点。

主要原因是，支付通道网络枢纽中心是有状态的，所以你要确保他们有良好的正常运行时间，可靠性和工作备份。相比之下，比特币节点几乎是完全无状态的，所有访问P2P网络的软件都知道如何从一个突然消失的节点恢复。它随时发生而且对用户是透明的。

这让运行完整的节点变得容易而安全：如果你的便宜的10美元的VPS停机重新启动，没有人会注意到或抱怨。如果有大量数据丢失，你可以重新安装节点，它将从零开始重新计算需要的所有数据。如果它被黑客攻击，没有什么东西可以偷。支付通道枢纽中心不能真正实现这些事情。

性能风险高

StrawPay不使用你能直觉想象出来的设计，信道链路发送到枢纽中心，枢纽中心到枢纽中心以及枢纽中心到接收者。而枢纽中心会向接收人发出承兑票据。设计师说：

我在等待这个问题。这可能是我们所做的最长的讨论。原因如下：

1）安全性：保持支付通道服务器运行是一个复杂的事情。它必须安全。大多数商家没有这方面的知识，所以他们的钱包可能会被黑客攻击。而我们设计的承兑票据除了商家，可被任何人使用，所以窃取它毫无意义。

2）性能：我们担心枢纽中心网络中，枢纽中心到枢纽中心的小额进展不足够快。最好告诉商家，消费者已经尽快支付，而不是让商家持有承兑票据。

这是一个非常艰难的选择。

我们已经涵盖了安全问题，所以这并不奇怪。但提到性能时，你可能会不满。不要感到不满意-支付通道协议涉及很多消息的往返和创建签名/验证。单独这些步骤并不慢：它们是以毫秒为单位的。但如果每个步骤需要200毫秒，你有十个，一下子付款就会有点迟钝。

在网络上传递比特币交易也不是一件快速的事情，但它至少是充满了大量的优化空间。本地交易验证非常快：传播延迟的问题很重要。通过枢纽中心/辐射网络支付是图形追踪：他们有很大区别。

关于这一点的正确表述是，非接触式EMV规范要求，支付时间应小于500毫秒。这个时间包括启动智能卡所，建立无线链路，实现ECDSA签名和授权支付，以及终端验证需要的时间。每个服务器请求在线授权延迟超时只有200毫秒。伦敦的地下网络站中，有的站要求人们三秒通过那个门。因此，性能很重要。

也许是StrawPay人过于保守-关键是，还没有人知道，因为没有人试图设立和部署这样的网络。因此，许多重要的问题仍然没有答案。

没有时间

让我们忽略上述所有的问题，并假设支付通道网络是目前最好的支付方式。这并不重要，因为最迟明年年中我们会找到一个解决方案，甚至提出的网络还都不存在。

很简单，我们没时间了。没有可以在未来十二个月内获得广泛应用的可靠技术方案，而不仅仅是提高现有系统的支付容量，每个人都已经很好的理解和实施这一点。

我喜欢Stroem/Lightning小额支付快速路由的想法。我喜欢直接发送/接收小额支付的付款通道这种想法。可能有一天我们都会使用支持这些系统的钱包。但是谈论这些事情对于解决我们目前的问题，毫无意义。

一些人似乎认为，如果我们保持比特币的交易容量限制，交易手续费将会平稳上升，自由市场将解决一切。这种看法并不对。在我的下一篇文章中，我会写如果我们不及时处理这一问题实际会发生什么事情。

待续 …

声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。