如何加速闪电网络广泛使用——祝贺闪电网络锁定资金超过100BTC
第0章引言
闪电网络里锁定的BTC已经超过100个，500多万人民币，这是一笔非常大的资金了，这意味着闪电网络得到了很大的资金的认可。这或许是最近BTC领涨——这是近一年来很稀有的事——最有可能的解释了。
本文解释闪电要进一步扩展到大规模应用的几个需要解决的问题或叫需要普及的认知。
第1章 打开和关闭支付通道的方式
在闪电网络里使用的币是被锁定在一个2-2签名的地址里的，存入的过程叫打开支付通道。这个2-2签名地址是由两个人分别持有一把私钥的地址。而我们现在持有比特币一般是存在自己一个人控制私钥的地址里。
如果要求用户使用闪电网络之前，先打开一个通道，再使用闪电网络支付，这是比较反人性的。即先构造一笔主链上的交易，将自己的币发到一个2-2签名的地址里，然后再使用闪电网络进行支付一次。如果主链交易可以直接完成支付，用户没有必要去搞两次交易。
那如何解决这个问题呢？答案是让用户购买比特币的时候就直接将币存放进一个闪电网络的支付通道中。比如现在绝大多数用户都是将交易所当成钱包，而交易所本身可以是一个闪电网络的节点，自动帮用户打开一个交易所和用户之间的支付通道。
而在闪电网络的支付场景下，用户一旦完成，用户可能会选择关闭支付通道。即用户利用闪电网络付完款后，可能会将余额提现到自己一个私钥完全控制的地址。如果是这样，也是一个反逻辑的做法。因为相当于用户需要支付两次，这纯是有毛病的做法，没有用户会这么干。
解决的办法是让用户无限期将币存在支付通道中，除非必要提现，否则用户应该尽可能长时间地放弃关闭支付通道。
要做到用户买币即存在支付通道，和用户长时间将币存在支付通道，这是需要闪电网络拥有超高的安全性。就像现在保存比特币使用冷钱包那样，理论上绝对安全。闪电网络如何做到，是一个重要要考虑的事。
第2章 寻找路由寻径的难题答案
闪电网络是有一个路由寻径的难题，是这样的：如果A和B打开了一个支付通道，但A和C没有打开支付通道，那如果A通过闪电网络给C支付一笔币，闪电网络需要寻找一条由A到达C的路径。假定，B和C之间有支付通道，那闪电网络就可以先由A到B，再B到C，这样完成支付。
这个路由算法是一个大问题，因为一般的用户不可能和很多人打开支付通道，基本上我们只能假定一个用户只和一个服务商打开支付通道。
如果路由之间的“跳”数太多，会对闪电网络全网造成额外的压力，因为这一条“多跳”的支付通道都需要改变状态。甚至会出现找不到可支付的路径的可能，这时候就需要用户将支付交易发送到主链来交易，即闪电网络内支付失败，而改用主链支付。
解决这个问题的办法是建立大型的支付通道中心。比如一个交易所和另一个交易所之间打开支付通道。而这两个交易所又和自己所有的用户打开支付通道，那这两个交易所的用户就可以通过简单的“三跳”，就完成支付。
所以我觉得闪电网络的发展应该放弃去中心化的思维，而鼓励大型中心化支付节点，让中心节点和散户建立通道，中心节点之间高效连接。最终如果能够说服所有的交易所都建设一个闪电网络中心节点，而且所有交易所的用户都和自己的交易所打开一个支付通道，那闪电网络可能就可以建立一个非常实用的支付网络了。
但这样又带来中心化的难题。
第3章 化解大型支付通道节点的中心化的威胁
闪电网络的经济模型，是必然会鼓励形成中心化的大型支付节点的。所谓的大型支付节点是指一个人使用一把私钥和很多其他人打开很多2-2签名的支付通道，这一把私钥可以和这些所有的2-2签名的支付通道调整余额，以完全闪电网络内的支付。
一般交易所和offchain钱包可以充当这种大型的支付通道。
这种大型的支付通道会带来多个问题。
第一个问题是这种中心节点注定是一个麻烦集中点，比如容易受到黑客的各种攻击，可能出现意外故障。因为闪电网络的支付通道是一定要双方在线才能完成支付的，所以这种中心节点必须保证7*24小时在线，这不是一个容易的事。一旦一个这种大型的中心支付通道节点出现故障，就会造成大规模的支付失败，这些支付失败的交易就需要回到主链上完成支付，这将会对主链形成巨大的压力。而因为Core的顽固，BTC主链是很难完成扩容的。
而且这种意外的中心支付节点故障可能会导致无法有效地广播通道内的最终状态，即不能使用通道双方都签名的方式来广播到主链，单方广播状态需要等锁定时间结束，这可能会导致资金短时间内无法使用。
第二个问题是一个现实社会的法律难题，这种中心化的支付通道是难于躲避政府的审查。这是和比特币的设计初衷相违背的。
这个问题就目前的BTC生态来说，好像是无解。最好的解决方案就是完成主链扩容，但要BTC扩容，太难了。
如果能对主链进行扩容，那中心节点故障后主链就可以处理，不至于造成长时间的堵塞，避免造成难于修复的问题。
目前解决了主链扩容的BCH能不能使用闪电网络呢？答案是不能。因为现在的闪电网络的设计都是基于不可延展性的交易来设计的，即隔离见证交易。BCH目前还没有部署这样的特性，短期来看，BCH社区认定延展性是一种功能，而不是一种缺陷，所以要部署类似隔离见证的特性估计很难。
而对政府审查的KYC来说，呵呵，无解。如果大型的中心支付节点是匿名性的，谁敢跟他长期打开支付通道呢？如果不是匿名的，注定是要面临KYC。
闪电网络如果想大规模普及，我个人觉得主链扩容是一个非常有利的推广方式。
第4章 推动闪电网络预存大量资金
闪电网络有一个支付通道内资金的流动性问题。如果A要经过B、C这两个节点通道，向D支付一笔0.1BTC的币，需要B和C都同时有0.1BTC+手续费的余额。这意味要要让闪电网络运行起来，需要预装远超过需要的支付总金额的资金，而且“跳数”越多，金额越大。而闪电网络前期还没有形成大型的中心支付通道的话，“跳数”注定是非常多的。
这样的困境会造成闪电网络内资金流动性不足，任何一笔大金额的支付都可能寻找不到足额的支付通道。
解决这个困境需要闪电网络的激励手段，即支付通道可以收手续费，这样会激励人专门去运营一个大型的中心支付节点，并且预存足够多的资金，以提供路由寻径到这个节点。
但这需要闪电网络的安全性让人放心，现在全网是107个币，却有1万多个在线支付通道，平均一个通道不足0.01个币。这样的流动性只能满足非常小额的支付。
第5章 完善闪电网络需要支收双方在线的尴尬
我们使用比特币主链，收款方是不需要在线的，冷钱包都行，收款只需要到区块浏览器去查一下就知道了。
但使用闪电网络支付，则需要收款方签署一个回执。相当于收到款了，还要给人家写一个收据。这相对于主链交易来说，是一个倒退。我们使用支付宝，微信支付都没这么干的。
对于大型中心支付通道来说，需要跟如此之多的用户频繁地签署回执，自动化程序设计也是一个大难题。
这是一个用户教育问题，只能通过性价比和教育来说服客户接受。
同时在收支双方要求在线还有另外一个难题，就是支付通道的双方都需要监控通道的余额状态，以防止其中一方向主链广播特定的历史余额状态来骗取额外的不属于他的资金。一旦监控到有这种欺诈，被骗的用户需要在约定好的结束期限之前向主链提供证据。这对用户来说，是一个巨大的负担。我们使用主链保存币，根本就没这回事，只要我不动私钥，这币永远是我的。
解决这种需要实时监控通道状态的难题可以提供专门的监督服务，这在闪电网络的生态里叫“瞭望塔”，用户可以委托“瞭望塔”来监督，并且在监测到恶意欺诈后采用行动。
第6章 习惯闪电网络没有历史支付记录
我们使用主链支付，每一笔交易都是可以查到的，无论是发生在多少年前，历史记录是不会消失。
在闪电网络里，历史支付状态只有通道里的双方知道，并且并不要求永久保留。这或者是一个使用比特币用户习惯的重大调整。
不过，这看起来也不是啥大问题，培训用户习惯而已。
第7章 缓解闪电网络放大了的51%攻击的威力
我们都知道比特币可以面临51%攻击来双花一笔交易，但无论从经济上，还是从技术上来说，实施起来都很难。但闪电网络可以放大矿工的51%的可能性。
因为闪电网络里的交易要退出到主链时，本质上是矿工来审查这些交易签名的余额分配状态的合法性的。一个持有51%的矿工，可以决定支付通道内最终的状态余额哪一份状态在主链上是合法的。如果一个矿工超过51%的算力，然后他在闪电网络充值几百几千几万个币，然后花出去，然后将第一版的签名状态到主链上广播，并且直接给确认了，那就是一个非常完美的51%攻击。
本质上闪电网络是延长了51%攻击的组织时间，在主链上（没有闪电网络）做51%攻击，需要在花出第一笔交易之后，以最快的速度切换51%的算力到这第一笔交易被包的前一个区块去挖矿。而且需要51%的算力拼出块胜过49%的算力，并且需要在短时间内拼出多出两个区块以上。
但在闪电网络的配合下，第一是花费这些预计要双花的币可以慢慢花，花几天几个月都没问题。第二是51%的算力是不需要到上面说的“打包第一笔交易区块”的前一个区块高度去挖矿，而是直接挑选对攻击者自己有利的余额状态进行确认，然后拼过49%的算力的确认数，就够了。
所以说，闪电网络可以放大51%攻击的威力。在主链上，其实51%攻击几乎是没有机会双花的，但闪电网络下，这可真说不清楚啦。
这个问题并不需要紧张，要齐聚51%的算力实在是太难。而且51%只是理论上的值，考虑到运气成分，真想要发动攻击，最好的拥有75%的算力。即使有人持有了51%的算力，这种攻击也会导致币价和矿机价一起跌，对攻击者没啥好处，经济账算不过来。最后这个问题可以通过实名制来解决，考虑到法制社会，犯盗窃罪是很严重的，而且闪电网络最终的发展，大的支付节点大概率是要实名制的。
所以说，发动这样的攻击可能性还是很低。
第8章结束语
虽然我是大区块的支持者，扩容方向我认为BCH走的才是更正确的方向，不过我真实希望闪电网络能够成功。
（欢迎加我微信号：HSL13116885 加入我的知识星球）
另请阅读：
上一篇：