CN111768192A - 链下通道金额均衡方法及系统 - Google Patents

链下通道金额均衡方法及系统 Download PDF

Info

Publication number
CN111768192A
CN111768192A CN202010559730.0A CN202010559730A CN111768192A CN 111768192 A CN111768192 A CN 111768192A CN 202010559730 A CN202010559730 A CN 202010559730A CN 111768192 A CN111768192 A CN 111768192A
Authority
CN
China
Prior art keywords
transaction
tee
channel
node
balanced
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010559730.0A
Other languages
English (en)
Other versions
CN111768192B (zh
Inventor
葛钟慧
谷大武
刘志强
龙宇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Jiaotong University
Original Assignee
Shanghai Jiaotong University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Jiaotong University filed Critical Shanghai Jiaotong University
Priority to CN202010559730.0A priority Critical patent/CN111768192B/zh
Publication of CN111768192A publication Critical patent/CN111768192A/zh
Application granted granted Critical
Publication of CN111768192B publication Critical patent/CN111768192B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明提供了一种链下通道金额均衡方法及系统，包括：链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；通道状态更新：节点在获得交易完成凭证后，据此在链下更新通道状态。本发明减少了均衡所需的确认时间与手续费；设定由TEE统筹运行链下均衡交易协议，在保证参与节点资金安全的前提下，使得协议更加隐私、有效地执行。

Description

链下通道金额均衡方法及系统
技术领域
本发明涉及区块链技术领域，具体地，涉及链下通道金额均衡方法及系统。
背景技术
作为近年来在技术研究与落地应用方面飞速发展的技术，区块链是一个网络间节点共同维护的分布式账本，解决了节点间交易或沟通时，需要第三方机构介入或者相互信任的问题。以太坊中智能合约的提出，使得节点间的合约可自动触发执行，降低了合约运行成本。然而，由于其内在的分布式特性，任何一笔交易均需通过网络中所有矿工的认证，导致网络的吞吐率低，交易延时长。以比特币为例，其采用的工作量证明(Proof-of-Work)机制使得网络的交易吞吐率为7笔每秒，交易的确认时间约为1小时。相比于传统的中心化机制如Visa吞吐率可达4.7万笔每秒，交易确认时间为秒级，区块链的大规模发展与应用受到极大限制。
为解决区块链的可扩展性问题，链下扩容方案应运而生。链下扩容方案也称Layer-2方案，将处于Layer-1的区块链作为信任根，并将交易与计算等转移到链下进行。只有在需要链上公证如纠纷仲裁时，交易方才与区块链交互并将相关凭证上链。相比于链上扩容方案如Bitcoin-NG、扩大区块容量、分片等，链下扩容方案不涉及区块链自身的属性，可附加在任意区块链上，因而具有更高的兼容性；由于交易在链下进行，因此网络吞吐率与交易时延仅受链下交易环境如网络时延的影响，极大的提升了交易性能；由于交易无需全网广播与矿工认证，因此具有隐私保护的特性。
支付通道是典型的链下扩容方案，代表应用有闪电网络(Lightning Network)等。抽象来看，一个支付通道的运行周期分为三个基本阶段：通道建立、通道状态更新与通道关闭。在通道建立阶段，两方或多方在链上开启共同控制的合约，并向其中预存金额；随后，参与方在链下对通道状态进行更新，即通道中金额的再分配；在参与方对通道状态产生纠纷或者要关闭通道时，提交通道状态至链上，由链上对通道分配做出判决。由支付通道延伸出的状态通道建立在图灵完备的区块链合约平台上，可实现通道中任意的状态转换，代表应用有Sprites等。
对于一个链下通道，在其双向的交易流向速率不同时，会导致通道内的金额聚集于某一方，导致尽管此通道为双向通道，但已退化为单向通道，降低了通道的使用率与网络吞吐率。基本的解决方案为关闭并重新开启此通道，以此来平衡此通道内的金额。但是此方案涉及两笔链上交易，需要较长的交易确认时间与手续费。节点间通过链下交易均衡通道间的金额，将通道从单向恢复至双向。
如图，通道在初始建立时的节点余额分配如图5左图所示，在运行一段时间后的通道内金额分配如图5右图所示。此时各节点在其中一通道中的余额耗尽，而在另一通道中积聚了通道的几乎大部分金额，即节点在链下支付网络中的余额分配不均。此时各节点通过组成环路交易，均衡各节点在涉及通道中的余额，即通过
Figure BDA0002545840300000021
Figure BDA0002545840300000022
三笔交易组成的交易集，在链下均衡δ的金额值。
为协调各参与均衡交易的节点的均衡需求，并使得各通道内的状态能得到一致性更新，需要选择一个领导节点来统筹运行链下均衡交易协议并生成均衡交易集，向各节点发送此交易集，由各节点对交易集的正确性进行验证，并据此对通道状态进行更新。但是此方案会向领导节点泄漏各参与节点、涉及通道、均衡交易等隐私信息，同时协议运行的效率无法得到保证，即无法保证领导节点能按时、有效地完成均衡交易。
发明内容
针对现有技术中的缺陷，本发明的目的是提供一种链下通道金额均衡方法及系统。
根据本发明提供的一种链下通道金额均衡方法，包括：
链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；
链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；
通道状态更新：节点在获得交易完成凭证后，据此在链下更新通道状态。
优选地，所述链下均衡协议包括：
协议初始化步骤：参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE，随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求；
均衡支付开启步骤：TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知；
均衡需求发送步骤：收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求；
均衡交易集生成与发送步骤：TEE收到各节点的均衡需求之后，生成均衡交易集，发送均衡交易信息给节点；
均衡交易确认步骤：节点收到均衡交易信息后，对其进行验证，若验证通过，则返回确认信息；
均衡交易完成凭证生成步骤：TEE在收到各节点返回的确认信息之后，生成均衡交易完成凭证，将均衡交易完成凭证发送至各节点。
优选地，所述均衡需求发送步骤包括：
节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
节点冻结两个通道的状态，以保证后续均衡交易的完成，此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额，双方的签名用σdmd表示；
节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE。
优选地，所述均衡交易集生成与发送步骤：
验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；
验证各通道内的均衡需求是否一致，对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}，验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan：验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
生成均衡交易金额，为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
生成均衡交易，对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
生成均衡交易集，将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
发送均衡交易信息，对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
所述均衡交易确认步骤：
将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-fligt，验证不通过则将此信息抛弃；
验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE。
优选地，所述均衡交易完成凭证生成步骤：
开启时长为Tcoll的定时器；
收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
若在定时期限内未能收集到所有信息，则设置flag＝cancel；
在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
将凭证(Certificate,σcert)发送至各节点。
优选地，所述链上TEE管理合约由六个函数构成：Register()函数、Evidence()函数、isAvailable()函数、Call()函数、Answer()函数以及isCorrect()函数；
所述Register()函数：验证TEE是否具有参与链下均衡支付的资格；
所述Evidence()函数：停用未能完成链下均衡支付的TEE；
所述isAvailable()函数：验证TEE是否有效；
所述Call()函数：发布对链下均衡交易完成凭证的征集；
所述Answer()函数：提交链下均衡交易完成凭证；
所述isCorrect()函数：验证链下均衡交易是否完成。
优选地，根据所述链上TEE管理合约对TEE管理：
TEE注册与移除步骤：确认某个TEE是否是合格的TEE，并且把出错的TEE移除；
交易凭证征集步骤：对交易凭证的征集，通过征集结果确认某个TEE是否正确履职，并把出错的TEE移除。
优选地，所述TEE注册与移除步骤包括：
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE，TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证；
TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程包括：
以集合AT存储目前可用的TEE，以集合BL存储被停用的TEE，初始化为空集；
验证此TEE为新加入，且未被停用，即
Figure BDA0002545840300000051
通过远程验证，确认此TEE的合法性与QUOTE的正确性，若验证不通过则将此消息抛弃；
将此TEE视为有效，将其公钥加入AT中，即AT:＝AT∪{pkTEE}。
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下：
将TEE的公钥pkTEE从集合AT中移除，并加入集合BL；
设置此TEE在停用之前的有效期为Tvalid；
其中，有效期Tvalid的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall；Tcoll指在链下均衡协议运行时，TEE发送给各节点交易信息后，开启Tcoll的时间窗收集节点的确认信息；Tcall指在链上对交易凭证征集时所设置的时间窗；
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下：
若此输入TEE公钥在AT中，或者在此函数调用之时，此TEE公钥在BL中，但仍处于有效期，则返回此TEE有效；
返回此TEE无效，即已被停用；
所述交易凭证征集步骤包括：
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果；
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下：
以集合CL存储提交的交易开启凭证，初始化为空集；
将cm分解为(flag,commit,pkTEE)；
验证σcm是否为pkTEE对cm的签名，若验证不通过则将此消息抛弃；
调用isAvailable(pkTEE)验证此TEE是否有效，若无效则将此消息抛弃；
验证flag＝＝in-flight，且cm不在集合CL中，若验证不通过则将此消息抛弃；
将cm加入集合CL中，并设定此凭证的状态为等待应答，设定应答期为Tcall，即交易完成凭证的提交与矿工对此凭证的验证需在此应答期内完成；
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成；Δ表示一笔交易从广播到上链并被所有节点认证所需的时间，即从一笔交易生成后在网络中广播，到上链，到被节点认可，之间所需的时间；
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下：
将Certificate分解为(flag,commit,pkTEE)；
验证σcert是否为pkTEE对Certificate的签名，若验证不通过则将此消息抛弃；
验证此凭证在提交时是否在应答期内。若超出征集期则将此消息抛弃；
验证在集合CL中，凭证cm＝(in-flight,commit,pkTEE)处于等待应答状态，若验证不通过则将此消息抛弃；
验证flag＝＝(complete∨cancel)，将cm在CL中的状态做对应地变更为交易执行或取消；
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下：
若cm不在集合CL中，返回此轮交易取消；
验证此功能在被调用时是否在cm的征集期内。若在征集期内则抛弃此消息；
验证cm是否处于等待应答状态，即在在征集期内未有凭证提交。若是，则可判决TEE未能完成此轮均衡交易，调用Evidence()函数将此TEE停用；返回此轮交易取消；
返回cm在集合CL中对应的状态，即交易执行，或交易取消。
优选地，所述通道状态更新包括：
节点在获得交易完成凭证后，可据此在链下更新通道状态，若另一方拒绝协同更新，则节点可在链上发起通道状态更新，为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况；
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下：
验证通道内第r轮的状态Stater是否是被通道双方共同签名确认的状态，若验证通过则第r+1轮通道状态待更新；若验证不通过则将此消息抛弃；
将cm分解为(flag,commit,pkTEE),验证path是否为tx对应commit的Merkle路径，若验证不通过则将此消息抛弃；
设置此次状态更新的期限为Tdispute，即若在此段时间内有高于r轮的通道状态提交，则抛弃此次链上更新；
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
验证此函数调用时，第r+1轮状态仍处于待更新状态；若验证不通过则抛弃此消息；
验证此函数在调用时是否在状态更新期内。若在期限内则抛弃此消息；
以cm为输入，调用ContractTR中的isCorrect()函数，确认此笔均衡交易的完成情况。若返回交易执行，则根据提交的tx更新通道状态；若返回交易取消,则维持原通道状态；
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对：
链上有对此交易完成状态的认证，则此时节点只需在Tdispute期限后调用Resolve()函数；
链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
链上无对此交易凭证的征集，且节点无交易完成凭证，此时节点需通过调用Call()函数发布对凭证的征集；
链上处于对此凭证的征集期，且节点有交易完成凭证，此时节点需在征集期内通过调用Answer()函数提交凭证；
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
根据本发明提供的一种链下通道金额均衡系统，包括：
链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；
链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；
通道状态更新模块：节点在获得交易完成凭证后，据此在链下更新通道状态；
所述链下均衡协议包括：
协议初始化模块：参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE，随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求；
均衡支付开启模块：TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知；
均衡需求发送模块：收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求；
均衡交易集生成与发送模块：TEE收到各节点的均衡需求之后，生成均衡交易集，发送均衡交易信息给节点；
均衡交易确认模块：节点收到均衡交易信息后，对其进行验证，若验证通过，则返回确认信息；
均衡交易完成凭证生成模块：TEE在收到各节点返回的确认信息之后，生成均衡交易完成凭证，将均衡交易完成凭证发送至各节点；
所述均衡需求发送模块：
节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
节点冻结两个通道的状态，以保证后续均衡交易的完成，此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额，双方的签名用σdmd表示；
节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE；
所述均衡交易集生成与发送模块：
验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；
验证各通道内的均衡需求是否一致，对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}，验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan：验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
生成均衡交易金额，为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
生成均衡交易，对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
生成均衡交易集，将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
发送均衡交易信息，对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
所述均衡交易确认模块：
将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-fligt，验证不通过则将此信息抛弃；
验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE；
所述均衡交易完成凭证生成模块：
开启时长为Tcoll的定时器；
收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
若在定时期限内未能收集到所有信息，则设置flag＝cancel；
在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
将凭证(Certificate,σcert)发送至各节点；
所述链上TEE管理合约由六个函数构成：Register()函数、Evidence()函数、isAvailable()函数、Call()函数、Answer()函数以及isCorrect()函数；
所述Register()函数：验证TEE是否具有参与链下均衡支付的资格；
所述Evidence()函数：停用未能完成链下均衡支付的TEE；
所述isAvailable()函数：验证TEE是否有效；
所述Call()函数：发布对链下均衡交易完成凭证的征集；
所述Answer()函数：提交链下均衡交易完成凭证；
所述isCorrect()函数：验证链下均衡交易是否完成；
根据所述链上TEE管理合约对TEE管理：
TEE注册与移除模块：确认某个TEE是否是合格的TEE，并且把出错的TEE移除；
交易凭证征集模块：对交易凭证的征集，通过征集结果确认某个TEE是否正确履职，并把出错的TEE移除；
所述TEE注册与移除模块包括：
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE，TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证；
TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程包括：
以集合AT存储目前可用的TEE，以集合BL存储被停用的TEE，初始化为空集；
验证此TEE为新加入，且未被停用，即
Figure BDA0002545840300000111
通过远程验证，确认此TEE的合法性与QUOTE的正确性，若验证不通过则将此消息抛弃；
将此TEE视为有效，将其公钥加入AT中，即AT:＝AT∪{pkTEE}。
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下：
将TEE的公钥pkTEE从集合AT中移除，并加入集合BL；
设置此TEE在停用之前的有效期为Tvalid；
其中，有效期Tvalid的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall；Tcoll指在链下均衡协议运行时，TEE发送给各节点交易信息后，开启Tcoll的时间窗收集节点的确认信息；Tcall指在链上对交易凭证征集时所设置的时间窗；
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下：
若此输入TEE公钥在AT中，或者在此函数调用之时，此TEE公钥在BL中，但仍处于有效期，则返回此TEE有效；
返回此TEE无效，即已被停用；
所述交易凭证征集模块：
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果；
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下：
以集合CL存储提交的交易开启凭证，初始化为空集；
将cm分解为(flag,commit,pkTEE)；
验证σcm是否为pkTEE对cm的签名，若验证不通过则将此消息抛弃；
调用isAvailable(pkTEE)验证此TEE是否有效，若无效则将此消息抛弃；
验证flag＝＝in-flight，且cm不在集合CL中，若验证不通过则将此消息抛弃；
将cm加入集合CL中，并设定此凭证的状态为等待应答，设定应答期为Tcall，即交易完成凭证的提交与矿工对此凭证的验证需在此应答期内完成；
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成；Δ表示一笔交易从广播到上链并被所有节点认证所需的时间，即从一笔交易生成后在网络中广播，到上链，到被节点认可，之间所需的时间；
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下：
将Certificate分解为(flag,commit,pkTEE)；
验证σcert是否为pkTEE对Certificate的签名，若验证不通过则将此消息抛弃；
验证此凭证在提交时是否在应答期内。若超出征集期则将此消息抛弃；
验证在集合CL中，凭证cm＝(in-flight,commit,pkTEE)处于等待应答状态，若验证不通过则将此消息抛弃；
验证flag＝＝(complete∨cancel)，将cm在CL中的状态做对应地变更为交易执行或取消；
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下：
若cm不在集合CL中，返回此轮交易取消；
验证此功能在被调用时是否在cm的征集期内。若在征集期内则抛弃此消息；
验证cm是否处于等待应答状态，即在在征集期内未有凭证提交。若是，则可判决TEE未能完成此轮均衡交易，调用Evidence()函数将此TEE停用；返回此轮交易取消；
返回cm在集合CL中对应的状态，即交易执行，或交易取消；
所述通道状态更新模块：
节点在获得交易完成凭证后，可据此在链下更新通道状态，若另一方拒绝协同更新，则节点可在链上发起通道状态更新，为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况；
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下：
验证通道内第r轮的状态Stater是否是被通道双方共同签名确认的状态，若验证通过则第r+1轮通道状态待更新；若验证不通过则将此消息抛弃；
将cm分解为(flag,commit,pkTEE),验证path是否为tx对应commit的Merkle路径，若验证不通过则将此消息抛弃；
设置此次状态更新的期限为Tdispute，即若在此段时间内有高于r轮的通道状态提交，则抛弃此次链上更新；
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
验证此函数调用时，第r+1轮状态仍处于待更新状态；若验证不通过则抛弃此消息；
验证此函数在调用时是否在状态更新期内。若在期限内则抛弃此消息；
以cm为输入，调用ContractTR中的isCorrect()函数，确认此笔均衡交易的完成情况。若返回交易执行，则根据提交的tx更新通道状态；若返回交易取消,则维持原通道状态；
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对：
链上有对此交易完成状态的认证，则此时节点只需在Tdispute期限后调用Resolve()函数；
链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
链上无对此交易凭证的征集，且节点无交易完成凭证，此时节点需通过调用Call()函数发布对凭证的征集；
链上处于对此凭证的征集期，且节点有交易完成凭证，此时节点需在征集期内通过调用Answer()函数提交凭证；
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
与现有技术相比，本发明具有如下的有益效果：
本发明提出了一种基于可信执行环境的链下通道金额均衡方案，与链上均衡方案相比，本发明减少了均衡所需的确认时间与手续费；设定由TEE统筹运行链下均衡交易协议，在保证参与节点资金安全的前提下，使得协议更加隐私、有效地执行。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1为本发明提供的链下均衡协议的流程示意图。
图2为本发明提供的节点生成确认消息示意图。
图3为本发明提供的对交易完成凭证的征集与应答流程示意图。
图4为本发明提供的链上状态更新的流程示意图。
图5为本发明提供的通道的节点余额分配示意图。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。
根据本发明提供的一种链下通道金额均衡方法，包括：
链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；
链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；
通道状态更新：节点在获得交易完成凭证后，据此在链下更新通道状态。
具体地，所述链下均衡协议包括：
协议初始化步骤：参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE，随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求；
均衡支付开启步骤：TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知；
均衡需求发送步骤：收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求；
均衡交易集生成与发送步骤：TEE收到各节点的均衡需求之后，生成均衡交易集，发送均衡交易信息给节点；
均衡交易确认步骤：节点收到均衡交易信息后，对其进行验证，若验证通过，则返回确认信息；
均衡交易完成凭证生成步骤：TEE在收到各节点返回的确认信息之后，生成均衡交易完成凭证，将均衡交易完成凭证发送至各节点。
具体地，所述均衡需求发送步骤包括：
节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
节点冻结两个通道的状态，以保证后续均衡交易的完成，此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额，双方的签名用σdmd表示；
节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE。
具体地，所述均衡交易集生成与发送步骤：
验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；
验证各通道内的均衡需求是否一致，对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}，验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan：验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
生成均衡交易金额，为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
生成均衡交易，对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
生成均衡交易集，将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
发送均衡交易信息，对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
所述均衡交易确认步骤：
将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-fligt，验证不通过则将此信息抛弃；
验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE。
具体地，所述均衡交易完成凭证生成步骤：
开启时长为Tcoll的定时器；
收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
若在定时期限内未能收集到所有信息，则设置flag＝cancel；
在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
将凭证(Certificate,σcert)发送至各节点。
具体地，所述链上TEE管理合约由六个函数构成：Register()函数、Evidence()函数、isAvailable()函数、Call()函数、Answer()函数以及isCorrect()函数；
所述Register()函数：验证TEE是否具有参与链下均衡支付的资格；
所述Evidence()函数：停用未能完成链下均衡支付的TEE；
所述isAvailable()函数：验证TEE是否有效；
所述Call()函数：发布对链下均衡交易完成凭证的征集；
所述Answer()函数：提交链下均衡交易完成凭证；
所述isCorrect()函数：验证链下均衡交易是否完成。
具体地，根据所述链上TEE管理合约对TEE管理：
TEE注册与移除步骤：确认某个TEE是否是合格的TEE，并且把出错的TEE移除；
交易凭证征集步骤：对交易凭证的征集，通过征集结果确认某个TEE是否正确履职，并把出错的TEE移除。
具体地，所述TEE注册与移除步骤包括：
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE，TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证；
TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程包括：
以集合AT存储目前可用的TEE，以集合BL存储被停用的TEE，初始化为空集；
验证此TEE为新加入，且未被停用，即
Figure BDA0002545840300000181
通过远程验证，确认此TEE的合法性与QUOTE的正确性，若验证不通过则将此消息抛弃；
将此TEE视为有效，将其公钥加入AT中，即AT:＝AT∪{pkTEE}。
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下：
将TEE的公钥pkTEE从集合AT中移除，并加入集合BL；
设置此TEE在停用之前的有效期为Tvalid；
其中，有效期Tvalid的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall；Tcoll指在链下均衡协议运行时，TEE发送给各节点交易信息后，开启Tcoll的时间窗收集节点的确认信息；Tcall指在链上对交易凭证征集时所设置的时间窗；
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下：
若此输入TEE公钥在AT中，或者在此函数调用之时，此TEE公钥在BL中，但仍处于有效期，则返回此TEE有效；
返回此TEE无效，即已被停用；
所述交易凭证征集步骤包括：
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果；
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下：
以集合CL存储提交的交易开启凭证，初始化为空集；
将cm分解为(flag,commit,pkTEE)；
验证σcm是否为pkTEE对cm的签名，若验证不通过则将此消息抛弃；
调用isAvailable(pkTEE)验证此TEE是否有效，若无效则将此消息抛弃；
验证flag＝＝in-flight，且cm不在集合CL中，若验证不通过则将此消息抛弃；
将cm加入集合CL中，并设定此凭证的状态为等待应答，设定应答期为Tcall，即交易完成凭证的提交与矿工对此凭证的验证需在此应答期内完成；
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成；Δ表示一笔交易从广播到上链并被所有节点认证所需的时间，即从一笔交易生成后在网络中广播，到上链，到被节点认可，之间所需的时间；
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下：
将Certificate分解为(flag,commit,pkTEE)；
验证σcert是否为pkTEE对Certificate的签名，若验证不通过则将此消息抛弃；
验证此凭证在提交时是否在应答期内。若超出征集期则将此消息抛弃；
验证在集合CL中，凭证cm＝(in-flight,commit,pkTEE)处于等待应答状态，若验证不通过则将此消息抛弃；
验证flag＝＝(complete∨cancel)，将cm在CL中的状态做对应地变更为交易执行或取消；
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下：
若cm不在集合CL中，返回此轮交易取消；
验证此功能在被调用时是否在cm的征集期内。若在征集期内则抛弃此消息；
验证cm是否处于等待应答状态，即在在征集期内未有凭证提交。若是，则可判决TEE未能完成此轮均衡交易，调用Evidence()函数将此TEE停用；返回此轮交易取消；
返回cm在集合CL中对应的状态，即交易执行，或交易取消。
具体地，所述通道状态更新包括：
节点在获得交易完成凭证后，可据此在链下更新通道状态，若另一方拒绝协同更新，则节点可在链上发起通道状态更新，为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况；
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下：
验证通道内第r轮的状态Stater是否是被通道双方共同签名确认的状态，若验证通过则第r+1轮通道状态待更新；若验证不通过则将此消息抛弃；
将cm分解为(flag,commit,pkTEE),验证path是否为tx对应commit的Merkle路径，若验证不通过则将此消息抛弃；
设置此次状态更新的期限为Tdispute，即若在此段时间内有高于r轮的通道状态提交，则抛弃此次链上更新；
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
验证此函数调用时，第r+1轮状态仍处于待更新状态；若验证不通过则抛弃此消息；
验证此函数在调用时是否在状态更新期内。若在期限内则抛弃此消息；
以cm为输入，调用ContractTR中的isCorrect()函数，确认此笔均衡交易的完成情况。若返回交易执行，则根据提交的tx更新通道状态；若返回交易取消,则维持原通道状态；
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对：
链上有对此交易完成状态的认证，则此时节点只需在Tdispute期限后调用Resolve()函数；
链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
链上无对此交易凭证的征集，且节点无交易完成凭证，此时节点需通过调用Call()函数发布对凭证的征集；
链上处于对此凭证的征集期，且节点有交易完成凭证，此时节点需在征集期内通过调用Answer()函数提交凭证；
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
本发明提供的链下通道金额均衡系统，可以通过本发明给的链下通道金额均衡方法的步骤流程实现。本领域技术人员可以将所述链下通道金额均衡方法，理解为所述链下通道金额均衡系统的一个优选例。
根据本发明提供的一种链下通道金额均衡系统，包括：
链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；
链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；
通道状态更新模块：节点在获得交易完成凭证后，据此在链下更新通道状态；
所述链下均衡协议包括：
协议初始化模块：参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE，随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求；
均衡支付开启模块：TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知；
均衡需求发送模块：收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求；
均衡交易集生成与发送模块：TEE收到各节点的均衡需求之后，生成均衡交易集，发送均衡交易信息给节点；
均衡交易确认模块：节点收到均衡交易信息后，对其进行验证，若验证通过，则返回确认信息；
均衡交易完成凭证生成模块：TEE在收到各节点返回的确认信息之后，生成均衡交易完成凭证，将均衡交易完成凭证发送至各节点；
所述均衡需求发送模块：
节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
节点冻结两个通道的状态，以保证后续均衡交易的完成，此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额，双方的签名用σdmd表示；
节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE；
所述均衡交易集生成与发送模块：
验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；
验证各通道内的均衡需求是否一致，对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}，验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan：验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
生成均衡交易金额，为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
生成均衡交易，对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
生成均衡交易集，将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
发送均衡交易信息，对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
所述均衡交易确认模块：
将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-fligt，验证不通过则将此信息抛弃；
验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE；
所述均衡交易完成凭证生成模块：
开启时长为Tcoll的定时器；
收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
若在定时期限内未能收集到所有信息，则设置flag＝cancel；
在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
将凭证(Certificate,σcert)发送至各节点；
所述链上TEE管理合约由六个函数构成：Register()函数、Evidence()函数、isAvailable()函数、Call()函数、Answer()函数以及isCorrect()函数；
所述Register()函数：验证TEE是否具有参与链下均衡支付的资格；
所述Evidence()函数：停用未能完成链下均衡支付的TEE；
所述isAvailable()函数：验证TEE是否有效；
所述Call()函数：发布对链下均衡交易完成凭证的征集；
所述Answer()函数：提交链下均衡交易完成凭证；
所述isCorrect()函数：验证链下均衡交易是否完成；
根据所述链上TEE管理合约对TEE管理：
TEE注册与移除模块：确认某个TEE是否是合格的TEE，并且把出错的TEE移除；
交易凭证征集模块：对交易凭证的征集，通过征集结果确认某个TEE是否正确履职，并把出错的TEE移除；
所述TEE注册与移除模块包括：
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE，TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证；
TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程包括：
以集合AT存储目前可用的TEE，以集合BL存储被停用的TEE，初始化为空集；
验证此TEE为新加入，且未被停用，即
Figure BDA0002545840300000241
通过远程验证，确认此TEE的合法性与QUOTE的正确性，若验证不通过则将此消息抛弃；
将此TEE视为有效，将其公钥加入AT中，即AT:＝AT∪{pkTEE}。
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下：
将TEE的公钥pkTEE从集合AT中移除，并加入集合BL；
设置此TEE在停用之前的有效期为Tvalid；
其中，有效期Tvalid的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall；Tcoll指在链下均衡协议运行时，TEE发送给各节点交易信息后，开启Tcoll的时间窗收集节点的确认信息；Tcall指在链上对交易凭证征集时所设置的时间窗；
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下：
若此输入TEE公钥在AT中，或者在此函数调用之时，此TEE公钥在BL中，但仍处于有效期，则返回此TEE有效；
返回此TEE无效，即已被停用；
所述交易凭证征集模块：
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果；
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下：
以集合CL存储提交的交易开启凭证，初始化为空集；
将cm分解为(flag,commit,pkTEE)；
验证σcm是否为pkTEE对cm的签名，若验证不通过则将此消息抛弃；
调用isAvailable(pkTEE)验证此TEE是否有效，若无效则将此消息抛弃；
验证flag＝＝in-flight，且cm不在集合CL中，若验证不通过则将此消息抛弃；
将cm加入集合CL中，并设定此凭证的状态为等待应答，设定应答期为Tcall，即交易完成凭证的提交与矿工对此凭证的验证需在此应答期内完成；
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成；Δ表示一笔交易从广播到上链并被所有节点认证所需的时间，即从一笔交易生成后在网络中广播，到上链，到被节点认可，之间所需的时间；
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下：
将Certificate分解为(flag,commit,pkTEE)；
验证σcert是否为pkTEE对Certificate的签名，若验证不通过则将此消息抛弃；
验证此凭证在提交时是否在应答期内。若超出征集期则将此消息抛弃；
验证在集合CL中，凭证cm＝(in-flight,commit,pkTEE)处于等待应答状态，若验证不通过则将此消息抛弃；
验证flag＝＝(complete∨cancel)，将cm在CL中的状态做对应地变更为交易执行或取消；
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下：
若cm不在集合CL中，返回此轮交易取消；
验证此功能在被调用时是否在cm的征集期内。若在征集期内则抛弃此消息；
验证cm是否处于等待应答状态，即在在征集期内未有凭证提交。若是，则可判决TEE未能完成此轮均衡交易，调用Evidence()函数将此TEE停用；返回此轮交易取消；
返回cm在集合CL中对应的状态，即交易执行，或交易取消；
所述通道状态更新模块：
节点在获得交易完成凭证后，可据此在链下更新通道状态，若另一方拒绝协同更新，则节点可在链上发起通道状态更新，为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况；
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下：
验证通道内第r轮的状态Stater是否是被通道双方共同签名确认的状态，若验证通过则第r+1轮通道状态待更新；若验证不通过则将此消息抛弃；
将cm分解为(flag,commit,pkTEE),验证path是否为tx对应commit的Merkle路径，若验证不通过则将此消息抛弃；
设置此次状态更新的期限为Tdispute，即若在此段时间内有高于r轮的通道状态提交，则抛弃此次链上更新；
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
验证此函数调用时，第r+1轮状态仍处于待更新状态；若验证不通过则抛弃此消息；
验证此函数在调用时是否在状态更新期内。若在期限内则抛弃此消息；
以cm为输入，调用ContractTR中的isCorrect()函数，确认此笔均衡交易的完成情况。若返回交易执行，则根据提交的tx更新通道状态；若返回交易取消,则维持原通道状态；
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对：
链上有对此交易完成状态的认证，则此时节点只需在Tdispute期限后调用Resolve()函数；
链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
链上无对此交易凭证的征集，且节点无交易完成凭证，此时节点需通过调用Call()函数发布对凭证的征集；
链上处于对此凭证的征集期，且节点有交易完成凭证，此时节点需在征集期内通过调用Answer()函数提交凭证；
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
下面通过优选例，对本发明进行更为具体地说明。
优选例1：
设定链下通道均衡协议运行在可信执行环境中，由可信执行环境的安全性作为协议安全、隐私运行的保障，将其签名的交易凭证作为各通道状态更新的依据。可信执行环境(Trusted Execution Environment，简写为TEE)是在计算机中开辟的一个安全区域，其中运行的代码与数据皆是外部不可访问的，即代码和数据的完整性与机密性可以得到保障。尽管TEE是安全可信的，但是TEE所处的计算机却能够控制TEE的运行与信息的发送。可以视为节点A(任意节点，不需要是参与节点)的计算机上有一个TEE环境，所有与此TEE交互的信息，节点A均不能破解。TEE是可信的，可以准确的执行预先设定的代码功能。虽然节点A不能破解发送给TEE的信息和TEE发出的信息，也不能干扰TEE中代码的运行，但是节点A可以控制TEE运行与否，比如关掉计算机。为保证TEE中运行的代码是正确的，TEE生成一个凭证QUOTE(在第五章第一节中提到)，收到这个凭证的节点可以到TEE的制造商(如intel)处验证。
我们假定提出的链下通道金额均衡方案运行在图灵完备的区块链平台上，如以太坊；同时智能合约的部署与执行不会受到任意节点的阻碍或影响。此外，我们假定节点发往链上的消息可在Δ时间内得到所有矿工认证并上链。链下通道金额均衡方案主要由链下均衡协议、TEE管理与通道状态更新三部分组成。链下均衡协议由节点选择的TEE运行；参与链下均衡支付的TEE通过链上合约ContractTR对其资格进行认证和管理；通道状态由通道双方在链下或链上通道管理合约Contractchan，依据均衡协议的运行结果进行更新。
链下均衡协议：
如图1所示，链下均衡协议由TEE运行，在TEE和具有均衡需求的节点集之间交互完成。链下均衡协议主要分为六步，在以下六节中分别介绍。
第1节协议初始化
参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE。此合约将在第五章中介绍。随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求。
第2节均衡支付开启
TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知。
第3节均衡需求发送
收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求，具体如下，
1)节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
2)节点冻结两个通道的状态，以保证后续均衡交易的完成。此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
3)节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额。双方的签名用σdmd表示；
4)节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE；
以图2中的Alice为例，其在通道Alice-Bob中的金额为100，在通道Alice-Carl中的金额为0。假设她要将Alice-Bob通道中的金额转移到Alice-Carl通道中，转移金额为50，则均衡目标为βAlice-Bob＝-50，βAlice-Carl＝50。此目标需要得到通道另一方的签名，即分别为Bob和Carl的签名，以此证明通道双方同意金额变动流向及数值。
第4节均衡交易集生成与发送
TEE收到各节点的均衡目标之后，生成均衡交易集，生成过程如下，
1)验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；2)验证各通道内的均衡需求是否一致。对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}。验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan。若验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
3)验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
4)生成均衡交易金额。为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
5)生成均衡交易。对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
6)生成均衡交易集。将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
7)发送均衡交易信息。对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
第5节均衡交易确认
节点收到均衡交易信息(TX,σTX)后，对其进行验证，验证过程如下，
1)将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
2)验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-flight。验证不通过则将此信息抛弃；
3)验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
4)节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE；
第6节均衡交易完成凭证生成
TEE在向各节点发送均衡交易信息之后，准备生成均衡交易完成凭证，具体如下，
1)开启时长为Tcoll的定时器；
2)收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
3)若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
4)若在定时期限内未能收集到所有信息，则设置flag＝cancel；
5)在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
6)将凭证(Certificate,σcert)发送至各节点；
至此，此轮链下均衡协议完成。各节点在收到交易完成凭证后据此更新通道状态；若节点未能收到此凭证，则可在链上发布对此凭证的征集。此过程将在链上TEE管理合约中叙述。
链上TEE管理合约：
链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理，由六个函数构成，Reg
ister(),Evidence(),isAvailable(),Call(),Answer(),isCorrect()，其功能如下，
1)Register().验证TEE是否具有参与链下均衡支付的资格；
2)Evidence().停用未能完成链下均衡支付的TEE；
3)isAvailable().验证TEE是否有效；
4)Call().发布对链下均衡交易完成凭证的征集；
5)Answer().提交链下均衡交易完成凭证；
6)isCorrect().验证链下均衡交易是否完成；
第1节 TEE注册与移除
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE。TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证。因此TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程如下，
Figure BDA0002545840300000301
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下，
Figure BDA0002545840300000302
其中，有效期的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall。对交易完成凭证的征集将在第2节中介绍。
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下，
Figure BDA0002545840300000311
第一节中的三个函数是确认某个TEE是否是合格的TEE，并且把出错的TEE移除。
第2节交易凭证征集
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果。对交易完成凭证的征集与应答流程如图3所示。
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下，
Figure BDA0002545840300000312
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成。
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下，
Figure BDA0002545840300000321
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下，
Figure BDA0002545840300000322
第二节中的三个函数关于对交易凭证的征集，可以通过其结果反应出TEE是否正确履职，并把出错的TEE移除。
第六章通道状态更新
节点在获得交易完成凭证后，可据此在链下更新通道状态。若另一方拒绝协同更新，则节点可在链上发起通道状态更新。为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况。链上状态更新的流程如图4所示。
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下，
Figure BDA0002545840300000323
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
Figure BDA0002545840300000331
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对，
1)链上有对此交易完成状态的认证。则此时节点只需在Tdispute期限后调用Resolve()函数；
2)链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
3)链上无对此交易凭证的征集，且节点无交易完成凭证。此时节点需通过调用Call()函数发布对凭证的征集；
4)链上处于对此凭证的征集期，且节点有交易完成凭证。此时节点需在征集期内通过调用Answer()函数提交凭证。
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
在本申请的描述中，需要理解的是，术语“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。
本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims (10)

