CN112907252A

CN112907252A - Block chain transaction method and system based on multi-person down-chain channel

Info

Publication number: CN112907252A
Application number: CN202110144286.0A
Authority: CN
Inventors: 孙毅; 裴奇; 贾林鹏; 蒋硕轩; 薛靖雯; 于雷
Original assignee: Institute of Computing Technology of CAS
Current assignee: Institute of Computing Technology of CAS
Priority date: 2021-02-02
Filing date: 2021-02-02
Publication date: 2021-06-04
Anticipated expiration: 2041-02-02
Also published as: CN112907252B

Abstract

The invention provides a block chain transaction method and a block chain transaction system based on a multi-person chain lower channel. And finishing the wheel consensus when each wheel is finished, and finishing the check point consensus when each period is finished. In the round of consensus stage, a leader sends a result, other nodes verify voluntarily, and provide service for offline nodes by the aid of supervision service; the checkpoint consensus carries out online two-stage consensus of all nodes and supports dynamic joining and exiting of channel nodes. Therefore, the consensus process can be accelerated, the system flux is improved, the risks of delayed discovery of malicious transactions and withdrawal of excessive transactions are reduced, and the flexibility of the nodes and the safety of the system can be ensured.

Description

Block chain transaction method and system based on multi-person down-chain channel

Technical Field

The invention relates to the technical field of research on the expansibility of a block chain, in particular to a method and a system for a channel under a multi-person chain of the block chain.

Background

The block chain has the characteristics of distribution, openness and transparency, safety and the like, so that people can conveniently and quickly exchange values on the Internet at low cost, and the block chain is a foundation for realizing the value Internet. The blockchain technology is just aiming at the verification and use requirements in a small-range technology community at the beginning of generation, and the simplicity and the robustness of a blockchain protocol are the initial design premise of the blockchain technology, so that the popularization of the blockchain technology to a wider-range and highly-concurrent internet application is not considered. The nodes in the block chain network adopt a unified consensus process, so that the characteristics of block chain safety and decentralization are realized, but the nodes in the whole network copy shared global account book data, block data containing transaction data are subjected to flooding transmission in the whole network, all data need to be verified and stored by each consensus node receiving the block, and the block chain performance is hindered by the mechanism. Therefore, there is still a large exploration space for improving the performance of the blockchain.

The low throughput of blockchains (measured as the number of transactions processed per second by the system), i.e. transactions per second, hereinafter referred to as TPS, directly limits the practical application scenarios. In a bitcoin network, since the entire network adopts a uniform consensus process, assuming that the average network bandwidth of the nodes is 10Mbit/s, the upper limit of the number of transactions that can be received per second for each node is 1000. Assuming that each node verifies each transaction for about 5ms, the theoretical number of transactions processed per second by each node is up to 200. Then the upper limit on the number of transactions per second that each blockchain network node can receive and validate is only about 200, subject to the synchronization mechanism and machine processing performance. In the actual operation process, the bitcoin processes 3.5 transactions per second averagely, and the Etheng processes 15 transactions per second averagely, so that even though the alliance chain has higher performance, the average TPS in the production scene is thousands of grades. With the soaring transaction volume of representative public link systems such as bitcoin and ether houses, the transaction congestion on the link is increasingly shown, and the number of unconfirmed transactions of the bitcoin and the ether houses can reach about 15 ten thousand. Congestion makes transaction fees expensive within a blockchain network, and may even cause transaction execution failure when congestion is severe.

In the financial field, the WeChat pays money at the present stage, and the WeChat processes thousands of transactions per second on average, and reaches hundreds of thousands of transactions at the peak value; a common credit card company, the payment card VISA, can handle nearly ten thousand transactions per second, and the validation time of a transaction only takes a few seconds. It is seen that the throughput and practical application of the blockchain system and the centralized transaction solution in daily use are far from the old, and therefore, increasing the blockchain throughput has become an urgent requirement for the blockchain application.

At present, in the research at home and abroad, the scheme for improving the block chain flux mainly comprises two schemes of chain up capacity expansion and chain down capacity expansion.

The on-chain expansion refers to the improvement of expandability through the basic protocol of optimizing and improving the block chain, and the included schemes are more diverse and are mainly embodied in three layers, namely a network layer, a consensus layer and a data layer. Such as selecting a faster consensus algorithm in the consensus layer; increasing the size of the block in the data layer or reducing the size of the transaction packet; a fragmentation protocol is provided in a network layer, and a block chain can process transactions in parallel, so that the performance of the block chain is improved. However, under the basic architecture and protocol framework of the block chain technology, by optimizing the parameters (block spacing, block size) and the operating environment parameters (GPU, memory, hard disk, network bandwidth of the mining node) and the like built in the protocol, the expected upper limit of the optimization effect can be estimated and cannot reach the flux level of the traditional centralized technology, that is, most of the effects of expansion on the chain are limited, and the expansion and upgrade process can cause hard branching, and although the throughput can be remarkably improved, the safety of the main chain can be reduced, and the protocol is very complex and is not complete at present. Attempting to implement a large replacement of the underlying protocol on a public-link system would face a double pressure of technology and community.

Under-chain (off-chain) capacity expansion does not change the basic protocol and the original trust hypothesis of the blockchain, and some operations are put outside the chain to improve the main chain throughput and provide the blockchain with the transverse expansion capability. The under-chain capacity expansion scheme mainly comprises an out-chain channel scheme and a side chain scheme, wherein the side chain is a chain parallel to a main chain, the chains can have own consensus mechanism, the consensus mechanism is not required to be the same as that of the main chain, the side chain is not completely independent, final settlement is finally carried out by depending on the main chain, the instant termination is not achieved, and the core problem concerned by the under-chain capacity expansion scheme is that a service scene is across chains, and the technical progress is not brought to the flux requirement. The downlink channel has instant termination and transaction privacy, and can minimize uplink operations, so that the downlink channel is widely concerned as a promising downlink expansion scheme. The status channel is used as a mainstream downlink capacity expansion protocol and can support different types of applications. Specifically, the participants of the application lock the status on the chain, and the participants agree locally under the chain, and the completion of the agreement can be considered that the status is confirmed. When an application is to be exited, the state is cleared on the chain. The payment channel belongs to the specific application of the state channel in the payment field, only completes the payment operation of asset transfer, and realizes the transaction with higher speed and lower cost.

The channel types can be divided into a double channel and a multi-person channel according to the number of lockable fund people supported in the payment channel.

The double channel means that the participants of the channel are two users, when the sender and the receiver lock funds on the chain respectively, the money is fixed on the channel of the two parties, the two parties trade at will in the channel, and the local part updates and identifies the account book, so that the natural problem of double flowers does not exist. Typical comparison is a lightning network based on a UTXO model and a lightning network based on an account model. When the transaction is carried out between nodes which are not directly connected in a double channel, one mode is that a sender and a receiver lock funds on a chain, a channel is newly built, and the two parties carry out any multiple transactions. If every two parties need to set up a channel on the uplink, the interaction with the link is too much, the overall overhead of the system is large, and the purpose of capacity expansion under the link cannot be achieved. The other way is to find a path in the payment channel network, and to complete a transaction by routing the transaction through other intermediate nodes and payment of one hop and one hop. The method is greatly influenced by network topology and routing algorithm, the fund capacity on the path is greatly influenced, when the network communication degree is low, the routing path of cross-channel transaction is long, the transaction success rate is reduced, and the problems of channel blockage, channel imbalance and the like also exist.

