Layer2 Payment Channel 学习笔记

Hacker Dōjō Web3前沿技术 workshop文稿
资助金额:120 USDT
Bounty 链接:https://dorahacks.io/daobounty/160
内容贡献者:HTseaaat
赏金发布:https://bscscan.com/tx/0xf4597e873cb86b06361488d553715808cf786f7cb56ae91501c5ec67cd01d9f3
本项目由Hacker Dōjō 资助,文章转载请注明出处。
Telegram: @DoraDojo0
WeChat: @HackerDojo0
E-mail: hackerdojo0@gmail.com

一、背景知识

区块链目前很严重的一个问题是链上处理能力不足,比特币十分钟才能产出一个区块,换算成每秒处理的交易数目的话就是7 tps,而主流的支付方式例如visa每秒可以处理的交易数目是24000 tps。缓慢的交易处理速度严重阻碍了区块链和虚拟货币向日常支付这种小微交易场景的普及,制约虚拟货币日常化的另一个因素就是高昂的手续费,因此目前区块链处理交易是缓慢且昂贵的,我们的目标就是研究新的技术来让区块链可以快速、便宜并且安全的处理交易。

区块链不可能三角指的是目前的区块链不可能同时达到安全性、去中心化和可扩展性,只能三者取其二。安全性是指网络在受到攻击时的运行能力;去中心化指的是为了让区块链去中心化,硬件要求不能成为参与的限制,验证网络的资源要求应该很低;可扩展性指的是网络的吞吐量除以其验证成本。

关于如何提高区块链可扩展性目前已有很多解决方案,链上扩容的方案有sharding、更改共识协议,以及提高区块大小等,链下的扩容方案有状态通道、侧链以及Rollup等。在不妥协区块链安全性的前提下,我们需要找到一个保证去中心化的前提下提高可扩展性的方案。

链上扩容和链下扩容的区别在于,链上扩容需要对区块链本身的架构进行修改,而链下扩容则不需要,其主要思想是将计算和存储转移到链下进行,因此也能更好的融入现存的区块链系统中。

二、支付通道(Payment Channel)

支付通道是一种链下扩容技术,通过将频次高的小微交易转移到链下通道来提高链上性能。支付通道的生命周期包含三个阶段:开启通道、更新通道和关闭通道。

在开启通道阶段,通道用户双方要在链上锁定一定的金额,并记录双方的地址,用来作为链下交易支付的初始余额,当开启一个支付通道的消息在链上记录以后,双方就可以在链下开启一个通道,并规定通道的初始状态(状态版本号)为State 0。

|602x339.60208823701674

当支付通道中产生交易时,交易发送方需要发送一条带有更高状态版本号的消息给交易接收方,这条消息中要包含交易后的通道余额分配,以及交易发送方的数字签名。交易接收方在验证签名以后,根据发送的消息更新本地的余额分配和状态版本号,从而实现支付通道状态的更新。在支付通道中的交易只需要一次通信,并且不需要矿工对交易进行验证,交易的有效性是由对方数字签名保证的,因此也不需要额外的手续费。

通道的双方均可以在任意时间关闭通道,只需要提交存储在本地最新的状态上链验证,合约会给通道另一方留出一定时间作为挑战期,防止通道节点作恶行为的发生。

|602x383.43529152157873

如果发起通道关闭的节点上传了旧的状态版本号,在挑战期内,通道另一方可以上传存储在本地带有对方数字签名的最新的状态版本号作为挑战。链上合约首先验证数字签名的有效性,在签名有效的前提下,合约根据状态版本号更大的一方进行余额的分配。

三、支付通道存在的问题

在链下没有直接建立通道连接的双方想要进行交易需要用到哈希时间锁定合约(hashed timelock contract, HTLC)或者虚拟通道技术(virtual channel)执行交易的转发。

|602x418.84722836632886

哈希时间锁合约由两部分组成,哈希锁和时间锁。在HTLC中,交易的接收方会生成一个密钥并对其进行哈希,它保证了如果收款方在区块链上协商的时间内揭示哈希值的原像,就会进行支付。如果收款方没有显示原像,并且超时结束,那么此次多跳支付是无效的。时间锁保证了交易的原子性。HTLC具体协议流程如下:

  1. Bob选择一个随机字符串x作为原像,并将其哈希值h = H(x)发送给Alice;
  2. Alice发送一个带有自己签名的HTLC合约给Ingrid,合约声明 “如果Ingrid能在t1时间内揭示原像,Alice将向Ingrid支付v”;
  3. Ingrid发送一个带有自己签名的HTLC合约Bob,合约声明 “如果Bob能在t2(t2<t1)时间内揭示原像,Ingrid将向Bob支付v”;
  4. Bob向Ingrid揭示原像x,以赎回合约中的金额v;
  5. Ingrid向Alice揭示原像x,赎回合约中的金额v。

Ingrid作为中间转发交易的节点,会从中收取一定的中介费用作为激励。这也就带来了以下几个问题:

  • Ingrid的可用性限制了吞吐量
  • 每笔交易的路由开销(中介费)
  • Ingrid控制并监视了交易的隐私

针对以上问题,虚拟通道技术在支付通道之上再建立一层虚拟通道,Alice和Bob可以在虚拟通道中建立直接的联系,而不再需要Ingrid参与到每一笔交易中。

开启虚拟通道需要Alice和Bob同时向中间人Ingrid发送带有各方数字签名的请求消息,Ingrid会在验证签名有效性以后返回给双方一个带有自己数字签名的回应消息。开启虚拟通道的步骤与开启支付通道协议流程类似,区别在于虚拟通道中的双方余额来自状态通道,而不是来自链上,并且开启虚拟通道也不需要和链上进行交互。

在虚拟通道中发送交易的流程和支付通道的状态更新流程类似,也需要更新虚拟通道的状态版本号,在虚拟通道的整个状态更新过程中,并不需要中间人Ingrid的参与。

在关闭虚拟通道过程中,需要双方提交最新的带有双方数字签名的通道版本号,中间人Ingrid在验证签名有效后根据通道版本分配通道余额。虚拟通道从开启到关闭整个过程是不需要和链上交互的,中间人Ingrid在这里扮演了链上合约的作用,只有在双方存在作恶行为或者未在规定时间内作出反应的情况下,Ingrid才会与链上交互申请关闭通道。

链下多个支付通道就能组成一个支付通道网络,在支付通道网络中哈希时间锁合约可以保证交易的原子性,因此交易发送方可以任意选择交易路径进行支付。

支付通道另一个问题是通道再平衡问题,当通道双方都有余额时通道的流向是双向的,而当一方余额变为0,这时候通道的流向就变成单向的。朴素的解决方法是关闭通道再重新在链上锁定金额开启通道,但这会造成和链上交互导致的不必要的开销。

Revive通道再平衡方案依靠支付通道网络中的环状路径,通过选举一个领导者指示余额的流动路径,让环状路径中的用户余额从资金充足的通道转移到资金不足的通道。整个方案是在链下执行的,并不需要和链上有交互。

但是这个方案的效率是比较低的,想要完成一次成功的通道再平衡,需要满足以下条件:

  • 对于有再平衡需求的用户,他们想要再平衡的通道和需要的币流方向都可以在支付通道网络中形成定向循环;
  • 一个公平的领导者有必要收集用户的再平衡需求,找到定向循环,并公正地生成循环的再平衡交易;
  • 一旦通道再平衡周期建立起来,周期内用户都需要配合通道再平衡协议。

Shaduf是一个非环的通道再平衡方案,通过将通道之间进行一次性绑定以后,就可以无限次的进行链下支付,整个过程不需要和链上交互,只需要在通道关闭时调用合约进行通道余额的再分配。并且用户只将自己连接的通道间进行绑定,因此不需要和其他用户进行合作,从而避免了因用户不合作所带来的再平衡失败的问题。

|602x356.4740199586533

第三个问题是通道用户离线问题,如果通道用户在关闭通道的挑战期内离线,那么他将没有办法上传最新的版本号去挑战作恶节点,等挑战期时间过后,链上合约就会根据作恶节点上传的状态版本号进行余额的分配,从而导致诚实节点的金额损失。

|602x273.50534567832506|602x272.620374550773

支付通道通过引入一个第三方瞭望塔(watchtower)来解决这个问题,瞭望塔是一个链下24小时保持在线的节点,其余支付通道在状态更新后,将更新后的状态存储到瞭望塔中,瞭望塔会监视是否有作恶节点上传旧状态来获利,如果发现有节点作恶,瞭望塔会上传存储在本地的最新的状态版本号作为挑战,挑战成功则按最新的状态版本号进行余额分配并惩罚作恶节点。

支付通道最后一个问题是隐私问题,试想一下如果Alice想要选择一条成功的多跳支付路径发送交易给Zoe,她应该怎么做呢?

|602x350.5114565206004

如果Alice知道其他通道的余额,那么可以保证交易的成功率,但是带来的问题是会暴露用户隐私。

如果Alice只知道其他通道的余额总和,那么可以保护通道的余额隐私,但是交易的成功率会有所下降。

保护隐私的方案有很多,这里我们可以只在网络中公布一个公开余额(public balance),并用零知识证明保证公布在网络上的公开余额是小于等于通道的真实余额(true balance)。具体协议流程如下:

  1. 每个状态通道都有一个公开余额和真实余额;
  2. 利用零知识证明保证公开余额要小于等于真实余额;
  3. 所有通道广播自己通道的公开余额并隐藏真实余额;
  4. 交易发送方可以根据其他通道的公开余额选择交易路径转发交易;
  5. 在完成多跳交易后通道更新自己的公开余额并广播。

四、状态通道

支付通道是在链下开启一个通道处理交易,而状态通道则是在链下开启一个通道处理通用计算,因此支付通道可以算作状态通道的一个子集。