1.一种链下通道金额均衡方法，其特征在于，包括：
链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；
链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；
通道状态更新：节点在获得交易完成凭证后，据此在链下更新通道状态。
2.根据权利要求1所述的链下通道金额均衡方法，其特征在于，所述链下均衡协议包括：
协议初始化步骤：参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE，随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求；
均衡支付开启步骤：TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知；
均衡需求发送步骤：收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求；
均衡交易集生成与发送步骤：TEE收到各节点的均衡需求之后，生成均衡交易集，发送均衡交易信息给节点；
均衡交易确认步骤：节点收到均衡交易信息后，对其进行验证，若验证通过，则返回确认信息；
均衡交易完成凭证生成步骤：TEE在收到各节点返回的确认信息之后，生成均衡交易完成凭证，将均衡交易完成凭证发送至各节点。
3.根据权利要求2所述的链下通道金额均衡方法，其特征在于，所述均衡需求发送步骤包括：
节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
节点冻结两个通道的状态，以保证后续均衡交易的完成，此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额，双方的签名用σdmd表示；
节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE。
4.根据权利要求3所述的链下通道金额均衡方法，其特征在于，所述均衡交易集生成与发送步骤：
验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；
验证各通道内的均衡需求是否一致，对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}，验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan：验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
生成均衡交易金额，为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
生成均衡交易，对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
生成均衡交易集，将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
发送均衡交易信息，对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
所述均衡交易确认步骤：
将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-fligt，验证不通过则将此信息抛弃；
验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE。
5.根据权利要求4所述的链下通道金额均衡方法，其特征在于，所述均衡交易完成凭证生成步骤：
开启时长为Tcoll的定时器；
收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
若在定时期限内未能收集到所有信息，则设置flag＝cancel；
在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
将凭证(Certificate,σcert)发送至各节点。
6.根据权利要求5所述的链下通道金额均衡方法，其特征在于，所述链上TEE管理合约由六个函数构成：Register()函数、Evidence()函数、isAvailable()函数、Call()函数、Answer()函数以及isCorrect()函数；
所述Register()函数：验证TEE是否具有参与链下均衡支付的资格；
所述Evidence()函数：停用未能完成链下均衡支付的TEE；
所述isAvailable()函数：验证TEE是否有效；
所述Call()函数：发布对链下均衡交易完成凭证的征集；
所述Answer()函数：提交链下均衡交易完成凭证；
所述isCorrect()函数：验证链下均衡交易是否完成。
7.根据权利要求6所述的链下通道金额均衡方法，其特征在于，根据所述链上TEE管理合约对TEE管理：
TEE注册与移除步骤：确认某个TEE是否是合格的TEE，并且把出错的TEE移除；
交易凭证征集步骤：对交易凭证的征集，通过征集结果确认某个TEE是否正确履职，并把出错的TEE移除。
8.根据权利要求7所述的链下通道金额均衡方法，其特征在于，所述TEE注册与移除步骤包括：
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE，TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证；
TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程包括：
以集合AT存储目前可用的TEE，以集合BL存储被停用的TEE，初始化为空集；
验证此TEE为新加入，且未被停用，即
Figure FDA0002545840290000041
通过远程验证，确认此TEE的合法性与QUOTE的正确性，若验证不通过则将此消息抛弃；
将此TEE视为有效，将其公钥加入AT中，即AT:＝AT∪{pkTEE}。
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下：
将TEE的公钥pkTEE从集合AT中移除，并加入集合BL；
设置此TEE在停用之前的有效期为Tvalid；
其中，有效期Tvalid的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall；Tcoll指在链下均衡协议运行时，TEE发送给各节点交易信息后，开启Tcoll的时间窗收集节点的确认信息；Tcall指在链上对交易凭证征集时所设置的时间窗；
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下：
若此输入TEE公钥在AT中，或者在此函数调用之时，此TEE公钥在BL中，但仍处于有效期，则返回此TEE有效；
返回此TEE无效，即已被停用；
所述交易凭证征集步骤包括：
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果；
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下：
以集合CL存储提交的交易开启凭证，初始化为空集；
将cm分解为(flag,commit,pkTEE)；
验证σcm是否为pkTEE对cm的签名，若验证不通过则将此消息抛弃；
调用isAvailable(pkTEE)验证此TEE是否有效，若无效则将此消息抛弃；
验证flag＝＝in-flight，且cm不在集合CL中，若验证不通过则将此消息抛弃；
将cm加入集合CL中，并设定此凭证的状态为等待应答，设定应答期为Tcall，即交易完成凭证的提交与矿工对此凭证的验证需在此应答期内完成；
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成；Δ表示一笔交易从广播到上链并被所有节点认证所需的时间，即从一笔交易生成后在网络中广播，到上链，到被节点认可，之间所需的时间；
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下：
将Certificate分解为(flag,commit,pkTEE)；
验证σcert是否为pkTEE对Certificate的签名，若验证不通过则将此消息抛弃；
验证此凭证在提交时是否在应答期内。若超出征集期则将此消息抛弃；
验证在集合CL中，凭证cm＝(in-flight,commit,pkTEE)处于等待应答状态，若验证不通过则将此消息抛弃；
验证flag＝＝(complete∨cancel)，将cm在CL中的状态做对应地变更为交易执行或取消；
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下：
若cm不在集合CL中，返回此轮交易取消；
验证此功能在被调用时是否在cm的征集期内。若在征集期内则抛弃此消息；
验证cm是否处于等待应答状态，即在在征集期内未有凭证提交。若是，则可判决TEE未能完成此轮均衡交易，调用Evidence()函数将此TEE停用；返回此轮交易取消；
返回cm在集合CL中对应的状态，即交易执行，或交易取消。
9.根据权利要求8所述的链下通道金额均衡方法，其特征在于，所述通道状态更新包括：
节点在获得交易完成凭证后，可据此在链下更新通道状态，若另一方拒绝协同更新，则节点向链上的通道合约Contractchan发起通道状态更新，为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约Contractchan通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况；
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下：
验证通道内第r轮的状态Stater是否是被通道双方共同签名确认的状态，若验证通过则第r+1轮通道状态待更新；若验证不通过则将此消息抛弃；
将cm分解为(flag,commit,pkTEE),验证path是否为tx对应commit的Merkle路径，若验证不通过则将此消息抛弃；
设置此次状态更新的期限为Tdispute，即若在此段时间内有高于r轮的通道状态提交，则抛弃此次链上更新；
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
验证此函数调用时，第r+1轮状态仍处于待更新状态；若验证不通过则抛弃此消息；
验证此函数在调用时是否在状态更新期内。若在期限内则抛弃此消息；
以cm为输入，调用ContractTR中的isCorrect()函数，确认此笔均衡交易的完成情况。若返回交易执行，则根据提交的tx更新通道状态；若返回交易取消,则维持原通道状态；
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对：
链上有对此交易完成状态的认证，则此时节点只需在Tdispute期限后调用Resolve()函数；
链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
链上无对此交易凭证的征集，且节点无交易完成凭证，此时节点需通过调用Call()函数发布对凭证的征集；
链上处于对此凭证的征集期，且节点有交易完成凭证，此时节点需在征集期内通过调用Answer()函数提交凭证；
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
10.一种链下通道金额均衡系统，其特征在于，包括：
链下均衡协议：由可信执行环境TEE运行，在TEE和具有均衡需求的节点集之间交互完成；
链上TEE管理合约：链上TEE管理合约ContractTR对参与均衡支付的TEE进行认证与管理；
通道状态更新模块：节点在获得交易完成凭证后，据此在链下更新通道状态；
所述链下均衡协议包括：
协议初始化模块：参与节点在链上TEE管理合约中认证有效的TEE集合，即在ContractTR中的集合AT中，选择一个TEE，随后各节点根据选择的TEE的公钥与TEE建立匿名通信通道，并向TEE发出均衡交易请求；
均衡支付开启模块：TEE收到来自节点集的均衡交易请求之后，TEE开启此轮均衡交易，并向各参与节点发出开启通知；
均衡需求发送模块：收到TEE发送的均衡交易开启通知，若节点确认参与此轮均衡交易，则向TEE发送此轮均衡需求；
均衡交易集生成与发送模块：TEE收到各节点的均衡需求之后，生成均衡交易集，发送均衡交易信息给节点；
均衡交易确认模块：节点收到均衡交易信息后，对其进行验证，若验证通过，则返回确认信息；
均衡交易完成凭证生成模块：TEE在收到各节点返回的确认信息之后，生成均衡交易完成凭证，将均衡交易完成凭证发送至各节点；
所述均衡需求发送模块：
节点确认此轮的均衡需求，即将金额转出的通道与金额转入的通道，与在各通道内期望的变动金额。通道以其唯一的标识符idchan表示，变动金额以βchan表示，大于0表示节点期望在此通道内获取金额，即作为此通道内均衡交易的接收方；小于0表示节点期望在此通道内转移金额，即作为此通道内均衡交易的发送方；
节点冻结两个通道的状态，以保证后续均衡交易的完成，此时若通道内的最新轮次为r，则此通道内的需求即为dmd＝{r,idchan,βchan}；
节点对dmd签名，并发给通道另一方签名，以此表示双方对此通道内金额流向以及金额变动值的认同，保证此金额变动值小于交易发送方在此通道内的余额，双方的签名用σdmd表示；
节点生成确认消息(Confirmation,{dmd,σdmd})，并将此消息发送给TEE；
所述均衡交易集生成与发送模块：
验证收到的各消息中附带的通道双方的签名是否正确，若不正确则将消息抛弃；
验证各通道内的均衡需求是否一致，对于同一个通道idchan，来自通道双方的需求dmd＝{r,idchan,βchan}与dmd′＝{r′,idchan,β′chan}，验证通道双方是否认同此通道所处的最新交易轮次，以及通道内的变动金额，即r＝＝r’且βchan＝-β′chan：验证通过，则将涉及通道存储在集合C中，即C＝C∪{idchan}，将其变动金额存储在集合A中，即A＝A∪{|βchan|}，若验证不通过则将此消息抛弃；
验证集合C中的通道是否能组成环路，抛弃不在环路内的节点，若不能组成环路则取消此轮均衡交易，并告知各节点；
生成均衡交易金额，为保证各参与节点的资金安全性，需满足其在通道内获得的金额值与转移的金额值相等，进而需满足此环路上各通道内的交易金额δ相等，为各通道金额变动值的最小值，即δ＝min{β|β∈A}；
生成均衡交易，对于通道idchan，若dmd＝{r,idchan,βchan}来自节点u，dmd′＝{r′,idchan,β′chan}来自节点v，且βchan<0，β′chan>0，则此通道内的交易发送方为u，接收方为v，交易为tx＝(r+1,u,v,δ)；
生成均衡交易集，将各均衡交易按照MerkleTree的结构组织起来，并将生成的MerkleRoot记为commit，将其与flag和TEE的公钥pkTEE组合生成均衡交易开启凭证cm＝(flag,commit,pkTEE)；设置flag＝in-flight表示交易集已生成，等待各节点的确认；TEE对cm签名生成σcm；
发送均衡交易信息，对于各参与节点，TEE将其涉及的分别作为发送方与接收方的两笔交易，以及对于每笔交易对应的MerklePath，封装为TX＝(cm,σcm,{tx,path})，并对TX签名，生成σTX，将消息(TX,σTX)发送给节点；
所述均衡交易确认模块：
将TX分解为TX＝(cm,σcm,{tx,path})，将cm分解为cm＝(flag,commit,pkTEE)；
验证σTX为公钥pkTEE对TX的签名，验证flag＝＝in-fligt，验证不通过则将此信息抛弃；
验证path是否为tx对应commit的Merkle路径，验证在两笔交易中是否分别作为交易发送方与接收方，且交易值是否相等，并不超过自己的转移意愿。验证不通过则将此信息抛弃；
节点对commit签名，生成σcommit，封装生成交易确认消息(Sign,commit,σcommit)，并将其发往TEE；
所述均衡交易完成凭证生成模块：
开启时长为Tcoll的定时器；
收到节点返回的交易确认信息，验证其签名，若签名不通过则设置flag＝cancel；
若在定时期限内收到所有节点的确认信息，并验证皆通过，则设置flag＝complete；
若在定时期限内未能收集到所有信息，则设置flag＝cancel；
在flag设定之后，生成均衡交易完成凭证Certificate＝(flag,commit,pkTEE)，并对此签名生成σcert；
将凭证(Certificate,σcert)发送至各节点；
所述链上TEE管理合约由六个函数构成：Register()函数、Evidence()函数、isAvailable()函数、Call()函数、Answer()函数以及isCorrect()函数；
所述Register()函数：验证TEE是否具有参与链下均衡支付的资格；
所述Evidence()函数：停用未能完成链下均衡支付的TEE；
所述isAvailable()函数：验证TEE是否有效；
所述Call()函数：发布对链下均衡交易完成凭证的征集；
所述Answer()函数：提交链下均衡交易完成凭证；
所述isCorrect()函数：验证链下均衡交易是否完成；
根据所述链上TEE管理合约对TEE管理：
TEE注册与移除模块：确认某个TEE是否是合格的TEE，并且把出错的TEE移除；
交易凭证征集模块：对交易凭证的征集，通过征集结果确认某个TEE是否正确履职，并把出错的TEE移除；
所述TEE注册与移除模块包括：
每个TEE具有一对公私钥，并且可为其中的程序与数据相关信息生成QUOTE，TEE公钥的合法性与QUOTE的正确性可通过远程认证，在TEE的生产商处验证；
TEE若要参与均衡支付，则以其公钥pkTEE与QUOTE为输入，调用Register()函数，由矿工对其合法性与正确性进行验证，验证过程包括：
以集合AT存储目前可用的TEE，以集合BL存储被停用的TEE，初始化为空集；
验证此TEE为新加入，且未被停用，即
Figure FDA0002545840290000101
通过远程验证，确认此TEE的合法性与QUOTE的正确性，若验证不通过则将此消息抛弃；
将此TEE视为有效，将其公钥加入AT中，即AT:＝AT∪{pkTEE}。
Evidence()函数由验证TEE是否完成链下均衡交易的isCorrect()函数调用，被调用时将作为输入的公钥对应的TEE停用，过程如下：
将TEE的公钥pkTEE从集合AT中移除，并加入集合BL；
设置此TEE在停用之前的有效期为Tvalid；
其中，有效期Tvalid的设定是为了使得在此期间，TEE正在处理的均衡交易，以及此交易可能存在的对交易完成凭证的征集，能够顺利完成，因此此期限需满足Tvalid≥Tcoll+Tcall；Tcoll指在链下均衡协议运行时，TEE发送给各节点交易信息后，开启Tcoll的时间窗收集节点的确认信息；Tcall指在链上对交易凭证征集时所设置的时间窗；
对TEE有效性的判断通过调用函数isAvailable()完成，以TEE的公钥为输入，判断过程如下：
若此输入TEE公钥在AT中，或者在此函数调用之时，此TEE公钥在BL中，但仍处于有效期，则返回此TEE有效；
返回此TEE无效，即已被停用；
所述交易凭证征集模块：
节点在返回交易确认信息后，开启Tcoll的定时器。若在此期限内未能从TEE处或从通道另一方处收到均衡交易完成凭证，则向链上发布对此凭证的征集；具有凭证的节点或者TEE可向链上提交应答，若不能及时提交应答会影响后续链上通道状态的更新；节点或合约可在征集期过后向合约查询征集结果；
Call()函数以均衡交易开启凭证cm和TEE的签名σcm为输入，发布对交易完成凭证的征集，征集过程如下：
以集合CL存储提交的交易开启凭证，初始化为空集；
将cm分解为(flag,commit,pkTEE)；
验证σcm是否为pkTEE对cm的签名，若验证不通过则将此消息抛弃；
调用isAvailable(pkTEE)验证此TEE是否有效，若无效则将此消息抛弃；
验证flag＝＝in-flight，且cm不在集合CL中，若验证不通过则将此消息抛弃；
将cm加入集合CL中，并设定此凭证的状态为等待应答，设定应答期为Tcall，即交易完成凭证的提交与矿工对此凭证的验证需在此应答期内完成；
其中，由于节点可在获得均衡交易开启凭证后即向链上提交对交易完成凭证的征集，为保证此时均衡交易与对凭证的征集均可顺利完成，需满足条件Tcall>Tcoll+Δ，即将完成凭证在生成后提交至链上，并得到矿工的认可的过程，均可在此期限内完成；Δ表示一笔交易从广播到上链并被所有节点认证所需的时间，即从一笔交易生成后在网络中广播，到上链，到被节点认可，之间所需的时间；
节点调用Answer()函数提交被征集的均衡交易完成凭证，完成对此轮均衡交易结果的认定，认定过程如下：
将Certificate分解为(flag,commit,pkTEE)；
验证σcert是否为pkTEE对Certificate的签名，若验证不通过则将此消息抛弃；
验证此凭证在提交时是否在应答期内。若超出征集期则将此消息抛弃；
验证在集合CL中，凭证cm＝(in-flight,commit,pkTEE)处于等待应答状态，若验证不通过则将此消息抛弃；
验证flag＝＝(complete∨cancel)，将cm在CL中的状态做对应地变更为交易执行或取消；
节点或合约以均衡交易开启凭证为输入，在征集期结束后调用isCorrect()函数查询对应的均衡交易的完成情况，查询过程如下：
若cm不在集合CL中，返回此轮交易取消；
验证此功能在被调用时是否在cm的征集期内。若在征集期内则抛弃此消息；
验证cm是否处于等待应答状态，即在在征集期内未有凭证提交。若是，则可判决TEE未能完成此轮均衡交易，调用Evidence()函数将此TEE停用；返回此轮交易取消；
返回cm在集合CL中对应的状态，即交易执行，或交易取消；
所述通道状态更新模块：
节点在获得交易完成凭证后，可据此在链下更新通道状态，若另一方拒绝协同更新，则节点可在链上发起通道状态更新，为保证在均衡交易中涉及的各通道可实现状态一致性更新，链上通道合约通过调用TEE管理合约中的isCorrect()函数，确认均衡交易的完成情况；
节点通过调用合约Contractchan的Dispute()函数向链上提交对通道内第r+1轮，即根据链下均衡交易而进行状态更新的请求，合约验证过程如下：
验证通道内第r轮的状态Stater是否是被通道双方共同签名确认的状态，若验证通过则第r+1轮通道状态待更新；若验证不通过则将此消息抛弃；
将cm分解为(flag,commit,pkTEE),验证path是否为tx对应commit的Merkle路径，若验证不通过则将此消息抛弃；
设置此次状态更新的期限为Tdispute，即若在此段时间内有高于r轮的通道状态提交，则抛弃此次链上更新；
在Tdispute期限后，节点通过调用Resolve()函数对第r+1轮的通道状态进行更新。此函数需调用合约ContractTR的isCorrect()函数来确认此轮均衡交易的完成状态，以此作为通道状态更新的依据，过程如下：
验证此函数调用时，第r+1轮状态仍处于待更新状态；若验证不通过则抛弃此消息；
验证此函数在调用时是否在状态更新期内。若在期限内则抛弃此消息；
以cm为输入，调用ContractTR中的isCorrect()函数，确认此笔均衡交易的完成情况。若返回交易执行，则根据提交的tx更新通道状态；若返回交易取消,则维持原通道状态；
从通道内节点的角度来看，当通道合约的Dispute()函数被调用而触发通道状态更新时，节点可处于以下几种情况，并做出如下应对：
链上有对此交易完成状态的认证，则此时节点只需在Tdispute期限后调用Resolve()函数；
链上无对此交易凭证的征集，且节点有交易完成凭证。此时节点需调用Call()函数发布对交易凭证的征集，并同时通过Answer()函数向提交相关凭证，完成对此均衡交易的完成状态认证；
链上无对此交易凭证的征集，且节点无交易完成凭证，此时节点需通过调用Call()函数发布对凭证的征集；
链上处于对此凭证的征集期，且节点有交易完成凭证，此时节点需在征集期内通过调用Answer()函数提交凭证；
由于通道状态依据链上对均衡交易完成情况的判断进行更新，为保证在状态更新期内均衡交易的完成情况能得到链上认证，期限需满足Tdispute>Tcall，即通道状态更新总是在状态认证完成后被触发。
CN202010559730.0A 2020-06-18 2020-06-18 链下通道金额均衡方法及系统 Active CN111768192B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010559730.0A CN111768192B (zh) 2020-06-18 2020-06-18 链下通道金额均衡方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010559730.0A CN111768192B (zh) 2020-06-18 2020-06-18 链下通道金额均衡方法及系统

Publications (2)

Publication Number Publication Date
CN111768192A true CN111768192A (zh) 2020-10-13
CN111768192B CN111768192B (zh) 2023-10-20

Family

ID=72721246

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010559730.0A Active CN111768192B (zh) 2020-06-18 2020-06-18 链下通道金额均衡方法及系统

Country Status (1)

Country Link
CN (1) CN111768192B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11949794B2 (en) 2021-05-08 2024-04-02 International Business Machines Corporation Data anonymization of blockchain-based processing pipeline

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110348853A (zh) * 2019-07-15 2019-10-18 中城智慧科技有限公司 一种基于标识认证的区块链离线交易方法和系统
CN110580413A (zh) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 基于链下授权的隐私数据查询方法及装置
CN110751468A (zh) * 2019-09-24 2020-02-04 上海交通大学 用于区块链扩展的多向状态通道方法、系统及介质
CN111078686A (zh) * 2019-11-13 2020-04-28 上海交通大学 基于存储证明的区块链方法及系统
CN111090888A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 验证合约的方法及装置
US20200169387A1 (en) * 2019-07-31 2020-05-28 Alibaba Group Holding Limited Blockchain-based data authorization method and apparatus

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110348853A (zh) * 2019-07-15 2019-10-18 中城智慧科技有限公司 一种基于标识认证的区块链离线交易方法和系统
US20200169387A1 (en) * 2019-07-31 2020-05-28 Alibaba Group Holding Limited Blockchain-based data authorization method and apparatus
CN110751468A (zh) * 2019-09-24 2020-02-04 上海交通大学 用于区块链扩展的多向状态通道方法、系统及介质
CN110580413A (zh) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 基于链下授权的隐私数据查询方法及装置
CN111078686A (zh) * 2019-11-13 2020-04-28 上海交通大学 基于存储证明的区块链方法及系统
CN111090888A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 验证合约的方法及装置

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HONGYANG LIU FENG SHEN , ZHIQIANG LIU , YU LONG: ""A Secure and Practical Blockchain Scheme for IoT"", 《2019 18TH IEEE INTERNATIONAL CONFERENCE ON TRUST, SECURITY AND PRIVACY IN COMPUTING AND COMMUNICATIONS/13TH IEEE INTERNATIONAL CONFERENCE ON BIG DATA SCIENCE AND ENGINEERING》, pages 1 - 8 *
VASILIOS A. SIRIS, DIMITRIOS DIMOPOULOS: ""IoT Resource Access utilizing Blockchains and Trusted Execution Environments"", 《2019 GLOBAL IOT SUMMIT》, pages 1 - 6 *
潘晨，刘志强，龙宇: ""区块链可扩展性研究：问题与方法"", 《计算机研究与发展》, pages 1 - 12 *
王秦远: ""基于 TrustZone 的联盟链安全 轻钱包设计与实现"", 《中国优秀硕士学位论文全文数据库信息科技经济与管理科学》, no. 3, pages 1 - 57 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11949794B2 (en) 2021-05-08 2024-04-02 International Business Machines Corporation Data anonymization of blockchain-based processing pipeline

Also Published As

Publication number Publication date
CN111768192B (zh) 2023-10-20

Similar Documents

Publication Publication Date Title
TWI679874B (zh) 跨區塊鏈的認證方法及裝置、電子設備
CN109508982B (zh) 区块链主链加并行多子链的随机并行拜占庭容错共识方法
CN110751468B (zh) 用于区块链扩展的多向状态通道方法、系统及介质
JP7021747B2 (ja) 決済システム、決済方法、利用者装置、決済プログラム
TW201943250A (zh) 跨區塊鏈的認證方法及裝置、電子設備
CN112541758A (zh) 基于区块链的多轮投票式容错排序共识机制与方法
CN112615915B (zh) 一种在私有链之间构建联盟链的方法
CN108881187A (zh) 一种适用于许可链场景的跨链数据传递方法及设备
CN112583917B (zh) 一种基于cscp的混合链构建方法
CN112907252B (zh) 一种基于多人链下通道的区块链交易方法及系统
WO2020173499A1 (zh) 基于公链的区块链子链创建方法及系统
CN112231741B (zh) 基于区块链系统的数据处理方法、装置、介质及电子设备
CN112232822A (zh) 区块链网络的交易处理方法、节点、设备及存储介质
CN111556026B (zh) 一种基于联盟链的匿名身份认证方法
CN115526553A (zh) 一种基于区块链的分布式共享仓储系统及实现方法
CN111786817A (zh) 一种区块链无线接入网中的安全高速数据通道及其设计方法
CN114154993A (zh) 一种基于区块链的v2g网络跨域交易安全方法
CN110503429B (zh) 一种去中心化的内容交互方法及系统
CN111768192A (zh) 链下通道金额均衡方法及系统
CN104753903A (zh) 一种认证方法、系统,及装置
CN111970370B (zh) 基于面向通信设备体系的多层区块链协议拓展系统及方法
CN113411338B (zh) 一种基于状态通道的链上-链下协同的资源交易方法
CN116186749A (zh) 基于区块链的业务处理方法、装置、电子设备和可读介质
CN112950180A (zh) 一种基于联盟链的通证方法、系统、电子设备及存储介质
CN116186786A (zh) 基于区块链的业务处理方法、装置、电子设备和可读介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant