从闪电到雷电:雷电网络设计特色和待解决问题



  • 雷电网络是热门的以太坊链下扩容解决方案。以闪电网络技术理念为基础,以期打破区块链处理能力的瓶颈,实现即时确认、低费用、高吞吐量的支付。

    雷电网络的关键技术与闪电网络一致,包括RSMC、HTLC等。由于大家对闪电网络已经较了解,我们不妨再熟悉一下类似的雷电网络中介转账的基本机制:

    A向D转账,经由B和C的支付通道中介。A构造由secret解锁的哈希锁向B转账,由B和C按同样的secret解锁条件依次构造向C和D的哈希锁转账。然后A向D提供解锁的secret。D向C出示secret,拿到哈希锁转账中被锁定的代币,并得到C向D转账的余额证明。最后C和B重复此操作。(注意:雷电网络早期设计中,哈希锁的secret由付款人设置)

    交易双方只要在链上存在交易通道,就能在链下基于被锁定的余额进行高频、双向的即时确认交易。多个通道形成的支付路径构成“雷电网络”。

    虽然闪电网络技术已经在某些虚拟币上进行了应用验证,但雷电网络基于以太坊实现仍有自身的设计特色。在迈向实际应用中,还面临这一些需要解决的关键问题,其中也不乏与以太坊环境有关的新的问题。对于这些问题的解决和方案选择,关系到雷电能否实现其应用目标。

    1
    设计特色

    1.1 智能合约(The Netting Channel Smart Contract)

    不同于闪电网络基于多重签名地址建立支付通道,雷电网络的支付通道是被链上的一个智能合约所代表的。智能合约的作用是:

    (1)为通道运作提供参与方认同的共享规则
    (2)以托管形式持有代币,以支持链下支付
    (3)使用不能被一方滥用的规则进行仲裁争议

    智能合约将在通道运行期间代持双方代币,在通道关闭时根据双方提交的链下签名确认的余额证明,在链上更新余额分配。

    用智能合约建立支付通道在代码层面较基于多重签名地址实现相对简单,给雷电网络的开发提供了便利,并且支持更为灵活的条件判定。但也带来了新的问题,这一点我们在后文介绍。

    1.2 智能转账(smart transfers)

    HTLC(哈希时间锁)是闪电网络支付路径得以实现的关键,而雷电网络利用以太坊支持智能合约的条件,引入了更为通用的“智能条件(Smart Condition)”,实现智能转账(smart transfers)。

    Smart Condition可接受任何格式的报文为参数,执行后对支付通道上的余额进行调整。闪电网络中的HTLC,成为了Smart Condition中可实现的条件之一[1]。

    智能转账能够根据链上智能合约可读取的条件进行结算,提供较检验哈希值的HTLC更为丰富的功能,如支持预测市场、期货等条件,实现更为丰富的应用。

    1.3 组合锁

    闪电网络中,HTLC的解锁取决于到期时间和收款人能否出示符合哈希值的secret两个条件。

    HTLC的secret一般由收款人设置,将secret的哈希值提供给付款人。但是这样做存在一定问题,即转账中,如果Alice临时改变路径,不想通过C转账。或者C离线,无法转账,Alice需要更改路径。更改路径后,在上次的HTLC没有到期之前,Bob和C有合谋的可能,在Bob从新路径拿到代币后,Bob向C透露secret,使Alice在旧路径被锁定的代币损失。

    而雷电网络开发者考虑为锁设置由三个锁组成的组合锁,解决此问题。包括:

    (1)重试哈希锁(retry hashlock)。重试哈希锁的secret由付款人提供,可能会被付款人重新生成。重新生成一般发生付款人想改变路径的情况。
    (2)收据哈希锁(receipt hashlock)。收据哈希锁的secret由收款人提供。
    (3)时间锁(time lock),用于由付款人控制的锁到期时间。

    在到期前要解锁这笔转账,就需要重试哈希锁和收据哈希锁的两个secret,可称之为secretR和secretE。

    改造后,以Alice通过C中介转账给Bob为例,新的转账方式是:

    (1)收款人Bob发送收据哈希锁给Alice,自己保留收据哈希锁的secretE。
    (2)付款人Alice使用收据哈希锁和自己的重试哈希锁构造给C的转账,Alice自己保留secretR。
    (3)C按照同样的锁向Bob构建转账。
    (4)Alice确认以上转账构造完毕后,向Bob提供secretR。
    (5)Bob拥有secretR和secretE,向C出示,解锁转账,获得代币。C也获知了两个secret,向Alice出示,解锁转账,获得代币。

    这样做的好处是,只要Alice不提供secretR,Bob不能在转账中途向转账中介C提供secret,使Alice遭受资金损失。

    1.4 细节

    雷电网络在设计细节方面与闪电网络也有一定不同。

    其中,用来更新通道余额分配的报文,增加了序号字段和等待期字段以便识别作废的报文[1]。如果A向链上提交更新余额的报文后存在等待期,在等待期中,如果有序号更新的报文提交,A将受到惩罚。惩罚一般是罚没A在通道中锁定的代币。

    另外,在余额分配中,申明新余额分配的方式是出示余额分配的净增减,而不是重新申明余额,和闪电网络有形式上的差别[1]。可能也由于这个缘故,雷电网络的通道称之为“The Netting Channel(净通道)”。

    2
    待解决问题

    2.1 通道设立成本

    最初,雷电网络的设计是比较简单的,设计为为建立一个通道就建立一个对应智能合约。这样做的初衷是代码比较简单。但是开发中发现,这不是最佳的方案。

    主要的原因是建立一个新通道的智能合约消耗的GAS成本过高。有开发者表示,在某种情况下打开一个新通道花费的GAS超过94万GAS,远远超过了建立一个一般的智能合约的GAS花费。一般创建智能合约100GAS,交易500GAS。(该新通道设立TXhash:0x1072aef7fc754e016a086d463d93423532ab7ff6fc60a8b91601aabcc2551ed1)

    因此,开发者试图单独为每一个代币建立通道合约,管理该代币的所有通道。这不是一个非常大的问题,代币通道的合约可以由雷电网络等团队建立,以推进雷电网络的应用。

    但是这也带来一些不足,比如,通道合约的代币种类不足,可能难以全面覆盖长尾的代币交换需求。以及缺乏Smart Condition条件的灵活性,设计复杂等。

    更重要的是,一个代币一个合约,造成两个频繁交易的节点,必须为每一个代币交换单独建立一个合约,提高了由多币种交换需求转账的复杂性。

    2.2 中介在线激励

    中介转账(Mediated Transfers)是雷电网络转账的重要类型。由于全网节点间不可能全部两两间建立支付通道,在没有建立通道的节点间转账,就需要经由与付款节点和收款节点有通道联系的中介节点进行中介。

    目前中介转账的激励来自于转账的手续费用,然而转账激励不能等同于在线激励。手续费用激励节点在受到转账请求时提供服务,但不一定能激励节点在线等待提供服务。

    中介节点需要在线,包括在线以供付款方搭建转账路径,以及搭建转账路径后在一定时间范围内在线等待解锁secret。中介在线等待提供服务的需要在线的网络成本,以及等待中介转账业务的机会成本,中介会评估在线受到中介转账业务的概率。

    一旦转账路径上的一个中介没有被激励在线,中介无法收到转账请求,不能知晓转账费用,整个中介转账就无法完成。

    因此转账费用能否激励较多数量的节点,维持一个可以方便找到转账路径的网络,可能需要检验和更多的措施。

    2.3 中介转账撤回

    中介转账不一定经常成功。失败的中介转账被定义为付款者不泄露secret使哈希锁不能解锁。这可能有两个原因,或者付款者没有接受到收款者secret请求,或者发起者放弃,以不同的路径重试转账。

    因此,存在付款人撤回中介中HTLC的需要,从中介那里撤回被锁定的代币。

    雷电网络的开发者考虑一种新的锁的类型。这个锁可以由一个退款(refund)secret控制。一旦出示退款secret,在锁设定的到期期限之前,锁可以被解锁,代币被释放回付款人处。

    当然,这会增加锁的复杂度,毕竟已经考虑设置重试哈希锁、收据哈希锁等组合所的情况。

    2.4 中介路径查找

    中介转账路径查找是一个难题。在没有通道连接的两个节点间转账,需要找到能够连接两个节点的中介路径,路径的查找面临诸多问题:

    (1)缺乏全局的路径视图,无法获知节点间的中介路径,或者最短的路径
    (2)无法获知路径中的通道的余额最新状态,即无法确认中介路径上的通道是否有足够余额进行转账
    (3)无法预知中介路径上的通道是否将被关闭,因为通道任意一方可在几乎任意时候发起通道关闭

    雷电网络初期使用一个图形搜索策略(graph search strategy),使用储存的路径为路径的查找进行启发。

    以上图A转账给G为例,每个节点代表一个雷电节点,每个实线箭头都是一个现有的通道和转账的方向,虚线和红色箭头是一个疲惫/封闭的通道:

    “A决定在局部的第一个中介路径。A的选择是由它所认为的最短路径决定的,并将转账发送到该路径的第一个节点。B将协调转账并执行自己的本地路径查找,它选择了C,然后选择t,结果B和C都做出了次优选择。T无法通过它的通道完成转账,将通过D传送转账。这将继续下去,直到转账期满或达到目标。”

    我们注意到,官方出示的路径查找中,T可能重复地将转账转回B,这是一个多余的步骤。如果B能够预知T的通道不同向G,那么就没有必要向T的方向转账。具备全局的通道路径尤为重要。

    开发者考虑为雷电配置高级视图(advanced view)解决此问题,高级视图能够提供的信息包括:

    (1)通道年龄:通道的年龄可以作为通道声誉的代表,类似于信誉
    (2)通道连接性:具有高连接性(有更多通道数)的节点可能更容易成功转账
    (3)最短路径:全局图进行搜索最短路径

    然而,同步通道的余额状态仍是难点,因为这可能意味着链下交易需要快照上链,或者专门的节点或合约同步链下交易的余额证明。虽然这不需要用作通道关闭时最终结算的依据,但无疑与雷电网路的设计思路有所冲突,不容易实现。

    2.5 离线风险

    虽然雷电网络通过链下交易解决了很多问题,但缺乏链上在线的激励,需要采取更多的措施来填补其造成的问题。前文所述的“中介在线激励”造成的问题仅仅寻找是转账路径的困难,而此处的“离线风险”造成的问题是节点权益的损失。

    离线风险包括两类,通道关闭时一方离线的风险,以及中介转账时中介离线的风险。

    (1)通道关闭一方离线

    一旦通道的任何一方想要赎回代币或者争议出现,该通道就必须关闭。例如,A向智能合约调用关闭功能后,结算窗口就打开。此时,B需要调用updateTransfer函数向合约提交余额证明。

    如果B由于离线,不能及时提交余额证明,就将采纳关闭通道的参与者的余额证明,并假设其他参与者没有收到任何转账。这对B来说可能造成损失。

    (2)转账中中介离线

    考虑一个中介转账案例:

    A通过B向C转账,此时A>B的转账哈希锁已经建立,B>C的转账哈希锁也已经建立。C向B提供secret后,C拿到了B提供的转账代币。此时B应该向A出示secret,以拿到代币。但此时B宕机了。

    那么C有动机关闭和B的通道,以在链上确认拿到的代币。而A可能让和B之间的哈西锁自然过期,以收回被锁定的转账。此时B将受到损失。

    对此,开发者提出第三方(Third parties)的解决方案。

    第三方的目的是代表参与者在结算过程中操作。出于这个原因,第三方必须保持最新的转账、锁和秘密,即同步通道的链下交易状态。允许第三方调用关闭通道的close函数和更新通道余额的updateTransfer函数,以保障离线节点的权益。

    当然这种方案也可能出现一系列问题,比如如何保证第三方不和通道交易对手合谋等等。

    2.6 通道关闭问题

    通道关闭的问题与以太坊智能合约有关。

    在一方调用close函数关闭通道后,会开启结算窗口,设置一个settlement_timeout作为结算的时限。然而由于结算需要调用updateTransfer函数等事务,消耗GAS。在某些情况下,当区块的GAS数量不够,以及没有足够可用的GAS支持结算完成。

    开发者提出一种可用GAS证明“proof of available gas”的方案。首先需要预测每一个操作的GAS花费,此后关闭通道的节点必须提供一些区块高度,合约将检查区块高度的可用GAS。

    3
    总结与讨论

    可以看到,雷电网路虽然有闪电网络技术作为基础,但在以太坊上实现式仍做了大量的改进。重点的改进包括,设置重试哈希锁、收据哈希锁、时间锁组成的组合锁,以使在中介转账路径搭建完成前,任何一方不能擅自动用被锁住的代币,并且使付款方有重新选择新的路径转账的可能;提供智能转账,可设置较HTLC更多灵活的余额结算条件,支持更丰富的应用。

    在以太坊环境搭建支付通道,也遇到了一些新的问题,主要是通道合约设立的成本和通道关闭的GAS问题。然而这些问题均有解决方案,并不十分突出。

    雷电网络待解决的问题,最突出的有两个。

    一是离线问题。离线造成中介转账的路径不能顺畅地搭建,也造成了通道关闭和中介转账中,离线节点代币损失的风险。

    也许有观点认为,这是离线节点自己的责任。但对于一个项目开发者而言,如果将因离线造成的代币损失的责任全部归咎于离线节点本身,这可能是不负责任的。毕竟链上的点对点交易,节点离线并不会造成损失。尤其是当节点有多个通道,面临无法预知的通道关闭时间,无法保持实时在线,解决离线风险是很有必要的。

    二是路径查找问题。也许通过高级视图,可以快速实现最短中介转账路径的查找。但同步通道的最新链下交易状态,仍是一个难点。

    当然,以上两个问题也有比较方便的解决办法,那就是支付中心。通过若干个和大量节点保持通道的支付中心,可以大量节省路径查找的问题,以及减少转账中介离线的可能,因为支付中心处于经济激励考虑会时常在线。但是仍无法解决支付中心在普通节点离线时,关闭通道的风险。此外,也有支付中心的管理风险。因为如果支付中心在同一时刻因为某种原因,关闭所有通道,对链上区块的GAS消耗是很大的,可能造成拥堵。

    但总的来说,雷电网络和闪电网络能够实现的性能仍是使人振奋的。它有望实现大部分的高频转账功能,非高频的转账还是留给链上更为方便。

    引用说明:
    [1] 《详解最近大热的闪电网络、雷电网络和CORDA》朱立
    其他关于技术方案的引用来自于https://github.com/raiden-network,不一一注明



  • 有点专业的,学习先


Log in to reply
 

Looks like your connection to Asch was lost, please wait while we try to reconnect.