瞭望塔与 BOLT13

fffmCQ.jpg

*作者:Sergi *

来源:https://btctranscripts.com/lightning-hack-day/2020-05-24-sergi-delgado-watchtowers/

Sergi Delgado Segura

本文为 Sergi Delgado Segura 在 2020 年 5 月的 Lightning Hack Day 活动上的演讲,由 Michael Folkson 转写为文字稿。

演讲视频:https://www.youtube.com/watch?v=Vkq9CVxMclE

演示文档:https://srgi.me/resources/slides/Potzblitz!2020-Watchtowers.pdf

引言

我准备讲讲瞭望塔和 BOLT13。在讲解瞭望塔的细节之前 —— 虽然闪电网络瞭望塔的大体想法已经为社区的大部分人所知 —— 我准备先退一步,尝试缩小一下我们准备讨论的东西。

回顾

在我们思考瞭望塔的时候,我们想的是闪电通道 —— 瞭望塔可以在你的通道对手尝试欺诈、而你正好下线或遭遇宕机的时候,用带有惩罚的承诺交易保证对手不会成功。但瞭望塔还可以用在别的地方。今天我就准备讲这个话题。我们平时讲的第三方监控系统(即 “瞭望塔”)的基本范式是,用户和塔,也就是用户和服务端。用户将一些数据和触发条件发送给服务端。这里的数据是什么,并不重要,触发条件是什么也不重要。服务端会在特定的一个通道信道中寻找符合触发条件的东西。在闪电通道这个案例中,服务端会在区块链上搜寻,而在另一个案例中,可能是另一个完全不同的环境。只要服务端看到了符合触发条件的东西,瞭望塔就会拿用户提供的数据来执行一个动作。这就是我们今天准备讨论的东西,大体上就是这样。我们来看看闪电通道这个场景。

1 分钟讲解闪电通道交易

我假设这里的听众对闪电通道没有任何了解。我会讲讲闪电交易 —— 我们要使用什么样的交易,以及如何使用它们。

首先是闪电通道的充值交易。这是所有事情的起点。参与一条通道的双方中的其中一方,将资金锁入一个 2-of-2 的多签名输出中。然后,使用这笔交易(的输出),我们会创建多笔承诺交易,以表示通道内部状态的更新。每一次我们希望给对手方支付、或者对手方想给我们支付时,就会发生一次状态更新(创建一笔承诺交易)。所以,我们会有许多个不同版本的承诺交易,每一笔交易都花费同一笔资金(同一个输出)。如果万事顺利,到某个时间点,我们会使用一笔关闭交易来关闭通道。我们会拿最新一笔承诺交易来解锁资金,这笔交易就是 “关闭交易”。

但是,通道内可能有不轨行为,你的对手可能选择一笔旧的承诺交易并把它广播到网络上。这就是我们说的 “通道被破坏” 的情形。

假如 Alice 尝试欺诈,Bob 可以创建惩罚交易、拿走通道内所有的资金。如你所见,这里标注了两种交易:承诺交易和惩罚交易。这就是我们关心的东西。

基本的瞭望塔协议

有了这些理解,我们就可以建立一种基本的瞭望塔协议。这里有两方:一位是弗罗多(Frodo),你们可能听说过,他来自 中土世界(Middle Earth);另一位是中本聪之眼(The Eye of Satoshi)。我不知道你们有没有听过《指环王》,但是弗罗多是个好人。

从用户的角度看,我们手上有一些数据。现在我们不会深究这些数据的细节,但请记住承诺交易的 ID 以及惩罚交易,是其中一部分。我们将以某种形式保存这些数据。创建一个约定,我们将数据发给瞭望塔,瞭望塔开始监控区块链,观察通道被破坏的情形。这里我们也不会详细解释是怎么监控的,基本的思路就是说,瞭望塔得到用户的信息之后,就可以使用承诺交易的 ID 来监测打破通道的行为。弗罗多喜欢外出,可能跑到没有信号的地方去,几个小时不能响应。但幸好,中本聪之眼帮他看着所有这一切。在弗罗多下线的时候,中本聪之眼依然看着区块链。某一刻,中本聪之眼看到了某一笔承诺交易出现在了新挖出的区块上。这就表明,弗罗多的通道被打破了。中本聪之眼注意到了,然后就把惩罚交易发送到网络中,而且运气好的话只需几个区块就能确认惩罚交易。使用惩罚交易夺回的资金,大部分会归还给用户,小部分会发送给瞭望塔。关于其工作的原理,大体上到这里就结束了。我们有数据、触发条件、以及监视区块链的第三方观察者。

在这里,我们关心四件事:(1)用户所拥有的信息的类型。就是屏幕上左边的红色部分。承诺交易、惩罚交易以及如何用它们来创建跟瞭望塔的约定。也就是说,如何将它们发送给瞭望塔?(2)谁能发送这些信息,怎么发送?(3)瞭望塔应该怎么存储这些信息呢?存储什么类型,用什么方式?(4)奖励机制如何设计?这四个问题,实际上就是四种属性,是我认为在设计一个非托管的瞭望塔协议是需要面临的四种取舍。

