编者注：本文为 Alex Bosworth 文章《Major Limitations of the Lightning Network》的第二部分，非常具体地谈到了闪电网络设计中的问题和开发方向，比如系统和用户的责任分割问题，以及交易传输中的路由问题。第一部分内容详见《荐阅 | 闪电网络当前的主要局限》

责任

把话题拉回系统设计，我想谈谈闪电网络的延展性设计以及我们如何实现延展。

在系统中我们面临着这些问题，同时也是责任。

系统中的参与者必须要回答以下问题：

谁的钱会归谁？

谁在其中起操控作用？

这些操作是在通道中发生的吗？

通道是怎样建立的？

谁在验证这些操作？

谁来保证每个人都遵守了规则？

同时如何确保每个人都获取到了正确的数据？

以上都是区块链和闪电网络在延展性上中所遇到的高级问题。

责任分摊

闪电网络的设计路线是分摊责任。

系统中每一个人都需要尽可能控制好自己的那一部分责任，这样以来，就能在不给整个系统过多负担的责任下使尽可能多的人参与进来。

闪电网络中将要使用的一条原则是：“你必须保管好自己资金的数据库”。

除你之外，没有人有义务告诉你这笔交易收了多少钱，你必须追踪自己交易的元数据，即：谁发送了交易，你又把交易发给了谁，这些将会是你自己的责任，而不是大家共同分担的责任。

当你在做某些全局性的操作而要给其他人证明的时候，你只需向他们展示最基本的证据证明自己的操作是合法的。

如此一来，加入的新用户不会给系统带来负担，而其他的方式会破坏网络增长的延展性。

我们同样设置了机制来保证用户仅仅需要核验区块、检查与自己发生交互的其他参与者的交易签名和操作。

用户只需要和固定数量的一小撮其他参与者发生交互，而不需要每来一个新人就费劲地核验一番。

这种思想同样体现在了闪电网络的数据共享上。我们将会把仅把那些和你直接相关——即你需要关注的——可能是交易中一部分的数据分发给你。

限定用户交互的其他参与者数量，能保证拓展网络的同时不至于增大添加新用户的边际成本。

责任代理

这给用户加入闪电网络带来了挑战。

在区块链中，系统其实已经替你完成了许多工作，用户无需对自己资金的数据库负责，而是由区块链系统自动完成。

你只需要拿好自己的助记词，下载好区块链，它会把所有的区块扫描一遍来检查你的资金存放位置。

我们在这个方向上做了更多的工作。

虽然有很多提案表示用户应该负更多的责任，来让 Layer-1 得以扩展，但至少目前我们并不是这么做的。目前，只要你没忘记助记词，别的都好说。

在区块链上，延展之所以成为一个难题，是因为系统中新用户的加入增加了需要核验的人数。

举例来说，如果网络中增加了一千个新用户，那每一个老用户都要核验这一千个新人，这非常不利于延展。从用户之间的数据共享角度看，用户越多意味着数据越多，所以随着网络的拓展、资源开销也急剧增大。

在区块链上靠别人替你操作数据着实舒心，而在闪电网络上要靠自己管理这一切就没那么友好了。

如果用户丢失了自己的数据库会有什么后果呢？由于我们取消了数据库共担的责任，现在数据库维护完全是用户自身的工作了。如果你把数据库弄丢了，那可要倒大霉了。

处理这个问题的一种途径是 “大家来采用责任代理”。即不把责任完全压在用户的肩上，而是有一些公摊的责任，但是需要用户来决定自己想承担多少公摊责任。

我们目前把这种机制叫做数据丢失保护协议，lnd 对这一特性正有所需求。

你的伙伴节点会帮助你保存一小组数据，在你想要关闭通道但丢失了部分数据的时候，为你提供所需要的数据来完成关闭操作。

我们刚刚在 0.6 版本中加入这个功能来实现静态通道备份系统。

这是一组你从别处复制过来的数据，你可以把他复制到 P2P 服务里，也能如你所愿直接放到 Google Drive 上。它以一个加密的、很小的文件形式来呈现。

我们目前正在致力于研发瞭望塔工程，当你不想要一直监视着通道，或者相对自己的通道承担所有的责任时，可以把这些工作外包给瞭望塔完成。

在区块链之类的系统中，如果有人想要搞双花或者别的破坏，整个社交网络会联合起来粉碎他们的阴谋。
正义之士会谴责：“你不能这么做，这没任何好处”。
或者通过别的方式来无效化这些攻击行为。将这种行为类比到闪电网络中，你可以讲：“我要选这些人当我的观察员，虽然我也可以自己完全揽下这些工作，但那样我就只能一直在网络上挂着了”。
同样由于区块链是一个共享所有数据的分布式账本，它会为你保管相关的数据。
而在闪电网络中，如果你不在线，那就有可能接收不到和自己有关的数据。
所以我们可以把责任代理出去，告诉所有人：“这个节点可以作为我的信箱。” 
充当信箱的节点会延迟 HTLC（哈希时间锁合约）最后一步的操作，然后向你发送邮件，或者你可以每天登陆一次闪电网络，检查邮箱是否收到邮件。接着由你来完成 HTLC 最后一步的操作。

上述机制设计的关键在于，你虽然需要他人充当你的信箱，但他们无法对你的资产做任何处置。我们在责任委派上会设计一种温和的解决方案。
路由限制

闪电网络中另一个常被提及的困境是：我们如何设计路由？

闪电网络中的路由跳转是十分困难的，它的理论依据建立在 “六度人脉” 现象之上（译者注：可通俗地阐述为：“你和任何一个陌生人之间所间隔的人不会超过六个，也就是说，最多通过六个人你就能够认识任何一个陌生人。”）。

在如此庞大、数以百万计的用户之中选择路由，从当前百万用户中的这一个跳转到另一个百万中的下一个，这是十分困难的问题。

不过，人们之间是有联系的，我认识你，而你认识他，这么一想，理论上我不难通过这一个个的中间人跳转到接收方用户。

而实际操作中的问题在于，我们无法得知究竟谁在线，谁能帮我们找到目的用户。仅仅知悉用户之间的关系是远远不够的，还必须知道谁能对路由请求作出响应。

用户同样不知道别人的通道内有多少资金，所以还要知道哪些路径能便于我们重整好自己的资金，使得无论我们向谁发起交易都可以顺利进行。想想在一部手机上要搞清楚数十亿人的关系、那么多的数据要及时更新，这简直是异想天开。

让用户对整个图有完整的认识不切实际，我们想要做的是让用户只知道网络中一部分的关系（就能让整个网络运转起来）。

死胡同

路由还有另一个问题，大问题。

如果有个节点没把你的 HTLC 转发出去，怎么办？

如果他们坐视不理，或者取消掉了后续转发、回到了链上，怎么办？

闪电网络赖以运转的智能合约就建立在这些区块时间上。区块时间可以很久，理论上长达数日。

Lnd 允许你设置自己可接受的区块时间，但要让路由节点也接受这个时间才行。

吊诡之处还在于，因为闪电网络是洋葱路由网络，你无法得知是谁在为你转发路由。

在你从这一点发送交易之后，整条线路上由别人处理你的交易。你能感受到操作的延时，但无法探查究竟是什么缘故，或者要等多久。

虽然这不会影响到资金安全，但你的钱在这个过程中是被锁定的，叫天不灵，叫地不应的用户体验很让人闹心。想完成支付，却不能立即完成，这就是闪电面临的路由问题。

一个可信赖的路由网络

旨在解决这些问题的一种方案就是将节点分为各个有着不同责任的角色。

每个节点都可以担当自己想要做的任何角色，所以你可以认为每个节点都是一样的，只不过某些节点希望和其他节点有所区分，扮演不同的角色。

一个简单的例子就是，移动端节点的用户并不希望自己的手机时刻连接着互联网，毕竟有着数百万的节点已经在进行这样的工作了。他只希望成为一个消费节点。如果可以的话，他可以成为一个路由节点，但这并不是他所希望的。

未来我们会看到节点的专业分化。

我们将会有一组特定的节点来进行转账并赚取手续费。我们会将网络分成不同类型的节点。

如果我们能够建立一个这样的网络，在其中可以根据节点的行为识别出哪些节点是路由节点，那就可以让用户自主选择路由节点..……之所以我会选择你来发送我的流量，是因为你看起来经常在线，成功率和速度都不错。

如果我们能够构建这样的网络，必然会有在网络边缘的人，那些移动钱包或是那些对于路由不感兴趣或是不擅长的人就会被分配到网络边缘。

而在网络中心将是那些擅长路由、长期在线并且能力强的节点。之后我们就可以更好地了解如何在网络上从 A 点走到 B 点。它像是模拟互联网一样，在你的笔记本电脑上运行一个 web 服务器，但是你不是必须这样做的。你可以将它运行在某地的一台服务器上。

如何构建它都取决于你，但如果你想要在互联网上进行路由，则可能需要选择一台服务器。

这也解决了我们之前说到的资本流动性问题。如果说路由节点等价于宽带路由器，路由节点之间有大容量的通道，那么你就不再需要考虑到达目的地的流动性问题。你可以依赖路由节点很好地连接彼此。

唯一的问题就是你能否到达路由节点，这话反过来说也是一样的，即接收方是否可以从路由节点收到你的交易。这使得问题变得愈加简单，因为你不必担心（在传递路径中的）六个 hop 是否具有适当的流动性，你只需要关注的是传递过程中是否第一个 hop 是你，最后一个 hop 是接受者就可以了。

为了达到这个效果，我们需要建立一个市场。我们需要的是奖励那些完成工作的路由节点，致使路由节点运行顺畅，路由节点的运行代价不高，所以它们只需要收取有限的手续费。

这是一种市场形成的过程，也是一种软件完善的过程。

公共参考点

一旦我们拥有了这样的网络，我们就可以使用良好的路由节点，同时也解决了路由图的计算问题。

我们原本的想法是：我是十亿人中的一员，所以我需要通过这样的十亿人的网络才能从我的节点到达其他人的节点，这怎么可能做得到呢，我甚至连路由图都没有。

但是现在，比如如果要发起一个收款请求，那么你可以把与你连接良好的参考点节点都记录下来（并发送给我）。你可以把所有良好的路由节点都视为参考点。

当我选择进行付款时，我可以看到（所有的）参考点，因为参考点的数量是有限的，同时它们之间也很好地连接在一起。虽然我不能了解整个路由图，但是当你发送付款请求给我时，其中可以包含到达你的节点的最后一部分路径。

这使得路由变的更加简单。我们甚至可以将路由时间段外包，甚至仅外包有关的计算部分。

一些人最近在邮件上谈及如何保证隐私性。如果你没有这方面的需求，你只需要支付给你能找到的人，让他们来跟网络中的数十亿人保持同步。

他们会想尽办法来找出最经济的模式。你可以在不信任他们的前提下外包给他们，因为你可以...（译者注：原文如此）。

同时，我也认为还存在着外包的权衡，由于整个网络的权衡，你可能无法获得完美的路径。可能会存在手续费更低，隐私性更好的方案。

目前为止，路由图算法只能集中在为你提供当前最低费用，并随着时间不断尝试更低的费用。而在未来，由于存在有限性，我们认识到是无法获得完美的路径的，所以我们只需要得到一个可接受的路径即可。

资金限制

另一个我之前谈及的在闪电网络上的巨大限制就是存在着资金限制。

你拥有一些小的（转账）通道，小的（UTXO）输出。你发送了 100 聪但这笔交易却无法上链（因为金额太小）。

如果你有更多的钱，比如 5 美元，无论当前手续费或是链的使用条件如何，你都可以将这笔交易上链。大额的交易也会遇到流动性问题。

这就是闪电网络的基本限制。

多支付路径

目前存在一种解决方案，虽然没有完全解决，但是这样的通过多路径到达目的地的想法也确实对后续发展很有帮助。我们有多种实现的方法。

目前我们可以立即采取一种已经在真实网络中测试过并且实现不太难的方案，这就是 Base AMP。

举个例子： “我想要得到 100 美元，所以在收到 100 美元等值的 HTLC（哈希时间锁定合约）之前我就一直等着，你将通过不同的路径来发送总价值为 100 美元的多个 HTLC，在收到所有 HTLC 之前，我只接收，但不会公开那个 pre-image（即用于构建哈希锁的数据）。一旦我拿到了 100 美元，我就公开 pre-image ，并取出所有 HTLC 里面的钱”。

这是一种技术含量不高但是安全的 AMP 方案，虽然当前客户端没有很好地支持这一点，但确实是一种值得一试的方案。

另一种发送更多资金，规避单个通道的最大值限制的处理方案则为，如果我们在单个转账方向上拥有多个通道，采取同样的方案，你只需要在两个不同的节点间等待多个 HTLC 。甚至不需要让发送方和接收方知道这一点，只需在路由路径中如此设置便可。

未来我们可以采取这样一种方案，我们拿到 pre-image 并将其分解成为一堆不同的加密后的信息，这样即使在 Base AMP 中，接受者也会受到经济激励一直等待，无法获取信息。通过使用 Schnorr 签名，使用更加高级的结构，即使他们想要得到这样的信息也不能实现。

多系统支持

我们依托闪电网络能做的另一件事就是接受它的这些局限性，并提出各种小技巧来处理一些边缘情况。

由于体积小，我们可以让一些小额的（UTXO）输出成为交易费。同时我们也可以做一些疯狂的事情，比如概率支付，“我们有 1% 的几率获得 100 美元” 之类的。

我们可以使用这条链或者那条链。我们可以使用 Liquid 侧链。如果我们为了绝对地最小化链上通道的大小而关闭通道和移除流量，这可能会派上用场。

我们可以使用不同的方法，使用其他不同的链，通过 submarine swaps （一种主链与闪电网络资产转移方案）来将其他的输出转移。我们也可以回归到链。

我们可以说， “让我们将主链发送的资产和闪电网络发送的资产整合到同一个钱包中，这样的话，如果发送金额过大而导致失败，我们可以接受，同时切换到主链上协同完成转账。”

现在人们也在尝试着一种叫做 turbo 的模式，在特定的情形中，它能实现零确认通道。 这意味着你可以同时获得主链和闪电网络的优点，即你可以留在闪电网络系统中但是使用主链转移任意高价值的资产。

另一种我觉得很酷的方式，我不知道是否有人正在研究这个问题。就是在小规模交易中，我们可以使用客户端签名来处理节点间的一些小 commitment 。我们可以使用电子现金以便你可以隐秘交易一些在主链上没有意义的微小的 commitment 。

最后一点，我们可以做的另一件事就是提高资产的限制值，由此来增加资本市场的复杂度。这也是现在人们所努力的另一个方向，比如 Bitrefill 着力于 turbo 模式但是同时也着手于 Thor 这个项目，这个项目就是允许你购买 inbound 流动资产（即接收其他节点数据），这和我们 Lightning 实验室的 Lightning Loop 项目不谋而合。

当我们拥有更多的工具，我们就会吸引到更成熟的买家和卖家，就可以更加增强你规避资产限制的能力。

1.0版本协议限制

我在这个演讲中加入了许多其他的东西。

我想谈的是， 1.0 的协议事实上有一些恼人的限制。我希望在这里强调一遍。考虑到闪电网络的重要性，虽然它不是一个一成不变的协议，也需要我们去适应和发展。这是一件好事。

我认为在 1.0 版本的协议中首先要被修复的问题就是，当你强制关闭一个通道时，返回的强制关闭的（UTXO）输出使用的是随机密钥。

如果你只有你的种子，你无法从主链中去扫描所有区块以找到你的资产，因为这些是使用随机密钥的而你不知道随机数是多少。这就是 1.0 版本中的一个问题。这增加了你自己所需要备份好的材料数。你需要时时保留着自己的随机数。

当然，还有其他一些问题。

每当你在区块链上关闭一个通道时，相应的资金就会被锁定到一笔 CSV 输出中（即 CheckSequenceVerify 文件），这也就意味着会锁定一定的时间，只有在一定的区块被挖出后才能解锁。

这就衍生出另一个问题，你无法在一笔 CPFP（Child-pays-for-parent） 的交易中对父交易额外收费（bump the fees），因为你无法在几个区块确认前花掉它。 CPFP 要求你把父交易和子交易放进同一个区块中，以便将利益绑定给同一个矿工。

我们所已知的另一个问题则为，通道的容量是固定的，且我们对通道的容量会有一个较低的限制，比如 0.16 。这就产生了很多问题，尤其是让交易所支持闪电网络。现在非常难实现。

另一个关于支出的问题在于，如果你在资金暴增期间有一些手续费较低的交易，你将会很难和其他节点协商提高手续费。这也是闪电网络现在面临的局限性，因为协议还不支持，你无法发送给别人，别人也无法接受。

升级到1.1版本的协议

而在 1.1 版本中，如果可以顺利完成，我们会添加各种新功能来解决上述的所有问题。

我们会将远程地址设置为静态的，这样如果经历了强制关闭通道，你也可以通过扫描整条主链来获得你想要的信息。你也不必保留那串随机数了。

在 CSV 约束的交易中，我们会增加别的一些引发条件。

我有些超时了，就不继续延伸，进入问答环节吧。

Q

AMP 是否存在当前系统一样的问题，即一个节点可能会扣住 HTLC 并且会锁定流动性？这要怎么处理？

A

当然，首先，我认为你必须要考虑整个路由节点网络。你并不是通过完全随机的节点进行发送的。你的发送是通过专门的节点网络进行的。事实上，这些被选出的节点是被你的大额手续费所激励的。你仍然有这样一个问题，即你不确定哪些节点是作恶的。有另外一种方法可以解决这个问题。一旦我们有了这些推送交易，或者我们和接收方有更多的交互，我们就可以通过一些测试查看是否有效来预先确认路由路径。在这种情况下，我们使用的并不是真正的钱，我们使用的是他们所不知道的一些虚假的哈希。我们可以说 “这个问题已经是过去式了” 。我们可以再次发送。准此，我们可以让这种情况变得越来越少。

Q

如何解决网络中广泛的通道平衡问题？

A

我确实认为我们应该反思把资本当成商品的观念。流动性是一种产品。我看到许多人谈到 “你们能否为我注入一些流动资产？”。我认为相对应的成熟方式是 “你想要 inbound 流动资产？请先进入 inbound 流动市场去寻找是否有你想要的 inbound 流动资产。” 一旦我们有了更成熟的方案，我们就可以针对你的特定的流动性问题提出更简单的方法。

Q

是否可以在通道打开之后更改愿意转发的 HTLC 的价值下限？

A

是的，我认为这个大小是可调整的。你可以说这是通道策略的一部分。当然，在技术上是可能的。你可以接收到一个 HTLC 然后说 “这太小了，我拒绝接收。”

Q

我们是否会在 1.1 版本中增大通道的大小？

A

是的，事实上它是无限的。通道的容量是不受限制的。但是我们仍然会遇到这样一个问题，我们可能需要一些默认的安全限制，因此我们可以讨论一下比较合理的数值。第二点，即使路径中的一个节点具有巨大的容量，也不是意味着路径中所有节点都拥有这么大的容量，因此，一种更好的方式就是作为一种生态系统慢慢增长。

Q

我想要将我的 Ind 节点移到 .onion 网络中，以隐藏我的 IP ,但是我希望我还是可以通过 Ind REST API 来访问我的电子商务商店，你觉得我应该怎么做？是使用 VPN 以取代 Tor 吗？

A

不。 Tor 只适用于闪电网络节点本身。我在基于Tor 的 Yalls.org 上用自己的节点执行你这样的操作。我建议大家都基于 Tor 来搭建自己的节点，这很酷。它依旧会保持正常的网络开放，所以你可以正常获取自己的 IP 并使用。

Q

你觉得在 1.1 这个版本中哪些首要用例或是服务会开放？

A

确切的我不是很清楚，这些仍在制定中。推送交易是我最期待的一个，因为它允许在网络上完全交互。你可以使用仅存在于闪电网络上的 API ，在其他地方没有。你使用的不是一个 HTTP REST API ，而是一个闪电网络 API 。这对我来说是最酷的一件事。

Q

对于那些试图更好的了解闪电网络的开发人员，你有什么推荐的吗？

A

我非常喜欢 BOLT RFC ，这也是我初探闪电网络的地方。我刚刚浏览了所有不同的 RFC 。他们有所变化，但是你依旧可以看到一些主链交易或是其他事物。 Lightning Labs 有一套 API 开发系统，在那上面我建了自己的内服务库，可以能让事情变得简单，运行良好。这也是我在建立 Y’alls 和 HTLC.me 时所用的。

原文链接: http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-alex-bosworth-major-limitations/

作者: Alex Bosworth
翻译&校对: 安仔 Clint, Whisker & 阿剑

*转载自以太坊爱好者

（向上滑动查看内容）

了解最新动态

官方网站

www.conflux-chain.org/zh/

微博关注@Conflux中文社区

weibo.com/confluxchain

Twitter关注@ConfluxChain

twitter.com/ConfluxChain

Reddit

www.reddit.com/user/ConfluxChain

Telegram

t.me/Conflux_English

GitHub开源交流

github.com/conflux-chain

Medium

medium.com/@Confluxchain

知乎关注@Conflux中文社区

www.zhihu.com/org/confluxzhong-wen-she-qu/activities