面向区块链轻节点的支付通道瞭望塔技术研究*

解岩凯,魏凌波,2,张 驰,王庆涛,孙启彬

1.中国科学技术大学 网络空间安全学院,合肥 230027

2.中国电子科技南湖研究院,嘉兴 341000

1 引言

中本聪于2008年发表比特币(bitcoin,BTC)的白皮书[1],宣告了基于区块链的加密货币的诞生.得益于区块链去中心化、不可篡改与公开透明等特点,加密货币受到了越来越多的关注.截止2021年2月,使用加密货币的人数已经超过了六千万[2].但随着用户规模与交易数量的快速增长,加密货币的低交易吞吐量成为亟待解决的重要问题.由于区块大小与区块产生时间均受到限制,比特币交易验证速度平均只能达到7笔/秒,只相当于现有中心化支付系统VISA的约七千分之一[3].虽然第二代加密货币以太坊实现了更高的交易吞吐量,但目前平均交易速度也仅为11.5笔/秒[4,5].以上数据表明,低交易吞吐量是主流加密货币面临的共性问题.

由于P2P网络中消息传播速度的限制以及节点性能的影响,直接对区块链进行扩容的方案会导致区块链系统安全性、可靠性和去中心化程度的下降,因此无法在比特币社区中得到一致认同.以扩展区块大小为例,如果比特币希望达到与VISA相同的交易吞吐量,则比特币需要在出块时间不变的前提下将区块扩大至8 GB,但是几乎没有多少矿工有能力承受维护这样的区块链带来的巨额成本,这将使比特币网络去中心化程度急剧下降,甚至回归中心化支付系统[3].正是基于这个原因,比特币历史上对区块链进行直接扩容的方案[6-10]均无法在比特币社区得到一致认同.加密货币低吞吐量的问题意味着加密货币的一部分交易将无法及时被记入链上[11],用户需要通过增加交易费的方式提高交易写入区块链的优先级,目前比特币交易的平均交易费已经超过19美元1数据来源于https://www.blockchain.com/charts/fees-usd-per-transaction,访问时间2021年3月18日..低交易吞吐量与高交易费问题严重制约了小额交易与高频交易在区块链网络上中的生存.

由于直接对区块链扩容的方案存在上述问题,区块链研究者提出了链下方案[12].链下方案在不改变区块链共识规则的前提下将当前区块链上的交易转移至链外处理.链下方案主要分为侧链[13]与支付通道网络[3]两大类,支付通道网络在交易速度、隐私性和效率等方面均优于侧链[14].支付通道网络是由运行支付通道节点软件的节点形成的对等网络,节点通过支付通道[15]与其他节点形成点对点连接.支付通道允许交易双方改变支付通道内资金的结算方案实现链下交易(off-chain transaction),区块链只记录通道的开启和关闭,并对链下交易提供安全保障.交易双方只将创建与关闭支付通道的交易写入区块链,而链下交易数目没有任何限制,这从根本上解决了区块链低吞吐量和高交易费的问题[16],为小额交易与高频交易在区块链网络上的应用提供了很好的解决方案.

为了避免支付通道中一方离线而导致另一方无法关闭支付通道取回资金,支付通道允许参与者在任意时刻公布支付通道的最新状态独立关闭支付通道.但是区块链无法判断被提交的状态是否是最新的,恶意的支付通道参与者可能向区块链公布过期的状态关闭支付通道,从而获得本不应属于他的通道份额.为了解决这个问题,关闭通道的交易拥有一个特殊的争议时间(dispute period)属性,公布了关闭通道交易的一方的资金在争议时间内会被冻结,这使得通道内诚实的用户可以在争议时间内取出冻结的资金,挽回恶意关闭通道交易可能造成的损失,并惩罚恶意的参与者.这样的安全保障机制要求通道参与者必须在每段争议时间内至少监视一次区块链,否则参与者可能无法发现已经被提交上链的恶意关闭通道交易或是来不及对链上的恶意交易进行反制.但在现实应用场景中,运行在手机等资源受限设备上的轻节点难以在每段争议时间内都同步区块链,因此他们在参与支付通道时存在资金损失风险.截止到2021年,比特币网络中仅有10 126个能够持续同步区块链的“活跃”全节点,以太坊中“活跃”的全节点只有6061个2数据来源于https://etherscan.io/charts,访问时间2021年3月18日.,这还不到加密货币总用户数的0.1%.可见大部分区块链用户使用支付通道实现链下交易时存在安全隐患,提高支付通道的安全性迫在眉睫.

为解决无法实时监听区块链带来的安全隐患,轻节点可以将监听恶意交易的任务外包给一个被称为“瞭望塔”(watchtower)的第三方[17].瞭望塔是一个或一组特殊的全节点,他们作为代理协助轻节点监视区块链,一旦发现支付通道以过期的状态进行结算,就启动支付通道的安全保障机制,帮助用户挽回损失并惩罚恶意参与者.虽然瞭望塔的引入提升了轻节点的安全性,但却带来了额外的安全与隐私泄露问题.首先,瞭望塔可能对支付通道安全性造成影响.如果瞭望塔是一个可信第三方,则支付通道的安全隐患已被解决,轻节点可以随意离线而不必担心支付通道被恶意关闭.但在现实中,瞭望塔和支付通道参与者均不一定是可信的,瞭望塔可能会消极怠工,或是和通道中的恶意节点合谋令诚实节点蒙受损失.其次,瞭望塔亦存在泄露用户隐私的可能.为了保证支付通道安全性,瞭望塔需要收集支付通道的更新日志以便于识别恶意关闭通道交易,但这侵犯了用户的隐私,瞭望塔可以获知通道内交易的内容,进而推断用户在真实世界的身份[18].最后,应用于比特币支付通道的瞭望塔存在效率问题.比特币支付通道瞭望塔需要保存支付通道的每一次更新才能帮助用户挽回损失以及惩罚恶意的参与者,这代表着为多个用户服务的比特币瞭望塔需要存储庞大的更新日志,并在每个新区块产生后都遍历一次数据库方可完成监视.因此,如何降低存储与计算开销也是比特币支付通道瞭望塔协议设计的关键一环.

截至目前已有大量的综述总结了近年来支付通道的研究进展[14,19,20],但仅有Gudgeon等人[12]在其关于支付通道的综述中介绍了瞭望塔的概念,并认为瞭望塔是解决支付通道安全问题的可行方案.但Gudgeon等人的综述主要围绕支付通道方案展开,并未对瞭望塔方案进行深入的研究,因此本文填补了支付通道网络中瞭望塔方面综述的空白.

瞭望塔方案设计需考虑支付通道的安全性、通道参与者的隐私性和瞭望塔的效率,已有的瞭望塔方案均试图解决其中一个或多个问题.本文对目前支付通道网络中各类瞭望塔方案进行了整理,基于方案的应用背景将其分为比特币中的瞭望塔和以太坊中的瞭望塔两大类,详细阐述了每种方案的原理,并从隐私性、安全性与效率等多个角度衡量两类方案的优劣.最后,我们对瞭望塔的未来研究进行了展望,提出了可行的研究思路.

2 支付通道技术简介

支付通道允许交易双方执行链下交易,进而降低交易费,提升交易速度.目前比较成熟的支付通道技术有比特币闪电网络中的支付通道[3]和以太坊的状态通道[21]等.接下来我们分别概述比特币和以太坊中的支付通道.

2.1 比特币中的支付通道

比特币支付通道中交易双方通过多重签名脚本建立一个联合账户以锁定资金,每次双方进行交易,他们在链下更新该账户中资金的分配方案,并签署新的承诺交易(commitment transaction)以完成分配状态的更新.如图1所示,在比特币区块链中,我们假设爱丽丝(以下简称A)和鲍勃(以下简称B)分别向支付通道中注入了0.5个比特币(交易中黑底白字黑框代表已签名,白底黑字黑框代表花费输出需要的签名),此时支付通道中总共拥有1个比特币,其中0.5个属于A,0.5个属于B.一旦A和B发生了链下交易,A和B更新支付通道中的资金分配方案,签署新的承诺交易.如果A和B不再进行交易了,他们将通道中最后一个承诺交易用作通道结算交易,并向区块链广播,将支付通道中锁定的资金结算给交易双方.

图1 支付通道概述Figure 1 Payment channel overview

只要交易双方没有关闭支付通道,他们就可以生成新的承诺交易来改变支付通道中资金的分配方案.所有承诺交易除输出不同外并无实质性差别,因此过期的承诺交易并不随着新承诺交易生成而自动作废,支付通道中恶意的一方可以在最新承诺交易被记入区块链前向区块链提交对自己更为有利的过期承诺交易,由于过期的承诺交易也是合法交易,因此也能通过比特币矿工验证并记入新区块,这最终会导致诚实参与者蒙受损失.为了避免这种情况的发生,支付通道通过设计序列到期可撤销合约(revocable sequence maturity contract,RSMC)引入争议时间,以实现承诺交易的安全更新.

RSMC定义了三类交易:承诺交易、可撤销的交付交易(revocable delivery transaction)和违约补救交易(breach remedy transaction).承诺交易的功能与前文是一致的,但为了保护诚实通道参与者的资金安全,承诺交易会将承诺交易发布者应得的通道份额输出到通道参与者的新共同账户中,而另一个通道参与者的通道份额则可以立即到账.可撤销的交付交易允许承诺交易发布者将承诺交易输出到共同账户中的资金取出,但这笔交易只有在锁定时间过后才能上链,因此承诺交易发布者的通道份额会被锁定一段时间,RSMC中这段锁定时间被称为通道争议期,也就是争议时间.违约补救交易的作用是对过期承诺交易进行反制.每当生成新的承诺交易后,交易双方交换生成违约补救交易所需要的密钥以作废过期的承诺交易.如果恶意的参与者提交一笔过期的承诺交易,在争议期内另一个参与者只需向区块链提交与过期承诺交易对应的违约补救交易就可以获得支付通道内的全部份额,这不仅挽回了损失还惩罚了恶意参与者;如果上链的是最新的承诺交易,通道参与者则无法生成对应的违约补救交易,因此提交承诺交易的参与者可以在争议期过后将通道中自己的份额取出.

然而,只有在争议时间内提交违约补救交易,违约补救交易才会生效.这是因为如果提交承诺交易的一方是诚实的,即公布了最新的承诺交易,那么区块链不能无限期冻结其资金.这也避免了另一方突然掉线而导致提交承诺交易的一方无法结算支付通道内资金的问题.但这也意味着即使恶意的一方向区块链提交了一笔过期的承诺交易,如果争议时间内另一方没有向区块链提交违约补救交易以取出锁定资金,其依然会遭受资金损失.为了防止这种攻击,交易双方需要实时监视区块链,以监测对方是否公布过期的承诺交易.如果B在争议时间内始终离线,那么恶意的一方就可以公布一笔过期的承诺交易实现对另一方的攻击.

2.2 以太坊中的支付通道

通过智能合约,Miller等人[21]将比特币中的支付通道拓展到以太坊为代表的第二代区块链中.将支付通道建立在智能合约上有三点优势:第一,智能合约大幅简化了通道链下更新的流程.通过在交易中维护一个名为“状态”的递增参数,以太坊中的支付通道可以在生成新链下交易的同时直接将旧承诺交易作废.由于智能合约可以通过比对状态参数的大小来判断链下交易发生的时序3与以太坊支付通道思路相同,Decker等人使用浮动交易对比特币支付通道进行改进,从而将交易时序引入比特币支付通道中,简化了通道链下更新流程[22].但目前比特币区块链并不支持浮动交易,因此该方案并不能直接用于比特币区块链.,因此对过期交易的反制只需向智能合约提交状态参数更大的交易即可完成,支付通道参与者只需存储状态通道的最新状态,这也最小化了用户的存储.第二,智能合约还可以允许用户根据其需求设计更为复杂的金融衍生工具,例如期权、担保交易和对赌协议等.第三,由于智能合约的图灵完备性,建构于智能合约的支付通道还可以允许多于两名参与者在同一个通道内执行链下交易.正因为基于智能合约的支付通道在合约中维护的状态参数,这类支付通道又被称为“状态通道”[21].

总的来说,支付通道不仅仅提升了区块链的吞吐量,还提升了区块链用户的交易效率以及隐私保护[23].相比于链上交易,支付通道使交易双方在限额内实现不限数量的链下交易,而只需要负担支付通道创建交易以及结算交易的交易费.此外,支付通道也显著增强了区块链的支付速度.区块链常规交易需要几十秒乃至数十分钟才能被区块链确认,而基于支付通道的支付可以在数毫秒之内完成[24].最后,该方案还能增强用户隐私保护效果.通过支付通道与其他节点相连的用户可以形成支付通道网络,交易双方并不需要向区块链提交交易建立直接的支付通道,而是通过现有支付通道网络进行支付,此时所有的交易都是链下进行的,因此全节点无法通过公开的区块链获取任何用户的交易信息,这也契合了加密货币最大化保护用户隐私的设计目标[25].

3 原始瞭望塔协议概述与其面临的挑战

运行在手机等资源受限设备中的轻节点无法保证时实在线并监视区块链.只要轻节点的离线时间大于争议时间,就可能面临丢失通道资金的风险.为规避上述风险,通道参与者可以设置较长的争议时间以避免损失,然而这会极大降低通道结算效率.但是对于轻节点来说,更长的通道结算时间将导致轻节点面临更大的通道资金安全性风险.如果轻节点的离线时间超过了争议时间,那么他就可能损失通道内属于他的部分乃至全部资金.为解决长时间离线问题,轻节点会将监视操作外包给时时在线的瞭望塔.一旦支付通道中的恶意参与者在轻节点离线时公布过期承诺交易,瞭望塔就可以监测到这种行为,代替用户向区块链提交违约补救交易,挽回轻节点的损失,并惩罚恶意的用户.

文献[17]中给出了原始的瞭望塔的实现.在比特币支付通道中,用户需要将每一笔过期承诺交易对应的违约补救交易上传到瞭望塔中.瞭望塔实时监测区块链中每一笔交易,并与违约补救交易中的地址进行匹配.一旦匹配到过期的承诺交易,瞭望塔就将对应的违约补救交易提交到区块链来进行反制.举个例子,交易方A和B通过RSMC建立了一个支付通道:如图2所示,在支付通道初始化时会生成了实线框中的所有交易,带有A标识的弧线框交易为A持有的交易,带有B标识的直角框交易为B持有的交易.对于A来说,即使B不响应,她也可以向区块链提交承诺交易1A独立关闭支付通道,当承诺交易A被区块链确认后,B立即得到支付通道中他的份额,而A的资金会被提交到一个新的多签名地址(A1,B1)中,只有在承诺交易1A被确认1000个区块后,矿工才会接受A提交的可撤销的交付交易并将其写入新区块内,允许A将多签名地址(A1,B1)中的资金提取到自己的地址中4这是通过比特币交易输入中的Sequence_no属性实现的,支付通道参与者可以根据需求灵活配置争议时间..同理,如果B向区块链提交承诺交易1B,A会立即得到她的份额,而B的资金也会被冻结相同的时间.

图2 瞭望塔参与的支付通道更新流程Figure 2 Watchtower-based payment channel workflow

当支付通道更新时,交易双方需要作废代表更新前状态的承诺交易,即生成作废更新前状态的对应违约补救交易,并将该违约补救交易上传到瞭望塔中.例如,当支付通道更新至承诺交易2A与2B时,交易双方需要将过期的承诺交易1A和1B作废.为实现这样的目标,通道双方需要交换过期承诺交易1A与1B的多签名输出中各自的私钥,进而允许交易双方生成针对过期承诺交易的违约补救交易来处理违约.具体地说,A需要将过期承诺交易1A中自己的公钥A1对应的私钥发送给B;同理,B亦需要将公钥B2对应的私钥发送给A.为了避免实时监视区块链带来的开销,交易双方可以使用私钥生成过期承诺交易对应的违约补救交易,并上传到瞭望塔中.每次更新交易双方都会重复这种操作,上传作废每一个对应过期承诺交易的违约补救交易至瞭望塔中.瞭望塔实时监测区块链中每一笔交易,并与违约补救交易中的地址进行匹配.如果发现匹配,则提交对应的违约补救交易帮助用户挽回损失.例如,一旦A发布过期承诺交易1A,实时监测区块链的瞭望塔就会捕捉到这笔过期的承诺交易,他会将收到的违约补救交易1B提交到区块链中,将(A1,B1)中的0.5个比特币全部转移到B的地址中.而公布过期承诺交易1A的A由于没有公钥B1对应的私钥,因此只能等待承诺交易1A被确认1000次之后,才能提交可撤销的交付交易1A提现(A1,B1)中的全部比特币.此时,即使B不监视区块链,他也不会损失任何资金.

不幸的是,这种简单的瞭望塔机制存在诸多问题.在效率方面,由于使用的密钥不同,因此每一个过期的承诺交易对应唯一的违约补救交易,因此瞭望塔需要存储全部的违约补救交易,并在新区块产生后遍历支付通道中所有的违约补救交易进行匹配,这为瞭望塔带来了巨大的开销.虽然瞭望塔开发者重新设计了违约补救交易的存储结构,压缩了瞭望塔存储违约补救交易的开销,但是存储一笔违约补救交易仍需要300-350字节.只要支付通道没有结算,瞭望塔就必须存储所有的违约补救交易.随着支付通道数目的不断增长,瞭望塔的存储压力也会不断增大.不仅如此,一旦一笔承诺交易被提交到区块链,瞭望塔就需要遍历整个数据库.随着数据库规模的增加,交易匹配也需要越来越多的计算资源[26].

构建于以太坊状态通道之上的原始瞭望塔不存在效率问题.与比特币支付通道瞭望塔不同,基于智能合约以太坊状态通道瞭望塔继承了状态通道的优点,最小化了瞭望塔存储的数据量进而提升了效率.举个例子,如图3所示,在A,B和C参与的状态通道中,每次交易后他们三个共同生成新的通道份额分配方案,更新状态序号并对其进行签名.随后通道参与者将最新的状态信息上传到瞭望塔,在接受到最新的状态信息后瞭望塔就可以删除旧状态最小化其存储开销.一旦恶意的参与者(假设为A)发布过期的状态state2,实时监测区块链的瞭望塔就会捕捉到这种行为,并向合约提交最新状态state3.由于瞭望塔提交了状态序号大于2的状态,则A的链上更新请求无效,在争议时间结束后通道以状态序号最高的状态进行结算.如果争议时间内没有新于state3的状态被提交,则通道合约将把state3视为最新的合法状态并将其记录到区块链上,完成状态的链上结算.

图3 瞭望塔参与的状态通道更新流程Figure 3 Watchtower-based state channel workflow

这两种原始瞭望塔都面临着隐私和安全问题.在隐私方面,将监视任务外包给瞭望塔会泄露用户的隐私.简单来说,每次支付通道的更新都会产生新的违约补救交易,或者最新状态,用户需要将全部更新信息提交给瞭望塔以便于瞭望塔提供监视服务.然而,通过用户每次提交的更新信息,瞭望塔可以了解用户支付通道的全部状态变化,进而推断出用户进行的每一笔交易信息,造成对用户隐私的侵犯.更重要的是,将监视任务外包给原始瞭望塔还面临安全隐患.信任单一瞭望塔违反了区块链去中心化的原则:如果瞭望塔因为网络等故障而无法监视区块链,或者欺骗用户而实际上不监视区块链,甚至与支付通道中恶意的一方共谋,这都将导致用户遭受无法索赔的资金损失.而且原始瞭望塔协议无法帮助用户收集证据,来向瞭望塔追偿[27].一种可行的方案是让用户与多个瞭望塔相连,只要有一个瞭望塔是诚实的,用户的资金就是安全的.最后,激励机制也会影响支付通道资金的安全,若没有足够的激励,瞭望塔就没有动力为用户提供服务.

针对文献[17]中原始瞭望塔的缺陷,区块链开发者已经提出了多种解决方案.我们搜集了目前的瞭望塔解决方案[26-34],根据其底层支付通道的不同,将它们分为比特币支付通道瞭望塔协议和以太坊状态通道瞭望塔协议两大类,并从瞭望塔效率、链下交易隐私保护以及支付通道资金安全性等三个方面衡量每一种方案.接下来我们首先介绍两类支付通道瞭望塔协议.

4 比特币支付通道瞭望塔协议

针对原始比特币支付通道瞭望塔存在的隐私、安全性与效率问题,比特币开发者提出了许多解决方案.由于解决瞭望塔的效率挑战是通过减少上传到瞭望塔的数据实现的,这必然提升了用户隐私.因此,我们把隐私和效率视为一个整体,将这些方案按其核心侧重点分为隐私提升方案以及安全提升方案,并分别阐述方案的实现细节以及优缺点.

4.1 隐私提升方案

为了保护用户的链下交易隐私,比特币开发者利用比特币部分操作符的特性改进了瞭望塔协议.Dryja[28]提出使用过期承诺交易的ID(transaction ID,TXID)作为密钥来加密违约补救交易,以提升轻节点的隐私保护效果.

当支付通道更新时,B就使用过期承诺交易的TXID加密对应的违约补救交易,并将其提交给瞭望塔.只要A是诚实的,她就不会将过期的承诺交易提交到区块链中.那么瞭望塔就无法获取解密违约补救交易所需的TXID,因此瞭望塔无法获知交易双方的通道份额.一旦A提交了过期的承诺交易(即A希望窃取B的资金),瞭望塔就可以从区块链中获取过期承诺交易的TXID,并用该TXID解密对应的违约补救交易并将其提交到区块链中挽回B的损失.除了提交到公开区块链中的交易信息,瞭望塔无法破解其余承诺交易.如果B拥有多个支付通道,这样还可以隐藏每个支付通道的更新频率,因为瞭望塔无法通过加密数据定位更新的支付通道.故该瞭望塔方案最大程度地保护了用户的隐私.

为了安全提取对方过期承诺交易的TXID,Dryja的瞭望塔方案还使用了隔离见证技术[35].隔离见证技术通过引入SIGHASH_NOINPUT操作符,将交易的TXID与签名分离,B只需要知道A过期承诺交易对应的输入输出,即可计算出交易的TXID.由于没有签名,B亦无法恶意公布A持有的过期承诺交易以窃取A在支付通道中的份额.隔离见证技术解决了TXID获取过程中的安全性问题,是Dryja的瞭望塔方案的基石.

另一方面,虽然支付通道中资金分配方案信息熵较低,但即使瞭望塔猜中违约补救交易对应的过期承诺交易中的资金分配方案,他也无法推导出过期承诺交易的TXID,解密对应的违约补救交易获得隐私数据佐证其猜测.如图2所示,在承诺交易每次更新时,A和B每次都会随机生成新的一次性地址锁定交易输出,这是因为作废旧状态需要向对方公布锁定输出地址对应的私钥.由于这些地址在区块链上从未出现过,因此瞭望塔无法猜测过期交易使用的地址.即使瞭望塔猜中过期承诺交易中的资金分配方案,他也无法猜中随机生成的地址,故无法推导出TXID来破坏B的隐私.

虽然Dryja的瞭望塔方案提升了轻节点的隐私保护效果,但瞭望塔所需的资源仍是整个系统的瓶颈.每当监测到一笔承诺交易,瞭望塔就需要提取其TXID,并遍历数据库中存储的全部加密信息以提取违约补救交易.由于引入了加密算法,这种方法所需的计算资源更多;另一方面,这种方法也会增加瞭望塔的存储开销.最后,没有支付通道参与方的帮助,瞭望塔无法识别已关闭的支付通道对应的违约补救交易,因为它们被TXID加密.这带来了额外的存储开销.

Khabbazian等人在Dryja的瞭望塔方案基础上提出了Outpost协议[26],在保护用户隐私的前提下显著提升了瞭望塔效率.在Outpost协议中,瞭望塔仅存储解密违约补救交易的密钥,提交承诺交易的一方必须向区块链提交一笔数据输出交易(通过OP_RETURN操作符实现)才可以关闭支付通道提取相应份额,数据输出交易以密文的形式记录了对应的违约补救交易.如果上链的是过期的承诺交易以及相应数据输出交易,瞭望塔就可以使用用户提交的密钥解密违约补救交易.因此这种方案显著提升瞭望塔的存储效率,且没有牺牲用户的隐私.

该方案重新设计了比特币支付通道的更新支付通道的流程以及链下交易的数据结构,使得提交承诺交易的一方必须向区块链提交数据输出交易,否则他无法提取支付通道中的份额.如图4所示,新承诺交易有三个输出,除了原有的两个结算输出,该方案使用第三个输出生成一笔数据输出交易以记录当前承诺交易的违约补救交易.为了保证恶意的支付通道参与者A一定需要生成并公布数据输出交易,数据输出交易包含另一个有少量比特币的输出,A在提取其支付通道余额时必须将该输入包含在可撤销的交付交易的输入中,否则她将无法关闭支付通道.可撤销的交付交易的两个输入存在两个相互独立的锁定时间,只有这两个锁定都解除,参与者A才能够提交可撤销的交付交易取回资金.在这两个锁定时间形成的争议期间内,只要瞭望塔监视到这笔数据输出交易,他就可以从中提取违约补救交易并将其提交到区块链,帮助合法用户挽回损失.

图4 Outpost方案示例Figure 4 Outpost scheme overview

