干货 | 闪电 VS 雷电:瞭望塔模式(中):瞭望塔中的隐私保护与可扩展性

Ajian   |     |   709 次阅读

闪电 vs. 雷电:瞭望塔可拓展吗? (上):模式及运营成本


本文我们将讨论扩展瞭望塔服务以及提升闪电网络、雷电网络隐私保护能力的几种不同的方法。

免责声明:虽然我持有 比特币(BTC),以太币(ETH),比特币现金(BCH),雷电网络代币(RDN)等加密货币,但我的投资组合很分散, 因此我没有任何经济动机为任何加密货币当托。我希望能够看到许多不同扩容方案的项目互相竞争,同时用户能够自由选择支付方案。如果你有不同立场,没有关系,我对此毫无意见并愿意与你继续探讨相关话题。感谢点对点(P2P) OTC 交易平台 LocalEthereum 对本文的支持。

背景介绍

首先,我要感谢 Reddit 这个社区,大家能够公开地讨论各种主题。上一篇文章在这 4 个子话题的主页推送,收获了一些非常棒的讨论。非常感谢!

其次,雷电网络的 “监察服务” 并不是最终名称,未来有可能会变化,因此在没有具体指明的情况下(例如:“闪电网络瞭望塔” 或 “雷电网络监察服务”),本文将使用 “瞭望塔” 来指代闪电网络与雷电网络的具体实现。

第三,如果你第一次接触瞭望塔这个概念,我建议你先阅读上一篇文章,其中讲述了:为什么瞭望塔对于链下扩容非常重要、瞭望塔服务运行原理、闪电网络与雷电网络实现之间的差异、描述了两种主流瞭望塔策略、瞭望塔服务运营(和资金)成本并概述了主要可扩展性挑战。

第四,我们还将使用到以下两个术语:

  1. 业务导向型瞭望塔指的是能够将同一通道或账户的所有状态更新链接在一起的瞭望塔
  2. 隐私导向型瞭望塔指的是不能将同一通道或账户的所有状态更新链接在一起的瞭望塔

有关这些模型的更多细节,请阅读上一篇文章

插播:有些人问我为什么使用 “业务(business) VS 隐私(privacy)” 这个词来表述瞭望塔服务的不同侧重。因为企业若想增加收入并且在竞争中生存下来,不关注隐私的瞭望塔服务提供方有更多途径来增加收入并降低运营成本。因此,从企业生存发展角度,他们的方案可行性更高。

关键问题

在广泛采用瞭望塔服务之前,社区需要解决三个主要问题:

  • 隐私
  • 可扩展性
  • 可追责性

在本文中,我们将讨论针对隐私与可扩展性的不同解决方案,并讨论它们的不足。

和往常一样,你不必认可本文描述的所有观点,但相信你读完会觉得不无裨益,如果你有什么想要分享讨论的,请随时参与进来。

隐私

我确信瞭望塔服务是闪电网络和雷电网络隐私保护的瓶颈所在,因为如果瞭望塔能够将交易关联起来,那么其他隐私保护功能便没有什么价值了。

普遍观点认为,相比于链上交易,链下交易仍具有更快速、更便宜、隐私保护更强的特点。但是,这种思维模式很难进行全球推广,因为若要全球推广,实际面临的问题就是 “它现在比 Visa、支付宝、微信、PayTM 更好么?或者换句话说,它能够永远存在么?”

此外,链下交易可能并不能更好地保护隐私,因为用户能够在每次链上交易的时候使用一个新的链上地址,像 LocalEthereum 等钱包或服务提供方都会默认提供这一功能。然而,链下交易仅能与唯一一个链上地址或通道关联。

让我们一起来看一些可以略微提升隐私保护能力解决方案。

1. 交易时间模糊化

适用范围:闪电网络 & 雷电网络

用户向瞭望塔发送状态更新之前,能够通过引入一些随机延迟(例如:几秒钟或几分钟)来将交易时间模糊化,从而增加流量分析成本。

然而,如果交易的对手方会不加任何延迟就将通道更新发送给他的瞭望塔的话,这种办法就行不通了,因为可能会有很大型的瞭望塔网络,它们将参与大规模金融监管,以遵守当地及国际法律,像银行和其他金融机构一样,必须向有关部门透露有关其客户的所有信息。在协议层面强行增加延迟可能有助于缓解这个问题,但是这样做会显得很奇怪。

注意:在业务导向型瞭望塔设计中,瞭望塔能够明确知道它们目前监听的具体是哪些通道,因此它们清楚每个通道的所有参与方。

下面的例子中,Bob 没有任何延迟地发送他的状态更新,但 Alice 尝试将交易时间模糊化:

此外,将状态更新延迟更长时间(例如几个小时)会让用户体验更差,因为为了确保交易安全,用户必须保持在线,直到状态更新发送出去并且收到一个确认信息。因此,要确定用户的时区以及识别用户是否使用唯一指纹或经常更换时区仍然相当容易。

插播:模糊化交易时间能够增强隐私导向型瞭望塔隐私保护能力,因为隐私导向型瞭望塔不能将相同通道或账户的状态更新相关联。然而,由于运营需求不断上涨但盈利模式有限,隐私导向型瞭望塔能否大规模推广仍不清楚。

在面向隐私的点对点(P2P)、自主保管且端到端加密的 LocalEthereum 平台上购买与出售以太币(ETH)。你可以创建一个新的密码保护账户,或者使用你最喜欢的钱包(例如:Ledger、MetaMask)或手机应用(像 imToken)登录。

2. 在不同瞭望塔之间循环更新状态

适用范围:闪电网络

用户能够在每笔链下交易完成之后,通过向多个瞭望塔中的随机一个发送他的状态更新的方式,实现瞭望塔间循环。

5

总之,这是一个不错的功能,但是在现代社会它并不能很大程度地提升隐私保护能力。因为在实际应用当中,我们应该将多个瞭望塔视作一个大的监听整个网络活动的实体。

6

正如上面所提到的,瞭望塔服务节点很可能会形成一个服从监管的大型瞭望塔网络,像银行一样参与大规模的金融监管。一些瞭望塔最初可能由独立实体控制,但最终会加入监管网络,就像最近 ShapeShift 等加密交易所一样。

-图源:@bitconner -

此外,瞭望塔循环会降低用户体验,因为用户必须发现多个瞭望塔节点,并且可能要多次支付。为了方便起见,大多数外行会仅仅选择一个特定的瞭望塔节点。因此,由于默认设置问题,瞭望塔循只能作为一小部分黑客才会使用的高级工具。

我们可以在协议层强制使用多个瞭望塔节点,但是大瞭望塔可以提供特定的服务来伪装成多个瞭望塔节点。

请注意,此解决方案并不适用于当前的雷电网络,因为在雷电网络中,用户是通过公共聊天室将状态更新信息发送给所有经注册的监察服务节点的。

还有许多其他的方法也使用了多瞭望塔节点(例如:Celer 网络),但我们留待后文加以探讨

3. 将不同用户的状态更新绑定在一起

适用范围:闪电网络(eltoo 升级后适用,但效果有限) & 雷电网络(效果有限)

另一种方式是使用混币服务的概念。

CoinJoin (混币)是一种免信任的方法,可以将多个消费者的比特币支付组合到一笔交易当中,从而使得外部观察者更难以确定哪个消费者向哪个或哪些接收方付款。wiki

与混币服务类似,不同用户的状态更新理论上能够以一种免信任的方式绑定在一起,并以一段数据的形式发送给瞭望塔。