现在,我们就要讲讲非托管的瞭望塔了。我们可以稍后再讲不同的设计。这样理解起来简单一些。

(非托管的)瞭望塔协议设计取舍

首先,我们要讲隐私性;换句话说,瞭望塔对自己的用户(一个闪电节点)到底知道什么?用户提供了什么信息,可以解读出什么?还有权限问题。谁能访问瞭望塔?谁能使用它,在何种条件下使用?第三件事是存储。瞭望塔必须存储什么信息?这些信息会如何增长?最后,我们还要考虑成本。运行瞭望塔服务的成本为何?谁为这些成本付费、分摊多少成本、如何支付?我们讲看到,这四种属性是相互关联的。设计其一就会影响其余方面的设计。

没有隐私 vs. 完全隐私

我们先从隐私性开始。这里我们有两个极端。没有隐私性,以及,完全隐私。可以认为是存在中间路线的,但我先聚焦这两种情形。如果你们想要的话,我们再跳到中间路线的设计。

在这里,主要的思路是,用户可以选择完全不为瞭望塔设置隐私屏障,也就是把所有的信息都发送给瞭望塔。这意味着,整个装置跟我们在几页幻灯片以前看到的案例非常相似。用户清楚地发送承诺交易 ID 和惩罚交易给瞭望塔。这意味着,瞭望塔可以验证收到的信息看起来像一笔有效的交易、一个合理的交易 ID。虽然瞭望塔不能知道所收到的交易是正确的还是错误的,只能确定它看起来是一笔有效的交易;瞭望塔也不知道承诺交易的任何内容,只知道其交易 ID。瞭望塔也不知道惩罚交易会不会从某一点开始变成有效交易、能够广播到网络上,还是自始至终只是一笔完全无效的交易。最后,这种模式的缺点是,瞭望塔将知道关于用户的支付信息。每次通道状态更新的时候,瞭望塔都会知道对应的惩罚交易。这可以推断出每次更新的时候是哪一方在给哪一方支付。这显然不是理想状态。

然后,我们也有一种高隐私性,或者说完全隐私性的模式,就是用户把加密过的信息发送给瞭望塔。我们稍后再了解更多的细节和它的工作原理。现在,我们要记住的是,这样一来,瞭望塔就只有在通道被打破的时候,才知道相关的惩罚交易。否则,瞭望塔存储下来的就只有加密的数据,而且在这个意义上,不能了解用户什么信息。在这种模式中,瞭望塔也不知道交易的任何信息,但这不是一个问题,因为知道完整的交易也没什么用。不过,这种模式也意味着更重的运算量。会涉及到一些缓存、加密和解密,但这是为了用户的隐私而作出的牺牲,应该是合理的。

总结一下,在两种方法中,用户都可以发送有用的信息给瞭望塔,瞭望塔都不能发现什么是有用的、什么是无用的。存储需求都很高。因此,隐私设计看起来比没有隐私的设计要好。我们可以保持用户的隐私,尤其是在闪电网络内的隐私(我们本来就希望它是一种高隐私性的设计)。这是我们想要的一些东西。

私人访问 vs. 公开访问

然后是权限问题。也可以分成两种不同的方法。可以将瞭望塔变成私人访问的,或者可以公开访问的。再说一次,中间路线是由的,但我们最后再说。我觉得私人访问可能会被用在非常小众的人群中,其中有些人是值得信任的。这意味着,你会自己运行瞭望塔,或者让你的朋友们 —— 也就是你信任的人 —— 运行。比如我的一个朋友,他为自己运行瞭望塔,然后我们周围的人也都沾光了。我们不会只运行一个全节点,我们可以让 N 个参与者接力运行。这很棒,只要每个人都守规矩,就不会有 DoS 攻击的问题。从用户的角度看,这可能会是一项免费的服务,用户可能不会付钱。主要的确定在于,这无法帮到整个网络。如果你不为服务支付,那就得由别人负担运营成本。免费服务是很难的。

另一方面,我们也可以有公开的瞭望塔。任何人都可以使用这种瞭望塔,这也是我们最终的目标。它可以作为一项服务来运行。理论上,谁来运行它并不重要。需要有一些权限控制,我们后面会回到这个问题。那么,它很有可能是一项付费服务。潜在的 DoS 攻击界面是非常广的。

总结一下,私人访问对于小群体用户来说更好。更低的存储要求,低使用成本(甚至无需付费),但也有运营成本。另一方面,公开访问模式的存储需求取决于用户的数量。也许能做到低成本。最后,我们会看到一个自由竞争的市场,价格最低、质量最好的服务能获得更大的市场。而且用户可以选择不止一个瞭望塔。

Max Hilebrand:低成本 vs. 高成本。低存储需求 vs. 高存储需求。你可以给我们一些大概的数字吗?

O(N) 的存储需求

存储需求将跟通道更新的次数高度一致。作为一个瞭望塔,你必须存储关于每一次通道更新的信息 —— 用户会把数据发送给你。假设用户会把加密的惩罚交易发送给你。这大概是 200 到 300 字节的量级,跟具体的设置有关,它是一笔两个输入、两个输出的隔离见证交易。不同模式下可能有所区别,但应该就在这两个数字之间。每次用户更新通道的时候(比如接收支付的时候),用户都会给你发送 200 字节,加上触发条件,大概是 60 字节,还有一些别的数据。所以在当前,每次通道更新你就要存储 300 到 400 字节。

Max Hilebrand:那么计算成本呢?能够在树莓派上完成吗,还是你很快就会需要一台强大的服务器电脑?

我认为是可以的。我就是用树莓派来做测试的。我已经在树莓派上测试我的实现有一段时间了。这取决于你的流量,以及你的树莓派应对这个流量的方式。此外,在你运行瞭望塔的时候,你还需要关心的是高可用心。应该做到你的用户不在线了,你也还能在线。这取决于你所提供的服务,如果你是为网络提供这项服务的,你可能必须使用更高可用性的东西,树莓派不是最佳选择。但我会在一台树莓派上运行。

至于运行这项服务的成本,用户需要花多少钱呢?理想情况下,这应该是你在通道中执行的支付的手续费的一小部分。问题在于,如果费用太高,使用瞭望塔就不值得了,尤其是你你的通道被打破的风险并不高的话。假如你是一个用户,你肯定也希望取得一个平衡:这项服务是有意义的,而且你支付得起。我没有得出应该对每次更新收取的费用。我的理解是,它应该是你为这笔支付所付的手续费的一小部分。

这也包括了存储的部分。这里的想法是,不论我们选择哪种模式,存储需求都跟通道更新的数量高度相关。我们可以尝试设计一种策略来兼容用户和瞭望塔的激励。我们后面会看到一些这样的例子。

利他主义的瞭望塔 vs. 营利的瞭望塔

最后,我们要聊聊成本的问题。如果你运行一个瞭望塔,你能做到完全不向用户收费吗?当然可以,但很有可能你的瞭望塔会遭受 DoS 攻击。尤其是某些人不希望它运行的时候。

你也可以收取较低的价格,我们就不说这个 “较低” 有多低了。只要你能合理定价,更多的流量就意味着更多的收入。其中的一些激励因素我在前面已经讲过了。比如,你可以让用户删除所有数据。假设你有一位用户关闭了一条通道,然后瞭望塔里面还留着跟这条通道有关的一些数据,这个瞭望塔是不知道相关通道的现状的,但用户知道。所以用户可以释放瞭望塔的一些存储空间,并使用这个空间来备份别的的通道。只要激励是一直的,你就可以为用户提供一个折扣,让用户帮忙删除一些永远不会再用上的信息。这取决于你是怎么运营的。

总结一下,私人访问和低存储需求是好的。但不收费的公开访问很可能会让你的瞭望塔过载。最后,如果你要收取少量费用,只要你收费合理,那就自然会有高存储需求。我们应该怎么将所有这一切汇总起来呢?

理想的瞭望塔(不含 Eltoo)

不涉及 Eltoo,理想的瞭望塔应该是高度隐私的(你发送的一切数据都是加密的)、公开可访问的(可以它可以作为一项服务)、具有不可爆破的 O(N) 存储需求(不论如何,你的存储需求总是 O(N))。那么,为了防止人们给你发送无用的数据从而攻击你,你能做什么呢?你应当如何定价,将攻击转化为利润?然后,运行成本应该很低。最后,皇冠上的明珠是可互通的瞭望塔 —— 不论你正在使用什么瞭望塔,也不论你在运行什么节点,只要有人提供服务,你就能用上。

BOLT13

这将我们带到了 BOLT13。BOLT13 是什么?它就是将所有这一切汇总起来。整个社区的多年的工作,希望开发出一种无论你在运行什么节点,都可以使用的瞭望塔。发现一个瞭望塔就可以使用它。假设你在运行 LND 节点,而某一个瞭望塔服务基于 c-lightning,那也没关系。如果你在使用 eclair 手机钱包,某人在运行一个 LND 瞭望塔,也没有关系。这就是我们的主要想法。那么,如何开发这样的协议,使之可延展、可以通过不同类型的服务呢?一套基础的服务,加上人们想要的其他服务,这样一来,只要一个瞭望塔能够提供你在寻找的服务,那就足够了。

通过监控模式实现隐私性