在该方案中,违约补救交易以密文的形式被打包到数据输出交易中,这是为了保证诚实的用户能够正常关闭支付通道.如前所述,当前承诺交易对应的数据输出交易记录的是当前承诺交易的违约补救交易,如果违约补救交易是以明文存储的,当A公布最新的承诺交易时B就可以从数据输出交易中提取违约补救交易以窃取A的资金.为了避免这种情况,A会加密违约补救交易.当支付通道更新时,交易双方不仅要交换过期承诺交易中锁定输出地址的私钥,还需要交换加密违约补救交易的密钥.在每次更新支付通道后,B只需要将128比特的密钥上传给瞭望塔.相比于动辄几百字节的违约补救交易,该方案显著压缩了瞭望塔的存储开销.此外,该方案也继承了Dryja的瞭望塔中的隐私保护的特性,除了被提交到区块链中用于关闭支付通道的承诺交易,瞭望塔无法破解B的链下交易内容.

总的来说,Outpost协议显著提升了瞭望塔效率以及用户隐私,并与现有比特币区块链完全兼容.但是这类方案没有讨论瞭望塔面临的资金安全隐患:信任单一瞭望塔违反了区块链去中心化的原则[36,37].并且这类方案缺乏针对恶意瞭望塔反制措施:假使瞭望塔不作为,甚至共谋则导致用户资金损失,用户也无法收集证据向瞭望塔索赔.

4.2 安全提升方案

为了解决原始瞭望塔方案中存在的安全隐患,Avarikioti等人首次将分布式理念引入瞭望塔协议中,为支付通道中的资金提供了更强的安全保障.安全性提升的另一种思路是通过引入保证金作为抵押,即使用户因瞭望塔不作为等原因损失了通道中的份额,他仍可以向区块链提交瞭望塔违约的证据,从而获得瞭望塔的保证金以补偿损失.

4.2.1 分布式瞭望塔协议

单一瞭望塔架构在瞭望塔不作为或共谋的情况下存在安全问题,将单一瞭望塔扩充为一组瞭望塔节点形成的分布式瞭望塔系统可以为用户提供更强的安全保障.Avarikioti等人在2018年首次提出分布式瞭望塔协议DCWC[29]以提升支付通道的安全性,并设计了相应的激励机制奖励诚实的瞭望塔:为支付通道安全做出贡献的瞭望塔可以参与分配支付通道中恶意参与者的份额.在DCWC中,只要有一个瞭望塔是诚实的,恶意参与者就无法窃取用户的资金.

DCWC中的违约补救交易是由支付通道参与者B生成,并层层转发到多个瞭望塔的.如果支付通道的另一个参与者A违约,先收到违约补救交易的瞭望塔有优先追索权与优先受偿权.换句话说,按照接收到违约补救交易的顺序,瞭望塔形成了一个队列.当区块链中出现过期的承诺交易时,只有队列前端的瞭望塔不作为,后续瞭望塔才能获得相应激励份额.举个例子,如果B向瞭望塔W1提交了违约补救交易,这笔违约补救交易经由瞭望塔W2传播到瞭望塔W3.如果A违约,并且W1履行了他的义务,他将获得全部的奖励.如果W1在规定的时间内不作为,W2最终帮助B挽回了损失,那么W1获得转发奖励,W2获得支付通道中A剩余的份额.只有当W1与W2皆不作为时,W3才会获得奖励.

这种瞭望塔的激励策略是通过切割争议时间实现的.其分配方式如图5所示:当A违约时,按照协议,所有瞭望塔都会向区块链提交违约补救交易,我们假设违约补救交易中有1.5 BTC的输出用于激励瞭望塔.激活该输出的解锁脚本有两种策略:如果瞭望塔W1实时在线,他就可以向区块链提交交易T11提取所有奖励.若在区块链生成s个区块后,W1仍未提取这笔输出,这代表W1实际上掉线了,违约补救交易是后续瞭望塔提交的.在这种情况下,后续瞭望塔可以提交交易T12,此时W1仅获得转发奖励,即0.5个比特币.同样,对于瞭望塔W2,他同样有生成s个区块的时间提取剩余全部奖励.若未提取,在扣除转发奖励后,通道内剩余比特币会被提交给后续瞭望塔进行分配.以此类推直至最后一个瞭望塔.所有生成s个区块对应时间之和即支付通道的争议时间.

图5 DCWC方案示例Figure 5 DCWC scheme overview

使用树状结构代替队列可以进一步提升支付通道的安全.在例子中,每个瞭望塔仅转发了一次违约补救交易,而在实际情况中,每个瞭望塔可以向多个瞭望塔转发违约补救交易,进而形成一个树.引入更多的瞭望塔进一步保证了用户的通道资金安全.不同分支中的瞭望塔是相互竞争的,换句话说,只有一条分支中的瞭望塔会获得奖励.

但是DCWC的激励措施缺乏吸引力,这会使DCWC方案在现实中无法达到预期的安全水平.由于瞭望塔只能从参与者恶意行为中获利,而理性的参与者并不会作恶,因此DCWC中的瞭望塔并无稳定的期望收益.另一方面,DCWC中越靠近叶子节点的瞭望塔存储压力会越大,而期望收益却越少.如图5所示,对于瞭望塔W2,他不仅仅需要存储违约补救交易,还需要存储交易T12.以此类推,相比于W2,瞭望塔W3需要再多存储一笔交易.总的来说,越靠近叶子节点的瞭望塔,所需要存储的交易就越多,由于需要向父节点分配转发奖励,其获得的奖励却更少.综上所述,理性瞭望塔不会参与这种协议[31],在现实中实现DCWC几乎是不可能的.

Leinweber等人认为可以通过分布式瞭望塔和可信执行环境(trusted execution environments,TEE)设计可靠的日志审查机制,以解决瞭望塔不作为的问题.该方案在现有瞭望塔系统中引入日志机制,通过日志审查识别不作为的瞭望塔.为了保证日志的可靠性,他们提出结合TEE,例如目前最受欢迎的Intel SGX[39],设计可靠的瞭望塔日志审查系统[30].简单来说,通过在服务器内部TEE运行瞭望塔以及日志程序,进而为用户提供可审查的瞭望塔服务.为了避免服务器中不可信部分干扰TEE中的代码执行,TEE被设计为与操作系统分开的隔离部分,以确保TEE中处理的数据不被具有特权的操作系统识别、修改.换句话说,具有管理权限的服务提供者不能影响TEE中信任代码的执行和输出,也不能识别其内部数据或者篡改其内部状态,因此恶意的服务器无法干扰TEE内部的日志生成程序,进而保证了日志的准确性.

但是依靠单一瞭望塔仍无法为用户提供强安全保证.这是因为恶意的服务器可以切断TEE与外部的通信,或者切断电源.不仅如此,由于TEE内部存储空间有限,因此TEE会将日志数据外包到不可信的外部存储中.尽管恶意的服务器无法篡改日志,但是他可以删除这些数据.为了解决这个问题,该方案将单瞭望塔扩展为分布式瞭望塔,从而为用户提供支付通道的强安全保障以及可靠的日志审查服务.当区块链产生新的区块,或者支付通道的状态发生更新,瞭望塔之间会互相审查并创建相关的审查日志,并对其进行签名.通过对比不同瞭望塔之间的日志数据,用户就可以验证瞭望塔是否持续监视区块链.

该方案亦利用TEE保护其内部数据机密性的特点,结合了BOLT#3方案[39]中的密钥推导算法生成RSMC中进行链下交易所需的密钥集,压缩了瞭望塔的存储开销,并保护了用户的隐私.只需要一个前面都是字节的种子,支付通道参与者就可以使用BOLT#3方案中的密钥推导算法生成248−1对公私钥,这完全满足支付通道更新的需求.因此,在支付通道初始化时,运行在TEE中的瞭望塔只需要获取支付通道双方的私钥种子.如果支付通道恶意的一方A提交过期的承诺交易,TEE使用种子生成对应私钥,进而生成对应违约补救交易,并将其提交到区块链帮助瞭望塔用户B挽回损失.相比于Outpost协议,这种方案进一步压缩了瞭望塔的存储开销.由于TEE只按照规定的代码提供瞭望塔服务,具有管理权限的服务提供者也不能识别TEE内部数据,因此恶意的服务器也无法获知支付通道双方用于更新支付通道的密钥种子,亦无法窥探用户隐私.

虽然这种方案可以允许用户识别不作为的瞭望塔,但是使用这种瞭望塔的用户仍需要向多个瞭望塔支付服务费.此外,信任TEE可能会威胁支付通道双方的资金安全.目前有很多研究者指出SGX面临信息泄露风险[40-44].如果恶意的服务器能够识别SGX内部的数据,这不仅仅破坏了用户的隐私,攻击者还可以获取支付通道双方用于更新支付通道的私钥种子,进而窃取其在支付通道中的资金.

4.2.2 保证金担保方案

文献[31]借鉴了以太坊状态通道瞭望塔PISA[29]的设计思路,提出了Cerberus channel方案,该方案通过重新设计比特币支付通道协议,将保证金机制引入到比特币支付通道瞭望塔中以增强瞭望塔安全性.在提供服务前,瞭望塔通过抵押交易将一大笔担保金锁定在与用户形成的联合账户中,作为瞭望塔提供服务的担保.与之前的方案不同,在该方案中瞭望塔需要参与支付通道的更新环节:当支付通道更新时,交易双方与瞭望塔不仅要生成新的承诺交易、可撤销的交付交易、违约补救交易,还需要生成对应反制瞭望塔的惩罚交易.在关闭支付通道结算通道内余额时,即使A公布承诺交易,B亦无法直接获得属于他的通道余额.只有在争议时间过后,或者获得瞭望塔的签名授权,他才能够提取属于他的份额.这是为了便于反制恶意的瞭望塔:举个例子,如图6所示,如果A公布过期的承诺交易,若在争议时间内瞭望塔不作为,B就可以在一个索赔时限内公布惩罚交易,进而没收保证金以弥补损失.如果瞭望塔及时向区块链提交了违约补救交易,即使B再向区块链提交惩罚交易,这笔交易也不会被区块链接受,因为他们花费了一笔相同的输出.

图6 Cerberus channels方案示例Figure 6 Cerberus channels scheme overview

需要注意的是,比特币区块链也不能无限锁定瞭望塔的保证金,在索赔时限后瞭望塔就可以赎回保证金,但用户索赔的时间期限远大于支付通道的争议解决时限.总的来说,该方案继承了PISA方案的部分优点:通过引入保证金担保的瞭望塔,在没有增加争议时间的前提下延长了用户的离线时间,在没有牺牲通道资金灵活性的前提下提升了安全性.

另一方面,恶意的支付通道双方无法骗取诚实瞭望塔的保证金.首先,如果A是诚实的,B是无法通过公布惩罚交易骗取诚实瞭望塔的保证金.如果没有过期的承诺交易,惩罚交易花费的输出就是不存在的,自然不会被区块链矿工接受.其次,即使A和B共谋,他们也无法骗取瞭望塔保证金.这是因为瞭望塔需要参与支付通道的每一次更新.换句话说,没有瞭望塔的帮助,他们无法更新支付通道生成新的惩罚交易.因此,只要瞭望塔实时监测区块链,恶意的支付通道双方不可能骗取瞭望塔保证金.

虽然该方案保证了用户资金安全,但并不保护用户隐私,因为瞭望塔需要参与每一次支付通道的更新.此外,该方案不仅增加了瞭望塔的存储与计算压力,还增加了用户的存储开销.不仅瞭望塔需要存储全部的违约补救交易,用户也需要存储全部的惩罚交易,以保证支付通道被恶意关闭时能索取保证金补偿.

5 以太坊状态通道瞭望塔协议

以太坊智能合约的引入使得瞭望塔可以同时兼顾用户的隐私性与安全性.在隐私性方面,通过使用哈希函数重新设计状态通道合约以及通道结算流程,瞭望塔无需知晓承诺交易的细节,亦可保证用户的通道资金安全.而在安全性方面,借助智能合约,开发者引入了保证金机制,即使瞭望塔未及时对过期交易做出反制,用户亦可以向合约提交瞭望塔违约的证据,来提取瞭望塔抵押在智能合约中的保证金,从而获得补偿.

5.1 隐私提升方案

最早的基于智能合约的瞭望塔由McCorry等人提出,作者设计了名为PISA的瞭望塔方案[27],来改善以太坊支付通道瞭望塔中存在的隐私问题.PISA调整了状态通道的结算流程,通道参与者只需向合约上传包含所有参与者签名的状态序号,以及状态序号对应的支付通道状态的哈希值即可开启链上结算.举个例子,在支付通道参与者进行状态更新的时候,瞭望塔用户只需要上传所有通道参与者签名的状态序号以及哈希值即可.在争议时间内,瞭望塔也仅需向合约发送上述最新的状态信息(包括状态序号和状态哈希值)即可完成对过期交易的反制,状态哈希值的原像将在争议时间过后才需要被发送至区块链上.这样的调整使得瞭望塔只需要获得最新状态的哈希值,以及所有通道参与者对哈希值的签名,即可拥有反制过期状态的能力,而不再需要获知完整的状态,从而最大化通道参与者的隐私.此外,这样的设计还减少了链上内容对通道参与者隐私的泄露,因为不成功的链上强制结算请求将不再泄露状态的内容.

然而,简单地将通道状态替换为状态的哈希值并不能很好地保护通道参与者的隐私.这是因为通道中资金分配方案信息熵较低,瞭望塔可以枚举通道可能的状态并计算哈希值.通过与状态通道参与者上传的哈希值进行比较,瞭望塔就可以获知通道参与者的资金分配状态,也就破坏了通道参与者的隐私.为此,通道参与者向支付通道状态中添加了一个随机数以提升隐私.简单来说,状态哈希值对应的原象中包含了一个随机数用于最大化分配状态的信息熵.在这种情况下,即使瞭望塔猜中对应状态中的资金分配方案,他也无法猜中该随机数,故无法推导出状态哈希来破坏其用户的隐私.

另一方面,PISA中的瞭望塔还引入了保证金机制以进一步提升用户资金安全性.简单来说,通过维护一个保证金合约账户实现保证金的抵押机制,一个瞭望塔的所有服务都在同一个合约账户上完成,这样独立又唯一的账户设置有利于瞭望塔宣传与开展服务.如图7所示,在提供服务前,瞭望塔需要向保证金合约中存入一大笔保证金,以作为瞭望塔提供服务的担保.当B向瞭望塔订购服务时,他需要向瞭望塔发送需要瞭望塔监视的通道状态哈希值hstate3和所有参与者对该状态的签名供瞭望塔使用,这表示state2及之前的状态不应被用于通道链上更新.如果瞭望塔同意提供服务,瞭望塔会向B发送一个用自己私钥签名的收据,这个收据包含了瞭望塔应该监视的通道状态信息,随后双方建立一个单向支付通道供B支付服务费.在向B发送收据后,瞭望塔监视区块链上与通道合约相关的交易,一旦发现A将hstate2用于链上状态更新,瞭望塔就可以在通道的争议解决时限前提交{hstate3,3}和所有参与者对{hstate3,3}的签名来完成对过期状态hstate2的反制.一旦B发现瞭望塔没有完成监视通道的任务,他可以在一个索赔时限内向保证金合约提供这个收据和状态通道当前状态,证明瞭望塔不作为,从而将瞭望塔锁定在保证金合约里的保证金取出,而瞭望塔只能在这个索赔时限后才能赎回保证金.需要注意的是,B索赔的时间期限应远大于状态通道的争议解决时限.总的来说,PISA通过引入保证金机制,在没有牺牲通道资金灵活性的前提下提升了安全性.

图7 PISA方案示例Figure 7 PISA scheme overview

相比于之前的方案,PISA瞭望塔方案在实现了强安全性的同时保护了用户的隐私.首先,由于持有瞭望塔签名过的收据,用户可以在瞭望塔未正常提供服务后通过保证金合约单方面取走瞭望塔的保证金.其次,状态通道参与者也无法私下更新状态通道进而骗取瞭望塔的保证金,因为只要不上传最新状态,他们就无法获得带有瞭望塔签名的收据,保证金合约不会接受没有瞭望塔签名收据的索赔请求.基于以上两点,用户与瞭望塔的资金安全都得到了保障.在隐私性方面,PISA中的瞭望塔只会获得状态的哈希值而无法获知状态的内容,这有效地维护了通道的隐私性.除此以外,相比于分布式瞭望塔协议,该方案显著降低了用户服务费.只需要一个瞭望塔,该方案就能提供合理的安全保障,另外,用户只有在更新状态时才需要付费,这种付费机制对于绝大部分交易量不大的用户也更为友好.

但PISA方案设计存在两个核心缺陷.首先,PISA瞭望塔可以向多个通道提供服务,这些通道中包含的资金总额可能超过瞭望塔抵押的保证金,这使得保证金带来的安全性担保会随着用户数量增多而严重减弱.当瞭望塔对多个用户不作为时,后提交证据的用户将无钱可取,这是PISA方案最致命的安全漏洞.第二,瞭望塔用户需要监视瞭望塔是否正常工作,虽然用户索赔的时间期限长于通道争议期限,但用户仍不能完全离线.PISA方案只是延长了用户可以安全离线的时间,但并未从根本上解决用户无法离线的问题.

5.2 安全提升方案

Avarikioti等人提出了BRICK方案,该方案通过引入分布式瞭望塔机制实现了比PISA更强的安全性保证[32].BRICK方案将瞭望塔从单个节点扩充为多个节点构成的委员会,并假设委员会中至少三分之二以上的节点是诚实的.与PISA不同,BRICK方案采取了“主动防御”策略:瞭望塔不再对过期交易进行反制,而是让过期交易无法被合约接受,从根本上失去上链的可能.为此,该方案直接让瞭望塔委员会介入链下状态更新与链上通道关闭中.在链下状态更新环节,每个通道参与者都需要将包含所有参与者签名的通道状态哈希hstatei发送给瞭望塔委员会并等待委员会成员对hstatei进行签名,只有超过t个委员会成员签名的状态才被视为合法状态,t是综合考虑委员会成员离线或怀有恶意等问题后设定的阈值,一般按照拜占庭容错机制设置为瞭望塔节点总数的三分之二.对于链上关闭通道环节,如果关闭通道的close(statei)指令集齐了所有通道参与者的签名,则通道无需经过委员会即可关闭.如果参与者无法集齐签名,则任何通道参与者都可以将当前通道状态statei连同一个关闭通道请求发送给委员会成员.委员会成员会在一个共识周期内验证此状态是否为他们签署过的最新通道状态,所有认同statei的委员会成员对statei签名并发送给通道参与者,只有收集到超过t个委员会成员签名的关闭通道请求才会被合约接受,完成委员会批准的通道关闭操作.

BRICK方案的安全性来源于分布式系统和保证金两个方面.与单瞭望塔相比,这种分布式瞭望塔能够在三分之一的节点是恶意的情况下提供可靠的服务,而进行恶意行为的瞭望塔节点也会在初次作恶后被没收保证金并开除出瞭望塔委员会.这说明BRICK方案的安全性不再完全依赖于瞭望塔抵押的保证金,与PISA方案相比实现了更高的安全性保证.与此同时,分布式的瞭望塔设计使得瞭望塔委员会抵押的保证金由全部瞭望塔节点分摊,单一瞭望塔不在需要抵押大额保证金.但BRICK没有设计与分布式瞭望塔相匹配的激励机制,而是让全部参与签署新状态的瞭望塔均摊用户的服务费.在不提升用户服务费总额的情况下,这种方案在实际中很难部署.