挑战:

  • 目前不清楚如何以免信任的方式实现该功能。很大程度上,用户仍需信任某一服务/状态更新参与方。然而,这个参与方可能泄露用户隐私。
  • 如果该功能的具体实现使得用户在收到瞭望塔成功接收数据的确认前,需要保持在线,就会造成用户体验较差的问题。
  • 该功能应该是一种默认功能,否则外行就不会使用该功能。
  • 在业务导向型设计中(例如:目前雷电网络的方案),只能将交易时间模糊化,而不能将状态更新所有者模糊化。

4. 状态更新路由

适用范围:闪电网络(eltoo 升级后适用,但效果有限) & 雷电网络(效果有限)

另一种非常有趣的方式是通过类似路由多跳转发的方式,将状态更新发送给瞭望塔。

然而,这个方案面临着很多挑战:

  • Alice 需要能够通过 Bob 和 Carol 将一个加密数据包发送给瞭望塔节点(使用 Tor 仅能屏蔽 IP,但并不够)。理想情况下,所有状态更新应该看起来属于最后一跳(Carol)。
  • 如果瞭望塔对存储或接收状态更新收费(有关业务模型的更多内容,请阅读下一篇文章),Carol 应该能够替 Alice 支付瞭望塔节点的服务费。
  • Bob 和 Carol 应该能够因提供数据转移服务而向 Alice 获取一定的费用,以激励他们提供这类服务。
  • Alice 需要获取到瞭望塔已经收到状态更新的确认信息。
  • 该路由算法应该是免信任的,所以实现思路并不清晰。
  • 该功能应该是一种默认功能,否则外行就不会使用该功能。
  • 即便能够正确地实现,它依旧会降低用户体验、增加受攻击面并且增加收费的中继节点。
  • 业务导向型瞭望塔(例如:目前雷电网络的方案)清楚正在检测的是哪条通道,并且也只知道状态更新的实际拥有者是谁,因此仍是只有交易时间可以模糊化。

5. 制造大量的噪声(虚假路由)

适用范围:闪电网络 & 雷电网络(无 PFS —— path-finding service,寻路服务)

用户可以通过发送大量虚假小额交易或向瞭望塔发送虚假状态更新的方式来隐藏他的真实交易,模仿高频经济活动或路由过程。

问题:

  • 即便隐私导向型瞭望塔能够存储更多的状态更新,可扩展性依旧是一个等待解决的问题。提供隐私导向型方案时,瞭望塔可以为状态储存向账户收费(适用于哪种方案?),但这样的话,由于需要花费真金白银,外行人就不会使用这个隐私功能了。
  • 创建大量虚假交易将大幅度增加带宽负担,因此有可扩展性的问题。
  • 如果对方使用寻路服务(PFS),那么发送虚假交易就没有意义了,因为 PFS 提供方知道哪些交易是真实交易。

因此,存在真实用例么?

业务导向型瞭望塔(RDN 或 eltoo)的隐私保护水平能够通过在协议层面强制用户发送小额噪声交易的方式来提升。由于瞭望塔只存储最新的状态更新,数据存储需求并不会显著增加。带宽负担仍然是一个比较严重的问题;对家若使用寻路服务,将消除发送噪声交易带来的隐私保护效果。

关于隐私的几点思考

到目前为止,这些都不是根本的解决方案,上面所描述的所有方法都有它们的缺点,如果我们在基础层已经有了较好的隐私保护,那么它们更多只是锦上添花,而非雪中送炭。然而,如果在基础层瞭望塔能够将同一通道或账户的所有状态更新关联起来,那么我们就无法大幅度提升隐私保护水平了。

可扩展性

如果闪电网络没有成为一个高度集中的中心辐射网络,那么每笔交易都将经过多跳转发,因此每笔交易都有很多节点发送状态更新给瞭望塔。

-二次方增长。图源:暸望塔可以扩展嘛?-

对于无法将相同通道或账户的状态更新链接到一起的隐私导向型暸望塔,其数据存储量将以二次函数形式增长。

接下来我们一起看看针对这个问题不同的解决方法以及它们各自的缺点吧。

1. 仅存储最后的状态更新(业务导向型)

适合:闪电网络(eltoo)& 雷电网络(当前实现)

最简单的解决方案是将同一个通道或者账户的所有状态更新链接到一起,只存储最后的状态更新(余额校验)。我们将这称作 “业务导向方法” ,你可以在上一篇文章中了解更多细节。

虽然日后可能作出改变,但是雷电网络监控服务的当前设计遵循这种方法,闪电网络暸望塔在 eltoo 实施后将通过经济激励切换到该模式,这需要 BIP 118 启动,并且还需要和 schnorr 一起部署,据 Christian Decker 说,这些功能都需要 seguito 脚本。

12

业务导向模式更易于扩展,因为它允许暸望塔摆脱庞大的数据库并专注于增加带宽容量。此外,暸望塔可以引入基于账户的系统,这是最可行的商业模式。

不幸的是,这种方式意味着非常低的隐私性,因为暸望塔有可能将所有交易与某些通道、地址、付费账户等关联起来。这与大多数合法中心化支付系统的运作方式基本类似。

2. 不发送包含通道中大比例资金的状态更新

适合:闪电网络 & 雷电网络

用户不需要将分配给他自己全部或者大多数资产的状态更新发送给暸望塔,因为他的交易对手无法从有这些状态的用户处窃取资产,或者说交易对手作弊的风险/回报比率非常差,例如,他将承担价值 90 美元的风险去盗取 10 美元,因此,当资产丢失风险非常低时,用户付费给暸望塔以存储这些状态更新的成本就太高了。

这种方法有助于将存储状态更新的数据库削减 5-20%,但是由于用户可以出于安全原因调整设置,它将会引入某些安全性风险并过度复杂化用户体验。此外,非专业人士为了省钱而选择的设置会严重破坏安全性。

另外,用户仍然需要发送一些给他自己分配大部分资产的状态更新给暸望塔,因为,如果所有人都对这种大额资金转移不太上心,那么对手方作弊的成功率就会变得很高(此中的博弈关系非常巧妙)。

3. 一段时间后删除状态更新(例如,1年后)

适合:闪电网络(非 eltoo)

即使通道关闭后,隐私导向的暸望塔仍然需要存储从该通道所有者处接收到的所有状态更新,这是完全不现实的。

一种解决办法是,暸望塔删除旧的状态更新(例如,1年前的旧数据),客户端将负责为还开着的通道重新发送状态更新。

14

遗憾的是,这种方法将仅删除已经关闭的通道的状态更新,因此不能实现显著的数据库 “瘦身” ,因为除非有强有力的经济激励,大多数通道很少被关闭。请记住,任何鼓励关闭旧的、“重的”通道的激励都将会增加链上压力,并且很有可能需要低隐私程度的基于订阅的系统。

与此同时,该解决方案将降低用户体验,因为用户将必须存储旧的状态并在数据过期之后重新发送这些数据。此外,这种方法将引入许多不同的大规模作弊场景,例如:

如果 Bob 丢失了他的手机(或者入狱/昏迷等等),他仍然可以通过恢复种子恢复他的链上资产,但是他没有可以关闭通道的最终状态,因此他必须一直等待,直到他的交易对手知道暸望塔会阻止作弊行为后单方面关闭通道。不幸的是,一年后,他存储在暸望塔内的所有的状态更新都将被删除,因此,大型的数据中心可以针对(超过1年)不活跃的通道作弊,风险/回报比率非常吸引人(例如:承担价值 $10 的风险去盗取 $100)。当然,Bob 可以尝试通过暸望塔恢复以前的状态数据并在一定时间后将这些数据重新发送给暸望塔,但是恢复状态更新意味着该基于账户的系统隐私性较低。Bob 同样可以在每次链下交易后将他的状态更新存储到云端,这也带来很多隐私相关的问题。

4. 让用户请求删除旧的数据

适合:闪电网络(非 eltoo )

另一种解决方法是,在关闭通道后,用户向暸望塔发送请求,其中包含可以安全删除的之前的状态更新列表。他甚至可以在一段时间内将密钥分割在多个请求中发送,并通过 Tor 路由以获取更多隐私保护。

这种方法可以帮助暸望塔略微修剪数据库,但是也存在许多问题:

  • 用户必须有相应的经济激励才会关闭旧的、“重的” 通道并发送请求删除旧的状态更新,因此将会有一个复杂的、低隐私程度的、基于账户的货币系统根据用户存储的状态多少定期向他们收取费用。例如,很多以前的推文,现在既没有人浏览也没有太多价值,用户完全可以删除掉,但是大多数用户都不会这么做。为什么呢?因为没有相应的经济激励推动他们这样做。
  • 假设用户必须定期为他所存储的所有状态更新数据支付一定费用。如果用户弄丢了保存着所有数据的设备那该怎么办?他可以通过恢复种子恢复他的资产(如果他有备份助记词),但是他无法向暸望塔发送删除之前状态的请求,即使他所有的通道最后都要被交易对手关闭。因此他必须转移到另一个暸望塔或者在原来的暸望塔建立一个新的账户,但是由于他不能自己关闭通道,他仍然需要向之前的暸望塔支付全额费用,直到很久以后,他所有的通道都被交易对手关闭。
  • 该方法即使正常运行,也无法解决所有问题,因为只有关闭了的通道的状态更新会被删除,因此暸望塔将必须存储所有还未关闭通道的状态更新。
  • 此外,这一特性将会增加链上压力,因为用户将更频繁的关闭、打开通道。

5. 科技的进一步发展

现在,大家可能认为隐私导向型暸望塔注定失败,但是我们不能忽视科技的发展

科技通过提供价格一样但是更高效的软/硬件来抵消收益递减规律,从而降低运营成本。但是,运营要求的二次增长需要被替换成线性增长,否则科技的创新将无法跟上不断增长的运营要求。

16

-线性增长。图源:暸望塔可以扩展嘛?-

不幸的是,为了做到这一点,隐私导向型暸望塔将不得不引入隐私程度非常低的基于账户的系统以限制用户群,因此我们有点小麻烦了。

总结一下:

  • 暸望塔可以引入基于账户的系统
  • 限制用户数量(例如:最多只支持 10 万名用户)
  • 数据存储要求将线性增加
  • 升级硬件(例如:每年)以保证较低的运营成本
  • 偶尔通过软件更新的方式降低运营成本

但是,如果使用低隐私程度的基于账户的系统,以隐私为导向的状态更新管理方法又有什么意义呢?

所有的一切看起来都有点糟糕,还有更好的解决方法吗?

混合模型

下面来看一些结合了不同方法的混合模型。

1. 限制接收的状态更新量

适用范围:闪电网络

上文中我们讨论了面向隐私的瞭望塔可以通过引入一个低隐私的基于账户的系统来限制其用户基础,从而将运营要求的二次增长替换为线性增长。

然而,存在另一种更加面向隐私的方法可以限制不断增长的数据存储要求:达到一定数量后便不再从任何用户接收任何状态更新,或者为所有客户设置每日/每月限制。

可能至少有两种不同的实现方式:

  • 对每一个新的状态更新,用户都 ping 一次瞭望塔
  • 用户初始化一个会话并且预定多个“存储槽”,这些“存储槽”可用来存储状态更新

如果一个瞭望塔拒绝再接收状态更新,那么用户可以将状态更新发送给另一个瞭望塔。

17

这是一种有趣的方法,可以让瞭望塔有能力限制其运营成本,但也存在责任追究、用户体验和变现方案的问题。因为基于帐户的系统是最可行的模式,我们将在下一篇文章中讨论。

混合模型可以通过以下额外的特征进行扩展:

  • 用户可以发送一个请求去删除属于已经关闭通道的旧状态更新(上文已经描述过了)。
  • 用户不需要向瞭望塔发送分配了大比例资金给某一用户的状态更小(上文已经描述过了)。

附注:限制接收的状态更新量可以让单个瞭望塔有能力限制其运营成本的增长,但是这并不能解决整个系统中存储容量的二次增长,也就是说,这只不过是让网络中的节点来分摊总负担

2. 保存按钮

使用范围:闪电网络 & 雷电网络(效果有限)

假设瞭望塔仅需要存储最新状态更新便足以阻止潜在对手作弊(RDN 或闪电网络的 eltoo 方法),用户可以在不与其瞭望塔同步的情况下进行多笔链下交易,然后仅发送最新状态更新。

用户可以定义何时将状态更新发送给瞭望塔:

  • 按下 “保存/同步” 按钮时
  • 周期性地(比如:有交易时每天或每小时)
  • 用户下线前自动同步

这样,面向业务的瞭望塔将会拥有更少的关于用户经济活动的信息,例如时间和交易总量,因此会有一定程度的隐私性。 数据存储要求也不会成为扩展的瓶颈,因为瞭望塔只会存储最新的状态更新。 此外,带宽负担会减少,因为并非所有状态更新都会发送给瞭望塔。

问题:

  • 最大的问题是用户体验,因为用户必须手动 “保存” 状态。
  • 它的安全性也较低,因为在用户丢失数据或设备之前,自动同步可能保存状态失败。
  • 自动同步将透漏用户的在线时间表。
  • 在 RDN 的当前设计中,这种方法只能隐藏交易的时间,即 RDN 监视服务仍然可以看到交易的总量,因为每个包(package)都将包含一个 nonce,表示在通道中交易的总数。
  • 它应该是默认设置,否则外行不会使用它。

3. 在面向隐私的模型,让用户主动请求删除旧状态

适用范围:闪电网络(eltoo)

实施 eltoo 之后,即使是面向隐私的瞭望塔也能够只存储属于特定通道的最新状态更新,但它们是如何确定哪些状态更新是旧的呢? 注意:面向隐私的瞭望塔无法将同一通道或帐户所做的所有状态更新联系在一起。*

解决方案是在经济上激励用户向瞭望塔发送删除旧状态的请求。 为了保护隐私,用户可以使用 Tor 在新交易完成一段时间后再向瞭望塔发送最新状态。

这种方法结合了:

  1. 面向隐私的设计
  2. 仅存储最新状态更新的能力
  3. 交易时间模糊化
  4. 用户请求删除旧状态

在我看来,这是隐私和可扩展性方面最平衡的方法。 但是,目前尚不清楚如何激励用户在不放弃隐私的情况下主动发送删除旧状态的请求。 我们将在下一篇关于可行商业模式的文章中研究。

总结

隐私和可扩展性问题有许多不同的解决方案,但所有这些方案都有所牺牲。 链下扩展的未来仍然非常不明确,因此,讨论不同设计的优缺点,研究激励模型,头脑风暴出解决问题的新方法和方案至关重要。

下一篇文章中,我们将研究追责问题的解决方案,并讨论不同的瞭望塔业务模式以及他们如何通过服务获利,因为需要考虑的因素变得更多了。

免责声明:我并不是一个权威的金融顾问,这篇文章也并非理财建议。本文提供的信息仅供教育用途,且仅代表我个人观点,并非事实。加密货币非常不稳定,波动非常大。对于因使用或信赖本文所提的任何内容、商品、服务或公司而造成或生成造成任何损害或损失的情况,我本人不直接或间接负责。如需投资,请向专业人士咨询。


原文链接: https://medium.com/crypto-punks/lightning-vs-raiden-watchtowers-monitoring-services-solutions-e243f7793d19
作者: Sam Aiken
翻译&校对: storm pang & 阿剑

本文由作者授权 EthFans 翻译及再出版。


你可能还会喜欢:

科普 | 用算盘了解闪电网络
引介 | Linkdrops:以太坊上发红包的开源标准
干货 | 理解 ProgPoW 算法

 
0 人喜欢