这是怎么做到的呢?我们来看看细节,看看数据加密和传输的具体设计。这个想法来自 Tadge(Dryja)在 2016 年米兰的 Scaling Bitcoin 大会上的提议。它背后的想法是非常直接的:直接使用来自承诺交易 ID 的某一些信息来加密惩罚交易。然后,还有一个从同一个承诺交易 ID 推导出来的定位器,或者说提示。将这两样东西发送给瞭望塔之后,瞭望塔就可以对发生在区块链上的承诺交易作出响应。就我所知,LND 的瞭望塔就是这样做的。这跟我们遵循的东西是一样的。

用户端

更具体来说,它是怎么工作的呢?首先,我们有一笔惩罚交易,许多字节。我们还有对应的承诺交易的 ID。我们要做的是取出承诺交易的前一半,16 个最重要的字节(MSB),作为定位器。然后,我们使用 CHACHA20POLY1305 加密算法,和从承诺交易 ID 中推导(哈希它)出的一个私钥,来加密惩罚交易。我们设定好加密算法、私钥和 IV(使用 0),就加密惩罚交易,获得一段密文。有了定位器和密文,我们就把它发送给瞭望塔。

瞭望塔端

从瞭望塔这边来看,我们需要做的事情是用每一个区块中的每一笔交易的 ID 生成一个定位器,也就是取得 16 个最大的字节,然后生成一个定位器。如果这个定位器在用户的约定列表中,我们就必须从同一个交易 ID 中生成密钥、将 IV 设为 0,然后解密属于这个约定的密文,以获得可能的一笔惩罚交易。然后,我们需要把惩罚交易发送到网络中、监控它以应对区块重组的情形、确保它被区块确认。可能在未来的版本中,惩罚交易会带有一个锚点输出,这样我们就能为它追加手续费。但现在讲这些就太复杂了。

这就是它的工作模式。

收入模式

那么,怎么营收呢?瞭望塔如何获得服务费?这里提出了三种办法,其中的两种,现在已经 有人使用了。一种是奖金模式,据我所知,LND 和 Electrum 就是用的这种。然后是按次付费的模式,和月费模式,这是 BLW 的做法。

奖金模式(bounty)是非常直接的。意思是,你在惩罚交易中放置一个给瞭望塔的输出。那么,当这个瞭望塔能够让这笔交易得到区块确认时,它自然就获得了通道的整个容量的一部分。

按次付费(per-appointment)则完全不同,它就像奖金模式的反面。在发送约定给瞭望塔之前,你要先付费。不论惩罚交易最后有没有用,你都要先付费。

最后是月费模式(subscription),它类似于按次付费,但不是细化到一次一次的约定。你是为一段时间的存储数据收费。我们看看这些方法的实际特性。

奖金模式

从用户的角度看,奖金模式当然好。用户只有在惩罚交易生效的时候才需要付费。这意味着,你知道瞭望塔一定会尽力,因为不尽力就得不到收入。

但对于瞭望塔来说,就不是那么好了,因为用户可以抢在瞭望塔前面发布惩罚交易;而且,用户可以发送跟通道无关、永远不会被触发的信息。然后,用户可以雇佣多个瞭望塔。可以搭便车 —— 用户可以雇佣整个网络的所有瞭望塔,但最后只会有一个瞭望塔能够得到支付。

从这里你就可以看出,这种模式是无法大规模应用的。大部分的服务端都会崩溃,可能只有一个能够胜出。

这种方法的主要好处是,瞭望塔可以使用 “子为父偿(CPFP)” 方法来为惩罚交易追加手续费。这是很棒的,这是我们要让它合理工作的一个东西。用户会在发送约定时设定手续费,但瞭望塔可以在事发时作出响应。如果手续费变化非常快,尤其是它在走高的话,如果我们没有类似的机制,瞭望塔就什么也做不了,惩罚交易也就无法得到区块确认了。最后,用户可以很容易轰炸瞭望塔:发送加密的、永远不会被触发的垃圾,然后塞爆瞭望塔。

按次收费

另一种办法是按次收费。这对瞭望塔来说更友好,但对用户来说不是很好。瞭望塔可以提前得到支付,但这意味着瞭望塔可以什么也不做。显然对用户不是好事。理性的用户可能只会雇佣少数的瞭望塔,因为需要提前支付。尝试爆破这些瞭望塔也需要付出代价。不能使用 CPFP,因为没有为瞭望塔准备的书市上。轰炸瞭望塔需要付出代价。每次更新通道状态、发送新的约定都需要支付费用,这可能会很麻烦,妖气是你跟瞭望塔并没有直接的通道的话。使用别的通道路由支付的话,可能会暴露你必须雇佣瞭望塔的事实。这显然并不理想。它很容易爆破,因为用户并没有进入成本。我不准备讨论这部分,但如果你有兴趣,我们后面再说。主要的意思是,如果用户可以直接发送信息给瞭望塔而不需要付出费用,那么就会出现一些麻烦的攻击,用户在瞭望塔中存储东西,并让瞭望塔执行大量没有实际价值的运算。

月费模式

月费模式跟按次收费很类似,但尽可能降低了后者的两种不利之处。支付次数更少,因此对双方来说都更容易。爆破瞭望塔更难,因为你哪怕用一次也得支付完整的月费。如果你想要制作很多分身来执行攻击,那么你需要为每一个分身支付一次月费。

月费 vs. 奖金

我们可以看到,月费和奖金都各有优缺点。我们应该使用哪一种呢?为什么不能同时使用两者?这里的想法是,我们可以结合两者的优点,形成一个非常可靠的方法:用户提前支付一小笔费用,然后将剩余的费用作为奖金。可以认为,用户一开始视为存储支付,然后,在瞭望塔可以执行相应的触发动作时,再额外支付。这使得我们可以形成不同的收费模式,我们可以再这几张幻灯片中看到。然后,理性的用户会仅仅雇佣少数瞭望塔。这跟月费模式是一样的。你也可以使用来自奖金模式的 CPFP。轰炸这样的瞭望塔也是有代价的。我们尽可能减少了支付的次数,并让爆破的代价变得更高。这还谈不上理想,但这是最接近理想的东西。

用户身份验证

如果使用月费模式,你就需要某种身份验证措施,来证明你已经为服务支付了费用。这可以帮助放置资源滥用。有几种方式可以做到。用户可以使用节点的私钥来签名消息,以证明节点的身份。这是跟节点 ID 绑定的,所以我们可能想要避免使用这种方法。你也可以使用一个临时密钥来做。你生成一个临时公钥并跟瞭望塔通信,然后就实现了相同的目标,而无需揭晓用户身份的任何信息,所以隐私性更好。你还有使用 LSAT 或类似方法的身份验证。在中本聪之眼中,我们用到了非常相似的东西,发送签名消息,但我们所用的 API 跟 LSAT 的工作原理非常相似。最后,只要你能知道谁付了钱,你就建立了收费模式,可以接收数据,并基于这些数据保持监控。这都很好。

插件

这个 BOLT 还给插件预留了空间。至少我们已经提出了一个。你可以在这里假如不少东西。在当前的版本中,有一个可追责性插件,可以用来确保瞭望塔做了承诺要做的事。如果 TA 能响应通道破环,那就没什么问题。然后你可以在此基础上建立一些东西,比如声誉系统:你可以证明某一个瞭望塔并没有信守承诺,然后告诉社区:“请不要使用这个服务,因为他们并没有如约监控我的通道”。它还可以用在完全不同的东西上,比如备份。我认为,Christian(Decker)会在另外一个时间讲解这个。想法其实差不多,你把一些加密的数据发送给瞭望塔,但瞭望塔并不知道这里面是什么东西;你同时发送了触发器,但这个触发器不必是有效的。这也是为什么我们要将存储的费用和触发的费用分别收取。最后,你可以延伸触发器的逻辑,跟其他东西一起工作。最近有一些关于 “保险柜” 的讨论。在 Revault 提议中,他们也需要某种监控服务,来保证作出响应。保险柜的触发器跟闪电通道的触发器有所不同,但你可以在密文中放入额外的信息,只要这些信息不是裸数据。你可以使用富格式数据。现在这些还没有定义,但你可以使用瞭望塔能够解析的带格式数据:“我收到的数据是为了这类响应而准备的。如果我已经同意了执行这类工作,我就应该做到。”

代码当前的状态

中本聪之眼当前的代码状态时,我们已经有了一个单独的、免费的、开源的瞭望塔,是 c-lightning 节点的一个插件,是在两周前放出的。现在它是基于订阅模式的,但是是免费的。月费模式会很快推出,至于是多快,在我们这个圈子里,你懂的。我们在积极开发,以推出月费模式。这里的设计理念是,我们想开发一个模块化的设计。我们希望直至多种支付模式,让运营者可以自选启用和停用。举个例子,你想使用 BTCPay Server 来执行所有的支付逻辑,也应该能做到。如果你想使用闪电网络,并自己管理所用的 HTLC,也可以。但工作还在进行中。现在,通信是通过使用 HTTPS 的 REST API 来实现的。它甚至可以用来实现开箱即用的备份,但它本意不是为了备份。我希望加入更多东西,以给予用户更多保证:备份就在那里。但你现在也可以使用它来备份,如果你想的话。然后,还有一些实例需要测试,主网和测试网什么的。

参考

以上就是我的演讲。我在这里列举了一些资源,包括我的代码本身、BOLT13,想看的话可以自己看看。我们也在积极寻找对这两样东西的反馈,请不吝赐教。还有可以下载的 c-lightning 插件,把它放到你的 c-lightning 插件文件夹,然后马上就可以使用了。它是用 Python 写得,跟代码的其余部分一样。它还带有说明书(README),但任何问题都可以自由提出。

如果你希望运行它和测试在线的示例,你可以运行自己的实例;但如果你只是想试用,它会运行在 lightning-cli registertower towerid@host:port,这两个实例的 ID 和主机分别是:

问答

Max Hillebrand:一个跟隐私性有关的问题。在网络层面上,或者说在通信层面上,比如说,用户需要使用 IP 还是 clearnet、需要一直使用相同的连接方式吗?这会导致去匿名化吗?

答:某用户正在给某 IP 发送信息的事情一定会泄露。然后,如果用户一直在使用相同的 IP 来运行节点,那么很有可能你能将所有来自该节点的信息都去匿名化。理想状态是(尤其是对 HTTP 来说)使用 Tor 或类似的协议来运行。如果你在闪电网络上运行,那也是你可以使用的另一种通信层,而且,举例来说,LND 的瞭望塔也是这么做的,那就没有这个问题。你必须尝试解耦它们,不然的话,你在应用层做了可以做的一切来保护隐私,但随后就在网络层泄露了信息。

Max Hillebrand:另一个问题是,你指出了支付方式是非常关键的。如果你在闪电网络上向瞭望塔发起了一笔常规支付,这笔支付本身就是一次通道更新,那你又必须再次雇佣瞭望塔来监控这个承诺交易。这不是一个死循环吗?

答:这是非常棘手的。这是我来来去去、反复检查的问题。你可以雇佣另一个瞭望塔,但这又会产生一次通道更新,也就是问题绕一圈又会回来。在这里要解决的是给通道的支付手段问题。只要没出什么问题、瞭望塔没有尝试欺诈你给瞭望塔的支付,你将总是拥有具体的支付。

Jeff Gallas:Javier 说他几天前安装好了 “中本聪之眼”,而且让它跑起来了。还有一些即时的反馈。Kasso 似乎只有一个泛泛的理解,需要花点时间才能深入。在我们一开始宣布这场讨论时,Reddit 上有一个评论:“如果你预期自己无法做到大部分时间都在线,你就不应该公开你自己的通道。当其他用户尝试使用你的通道来转发支付是,他们将需要花费更多时间来发现可用的路径。如果你只想使用偶尔在线的节点,使用不公开的通道,对大家都好。”我想,问题在于,从特定的角度看,瞭望塔的具体应用场景在哪?谁会使用瞭望塔?它只是一种你下线时候的备份方案吗?如果你只有手机节点、一两条通道、偶尔发起支付,你会使用它吗?它在全景图中究竟扮演什么角色?

答:我认为瞭望塔会有多个应用场景。手机钱包显然是其中之一。如果我们认为大规模采用会发生,无论我们喜不喜欢,都不可能让每个使用闪电网络的人都运行一个全节点。 我希望每个人都运行全节点,但我不认为这会发生。你在大部分时间里都处在风险之中,因为你的手机节点只有在你打开 app 的使用才在线,别的时候你是离线的。或者,app 会要求你时不时打开它,以更新信息、防止欺诈。但这样做是在打扰用户,从用户体验上来说不是个好主意。所以从我的角度看,手机钱包显然是一个应用场景。至于非手机的钱包,我认为瞭望塔也有用。有两个作用。第一个是,若是你的数据损坏了,该怎么办呢?我们假设你没有备份、你的节点损坏了。那你就一无所有了:你什么也做不了。你可以向通道对手哭惨,希望拿回所有的信息,但这要看对手的人品。如果你的对手就是不想帮你,反而欺诈你,你能怎么办呢?而瞭望塔的好处之一在于,如果我们大量使用瞭望塔,使用这套协议,你可以做到的一件事就是减少争议的时间。现在,一个用户体验问题是,每次你不得不强制关闭通道的时候,你都必须等待很长时间,这个时间窗口是用来防止人们欺诈的。但如果你确定瞭望塔服务可以帮助你,你就可以缩短时间锁的长度。我不是说你可以高枕无忧,只是说你可以缩短时间,因为即使你不在线,别人也可以帮你提供数据。即使在最坏情况下,你的用户体验也会好一些。所以,你是将一个问题转化成另一个问题:在不使用瞭望塔的时候,你的全节点即使短时间离线,也可能会出问题;而使用了瞭望塔,最坏的情况,也不过是你必须等待几天。

Max Hillebrand:那 HTLC 被发到链上去的时候会怎么样呢?这时候瞭望塔会怎么做?

答:当前的方法还没覆盖 HTLC,因为 HTLC 当前的商讨方式。瞭望塔缺乏触发 HTLC 成功交易和超时交易所需的信息。实际上这是一个很好的问题,因为我们最近也一直在讨论。你可以使用多种方法解决这个问题。比如,你可以将这些信息连同密文一起发给瞭望塔。这意味着每次你要更新 HTLC 的时候,首先,数据包都会变得更大,而且,你可能需要在瞭望塔处更新信息。你可以想象这有多么麻烦。我最近在思考的另一个事情是,对承诺交易和惩罚交易能用的模式,对 HTLC 和 HTLC 的惩罚分支也有用。你可以使用 HTLC 交易的哈希值加密收回 HTLC 价值的交易、发送给瞭望塔。然后,当瞭望塔看到了 HTLC 交易,就可以响应。但 HTLC 的价值可能远远小于通道中的其余部分的资金,这样做值得吗?我不能断定。我们已经讨论了这些,但没有很好的解决方案,因为太多悬而未决的问题了。

Jeff Gallas:一个来自 Mattermostr 的评论:“我会主张,在你跟瞭望塔开启一条公开通道的时候,他可能有激励不对通道破坏作出响应。因为他知道你离线了、无法自己作出响应,所以他会尝试欺诈你。你永远不该依赖于单一瞭望塔。”你怎么看呢?

答:显然你不应该信任单个瞭望塔。我反正永远不会这么做。回到瞭望塔尝试欺诈用户的情形,如果用户一直在给瞭望塔支付,那对瞭望塔来说,余额是不断积累的,用户的余额则是不断下降的。如果我们假设他们之间没有双向通道,或者瞭望塔不会通过通道给用户支付,那么瞭望塔应该没有动机欺诈用户,因为最新的状态总是给他分配最多资金的。如果不是这样的花,当然,你作为瞭望塔,你可以给用户支付,然后尝试欺诈。尤其是没有别人能应对的时候。这将我们引向更多的问题,比如,我们应该如何给瞭望塔支付。我们不是必须通过闪电网络来给瞭望塔支付。你可以这么做,这是办法之一,但你也可以通过别的方法来支付。法币或者链上交易。

Max Hillebrand:你之前提到这里没考虑 Eltoo。Taproot 和 Eltoo 会改变这一切吗?

答:Eltoo 会完全改变存储的复杂度。你不需要存储那么多信息。这意味着,运行一个瞭望塔会变得非常便宜,意味着可能更多人会运行它,作为许多用户的中介。这时候,攻击将减少,因为许多攻击都基于耗尽存储空间。但它没有改变的是,你需要高可用性。如果瞭望塔不能及时响应,那还是会出问题。运行瞭望塔会变得更简单。你发送的大部分信息可能都是无用的。只要你能提供信息给瞭望塔、使其能建构出要做的事情,而不是将所有的裸信息给他,那就是更好的。数据更少,复杂性就更小。它跟我一开始引用的托管式解决方案很像。我一直在讨论非托管,但也有一些人说,为什么我要运行一个只为我自己工作的瞭望塔呢?为什么我必须自己解决这个问题?我可以把一个密钥分享给瞭望塔,然后给他们发送信息,让他们做完剩下的事情,不行吗?当然可以,你可以这样做。你复制了自己的私钥,意味着你要承担的、因为私钥被放在热存储中而遭劫持的风险就更高。但这都取决于你自己。我们的想法只是,要能让瞭望塔成为一项服务。有了 Eltoo,你可以直接发送密钥,密钥和其它瞭望塔可用来建构交易的信息。需要存储的信息的数量可以大大减少。

Jeff Gallas:Michael(Folkson)提了好多个问题。你已经回答了他的其中一个问题,就是在尝试提供瞭望塔服务之前应该先循行自己的瞭望塔。那么,这个瞭望塔 BOLT 成熟了吗?c-lightning 也可以使用不同的瞭望塔设计/插件 吧?你是如何将瞭望塔与 c-lightning 结合起来的?

答:当然,做别的事情之前一定要先运行好自己的。我的意见是 —— 你们不必同意 —— 不论你是为了自己还是为了别人,我会使用隐私模式,而不是复制私钥的方法。这意味着你的存储此根本和存储需求都会变得更高。但这也意味着,如果你的瞭望塔被爆破了,也不会有数据泄露、不会有私钥泄露。这还意味着,根据你的设置,你的瞭望塔不必像你的节点或者你的冷存储一样保护起来。这取决于你自己。我总是认为,更少泄露重要信息的故障,总是一件好事。你当然应该先运行自己的瞭望塔,然后再尝试为别人运行。至于 BOLT 13 以及为 c-lightning 设计的钩子程序,我们迭代了两版 BOLT13,显然还没结束。比如,我们必须开发完整的通信部分。消息类型还没定义,所以如果你没法实现它,因为有些东西我们还没定义好。还有一些围绕它的讨论,尤其是因为例外情形和攻击。我跟 c-lightning 和 LND 团队有很多讨论。只要这些讨论再继续,我们就一定能到达终点。就我所知,这个过程不像 BIP。我们是每隔一段时间,比如一个月,社区的一部分人就聚集起来讨论问题并推进。至于多长时间才能让人们接受它,我没有概念。c-lightning 的钩子程序是 Christian 的工作。我使用 c-lightning 的插件系统为中本聪之眼开发了一个插件。他们提供的是一个接口,给你每一次更新的承诺交易的 ID 和对应的惩罚交易。然后,一旦你获得了这些信息,怎么用就看你自己了。我猜,你可以用这个插件来建立闪电网络的通信。既然如此,你应该也很容易能开发出一个插件跟一个 LND 瞭望塔通信(举个例子)。只要你遵循这个方法。有多容易呢?我觉得应该是非常容易的。c-lightning 的插件系统真的很棒。它有针对不同语言的绑定。Python 语言的支持很棒。我花了不少时间,因为我两边都要开发,服务端和用户端。但说实话,并不难。使用 c-lightning 的插件系统甚至比你上手一个不熟悉的系统还要容易。

Jeff Gallas:还有一些来自 webprogrammer 的问题。他问,你需要监控和解密多少惩罚交易呢?树莓派 4 能完成吗?就是运行一个瞭望塔的硬件要求。

答:我必须对我的树莓派做压力测试,才能知道它的极限。坦白说,我还没有数字,所以没法断定 “只需 500 MB 和 Core 就可以了” 之类的。既然很多人这么问,我就统计一下,然后发到推特上。根据我的经验,它并不会消耗什么资源。

Jeff Gallas:webprogrammer 还问,瞭望塔会使用闪电网络的 gossip 协议来公告自己的服务吗?

答:这是一个很棒的问题,也是我自己想问的。在你开发这样的东西的时候,对等节点发现总是非常复杂的。就跟节点连接到闪电网络的问题一样。你是应该随机选择一个节点呢?还是应该想连哪个就连哪个?问题是一样的。当前,这个协议还没有发现服务的部分。我在这个 BOLT 的第一版想过这个问题,但到第二版也还没有做进去,因为一些讨论,有人喜欢,也有人不喜欢。技术上确实是用 gossip。我们应该使用 gossip 吗?我还挺想讨论这个问题的。请在闪电网络开发者邮件组中回复,或开启一个讨论。我没有答案。瞭望塔是这样一种东西,即使可以用在闪电网络中,它也不依赖于闪电网络。你只要开始看它,就会觉得非常有意思。我们当前的实现并不依赖于在闪电网络中实现的东西。BOLT11 发票的 bech32 编码,就是唯一用到闪电网络的地方了。消息签名的办法跟 LND 和 c-lightning 是一样的,但这只是为了兼容。关键是瞭望塔只观察区块链。它检查区块并寻找区块中的信息。我们想要运用闪电网络吗?我认为我们可以,也应该运用。但我们最后会这么做吗?这就要交给社区来决定了。这不是由我来决定的。虽然我也尝试推进了,但这不是我要做的唯一一件事。我希望人们能参与进来,谢谢了!

Max Hillebrand:如你前面所说的,瞭望塔的整个概念并不是跟闪电网络绑定的。它是更加通用的。如果瞭望塔只是一个通用的数据存储,它是否有办法证明自己依然保存着用户的数据?它能不能忘记或者删除数据?

答:这是一个重要的问题。我们计划在这个 BOLT 中加入一个东西。我在几个月前的 Advancing Bitcoin 上跟 ZmnSCPxj 讨论过这个问题。需求是你可以证明某个数据依然在瞭望塔中,而且可以证明瞭望塔能够对触发器作出响应。前者很容易,后者就更加棘手。为了证明瞭望塔依然存储着你的信息,你可以查询它。我们设计了一种信息可以向塔请求信息,然后瞭望塔会回复你。瞭望塔可以作为一种开箱即用的备份服务。你先提供信息,然后再查询。你自己有解密密钥,这就够了。现在的 BOLT 还没有这部分,但我希望加入它。这是打探的第一种方法。你还可以时不时发送请求,以确认信息还在那里。事实上,信息还在那里,并不意味着瞭望塔会作出响应。但至少,表明瞭望塔还保存着它。这是第一步。你总是可以通过一些只有该瞭望塔才有的假工作,来检查它会不会响应。如果瞭望塔影响了,那就没什么问题。但如果它不响应,就说明它不会被触发了。我希望它变得更简单一些。你发送一些信息到某地,这些信息又因为某事而触发。Joost Jager 有一个非常棒的想法,关于如何持续为服务端支付,以保证你只需在他们还保存着信息的时候付费。你可以制作一种条件式支付,跟希望瞭望塔保存的数据绑定。举例来说,我以前发送给你的某个约定的哈希值。你创建一个 HTLC,假设对方拥有原像。最后,你可以已经支付了月费,但瞭望塔没有解开哈希谜题,这样,当你下次想支付月费的时候,瞭望塔就没法接受了,因为他们没有那段信息。这是非常简单的,而且也是我会考虑加入这个 BOLT 的东西。

(完)

声明:该文观点仅代表作者本人,与炒币网无关。炒币网系信息发布平台,仅提供信息存储空间服务。对所包含内容的准确性、可靠性或者完整性不提供任何明示或暗示的保证,并不对文章观点负责。 提示:投资有风险,入市须谨慎。本资讯仅供参阅,不作为投资理财建议。

发表评论

登录后才能评论