In a general sense, the multi-person channel allows multiple ginseng to be added into the same channel, and transaction is carried out between any two parties in the channel, but the updating of the account book is carried out in the channel globally, and needs to be approved by all nodes in the channel, and one fund can be used for transaction with multiple persons, so that the channel is more flexible in fund use, and the problem of double flowers is brought. In the multi-person channel, all nodes in the same channel can be directly transacted, the nodes are added into the multi-person channel through transaction on one link, namely n unidirectional connections are established, compared with the method for establishing one unidirectional connection on one link of the double channel, the network connectivity is improved by n times, the cross-channel transaction is reduced, and meanwhile, the problems existing in the double channel can be relieved, so that the multi-person channel is an effective means for improving the flux of a block chain system.

At present, a multi-person channel has a plurality of construction modes, and the problem of how to enable a plurality of persons to transfer money more conveniently is solved substantially, but a transaction object is not restricted to a specific peer party like a double-person channel.

The scheme extends on the basis of a double channel, and a virtual channel mechanism is applied to construct a multi-channel, wherein the multi-channel is a double channel in nature, and funds are bound on a specific link when the funds are locked on the link. Specifically, the method comprises the following steps: the multi-person virtual channel includes two types of channels, one is a channel formed after locking funds on a chain, and is called an account channel (referred to as a channel in the foregoing), and the other is a virtual channel established based on an existing account channel. For example, three nodes a, B and C are directly connected by an account channel, when direct transaction of a and C is required, in order to reduce overhead on a chain, instead of directly establishing the account channel from a to C, a part of funds are reserved in the channels from a and B and the channels from B and C, B is used as an untrusted third party to establish a virtual channel from a to C, an intermediate node B participates in consensus only when the virtual channel is established and revoked, and transaction can directly occur between a and C. The multi-person virtual channel means that nodes participating in the same multi-party channel are on a directly connected path, and the path is not sensitive to the specific channel type at the bottom, namely, the virtual channel and the ledger channel can be combined. The scheme applies the virtual channel, expands the original downlink channel network and provides a choice for establishing a multi-party channel, but the problem is obvious: in order to enable multiple nodes to be on a directly connected path, multiple virtual channels need to be established recursively, and the mechanism is complex; although the path searching problem can be relieved by pre-locking funds, the problems of available paths, channel blockage and channel unbalance still exist, and the flexibility is poor; in order to realize a punishment mechanism under a malicious condition, except for a head node and a tail node on the path, the locked funds of other intermediate nodes are higher than the actual needs of the intermediate nodes, so that the liquidity of the funds is weakened; the scheme does not support the dynamic joining and exiting of the nodes, each state updating needs the participating transaction nodes on one path to achieve consensus, and the throughput of the multi-hop serial updating mode is limited.

Another way is to use intelligent contracts to lock funds on the chain, i.e., multiple people are locked in a lane, so that after multiple people build the lane, the locked funds on the chain can be traded among multiple people in the lane. The specific scheme comprises the following steps: the NOCUST comprises a chain verification contract and a fixed chain operator (operator, which is specially used for providing transaction transfer service for other nodes in a channel), and the chain operator forms a star-shaped multi-person channel; each node sends the status update to the operator, and the operator periodically submits the transactions to the chain in batches; within a period of time, the node can only send a transaction, and the down-link transaction can be continued after the determination. In this scheme a fixed operator introduces a single point of failure; the time delay of state updating is increased periodically and alternately on the chain; and the concurrent processing is not supported, and the effect of capacity expansion under the chain is influenced. Gnocchi is used as a multi-person under-chain payment scheme supporting high concurrency, when a multi-person channel is constructed, a leader is selected under the chain by multiple parties, and then the channel is opened and the state in the channel is updated by the leader. The leader periodically broadcasts the latest under-link state to the user nodes in the under-link channel, and all nodes in the channel check the under-link result. The leader of the scheme is selected in advance, and although the reliability is high, a single point of failure still exists; no interactive verification exists among nodes in the transaction process, so that the malicious (double flowers) can be only discovered in a delayed way; when the node exits, updating in the channel is suspended, and the operation can be continued under the chain only after the state on the chain is updated, so that the stability and the throughput of the channel are obviously reduced along with the increase of the exiting frequency of the node; when the leader is to exit, the entire channel must be shut down, which is not friendly to other nodes and is not reasonable. The Garou is a multi-person channel based on a variable center node, the channel does not rotate around a node, and the nodes are in an equal position. And at the beginning of each period, selecting a unique leader in the current round by taking the current balance of all the nodes as a random seed. When the current round is to be finished, the two-stage consensus algorithm is executed inside the channel, all nodes in the channel reach the same result, and then the next round is started. The scheme is weakly central, and the joining and exiting of the nodes can be realized in each round of consensus process. However, all nodes need to participate in two-stage consensus, and as the number of user nodes in a channel under a link increases, communication overhead and transaction delay in the channel also increase, thereby reducing the consensus efficiency. The mode of replacing the leader in each round can stress some nodes without computing capacity, and the channel cannot be used when the leader rotated is not on line.

When the inventor conducts research on the multi-person downlink channel, the key advantage of the multi-person downlink channel is found that one fund locked in the channel by the user can be in downlink transaction with any user in the channel, the mobility of the channel fund is improved, and the channel establishment cost among the users is reduced. However, the multi-person downlink channel simultaneously introduces the problem of consistency of multi-person status updates, and needs to prevent double spending of funds. The main idea of the existing scheme is to elect a leader in a channel, the leader is responsible for collecting and processing transactions, and a mechanism is designed to achieve consensus on account book updating, so that malicious conditions can be detected immediately, and the safety of funds is ensured. However, the prior art has a great weight in the process of mechanism design, and generally speaking, the common efficiency in the channel interior and the channel stability still have a large improvement space.

In terms of consensus efficiency, existing mechanisms can be divided into on-chain consensus and off-chain consensus.

Chain consensus requires that the leader periodically uplink transaction information processed periodically, and is achieved in a manner known in the art. However, the periodic transaction delay of the result of the link-up method is large and expensive transaction fee is required, so that more schemes select the way of the link-down consensus.

The under-chain consensus refers to using some consensus algorithm inside the channel to agree on the result. One solution is to use a two-phase consensus, i.e., after the leader broadcasts the results, all nodes need to check the results and, if legal, need to return a signature for the results to the leader within a specified time, and the leader node considers an agreement after collecting the signatures of all nodes. In this way, as the number of user nodes in the channel under the link increases, the communication overhead and the transaction delay in the channel also increase, thereby reducing the consensus efficiency. Another scheme does not require the user node in the downlink channel to respond to the legal result, and only needs to uplink the user node when the malicious situation is found. No special handshaking consensus process exists among the nodes, and the leader only simply broadcasts the result, so that the consensus process is accelerated. However, when the leader makes a malicious call or the network condition is not good, the malicious call is delayed to be discovered, and for the dynamic joining and exiting of the nodes, the channel needs to be updated and suspended, and the channel can be continuously used after the chain is removed for settlement, so that the corresponding overhead is relatively high, and the efficiency is reduced.

From the aspect of channel stability, the existing mechanism is mainly divided into a fixed leader and a random leader replacement for each round in the selection of the leader. In the scheme of the fixed leader, the channel is continuously managed by the fixed leader from the establishment to the closing, so that the power of the fixed leader in the channel is too large, and the channel cannot be used continuously once the leader goes down. And because the existing random scheme lacks evaluation on the aspects of node computing capacity, online service capacity and the like, under the conditions that the computing power of the elected leader is low, the leader is not online and the like, the channel service under the chain cannot be used, the channel stability is further damaged, the user experience is seriously influenced, and the system safety is damaged.

Disclosure of Invention

The inventor discovers that the multi-person channel scheme needs to be redesigned to solve the problems through research on the existing multi-person channel technology, and the scheme covers the full life cycle of the channel: the method mainly improves the processes of channel establishment, down-link transaction, down-link consensus, channel closing, dispute processing, node dynamic joining and exiting and the like in a down-link consensus part so as to improve the flux and stability of the system.

In view of the deficiencies of the prior art, the present invention aims to optimize a processing flow of a blockchain multi-person chain lower channel, and to achieve improvement of throughput and stability of a multi-person chain lower channel system, and specifically, the present invention provides a blockchain transaction method based on a multi-person chain lower channel, including:

step 1, a user node initiates a transaction request for opening a downlink channel to a block chain, the block chain opens the downlink channel according to the transaction request, the user node serves as a leader to join the downlink channel and is responsible for maintaining the state of a downlink account book, a plurality of user nodes join the downlink channel through a channel identifier of the downlink channel, and the number of initialization rounds is 0;

step 2, judging whether the current wheel number is smaller than a preset value, if so, executing step 3, otherwise, executing step 4;

step 3, initiating down-link transaction among user nodes in the down-link channel within preset time, confirming the signature of the down-link transaction by a leader according to the signature of a sender and the signature of a receiver of the down-link transaction, recording the down-link transaction into a down-link account book, returning the confirmed signature to the sender and the receiver, broadcasting down-link account book state update to all the user nodes in the down-link channel by the leader after the preset time is reached, adding 1 to the number of rounds, and executing the step 2 again;

and 4, the leader sends a check point consensus message containing the state of the account book under the chain to all user nodes in the channel, the user nodes in the channel realize that all the user nodes in the channel achieve a consistency view on the state of the account book under the chain by confirming the check point consensus message, the number of turns is set to zero, and then the step 2 is executed.

The blockchain transaction method based on the multi-person downlink channel, wherein

In step 1, the joining of the user node as a leader to the downlink channel specifically includes:

subtracting value _ A from the account fund of the user node on the block chain, adding value _ A to the account fund of the user node in the channel under the chain, and returning a unique channel identifier for the transaction request by the contract;

in step 1, the adding, by the plurality of user nodes, the channel identifier of the downlink channel into the downlink channel specifically includes:

initiating a transaction of adding into the downlink channel by a user node to be added, wherein the transaction comprises a channel identifier to be added, locking the fund of the user node to be added, updating the state of an account book under the link, expressing the balance of the account and transaction information corresponding to the account by a Mercker line segment tree, and storing the balance of the account in the account tree by dividing the line segment; and the transaction information corresponding to each account is stored in a transaction tree, wherein the expenditure transaction is represented by a Mercker tree, the income transaction is represented by a Mercker line segment tree, and the user nodes in the down-link channel synchronize the down-link account state with the user nodes to be added.

The blockchain transaction method based on the multi-person downlink channel comprises the following steps of (2):

the leader checks whether the transaction serial number of the transaction sender under the chain is continuously increased and whether the balance is sufficient; and after the checking is passed, signing the transaction, sending the signature to a sender and a receiver, and updating the state of the account book under the chain: adding a leaf node in the transaction tree of the account of the receiver to record the information of the transaction under the chain and reconstruct the Mercker tree of the transaction; newly adding leaf nodes in the transaction-out tree of the account of the sender, and reconstructing a Merckel transaction line segment tree.

The blockchain transaction method based on the multi-person downlink channel, wherein the step 3 comprises the following steps:

if the user node in the downlink channel does not receive the state update of the account book within the specified time, sending a request to the leader, and waiting again; if the sender still does not receive the reply of the receiver after waiting, submitting a request to the block chain, and requiring a leader to submit the state update of the current round of the account book to the chain;

and if the leader does not submit the current round of book state update to the chain within the set time, the user node initiating the request submits the latest check point consensus message on the chain and requests to punish the leader, so that the capital punishment of the leader node is realized, and the capital distribution is divided again on the chain.

The blockchain transaction method based on the multi-person downlink channel comprises the following steps of (4):

the leader broadcasts a checkpoint consensus message to all user nodes in the downlink channel, wherein the checkpoint consensus message comprises account book state updating of leader signatures, requests for joining and quitting nodes and requests for election of the leader;

after all the user nodes verify the consensus information, all the user nodes send signatures to the leader, and locally record the latest consensus information;

when the leader receives the signatures of all the user nodes in the current channel, an aggregated signature message of the signatures of all the user nodes is constructed and sent to all the user nodes in the channel, the consensus is completed, and all the user nodes achieve a consistent view on the latest linked account state.

The blockchain transaction method based on the multi-person downlink channel, wherein the step 3 further comprises:

and all user nodes in the downlink channel locally calculate the importance scores of the candidate nodes, and update the leader by taking the importance scores as weights and adopting an encryption drawing mode.

The blockchain transaction method based on the multi-person down-link channel further comprises the following steps:

the monitoring service node in the block chain calls a monitoring service intelligent contract, locks a fund as a guarantee fund and provides service to the outside;

the user node in the downlink channel is used as a delegation node to establish a delegation relationship with the monitoring service node by using a Hash time lock mechanism, and the delegation node is offline before executing the step 4;

when disputes occur in the down link channel, the monitoring service node raises up the down link account state to the link by initiating a state updating challenge, judges whether balance division of the entrusting node in the down link account state submitted to the link is correct or not, if yes, the latest down link account state is stored, otherwise, the monitoring service node raises up the error challenge to the link, and the latest down link account state is stored after the benefit of the entrusting node is maintained;

and (3) the entrusting node is on-line, the latest linked account state is synchronized, whether the fund distribution of the entrusting node changes on the link is judged, if yes, a pursuit transaction is constructed, the linked account state when the entrusting relationship is established and the current linked account state are taken as certificates, a dispute processing function of the intelligent contract of the monitoring service is called, the guarantee fund is deducted from the monitoring service node, otherwise, the step 2 is executed, and the linked transaction is continued.

The invention also provides a blockchain transaction system based on the multi-person down-link channel, which comprises the following steps:

the system comprises a module 1, a block chain and a plurality of user nodes, wherein the module 1 is used for enabling the user nodes to initiate a transaction request for opening a downlink channel to the block chain, the block chain opens the downlink channel according to the transaction request, the user nodes are used as a leader to join the downlink channel and are responsible for maintaining the state of a downlink account book, the plurality of user nodes join the downlink channel through channel identifiers of the downlink channel, and the number of initialization rounds is 0;

the module 2 is used for judging whether the current round number is smaller than a preset value, if so, the module 3 is called, and otherwise, the module 4 is called;

a module 3, configured to initiate a downlink transaction between user nodes in the downlink channel within a preset time, where a leader confirms the signature of the downlink transaction according to a sender signature and a receiver signature of the downlink transaction, and records the downlink transaction in a downlink account book, and returns the confirmed signature to the sender and the receiver, and after the preset time is reached, the leader broadcasts a downlink account book state update to all user nodes in the downlink channel, and adds 1 to the number of rounds, and executes the module 2 again;

a module 4, configured to enable a leader to send a check point consensus message including the state of the account book under the chain to all user nodes in the channel, where the user nodes in the channel achieve a view of consistency of the state of the account book under the chain by all user nodes in the channel by confirming the check point consensus message, and the number of rounds is set to zero, and then the module 2 is called;

wherein the joining of the user node as a leader in the module 1 to the downlink channel specifically includes:

the adding, by a plurality of user nodes in the module 1, the downlink channel via the channel identifier of the downlink channel specifically includes:

The blockchain transaction system based on the multi-person down-link channel comprises a module 2 and a module management module, wherein the module management module comprises:

the leader checks whether the transaction serial number of the transaction sender under the chain is continuously increased and whether the balance is sufficient; and after the checking is passed, signing the transaction, sending the signature to a sender and a receiver, and updating the state of the account book under the chain: adding a leaf node in the transaction tree of the account of the receiver to record the information of the transaction under the chain and reconstruct the Mercker tree of the transaction; newly adding leaf nodes in a transaction tree of a sender account, and reconstructing a Mercker transaction line segment tree;

the module 3 comprises:

if the leader does not submit the current round of book state update to the chain within the set time, the user node initiating the request submits the latest check point consensus message on the chain and requests to punish the leader, thus realizing the fund punishment to the leader node and subdividing the fund distribution on the chain;

the module 4 comprises:

The blockchain transaction system based on the multi-person down-link channel, wherein the module 3 further comprises:

all user nodes in the downlink channel locally calculate importance scores of the candidate nodes, and the importance scores are used as weights to update the leader in an encryption drawing mode;

the blockchain transaction system based on the multi-person down-link channel further comprises:

the user node in the downlink channel is used as a delegation node to establish a delegation relationship with the monitoring service node by using a Hash time lock mechanism, and the delegation node is offline before the module 4 is called;

and the entrusting node is on-line, the latest linked account state is synchronized, whether the fund distribution of the entrusting node changes on the link is judged, if yes, a pursuit transaction is constructed, the linked account state when the entrusting relationship is established and the current linked account state are taken as certificates, a dispute processing function of the intelligent contract of the monitoring service is called, the guarantee fund is deducted from the monitoring service node, and if not, the module 2 is called to continue the linked transaction.

According to the scheme, the invention has the advantages that:

the current mainstream block chain technology generally faces the problems of low flux, poor expansibility and the like in the actual service scene. The chain down channel is used as a capacity expansion scheme with high feasibility, and is very beneficial to the improvement of flux. Current solutions lack in-depth considerations in channel internal consensus efficiency and channel stability. In fact, the core problem of the multi-person channel is how to perform transactions among multiple persons, and how to achieve consensus on the transactions in the channel for a period of time, so that an efficient consensus algorithm can be adapted in the multi-person channel, and a reasonable mechanism is designed to ensure safety and usability. The core of the invention comprises the steps of evaluating user nodes in the downlink channel to select a better leader node and provide support for the long-term stable operation of the channel.

Drawings

FIG. 1 is a diagram of a processing architecture for a multi-person downlink channel system;

FIG. 2 is a flow diagram of an audit service;

FIG. 3a is a schematic diagram of a transaction flow;

FIG. 3b is a schematic diagram of the system at an operational stage;

FIG. 4 is a diagram of state transitions within a down link lane;

FIG. 5 is a diagram showing the common view of checkpoints in a down-link channel;

FIG. 6 is a schematic representation of a Merckell's line segment tree;

FIG. 7 is a flow chart of a double payment channel process of the present invention;

FIG. 8 is a flow chart of the multiple payment gateway process of the present invention;

FIG. 9 is a flow chart of an audit service mechanism.

Detailed Description

In order to make the aforementioned features and effects of the present invention more comprehensible, embodiments accompanied with figures are described in detail below.

The invention aims to optimize the processing flow of the block chain multi-person under-chain channel and realize the improvement of the flux and the stability of a multi-person under-chain channel system. Specifically, the method comprises the following steps:

the path establishment process allows multiple nodes to join the same path rather than being limited to transactions between two parties, thereby enabling a locked share of funds on the chain to be used between multiple parties down the chain. The transaction under the chain needs three parties, namely a sender, a receiver and a leader, the three parties can be signed to consider the transaction to be confirmed, and any party doing the malicious can submit the malicious evidence to be disputed on the chain. The node exits, and dispute processing is executed on the chain, so that safety guarantee is provided for the channel under the chain.

The consistency is enhanced by the under-chain consensus, the state of the whole system is updated by taking a round as the minimum unit, each round is a complete transaction process between nodes, check points are inserted among multiple rounds, and the multiple rounds between the check points and the previous check point form the synchronization period of the whole system. And finishing the wheel consensus when each wheel is finished, and finishing the check point consensus when each period is finished. In the round of consensus stage, a leader sends a result, other nodes verify voluntarily, and provide service for offline nodes by the aid of supervision service; the checkpoint consensus carries out online two-stage consensus of all nodes and supports dynamic joining and exiting of channel nodes. Therefore, the consensus process can be accelerated, the system flux is improved, the risks of delayed discovery of malicious transactions and withdrawal of excessive transactions are reduced, and the flexibility of the nodes and the safety of the system can be ensured.

And introducing an on-demand replacement mechanism of the leader node during the operation of the system, wherein the on-demand replacement mechanism comprises normal exit and early exit of the leader at a check point. The early quitting is divided into active quitting and passive quitting, and the safety of funds in the channel under the chain is ensured by providing a processing method for various quitting behaviors of the leader; and designing a node evaluation mechanism, randomly selecting a leader node with higher importance to the system, and improving the stability of the system.

The architecture of the multi-person downlink channel system proposed by the present invention is shown in fig. 1. The multi-person under-chain channel processing architecture provided by the invention comprises a client module, an on-chain block chain layer and an under-chain multi-person channel layer.

The client manages account information and realizes management of uplink and downlink assets of the chain. The method comprises the steps of transferring account assets on a block chain into accounts of a channel under the chain, transferring account assets in the channel under the chain into accounts of the block chain, and mutually transferring accounts in the channel under the chain. The client needs to complete the function of the user interacting with the uplink and the downlink of the chain, and the interaction with the chain is realized through the channel management module; the down-link interaction mainly completes the sending and receiving of the transaction and is responsible for the transaction processing module. When the user participates in the down-link activities, the user needs to be responsible for the state of the user in the channel, so that the function of maintaining the state of the channel is played, and the role management module completes the role switching function according to different participation degrees.

The block chain layer on the chain plays a role in protecting the safety of the fund of the user under the chain, can receive the request initiated by the user, and can monitor the message under the chain to realize the cooperation under the chain. The method comprises the following steps: the multi-person payment channel service module provides basic support capability for normal operation of a multi-person channel and realizes the functions of opening and closing the channel, dispute processing, node joining and quitting and the like; the channel monitoring service monitors dispute processing information on the chain for an offline node under the chain, uploads the state in time, provides value-added service under the chain, provides enough flexibility for users and provides safety.

The multi-person channel layer under the chain mainly unloads load pressure on the chain, and fast and low-cost state conversion between accounts under the chain is completed. The trading module is responsible for the transaction state conversion between two parties in the multi-person channel, the selected leader checks the validity of the transaction, confirms the transaction and prevents double flowers. Generally, the sender, the receiver and the leader acknowledge the signed transaction, and then the signed transaction is acknowledged to be completed, so that the waiting time delay on the chain is greatly reduced. The nodes in the channel can transfer accounts with each other, and each node needs to know the current ledger state of other nodes definitely, so that a consistency view is achieved among the nodes in the channel through a consensus mechanism. The consensus process is divided into two categories, wheel and checkpoint. The transaction process and the consensus process both need the participation of a leader to accelerate the processing process, but need to replace the leader as required, and comprise the normal exit of the leader at a check point, the active exit at a certain round and the passive exit at a certain round; and when a new leader is generated, comprehensively evaluating the nodes and selecting the better nodes.

It should be particularly noted that the processing flow of the present invention is applicable to multi-person channels of any status class, including but not limited to multi-person payment channels, multi-person application channels, etc. For simplicity of illustration, the present invention is described with respect to a multiple people payment channel.

The specific module design of three parts is as follows:

a client:

the client mainly comprises four modules of account management, channel management, transaction processing and role management.

The account management module is responsible for generating and locally storing the account private key. Meanwhile, an Elliptic Curve Digital Signature Algorithm (ECDSA) and a Keccak-256 algorithm are used for obtaining an account address corresponding to the private key. Each user may have a different account. The channel management module completes the transfer of the account assets on the block chain to the accounts of the channel under the chain, and transfers the account assets in the channel under the chain to the accounts of the block chain; and completing the transfer among accounts in the down-link channel with the transaction module.

The channel management module mainly completes the function of interacting with the block chain, including opening or adding a certain channel, processing disputes in the channel, and participating in the process of fund division when the channel is closed or quits the channel.

After the node creates or joins the channel through the channel management module, the node can participate in the down-link transaction by using the transaction processing module. And the participator calls the transaction sending module to specify a channel to be transacted and another peer, and completes the transfer operation between accounts in the channels of the two transacting parties in the multi-person channel under the chain.

And the role management module is responsible for managing the capacity of the current node participating in the channel. If the transaction is only simply participated in, the channel is only required to be maintained, the maintenance comprises checking and authenticating each participated transaction, the latest down-link account book state is required to be synchronized during each round of consensus, and the wrongly-done condition is fed back to the link in time. If one wants to become a leader, one needs to assume more responsibility, including collecting all transactions in the channel, checking and authenticating as intermediate nodes for each transaction, and signing endorsements. Therefore, as a leader, the leader has requirements on the machine performance, the online time, the network condition and the like of the node, and simultaneously as an incentive mechanism, the leader can charge a small transaction fee for each transaction.

Block chain layer on chain:

the main realization form on the chain is an intelligent contract which comprises a module for multi-person channel service and a channel monitoring service module for providing off-line service for user nodes in a channel under the chain.

And a multi-person channel service module. The module receives the call of the channel management module in the client and serves the channel of the multiple people under the chain. The method mainly comprises the following functions:

1. opening a channel: and the client node calls the function of opening the channel, establishes a new channel, transfers the fund of the block chain account into the channel account, contracts distribute a unique identifier of the whole network for the channel, and sets the relevant parameters of the channel such as a time window for dispute treatment and the like.

It should be noted that: the node when the channel is opened can be one account or a plurality of accounts, namely, a plurality of accounts privately construct an aggregated signature, call the channel establishment function, and open the channel means that a plurality of nodes are added into the channel.

2. Adding a channel: nodes that have frequent transaction requirements with nodes within the channel may invoke the function of joining the channel, entering funds that include an identifier of the channel, and want to be locked within the channel. And sends a request to the leader node.

a) Before the first checkpoint consensus (see below under-chain channel layer-consensus module) starts, a channel cube is used as a leader node for the cold start phase of the channel, and a message is sent to the channel cube during the registration on the chain.

b) If a new leader has been generated, the information of the leader node is stored in any of the user nodes in the downlink path, and the current leader node can be queried from the user nodes in the downlink path, and then a join request can be sent.

3. Dispute processing: when the number of the nodes in the channel is more than or equal to 2, the transaction process can be started, once the malicious behavior of a node in the running period of the channel is discovered by the honest node, the honest node calls a dispute processing function, inputs the latest ledger state approved by all the nodes in the channel, the malicious node makes malicious evidence and other information, enters a dispute processing challenge period in a contract, and the node under the chain can submit the latest ledger state different from the state on the chain to dispute legal rights and interests. When the challenge period ends, ledger status updates are done on the chain by contract-specific rules.

4. An exit channel: when the node decides to leave the channel, the transfer of funds from the channel account into the blockchain account needs to be completed. And calling a quit channel function, inputting quitable certification, balance division and other information, recording the latest down-link account state after contract verification, removing the node from the channel and finishing account transfer.

5. Closing the channel: closing the path corresponds to all nodes exiting the path.

And a channel monitoring service module. The module is a third-party service capable of tracing responsibility, provides capital security guarantee for online or offline nodes of a multi-person channel, and monitors messages of dispute processing on a chain of the channel. The channel node calls the supervision service module, specifies a specific supervision service node, and starts a delegation process, wherein a specific service flow is shown in fig. 2. Specifically, the method comprises the following steps:

1. and (3) registration of a service node: the service node needs to lock a guarantee in the monitoring contract to represent that the service node is registered, and after the registration is finished, the service node has a unique service identifier in the system. The more funds the service node locks, the stronger the ability to prove to bear the risk, and the more likely it is to be chosen by a node within the tunnel.

2. The channel node and the supervision service node establish a delegation relationship: both parties want to agree on a trust that can be verified and committed. This process employs a hash time lock mechanism. Specifically, the method comprises the following steps:

a) the channel node provides entrusting information to the monitoring contract, and the entrusting information comprises node state related information: the latest current down-link account state comprises a timestamp, a signature of a Mercker root of an incoming transaction and an outgoing transaction, a node account balance and the like; service node related information: i.e., an identifier of the server, etc.; service-related content: service duration, service fee, etc.; and a hash value obtained by carrying out hash operation on the original secret value, and locking the service fee in the supervision and contract.

b) The channel node sends the original value of the secret value to the service node and starts a timer.

c) The server checks whether the request content is correct or not, and whether the service sets parameters are agreed:

1) if the entrusting requirement is agreed and the reply validity period is within, the original value of the secret value is sent to the monitoring contract, the contract pays the service fee to the service party, and the service is started.

2) If not, no response is made, and when the reply time expires, the tunnel node may initiate a request to the overseeing contract to redeem the locked service fee and delegate the shutdown.

3. Other honest nodes in the channel can commonly recognize the chain account status of each round, and once a malicious event is found, a dispute processing process on the chain is initiated. To prevent malicious nodes from submitting incorrect state updates to the chain and being identified on the chain, resulting in a loss of funds from honest nodes, the channel node is required to listen for on-chain messages. The monitoring service mainly provides services that listen for messages on the chain and make feedback:

a) the monitoring service is used in the channel node online scene, so that a double-layer guarantee of fund safety is provided, and the phenomenon that dispute processing messages on a chain are not observed due to temporary downtime of the channel node or other accidents is avoided.

b) After the channel node is offline, the supervision server which needs to be entrusted is full to provide service according to an entrusting contract, and once the condition unfavorable to the entrusting party is found, the certification representing the benefit of the entrusting party is submitted to the on-chain dispute handling process of the channel.

c) It should be noted that if the channel node is not immediately taken off the line after delegation, and also participates in the consensus process, resulting in a change of the latest status, the latest status needs to be provided to the service node when the channel node is taken off the line.

4. And after the channel node is on line, the service condition of the monitoring service party is checked, and if the service is in dispute, dispute processing in a monitoring service contract can be invoked to punish the service party.

Under-chain multi-person access layer:

the multi-person channel layer under the chain takes the block chain as the endorsement to realize safe, quick and low-cost transaction. The system mainly comprises a transaction module and a consensus module. In order to ensure the safe and controllable passage, a secondary leader is provided to replace the modules as required. In order to enhance the stability of the channel and maintain good ecology in the channel, a node evaluation module is provided to calculate the importance of the nodes and select a better leader.

Transaction module

The transaction is mainly participated by the sender, the receiver and the third-party leader, and the specific processing flow is as shown in fig. 3 a:

1. the user initiates a down-link transaction at the client, signs the down-link transaction and sends the down-link transaction to the receiver. Where the transactions include transfer transactions, contract invocations, and the like.

2. And after receiving the transaction, the receiver checks whether the state change of the transaction is effective, and sends the signed down-link transaction to the sender.

3. And the sender sends the transaction signed by the two parties to the leader, the leader checks the validity, confirms and signs, and sends the signature result to the sender and the receiver.

It should be noted that step 3 may also be sent by the receiver to the leader, and this example is for illustration only. The result of the offline transaction process is that the three parties validate and sign a transaction.

Consensus module

The processing in the down link channel is calculated in cycles. According to different consensus patterns, the method is divided into a round (slot) and a check point (checkpoint). Multiple rounds constitute one check point, and a period is formed between two check points. Checking points requires all nodes to be online, synchronizing the down-link account state occurring in the week period, and signing and authenticating the latest down-link account state. And the monitor provides monitoring service for each round of offline nodes. The system operation phase division diagram is shown in fig. 3 b.

And taking the result after the check point consensus as an initial state, and entering the transaction stage of each round. And (4) ending a round of the common identification stage, and aiming at enabling the user nodes in the channel under the chain to find the malicious conditions of the leader node in time. And (4) entering the inspection point after a plurality of rounds to be commonly identified, and performing reciprocating circulation. The in-channel ledger status update is shown in fig. 4.

The round consensus refers to the leader periodically broadcasting to all nodes in the channel the down-link account status that includes all transactions for the round. The method aims to ensure that the honest nodes verify the behavior of the leader in a short time in time, discover the malicious situation as early as possible and avoid too many transactions of rollback.

If the leader is good and the account status is broadcast according to the rule on time, the online nodes in the channel can receive the account update and verify the account update under the condition of good network condition.

If the leader is malicious or the network is in a bad condition, the online node does not receive the message broadcasted by the leader within a preset time, and then sends the message to the leader to request. Once the leader does not respond at the specified time, the user nodes in the downlink channel initiate an application to the chain requesting the leader to broadcast the status update for this round. Once the leader has not fed back within the specified time, it can be concluded that the leader is in offence, and a dispute treatment is initiated up the chain while entering the process where the leader passively exited.

The checkpoint consensus is a consensus made in a certain round after multiple rounds (or one round), and all nodes are required to be online. The method aims to enable all nodes in the channel to achieve a consistent view of the link account state in the channel, process the joining and quitting requests of the nodes and finish the replacement of the leader. The flow chart is shown in FIG. 5:

1. and the leader initiates a check point consensus process and sends a check point consensus message to all nodes in the channel, wherein the check point consensus message comprises the current linked account state, a joining and quitting request, a candidate leader request and a channel closing request.

2. And the user node in the downlink channel checks after receiving the account book update:

a) without objection, send a signature to the leader.

b) And if there is an objection, submitting state update to the chain and performing dispute processing. Consensus within the channel is interrupted, which in turn enables determination of current round book updates on the chain.

3. The leader waits for the checking result of the user node in the downlink channel on the downlink account book state:

a) and if the leader receives the signatures of all the nodes in the channel in the normal waiting window, considering that all the nodes agree with the result, broadcasting the aggregated signatures of all the nodes, replacing the leader, and entering the next round.

b) If the leader does not receive the signatures of all the nodes in the channel in the normal waiting window, the leader directly initiates a request on the chain and requires the non-response nodes to respond to the signatures. Nodes that do not submit signatures on time are punished. The determination of the current round ledger update is in turn implemented on the chain.

Replacing the leader as needed:

the method comprises the steps of normally exiting the leader at the check point and early exiting according to requirements, wherein the early exiting comprises active exiting and passive exiting. Normal exits are lossless, while early exits impact the stability of the lane, thus requiring arbitration on the chain and penalizing the leader with a certain amount of money. Specifically, the method comprises the following steps:

1. and when the leader actively exits in advance, the leader calls a leader exiting function of the channel contract to submit the current latest under-chain state update to the chain. If the arbitration is completed according to the status submitted by the leader on the chain, then a slight penalty is executed for the leader, such as a proportional penalty on the fund in the channel, and the leader is prohibited from participating in the transaction or competing for the leader for a period of time.

2. Passive exit is caused by bad service quality of the leader node or a bad condition, the bad condition is found by honest nodes under the chain, evidence that the service quality of the leader node is bad is submitted to a dispute processing program of a contract of the channel on the chain, the contract carries out arbitration, severe punishment is carried out on the leader, for example, funds in all channels are deducted, and the channel is driven out.

When the leader exits, a new leader needs to be generated. The new leader node election uses the encrypted drawing mode, but takes the importance scores of the nodes as the calculation weight.

The node that wants to become the r-th round leader uses locally the following encrypted drawing algorithm:

procedure Sortition(sk_i,seed_r,τ,r,w,W):

<hash，proof)←VRF_sk(seed_r||r)

j++

return<hash，proof，j>

wherein sk_iIs the private key of the candidate node, seed_rIs the random number of round r, r is the current round number, τ is the threshold number of candidates expected to enter the final selection, W is the importance score import of the current node, W is the sum of the importance scores. Using VRF, hash values and a certificate representing the current node can be computed. p represents the probability of each importance of a node making it elected. To be provided with

As the selection threshold, a node that can satisfy the condition is selected.

The importance scores are given as follows, where the functions f1, f2, f3, f4 represent functions in unity, and delta, alpha, beta, gamma represent the effect of each term on the importance score. balance_kRepresents the balance of candidate node k at the r-1 checkpoint; txOutNum_kIs a node in [ r-x, r-1 ]]Output total transaction number of, txInNum_kIs a node in [ r-x, r-1 ]]The input transaction total of (1), txSign is the node at [ r-x, r-1 ]]In addition to self-trading, other signature trading totals, i.e., nodes, have elected leaders and provided authenticated services for others.

The importance score comprehensively considers the balance in the channel of the node and the behavior activity of the node in a period of time to represent whether the node actively participates in the transaction in the channel. For example, if a, B, C all want to become the leader of the next round, if C has a lot of locked funds when joining, but because it has no trading activity for a while, then there is trading activity for a and B with a small balance when calculating the importance score, and it has a high probability to become the leader of the next round.

Specifically, the processing flow is as follows:

before the next check point consensus, the node which is willing to be a leader uses an encryption drawing algorithm to calculate < hash, proof, j >, and sends a request to all nodes in the channel.

And after other nodes in the channel receive the request, verifying by using parameters such as the public key, the hash value, the proof and the like of the leader candidate node. After the verification is passed, j is calculated and compared with j sent by the candidate node. If they are the same, the record is local.

When the checkpoints are in consensus, the consensus message broadcasted by the leader node of the current round includes the requests of all the leader candidates in the period.

And all nodes in the channel compare the candidate request in the consensus message with the locally received request, and if the verification is passed, the node with the maximum hash value is considered as the leader of the new period.

And if the new leader is down or is badly done, sequentially delaying the leader according to the sequence of the hash values, and starting a new period.

The present invention will be described in detail with reference to the drawings and examples, which take a multi-person payment gateway as an example.

The first is the use scenario of a double payment channel. Fig. 7 is a flow chart of a and B establishing a multi-person channel and conducting a transaction.

Step S1, the channel management module of the client side where a is located calls the account management module of the client side where a is located, and initiates a transaction of opening a channel to the contract on the link, which is marked as < a, value _ a, setup (settleTime, epochTime, delta, consTime, respTime >) >. The method comprises the steps of representing that a user A calls a setup function of a channel contract, locking the fund of value _ A, and setting a constant parameter of a channel, wherein when dispute processing of the channel is set, a challenge window is settleTime, the time of each round in the channel is epochTime, and the time of one period is delta round. Each round includes a transaction and a consensus time. The time for collecting the signature when the check points are identified is consTime, and the response time after the mutual request between the user nodes in the down-link channel is respTime.

Step S1.1, an account management module of the client side where the A is located subtracts value _ A from account fund of the user on the block chain, and adds value _ A to account fund in a channel.

Step S1.2, the contract returns a unique channel identifier channeld for this pen setup channel transaction.

In step S2, node B uses the channel management module and the account management module of the client to initiate a transaction of joining the channel to the contract on the chain, which is denoted as < B, value _ B, lockup (channeld >), indicating that user B wants to join the channel channeld, and locks the fund of value _ B.

Step S2.1, node B sends a request to node a to join the channel, denoted join request (C/D, channeld, value,), indicating that it is requested to join the channel of channeld and that value funds have been locked. Meanwhile, the node A acquires the fund locked in the contract channel by the node B through the monitoring block chain, namely the information of joining the channel, updates the account book state under the chain, records the state as <0, MerkleizedIntervalTree >, which represents the current 0 th round, and represents the balance of the account and the transaction information corresponding to the account by a Merckelized line segment tree (see figure 6 for an example of a data structure). The balance of the account is stored in an account tree through division of line segments; the transaction information corresponding to each account is stored in a transaction tree, wherein the outlying transaction (outlying transfer) is represented by a Mercker tree and the incoming transaction (incoming transfer) is represented by a line segment. A synchronizes the linked down-book state with B.

In step S3, if the number of nodes in the channel is greater than or equal to 2, the process of the downlink transaction in the channel may be started. And (3) establishing a cube for the channel by a leader in the cold starting stage of the default channel, namely automatically setting the role of the role management module of the client side where the A is positioned as the leader and taking charge of maintaining the state of the account book under the chain.

Step S3.1, the sender B transfers accounts to the receiver A, a transaction management module of a client side where the B is located constructs a transaction, the transaction is recorded as < e, B, A, nonce, amount and recipientLeafIndex >, the transaction is shown to occur in the e-th round, the sender B sends amount to the receiver A (the leaf index on the account tree is recipientLeafIndex), the transaction number sent by the sender in the current period is recorded as a nonce (equivalent to the version number of the down-link transaction), and the nonce is sent to the receiver A after signature.

And S3.2, after the transaction processing module of the client side where the receiver A is located receives the transaction, checking the signature of the sender B, judging whether the transfer amount is correct or not, and sending the signature to the sender B under the legal condition.

Step S3.3, the sender B sends the transaction containing the two-party signature to the leader a.

Step S3.4, the leader A checks whether the nonce of the transaction sender is continuously increased and whether the balance is sufficient, namely offset + amount < balance _ B on the account tree; and signing the transaction after the verification is passed, sending the signature to B, and updating the account book state under the chain: adding a leaf node in the transaction entering tree of the account A, recording transaction related information, and reconstructing the Mercker tree; adding new leaf nodes in the transaction tree of the account B, reasonably dividing line segments, and reconstructing a Mercker transaction line segment tree. The reasonable division line segment can be divided according to the balance, for example, the account one balance is 3 blocks, the account two balance is 5 blocks, and the division of the line segment is 0, 3 and 8.

And step S3.5, the client side of the B receives the transaction of the authentication signature of the A, and the state of the account book under the local update chain is the same as that of the A. A and B can carry out any multiple transactions in the ith round.

In step S4, when the consensus time of the current round is reached, the node a broadcasts the ledger status update of this round to the user nodes (only node B at this time) in the downlink channel, which indicates < MerkleizedIntervalTree, e >, i.e. the merkelized line segment tree of the e-th round.

Step S4.1, if B does not receive the ledger status update within respTime, send a request to a and wait for alpha respTime again.

Step s4.1.1, if B still does not receive a reply from a, send a challenge of state update < stateupdatechange (e, leader >) to the chain, indicating that the leader node leader is requested for the ledger state update of the e-th round.

And S4.2, if the B receives the state of the linked account on time, verifying.

In step S4.2.1, if B finds that the down-link account status recorded by a is incorrect, such as the line segment division in the account tree is incorrect, the transaction number in the transaction tree is incorrect, etc., then a challenge of status update error is sent to the chain < stateupdatefauldelezelnterval > (e, leader, faulmelkleizedlntervaltree), which indicates that the leader node leader constructs the incorrect down-link account status faulmelkleizedlntervaltree in the e-th round.

If the linked ledger status is found to be valid, step S4.2.2, the transaction continues. A continues to act as a leader and the lane proceeds to the next round. The flow proceeds to step 3.

The above process describes the process of trading and round consensus within a two-person corridor, followed by an example expansion, joining and exiting of nodes, election of a new leader node, and an explanation of checkpoint consensus. The flow chart is shown in figure 8.

And step S1, performing transaction and consensus between A and B according to turns.

Step S2-1, node C, D, E locks the funds into the tunnel and sends a signed join tunnel request to node a.

Step S2-1.1, A receives the request for joining the channel, verifies the signatures of C, D and E, inquires about the locking condition of the chain fund, and stores the request into a local request list enter (E) under the condition that the locking condition is legal. It should be noted that if multiple nodes are added to the channel, and there is no transaction process yet, other nodes can be added immediately, and the process proceeds to step S2.

And step S3, after delta epochTime, reaching the consensus time of the current period, and starting the two-stage consensus process.

Step S3.1, the node A broadcasts the consensus information of the round to all nodes (only node B at this time) in the channel, < e, MerkleizedInterval Tree, enter (e), Withdraw (e), Candidate (e +1) >. Indicating the e-th round, accounting state update of the a-signature after the processing node joins and exits, and requests to join and exit the node, requests that want to race for the next round leader.

And step S3.2, other nodes verify and synchronize the consensus information.

If a does not broadcast the message on time or B finds that there is still an unprocessed challenge, B initiates a state update challenge stateupdatechange (e, leader) on the chain, step S3.2.1. If B finds that there is invalid item in the consensus message, B sends the challenge of state update error to the chain < stateUpdateFaultChangeE (e, leader, faultMerkletIntervalTree) >.

Step S3.2.2, if B receives the request and there is no challenge that the leader needs to respond to on the chain, after checking the consensus information, it is determined that the consensus information is valid, i.e. the balance of each account in the down-link account status is correctly divided, the transaction executed by each account is correctly recorded in the transaction tree, the signature of the joining node and the locking of the funds on the chain are proper, the fund distribution of the exiting node is reasonable, and there is no double-flower problem. B sends a signature to node a and locally records the latest consensus message.

Step S3.3, A collects the signatures of all nodes in the current channel.

If a has a signature that is not received after consTime (only B at this time), step S3.3.1 initiates a request for a state update signature to the chain, < stateUpdateSignRequest (e, leader) >.

At step S3.3.2, if a receives the signatures of all nodes in consTime, the consensus is completed, and all the user nodes in the downlink channel are considered to have a consistent view of the latest downlink ledger status.

And step S3.4, broadcasting the aggregation signature of the effective nodes to all the nodes in the channel by the A.

At step S3.4.1, if the user node in the downlink channel receives the aggregated signature, the verification is performed. If the verification is passed, the aggregated signature is broadcasted to other nodes, and the next round of transaction is directly entered.

In step S3.4.2, if the user node in the downlink channel does not receive the signature after the consTime, or the signature verification fails (e.g., the number of signatures is insufficient, the signature itself has a problem, etc.), B challenges the state update on the chain < stateupdatechange (e, leader) >.

At step S4, all nodes in the tunnel locally compute the leader of a new round. The importance scores of the candidate nodes are locally computed, and the nodes use the VRF to derive the leader of the next round.

At step S5, the checkpoint consensus completes successfully under the chain, starting a new cycle with a new leader. The node applying for joining the channel can participate in the next round of transaction activity, the node applying for exiting the channel can submit the consensus information to the chain to complete the fund extraction, and the latest fund distribution is recorded on the chain at the moment.

At this time, the nodes in the channel are a, C, D, and E, and the following flow mainly describes the monitoring service processing flow, as shown in fig. 9.

Step S1-1, the elected leader (assuming it is still a) is responsible for the deal in the new period.

And step S1-2, the supervision service node F calls a supervision service intelligent contract to construct a registration transaction, which is expressed as < F, value, Setup () >, and which is expressed as locking a fund value as a guarantee fund to provide service for the outside.

Step S2, after the channel node C completes multiple transactions, it does not need to do transaction until reaching the next check point, and before it wants to go off-line, it establishes the entrusting relationship with the monitoring service party F.

Step S2.1, the channel node C calls a monitoring service intelligent contract to construct an entrusted reservation transaction < C, F, value, Deposit (e _ start, e _ end, channel Id, balance _ e, in _ root, out _ root, hash _ i, time) >, which indicates that C is willing to pay value for the service provided by the service party F, the effective time of the service is the e _ start round, and the service ending time is the e _ end round. C, the balance of the current account tree is balance _ e, the root of the transaction tree is in _ root, the root of the transaction tree is out _ root, and F needs to supervise the on-chain dispute handling event occurring in the channel channelId to maintain the legal benefit of C. And meanwhile, selecting a random number generation hash as a condition for acquiring the service charge C by the F. C needs to provide a receipt within time.

Step S2.1.1 channel node C sends the original value of the hash private to serving node F.

Step S2.1.2, the service node F checks the current node C status, including balance, whether the transaction information is valid, whether the payment amount and service time are appropriate, invokes the monitoring service intelligent contract, constructs the receipt transaction < F, C, hash (deposit), and prime >, which means that F is willing to provide service for C, the concrete content of the service is the hash of the parameters in the C's entrustment reservation transaction, and uses the original value as the unlocking condition, to realize the C locking fund transfer to F in the contract.

At step S3, a dispute occurs within the channel, if leader a does not broadcast the linked ledger status on time. The online node D initiates a state update challenge stateupdatechange (e, leader) onto the chain. The supervisor listens for the down-chain ledger state submitted on the chain by the leader or other parties.

Step S3.1, if the monitoring service node F finds that the balance division of the channel node C in the chain down account book state submitted by the node is incorrect, the transaction tree of the channel node C is changed definitely, the transaction information which is malicious is checked, and the staggered error challenge stateUpdateFaultChanllenge (e, leader, faultMerklezedIntervalTree) is promoted to the chain.

And S3.2, if the offline account state correctly divides the fund of the node C, no response is made, and the latest offline account state is stored.

And step S4, the node C is on line, synchronizes the latest linked account state, and checks whether the monitoring server provides service.

And S4.1, if the fund distribution of the step C is changed on the chain, the service party does not have a protection function, a tracing transaction is constructed, a dispute processing function for monitoring an intelligent contract of the service is called by using the state during delegation, the current state of the linked account book and the receipt information as a voucher, and the guarantee fund is deducted from the service party.

The following is a detailed description of the process flow for the various challenges described herein. The challenges that occur include:

1. the leader node performs malicious activities, including but not limited to broadcasting different accounts to different nodes, missing of transactions in the accounts and the like, punishment needs to be performed in a chain mode, and global consensus is achieved in the chain mode. Expressed as:

stateUpdateFaultChallenge(e,leader,faultMerkleizedIntervalTree,proof>。

the specific treatment method is as follows:

a) the honest node submits the status faultMerkleilizedInterval Tree and proof of the linked account containing the dispute making information to a multi-person channel intelligent contract by calling a triggerDispute method, executes check inside the contract, enters a dispute processing flow once the dispute making is determined, and opens a dispute processing window.

b) Honest nodes submit the linked account status of the ith (i < e) round in a dispute processing window, the status needs to meet the requirement of being nearest to the current round, and the balance of the leader can make up the loss caused by the returned transaction as much as possible.

c) At the end of the dispute handling window, the transition function in the contract selects the most appropriate state to perform the allocation of funds on the chain. The leader node is removed from the set of channel participants, a portion of its funds are divided to the victim node, and a portion are used as the incentive to generate a new leader node.

2. The leader node conducts a malicious operation, and the result is not broadcasted on time, so that the latest account book state of other channel nodes under the chain is prevented from being synchronized; or the leader node needs to exit in advance and needs a chain mode to achieve global consensus. Denoted as stateUpdateChanllenge (e, leader) >. The specific treatment method is as follows:

a) and the nodes request the leader node to submit the linked account state of the e-th round by calling the multi-person channel intelligent contract, enter a request processing flow and start a request processing window.

b) If the leader node does not respond within the request processing window, the stateUpdateFaultChallenge phase may be entered.

c) And after the leader node responds, the contract checks the response validity, judges whether the leader node actively exits after the check is passed, and generates a new leader stage if the leader node actively exits, otherwise, the channel continues to normally operate.

3. And the user nodes in the downlink channel do malicious actions, do not respond on time, feed back signatures and the like. Denoted as < stateUpdateSignRequest (e, leader) >. The specific treatment method is as follows:

a) when the leader node collects the signatures, if any node does not respond within a specified time, the current latest ledger state and the signatures of multiple persons are submitted to the chain, the contract enters a signature request processing flow, and a request processing window is opened.

b) And collecting the signature of the unsigned node in the request processing window, and recording the submitted signature. For nodes that expire with an uncommitted signature, the node is removed from the channel participant set, with funds divided into a channel shared fund pool for intra-channel incentive bonus use.

The following are examples of methods of use corresponding to the above-described apparatus examples, and this embodiment can be implemented in cooperation with the above-described embodiment. The related technical details mentioned in the above embodiments are still valid in this embodiment, and are not described herein again in order to reduce repetition. Accordingly, the related-art details mentioned in the present embodiment can also be applied to the above-described embodiments.

the module 3 comprises:

the module 4 comprises:

Claims

1. A blockchain transaction method based on a multi-person down-link channel is characterized by comprising the following steps:

step 1, a user node initiates a transaction request for opening a downlink channel to the blockchain, the blockchain opens the downlink channel according to the transaction request, the user node serves as a leader to join the downlink channel and is responsible for maintaining the state of the account book under the chain, a plurality of user nodes join the downlink channel through a channel identifier of the downlink channel, and the number of initialization rounds is 0;

2. The blockchain transaction method based on the multi-person downlink channel of claim 1,

3. The method as claimed in claim 2, wherein the step 2 comprises:

4. The method as claimed in claim 1, wherein the step 3 comprises:

5. The method of claim 1, wherein the step 4 comprises:

6. The method as claimed in claim 1, wherein the step 3 further comprises:

7. The blockchain transaction method based on the multi-person downlink channel according to claim 1, further comprising:

8. A blockchain transaction system based on a multi-person down-link channel, comprising:

9. The system of claim 8, wherein the module 2 comprises:

the module 3 comprises:

the module 4 comprises:

10. The system of claim 8, wherein the module 3 further comprises: