作者: Alex Bosworth
翻译&校对: IAN LIU, 安仔 Clint & 阿剑
引言
我在推特上发起了一次调查，发现大家似乎对闪电网络的局限性都很感兴趣——究竟闪电网络能做些什么，又或做不到什么。今天我就来和大家厘清一下闪电网络的能力范围。
通道配置问题
从我一开始接触闪电网络，我就在思考闪电网络的目标究竟是什么；我突然灵光乍现—— 假如全世界的交易都是闪电交易那会怎么样？（当然这不切实际，因为全世界范围的交易种类太多了。）我想要以此假设为切入点，讨论如何使得闪电网络兼容所有的交易。
首先我们要明确闪电网络的定义 —— 闪电网络指的是基于余额锁定的状态通道所构建的系统。在系统中你我各自持有一些钱，然后我们使用闪电网络实现 “从我这儿转钱到你那儿” 或 “从你那儿转钱到我这儿”。我们还能使用 HTLCs 扩展以上功能，比如实现 “我转钱给你，然后你再转钱给某某”。上述行为的前提是我们具备这些余额锁定的状态通道，这也是闪电网络的基本功能界限。现在的问题是，这些通道有固定的容量与参与者集合，如果我们临时需要发送一笔大额交易，而在此之前你从未与收款方有过任何交互，就会面临通道还未正确设置的问题；你可以自行更改设置，但要求用户去做这样的操作就违背了我们设计闪电网络的初衷。
这可能是使用闪电网络会遇到的主要问题，不过除此之外，还有一些问题大家可能会有兴趣。
一、闪电网络是崭新的生态系统、首创的平台，需要大家学习如何使用它，同时还需要有人进行协议开发、软件开发、建立路由节点、担保资金等等。构建闪电网络生态系统，也是种建设市场的过程，没有这些人做出贡献，闪电网络将一文不值，因此生态系统的建立也是制约闪电网络的因素之一。
二、Layer-1 是决定闪电网络能否运作的关键因素。即使能够在链下做许多事，我们仍需要保证这些操作都是基于去中心化的 Layer-1 ，而且链下的交易最终能够上链。
就目前情况来看，比特币网络是最有可能成为第二层网络（闪电网络）底层支持的 Layer-1。
大额交易
从货币的角度来看，我们必须确保比特币是被大众接受的支付工具，因为在推荐其他人使用闪电网络进行支付可能遇到的最大障碍是，该如何说服他们使用这类奇怪的货币（比特币），这对使用者有什么好处？为什么这是件很酷的事？这貌似是我们这种闪电网络协议开发者无法控制的事，但这对于闪电网络的发展极为重要。
我只是要强调，如果你要进行低频次、高额、偶发的交易，那么使用闪电网络会遇到诸多限制，这并不适合你。有很多人问： “什么是大额交易？ 5 美元以上算吗？还是 50、500 美元以上呢？” —— 这么问本身就很有问题。
闪电网络是个市场、是个持续进化的生态系统，你可以将其想象为互联网。这个互联网中还连接者大学的内网和公司的内网，内网里的使用者彼此关联，因此网络带宽非常大，能够快速发送信息；然而，一旦使用者登录互联网网看视频或做些其他事，他们就会面临计算机的 “最后一公里” 问题：使用者以为服务商能够提供高质量视频，但当他们拨号联网后，却发现（因为网速不够）看不了高清视频；又或是使用者想要上传视频，却发现自己上传网速不够。
我所谓的 “大额交易” 问题，跟这个网速问题意思是一样的。
假如今天有个网络，彼此之间都在余额锁定为 1000 美元的通道中相互连接，那么即使我非常富有，想传输百万美元的价值，我还是会受到系统的容量限制。所以即便我有大量的钱，我想在一个锁定余额 1000 美元的通道中转钱给某个人，那么上限就是 1000 美元，这就是所谓的大额度。
区块链 vs 闪电网络
你为什么要使用区块链？区块链技术很棒，但你得忍受大量冗余；而状态通道却恰好能从冗余中获益。如果你正在操作高价值的交易，那么区块链适合你，因为区块链能够避免资产流动过程中可能出现的问题；同时区块链使用起来也相对简单，如果你需要在一个尽可能安全的地方保存资金，我会说那就用超级冷钱包吧。
区块链网络将部分责任移转给整个区块链社区；而闪电网络将更多责任赋予给使用者，这也意味着使用难度更大，后面我会进一步说明。
托管 vs 闪电网络
闪电网络的另一个竞争者是托管式清结算网络（如， Liquid 或类似交易所），或是其他使用闪电网络的系统，如 tipping.me 或 我创建的 htlc.me 。相比于闪电网络，托管式工作适合低价值的交易，因为区块链具有一定的上链成本，如果你的交易额度低于这个成本，那就会出现一些问题。因此，区块链在清算小额交易上的困难也制约了闪电网络。
在发送超大额交易时，闪电网络也会遇到问题。在区块链发起上千万的交易对你或许不是事儿，但如果是价值数十亿的交易，你就会开始担心区块链的工作量证明是否靠谱，紧接着你就会想念托管式服务或是其他系统的好；更糟心的是，工作量证明需要耗费很长一段时间，你只能等着。所以闪电网络能做的事情并非无限多，面对上述这几种情况，闪电网络并不是很好的选择。如果你能够找到值得信任的托管方、不介意做些妥协、不想把资金的责任揽在身上，那么托管式服务会比闪电网络适用。
区块大小限制
我从比较抽象的视角讨论闪电网络的局限性，如果你主要想了解闪电网络可扩展性的限制，那我们先来谈谈区块大小的限制。究竟一个区块能够装进多少交易，大家对这个数字都非常着迷；我认为观察交易如何被装进区块是件很有趣的事，所以我自制了一张图表来展示一笔普通交易的数据构成，因为开关通道的交易就是一笔普通的交易，所以我们能直接看出一次开关通道需要占据多少数据量。图例中表示了一个最小通道，字节都映射为虚拟字节；因为使用了隔离见证，所以签名字节数经过压缩。按照估算，一笔通道交易大小大约是 112 个虚拟字节数。
这是理论上构造一个通道的最小数据量，我们能将其视为单位通道大小，推算一个区块中能容纳多少笔通道交易。每个区块约有一百万字节的空间，如果我们能够将通道大小降低至 100 字节左右，理应能在区块中放入大量的通道。但实际上并非如此，要获得精确的单位通道大小，还需要经过更多复杂的考虑。
节约虚拟字节的技巧
有什么方法能够使通道开关交易大小缩减为理论上的最小值？如果所有交易只有一个输出，便能节省很多空间。但是当我们关闭一个通道时，可能会有多个输出，因为通道中至少有两方在进行资金转移。这时候你可以站出来呼吁， “为了降低上链的数据大小，我们在关闭通道前进行一下重整吧” ；所以我们会以某种方式推出其中一个输出，使得区块链只需要处理一个交易输出。这么做能节省区块空间，同时节省费用。
另一种释放链上空间的做法是， “开启一个通道的同时，关闭另一个通道”。换句话说，因为某些交易输出能作为其他交易的输入，所以我们能将通道合并为一。 这是个非常有用的技巧。
另一种我们当前尚不支持，但是短期内会看到进展的有用技术是多签名形式转化，也就是把多重签名压缩为单个签名的技术。这一技术极为强大，几乎不存在什么重大缺陷。通过签名聚合，我们能够将大量的签名合而为一。如果能用 Schnorr 和 Musig 进行签名整合当然很好，不过以椭圆曲线数字签名（ECDSA）实现也行。
还有一件事需要考虑，很多时候人们会估算上链的成本，并倾向不配合关闭通道。比如存在这种情况—— “我们要将通道输出广播上链，但是对方掉线了，该怎么办？”
在示例中，如果有一方选择不配合关闭通道，这并不需要通过什么复杂的脚本来解决，因为我们可以直接将不配合关闭通道的操作视为交易失败条件之一。我们应该尝试以时间锁或更高昂的费用，通过经济手段激励人们彼此配合关闭通道，比如，如果不合作关闭通道，就得付出更多的费用。
另一个我们已经实现的节省虚拟字节的方案是关于粉尘交易输出的（比如在闪电网络中，可能出现只值半美分的交易输出），因为在上链环节，这种极小额的交易输出会被区块链拒绝，或在对等传输阶段视为垃圾交易。作为解决方案，软件会将这些极小的输出放进矿工费中，因此，当我们必须以不配合的方式关闭通道时，能够稍微提高交易确认速度。
增加通道成员，减少虚拟字节
改善闪电网络的又一利器则是创建多方，而非仅仅两方参与的通道。当然这样的设计并非万全之策，而且这种机制的复杂性限制了它的落地应用。目前我们最多只能在一个通道中加入两个参与者，而在一个通道中加入更多人其实正是拓展虚拟字节利用率的绝佳手段。
单个通道中加入多个参与者的约束条件在于，究竟输入会被转换为多少个输出？通道内的交易最终还是要落到区块链上的，即使某一时刻不打算上链打包交易，我们也要具备交易随时上链的能力。
而现在面临的的限制是每个人都想要拿回属于自己的那一份交易输出。比如说现在到了关闭通道的时候，我想收回属于自己的钱，此时每一个输出都要花费大约 30 个虚拟字节。其实这时候你还不一定需要耗费这 30 个虚拟字节，但当你在在通道中遇到分歧，没法最终整合到一个输出的情境时，就必须多消耗这 30 个虚拟字节。
必须提醒一点的是，这些多方参与的通道，在建立时只需要一个人进行注资，即仅需要一个人来建立输入并发起交易。我实际上可以在向通道注资之后广而告之，“来十个人加入我刚刚建立的通道吧，这个通道的注资输入是我一个人的，大家接下来就把我的输入折腾成大家的输出，当然这些输出不会即刻反映到区块链上，除非我们没法继续重整这些输出，只能不情愿地关闭通道，将交易广播上链。”
多方参与的通道，人数可以达到相当高。基于我之前提到的签名整合技术——将数百个签名整合到一个签名上——理论上我们能在一个通道内加入数以千计的参与者。在设置输入需要留意：你其实也在设置大家的集体公钥，而集体公钥是由所有人的公钥进行哈希处理整合而成，所以并不需要多大的存储占位空间，就是固定大小的一段。
如果上述想法能落地实现，就意味着我们能够在一个区块中添加成百上千的通道。不负责任第畅想一下，也许能有数以千计的参与者加入到通道中。即使从现实出发，达到数十成百的参与者也不成问题。按这样计算，在一周之内我们能处理达到百万量级人次的交易。如此看来，以增加通道参与方的数量的方式来攫取通道的处理潜力具有相当大的探索空间，并且这种努力的方向并不会改变区块链的属性。
责任
把话题拉回系统设计，我想谈谈闪电网络的延展性设计以及我们如何实现延展。在系统中我们面临着这些问题，同时也是责任。系统中的参与者必须要回答以下问题：谁的钱会归谁？谁在其中起操控作用？这些操作是在通道中发生的吗？通道是怎样建立的？谁在验证这些操作？谁来保证每个人都遵守了规则？同时如何确保每个人都获取到了正确的数据？以上都是区块链和闪电网络在延展性上中所遇到的高级问题。
责任分摊
闪电网络的设计路线是分摊责任。系统中每一个人都需要尽可能控制好自己的那一部分责任，这样以来，就能在不给整个系统过多负担的责任下使尽可能多的人参与进来。闪电网络中将要使用的一条原则是：“你必须保管好自己资金的数据库”。
除你之外，没有人有义务告诉你这笔交易收了多少钱，你必须追踪自己交易的元数据，即：谁发送了交易，你又把交易发给了谁，这些将会是你自己的责任，而不是大家共同分担的责任。
当你在做某些全局性的操作而要给其他人证明的时候，你只需向他们展示最基本的证据证明自己的操作是合法的。如此一来，加入的新用户不会给系统带来负担，而其他的方式会破坏网络增长的延展性。我们同样设置了机制来保证用户仅仅需要核验区块、检查与自己发生交互的其他参与者的交易签名和操作。
用户只需要和固定数量的一小撮其他参与者发生交互，而不需要每来一个新人就费劲地核验一番。这种思想同样体现在了闪电网络的数据共享上。我们将会把仅把那些和你直接相关——即你需要关注的——可能是交易中一部分的数据分发给你。限定用户交互的其他参与者数量，能保证拓展网络的同时不至于增大添加新用户的边际成本。
责任代理
这给用户加入闪电网络带来了挑战。在区块链中，系统其实已经替你完成了许多工作，用户无需对自己资金的数据库负责，而是由区块链系统自动完成。你只需要拿好自己的助记词，下载好区块链，它会把所有的区块扫描一遍来检查你的资金存放位置。我们在这个方向上做了更多的工作。
虽然有很多提案表示用户应该负更多的责任，来让 Layer-1 得以扩展，但至少目前我们并不是这么做的。目前，只要你没忘记助记词，别的都好说。在区块链上，延展之所以成为一个难题，是因为系统中新用户的加入增加了需要核验的人数。举例来说，如果网络中增加了一千个新用户，那每一个老用户都要核验这一千个新人，这非常不利于延展。从用户之间的数据共享角度看，用户越多意味着数据越多，所以随着网络的拓展、资源开销也急剧增大。
在区块链上靠别人替你操作数据着实舒心，而在闪电网络上要靠自己管理这一切就没那么友好了。如果用户丢失了自己的数据库会有什么后果呢？由于我们取消了数据库共担的责任，现在数据库维护完全是用户自身的工作了。如果你把数据库弄丢了，那可要倒大霉了。
处理这个问题的一种途径是 “大家来采用责任代理”。即不把责任完全压在用户的肩上，而是有一些公摊的责任，但是需要用户来决定自己想承担多少公摊责任。我们目前把这种机制叫做数据丢失保护协议，lnd 对这一特性正有所需求。
你的伙伴节点会帮助你保存一小组数据，在你想要关闭通道但丢失了部分数据的时候，为你提供所需要的数据来完成关闭操作。我们刚刚在 0.6 版本中加入这个功能来实现静态通道备份系统。这是一组你从别处复制过来的数据，你可以把他复制到 P2P 服务里，也能如你所愿直接放到 Google Drive 上。它以一个加密的、很小的文件形式来呈现。我们目前正在致力于研发瞭望塔工程，当你不想要一直监视着通道，或者相对自己的通道承担所有的责任时，可以把这些工作外包给瞭望塔完成。
在区块链之类的系统中，如果有人想要搞双花或者别的破坏，整个社交网络会联合起来粉碎他们的阴谋。正义之士会谴责：“你不能这么做，这没任何好处”。或者通过别的方式来无效化这些攻击行为。将这种行为类比到闪电网络中，你可以讲：“我要选这些人当我的观察员，虽然我也可以自己完全揽下这些工作，但那样我就只能一直在网络上挂着了”。
同样由于区块链是一个共享所有数据的分布式账本，它会为你保管相关的数据。而在闪电网络中，如果你不在线，那就有可能接收不到和自己有关的数据。所以我们可以把责任代理出去，告诉所有人：“这个节点可以作为我的信箱。”充当信箱的节点会延迟 HTLC（哈希时间锁合约）最后一步的操作，然后向你发送邮件，或者你可以每天登陆一次闪电网络，检查邮箱是否收到邮件。接着由你来完成 HTLC 最后一步的操作。上述机制设计的关键在于，你虽然需要他人充当你的信箱，但他们无法对你的资产做任何处置。我们在责任委派上会设计一种温和的解决方案。
微信扫一扫 
