我在推特上发起了一次调查,发现大家似乎对闪电网络的局限性都很感兴趣 —— 究竟闪电网络能做些什么,又或做不到什么。今天我就来和大家厘清一下闪电网络的能力范围。

原文标题:《干货 | 闪电网络当前的主要局限》
原文作者:Alex Bosworth
翻译 & 校对:安仔 Clint、Whisker & 阿剑

七大维度俯瞰,闪电网络核心开发者万字点破闪电网络当前局限Alex Bosworth,闪电网络基础设施负责人

一、通道配置问题

从我一开始接触闪电网络,我就在思考闪电网络的目标究竟是什么;我突然灵光乍现 —— 假如全世界的交易都是闪电交易那会怎么样?(当然这不切实际,因为全世界范围的交易种类太多了。)我想要以此假设为切入点,讨论如何使得闪电网络兼容所有的交易。

首先我们要明确闪电网络的定义 —— 闪电网络指的是基于余额锁定的状态通道所构建的系统。在系统中你我各自持有一些钱,然后我们使用闪电网络实现「从我这儿转钱到你那儿」或「从你那儿转钱到我这儿」。我们还能使用 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 最后一步的操作。上述机制设计的关键在于,你虽然需要他人充当你的信箱,但他们无法对你的资产做任何处置。我们在责任委派上会设计一种温和的解决方案。

作者 : Alex Bosworth

翻译 & 校对 :IAN LIU, 安仔 Clint & 阿剑

五、路由限制

闪电网络中另一个常被提及的困境是:我们如何设计路由?闪电网络中的路由跳转是十分困难的,它的理论依据建立在 「六度人脉」现象之上(译者注:可通俗地阐述为:「你和任何一个陌生人之间所间隔的人不会超过六个,也就是说,最多通过六个人你就能够认识任何一个陌生人。」)。在如此庞大、数以百万计的用户之中选择路由,从当前百万用户中的这一个跳转到另一个百万中的下一个,这是十分困难的问题。

不过,人们之间是有联系的,我认识你,而你认识他,这么一想,理论上我不难通过这一个个的中间人跳转到接收方用户。而实际操作中的问题在于,我们无法得知究竟谁在线,谁能帮我们找到目的用户。仅仅知悉用户之间的关系是远远不够的,还必须知道谁能对路由请求作出响应。用户同样不知道别人的通道内有多少资金,所以还要知道哪些路径能便于我们重整好自己的资金,使得无论我们向谁发起交易都可以顺利进行。想想在一部手机上要搞清楚数十亿人的关系、那么多的数据要及时更新,这简直是异想天开。让用户对整个图有完整的认识不切实际,我们想要做的是让用户只知道网络中一部分的关系(就能让整个网络运转起来)

死胡同

路由还有另一个问题,大问题。如果有个节点没把你的 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 时所用的。

来源链接:diyhpl.us