Liu等人提出了Fail-safe方案[33]进一步减少了BRICK中所需的用户服务费.该方案通过引入审查机制进而使用单一瞭望塔取代了瞭望塔委员会.在Fail-safe方案中,瞭望塔不但需要介入链下状态更新与链上通道关闭,它还必须定期向通道合约发送通道最新状态序列号,并以此来向通道参与者证明其可靠性.

然而fail-safe方案只能提供与PISA方案相同的安全性保障.因为审查机制并不能保证瞭望塔不与恶意的参与者共谋,用户仍需监视区块链来收集瞭望塔违约的证据.因此Fail-safe方案在安全性保证方面和PISA完全相同,将安全性完全依托于瞭望塔抵押的保证金.不仅如此,定期向保证金合约提交最新状态序列号还增加了运行瞭望塔的成本,如果状态通道的参与者交易频率不高,提交状态所需要的交易费可能超过直接进行链上交易所需的交易费.

从整体上讲,虽然瞭望塔方案可以通过保证金机制实现更强的安全保障,但必须超过所有用户通道内资金总和的高额保证金也极大地增加了瞭望塔运营的成本,使瞭望塔运营者面临巨大的资金压力.因此,如何降低瞭望塔运行成本并实现强安全性保障是这些方案面临的一个十分重要的待解决问题.

6 总结与展望

为了保证轻节点能够安全地使用支付通道进行交易,区块链开发者提出了瞭望塔技术.但瞭望塔技术设计面临效率、用户链下交易隐私以及用户通道资金安全三个挑战.本文系统地整理了自支付通道瞭望塔出现以来关于瞭望塔的研究进展,根据其底层支付通道的不同将其分为比特币支付通道的瞭望塔技术和以太坊支付通道的瞭望塔技术,详细阐述了每一种瞭望塔技术的原理,并将这些方案纳入到统一的框架中进行比较,为了方便读者比较,我们绘制了表1展示这些方案的优势以及缺陷.

表1 各方案性能对比Table 1 Comparison of each watchtower scheme

在比特币支付通道瞭望塔中,现有的解决方案只能解决瞭望塔面临的部分挑战.由表1所示,Dryja的瞭望塔显著提升了用户隐私保护效果,Outpost协议在此基础上引入数据输出交易进一步提升了瞭望塔效率,DCWC瞭望塔与Cerberus瞭望塔分别使用分布式协议以及保证金机制提升了用户资金安全性.但是这些方案均无法在高隐私性低开销的前提下实现高安全性,仅有基于TEE的方案可以同时实现瞭望塔设计的这三个目标.然而该方案将用户私钥托管入TEE中,这将用户的通道资金安全完全托付于TEE,这种TEE的使用策略至今尚有争议,不断涌现出对TEE的侧信道攻击手段使得基于TEE的方案面临安全挑战[44].一旦攻击者通过侧信道攻击破解TEE中存储的私钥,攻击者就可以窃取支付通道中的资金.

在以太坊状态通道中,虽然基于保证金的方案可以为瞭望塔用户提供高资金安全性保证,但它们也显著增加了运行瞭望塔的成本,终将提升用户服务费,而这可能超过了用户自己运行一个全节点的成本,进而降低了瞭望塔的吸引力.不仅如此,除了服务费更高的BRICK方案,其余方案仅仅提升了支付通道参与者监视区块链的间隔,并不能允许用户彻底离线.

综上所述,支付通道的瞭望塔技术通过引入第三方(即瞭望塔)的方式为支付通道用户提供了一道额外的安全防线.然而,由于瞭望塔并不一定可信,因此将监视区块链的任务委托给瞭望塔并不能保证用户链下交易的安全.除此以外,瞭望塔的介入所导致的链下交易隐私泄露,和第三方提供服务的效率也同样是瞭望塔技术亟待解决的关键问题.目前已有的方案均未能同时兼顾安全性、隐私性与效率,这说明瞭望塔技术尚需进一步完善.完善现有的瞭望塔技术可以从以下两个方面入手:

第一种思路是设计可约束瞭望塔行为的协议.为了避免因瞭望塔的不可信或不作为而导致用户通道资金或者交易隐私遭受损失,约束瞭望塔的行为或许是一种可行的思路.举例来说,使用TEE设计瞭望塔协议可以实现约束瞭望塔行为的目标,提供可信执行的TEE不会执行恶意的操作.虽然目前学术界已经存在基于TEE的瞭望塔方案[30],但该方案将用户私钥托管于TEE中,虽然提升了瞭望塔的效率,但无法抵抗对TEE的侧信道攻击,这是此方案的核心缺陷.因此,如何在TEE不持有用户私钥的情况下,设计高效的基于TEE瞭望塔方案,是未来瞭望塔技术的研究热点.更加抽象地说,将TEE视为一道额外的安全防线,而不是完全取代现有的安全机制[45],或许是将TEE应用至瞭望塔领域的可靠思路.这样,即使TEE出现安全漏洞,系统的信任假设也只会收缩至未使用TEE之前,而不会威胁支付通道参与者的资金安全.

另一种思路是改进现有的保证金体系.现有基于保证金的瞭望塔运行成本过高,且并没有完全免除用户监视区块链的责任.通过引入信誉担保机制取代保证金担保机制可以降低瞭望塔的押金成本,并为用户提供可靠的担保.目前,基于区块链的身份信誉系统已有诸多详尽的研究,最受欢迎的区块链自主身份管理系统如uPort[46]与ShoCard[47]已经在学术界和商业界都有较大的影响力,并积累了一定的用户群体.这些身份系统允许瞭望塔运行者将其身份信息绑定到区块链中,从而以其身份信誉取代或部分取代基于保证金的担保机制.假使瞭望塔作恶,其作恶的证据将会被永远记录在区块链中,用户可以随时同步区块链收集瞭望塔作恶的证据,并根据瞭望塔身份信息向其索赔.由于瞭望塔的身份信息与作恶的证据会被永远记录在区块链中,用户可以在任意时间同步区块链收集证据,并向瞭望塔运行者索赔.这种设计思路不仅通过身份信誉作为抵押降低了运行瞭望塔的成本,也进一步减轻了用户定期监视区块链的责任,因此值得进一步研究.

得益于交易速度、隐私性、效率等方面的优势,支付通道协议已经成为链下扩容的研究热点.作为支撑区块链支付通道协议中不可或缺的一环,瞭望塔技术近年来也得到广泛关注和大量研究.本文系统梳理了区块链瞭望塔技术的主要进展,详细分析了现有瞭望塔技术的不足,并对其发展趋势进行了展望,从而为研究人员和开发者提供有用参考.