一种可监管的区块链支付通道网络及监管方法

1.本发明涉及信息安全技术领域，尤其涉及一种可监管的区块链支付通道网络及监管方法。


背景技术：

2.区块链技术是一种分布式账本技术，具有去中心化、匿名化、交易公开透明、不可篡改、 交易可追溯这五大特点。但由于区块链底层的共识机制和交易验证机制导致加密数字货币的 吞吐量低，而支付通道技术是有前途的解决区块链可扩展性的技术。
3.支付通道技术是链上锁定资金，链下资金状态再分配，区块链只作为最终的仲裁者，通 过这种方式实现将大量区块链交易转移至链下，从而提高区块链的吞吐量。用户只有在必要 时才会将最新交易状态提交至区块链智能合约以关闭通道取回锁定资金，否则只会由用户保 存在链下。为防止恶意用户提交旧状态交易以窃取资金，智能合约往往会预留一段争议期等 待正常用户提交交易，通过对两个交易状态新旧的断言来阻止恶意行为。随着支付通道的增 多，支付通道之间的互连逐渐形成了支付通道网络。
4.支付通道网络技术是实现没有直接相连通道的用户之间的交易。发送者首先在支付通道 网络中寻找一条资金充足且中间用户愿意协助的可到达接受者的由支付通道构成的路径。然 后，该路径中的所有支付通道用户都沿着发送者到接收者的方向执行交易，即发送者支付给 中间用户，中间用户支付给接收者。为激励中间用户协助执行交易，他们可以收取一定的交 易费。同时，为了防止中间用户接受资金而不转给接收者，基于密码学哈希算法的时间锁定 合约确保所有交易的原子性，即要么同时成功，要么同时失败。接收者生成哈希值发送给发 送者以逐步构建多跳交易。当接收者收到基于哈希时间锁合约的交易时，将会向上一跳发送 哈希原像并逐跳发送至发送者处以完成多跳交易。
5.在区块链加密货币交易中，由于区块链的匿名性，利用区块链加密货币进行非法行为层 出不穷。但区块链交易公开透明和可追溯的特性，使得对非法交易溯源、识别、检测以及跟 踪成为可能。
6.支付通道网络技术作为解决区块链可扩展性的技术之一，已经成为区块链数字加密货币 的衍生交易场景。区块链用户可创建支付通道实现链下交易，只将最终的交易结果上链。通 道内的交易数据只有通道双方知晓，不具备交易公开透明的特性。并且，支付通道网络中的 交易可以被分割成多个片段，在不同的通道用户之间传播，因此很难将发送者/接收者与正在 转账的货币联系起来，不具备交易可追溯性的特性。因此，这使得在支付通道网络中识别非 法交易变得困难，无法实现有效监管。


技术实现要素：

7.本发明要解决的技术问题是针对上述现有技术的不足，提供一种可监管的区块链支付通 道网络及监管方法，实现对区块链用户使用支付通道网络进行加密货币交易时的监管。
8.为解决上述技术问题，本发明所采取的技术方案是：
9.一方面，本发明提供一种可监管的区块链支付通道网络，包括若干个瞭望塔，并根据传 统区块链支付通道网络拓扑结构，将整个支付通道网络分为若干个局域支付通道网络，各个 局域支付通道网络之间互连；所述局域支付通道网络包括若干个通道用户和一个路由计算终 端，由路由计算终端替局域支付通道网络中所有通道用户进行路由计算，且各局域支付通道 网络中的路由计算终端互连；所述通道用户作为交易的发起者、交易接收者以及中间节点， 负责发起交易以及路由交易；所述瞭望塔为通道用户提供存储服务和争议服务；所述路由计 算终端为通道用户进行路由路径计算。
10.另一方面，本发明提供一种可监管的区块链支付通道网络的监管方法，包括网络初始化 阶段、交易阶段、关闭阶段和监管阶段；
11.所述网络初始化阶段包括瞭望塔监管注册、用户监管注册、瞭望塔推荐和支付通道创建 四部分；所述瞭望塔监管注册和用户监管注册是指瞭望塔和用户在加入支付通道网络之前， 都需要在监管部门进行注册；所述瞭望塔推荐是指注册过的瞭望塔能够根据用户的偏好被监 管部门推荐给用户，向用户提供存储服务和争议服务，并收取一定的费用；所述支付通道创 建是指用户向区块链发布支付通道合约来创建支付通道，并在该支付通道合约中初始化通道 信息；
12.所述交易阶段分为通道内交易和跨通道交易；通道内交易指两个有直接相连通道的用户 进行交易，通道用户需要在交易过程中将通道状态与瞭望塔进行存储备份；跨通道交易指两 个无直接相连通道的用户借助中间通道用户进行交易；中间通道用户需要收取路由费用；
13.所述关闭阶段是指通道用户关闭支付通道的过程；该过程分为两类，第一类是通道用户 合作关闭通道，第二类是通道用户不合作关闭通道；当通道用户不在线时，由签订的瞭望塔 替代通道用户进行权益争议；
14.所述监管阶段是指监管部门对区块链支付通道网络进行监管；监管部门从瞭望塔处获取 通道内交易数据从而实现通道内监管；监管部门从路由计算终端处获取跨通道交易数据，并 根据跨通道交易序列seq以及路由路径信息来追踪跨通道交易从而实现跨通道监管。
15.所述瞭望塔监管注册的具体方法为：
16.步骤11：监管部门向区块链发布瞭望塔管理合约；所述瞭望塔管理合约的功能包括瞭望 塔注册、瞭望塔服务合约绑定、惩罚瞭望塔和增加瞭望塔罚金；
17.步骤12：瞭望塔向监管部门发送监管注册请求；所述监管注册请求中包含瞭望塔区块链 地址、瞭望塔存储费用、瞭望塔争议费用、瞭望塔罚金和瞭望塔公钥；
18.步骤13：监管部门收到瞭望塔的注册请求后，向瞭望塔管理合约发起交易，交易中包括 瞭望塔区块链地址、瞭望塔存储费用、瞭望塔争议费用和瞭望塔公钥，交易完成则瞭望塔注 册成功；
19.步骤14：瞭望塔注册成功后，向区块链发布瞭望塔服务合约；所述瞭望塔服务合约的功 能包括签订用户、增加通道和删除通道。
20.所述用户监管注册的具体方法为：
21.监管部门发送自己的公钥给用户；用户生成对称密钥，并用监管部门的公钥对该
对称密 钥加密，然后将加密后的对称密钥以及自己的公钥发送给监管部门，完成用户监管注册。
22.所述瞭望塔推荐的具体方法为：
23.步骤21：用户向监管部门发送瞭望塔推荐请求，瞭望塔推荐请求包括用户区块链地址和 瞭望塔属性偏好信息；用户将瞭望塔推荐请求和签名发送给监管部门；
24.步骤22：监管部门验证瞭望塔推荐请求的签名后，将瞭望塔推荐结果和签名发送给用户， 推荐结果中包括用户区块链地址、瞭望塔区块链地址、瞭望塔存储费用、瞭望塔争议费用、 瞭望塔公钥和瞭望塔服务合约地址；
25.步骤23：用户收到瞭望塔推荐结果后，验证瞭望塔推荐结果的签名，向瞭望塔服务合约 发送交易，交易中包括用户公钥。
26.所述支付通道创建的具体方法为：
27.步骤31：用户a与用户b在区块链下发送彼此的区块链地址、公钥、彼此签订的瞭望塔 区块链地址、瞭望塔服务合约地址、瞭望塔公钥和瞭望塔争议费用，商议通道初始资金分配 方案和通道初始状态版本号；
28.步骤32：用户a生成通道初始状态和签名发送给用户b，该通道初始状态包括通道初始 状态版本号、用户a的区块链地址、用户b的区块链地址、用户a的通道初始资金和用户b 的通道初始资金；
29.步骤33：用户b验证用户a生成的通道初始状态签名后，生成通道初始状态的签名并发 送给用户a；
30.步骤34：用户a验证用户b生成的通道初始状态签名后，则向区块链发布支付通道合约； 所述支付通道合约的功能包括用户关闭通道、瞭望塔关闭通道、正常关闭和争议关闭。
31.所述通道内交易的具体方法为：
32.步骤41：通道用户a向直接相连的通道用户b发起第i次交易，通道用户a生成新的通 道状态；新的通道状态包括支付通道合约地址、通道第i次交易的版本号、通道用户a的区 块链地址、通道用户b的区块链地址、通道用户a在第i次交易后通道内未被锁定的资金以 及通道用户b在第i次交易后通道内未被锁定的资金；通道用户a对新的通道状态和通道第 i次交易的版本号分别生成签名，并将新的通道状态和签名以及通道第i次交易的版本号的签 名发送给通道用户b；
33.步骤42：通道用户b验证用户a发送的签名后，对新的通道状态和通道第i次交易的版 本号生成签名，并将签名发送给通道用户a；
34.步骤43：通道用户a验证用户b发送的签名后，对新的通道状态进行对称加密，对加密 后的新通道状态生成签名，并将通道内交易数据发送给通道用户a签订的瞭望塔；该通道内 交易数据包括支付通道合约地址、通道第i次交易的版本号、通道用户a对支付通道合约地 址和通道第i次交易的版本号的签名、通道用户b对支付通道合约底子和通道第i次交易的 版本号的签名、加密后的新通道状态以及通道用户a对加密后的新通道状态的签名；
35.步骤44：通道用户a签订的瞭望塔验证用户a发送的签名后，替通道用户a存储备份 通道内交易数据，对通道用户a的通道内交易数据生成签名，并将存储凭证发送给通道用户 a，该存储凭证包含通道内交易数据的哈希值和瞭望塔对通道内交易数据的签名；
36.步骤45：通道用户a验证瞭望塔对通道内交易数据的签名后，向瞭望塔支付存储费用；
37.步骤46：通道用户b同样对新的通道状态加密，用户b签订的瞭望塔执行与用户a的 瞭望塔相同的存储备份操作。
38.所述跨通道交易的具体方法为：
39.步骤51：跨通道交易发送方向未有直接通道相连的跨通道交易接收方进行交易；
40.步骤52：跨通道交易接收方生成一个随机值，并生成该随机值的哈希值及其签名，再将 哈希值及其签名发送给跨通道交易发送方；
41.步骤53：跨通道交易发送方收到哈希值并验证其签名后，向路由计算终端发送路由计算 请求，该路由计算请求包括跨通道交易信息及签名；跨通道交易信息包括跨通道交易发送方、 跨通道交易接收方和交易金额；
42.步骤54：路由计算终端收到跨通道交易发送方发送的路由计算请求并验证跨通道交易签 名后，根据最短路径路由算法进行路由路径的计算，得到一条路由路径，并生成路径包；所 述路径包被层层加密，每一层路径包只能由路径当前通道用户的私钥解密；路径包包含下一 跳的通道用户、向下一跳通道用户支付的金额以及发送给下一跳的路径包；路由计算终端发 送路由请求结果给跨通道交易发送方，该路由请求结果包含哈希时间锁的序列号seq和路径 包；
43.步骤55：跨通道交易发送方用自己的私钥解密路径包，得到下一跳的通道用户、支付金 额以及发送给下一跳通道用户的路径包；跨通道交易发送方生成新通道状态，新的通道状态 包括支付通道合约地址、通道交易版本号、当前通道用户的区块链地址、通道下一跳用户的 区块链地址、当前通道用户在通道内未被锁定的资金、通道下一跳用户在通道内未被锁定的 资金以及序列号为seq的哈希时间锁；序列号为seq的哈希时间锁包括哈希时间锁序列号、 哈希时间锁发送方的区块链地址、哈希时间锁接收方的区块链地址、通道在序列号为seq的 哈希时间锁中被锁定的资金、哈希锁、时间锁和哈希时间锁被锁定的时间；跨通道交易发送 方生成新通道状态的签名，并将新通道状态及其签名、支付通道合约地址和通道交易版本号 的签名、路径包及其签名发送给下一跳通道用户；路径中的中间通道用户依次向后生成新的 通道状态，通道状态中包括序列号为seq的哈希时间锁，其中的时间锁依次递减；
44.步骤56：跨通道交易接收方收到路径上一跳通道用户发送的通道状态，验证通道状态签 名后，将该通道状态的签名以及支付通道合约和交易版本号的签名发送给上一跳通道用户； 跨通道交易接收方生成新通道状态，该通道状态包括序列号为seq的哈希时间锁；序列号为 seq的哈希时间锁中添加哈希密钥和哈希时间锁被解锁的时间；跨通道交易接收方对新通道状 态生成签名，并将新通道状态及其签名以及支付通道合约地址和交易版本号的签名发送给上 一跳通道用户；路径中的中间通道用户依次向前生成新的通道状态，新的通道状态中包括序 列号为seq的哈希时间锁，其中添加哈希密钥和哈希时间锁被解锁的时间；
45.步骤57：跨通道交易发送方收到下一跳通道用户发来的通道状态及其签名，该通道状态 中包含序列号为seq的哈希时间锁，该哈希时间锁中包含哈希密钥和哈希时间锁被解锁的时 间；跨通道交易发送方则验证下一跳通道用户发来的通道状态签名，验证哈希密
钥是否正确， 验证哈希时间锁被解锁的时间是否小于时间锁减去哈希时间锁被锁定的时间的差值；以上全 部验证通过后，生成该通道状态的签名及支付通道合约地址和交易版本号的签名，并发送给 下一跳通道用户；此时，跨通道交易的发送方与跨通道交易的接收方的跨通道交易完成；跨 通道交易的发送方向路由计算终端发送哈希时间锁序列号和跨通道交易完成的标识；
46.步骤58：路由计算终端收到跨通道交易完成的标识后，存储跨通道交易发送方的跨通道 交易数据，该交易数据包括跨通道交易发送方的区块链地址、跨通道交易接收方的区块链地 址、跨通道交易金额、跨通道交易的路由路径和哈希时间锁的序列号。
47.所述关闭阶段包括通道用户a和通道用户b合作关闭通道以及通道用户a和通道用户b 不合作关闭通道两种关闭方式，其中，
48.若通道用户a和通道用户b合作关闭通道，则通道用户a和b向支付通道合约发送交 易，该交易包括通道关闭时的最终通道状态、通道用户a对最终通道状态的签名、通道用户b对最终通道状态的签名；支付通道合约验证通道用户a用户b和对最终通道状态的签名， 若验证通过，等待争议时间过后，就关闭通道；最终通道状态中未被锁定的资金，分别转入 通道用户a和通道用户b的区块链地址；若最终通道状态中存在哈希时间锁且该跨通道交易 未完成，则将哈希时间锁中被锁定的资金转回哈希时间锁发送方；若最终通道状态中存在哈 希时间锁且该跨通道交易已完成，则将哈希时间锁中被锁定的资金转入哈希时间锁接收方；
49.若通道用户a和通道用户b不合作关闭通道，则通道用户a向支付通道合约发送交易， 该交易包括版本号为p的通道状态及通道双方的签名；当通道用户b在争议时间内查看到支 付通道合约发生改变，且通道内资金分配与通道用户b链下存储的最新通道状态内的资金分 配不符，存在争议；通道用户b则向支付通道合约发送交易，该交易包含版本号为q的通道 状态及通道双方的签名；若版本号q大于版本号p，则支付通道合约将通道内所有资金转入 通道用户b的区块链账户中；若通道用户b不在线，通道用户b签订的瞭望塔将代替通道用 户b进行争议；通道用户b签订的瞭望塔根据通道用户b备份的最新通道交易数据向支付通 道合约发送交易，该交易包含支付通道合约地址、交易版本号、通道双方和该瞭望塔对支付 通道合约地址和交易版本号的签名；此时，通道用户b签订的瞭望塔争议成功，支付通道合 约向该瞭望塔的瞭望塔服务合约支付争议费用，并向通道用户a退回其瞭望塔的争议费用。
50.所述监管阶段的具体方法为：
51.监管部门从瞭望塔处获取支付通道网络中通道用户的通道内交易数据，从路由计算终端 处获取通道用户的跨通道交易数据；监管部门用通道用户的对称密钥对加密的通道状态进行 解密，得到原始通道状态；监管部门从跨通道交易数据中获得通道用户跨通道交易的路由路 径、跨通道交易接收方、跨通道就交易金额，并根据哈希时间锁序列号seq在路径相关的通 道用户中查找到该跨通道交易的通道状态。
52.采用上述技术方案所产生的有益效果在于：本发明提供的一种可监管的区块链支付通道 网络及监管方法，(1)根据支付通道网络的拓扑以及交易特性，将支付通道网络分为多个局 域支付通道网络，从而提高路由计算的效率；(2)将路由计算功能从支付通道用户身上抽离 出来，通过专门的路由计算终端来进行路由计算，从而减少通道用户的计算开
销和存储开销； (3)将瞭望塔引入支付通道网络，让瞭望塔存储备份通道交易数据，以便监管部门获取通道 内交易数据，从而实现通道内监管；瞭望塔是由监管部门进行推荐，从而保证了瞭望塔的可 信度并提高通道更新的效率；(4)通过智能合约和监管注册实现了对支付通道网络中通道用 户和瞭望塔的公开监管；(5)将跨通道路由信息进行存储，并将支付通道网络中跨通道的交 易进行了联系，从而实现了跨通道交易的监管。
53.该可监管的区块链支付通道网络及监管方法通过通道交易数据存储和路由路径计算分 离，实现了交易对监管部门的公开透明和可追溯，实现对通道内交易以及跨通道交易的监管， 最终实现对整个区块链支付通道网络的监管。同时，监管方法还考虑到了轻量级通道用户计 算能力和存储能力有限，瞭望塔加入支付通道网络中所带来的的效率问题，以及真实支付通 道网络的路由计算问题，仅实现了支付通道网络的监管，还对支付通道网络的性能进行了优 化。
附图说明
54.图1为本发明实施例提供的一种可监管的区块链支付通道网络的架构图；
55.图2为本发明实施例提供的一种可监管的区块链支付通道网络的监管方法的流程图。
具体实施方式
56.下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于 说明本发明，但不用来限制本发明的范围。
57.本实施例中，一种可监管的区块链支付通道网络，如图1所示，包括若干个瞭望塔，并 根据传统区块链支付通道网络拓扑结构，将整个支付通道网络分为若干个局域支付通道网络， 各个局域支付通道网络之间互连；所述局域支付通道网络包括若干个通道用户和一个路由计 算终端，由路由计算终端替局域支付通道网络中所有通道用户进行路由计算，且各局域支付 通道网络中的路由计算终端互连；所述通道用户作为交易的发起者、交易接收者以及中间节 点，负责发起交易以及路由交易；所述瞭望塔为通道用户提供存储服务和争议服务；所述路 由计算终端为通道用户进行路由路径计算。
58.一种可监管的区块链支付通道网络的监管方法，如图2所示，包括网络初始化阶段、交 易阶段、关闭阶段和监管阶段；
59.所述网络初始化阶段包括瞭望塔监管注册、用户监管注册、瞭望塔推荐和支付通道创建 四部分；所述瞭望塔监管注册和用户监管注册是指瞭望塔和用户在加入支付通道网络之前， 都需要在监管部门进行注册；所述瞭望塔推荐是指注册过的瞭望塔能够根据用户的偏好被监 管部门推荐给用户，向用户提供存储服务和争议服务，并收取一定的费用；所述支付通道创 建是指用户向区块链发布支付通道合约来创建支付通道，并在该支付通道合约中初始化通道 信息；
60.所述交易阶段分为通道内交易和跨通道交易；通道内交易指两个有直接相连通道的用户 进行交易，通道用户u需要在交易过程中将通道状态与瞭望塔wu进行存储备份，wu表示通道 用户u签订的瞭望塔；跨通道交易指两个无直接相连通道的用户借助中间通道用户进行交易， 即通道用户uo通过通道用户ui(i＝1,
…
,n-1)向通道用户un发起一笔跨通道交
易tx＝{uo,un,a}，其中a表示交易金额。中间通道用户ui需要收取路由费用
61.所述关闭阶段是指通道用户关闭支付通道的过程；该过程分为两类，第一类是通道用户合作关闭通道，第二类是通道用户不合作关闭通道；当通道用户不在线时，由签订的瞭望塔替代通道用户进行权益争议；
62.所述监管阶段是指监管部门对区块链支付通道网络进行监管；监管部门从瞭望塔处获取通道内交易数据从而实现通道内监管，并根据跨通道交易序列seq以及路由路径信息来追踪跨通道交易从而实现跨通道监管。
63.本实施例中，瞭望塔监管注册的具体方法为：
64.步骤1：监管部门向区块链支付通道网络发布瞭望塔管理合约(watchtowermanagementcontract，简称wmc)；所述瞭望塔管理合约的功能包括瞭望塔注册register、瞭望塔服务合约绑定wsc、惩罚瞭望塔penalty和增加瞭望塔罚金addfine；
65.步骤2：瞭望塔向监管部门发送监管注册请求register＝{addrw,fees,feed,fine,pkw}；其中，addrw为瞭望塔区块链地址，fees为存储费用，feed为争议费用，fine为罚金，pkw为瞭望塔公钥；
66.步骤3：监管部门收到瞭望塔的注册请求后，向瞭望塔管理合约wmc发起交易tx
register
＝{addrw,fees,feed,pkw}，完成瞭望塔的注册；
67.步骤4：瞭望塔注册成功后，向区块链支付通道网络发布瞭望塔服务合约(watchtowerservicecontract，简称wsc)；所述瞭望塔服务合约的功能包括签订用户signuser、增加通道addchannel和删除通道deletechannel；
68.本实施例中，瞭望塔管理合约和瞭望塔服务合约如表1、2所示：
69.表1瞭望塔管理合约
70.[0071][0072]
表2瞭望塔服务合约
[0073]
[0074]
本实施例中，用户监管注册的具体方法为：
[0075]
监管部门发送自己的公钥pkg给用户u；用户u生成对称密钥其中，为对称加密密钥生成函数，t代表当前时间，并用监管部门的公钥对该对称密钥加密esk
enc
＝en(esk,pkg)，其中，en为对称加密函数，然后将加密后的对称密钥esk
enc
以及自己的公钥pku发送给监管部门，完成用户监管注册；
[0076]
本实施例中，瞭望塔推荐的具体方法为：
[0077]
步骤1：用户u向监管部门发送瞭望塔推荐请求request＝{addru,prefer}，其中，addru表示用户区块链地址，prefer表示瞭望塔属性偏好信息；用户u生成签名sigu(request)，并将{request,sigu(request)}发送给监管部门；
[0078]
步骤2：监管部门验证签名sigu(request)后，生成瞭望塔推荐结果result＝{addru,addrw,fees,feed,pkw,addr
wsc
}，其中，包括用户区块链地址addru、瞭望塔区块链地址addrw、瞭望塔存储费用fees、瞭望塔争议费用feed、瞭望塔公钥pkw、瞭望塔服务合约地址addr
wsc
；监管部门对瞭望塔推荐结果生成签名sigg(result)，并发送{result,sigg(result)}给用户u；
[0079]
步骤3：用户u收到瞭望塔推荐结果后，验证签名sigg(result)，向瞭望塔服务合约wsc发送交易tx
signuser
＝{pku}；
[0080]
本实施例中，支付通道创建的具体方法为：
[0081]
步骤1：用户a与用户b在区块链下发送彼此的区块链地址addra和addrb、公钥pka和pkb、瞭望塔区块链地址和瞭望塔的服务合约地址和瞭望塔的公钥和瞭望塔的争议费用和商议通道初始资金分配方案和通道初始状态版本号nonce，其中，表示用户a在通道内的初始资金，表示用户b在通道内的初始资金；
[0082]
步骤2：用户a生成通道初始状态生成签名并发送通道初始状态和签名给用户b；
[0083]
步骤3：用户b验证签名后，生成签名并发送给用户a；
[0084]
步骤4：用户a验证签名后，则向区块链发布支付通道合约(paymentchannelcontact，简称pcc)；所述支付通道合约的功能包括用户关闭通道userclosechannel、瞭望塔关闭通道wclosechannel、正常关闭normalclose和争议关闭disputeclose；
[0085]
本实施例中，支付通道合约如表3所示：
[0086]
表3支付通道合约
[0087]
[0088]
[0089][0090]
本实施例中，通道内交易的具体方法为：
[0091]
步骤1：通道用户ua向直接相连的通道用户ub发起交易，通道用户ua生成新的通道状态 其中，cid表示支付通道合约地址、nonce+i表示通道 第i次交易的版本号，nonce为通道初始交易版本号，ua、ub分别表示通道用户a和用户b 的区块链地址，分别表示通道用户a和用户b在通道内未被锁定的资金；通道用户ua对新的通道状态和通道交易的版本号生成签名和并将新的通 道状态和签名以及通道交易的版本号的签名发送给通 道用户ub；
[0092]
步骤2：通道用户ub验证签名和后，生成签名和 并将签名发送给通道用户ua；
[0093]
步骤3：通道用户ua验证签名和后，对新的通道状态进行对称加密生成签名并将通道交易数 据发送给用户 ua的瞭望塔
[0094]
步骤4：瞭望塔验证签名和后，替通道用户ua存储备 份通道交易数据data，生成签名sigw(data)，并将存储凭证proofs＝{h(data),sigw(data)}发 送给通道用户ua，其中，h(data)为通道交易数据data的哈希值，h()为哈希函数；
[0095]
步骤5：通道用户ua验证签名sigw(data)后，向瞭望塔支付存储费用fees；
[0096]
步骤6：通道用户ub同样对新的通道状态加密生成用户ub的瞭望塔执行与 用户ua的瞭望塔相同的存储备份操作；
[0097]
本实施例中，跨通道交易的具体方法为：
[0098]
步骤1：通道用户u0向未有直接通道相连的通道用户un进行交易；
[0099]
步骤2：通道用户un生成一个随机值key，并生成随机值的哈希值hash＝h(key)及其签 名再将哈希及其签名发送给通道用户u0；
[0100]
步骤3：通道用户u0收到随机值key的哈希值hash并验证签名后，向路由计 算终端发送路由计算请求其中，tx＝{uo,un,a}，u0为交易发送方，un为交易接收方，a交易金额，为用户u0针对tx生成的签名；
[0101]
步骤4：路由计算终端收到用户u0发送的路由计算请求routing并验证签名后， 根据最短路径路由算法进行路由路径的计算，得到一条路由路径 path＝u0→
u1→…
uj…→un-1
→
un，uj为第j个通道用户，0＜j＜n，生成路径包 发送路由请求结果 给通道用户u0，其中，seq表示此次哈希时间锁的序列号；
[0102]
步骤5：通道用户u0用自己的私钥解密路径包 得到下一跳的通道用 户u1、支付金额以及发送给通道用户u1的路径包通道用户u0生成新的通道状态其中，表 示哈希时间锁，seq为哈希时间锁的序列号，用户u0为哈希时间锁发送方的区块链地址、用 户u1为哈希时间锁接收方的区块链地址、表示被锁定的资金、hash表示哈希锁、 n
×
t表示时间锁、t
lock
表示被锁定的时间；用户u0生成新的通道状态的签名并将 通道状态及其签名以及路径包发送 给通道用户u1；
[0103]
步骤6：通道用户uj收到路径上一跳的通道用户u
j-1
发送的通道状态以及路径包其中 验证签名验证签名和后，生成签名并发送 给通道用户u
j-1
；通道用户uj根据路径包生成通道状 态其中， 生成签名并将 发送给路径下一跳的通道用户 u
j+1
；
[0104]
步骤7：通道用户un收到通道用户u
n-1
发送的通道状态并验证签名和 后，生成签名并发送给通 道用户u
n-1
；通道用户un生成通道状态其中 用户un生成签名并将 发送给通道用户u
n-1
；
[0105]
步骤8：通道用户uj收到路径下一跳的通道用户u
j+1
发送的通道状态其中 用户uj验证签名和验证哈希值hash＝h(key)，验证时间(t
unlock-t
lock
)＜(n-j)
×
t，全 部验证通过后，生成签名并将发送给通道用户 u
j+1
；通道用户uj生成通道状态其中 生成签名并 将发送给路径上一跳通道用户u
j-1
；
[0106]
步骤9：通道用户u0收到通道用户u1发送的通道状态其中 用户u0验证签名和 验证哈希hash＝h(key)，验证时间(t
unlock-t
lock
)＜n
×
t，全部验证通过 后，生成签名并将发送给通道用户u0；此时， 通道用户u0与通道用户un的跨通道交易完成；通道用户u0向路由计算终端发送哈希时间锁序 列号和跨通道交易完成的标识{seq,success}；
[0107]
步骤10：路由计算终端收到跨通道交易完成的标识success后，存储通道用户u0的跨通 道交易数据datarouting＝{routing,path,seq}。
[0108]
本实施例中，关闭阶段包括通道用户ua和通道用户ub合作关闭通道以及通道用户ua和通 道用户ub不合作关闭通道两种关闭方式，其中，
[0109]
若通道用户ua和通道用户ub合作关闭通道，则通道用户向支付通道合约pcc发送交易 其中
ꢀꢀ
表示通道cid关闭时的通道状态， nonce+last表示关闭通道时的版本号，分别表示通道关闭时用户ua和ub在通道内未 被锁定的资金；该通道不存在跨通道交易或者跨通道交易已完成，则不存在，
通道 关闭时用户ua和的最终资金若该通道存在未完成的跨通道交易， 则存在，且用户ua为哈希时间锁的发送者，若哈希原象key未知，则为哈希时间锁的发送者，若哈希原象key未知，则若哈希原象key已知，则支付通道合约pcc验证签名 和若验证通过，等待时间t
dispute
后，则向用户ua的区块链账户转入资 金向用户ub的区块链账户转入资金
[0110]
若通道用户ua和通道用户ub不合作关闭通道，则通道用户ua向支付通道合约pcc发送 交易其中当通道用户ub在t
dispute
时间内查看到支付通道合约pcc发生改变，则通道内资金分配与通道 用户ub链下存储的最新通道状态内的资金分配不符，存在争议；通道用户ub则向支付通道合 约pcc发送交易其中 若nonce+q＞nonce+p，则支付通道合约pcc将通道 内所有资金转入通道用户ub的区块链账户中；若通道用户ub不在线，通道用户ub签订的瞭 望塔将代替通道用户ub进行争议；瞭望塔根据通道用户ub备份的最新通道交易数据向支付通道 合约pcc发送交易 若 nonce+q＞nonce+p，则区块链将通道内所有资金转入通道用户ub的区块链账户中；此时， 瞭望塔争议成功，支付通道合约pcc向瞭望塔的瞭望塔服务合约wsc支付争议费用 feed，并向用户ua退回瞭望塔的争议费用。
[0111]
本实施例中，监管阶段的具体方法为：
[0112]
监管部门从瞭望塔处获取支付通道网络中用户ua的交易数据，该交易数据包括通道内交 易数据和跨通 道交易数据datarouting＝{routing,path,seq}，其中，为 加密的通道状态；监管部门用通道用户ua的对称密钥esk对进行解密得到 原始通道交易数据监管部门从跨通道交易数据 datarouting中得知通道用户ua通过路径ua→
u1→…→un-1
→
ub向通道用户ub支付a，并根 据哈希时间锁序列号seq在路径用户中查找该跨通道交易的通道状态；因此，监管部门实现 了对整个区块链支付通道网络的监管。
[0113]
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照 前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前 述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而 这些修改或者替换，并不使相应技术方案的本质脱离本发明权利要求所限定的
范围。