CN112907252B - 一种基于多人链下通道的区块链交易方法及*** - Google Patents

一种基于多人链下通道的区块链交易方法及*** Download PDF

Info

Publication number
CN112907252B
CN112907252B CN202110144286.0A CN202110144286A CN112907252B CN 112907252 B CN112907252 B CN 112907252B CN 202110144286 A CN202110144286 A CN 202110144286A CN 112907252 B CN112907252 B CN 112907252B
Authority
CN
China
Prior art keywords
chain
channel
transaction
node
leader
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.)
Active
Application number
CN202110144286.0A
Other languages
English (en)
Other versions
CN112907252A (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.)
Institute of Computing Technology of CAS
Original Assignee
Institute of Computing Technology of CAS
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 Institute of Computing Technology of CAS filed Critical Institute of Computing Technology of CAS
Priority to CN202110144286.0A priority Critical patent/CN112907252B/zh
Publication of CN112907252A publication Critical patent/CN112907252A/zh
Application granted granted Critical
Publication of CN112907252B publication Critical patent/CN112907252B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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/405—Establishing or using transaction specific rules
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

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

Abstract

本发明提出一种基于多人链下通道的区块链交易方法及***，整个***状态更新以轮为最小单位，每一轮为节点间一次完整的交易过程，在多轮之间***检查点，检查点与前一个检查点之间的多轮组成整个***的同步周期。每轮结束时需要完成轮共识，每个周期结束时完成检查点共识。轮共识阶段由领导者发送结果，其他节点自愿验证，辅以监察服务，为下线节点提供服务；检查点共识进行所有节点在线的两阶段共识，支持通道节点的动态加入与退出。这样既能加速共识的过程，提升***通量，降低作恶被延迟发现、过多交易被撤销的风险，也能保证节点的灵活性和***的安全性。

Description

一种基于多人链下通道的区块链交易方法及***
技术领域
本发明涉及区块链的扩展性研究技术领域，并特别涉及一种区块链多人链下通道方法及***。
背景技术
区块链以其分布式、公开透明、安全等特性使得人们可以在互联网上方便快捷、低成本地进行价值交换，是实现价值互联网的基石。区块链技术在产生之初，只是针对小范围技术社区内的验证和使用需求，区块链协议的简单和健壮性是区块链技术的最初设计前提，因此并没有考虑向更广范围的、高并发的互联网应用推广。区块链网络中的节点采用统一的共识过程，实现了区块链安全性、去中心化的特性，但全网节点复制共享的全局账本数据，并将包含事务数据的区块数据在全网进行洪泛式传播，收到区块的每个共识节点需要验证并存储所有的数据，这样的机制造成了区块链性能受阻。因此，提升区块链的性能依旧有很大的探索空间。
区块链的低通量(以“***每秒钟处理的交易数量”衡量区块链的通量，即Transactionpersecond，下文以TPS指代)直接限制了其在实际生活中的应用场景。在区块链网络中，由于全网采用统一的共识过程，假设节点的平均网络带宽为10Mbit/s，那么每个节点的每秒可以接收的事务数量上限是1000。假设每个节点对每笔事务的验证时间大约5ms，每个节点每秒处理的事务理论数量上限为200。那么受同步机制和机器处理性能的影响，每个区块链网络节点每秒能接收到并验证的事务数量上限只是200左右。实际运行过程中，以太坊平均每秒处理15笔交易，就算性能更高的联盟链，在生产场景下的平均TPS也是千级别。随着以太坊等代表性公链***的交易量飙升，链上交易拥堵日益显现，以太坊的未确认交易数能达到15万笔左右。拥堵使得区块链网络内的交易费变得昂贵，拥堵严重时甚至会使交易执行失败。
而在金融领域中，现阶段支付宝，微信平均每秒处理交易千笔，峰值时达到了几十万笔；普通的***公司，支付卡VISA可以每秒处理近万笔事务，并且事务的确认时间只需几秒钟。由此可见，区块链***的通量和实际应用与日常使用的中心化交易解决方案依旧有很大的差距，因此，提高区块链通量已经成为当今区块链应用的迫切需求。
目前，国内外的研究中，提高区块链通量的方案主要分为链上扩容和链下扩容两种。
链上(on-chain)扩容是指通过优化、改进区块链的基本协议提升可扩展性，其包含的方案也比较多样，主要体现在三个层面:网络层、共识层和数据层。比如共识层中选择更快的共识算法；数据层中增加区块大小或者降低交易包的规模；网络层中提出了分片协议，区块链可以并行的处理交易，进而提升区块链性能。但在区块链技术的基础架构和协议框架下，通过优化其协议内置的参数(出块间隔、区块大小)和运行环境参数(挖矿节点的GPU、内存、硬盘、网络带宽)等，其预期的优化效果上限可以预估且无法达到传统中心化技术的通量水平，即链上扩容大多效果有限，而且扩容升级过程会造成硬分叉，分片虽然可以显著提高吞吐量，但是会降低主链安全性，且协议十分复杂，目前还不完备。试图在公链***上实现底层协议的大幅更替，将面临技术和社区的双重压力。
链下(off-chain)扩容则不改变区块链基本协议和原有信任假设，通过将一些操作放于链外以提升主链吞吐量，为区块链提供横向的扩展能力。链下扩容方案主要包括链外通道和侧链方案，侧链是指与主链平行的链，这些链可以有自己的共识机制，不需要和主链的共识机制相同，侧链并不是完全独立的，最终还是依赖主链做最终的结算，不具备即时终结性，且其关注的核心问题是业务场景跨链，并没有给通量需求带来技术进步。而链下通道具备即时终结性和交易隐私性，可以最小化链上操作，因此作为一种很有前景的链下扩容方案受到广泛关注。状态通道作为一种主流的链下扩容协议，可以支持不同种类的应用。具体来说，应用的参与者在链上锁定状态，参与者在链下局部共识，共识完成即可认为状态被确认。当要退出应用时，在链上清算状态。支付通道属于状态通道在支付领域内的具体应用，只完成资产转移的支付操作，实现速度更快、费用更低的交易。
根据支付通道内支持的可锁定资金人数，可以将通道类型划分为双人通道和多人通道。
双人通道是指通道的参与方是两个用户，当发送方和接收方分别在链上锁定资金后，这笔钱就固定在双方这个通道上，两方在通道内任意交易，局部对账本进行更新共识即可，天然的没有双花问题。比较具有代表性的是基于UTXO模型的闪电网络和基于账户模型的雷电网络。对于双人通道中非直接相连节点间进行交易时，一种方式是发送方和接收方在链上锁定资金，新建通道，两方进行任意多笔交易。如果每两方都需要上链建立一条通道，那么与链上的交互多，***整体开销较大，无法达到链下扩容的目的。另一种方式是在支付通道网络中寻路，通过其他中间节点路由交易，一跳一跳的支付，完成一笔交易。这种方式受网络拓扑，寻路算法，路径上资金容量的影响比较大，当网络联通度较低时，跨通道交易的路由路径比较长，会导致交易成功率降低，还存在通道阻塞，通道失衡等问题。
多人通道在一般意义上就是允许多个人参加到同一个通道中，交易在通道内的任意两方间进行，但是账本更新要在通道内全局进行，需要得到通道内所有节点的认可，一份资金能用于和多人交易，使得通道在资金使用上更灵活，同时带来了双花问题。多人通道中，同一个通道内的所有节点间都可以直接进行交易，节点通过一笔链上交易加入多人通道，则相当于建立了n条单向连接，相比于双人通道的一笔链上交易建立一条单向连接，网络连通度上有n倍的提升，减少跨通道交易的同时，可缓解双人通道内存在的问题，因此多人通道是提升区块链***通量的有效手段。
目前多人通道有多种构建模式，实质上都是在解决如何让多个人能互相更方便的转账，而不是像双人通道一样，将交易对象约束为某个特定的对等方。
一种是多人虚拟通道，作为一种伪多人通道，这种方案在双人通道的基础上做延伸，应用虚拟通道机制，构建多人的通道，本质还是双人通道，因为链上进行资金锁定时，还是双人的通道，资金绑定在特定链路上。具体来说：多人虚拟通道中包括两种类型的通道，一种是在链上锁定资金后构成的通道，叫做账本通道(前文中称为通道)，另一种是基于已存的账本通道建立的虚拟通道。比如A，B和C三个节点由账本通道直接相连，当需要A和C直接交易时，为了减少链上的开销，不是直接建立A到C的账本通道，而是在A与B和B与C的通道内预留一部分资金，让B作为不可信第三方，建立一条A与C的虚拟通道，中间节点B只在虚拟通道建立和撤销的时候参与共识，交易可以直接在A与C之间发生。多人虚拟通道意味着参与同一个多方通道的节点在一条直接相连的路径上，这条路径对底部的具体通道类型是无感知的，即可以是虚拟通道和账本通道的组合。这种方案应用虚拟通道，对原有的链下通道网络进行了扩展，提供了一种建立多方通道的选择，但是存在问题很明显：为了让多节点在一条直接相连的路径上，需要递归建立多条虚拟通道，机制复杂；虽然预锁定资金能缓解寻路问题，依旧存在路径可用，通道阻塞，通道失衡的问题，灵活性比较差；为了实现恶意情况下的惩罚机制，除了这条路径上的头节点和尾节点，其他中间节点锁定的资金都高于它的实际需要，削弱了资金的流动性；此方案并不支持节点的动态加入与退出，每次状态更新都需要一条路径上的参与交易节点达成共识，多跳且串行更新的方式使得其吞吐受限。
另一种方式则是利用智能合约，在链上锁定资金时，就是多个人锁定在了一个通道内，因此多个人构建通道后，链上锁定的资金可以在这个通道内的多个人间交易。具体的方案包括：NOCUST，***中包含链上的验证合约和固定的链下运营商(operator，专门为通道内其它节点提供交易的中转服务)，链下以运营商构成了星型的多人通道；每个节点将状态更新发送给运营商，由运营商周期性地向链上批量提交交易；一段时间内，节点只能发送一笔交易，要等确定后才可以继续链下交易。这种方案中固定的运营商引入了单点故障；周期性和链上交互增加了状态更新的时延；不支持并发处理，影响链下扩容的效果。Gnocchi作为一种支持高并发的多人链下支付方案，构建多人通道时，多方在链下就选定好了领导者，之后的打开通道及通道内状态更新均由领导者来负责。领导者周期性向链下通道内用户节点广播最新链下状态，通道内所有节点检查链下的结果。这种方案的领导者是被提前选择出来的，虽然可信度高，但依旧存在单点故障；交易过程中节点间无交互的验证，导致作恶(双花)只能被延迟发现；而且节点退出时通道内的更新要暂停，需要等链上状态更新后，链下才可以继续运行，那么伴随着节点的退出频率增加，通道的稳定性及吞吐会显著下降；当领导者要退出时，整个通道必须要关闭，对其他节点不友好，不是很合理。Garou则是基于可变中心节点的多人通道，通道内不是围绕着一个节点在转，节点都处于一种平等的地位。每个周期开始时，以所有节点的当前余额为随机种子，选举当前轮唯一的领导者。当前轮要结束的时候，通道内部执行两阶段的共识算法，通道内所有节点对结果达成一致，再进入下一轮。这种方案是弱中心的，每轮共识的过程中可实现节点的加入与退出。但所有节点都需要参与两阶段共识，那么随着链下通道内用户节点数的增加，通道内通信开销，交易时延也会增加，从而导致共识效率降低。使用每轮都更换领导者的方式，会对一些不具备计算能力的节点造成压力，且存在轮换到的领导者不在线的情况，通道也不可用。
发明人在进行多人链下通道的研究时，发现多人链下通道的关键优势在于用户在通道内锁定的一份资金，可以与通道内任意用户进行链下交易，提升通道资金流动性，并降低用户间通道建立成本。但是，多人链下通道同时引入了多人状态更新一致性的问题，需要防止资金的双花。现有方案主要思路是在通道中选举领导者，领导者负责收集处理交易，并设计机制对账本更新达成共识，使得恶意情况能够被即时检测，保证资金的安全性。但是现有技术在进行机制设计时各有侧重，总体来说，在通道内部的共识效率和通道稳定性方面仍然有较大提升空间。
从共识效率来说，现有机制可分为链上共识和链下共识。
链上共识需要领导者将周期内处理的交易信息定期上链，以上链周知的方式实现共识。但周期性将结果上链这种共识方法的交易延迟大，且需要花费昂贵的交易费，因此较多方案选择链下共识的方式。
链下共识指在通道内部使用某种共识算法，对结果达成一致。一种方案是使用两阶段共识，即领导者广播结果后，所有节点需要检查结果，如果合法，需要在规定时间内向领导者返回对结果的签名，领导者节点收集到所有节点的签名后认为达成一致。这种方式随着链下通道内用户节点数的增加，通道内通信开销、交易时延也会增加，从而导致共识效率降低。另一种方案不要求链下通道内用户节点对合法结果做响应，只需要在发现了恶意情况时上链处理即可。节点间没有专门的握手共识过程，领导者只是单纯的广播结果，加快了共识的过程。但在领导者作恶，或者网络状况不好的情况下，作恶被延迟发现，而且对于节点的动态加入退出，通道要更新暂停，去链上结算之后才能继续用这个通道，相应的开销也比较大，效率会降低。
从通道稳定性方面来说，现有机制在对领导者的选择上，主要分为固定的领导者和每轮都随机更换领导者。固定领导者的方案，通道从建立到关闭，持续由固定的领导者来管理通道内的交易，使得它在***中的权力过大，一旦领导者宕机，通道便无法继续使用。而每轮都更换领导者的方式，由于现有随机方案缺乏对于节点计算能力、在线服务能力等方面评价，在当选领导者算力较低、不在线等情况下，链下通道服务也无法使用，进而破坏通道稳定性，严重影响用户体验，危害***安全。
发明内容
发明人通过对现有多人通道技术的研究发现，解决以上问题需要重新设计多人链下通道方案，涵盖通道全生命周期：通道建立，链下交易，链下共识、通道关闭、争议处理、节点动态加入退出等过程，主要在链下共识部分做改进，以提升***的通量和稳定性。
针对现有技术的不足，本发明的目的在于优化区块链多人链下通道的处理流程，实现多人链下通道***的通量与稳定性提升，具体来说本发明提出一种基于多人链下通道的区块链交易方法，其中包括：
步骤1、用户节点向区块链发起一笔打开链下通道的交易请求，该区块链根据该交易请求开启链下通道，该用户节点作为领导者加入该链下通道，负责维护链下账本状态，且多个用户节点通过该链下通道的通道标识符加入该链下通道，初始化轮数为0；
步骤2、判断当前轮数是否小于预设值，若是，则执行步骤3，否则执行步骤4；
步骤3、在预设时间内，该链下通道内用户节点间发起链下交易，领导者根据该链下交易的发送方签名和接收方签名，对该链下交易进行确认签名，并将该链下交易记入链下账本，将该确认签名返回该发送方和该接收方，达到该预设时间后，领导者向该链下通道内所有用户节点广播链下账本状态更新，轮数加1，再次执行该步骤2；
步骤4、领导者将包含链下账本状态的检查点共识消息发送给通道内所有用户节点，通道内用户节点通过确认该检查点共识消息，实现通道内所有用户节点对该链下账本的状态达成一致性视图，轮数置零，再次执行该步骤2。
所述的基于多人链下通道的区块链交易方法，其中
该步骤1中该用户节点作为领导者加入该链下通道，具体包括：
用户节点在该区块链上的账户资金减value_A，用户节点在该链下通道中的账户资金加value_A，合约为该交易请求返回唯一的通道标识符；
该步骤1中多个用户节点通过该链下通道的通道标识符加入该链下通道，具体包括：
待加入的用户节点发起一笔加入该链下通道的交易，包括要加入的通道标识符，并锁定待加入的用户节点的资金，并对链下账本状态进行更新，由默克尔化的线段树来表示账户的余额以及账户对应的交易信息，账户的余额通过线段的划分存储在账户树中；每个账户对应的交易信息存储在交易树中，其中支出交易由默克尔树来表示，收入交易由默克尔化的线段树表示，该链下通道中用户节点与待加入的用户节点同步链下账本状态。
所述的基于多人链下通道的区块链交易方法，其中该步骤2包括：
领导者检查该链下交易发送方的交易序号是否是连续递增，余额是否充足；检查通过后对交易签名，发送签名至发送方和接收方，并更新链下账本状态：在接收方账户的入交易树中新增一个叶子节点，以记录该链下交易的信息，重新构建交易的默克尔树；发送方账户的出交易树中新增叶子节点，重新构造默克尔化的交易线段树。
所述的基于多人链下通道的区块链交易方法，其中该步骤3包括：
若链下通道内用户节点在规定时间内没有收到账本状态更新，则向领导者发送请求，并再次等待；若等待后发送方依旧没有收到接收方的回复，则向区块链提交请求，要求领导者向链上提交当前轮的账本状态更新；
若领导者没有在规定时间内向链上提交当前轮的账本状态更新，发起请求的用户节点在链上提交最近的检查点共识消息，并请求惩罚领导者，实现对领导者节点的资金罚没，链上重新划分资金分配。
所述的基于多人链下通道的区块链交易方法，其中该步骤4包括：
领导者向该链下通道内所有用户节点广播检查点共识消息，包括领导者签名的账本状态更新，加入和退出节点的请求，和竞选领导者的请求；
所有用户节点对该共识消息进行验证通过后，所有用户节点向领导者发送签名，并在本地记录最新的共识消息；
当领导者接收到当前通道内所有用户节点的签名，构造所有用户节点签名的聚合签名消息，发送给通道内所有用户节点，则共识完成，所有用户节点都对最新的链下账本状态达成了一致性视图。
所述的基于多人链下通道的区块链交易方法，其中该步骤3还包括：
该链下通道内所有用户节点在本地计算候选节点的重要性评分，以该重要性评分作为权重，采用加密抽签的方式对领导者进行更新。
所述的基于多人链下通道的区块链交易方法，其中还包括：
区块链中监察服务节点调用监察服务智能合约，锁定一笔资金作为保证金，对外提供服务；
该链下通道内用户节点作为委托节点与监察服务节点使用哈希时间锁机制建立委托关系，并该委托节点在执行步骤4之前离线；
当该链下通道内发生争议，通过发起状态更新挑战向链上提交链下账本状态，该监察服务节点判断提交至链上的链下账本状态中对委托节点的余额划分是否正确，若正确则保存最新的链下账本状态，否则向链上提交错误挑战，维护委托节点的利益后保存最新的链下账本状态；
委托节点上线，同步最新的链下账本状态，判断委托节点的资金分配在链上是否发生变化，若是，则构造追责事务，以建立委托关系时的链下账本状态和当前链下账本状态作为凭证，调用监察服务智能合约的争议处理函数，对监察服务节点进行保证金扣除，否则执行步骤2，继续进行链下交易。
本发明还提出了一种基于多人链下通道的区块链交易***，其中包括：
模块1，用于使用户节点向区块链发起一笔打开链下通道的交易请求，该区块链根据该交易请求开启链下通道，该用户节点作为领导者加入该链下通道，负责维护链下账本状态，且多个用户节点通过该链下通道的通道标识符加入该链下通道，初始化轮数为0；
模块2，用于判断当前轮数是否小于预设值，若是，则调用模块3，否则调用模块4；
模块3，用于在预设时间内，使该链下通道内用户节点间发起链下交易，领导者根据该链下交易的发送方签名和接收方签名，对该链下交易进行确认签名，并将该链下交易记入链下账本，将该确认签名返回该发送方和该接收方，达到该预设时间后，领导者向该链下通道内所有用户节点广播链下账本状态更新，轮数加1，再次执行该模块2；
模块4，用于使领导者将包含链下账本状态的检查点共识消息发送给通道内所有用户节点，通道内用户节点通过确认该检查点共识消息，实现通道内所有用户节点对该链下账本的状态达成一致性视图，轮数置零，再次调用该模块2；
其中该模块1中该用户节点作为领导者加入该链下通道，具体包括：
用户节点在该区块链上的账户资金减value_A，用户节点在该链下通道中的账户资金加value_A，合约为该交易请求返回唯一的通道标识符；
该模块1中多个用户节点通过该链下通道的通道标识符加入该链下通道，具体包括：
待加入的用户节点发起一笔加入该链下通道的交易，包括要加入的通道标识符，并锁定待加入的用户节点的资金，并对链下账本状态进行更新，由默克尔化的线段树来表示账户的余额以及账户对应的交易信息，账户的余额通过线段的划分存储在账户树中；每个账户对应的交易信息存储在交易树中，其中支出交易由默克尔树来表示，收入交易由默克尔化的线段树表示，该链下通道中用户节点与待加入的用户节点同步链下账本状态。
所述的基于多人链下通道的区块链交易***，其中该模块2包括：
领导者检查该链下交易发送方的交易序号是否是连续递增，余额是否充足；检查通过后对交易签名，发送签名至发送方和接收方，并更新链下账本状态：在接收方账户的入交易树中新增一个叶子节点，以记录该链下交易的信息，重新构建交易的默克尔树；发送方账户的出交易树中新增叶子节点，重新构造默克尔化的交易线段树；
该模块3包括：
若链下通道内用户节点在规定时间内没有收到账本状态更新，则向领导者发送请求，并再次等待；若等待后发送方依旧没有收到接收方的回复，则向区块链提交请求，要求领导者向链上提交当前轮的账本状态更新；
若领导者没有在规定时间内向链上提交当前轮的账本状态更新，发起请求的用户节点在链上提交最近的检查点共识消息，并请求惩罚领导者，实现对领导者节点的资金罚没，链上重新划分资金分配；
该模块4包括：
领导者向该链下通道内所有用户节点广播检查点共识消息，包括领导者签名的账本状态更新，加入和退出节点的请求，和竞选领导者的请求；
所有用户节点对该共识消息进行验证通过后，所有用户节点向领导者发送签名，并在本地记录最新的共识消息；
当领导者接收到当前通道内所有用户节点的签名，构造所有用户节点签名的聚合签名消息，发送给通道内所有用户节点，则共识完成，所有用户节点都对最新的链下账本状态达成了一致性视图。
所述的基于多人链下通道的区块链交易***，其中该模块3还包括：
该链下通道内所有用户节点在本地计算候选节点的重要性评分，以该重要性评分作为权重，采用加密抽签的方式对领导者进行更新；
所述的基于多人链下通道的区块链交易***，还包括：
区块链中监察服务节点调用监察服务智能合约，锁定一笔资金作为保证金，对外提供服务；
该链下通道内用户节点作为委托节点与监察服务节点使用哈希时间锁机制建立委托关系，并该委托节点在调用模块4之前离线；
当该链下通道内发生争议，通过发起状态更新挑战向链上提交链下账本状态，该监察服务节点判断提交至链上的链下账本状态中对委托节点的余额划分是否正确，若正确则保存最新的链下账本状态，否则向链上提交错误挑战，维护委托节点的利益后保存最新的链下账本状态；
委托节点上线，同步最新的链下账本状态，判断委托节点的资金分配在链上是否发生变化，若是，则构造追责事务，以建立委托关系时的链下账本状态和当前链下账本状态作为凭证，调用监察服务智能合约的争议处理函数，对监察服务节点进行保证金扣除，否则调用模块2，继续进行链下交易。
由以上方案可知，本发明的优点在于：
当前主流的区块链技术，在实际业务场景下普遍面临通量较低、扩展性较差等问题。链下通道作为一种可行性较高的扩容方案，对通量的提升非常有益。目前的方案在通道内部共识效率和通道稳定性方面缺乏深入的考虑。实际上，多人通道的核心问题是多人之间如何进行交易，多人如何对通道内部一段时间的交易达成共识，因此可以将高效的共识算法在多人通道内适配，设计合理的机制保证安全性和可用性。本发明核心包括提出对链下通道内用户节点进行评估，以选出较优的领导者节点，为通道的长久稳定运行提供支撑。
附图说明
图1为多人链下通道***处理架构图；
图2为监察服务流程图；
图3a为交易流程示意图；
图3b为***运行阶段示意图；
图4为链下通道内的状态转换图；
图5为链下通道内的检查点共识图；
图6为默克尔化的线段树示意图；
图7为本发明双人支付通道处理流程图；
图8为本发明多人支付通道处理流程图；
图9为监察服务机制流程图。
具体实施方式
为让本发明的上述特征和效果能阐述的更明确易懂，下文特举实施例，并配合说明书附图作详细说明如下。
本发明的目的在于优化区块链多人链下通道的处理流程，实现多人链下通道***的通量与稳定性提升。具体而言：
通道建立过程允许多个节点加入同一个通道，而不是局限于两方间交易，从而实现链上锁定的一份资金在链下多方间使用。链下交易需要三方参与，即发送方，接收方，以及领导者，三方签名后即认为交易确认，任意一方作恶都可以提交作恶证据在链上进行争议处理。节点退出，争议处理在链上执行，为链下通道提供安全保障。
链下共识强调强一致性，整个***状态更新以轮为最小单位，每一轮为节点间一次完整的交易过程，在多轮之间***检查点，检查点与前一个检查点之间的多轮组成整个***的同步周期。每轮结束时需要完成轮共识，每个周期结束时完成检查点共识。轮共识阶段由领导者发送结果，其他节点自愿验证，辅以监察服务，为下线节点提供服务；检查点共识进行所有节点在线的两阶段共识，支持通道节点的动态加入与退出。这样既能加速共识的过程，提升***通量，降低作恶被延迟发现、过多交易被撤销的风险，也能保证节点的灵活性和***的安全性。
***运行过程中，引入领导者节点的按需更换机制，所述按需包括领导者在检查点的正常退出和提前退出。提前退出分为主动退出和被动退出，通过对领导者的多种退出行为提供处理方法，保证链下通道内资金的安全性；设计节点评估机制，随机选择对***重要性更大的领导者节点，提升***稳定性。
本发明所提出的多人链下通道***的架构如图1所示。本发明提出的多人链下通道处理架构由客户端模块，链上区块链层和链下多人通道层三部分组成。
其中，客户端管理账户信息，实现链上链下资产的管理。包括将区块链上的账户资产转移到链下通道的账户中，将链下通道中的账户资产转移到区块链的账户中，在链下通道的账户中相互转账。客户端需要完成用户与链上链下交互的功能，通过通道管理模块实现与链上的交互；链下交互主要完成交易的发送和接收，由事务处理模块负责。用户参与链下活动的时候，需要为自己在通道内的状态负责，因此承担着维护通道状态的作用，根据参与程度的不同，由角色管理模块完成转换角色的功能。
链上区块链层对链下用户资金的安全性起着保护作用，能够接受用户发起的请求，并且可以监听链下的消息，实现链上链下的协同。包括：多人支付通道服务模块，为多人通道的正常运行提供基础支撑能力，实现通道的打开、关闭、争议处理、节点加入退出等功能；通道监察服务，为链下的离线节点监听链上的争议处理消息，及时上传状态，为链下提供增值服务，给予用户足够灵活度，并提供安全性。
链下多人通道层主要卸载链上的负载压力，完成链下账户间快速、低成本的状态转换。交易模块负责多人通道内双方之间的事务状态转换，由选定的领导者检查事务的合法性，对事务确认，防止双花。一般认为由发送方，接收方以及领导者认可签名的事务，则被确认完成，大大降低链上等待时延。通道内部的节点之间可以相互转账，每个节点要明确地知道其他节点当前的账本状态，通过共识机制使得通道内部节点间达成一致性视图。共识过程又分为轮和检查点两种。事务处理过程以及共识过程都需要领导者的参与，加速处理过程，但是需要对领导者进行按需的更换，包括领导者在检查点的正常退出，在某一轮的主动退出，某一轮的被动退出；产生新领导者时，对节点进行综合评估，选出较优的节点。
需要特别说明的是，本发明的处理流程适用于任何状态类的多人通道，包括但不限于多人支付通道，多人应用通道等。为简化说明，本发明以多人支付通道为例进行描述。
三个部分的具体模块设计如下：
客户端：
客户端主要包括账户管理、通道管理、事务处理、角色管理四个模块。
账户管理模块负责生成并在本地保存账户私钥。与此同时，使用椭圆曲线数字签名算法(ECDSA)与Keccak-256算法得到私钥对应的账户地址。每个用户可以拥有不同的账户。与通道管理模块完成区块链上的账户资产转移到链下通道的账户中，将链下通道中的账户资产转移到区块链的账户中；与交易模块完成链下通道中账户间的转账。
通道管理模块主要完成和区块链交互的功能，包括打开或者加入某个通道，对通道内的争议进行处理，通道关闭时或者退出通道时参与资金划分的过程。
节点通过通道管理模块创建或者加入通道后，利用事务处理模块便可以参与链下的事务。参与方调用事务发送模块，指定要交易的通道和另一个对等方，在链下多人通道中完成交易双方通道内账户间的转账操作。
角色管理模块负责对当前节点参与通道的能力进行管理。如果只是单纯的参与交易，则只需要对通道本身进行维护，包括对每笔参与的交易进行检查认证，每轮共识时需要同步最新的链下账本状态，对作恶情况及时反馈至链上。如果想要成为领导者，则需要承担更多的责任，包括收集通道内的所有交易，作为中间节点为每笔交易检查和认证，签名背书。因此作为领导者会对节点的机器性能，在线时长，网络状况等有要求，同时作为激励机制，领导者可以对每笔交易收取少量的交易费。
链上区块链层：
链上主要的实现形式是智能合约，包括对多人通道服务的模块，对链下通道内用户节点提供离线服务的通道监察服务模块。
多人通道服务模块。此模块接受客户端中通道管理模块的调用，为链下多人通道服务。主要包括以下功能：
1.打开通道：客户端节点调用打开通道功能，则建立一个新的通道，将区块链账户的资金转移到通道账户内，合约为通道分配全网唯一的标识符，并设置争议处理的时间窗口等通道相关的参数。
需要注意的是：打开通道时的节点可以是一个账户，也可以是多个账户，即多个账户私下构造一个聚合签名，调用通道建立函数，打开通道的同时意味着多个节点都加入了通道。
2.加入通道：与通道内的节点有频繁交易需求的节点可以调用加入通道的功能，输入包括通道的标识符，想要在通道内锁定的资金。并向领导者节点发送请求。
a)第一次检查点共识(见下文链下通道层-共识模块)开始之前，为通道冷启动阶段，由通道建立方作为领导者节点，消息发送给链上注册时的通道建立方。
b)若已经产生了新的领导者，领导者节点的信息会存储在任何一个链下通道内用户节点，可以向链下通道内用户节点询问当前领导者节点，然后发送加入请求。
3.争议处理：当通道内的节点数大于等于2时便可以开始交易过程，一旦有节点在通道运行期间有作恶的行为被诚实节点发现，诚实节点调用争议处理功能，输入最新且被通道内所有节点认可的账本状态，恶意节点作恶的证据等信息，合约内进入争议处理挑战期，链下节点可提交不同于链上的最新账本状态，争取合法的权益。当挑战期结束，由合约特定规则在链上完成账本状态更新。
4.退出通道：节点决定离开通道时，需要完成资金从通道账户转移到区块链账户内。调用退出通道功能，输入可退出的证明，余额划分等信息，合约验证后记录最新的链下账本状态，将节点从通道内移除并完成转账。
5.关闭通道：关闭通道相当于所有节点退出通道。
通道监察服务模块。此模块是一种可追责的第三方服务，为多人通道的在线或者下线节点提供资金安全保障，监听此通道在链上进行争议处理的消息。通道节点调用监察服务模块，指定特定的监察服务节点，开启委托过程，具体的服务流程如图2所示。具体来说：
1.服务节点注册：服务节点需要先在监察合约内锁定一笔保证金，表示注册成为服务节点，注册好之后在***中有唯一的服务标识符。服务节点锁定的资金越多，证明承担风险的能力越强，越有可能被通道内的节点选中。
2.通道节点与监察服务节点建立委托关系：双方要对委托达成可验证、可追责的共识。此过程采用哈希时间锁机制。具体来说：
a)通道节点向监察合约提供委托信息，包括节点状态相关信息：即当前最新的链下账本状态，包括时间戳，入交易和出交易的默克尔根，节点账户余额等的签名；服务节点相关信息：即服务者的标识符等；服务相关的内容：服务时长，服务费等；以及一个秘密值原值经过哈希运算后的散列值，并在监察合约内锁定服务费。
b)通道节点向服务节点发送秘密值原值，并启动计时器。
c)服务方检查委托内容是否正确，是否同意服务设定的参数：
1)如果同意委托要求，且在回复有效期内，则向监察合约发送秘密值原值，合约向服务方支付服务费，服务开启。
2)如果不同意，则不响应，等回复时间过期，通道节点可以向监察合约发起请求，赎回锁定的服务费，委托关闭。
3.通道内其他诚实节点会对每一轮的链下账本状态进行共识，一旦发现恶意事件，则发起链上的争议处理过程。为了防止恶意节点向链上提交了不正确的状态更新，并在链上被确定，造成诚实节点的资金损失，需要通道节点监听链上消息。监察服务主要提供监听链上消息并作出反馈的服务：
a)通道节点在线场景下使用监察服务，是为了提供资金安全的双层保障，避免自己临时宕机或者其他意外，导致没有观测到链上的争议处理消息。
b)通道节点下线后，需要委托的监察服务方全权按照委托合同提供服务，一旦发现对委托方不利的情况发生，要向通道的链上争议处理过程提交代表委托方利益的证明。
c)需要注意的是，如果通道节点委托后，没有马上下线，还参与了共识过程，导致最新状态有变化，那么在下线时还需要向服务节点提供最新状态。
4.通道节点上线后，会对监察服务方的服务情况进行检查，如果对服务有异议，可调用监察服务合约中的争议处理，对服务方进行惩罚。
链下多人通道层：
链下多人通道层以区块链作为背书，实现安全、快速、低成本的交易。主要包括交易模块以及共识模块。为了保证通道安全可控，提供辅助的领导者按需更换模块。为了增强通道的稳定性和维护通道内部良好的生态，提供节点评估模块，对节点的重要性进行计算，选出较优领导者。
交易模块
交易主要由发送方，接收方和第三方领导者参与，具体处理流程如图3a所示：
1.用户在客户端发起一笔链下事务，并对链下事务签名，将链下事务发送至接收方。其中事务包括转账交易、合约调用等。
2.接收方收到事务后，检查事务的状态变化是否有效，发送签名后的链下交易给发送方。
3.发送方将两方签名的交易发送至领导者，由领导者检查合法性，确认并签名，将签名结果发送给发送方和接收方。
值得注意的是，步骤3也可以由接收方向领导者发送，此例只作为说明。链下交易过程的结果是三方对一笔交易进行确认并签名。
共识模块
链下通道内的处理是以周期来计算的。根据共识模式的不同，划分为轮(slot)和检查点(checkpoint)。多轮构成一个检查点，两个检查点间为一个周期。检查点时需要所有的节点在线，对周期间发生的链下账本状态进行同步，并对最新的链下账本状态签名认证。监察方为每一轮的下线节点提供监察服务。***运行阶段划分示意图如图3b所示。
以检查点共识后的结果为初始状态，进入每轮的交易阶段。一轮结束进入轮共识阶段，目的是让链下通道内用户节点及时发现领导者节点的作恶情况。多个轮后进入检查点共识，往复循环。通道内账本状态更新如图4所示。
轮共识指领导者定期向通道内所有节点广播包括此轮所有交易的链下账本状态。目的是让诚实节点及时验证领导者在短时间内的行为，可以尽早发现恶意情况，避免回滚太多交易。
如果领导者是善意的，且按照规定按时的广播链下账本状态，那么在网络状况良好的情况下，通道内的在线节点都可以接收到账本更新，进行验证。
如果领导者是恶意的，或者网络状况不佳时，在线节点没有在预定的时间内收到领导者广播的消息，则向领导者发送消息进行请求。一旦领导者没有在规定的时间响应，那么链下通道内用户节点向链上提起申请，要求领导者广播此轮的状态更新。一旦领导者没有在规定的时间内反馈，则可断定领导者作恶，向链上提起争议处理，同时进入领导者被动退出的过程。
检查点共识是经历多轮(也可以是一轮)后的某一轮做共识，需要所有节点在线。目的是让通道内所有节点对通道内的链下账本状态达成一致性视图，处理节点的加入退出请求，并完成领导者的更换。流程示意图如图5所示：
1.领导者发起检查点的共识过程，将检查点共识消息发送给通道内所有节点，检查点共识消息包括当前链下账本状态、加入退出请求、候选领导者请求和关闭通道请求。
2.链下通道内用户节点收到账本更新后进行检查：
a)没有异议，发送签名至领导者。
b)有异议，向链上提交状态更新，进行争议处理。中断通道内的共识，转而在链上实现当前轮账本更新的确定。
3.领导者等待链下通道内用户节点对链下账本状态的检查结果：
a)如果领导者在正常等待窗口内收到了通道内所有节点的签名，则认为所有节点对结果达成一致，广播所有节点的聚合签名，更换领导者，进入下一轮。
b)领导者在正常等待窗口内没有收到通道内所有节点的签名，则直接在链上发起请求，要求无应答节点应答签名。对于不按时提交签名的节点予以惩罚。转而在链上实现当前轮账本更新的确定。
按需更换领导者：
按需包括领导者在检查点的正常退出，以及提前退出，提前又包括主动退出和被动退出。正常退出是无损的，而提前退出对通道的稳定性造成了影响，因此需要在链上做仲裁并对领导者罚没一定的资金。具体来说：
1.提前主动退出时，领导者调用通道合约的领导者退出功能，向链上提交当前的最新链下状态更新。如果链上是按照领导者提交的状态完成仲裁，那么对领导者执行轻度罚没，如将通道内的资金进行一定比例的罚没，并禁止其一段时间内参与交易或者竞选领导者。
2.被动退出源于领导者节点的服务质量不好，或出现作恶情况，这时由链下的诚实节点发现作恶情况，向链上通道合约的争议处理程序提交领导者节点服务质量不好的证据，合约进行仲裁，对领导者进行重度罚没，如扣除所有通道内的资金，并驱逐出通道。
领导者退出时，需要产生新领导者。新的领导者节点选举采用加密抽签的方式，但是以节点的重要性评分作为计算权重。
想要成为第r轮领导者的节点本地使用如下加密抽签算法：
Procedure Sortition(ski,seedr,τ,r,w,W):
<hash，proof>←VRFsk(seedr||r)
j++return<hash，proof，j>
其中，ski是候选节点的私钥，seedr是第r轮的随机数，r是当前的轮数，τ是预期进入最终选择的候选者阈值数，w是当前节点的重要性分数importance，W是重要性分数总和。使用VRF可以计算出散列值和代表当前节点的证明。p代表节点的每份重要性使其被当选的概率。以作为选择阈值，选择能够满足条件的节点。
重要性评分方式如下，其中函数f1，f2，f3，f4表示统一单位的函数，delta，alpha，beta，gamma表示每一项对重要性分数的影响。balancek表示候选者节点k在第r-1个检查点时的余额；txOutNumk是节点在[r-x,r-1]的输出交易总数，txInNumk是节点在[r-x,r-1]的输入交易总数，txSign是节点在[r-x,r-1]中，除了自身交易外，其他签名交易总数，即节点当选过领导者，并且为其他人提供过认证服务。
重要性评分综合考虑节点的通道内余额，以及节点在一段时间内的行为活动，表征其是否积极参与通道内交易。比如A，B，C都想成为下一轮的领导者，如果C加入时锁定的资金非常多，但因为它在一段时间内没有交易行为，那么在计算重要性分数时，对于A和B，在余额较少情况下，都存在交易活动，依旧有很大的概率成为下一轮的领导者。
具体来说，处理流程如下：
有意愿做领导者的节点，在下一次检查点共识之前，使用加密抽签算法计算出<hash,proof,j>，并向通道内所有节点发送请求。
通道内其他节点收到请求后，使用领导者候选节点的公钥，散列值，proof等参数，进行验证。验证通过后计算j，并且与候选者节点发送的j做比较。如果相同则记录在本地。
检查点共识时，当前轮的领导者节点广播的共识消息中，包括本周期内所有的领导者候选者的请求。
通道内所有节点对比共识消息中的候选者请求和本地收到的请求，验证通过，则认为hash值最大的节点当选为新周期的领导者。
如果新的领导者发生宕机或者作恶的情况下，根据hash值的排序，依次顺延领导者，开启新的周期。
本部分以多人支付通道为例，结合附图和实施例对本发明作进一步的详细说明。
首先是双人支付通道的使用场景。图7为A和B建立多人通道并进行交易的流程图。
步骤S1，A所在客户端的通道管理模块调用A所在客户端的账户管理模块，向链上合约发起一笔打开通道的交易，记作<A,value_A,setup(settleTime,epochTime,delta,consTime,respTime,)>。表示用户A调用通道合约的setup函数，锁定value_A的资金，并设置通道的常量参数，包括设定此通道的遇到争议处理时，挑战窗口是settleTime，通道内每一轮的时间是epochTime，一个周期的时间是delta轮。每一轮包括交易和共识的时间。检查点共识时收集签名的时间是consTime，链下通道内用户节点间相互请求后的响应时间是respTime。
步骤S1.1，A所在客户端的账户管理模块将用户在区块链上的账户资金减value_A，在通道中的账户资金加value_A。
步骤S1.2，合约为此笔建立通道交易返回唯一的通道标识符channelId。
步骤S2，节点B使用客户端的通道管理模块和账户管理模块，向链上合约发起一笔加入通道的交易，记作<B,value_B,lockup(channelId)>，表示用户B要加入通道channelId，并锁定value_B的资金。
步骤S2.1，节点B向节点A发送加入通道的请求，记作joinRequest(C/D,channelId,value,)，表示请求加入channelId的通道，而且已经锁定了value的资金。同时，节点A通过监听区块链得到节点B在合约通道内锁定资金，即加入通道的信息，对链下账本状态进行更新，记作<0,MerkleizedIntervalTree>，表示当前为第0轮，由默克尔化的线段树(数据结构的示例见图6)来表示账户的余额以及账户对应的交易信息。账户的余额通过线段的划分存储在账户树中；每个账户对应的交易信息存储在交易树中，其中支出交易(outgoingtransfer)由默克尔树来表示，收入交易(incoming transfer)由线段表示。A与B同步链下账本状态。
步骤S3，通道内的节点数大于等于2，可以开始通道内的链下交易过程。默认通道冷启动阶段的领导者为通道建立方，即A所在客户端的角色管理模块的角色自动设置为领导者，负责维护链下账本状态。
步骤S3.1，发送方B向接收方A转账，B所在客户端的交易管理模块构造交易，记作<e,B,A,nonce,amount,recipientLeafIndex>，表示这笔交易在第e轮发生，发送方B向接收方A(在账户树上的叶子索引是recipientLeafIndex)发送amount，发送方在当前周期内发送的交易数记作nonce(相当于链下交易的版本号)，签名后发送至A。
步骤S3.2，接收方A所在客户端的交易处理模块收到交易后，检查发送方B的签名，转账数额是否正确，合法的情况下将签名发送至B。
步骤S3.3，发送方B将含有两方签名的交易发送至领导者A。
步骤S3.4，领导者A检查这笔交易发送方的nonce是否是连续递增，余额是否充足，即在账户树上的offset+amount<balance_B；验证通过后对交易签名，发送签名至B，并更新链下账本状态：在账户A的入交易树中新增一个叶子节点，记录交易相关信息，重新构建默克尔树；账户B的出交易树中新增叶子节点，合理划分线段，重新构造默克尔化的交易线段树。其中合理划分线段可按照余额的多少划分，比如账户一余额3块，账户二余额5块，那线段的划分是0，3，8。
步骤S3.5，B所在客户端收到了A认证签名的交易，和A一样在本地更新链下账本状态。A与B在第i轮内可以进行任意多笔交易。
步骤S4，当到达当前轮的共识时间，节点A向链下通道内用户节点(此时只有节点B)广播此轮的账本状态更新，表示<MerkleizedIntervalTree,e>，即第e轮的默克尔化的线段树。
步骤S4.1，如果B在respTime内没有收到账本状态更新，则向A发送请求，并再次等待alpha*respTime。
步骤S4.1.1，如果B依旧没有收到A的回复，则向链上发送状态更新的挑战<stateUpdateChallenge(e,leader,)>，表示向领导者节点leader请求第e轮的账本状态更新。
步骤S4.2，如果B按时收到了链下账本状态，进行验证。
步骤S4.2.1，如果B发现A记录的链下账本状态有误，比如账户树中的线段划分有误，交易树中的交易数量有误等，则向链上发送状态更新错误的挑战<stateUpdateFaultChallenge(e,leader,faultMerkleizedIntervalTree>，表示领导者节点leader在第e轮构造了错误的链下账本状态faultMerkleizedIntervalTree。一般情况下，认为领导者没有动机作恶，因为其作恶行为会被直接发现。并且在链上损失资金。
步骤S4.2.2，如果发现链下账本状态有效，则继续交易。A继续担任领导者，通道进入下一轮。流程进入步骤3。
以上过程描述了两人通道内进行交易和轮共识的过程，接下来将例子拓展，对节点加入退出，选举新的领导者节点，以及检查点共识做阐述。流程图见图8。
步骤S1，A与B之间按轮执行交易并共识。
步骤S2-1，节点C，D，E向通道内锁定资金，并且向节点A发送签名的加入通道请求。
步骤S2-1.1，A收到加入通道请求，对C，D和E的签名进行验证，并查询链上资金的锁定情况，均合法的情况下将请求存入本地的请求列表Enter(e)。值得注意的是，如果通道内加入了多个节点，都还没有交易的过程，那么其他节点是可以马上加入的，进入步骤S2。
步骤S3，经过delta*epochTime时间，到达当前周期的共识时间，开启两阶段共识过程。
步骤S3.1，节点A向通道内所有节点(此时只有节点B)广播此轮的共识消息，<e,MerkleizedIntervalTree,Enter(e),Withdraw(e),Candidate(e+1)>。表示第e轮，处理节点加入和退出后，A签名的账本状态更新，以及加入和退出节点的请求，想要竞选下轮领导者的请求。
步骤S3.2，其他节点对共识消息进行验证和同步。
步骤S3.2.1，如果A没有按时广播消息或者B发现仍有未处理的挑战，B向链上发起状态更新的挑战stateUpdateChallenge(e,leader)>。如果B发现共识消息中存在无效项，B向链上发送状态更新错误的挑战<stateUpdateFaultChallenge(e,leader,faultMerkleizedIntervalTree)>。
步骤S3.2.2，如果B收到请求，且链上无此领导者需要应答的挑战，对共识信息检查后，认定共识消息有效，即链下账本状态中的每个账户的余额都划分正确，每个账户执行的交易都被正确的记录在交易树中，加入节点的签名以及链上资金锁定妥当，退出节点的资金分配合理，没有双花问题。B向节点A发送签名，并在本地记录最新的共识消息。
步骤S3.3，A收集当前通道内所有节点的签名。
步骤S3.3.1，如果A在consTime后还有未收到的签名(此时只有B)，则向链上发起状态更新签名的请求，<stateUpdateSignRequest(e,leader)>。
步骤S3.3.2，如果A在consTime内收到了所有节点的签名，则共识完成，认为所有的链下通道内用户节点都对最新的链下账本状态达成了一致性视图。
步骤S3.4，A向通道内所有节点广播有效节点的聚合签名。
步骤S3.4.1，如果链下通道内用户节点收到了聚合签名，进行验证。验证通过则向其他节点广播此聚合签名，并直接进入下一轮的交易。
步骤S3.4.2，如果链下通道内用户节点在consTime后未收到签名，或者对签名验证不通过(如签名数不够，签名本身有问题等)，B向链上发起状态更新的挑战<stateUpdateChallenge(e,leader)>。
步骤S4，通道内所有节点在本地计算新一轮的领导者。本地计算候选节点的重要性评分，节点使用VRF得出下一轮的领导者。
步骤S5，检查点共识在链下成功完成，以新的领导者开启新的周期。申请加入通道的节点可以参与下一轮的交易活动，申请退出通道的节点，可以向链上提交共识信息，完成资金的提取，此时链上记录最新的资金分配。
此时通道内的节点为A，C，D，E，下面的流程主要说明监察服务处理流程，见图9。
步骤S1-1，当选的领导者(假定依旧是A)负责新周期内的交易。
步骤S1-2，监察服务节点F调用监察服务智能合约，构造注册事务，表示为<F,value,Setup()>，表示锁定一笔资金value，作为保证金，对外提供服务。
步骤S2，通道节点C完成多笔交易后，在到达下一检查点前不需要再交易，想要离线前，与监察服务方F建立委托关系。
步骤S2.1，通道节点C调用监察服务智能合约，构造委托预约事务<C,F,value,Deposit(e_start,e_end,channelId,balance_e,in_root,out_root,hash_i,time)>，表示C愿意为服务方F提供的服务支付value，此项服务的生效时间是第e_start轮，结束服务时间是第e_end轮。C当前在账户树上的余额是balance_e，入交易树的根是in_root，出交易树的根是out_root，F需要监管通道channelId内发生的链上争议处理事件，维护C的合法利益。同时选择随机数生成散列，作为F获取C服务费的条件。C需要在time时间内提供收据。
步骤S2.1.1通道节点C向服务节点F发送散列的原值primitive。
步骤S2.1.2，服务节点F检查当前节点C的状态，包括余额，交易信息是否有效，付款金额与服务时间是否合适，调用监察服务智能合约，构造收据事务<F,C,hash(Deposit),primitive>，表示F愿意为C提供服务，服务的具体内容是C的委托预约事务中参数的散列，使用原值作为解锁条件，实现C锁定资金在合约内向F转移。
步骤S3，通道内发生争议，如领导者A没有按时广播链下账本状态。在线节点D向链上发起状态更新挑战stateUpdateChallenge(e,leader)>。监察方监听领导者或者其他方在链上提交的链下账本状态。
步骤S3.1，如果监察服务节点F发现存在节点提交的链下账本状态中对通道节点C的余额划分不正确，那么C的交易树肯定被更改了，检查作恶的交易信息，向链上提交错误挑战stateUpdateFaultChallenge(e,leader,faultMerkleizedIntervalTree>。
步骤S3.2，如果链下账本状态对节点C的资金划分正确，则不做响应，同时保存最新的链下账本状态。
步骤S4，节点C上线，同步最新的链下账本状态，检查监察服务方是否提供服务。
步骤S4.1如果C的资金分配在链上发生变化，说明服务方没有做好保护作用，构造追责事务，以委托时的状态，当前的链下账本状态，收据信息作为凭证，调用监察服务智能合约的争议处理函数，对服务方进行保证金扣除。
下面针对文中的多个挑战的处理流程做具体的说明。挑战发生的情况包括：
1.领导者节点作恶，包括但不限于向不同的节点广播不同的账本，账本中有交易的遗漏等，需要通过链上的方式进行惩罚，以链上的方式来达成全局共识。表示为：
stateUpdateFaultChallenge(e,leader,faultMerkleizedIntervalTree,proof>。
具体处理方式如下：
a)诚实节点将包含作恶信息的链下账本状态faultMerkleizedIntervalTree以及proof，通过调用triggerDispute方法提交至多人通道智能合约，合约内部执行检查，一旦确定作恶，则进入争议处理流程，开启争议处理的窗口。
b)诚实节点们在争议处理窗口内提交第i(i<e)轮的链下账本状态，这个状态需要满足距离当前轮最近，且领导者的余额能够尽可能弥补被回退交易带来的损失。
c)争议处理窗口结束时，合约中的transition函数选择最合适的状态，执行链上的资金分配。将领导者节点从通道参与者集合中移除，其资金的一部分划分至受害节点，一部分作为产生新领导者节点的激励金。
2.领导者节点作恶，不按时广播结果，阻碍其他通道节点在链下同步最新账本状态；或者领导者节点需要提前退出，需要链上的方式来达成全局共识。表示为stateUpdateChallenge(e,leader)>。具体处理方式如下：
a)节点通过调用多人通道智能合约，请求领导者节点提交第e轮的链下账本状态，进入请求处理流程，开启请求处理窗口。
b)如果领导者节点在请求处理窗口内无响应，则可进入stateUpdateFaultChallenge阶段。
c)领导者节点响应后，合约对响应的合法性进行检查，检查通过后，判断是否是领导者节点主动退出，如果是则进行产生新领导者阶段，否则通道继续正常运行。
3.链下通道内用户节点作恶，不按时响应，反馈签名等。表示为<stateUpdateSignRequest(e,leader)>。具体处理方式如下：
a)领导者节点在收集签名时，如果有节点在规定时间内没有响应，则向链上提交当前的最新账本状态以及多人的签名，合约进入签名请求处理流程，开启请求处理窗口。
b)请求处理窗口内收集未签名节点的签名，记录提交的签名。对于过期未提交签名的节点，将节点从通道参与者集合中移除，其资金划分进通道共享资金池，用于通道内激励奖金使用。
以下为与上述装置实施例对应的使用方法实施例，本实施方式可与上述实施方式互相配合实施。上述实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在上述实施方式中。
本发明还提出了一种基于多人链下通道的区块链交易***，其中包括：
模块1，用于使用户节点向区块链发起一笔打开链下通道的交易请求，该区块链根据该交易请求开启链下通道，该用户节点作为领导者加入该链下通道，负责维护链下账本状态，且多个用户节点通过该链下通道的通道标识符加入该链下通道，初始化轮数为0；
模块2，用于判断当前轮数是否小于预设值，若是，则调用模块3，否则调用模块4；
模块3，用于在预设时间内，使该链下通道内用户节点间发起链下交易，领导者根据该链下交易的发送方签名和接收方签名，对该链下交易进行确认签名，并将该链下交易记入链下账本，将该确认签名返回该发送方和该接收方，达到该预设时间后，领导者向该链下通道内所有用户节点广播链下账本状态更新，轮数加1，再次执行该模块2；
模块4，用于使领导者将包含链下账本状态的检查点共识消息发送给通道内所有用户节点，通道内用户节点通过确认该检查点共识消息，实现通道内所有用户节点对该链下账本的状态达成一致性视图，轮数置零，再次调用该模块2；
其中该模块1中该用户节点作为领导者加入该链下通道，具体包括：
用户节点在该区块链上的账户资金减value_A，用户节点在该链下通道中的账户资金加value_A，合约为该交易请求返回唯一的通道标识符；
该模块1中多个用户节点通过该链下通道的通道标识符加入该链下通道，具体包括：
待加入的用户节点发起一笔加入该链下通道的交易，包括要加入的通道标识符，并锁定待加入的用户节点的资金，并对链下账本状态进行更新，由默克尔化的线段树来表示账户的余额以及账户对应的交易信息，账户的余额通过线段的划分存储在账户树中；每个账户对应的交易信息存储在交易树中，其中支出交易由默克尔树来表示，收入交易由默克尔化的线段树表示，该链下通道中用户节点与待加入的用户节点同步链下账本状态。
所述的基于多人链下通道的区块链交易***，其中该模块2包括：
领导者检查该链下交易发送方的交易序号是否是连续递增，余额是否充足；检查通过后对交易签名，发送签名至发送方和接收方，并更新链下账本状态：在接收方账户的入交易树中新增一个叶子节点，以记录该链下交易的信息，重新构建交易的默克尔树；发送方账户的出交易树中新增叶子节点，重新构造默克尔化的交易线段树；
该模块3包括：
若链下通道内用户节点在规定时间内没有收到账本状态更新，则向领导者发送请求，并再次等待；若等待后发送方依旧没有收到接收方的回复，则向区块链提交请求，要求领导者向链上提交当前轮的账本状态更新；
若领导者没有在规定时间内向链上提交当前轮的账本状态更新，发起请求的用户节点在链上提交最近的检查点共识消息，并请求惩罚领导者，实现对领导者节点的资金罚没，链上重新划分资金分配；
该模块4包括：
领导者向该链下通道内所有用户节点广播检查点共识消息，包括领导者签名的账本状态更新，加入和退出节点的请求，和竞选领导者的请求；
所有用户节点对该共识消息进行验证通过后，所有用户节点向领导者发送签名，并在本地记录最新的共识消息；
当领导者接收到当前通道内所有用户节点的签名，构造所有用户节点签名的聚合签名消息，发送给通道内所有用户节点，则共识完成，所有用户节点都对最新的链下账本状态达成了一致性视图。
所述的基于多人链下通道的区块链交易***，其中该模块3还包括：
该链下通道内所有用户节点在本地计算候选节点的重要性评分，以该重要性评分作为权重，采用加密抽签的方式对领导者进行更新；
所述的基于多人链下通道的区块链交易***，还包括：
区块链中监察服务节点调用监察服务智能合约，锁定一笔资金作为保证金，对外提供服务；
该链下通道内用户节点作为委托节点与监察服务节点使用哈希时间锁机制建立委托关系，并该委托节点在调用模块4之前离线；
当该链下通道内发生争议，通过发起状态更新挑战向链上提交链下账本状态，该监察服务节点判断提交至链上的链下账本状态中对委托节点的余额划分是否正确，若正确则保存最新的链下账本状态，否则向链上提交错误挑战，维护委托节点的利益后保存最新的链下账本状态；
委托节点上线，同步最新的链下账本状态，判断委托节点的资金分配在链上是否发生变化，若是，则构造追责事务，以建立委托关系时的链下账本状态和当前链下账本状态作为凭证，调用监察服务智能合约的争议处理函数，对监察服务节点进行保证金扣除，否则调用模块2，继续进行链下交易。

Claims (6)

1.一种基于多人链下通道的区块链交易方法，其特征在于，包括：
步骤1、用户节点向该区块链发起一笔打开链下通道的交易请求，该区块链根据该交易请求开启链下通道，该用户节点作为领导者加入该链下通道，负责维护链下账本状态，且多个用户节点通过该链下通道的通道标识符加入该链下通道，初始化轮数为0；
步骤2、判断当前轮数是否小于预设值，若是，则执行步骤3，否则执行步骤4；
步骤3、在预设时间内，该链下通道内用户节点间发起链下交易，领导者根据该链下交易的发送方签名和接收方签名，对该链下交易进行确认签名，并将该链下交易记入链下账本，将该确认签名返回该发送方和该接收方，达到该预设时间后，领导者向该链下通道内所有用户节点广播链下账本状态更新，轮数加1，再次执行该步骤2；
步骤4、领导者将包含链下账本状态的检查点共识消息发送给通道内所有用户节点，通道内用户节点通过确认该检查点共识消息，实现通道内所有用户节点对该链下账本的状态达成一致性视图，轮数置零，再次执行该步骤2；
其中，该步骤1中该用户节点作为领导者加入该链下通道，具体包括：
用户节点在该区块链上的账户资金减value_A，用户节点在该链下通道中的账户资金加value_A，合约为该交易请求返回唯一的通道标识符；
该步骤1中多个用户节点通过该链下通道的通道标识符加入该链下通道，具体包括：
待加入的用户节点发起一笔加入该链下通道的交易，包括要加入的通道标识符，并锁定待加入的用户节点的资金，并对链下账本状态进行更新，由默克尔化的线段树来表示账户的余额以及账户对应的交易信息，账户的余额通过线段的划分存储在账户树中；每个账户对应的交易信息存储在交易树中，其中支出交易由默克尔树来表示，收入交易由默克尔化的线段树表示，该链下通道中用户节点与待加入的用户节点同步链下账本状态；
该步骤3包括：
若链下通道内用户节点在规定时间内没有收到账本状态更新，则向领导者发送请求，并再次等待；若等待后发送方依旧没有收到接收方的回复，则向区块链提交请求，要求领导者向链上提交当前轮的账本状态更新；
若领导者没有在规定时间内向链上提交当前轮的账本状态更新，发起请求的用户节点在链上提交最近的检查点共识消息，并请求惩罚领导者，实现对领导者节点的资金罚没，链上重新划分资金分配；该链下通道内所有用户节点在本地计算候选节点的重要性评分，以该重要性评分作为权重，采用加密抽签的方式对领导者进行更新；
该步骤4包括：
领导者向该链下通道内所有用户节点广播检查点共识消息，包括领导者签名的账本状态更新，加入和退出节点的请求，和竞选领导者的请求；
所有用户节点对该检查点共识消息共识消息进行验证通过后，所有用户节点向领导者发送签名，并在本地记录最新的检查点共识消息；
当领导者接收到当前通道内所有用户节点的签名，构造所有用户节点签名的聚合签名消息，发送给通道内所有用户节点，则共识完成，所有用户节点都对最新的链下账本状态达成了一致性视图。
2.如权利要求1所述的基于多人链下通道的区块链交易方法，其特征在于，该步骤2包括：
领导者检查该链下交易发送方的交易序号是否是连续递增，余额是否充足；检查通过后对交易签名，发送签名至发送方和接收方，并更新链下账本状态：在接收方账户的入交易树中新增一个叶子节点，以记录该链下交易的信息，重新构建交易的默克尔树；发送方账户的出交易树中新增叶子节点，重新构造默克尔化的交易线段树。
3.如权利要求1所述的基于多人链下通道的区块链交易方法，其特征在于，还包括：
区块链中监察服务节点调用监察服务智能合约，锁定一笔资金作为保证金，对外提供服务；
该链下通道内用户节点作为委托节点与监察服务节点使用哈希时间锁机制建立委托关系，并该委托节点在执行步骤4之前离线；
当该链下通道内发生争议，通过发起状态更新挑战向链上提交链下账本状态，该监察服务节点判断提交至链上的链下账本状态中对委托节点的余额划分是否正确，若正确则保存最新的链下账本状态，否则向链上提交错误挑战，维护委托节点的利益后保存最新的链下账本状态；
委托节点上线，同步最新的链下账本状态，判断委托节点的资金分配在链上是否发生变化，若是，则构造追责事务，以建立委托关系时的链下账本状态和当前链下账本状态作为凭证，调用监察服务智能合约的争议处理函数，对监察服务节点进行保证金扣除，否则执行步骤2，继续进行链下交易。
4.一种基于多人链下通道的区块链交易***，其特征在于，包括：
模块1，用于使用户节点向区块链发起一笔打开链下通道的交易请求，该区块链根据该交易请求开启链下通道，该用户节点作为领导者加入该链下通道，负责维护链下账本状态，且多个用户节点通过该链下通道的通道标识符加入该链下通道，初始化轮数为0；
模块2，用于判断当前轮数是否小于预设值，若是，则调用模块3，否则调用模块4；
模块3，用于在预设时间内，使该链下通道内用户节点间发起链下交易，领导者根据该链下交易的发送方签名和接收方签名，对该链下交易进行确认签名，并将该链下交易记入链下账本，将该确认签名返回该发送方和该接收方，达到该预设时间后，领导者向该链下通道内所有用户节点广播链下账本状态更新，轮数加1，再次执行该模块2；
模块4，用于使领导者将包含链下账本状态的检查点共识消息发送给通道内所有用户节点，通道内用户节点通过确认该检查点共识消息，实现通道内所有用户节点对该链下账本的状态达成一致性视图，轮数置零，再次调用该模块2；
其中该模块1中该用户节点作为领导者加入该链下通道，具体包括：
用户节点在该区块链上的账户资金减value_A，用户节点在该链下通道中的账户资金加value_A，合约为该交易请求返回唯一的通道标识符；
该模块1中多个用户节点通过该链下通道的通道标识符加入该链下通道，具体包括：
待加入的用户节点发起一笔加入该链下通道的交易，包括要加入的通道标识符，并锁定待加入的用户节点的资金，并对链下账本状态进行更新，由默克尔化的线段树来表示账户的余额以及账户对应的交易信息，账户的余额通过线段的划分存储在账户树中；每个账户对应的交易信息存储在交易树中，其中支出交易由默克尔树来表示，收入交易由默克尔化的线段树表示，该链下通道中用户节点与待加入的用户节点同步链下账本状态；
该模块3包括：
若链下通道内用户节点在规定时间内没有收到账本状态更新，则向领导者发送请求，并再次等待；若等待后发送方依旧没有收到接收方的回复，则向区块链提交请求，要求领导者向链上提交当前轮的账本状态更新；
若领导者没有在规定时间内向链上提交当前轮的账本状态更新，发起请求的用户节点在链上提交最近的检查点共识消息，并请求惩罚领导者，实现对领导者节点的资金罚没，链上重新划分资金分配；该链下通道内所有用户节点在本地计算候选节点的重要性评分，以该重要性评分作为权重，采用加密抽签的方式对领导者进行更新；
该模块4包括：
领导者向该链下通道内所有用户节点广播检查点共识消息，包括领导者签名的账本状态更新，加入和退出节点的请求，和竞选领导者的请求；
所有用户节点对该检查点共识消息进行验证通过后，所有用户节点向领导者发送签名，并在本地记录最新的检查点共识消息；
当领导者接收到当前通道内所有用户节点的签名，构造所有用户节点签名的聚合签名消息，发送给通道内所有用户节点，则共识完成，所有用户节点都对最新的链下账本状态达成了一致性视图。
5.如权利要求4所述的基于多人链下通道的区块链交易***，其特征在于，该模块2包括：
领导者检查该链下交易发送方的交易序号是否是连续递增，余额是否充足；检查通过后对交易签名，发送签名至发送方和接收方，并更新链下账本状态：在接收方账户的入交易树中新增一个叶子节点，以记录该链下交易的信息，重新构建交易的默克尔树；发送方账户的出交易树中新增叶子节点，重新构造默克尔化的交易线段树。
6.如权利要求4所述的基于多人链下通道的区块链交易***，其特征在于，所述的基于多人链下通道的区块链交易***，还包括：
区块链中监察服务节点调用监察服务智能合约，锁定一笔资金作为保证金，对外提供服务；
该链下通道内用户节点作为委托节点与监察服务节点使用哈希时间锁机制建立委托关系，并该委托节点在调用模块4之前离线；
当该链下通道内发生争议，通过发起状态更新挑战向链上提交链下账本状态，该监察服务节点判断提交至链上的链下账本状态中对委托节点的余额划分是否正确，若正确则保存最新的链下账本状态，否则向链上提交错误挑战，维护委托节点的利益后保存最新的链下账本状态；
委托节点上线，同步最新的链下账本状态，判断委托节点的资金分配在链上是否发生变化，若是，则构造追责事务，以建立委托关系时的链下账本状态和当前链下账本状态作为凭证，调用监察服务智能合约的争议处理函数，对监察服务节点进行保证金扣除，否则调用模块2，继续进行链下交易。
CN202110144286.0A 2021-02-02 2021-02-02 一种基于多人链下通道的区块链交易方法及*** Active CN112907252B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110144286.0A CN112907252B (zh) 2021-02-02 2021-02-02 一种基于多人链下通道的区块链交易方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110144286.0A CN112907252B (zh) 2021-02-02 2021-02-02 一种基于多人链下通道的区块链交易方法及***

Publications (2)

Publication Number Publication Date
CN112907252A CN112907252A (zh) 2021-06-04
CN112907252B true CN112907252B (zh) 2023-10-31

Family

ID=76121530

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110144286.0A Active CN112907252B (zh) 2021-02-02 2021-02-02 一种基于多人链下通道的区块链交易方法及***

Country Status (1)

Country Link
CN (1) CN112907252B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113570458B (zh) * 2021-07-16 2023-09-26 东北大学秦皇岛分校 一种基于代理重加密的区块链支付通道监管方法
CN113900837A (zh) * 2021-10-18 2022-01-07 中国联合网络通信集团有限公司 算力网络处理方法、装置、设备及存储介质
CN114629735B (zh) * 2022-01-20 2024-05-31 中国农业银行股份有限公司 基于多方状态通道的状态交互方法、装置、设备及介质
CN114119242B (zh) * 2022-01-28 2023-03-14 浙商银行股份有限公司 基于自适应窗口分片的联盟链性能优化方法及装置
CN114826603B (zh) * 2022-03-22 2023-11-14 上海交通大学 多人链下状态通道中信息安全保护实现方法及***
CN114666248B (zh) * 2022-05-18 2022-09-06 浙商银行股份有限公司 一种联盟链分片交易分发方法及装置
CN115150103B (zh) * 2022-08-29 2022-11-29 人民法院信息技术服务中心 基于区块链的数字凭证离线验证方法、装置及设备
CN116846916B (zh) * 2023-09-01 2023-12-08 武汉趣链数字科技有限公司 数据同步方法、装置、电子设备及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108711052A (zh) * 2018-05-18 2018-10-26 电子科技大学 一种基于区块链的信息验证***
CN108924092A (zh) * 2018-06-07 2018-11-30 北京航空航天大学 基于区块链的可公开仲裁分布式云存储方法及***
CN109104413A (zh) * 2018-07-17 2018-12-28 中国科学院计算技术研究所 用于安全多方计算的私有数据求交集的方法及验证方法
WO2019142049A1 (en) * 2018-01-17 2019-07-25 Geeq Corporation Blockchain methods, nodes, systems and products
CN111736963A (zh) * 2020-06-08 2020-10-02 中国科学院计算技术研究所 一种用于无主链多分片区块链的事务处理***及方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114207643A (zh) * 2019-04-19 2022-03-18 科恩巴斯公司 用于区块链经营的***和方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019142049A1 (en) * 2018-01-17 2019-07-25 Geeq Corporation Blockchain methods, nodes, systems and products
CN108711052A (zh) * 2018-05-18 2018-10-26 电子科技大学 一种基于区块链的信息验证***
CN108924092A (zh) * 2018-06-07 2018-11-30 北京航空航天大学 基于区块链的可公开仲裁分布式云存储方法及***
CN109104413A (zh) * 2018-07-17 2018-12-28 中国科学院计算技术研究所 用于安全多方计算的私有数据求交集的方法及验证方法
CN111736963A (zh) * 2020-06-08 2020-10-02 中国科学院计算技术研究所 一种用于无主链多分片区块链的事务处理***及方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
《Privacy Protection for Blockchains with Account and Multi-Asset Model》;Donghui Ding et al.;《CHINA COMMUNICATIONS》;第16卷(第6期);69-79 *
区块链的数据管理技术综述;张志威;王国仁;徐建良;杜小勇;;软件学报(第09期);全文 *
许可链多中心动态共识机制;闵新平;李庆忠;孔兰菊;张世栋;郑永清;肖宗水;;计算机学报(第05期);全文 *

Also Published As

Publication number Publication date
CN112907252A (zh) 2021-06-04

Similar Documents

Publication Publication Date Title
CN112907252B (zh) 一种基于多人链下通道的区块链交易方法及***
Huang et al. Repchain: A reputation-based secure, fast, and high incentive blockchain system via sharding
CN109871669B (zh) 一种基于区块链技术的数据共享解决方法
US11177939B2 (en) Blockchain system including a distributed network of a plurality of nodes and a method for achieving an agreement between the plurality of nodes executed by processors of the block chain system
CN109360100B (zh) 基于区块链技术的交易快速确认方法及装置
CN108717630B (zh) 一种出块方法及其实现***
Yun et al. DQN-based optimization framework for secure sharded blockchain systems
CN112541758A (zh) 基于区块链的多轮投票式容错排序共识机制与方法
CN109741068B (zh) 网银跨行签约方法、装置及***
EP4318362A1 (en) Blockchain-based data processing method, apparatus and device, and storage medium
CN111371905B (zh) 一种基于云计算的区块链分层共识证明***与方法
WO2020173497A1 (zh) 一种部署有中心化***的区块链网络
CN112636905B (zh) 基于多角色的可扩展共识机制的***及方法
Wang et al. Beh-Raft-Chain: a behavior-based fast blockchain protocol for complex networks
CN113407977B (zh) 基于聚合签名的跨链扩展方法及***
Wang et al. Blockchain-based dynamic energy management mode for distributed energy system with high penetration of renewable energy
CN112104685A (zh) 一种基于区块链的联盟链底层***
CN110445795B (zh) 一种区块链认证唯一性确认方法
CN115499129A (zh) 一种多模信任跨链共识方法、***、介质、设备及终端
CN112187866B (zh) 一种基于共享存储的新型区块链共识方法
Le et al. A lightweight block validation method for resource-constrained iot devices in blockchain-based applications
CN111131298A (zh) 一种基于信用去中心化的poc高效共识机制及实现方法
Ye et al. Garou: An efficient and secure off-blockchain multi-party payment hub
Xi et al. [Retracted] A Comprehensive Survey on Sharding in Blockchains
CN114143021B (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