区块链链下通道研究综述*

2024-04-28刘懿中陈若楠刘建伟

密码学报 2024年1期

刘懿中, 姜楠, 陈若楠, 刘建伟

1.北京航空航天大学网络空间安全学院, 北京 100191

2.密码科学技术全国重点实验室, 北京 100878

1 引言

2008 年, 比特币[1]的出现带动了对数字货币的研究热潮, 而作为数字货币底层技术的区块链技术也成为了一个备受关注的研究领域.区块链的本质是一种分布式、去中心化的账本, 此账本记录了所有参与者的一系列交易和事件, 这些记录以区块的形式链接在一起, 形成一个不可篡改的链条.区块链的发展为各种领域带来了创新的可能与机遇, 尤其是在医疗、金融等领域[2].但区块链在可扩展性方面的缺陷也限制了其应用与推广.当前, 比特币的交易吞吐量大约为3–7 TPS (transactions per second), 以太坊[3]大约为10–20 TPS, 而中心化支付服务提供商VISA 大约为3000 TPS[4].显然, 当前的区块链数字货币平台难以满足人们的支付愿景, 因此, 解决区块链的可扩展性问题进而提高交易性能是必须的.

1.1 区块链概述

区块链是一个分布式数据库, 其中存储了各种记录的有序列表.记录存储在链接的块中.块之间的链接通过哈希函数实现.

一个区块主要由区块头和区块体构成.区块头记录了区块的基本信息, 例如版本号(version number)、前一区块的哈希值(previous block hash)、默克尔树根值(Merkle root)、时间戳(timestamp)、随机数(nonce) 等.区块体一般记录了当前区块内的交易信息, 例如转账的发送方、接收方、交易金额等.

默克尔树(Merkle tree)[5]是一种哈希树的数据结构.这个树结构是由计算机科学家Merkle 在1987年首次提出的, 默克尔树在区块链中的应用主要包括快速比较大量数据、快速定位修改、隶属证明、隐私保护等.

在区块链的交易过程中, 通常需要用到智能合约[6]技术.智能合约是根据预先编写好的规则诚实执行的合约, 交易双方的协议条款直接编写成代码, 该代码及其中包含的协议存储于分布式的区块链网络上,而不是中央位置.区块链的不可篡改性确保了智能合约一定会诚实地按照其预先定义的规则(编写的代码) 执行而不会被篡改.

两种最典型的基于区块链的加密货币是比特币(Bitcoin) 和以太坊(Ethereum).比特币于2008 年由中本聪(Nakamoto) 提出, 使用工作量证明(proof of work, PoW) 共识算法来验证和添加新的交易到区块链.矿工通过解决复杂的数学问题来创建新的区块, 并获得比特币奖励作为激励.比特币具备一定的稀缺性, 因为其总供应量被固定在2100 万枚, 因此也被用于投资和交易.以太坊由Buterin 等人于2015 年创立, 作为一种开源的区块链平台, 以太坊不仅是一种数字货币, 还是一个智能合约平台, 允许开发者创建去中心化的应用程序(DApps), 以实现更广泛的区块链应用.以太币(ETH) 是以太坊的货币.

1.2 区块链三元悖论

如表1 所示, 区块链系统有三个重要特性: 第一是可扩展性[7].在面对增加的用户数量、交易量或数据量时, 区块链网络的性能和吞吐能力可能会受到限制, 导致系统变得缓慢、不稳定甚至不可用; 第二是安全性[8].网络容易受到各种安全漏洞的影响, 例如51% 攻击、女巫攻击、零钱攻击、分布式拒绝服务攻击(DDoS)、合谋攻击等; 第三是去中心化[9].虽然区块链被设计成一个去中心化的系统, 但在实际运行中, 一些问题可能导致权力集中在少数节点或实体手中, 从而破坏了系统的原本去中心化目标.

表1 区块链三特性Table 1 Three characteristics of blockchain

类似于传统分布式系统的三元悖论(CAP 定理[13]), 区块链系统也存在着三元悖论问题[14]: 可扩展性、安全性、去中心化无法同时满足, 即最多只能满足其中的两个.例如, 比特币是一种典型的去中心化虚拟货币, 采用工作量证明的共识机制来保证安全性, 但正是由于共识机制的限制降低了其交易处理速度;分片技术是一种提高区块链可扩展性的途径, 将区块链分割为不同区块, 每个分片可以并行处理交易, 但在一些情况下某些分片可能会集中大量的交易, 因此降低整体的去中心化程度.所以, 平衡甚至实现这三个方面的性质, 使区块链能够更适合生活中更复杂、更大规模的场景, 对于区块链的未来发展尤为重要.

1.3 可扩展性问题及解决方案

影响区块链可扩展性[15]的主要因素如下:

(1) 吞吐量: 吞吐量是指每秒确认的交易数量.在比特币中, 吞吐量大致为每秒3–7 个交易, 而对于以太坊, 它是15 TPS 左右.这些都无法与现今流行的支付系统相比, 如VISA 提供3000 TPS, Paypal 提供193 TPS, Apple Pay 的吞吐量为385 TPS.有限的交易吞吐量将导致区块链网络的拥塞.当交易的数量超过最大区块大小时, 一些交易将不得不等待另一个区块被包括在区块链中.

(2) 交易延迟: 交易延迟指的是提交交易到网络并最终写入区块链的整个过程所花费的时间.当用户发送一笔交易时, 这笔交易需要被网络中的节点广播、验证、打包成区块, 并被添加到区块链上.交易延迟涉及从交易发送到交易确认的整个时间间隔.随着区块链的不断增长, 更多的交易将被提交到区块链, 延迟也会受到影响.

(3) 交易费用: 交易费用是指在进行区块链上的交易时需要支付的费用.这些费用用来激励矿工或验证节点, 以激励他们验证、打包和添加交易到区块链中.交易费用通常以加密货币的形式支付, 如比特币.

(4) 存储: 区块链的存储限制是由于区块链的不断增长以及参与交易的每个节点都需要在区块链上保存完整的数据记录导致的.所有参与节点都必须拥有大量的存储容量, 以确保区块链上写入数据的安全性.但随着区块链规模的发展, 越来越少的节点能够在其硬件上存储整个区块链, 网络的分散性将降低.

针对区块链可扩展性问题的解决方案主要有两种: Layer-1 扩容和Layer-2 扩容.Layer-1 扩容也称为链上扩容, 主要针对区块链协议本身进行改进或优化, 以增加整个区块链网络的交易处理能力和吞吐量.Layer-1 扩容的目标是通过提升底层区块链协议的性能, 实现更高效的交易确认和区块生成, 从而应对网络拥堵和交易延迟的问题.Layer-1 扩容的主要方案包括: 区块生成时间和大小优化、共识机制[16]改进、分片技术[17].Layer-1 扩容可以在一定程度上提高区块链的性能, 包括交易吞吐量和交易延迟, 但对于区块链底层协议的变更可能会引入新的安全风险和漏洞, 例如, 分片技术增加了区块链设计的复杂性和困难性, 同时因为某些分片集中处理大量交易, 从而降低了整体网络的去中心化程度.

Layer-2 扩容[18]也叫做链下扩容.与Layer-1 扩容不同的是, Layer-2 扩容通常不需要对底层区块链进行大规模的修改, 这意味着现有的区块链可以通过附加Layer-2 协议来获得更好的性能.在Layer-2 扩容方案中, 实际交易在Layer-2 上发生, 但最终的结算结果会被提交到底层区块链, 以确保安全性和可审计性.同时, 通过将交易从底层区块链迁移到Layer-2, 可以降低交易费用, 因为Layer-2 上的交易通常更便宜且更快速.Layer-2 扩容的主要方案包括: 链下通道(off-chain channels)、侧链(side chains)、跨链(cross chains).其中, 侧链[19]是独立于主链且与主链并行运行的区块链, 其主要目的是分担主链上复杂的计算任务, 同时, 它还允许资产在不同区块链间进行转移.一般而言, 每一个侧链都有自身的共识机制来处理交易, 侧链与主链之间通过双向锚定(two-way peg) 进行通信和资金转移.跨链[20]可以帮助不同种区块链之间的用户完成资产转移, 从本质上来看, 跨链相当于区块链间交易的中介.

Layer-2 扩容方案往往更适合区块链, 因为它们不需要对区块链的原本设计进行重大修改, 更容易直接在现有平台上应用, 同时能够保证去中心化和安全性等区块链特性.

1.4 链下通道概述

链下通道[21]是Layer-2 扩容的一种重要技术手段, 旨在将交易转移至链下进行, 而只将最终结果提交到区块链, 从而提高交易吞吐量和降低交易成本.链下通道对底层区块链系统有较大的依赖性, 因为为了保证安全, 必须假设在通道上发生的任何交易都可以在需要时在链上发布.链下通道要求参与者在链上锁定一部分资产以用于交易和奖惩, 此种机制能够满足在用户之间建立信任的要求, 并且能够保证各方根据协议进行操作, 因为参与者都在链上锁定了资产, 任何违反协议的操作都将导致资产的损失.在实际应用中, 链下通道一般有两种工作状态: 在乐观情况下, 没有参与者试图欺骗他人, 参与者之间的交易能够在链下准确有序进行; 在悲观情况下, 系统中可能存在试图欺骗他人的参与者, 此时需要区块链采取一定的争议解决机制, 对争议进行处理.

状态通道是一种基于区块链技术的扩展方案, 用于提高区块链网络的吞吐量和效率.在状态通道中,参与者可以在链外进行交易, 只在需要时将最终结果提交到区块链上, 从而减轻了区块链上的交易负担.这种方法可以有效减少交易的处理时间和费用, 并且能够实现更高的吞吐量.状态通道可以应用于各种场景, 包括游戏、身份验证、去中心化交易所(decentralized exchange, DEX)、供应链管理等.它们是一种被广泛认可的解决方案, 可用于提高区块链网络的可扩展性和效率.

链下通道的主要工作阶段包括:

• 创建阶段.在此阶段, 参与者必须通过协议创建通道.参与者需要将一定数量的资金锁定在通道的智能合约中.这些资金将用于通道内的交易, 并当参与者作恶时扣除作为惩罚.如果在争议解决阶段判定参与者有恶意行为, 智能合约将罚没他们预存的资金.通道参与者必须签署一个他们一致同意的初始状态.该初始状态表示链下通道的开通, 之后用户可以开始交易.

• 更新阶段.此阶段是链下通道功能实现的核心阶段.在此阶段, 参与者通常通过加密签名的消息直接进行相互通信, 而不与链上互动.此消息通常包括一个随机数, 用于标记交易的序列号, 并防止重放攻击.通过这样的消息, 一个参与者可以向其他参与者提出交易, 同时也能验证并接受其他参与者提出的交易.消息的交互是在链下进行的, 这与链下通道最大限度减少链上负担的目标一致.

• 争议阶段.如果参与者的行为偏离或者违背协议, 则链下通道进入到争议阶段.参与者如果对通道的交易或者状态有异议, 可以提出争议, 争议通常涉及交易的金额、顺序、时间戳等方面.提出争议的参与者需要将争议提交到链上进行解决.在提交争议后, 相关的参与者需要提供与争议有关的证据, 如签名、交易数据等.这些证据将帮助区块链了解争议的背景和内容.区块链依据证据进行评估和仲裁, 以解决争议, 并在链上执行相应的仲裁结果.当争议被解决时, 通道可以返回到更新阶段或前进到关闭阶段.

• 关闭阶段.在此阶段, 链下交易的最终结果将被写入区块链, 同时, 将根据交易结果计算预先锁定资金的剩余值, 并返还给参与者.在乐观情况下, 当参与者完成交互并且所有人都同意将其结果发布到区块链系统时, 通道顺利关闭.但当通道内发生争议时, 将根据区块链的仲裁结果完成资产重新分配, 通道关闭.

1.5 本文贡献

本文主要研究了以下内容:

(1) 总结了区块链的三元悖论问题, 详细解释了区块链可扩展性问题的影响因素以及现有解决方案.(2) 总结了链下支付通道的基本工作流程, 包括通道创建、通道更新、争议解决、通道关闭.

(3) 总结了链下支付通道方案的评判标准, 包括鲁棒性、隐私性、是否允许多方参与、是否支持即时存取款等内容.表2 展示了各类链下通道方案的特点, 其中, 适用性指链下通道可应用于何种区块链加密货币平台, 鲁棒性指的是通道在面对各种异常情况时的稳健性和可靠性, 灵活性指的是通道允许节点的随时加入和退出, 隐私性指的是参与者在通道内部进行交易时的隐私保护程度, 多方参与指通道支持多节点参与其中, 即时性是指通道允许节点随时向通道内存取款, 跨节点指通道支持两个不直接相连的节点跨中间节点进行交易.

表2 链下通道总结Table 2 Summary of payment channels

(4) 分类研究了链下支付通道方案, 分析了各类链下通道的基本原理(各支付通道的核心技术概括性比较如表3 所示)、典型方案和优缺点.根据支付通道中参与者的数量可以分为双方支付通道和多方支付通道.对于双方支付通道, 依据实现原理和功能的不同, 又可分为普通支付通道、基于HTLC 的支付通道、虚拟通道、支付通道再平衡.根据通道的匿名性, 又可单独分出匿名支付通道.

表3 链下通道核心技术比较Table 3 Comparison of off-chain channel core technologies

双方支付通道在两个用户之间构建可信的链下通道, 以实现对区块链的扩展.典型方案包括雷电网络[22]、AuxChannel[23]、Sleepy Channels[24]、闪电网络[25]等.

基于HTLC 的支付通道利用HTLC 路由技术, 实现跨界点的链下交易.典型方案包括闪电网络[25]、RobustPay[26]、RobustPay+[27]等.

支付通道再平衡解决通道内参与方资金枯竭的问题, 通过在链下通道间进行余额的重新分配来避免链上“充值” 的代价.典型方案包括Revive[32]、Cycle[33]、Hide & Seek[34]、Shaduf[35]、Musketeer[36]等.

虚拟通道为两个不存在直连通道的节点建立虚拟连接, 以完成双方交易.典型方案包括Perun[28]、BCVC[29]、Elmo[30]、CCVPV[31]等.

多方支付通道实现通道内的交易可以有多个用户参与, 在某些场景下能够提高通信的效率.典型方案包括Sprites[37]、Garou[38]、Magma[39]等.

匿名支付通道实现通道内节点及交易信息的匿名性, 以保护用户隐私.典型方案包括Bolt[40]、MAPPCN[41]、A2L[42]、BlindHub[43]等.

各种链下通道方案之间存在着诸多联系.普通支付通道是一种简单的双方通道, 只允许两个参与者之间进行交易.基于HTLC 的链下通道在普通支付通道的基础上进行构建, 多个普通支付通道线性链接在一起, 并利用HTLC 协议进行资金转移和跨链支付.虚拟通道是一种扩展的支付通道, 允许节点在已有通道的基础上建立虚拟链接, 以实现跨节点的高速交易.多方支付通道允许多个参与者之间进行交易, 而不仅仅是两个参与者之间, 这种通道可以通过在多个参与者之间建立连接来实现资金的流动, 从而支持多方之间的复杂交易.匿名支付通道在支付通道的基础上增强用户的隐私保护特性, 通常使用零知识证明或其他匿名化技术来隐藏交易的相关信息, 以确保参与者的身份不被公开.不同种通道在实现方式、功能和适用场景上有所不同, 但它们都是为了解决区块链技术中的可扩展性和性能问题而设计的, 它们共同的目标是提高交易效率、降低交易成本、保护用户隐私和增强交易安全性.

(5) 分析了未来链下支付通道的研究热点和发展方向.

1.6 相关工作

链下支付通道是解决区块链可扩展性问题的一个可行方案, 能在一定程度上保证区块链的去中心化、可扩展性和安全性, 近年来国内外对于链下支付通道的综述研究主要包括以下内容:

在国外研究方面, 文献[44] 主要梳理了链下通道的发展历史, 解释了各种链下通道的由来以及发展趋势, 但对具体技术细节缺乏分析.文献[45] 研究了区块链可扩展性问题的主要解决思路, 包括Layer-1 扩容和Layer-2 扩容, 总结了每种扩容思路基本流程, 但缺少对典型方案的总结和对比; 文献[46] 主要关注Layer-2 扩容方案, 包括支付通道、侧链、跨链技术、链下计算等, 对于每种方案, 给出了基本原理和典型案例, 但对于每一类方案的介绍较为简单.

在国内研究方面, 文献[47] 主要研究链下通道路由算法, 梳理了10 种典型算法及其发展历程, 并对算法进行了评价分析, 但缺乏从整体角度对链下通道的解释和探讨; 文献[48] 研究了比特币区块链扩容技术, 包括链上扩容和链下扩容两方面, 对链上扩容的安全性以及链下扩容的效果进行了分析, 研究方面更为宽泛但对链下通道的总结不够详实; 文献[49] 总结了4 种区块链可扩展性问题的解决方案, 包括链下通道、Bitcoin-NG、分片机制和跨链技术, 分析对比了不同方案的特性、适用场景及优缺点, 但缺乏对链下通道的进一步分类和解析.

本文对链下通道的研究总结如表2 所示.其中, 符号“/” 代表当前系统没有该特性值或没有具体可查的系统参数; 符号“√” 代表满足当前特性; 符号“×” 代表不满足当前特性.

2 双方支付通道

2.1 概念

一个双方支付通道是一个构建在两个参与者之间的可信链下支付通道, 以实现两个参与者的快速链下支付.双方支付通道中, 两方参与者首先需要在链上锁定一部分资金, 然后在链下进行多次交易, 每次交易都会更新双方的资金分配, 但不会广播到链上.只有当双方想要关闭通道时, 才会将最终的资金分配结果提交到链上, 解锁资金并分配给双方.这样可以减少链上的交易次数、提高支付效率、降低手续费, 并保证双方的资产安全.双方支付通道可以分为以下三类: 第一类是一般的支付通道, 是后续对链下通道改进工作的基础; 第二类是基于HTLC 的状态通道, 是一种利用哈希时间锁机制对支付通道的扩展方案; 第三类是虚拟通道, 是一种基于一般支付通道建立的更深层次的链下通道.

2.2 典型方案分析

2.2.1 支付通道

(1) 闪电网络(lightning network)

闪电网络[25]是一种典型的支付通道方案, 旨在解决比特币的可扩展性和性能问题, 是一个与比特币区块链并行运行的链下支付通道网络.在闪电网络中, 大部分交易都是链下进行的, 而不是立即记录在比特币主链上.这意味着交易不必等待区块链的确认, 从而避免了区块链上的交易延迟.从理论上讲, 闪电网络每秒可实现的交易数量达百万级别.同时, 链下交易也意味着更低的交易费用, 这也是闪电网络的主要优势之一.

闪电网络包括三个阶段: 建立通道、交易、关闭通道.其主要工作过程如下:

• 通道开启.在开始交易之前, 双方首先在通道中保存了一定数量的比特币作为存款(大于后续交易所涉及的总金额), 用于后续链下交易, 同时被记录在比特币主链上.

• 通道更新.通道开启后, 双方可以在通道中相互交易, 如果其中一方作弊, 该通道中的所有存款将被发送给对方作为惩罚.

• 通道关闭.当关闭通道时, 双方的最终余额提交给比特币主链, 主链将通道内的资金根据交易双方各自的最终余额分配给参与者.

多个支付通道可以构成支付通道网络(payment channel network, PCN)[50], 使没有直接建立支付通道的双方之间能够完成链下交易, 即两个想要交易的节点之间没有直接支付通道, 但有诸多中间节点, 这两个节点便可以通过路由技术借助中间节点完成交易.例如, 闪电网络的网络示意图如图1 所示, 其中, 节点1 可以通过两个通道(节点1-节点2-节点3) 完成与节点3 之间的交易.

图1 支付通道网络Figure 1 Payment channel network

闪电网络中的多个交易都是在链下完成的, 整个流程只产生两条提交给主链的交易记录, 即建立通道时的资金锁定记录和关闭通道时的余额上传记录, 因此可以大大提高交易吞吐量.不过, 闪电网络的缺陷也非常明显.第一, 链下通道要求双方同时在线; 第二, 闪电网络的大额交易成功率较低, 即目前闪电网络不适合处理大额交易; 第三, 部分节点可能会频繁作为路由节点, 导致这些节点的中心化, 从而影响区块链的去中心化性质[51].

(2) 雷电网络(Raiden network)

与闪电网络的原理类似, 雷电网络[22]也是一种链下支付通道网络.不同的是, 雷电网络是对以太坊区块链的补充, 可以与任何ERC20 兼容的代币配合使用, ERC20 是以太坊区块链上的一种代币标准, 它规定了代币的基本功能和交互方式.

雷电网络的工作原理是在以太坊网络上的双方之间建立链下支付通道.这些支付通道是使用智能合约创建的, 无需中介即可实现各方之间安全快速的交易, 因此是去中心化的Layer-2 扩容方案.与闪电网络类似, 雷电网络也使用支付通道网络来实现没有建立直接支付通道的各方之间的交易.

雷电网络用以保证其通道内的交易安全、正确的技术是余额证明(balance proofs), 余额证明包含一方发送给另一方的所有通道内转账的最终金额, 并由发送方进行数字签名.具体而言, 在通道建立后, 交易双方可以在通道内进行多笔交易, 当一方想要在区块链上结算余额时, 无论是接收还是转出资金, 都可以向智能合约出示余额证明来关闭通道.同时, 当一方选择关闭通道时, 另一方也必须出示余额证明.双方提交余额证明后, 由区块链验证通过, 便可以实现资金的转移.

雷电网络的两个主要子项目是: 雷电轻客户端(Raiden light client) 和µRaiden.雷电轻客户端是轻量化的雷电网络, 允许用户在不运行完整节点的情况下, 通过轻客户端访问网络, 并可以与完整的雷电节点进行通信, 以执行链下交易和智能合约功能, 轻客户端为移动设备和基于网络的应用程序提供了轻量级的雷电网络通道服务.µRaiden 是基于雷电网络的多对一的单向、轻量级、微支付通道协议, 旨在提供适用于小额支付的通道技术, 使以太坊上的微支付变得更加容易和实用.µRaiden 特别适用于频率高但涉及金额小的交易, 例如在线游戏交易等.

雷电网络具备与其他区块链进行跨链互操作的能力.通过减少链上交易的需求, 雷电网络能够有效降低交易的费用, 同时, 链下交易比链上交易具有更好的隐私性.但是, 由于通道的正确运行依赖于智能合约, 所以智能合约的安全性决定了雷电网络的安全性, 如果智能合约被攻击者攻击, 那么雷电网络的安全性也将遭受严重威胁.

(3) Sleepy Channels

在一个双方支付通道中, 交易双方需要不断监控区块链, 以确保对方没有发布过时的交易信息.一旦作恶一方向链上发布了过时的交易信息, 则诚实的一方会向链上提供证据, 以对作恶行为做出惩罚.这意味着交易双方需要时刻保持在线, 否则无法对链上行为进行监控, 进而被恶意用户利用.为了保证交易一方断线时的资产安全性, 链下通道一般引入瞭望塔(Watchtowers) 机制.瞭望塔是一个代表离线用户监控区块链的第三方, 可以帮助用户完成惩罚工作.瞭望塔机制的限制在于, 要么瞭望塔是可信的, 这是一种很强的安全假设.要么瞭望塔在工作前率先锁定一部分资金, 以便追究其责任, 这在大型支付通道网络的资金层面是很难实现的.

Sleepy Channels 由Aumayr 等人[24]提出, 解决了支付通道网络对于瞭望塔的依赖问题.当不可信的双方想要构建Sleepy Channels 时, 双方需要额外抵押一部分资金, 以保证通道的安全性.具体而言, 如图2 所示, Alice 和Bob 之间已建立链下通道, 在通道创建时, 依据块高设定时间T, 用户只需要在T之前在线一小段时间即可,T之前可以放心离线.设定f表示通道内锁定的资金总量;vA、vB分别代表Alice、Bob 在通道内的余额;f=vA+vB.假设Alice 想要关闭通道, 对于Alice 来说, 她本地记录了通道的当前状态, 即认为Alice 有vA, Bob 有vB, Alice 把她的状态上传到链上, 对于vA来说有三种可能:

图2 Sleepy Channels 示意图Figure 2 Diagram of Sleepy Channels

• Bob 离线, 当时间超过T之后, 解锁.

• Alice 发布的是过时的状态, 同时Bob 在T之前在线, 对其提出争议, 惩罚vA给Bob.

• Bob 在线, 确认Alice 上传的状态是对的, Bob 拿回自己的余额, 此时Alice 也可以解锁她的余额.

如果是Bob 想要关闭通道的话, 情况是类似的.

(4) AuxChannel

AuxChannel 由Sui[23]等人提出, 旨在为无脚本功能的区块链提供链下通道.由于大多数链下通道的运行都需要复杂协议的支持, 即要求区块链具备一定的脚本能力.因此, 为无脚本功能的区块链设计链下通道是有必要的.AuxChannel 仅要求链上支持可验证加密签名(verifiably encrypted signature), 而无需任何脚本能力.为提高AuxChannel 的高效性提出了一种新的密码学原语, 称为连续可验证加密签名(consecutive verifiably encrypted signature, CVES).

CVES 允许签名者使用他的加密密钥序列来加密他的签名, 同时, 这些加密的签名是可验证的.更重要的是, 加解密密钥对是连续的, 这意味着最新的密钥对是从它们的前一个会话中导出的.所以, 验证者既能保证加密签名的正确性, 又能保证签名者密钥的连续性.因此, 整个过程变得更加高效, 但AuxChannel的隐私性有待进一步研究和提高.

2.2.2 基于HTLC 的状态通道

(1) HTLC 概述

在支付通道网络中, 若两个节点之间并不存在直接的支付通道, 但存在一条包含若干中间节点的通路,则这两个节点可以通过哈希时间锁定合约(hash time lock contract, HTLC) 完成交易.HTLC 实现了借助他人的支付通道执行跨多个中间节点的支付, 而无需再建立一条直连的通道.

(2) 闪电网络的HTLC

作为一种主流的资金路由技术, HTLC 在很多链下通道方案中得到了应用.最早应用HTLC 的链下通道是闪电网络.为了允许两个不存在直连通道的用户能够执行交易, 闪电网络引入了HTLC 技术.闪电网络中HTLC 的运行流程如图3 所示, A 和C 想要交易, 例如A 想要给C 转账1 BTC, 但A 和C 之间不存在直连的通道, 但A 和B 之间存在通道, B 和C 之间存在通道, 则可以借助B 作为路由完成A、C 之间的交易.过程如下:

图3 哈希时间锁原理Figure 3 Hash time lock contract principle

• 计算哈希值.首先C 随机生成原像R, 并根据原像计算其哈希值H= Hash(R), 并将H发送给A.

• 锁定资金.A 接收到H后, 将H发送给B 以启动HTLC 协议, A 锁定1.01 BTC 在HTLC 上,A 和B 之间形成约定: 在两天时间内, 若B 能揭示出原像R的值, 则A 给B 转账1.01 BTC,多出的0.01 BTC 作为对B 充当路由的奖励.值得注意的是, 此处约定的时间是一个假设, 整个通路中中间节点越多, 其值可能越大; B 接收到H后, 同样锁定资金, 并与C 达成约定: 在一天时间(比之前约定的时间更少) 内, 若C 能揭示出原像R的值, 则B 给C 转账1 BTC.

• 解锁资金.C 在约定时间内将R值发送给B, 并从B 处接收1 BTC 的转账; 同理, B 也能从A处得到对应转账金额.

在此过程中, 中间节点B 若想从A 处得到1.01 BTC, 就必须先根据合约支付1 BTC 给C 以得到原像R, 因此B 没有机会窃取资金, 便不存在不可信第三方的威胁.在本次交易过程中, 中间节点B 的两条通道内的资产状态发生了改变, 但总资产状态(除奖励外) 没发生改变.HTLC 协议就是使得两条支付通道在变化过程中相互协调, 安全地从一种状态变为另一种状态, 确保路由交易过程中自身资产的安全性.

在闪电网络中, HTLC 容许时间(HTLC tolerance) 被定义为两个节点约定HTLC 协议的时间限度,即一方需要在容许时间内揭露哈希原像才能获得对方的转账.容许时间的大小被定义为距离转账接收方的跳数, 例如, 假设C 作为转账的接收方, B 与C 间隔1 跳, 则B、C 之间的容许时间为1, 如果A 与C间隔2 跳, 则A、C 的容许时间为2.这种设计可以保证每个通道都有足够的时间执行HTLC 合约.

(3) RobustPay

RobustPay[26]是一种针对比特币支付通道网络的具备鲁棒性的支付路由协议, 基本流程如下:

• 交易发起.发送方向网络中的某个节点发起支付请求, 指定接收方和支付金额.

• 计算路径.节点使用本地信息和网络信息计算出两条不相交的路径, 分别用于正常支付和备用支付.

• 哈希锁定.发送方向接收方发送支付请求, 包括两条路径和相应的哈希锁定时间合约.

• 支付.接收方验证支付请求, 并在两条路径上选择一条进行支付.如果正常支付路径上的支付成功,接收方向发送方发送原像, 以解锁HTLC 并完成支付.如果正常支付路径上的支付失败, 则接收方可以选择备用路径进行支付.如果备用路径上的支付成功, 则接收方向发送方发送原像, 以解锁HTLC 并完成支付.如果备用路径上的支付也失败, 则支付失败.

RobustPay 对传统的HTLC 协议进行了修改, 提高了路由协议的效率和鲁棒性.改进之处是, 如果接收方没能在容许时间内提供哈希原像或者在提供哈希原像之前取消交易, 则发送方锁定的资金将被退还.缺点是, 计算路径时要选择两条可行路径, 在一定程度上增加了计算复杂性, 同时也对应用场景有所限制.

(4) RobustPay+

RobustPay+[27]在RobustPay 的基础上进一步改进了HTLC 协议, 提高了HTLC 协议的安全性.为一场交易提供两条可行支付路径, 这两条路径不共享中间节点, 当一条路径中的某些节点被攻击或自身出现故障而导致支付路径失效时, 另一条路径也能完成交易, 提高了通道的鲁棒性.链下交易在这两条路径中同时执行, 如果一条路径首先完成交易, 则另一条路径上的交易无效.

RobustPay+通过改进HTLC 协议, 提高了链下通道的鲁棒性, 但由于需要为一个交易建立两条或更多通道, 导致其效率有所下降, 其次, 两条通道的并行执行, 占用了更多通信资源.同时, 完全保证两条通道没有共同的中间节点也是困难的.

2.2.3 虚拟通道

(1) 虚拟通道概述

虚拟通道是另一种实现没有直连通道的两个节点间交易的方式.虚拟通道的运行原理如图4 所示.如果A 与C 已经建立了一条支付通道(记为c1), B 与C 之间也建立了一条支付通道(记为c2), 那么当A和B 想要执行交易时, 就无需直接建立一条支付通道, 而是使用C 作为中间节点来路由其交易资金.具体运行过程是:

图4 虚拟通道Figure 4 Virtual channel

• 虚拟通道建立.基于c1和c2建立一条A 和B 之间的虚拟通道(记为VC, 假设初始的资金分配状态为[A →XA| B →XB]), 此时, A 和B 便可以通过此虚拟通道执行交易.值得注意的是, 在以上通道中, 称A-C-B 为一条支付路径, 路径长度为实际支付通道的数量, 即为2, 支付路径两端的节点A 和B 称为交易节点, 交易节点之间的节点C 称为中间节点.

• 资金锁定.对于一条支付路径的每一条实际支付通道两端的节点, 他们会分别锁定与交易节点相同的资金, 以保证虚拟通道的正确运行.在A-C-B 这条支付路径中, A 和C 会分别从其在C1通道上部署的资产中锁定XA和XB的份额, C 和B 会分别从其在C2通道部署的资产中锁定XA和XB的份额, 这些实际支付通道中锁定的XA和XB的资产用来供虚拟通道使用.

• 通道更新.A 和B 互相签名并发送更新虚拟通道中资金分配的消息.

• 通道关闭.当虚拟通道的有效期到期后, 会执行虚拟通道关闭程序, 虚拟通道的关闭是通过在底层的支付通道中进行结算来完成的, 例如如果虚拟通道关闭时最终的资金分配状态为A 向B 支付q(q

进一步, 基于递归的方式, 可以将VC 当作底层通道, 构造更高级别的虚拟通道, 实现跨越更多个中间节点的链下支付.与哈希时间锁合约方案相比, 虚拟通道方案的中间节点无需牵涉到每笔交易中来, 只需通过智能合约自动执行, 因此更具隐私性和低延迟性, 但是这样的缺点也很明显, 即需要中间节点锁定足够数量的资金, 同时协议复杂, 底层智能合约实例计算存储性能负载大.

(2) Perun

Perun[28]是一种典型的虚拟通道方案, 是建立在以太坊上的虚拟通道, 参与者可以在不需要第三方同意的情况下立即打开和更新通道.一旦虚拟通道建立完成, 两方可以直接进行交易.

如图5 所示, Perun 的基本步骤如下:

图5 Perun 结构图Figure 5 Perun architecture

• 通道建立.参与方需要在区块链上创建一个智能合约, 该合约将用于存储通道的状态.在建立通道时, 参与方需要向合约中存入一定数量的加密货币作为保证金.这些加密货币将被锁定在合约中,直到通道被关闭.

• 状态交换.参与方可以在通道内进行多次交易, 而无需将每笔交易都记录在区块链上.在交换状态时, 参与方需要使用离线签名来验证交易的有效性.离线签名是一种签名方式, 它允许参与方在不将交易广播到区块链上的情况下进行交易.

• 通道关闭.参与方可以将通道的最终状态提交到区块链上, 以便最终结算.在关闭通道时, 参与方需要使用离线签名来验证通道的最终状态.一旦通道被关闭, 参与方可以从合约中取回他们的保证金和最终结算的资金.例如, 假设A 向B 转账X, 此时在A-C-B 这条支付路径上的每一条实际支付通道中, 将完成资金转结, 即A 向C 转账X, C 向B 转账X.

值得注意的是, 在Perun 中, 一旦A 和B 之间的虚拟通道成功建立, 两者便可进行多次交易, 同时,只要通道中的各方都是诚实的, A 和B 便只需要与C 执行两次通信, 分别是通道开启时的资金锁定和通道关闭时的资金转结, 而在通道更新过程中, A 和B 都无需与C 进行通信与交易.

Perun 也实现了虚拟通道开启和更新过程中的共识机制.对于支付路径A-C-B 而言, 在虚拟通道开启时, 三方参与者必须全部知情.一方面, 交易节点A 和B 必须对虚拟通道开启达成共识, 否则, 假如A认为通道已经开启而B 与之相反, 则两者之间无法完成交易; 另一方面, 中间节点C 也需要知悉虚拟通道的开启, 否则交易也无法正常执行.同时, 通道更新过程也需要共识机制, 对于实际通道或虚拟通道, A 和B 需要确认每次通道更新总是在恒定的时间内完成的.

虽然Perun 实现了没有直连通道的两个节点间的直接交易, 但要求中间节点参与通道开启和资金结算过程, 这导致的问题有: 1⃝系统可靠性降低, 因为中间节点可能被迫下线; 2⃝增加延迟, 因为通道开启和关闭都需要经过中间节点的共识; 3⃝增加交易成本, 因为中间节点需要收取手续费.

(3) BCVC

UTXO (unspent transaction output) 模型是一种用于跟踪和管理区块链上交易输出的模型.在UTXO 模型中, 每个交易输出都被视为一个未花费的输出, 即未被之后的交易使用.当一个交易被创建时, 它会消耗之前的未花费输出, 并创建新的未花费输出.这种模型的优势在于它能够提供更好的隐私保护和更高的并行性, 因为每个交易输出都是独立的, 并且可以并行地进行验证和处理.UTXO 模型被许多加密货币系统使用, 包括比特币和以太坊.

BCVC (Bitcoin-compatible virtual channels)[29]是一种基于UTXO 模型的适用于性能较弱的区块链平台的虚拟通道协议.

BCVC 解决的问题是, 虚拟通道只能运行在能够支持图灵完备的脚本语言的区块链平台, 使得虚拟通道能够更轻松地适用于更多平台, 这是因为, 执行BCVC 所需的脚本功能只有数字签名和时间锁功能.BCVC 支持将虚拟通道转换为实际支付通道, 即对于A-C-B 这条支付路径, 可以将A 与B 之间的虚拟通道转换为支付通道, 从而取消中间节点C 的参与, 减轻对中间节点的依赖.

为实现虚拟通道与支付通道的转换, BCVC 提出了两个不同的方案, 分别被称为VC-V 和VC-NV.这两个方案的区别在于, VC-V 保证虚拟通道中的交易节点A 或B 能够在有效期内完成通道的转换; 而VC-NV 不定义有效期, 同时通道转换的任务由中间节点C 完成.

BCVC 扩展了虚拟通道的适用范围, 使其能够适用于更广泛的区块链平台, 但是, 由于其轻量化的智能合约设计, 可能导致功能的不完善以及安全性的降低.

(4) Elmo

Elmo 由Kiayias 和Litos[30]提出, 是一种递归的虚拟通道构建方法, 能够应用于已存在的虚拟通道,从而创建更多的通道.这种递归构造方法使得Elmo 可以构建无限寿命(unlimited lifetime) 的通道, 并且可以在任意数量的通道上应用.通过利用递归构造方法, Elmo 能够实现对称性, 从而提高通道的效率和安全性.由于Elmo 不需要智能合约支持, 所以可以应用于比特币平台.实验证明, Elmo 构造方法的乐观和悲观执行路径在轮复杂度方面都是最优的, 因为在两个端点之间发出支付只需要三个消息, 其大小与通道的长度无关, 而关闭通道则需要任何参与方(端点或中间节点) 的两个链上交易, 也与通道的长度无关.本方案通过利用复杂的虚拟通道设置协议来实现上述目标, 该协议一方面使端点能够使用在基础通道和虚拟通道之间不变的接口, 而另一方面, 中间节点可以在通道关闭时遵循任何任意激活序列.在此构造方法中,每次特定通道C充当新虚拟通道的基础通道时, 都会添加一个“虚拟化层”.当它的一个所有者想要关闭C时, 它必须在链上同步与虚拟化层一样多的交易.此外, 与关闭虚拟通道相关联的时间锁随着其基本通道的虚拟化层的数量而增加.因此, 本方案的复杂性和成本将随着虚拟化层数的增加而增加.

(5) CCVPC

区块链系统的异构性使得跨链数据流和价值转移极具挑战性, 为解决此问题, Jia 等人[31]提出了跨链虚拟支付通道(cross-chain virtual payment channels, CCVPC).现有跨链交易方案大都利用可信第三方(trusted third party, TTP) 或哈希锁和时间锁, 因此带来中心化问题或可扩展性问题.而跨链虚拟支付通道方案在虚拟通道概念的基础上深入挖掘, 实现不同区块链系统中的两个用户在中间节点的帮助下进行无限的链下交易, 从而解决了中心化和可扩展性问题.此外, 由于中间节点只参与通道的开闭操作, 进一步提高了跨链交易的效率, 在一定程度上甚至增强了跨链交易的私密性.此外, 该方案只需要一个支持图灵完备脚本语言的区块链系统.同时, 本方案的安全性在UC 框架下的正式证明中得以验证.本方案的改进之处在于, 若能在不影响安全性的前提下删除方案中的oracle 系统, 则能大大提高效率; 同时, 保证通道内交易信息的隐私性对于方案的进一步发展也具有重要意义.

2.2.4 支付通道再平衡

支付通道中, 可能存在其中一方向另一方单向多次转账而导致通道内该方资金枯竭的问题.例如, 通道内一方是顾客, 一方是商家, 一段时间的单向支付后必然面临顾客在通道内余额不足的情况.此时, 若想继续进行后续支付行为, 就必须增加通道内该方的余额.一般情况下, 通道参与方可以关闭当前通道, 然后重新开启新的通道并在通道中存入足够的资金以完成后续交易.当小额交易较为频繁时, 通过这种方式解决通道资金枯竭的问题则会失去链下支付通道本身减少链上交易、增强区块链可扩展性的意义.此时, 若通道参与方同时存在两个通道中, 其中一个通道的资金枯竭, 而另一通道内余额充足, 那么能否将其在另一通道内余额转入资金枯竭的通道内以支持该通道内的后续交易呢? 链下通道的再平衡(rebalancing) 正是解决这样一类问题的方法, 使得通道参与方的余额在其所在的多个通道内相互转移, 以保障其链下交易的持续.如图6 所示, 参与方A、B、C 两两之间存在支付通道α、β、γ, 通道上的数字代表参与方在该通道的余额, 即参与方A 在通道α的余额为200, 在通道γ的余额为2.若此时参与方B 想通过通道α向参与方A 转账, 则无法实现, 参与方B 在通道α中的资金已然枯竭.若按照图示的方向进行再平衡, 对各个通道内的参与方余额进行重新分配, 则面临上述问题的各参与方可继续完成后续链下交易.

图6 支付通道再平衡Figure 6 Payment channel rebalancing

(1) Revive

Revive 由Khalil 和Gervais[32]提出, 旨在解决链下通道的再平衡问题.链下通道通常依赖于资金的锁定和释放, 因此当通道的资金分布不均匀或需要调整时, 就需要进行资金再平衡.其产生原因主要包括:1⃝交易不均衡.如果在通道中的一方频繁进行支付, 而另一方很少支付, 通道的资金可能会倾向于一方,需要重新分配资金以保持平衡.2⃝通道资金耗尽: 如果一个通道的资金用尽, 需要关闭通道并重新分配资金, 以便继续使用该通道.3⃝费用优化.有时候, 通道中的一方可能希望调整资金以优化交易费用.这可能涉及到将资金从一个通道移动到另一个通道, 以便更有效地进行支付.

Revive 作用于环形支付通道网络, 由一个诚实的领导者(leader) 收集用户的再平衡需求, 检查哪些再平衡需求可以在保证用户不丢失资金的情况下实现, 然后实现用户们的再平衡需求.Revive 没有链上消耗, 再平衡过程在链下完成.缺点是, 执行条件苛刻, 只能针对环形有向支付通道网络; 其次需要一个诚实的领导者和每个用户的配合.

(2) Cycle

Cycle 由Hong 等人[33]提出, 其中通道参与者可以异步地对通道余额进行再平衡, 协议中通过设定并广播资金的偏移量来实施对通道余额的再平衡.协议不仅支持两个相邻通道之间的再平衡, 还支持没有直接通道相连的虚拟通道之间的再平衡.协议通过部署仲裁智能合约来解决因网络延迟或恶意参与者引起的争议.此外, 协议中考虑到预期偏移量的传播可能会泄漏通道参与方的资金隐私, 结合本地化差分隐私(local differential privacy) 技术隐藏通道参与方的输入, 保障参与方的资金隐私安全.

Cycle 协议执行也需要通过环形支付通道网络, 并且再平衡所依赖的环形通道参与方是静态设定的,通道参与方需要通过注册合约加入协议, 即协议初始阶段就已设定好能够进行再平衡的通道参与方以及环形通道网络的规模.此外, 再平衡的所有步骤都使用了智能合约, 无法适配于比特币.

(3) Hide & Seek

Hide & Seek 由Avarikioti 等人[34]提出, 是一种可选择的再平衡协议, 将再平衡问题简化为最小成本流问题, 选定一系列代表来执行线性规划实现通道间的再平衡, 参与方通过秘密共享向指定的代表提交他们的再平衡请求, 即希望再平衡多少金额, 并设定目标函数使得通道内再平衡的资金总量最大化.协议结合安全多方计算的思想, 使得再平衡的过程是完全私有化的, 从而保障各通道参与方的隐私.Hide &Seek 协议也需要借助环形支付通道来完成再平衡, 并且协议使用了智能合约来实现环形事务的自动执行,不适配于比特币.但Hide & Seek 协议将再平衡的周期进行分解, 将一周期分为探索阶段和执行阶段.在探索阶段, 将再平衡问题转化为线性规划, 并通过多方计算协议来解决线性规划问题, 以保证隐私和效率.在执行阶段, 将探索阶段的输出分解为一组循环流动, 并通过创建HTLC 来确保循环中的交易具有原子性.此方案的问题在于, 一方面对于敌手攻击能力的假设比较保守, 在应用层面有一定局限性; 另一方面没有考虑网络拓扑的动态变化, 对于网络结构的变化可能需要重新执行协议, 同时, 协议的设计没有考虑交易费用的问题, 由此可能损害参与者的利益.

(4) Shaduf

Shaduf 由Ge 等人[35]提出, 协议摆脱了Revive 等方案对于环形有向支付通道网络的依赖, 能够在相邻的两通道内进行再平衡.Ge 等人考虑到再平衡过程中的双重转移攻击(double-shifting attack), 即两通道的中间人与其中一个通道参与方合谋, 将通道内的有限资金转移到多个通道, 其中转移走的总金额大于通道容量, 导致争议索赔阶段参与的其他通道面临资金损失.为抵抗此类攻击, Shaduf 提出了绑定(bind) 的方法, 将两相邻通道进行绑定.一次链上绑定后, 用户可在两通道间双向无限次转移资金.同时,为了提高再平衡的效率, 一个通道内的资金可以以配额的方式与多个通道进行绑定.

Shaduf 可以抵抗不合作的参与者, 不受他人需求的限制.使用通用可组合(universal composable,UC) 框架中的理想/现实世界范式形式化了Shaduf 的安全属性, 并根据定义提供了形式化的安全性证明.但由于其复杂性, 需要支持智能合约, 即比特币不适配.

(5) Musketeer

Musketeer 由Avarikioti 等人[36]提出, Avarikioti 等人认为Revive 和Hide&Seek 协议中的再平衡子图只包括了希望进行再平衡的各参与方, 而支付通道网络中绝大多数可能以低费用或免费方式来传递交易的通道被忽略了.因此, 即使使用全局协调的再平衡, 有限的再平衡子图仍然会影响整体方案的最优性.协议涉及到支付通道网络中的所有参与方, 最大限度地提高流动性利用率及交易吞吐量.协议将再平衡问题转化为双重拍卖再平衡问题, 参与方可以作为买家或者卖家参与协议, 其中买家可以支付一定的费用用于再平衡, 卖家可以收取费用以提供交易的路由服务.虽然有的通道参与方与其他用户的再平衡问题无关,但他们可以提供有偿的路由服务, 提高整个支付通道网络的资金流动性和吞吐量.双重拍卖的不可能性结果证明Musketeer 方法不能同时满足期望的属性, 包括经济效率、个体合理性(individual rationality)、真实性和循环预算平衡等, 这意味着无法设计一种机制, 使得所有参与者都能够获得最大的利益, 同时保持真实性和循环预算平衡.文中提出拍卖再平衡机制中, 买家支付的价格取决于支付通道网络的底层图结构.由于这种依赖关系, 卖家的收益将取决于图中可行的再平衡循环的数量.因此, 卖家无法控制买家支付的价格, 而是受到PCN 结构的影响.这可能会导致卖家的收益受到图中可行再平衡循环数量的限制, 从而影响了卖家的利润.

3 多方支付通道

3.1 概念

多方支付通道(multi-party payment channel)[52]是在双方支付通道的基础上设计的, 如图7 所示,多方支付通道可以看成是由多个双方支付通道构成的.

图7 多方支付通道示例Figure 7 Multi-party payment channel example

与双方支付通道类似, 多方支付通道的运行周期也主要包括三个阶段: 创建、更新和关闭[53].

• 通道创建.在通道创建阶段, 智能合约收集加入到多方支付通道的所有区块链用户的地址和所有双方支付通道, 并验证所有用户的签名, 验证成功后, 完成通道创建, 此时, 各双方支付通道不能独立于多方支付通道使用.

• 更新.在更新阶段, 智能合约更新多方支付通道的新状态, 包括各双方支付通道最新余额分配情况和版本号.

• 通道关闭.在关闭阶段, 当通道内的交易全部完成后, 用户能够向智能合约请求通道关闭, 智能合约验证用户们的签名, 完成验证后, 关闭通道, 双方支付通道被设置为空闲状态, 可以独立使用.

图7 是一个多方支付通道的例子.图7(a)是通道的初始状态, 其中有五个用户和四个双方支付通道,并假设每个用户在其所在通道锁定的资金都是5 个代币, 假设在一轮交易中所有人都需要向D 转账1 个代币, 可记为{(A, D, 1), (B, D, 1), (C, D, 1), (E, D, 1)}.但是, 并不是任意两个节点间都有直连通道来执行交易, 需要借助一些节点作为中间节点进行交易, 此时, 一些通道可能被多次使用.为了减少交易的总次数, 可以把通道内的多次交易合并为一次交易, 即{(A, B, 1), (B, D, 4), (C, B, 2), (E, C, 1)}, 交易结果如7(b)所示.下一轮所有节点都需要给C 转账1 个代币, 则最终交易结果如7(c)所示.

3.2 典型方案分析

(1) Sprites

Sprites[37]的路由方案也是采用HTLC 实现的, 它引入了一个简单的智能合约, 称为原像管理器(preimage manager, PM), 用以记录HTLC 中发布过的原像.PM 负责统一管理所有通道内的原像是否按时发布, 这能保证在争议处理过程中, 所有通道都以一致的方案解决争议(要么交易全部完成, 要么全部取消).由于对全局智能合约的依赖, 导致Sprites 对区块链平台的脚本能力有较强要求, 适用范围有限.

Sprites 支持部分取款和存款, 即向通道内增加或减少锁定资金的数额, 在此期间, 通道可以继续运行而不会中断.它不支持用户的即时退出和进入, 因此不能完全保证通道的灵活性.

(2) Garou

Garou 由Ye 等人[38]提出.如图8 所示, Garou 有两个组成部分: 链上智能合约和链下交易协议.

图8 Garou 结构图Figure 8 Garou architecture

链上智能合约管理着所有参与者的存款, 并充当争议解决者.在链上智能合约的支持下, 即使支付中心的所有其他参与者都是恶意的, 诚实的一方也不会承担任何财务损失.

链下交易分为三个阶段: 领导者选举、交易和共识.

• 领导者选举.采用一个自动的领导者选举机制, 以消除额外的通信开销, 同时避免了由一个固定的领导人造成的单点故障.

• 交易.在交易阶段, 通道中的参与者可以自由地相互进行转账, 但是, 参与者花费的数额不能超过他们当前余额.

• 共识.在共识阶段, 所有参与者就当前阶段的最终状态达成共识, 该状态充当Garou 的链下执行的检查点.在发生争议的情况下, 诚实的参与者可以将最新的状态提交给链上智能合约, 以加强其资产安全性.

对于用户的加入和退出, 由领导者处理, 领导者在通道的状态信息中添加加入或退出信息, 等待用户对信息达成共识并执行相应操作.因此, 只有当通道正常工作时, 这个过程才能成功完成.

(3) Magma

Magma 由Ge 等人[39]提出.如图9 所示, Magma 的一个周期分为五个阶段: 通道开启、用户加入、通道更新、用户退出、通道关闭.Magma 引入了一个不可信的操作员(operator) 来完成其他用户的状态更新、加入和退出.在开启、更新和关闭过程中, 更新是最重要和最关键的过程.它实现了通道的核心功能, 即: 使各方之间能够进行链下交易, 并且在通道的周期内尽可能正确运行.此外, 加入、退出和关闭过程依赖于更新过程.因为这三个过程都需要改变通道状态, 而所有的状态都是由更新过程产生的.

图9 Magma 结构图Figure 9 Magma architecture

在Magma 中, 用户可以即时加入或退出开放的多方支付通道, 而无需关闭或重新打开通道.在用户加入时, 首先用户向操作员发送加入请求, 请求需要包含用户的初始信息以及作恶补偿, 以防止恶意加入.接收到加入请求, 操作员检查其正确性, 如果正确, 则他回复加入确认信息, 该信息可以由加入方转发到链上智能合约以声明加入.在被智能合约通知加入完成之后, 操作员在下一次更新中将加入方的信息添加到信道更新状态中.当用户想要退出通道时, 他向智能合约提交申请, 合约根据最新状态退还退出方的余额.在退出之后, 通道继续工作, 并且最新状态可以被视为检查点.

Magma 增强了多方支付通道的灵活性, 允许用户动态加入或退出通道.但是, 在Magma 中, 通道的状态在通道内是公开的, 这意味着用户或操作员知道通道内的交易和金额, 从而导致隐私保护受到限制.

4 匿名支付通道

4.1 概念

匿名支付通道是一种允许参与者在不暴露其真实身份或具体交易信息的情况下进行支付和交易的链下通道, 旨在提高链下交易的隐私性和安全性.

4.2 典型方案分析

(1) Bolt

Bolt[40]为三种支付通道设计了三种匿名支付通道协议, 这三种通道分别是: 单向支付通道、双向支付通道、间接支付通道.

1⃝单向支付通道: 单向支付通道允许付款方A 持续向收款方B 发起多笔交易, 但此交易是单向的,即不支持B 向A 转账.

Bolt 针对e-cash[54]单向支付通道方案进行改进.在传统的e-cash 单向支付通道的关闭过程中, A需要向B 提供自己的资金信息, 以证明自己的资金余额, 以防止双花攻击, 这将破坏通道的匿名性.Bolt的改进措施是, 由B 存储必要的信息以对通道关闭的状态进行验证, 而A 不需向B 提供余额信息, 而是将所剩资金花费于自己的账户, 然后向链上提供相应的证据.当发生争议时, 由链上负责解决.

2⃝双向支付通道: 通道双方可以互相执行转账交易.

Bolt 将匿名的单向支付通道扩展到匿名的双向支付通道.其中, 用户需要使用零知识证明和盲签名来证明资金的正确性以及新余额与原始余额的差值是正确的.为了保证通道关闭时, 通道双方的余额更新为最新值, 用户需要发布一个最终通道余额的承诺以及一个零知识证明, 以证明他拥有通道余额的签名.

3⃝双向间接通道: 交易双方之间不存在直连通道, 但可以通过若干中间节点完成交易, 例如基于HTLC 路由技术的通道.

假设A-C-B 是一个双向间接通道, 其中A 与B 可以借助第三方C 进行双向交易.Bolt 的实现目标是, C 无法知道交易双方的身份, 也不能知道交易的金额.由于第三方C 只是被动地参与到了交易中, 因此他并不需要了解通道的支付状态, 只需要交易双方A 和B 对交易达成一致即可.

Bolt 实现了一种去中心化的匿名支付通道, 保证用户的交易信息不被泄露, 但需要在每个节点运行额外大约5 MB 的通信开销, 对节点的存储能力和通信能力有较高要求, 这阻碍了其广泛的部署.

(2) MAPPCN

MAPPCN[41]利用椭圆曲线保证支付通道的匿名性, 其安全性依赖于椭圆曲线上的离散对数问题.MAPPCN 对时间锁机制进行改进, 利用椭圆曲线完成时间锁的验证以及保证资金的解锁, 使资金能够安全且隐私地在通道内流转.

在MAPPCN 中, 中间节点在每轮通信中, 只向其直连节点发送消息, 这提高了通信的效率.此外, 为了保证转账方和接收方的匿名性, MAPPCN 的改进是, 在利用时间锁机制执行资金流转过程中, 转账方和接收方不向除其直接邻居节点之外的任何节点发送任何消息, 以防止每个中间节点都知道消息发送方的身份, 保证了通道内交易双方的匿名性.

椭圆曲线上的离散对数问题的困难性保证了MAPPCN 的安全性, 但是由于椭圆曲线密码体制的复杂性以及计算速率的限制, 导致MAPPCN 的效率较低, 实施难度较大.

(3) A2L

Tairi 等人[42]提出了A2L 协议, 实现了一种基于有条件三方交易的支付通道集线器(payment channel hubs, PCH)构造, 只有当接收方在发送方的帮助下解决了密码谜题时, 中间方才会向接收者支付费用,而发送方协助接收方解决谜题意味着发送方已经向中间方支付了费用, 由此构成一个三方的原子锁.文中首次证明了在只需要底层脚本语言的数字签名和时间锁功能的情况下, 就可以设计一个安全且保护隐私的PCH, A2L 对比特币兼容.A2L 支持原子性、不可链接性、互操作性和可扩展性.Tairi 等人在UC 框架中证明了A2L 协议的安全性和隐私性, 并提出了一个基于适配器签名和随机化谜题的实例化方案.交易关系的匿名性和交易金额的隐私性是PCH 的理想隐私保护特性, 它可以防止攻击者识别发送方和接收方的身份以及支付金额, 但协议所涉及的交易量是固定的, 无法实现不同金额的支付.

(4) BlindHub

Qin 等人[43]提出了BlindHub 协议, 考虑到现有的能够兼容比特币并提供交易关系匿名的PCH 结构只支持预定义的固定支付金额, 为了实现不同金额的支付, 要么需要多个PCH 系统, 要么需要多次运行一个PCH 系统.BlindHub 协议在实现交易关系匿名PCH 的基础上, 还支持可变支付金额.Qin 等人提出了盲适配器签名(blind adaptor signature, BAS) 和灵活盲条件签名(flexible blind conditional signature, FBCS) 两个新型密码学原语, 分别用于实现基于盲签名的适配器签名协议和提供原子性与隐私保护的PCH.协议首先通过设计BlindChannel 来实现双向支付通道内的隐私保护, 并在UC 框架下证明了其安全性.在此基础上进一步提出了BlindHub 协议, 用于有条件支付的私有化三方协议, 且交易的中间方无法对发送方和接收方进行链接, 保障交易方的隐私性.BlindHub 协议仅需要用到数字签名和底层区块链的时间锁功能.结合BlindHub 和BlindChannel, 给出了一个比特币兼容的PCH 结构, 实现价值隐私保护、原子性、关系匿名性、抵抗恶意破坏, 同时支持可变支付金额.然而, 为了实现相应的安全目标, BlindHub 方案的协议设计复杂, 难以实现; 同时, 仿真实验表明, 利用本方案完成一次交易需要大约17 秒时间, 这有悖于链下通道高性能、高效率的特性.