CN112907252B

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

Info

Publication number: CN112907252B
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: 2023-10-31
Anticipated expiration: 2041-02-02
Also published as: CN112907252A

Abstract

The invention provides a blockchain transaction method and a blockchain transaction system based on a multi-person chain lower channel. The wheel consensus needs to be completed at the end of each round, and the checkpoint consensus is completed at the end of each cycle. In the round consensus stage, a leader sends a result, other nodes voluntarily verify and assist in monitoring service to provide service for the offline node; the check point consensus performs two-stage consensus that all nodes are online, and supports the dynamic joining and exiting of channel nodes. Therefore, the method can accelerate the consensus process, promote the system flux, reduce the risks of delayed discovery of wrongly and excessive transaction withdrawal, and ensure the flexibility of the nodes and the safety of the system.

Description

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

Technical Field

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

Background

The blockchain has the characteristics of distributed, transparent disclosure, safety and the like, so that people can conveniently and quickly exchange value on the Internet at low cost, and the blockchain is a foundation for realizing the value Internet. At the beginning of the generation of blockchain technology, the simplicity and robustness of the blockchain protocol is an initial design premise of the blockchain technology only aiming at the verification and use requirements in a small-range technical community, so that the popularization of the blockchain technology to a wider-range and high-concurrency Internet application is not considered. The nodes in the blockchain network adopt a unified consensus process, so that the characteristics of blockchain safety and decentralization are realized, but the nodes in the whole network copy shared global account book data, and the blockdata containing transaction data are flooded in the whole network, and each consensus node receiving the block needs to verify and store all data, so that the blockchain performance is blocked by the mechanism. Thus, there is a great deal of room for exploring the performance of the lifting blockchain.

The low throughput of blockchains (measured in "number of transactions processed per second by the system", i.e., transactionpersecond, hereinafter referred to as TPS) directly limits its use in real life. In a blockchain network, since the whole network adopts a unified 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 of each node is 1000. Assuming that the validation time of each node for each transaction is about 5ms, the theoretical upper limit on the number of transactions processed per second per node is 200. Then the upper limit on the number of transactions each blockchain network node can receive and validate per second is only around 200, subject to the synchronization mechanism and machine processing performance. In the actual running process, the ethernet house processes 15 transactions per second on average, namely a alliance chain with higher performance, and the average TPS in the production scene is also of the thousand grades. Along with the surge of the transaction amount of the representative public chain system such as the Ethernet, the transaction congestion on the chain is increasingly displayed, and the unacknowledged transaction number of the Ethernet can reach about 15 ten thousand. Congestion makes transaction fees in blockchain networks expensive and even fails to execute when congestion is severe.

In the financial field, the current stage pays treasures, and the WeChat average processes thousands of transactions per second, and the peak value reaches hundreds of thousands of transactions; a common credit card company, a payment card VISA, can handle nearly ten thousand transactions per second, and the validation time of a transaction takes only a few seconds. As can be seen, the throughput and practical application of blockchain systems are greatly different from the centralized transaction solutions of daily use, and thus, increasing blockchain throughput has become an urgent need for blockchain applications today.

At present, in domestic and foreign researches, the scheme for improving the flux of the blockchain is mainly divided into two types of on-chain capacity expansion and under-chain capacity expansion.

On-chain (on-chain) expansion refers to the improvement of expandability by optimizing and improving the basic protocol of a blockchain, and comprises various schemes, wherein the schemes 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 block size or reducing the size of the transaction package in the data layer; the network layer provides a slicing protocol, and the blockchain can process transactions in parallel, so that the blockchain performance is improved. However, under the basic architecture and protocol framework of the blockchain technology, by optimizing parameters (block-out interval, block size) and operation environment parameters (GPU, memory, hard disk, network bandwidth) of the built-in protocol of the blockchain technology, the upper limit of the expected optimization effect can be estimated and cannot reach the flux level of the traditional centralization technology, namely, most of on-chain capacity expansion is limited, hard bifurcation is caused in the capacity expansion upgrading process, and the throughput can be obviously improved by slicing, but the main chain safety is reduced, the protocol is quite complex, and the existing technology is incomplete. Attempts to implement substantial replacement of the underlying protocol on a public-chain system will face dual pressures of technology and communities.

Under-chain (off-chain) expansion does not change the blockchain base protocol and original trust assumptions, and provides lateral expansion capability for the blockchain by placing some operations outside the chain to improve the backbone throughput. The under-chain capacity expansion scheme mainly comprises an off-chain channel and a side chain scheme, wherein the side chains refer to chains parallel to a main chain, the chains can have own consensus mechanisms, the same consensus mechanisms as the main chain are not needed, the side chains are not completely independent, and finally, final settlement is carried out depending on the main chain, so that the under-chain capacity expansion scheme does not have instant terminacy, and the core problem of concern is that business scenes cross the chains, and technical progress is not brought to flux requirements. While the under-link channel has instant terminacy and transaction privacy, it can minimize the on-link operation, so it is widely focused as a promising under-link expansion scheme. The state channel is used as a mainstream under-link capacity expansion protocol and can support different kinds of applications. Specifically, the participants of the application lock up the state on the chain, the participants locally consensus under the chain, and the completion of the consensus can be considered that the state 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 status channel in the payment field, only completes the payment operation of asset transfer, and realizes the transaction with faster speed and lower cost.

The channel types may be divided into two-person channels and multi-person channels according to lockable fund numbers supported in the payment channel.

The double-person channel means that the participants of the channel are two users, after the sender and the receiver lock funds on the chains respectively, the money is fixed on the channel of the two parties, the two parties can trade at will in the channel, the local account book is updated and consensus is carried out, and the double-flower problem is avoided naturally. A comparison is typically made of a lightning network based on the UTXO model and a lightning network based on the account model. For transactions between nodes which are not directly connected in a double channel, one way is that a sender and a receiver lock funds on a chain, a channel is newly built, and two parties perform any multiple transactions. If one channel is needed to be established between each two parties, the interaction with the link is more, the overall overhead of the system is larger, and the purpose of expanding the capacity under the link can not be achieved. Another way is to find a way in the payment channel network, route the transaction through other intermediate nodes, pay one hop by one hop, complete a transaction. The method is influenced by network topology, a routing algorithm and the fund capacity on the path is relatively large, and when the network connectivity is relatively low, the routing path of the cross-channel transaction is relatively long, so that the transaction success rate is reduced, and the problems of channel blockage, channel unbalance and the like exist.

In a general sense, a plurality of persons are allowed to be added into the same channel, the transaction is carried out between any two parties in the channel, but the account book update is carried out globally in the channel, approval of all nodes in the channel is required to be obtained, and one fund can be used for transaction with a plurality of persons, so that the channel is more flexible in fund use, and meanwhile, the double-flower problem is brought. In the multi-person channel, all nodes in the same channel can directly conduct transactions, the nodes add the multi-person channel through one-chain transaction, n one-way connection is established, compared with one-way connection established by one-chain transaction of a double channel, n times of network connectivity is improved, 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 plurality of people channels have a plurality of construction modes, and the problem of how to enable a plurality of people to transfer accounts more conveniently is solved, rather than restricting a transaction object to a specific peer as in a double channel.

A multi-person virtual channel is used as a pseudo multi-person channel, the scheme extends on the basis of a double-person channel, a virtual channel mechanism is applied to construct the multi-person channel, and the multi-person channel is essentially double-person channel, because when funds are locked on a chain, the double-person channel is also used, and the funds are bound on a specific link. Specifically: the multi-person virtual channel includes two types of channels, one is a channel formed by locking funds on a chain and called a ledger channel (hereinafter referred to as a channel), and the other is a virtual channel established based on the existing ledger channel. For example, when the direct transaction of A and C is needed, in order to reduce the overhead on the chain, instead of directly establishing the A to C ledger channel, a part of funds are reserved in the A, B and C channels, so that B is used as an untrusted third party to establish a virtual channel of A and C, the middle node B participates in consensus only when the virtual channel is established and withdrawn, and the transaction can directly occur between A and C. By a multi-person virtual channel is meant that nodes participating in the same multi-party channel are on a directly connected path that is not perceived as being of a specific channel type at the bottom, i.e. a combination of virtual and ledger channels. The scheme uses the virtual channel, expands the original chain channel network, provides a choice for establishing the multiparty channel, but has obvious problems: in order to enable multiple nodes to be on a direct connection path, multiple virtual channels need to be established in a recursion mode, and the mechanism is complex; although the pre-locked fund can relieve the problem of path finding, 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 the malicious condition, except for a head node and a tail node on the path, the funds locked by other intermediate nodes are higher than the actual needs of the intermediate nodes, so that the mobility of the funds is weakened; the scheme does not support the dynamic joining and exiting of nodes, and each state update requires a transaction participating node on one path to agree on, and the throughput is limited by a multi-hop and serial update mode.

Another way is to use smart contracts, when locking funds on a chain, that is, multiple people are locked in a channel, so that after multiple people build a channel, the funds locked on the chain can be traded among multiple people in the channel. The specific scheme comprises the following steps: NOCUST, the system contains verification contracts on the chain and fixed under-chain operators (specially providing transit services of transactions for other nodes in the channel), and the under-chain operators form a star-shaped multi-person channel; each node sends status updates to the operator, which periodically submits transactions to the chain in batches; the node can only send one transaction for a period of time, and the off-link transaction can be continued after the determination. The fixed operators in this scenario introduce a single point of failure; the periodicity and on-chain interactions increase the latency of state updates; and concurrent processing is not supported, so that the effect of under-chain capacity expansion is affected. Gnocchi is used as a multi-person under-chain payment scheme supporting high concurrency, when a multi-person channel is built, a leader is selected by multiple parties under the chain, and the subsequent opening of the channel and the updating of the state in the channel are all responsible for the leader. The leader periodically broadcasts the latest under-link status to user nodes in the under-link channel, and all nodes in the channel check the under-link results. The leader of the scheme is selected in advance, and although the reliability is high, single-point faults still exist; no interactive verification between nodes in the transaction process, so that disfigurement (double flowers) can only be found in a delayed way; in addition, when the node exits, the updating in the channel is suspended, and after the state on the chain is updated, the operation can be continued under the chain, so that the stability and throughput of the channel can be obviously reduced along with the increase of the exit frequency of the node; when the leader is to exit, the whole channel must be closed, which is not friendly to other nodes, not quite reasonable. Garou is a multi-person channel based on a variable center node, the channel does not revolve around a node, and the nodes are all in an equal position. And when each period starts, taking the current balance of all nodes as a random seed, and electing a unique leader of the current round. When the current round is about to end, a two-stage consensus algorithm is executed in the channel, all nodes in the channel agree on the result, and then the next round is entered. The scheme is weakly-centered, and the joining and the exiting of the nodes can be realized in the course of each round of consensus. However, all nodes need to participate in two-stage consensus, and as the number of user nodes in the downlink channel increases, the communication overhead in the channel increases, and the transaction delay increases, so that the consensus efficiency decreases. The mode of replacing the leader in each round can cause stress on some nodes without computing power, and the channel is not available in the case that the rotated leader is not on line.

When the inventor researches the multi-person link down channel, the key advantage of the multi-person link down channel is that a part of funds locked by a user in the channel can be subjected to link down transaction with any user in the channel, so that the mobility of the channel funds is improved, and the channel establishment cost among users is reduced. However, the multiple-person undersea channel introduces the problem of multiple-person status update consistency at the same time, requiring prevention of double spending of funds. The main thought of the existing scheme is to elect a leader in a channel, the leader is responsible for collecting and processing transactions, and a design mechanism agrees with account book updating, so that malicious situations can be detected in time, and the fund safety is ensured. However, the prior art has a great emphasis on mechanism design, and overall, there is still a great improvement space in terms of consensus efficiency and channel stability inside the channel.

From the perspective of consensus efficiency, existing mechanisms can be divided into on-chain and off-chain consensus.

On-chain consensus requires that the leader periodically uplinks transaction information processed in the cycle, implementing the consensus in a manner known per se from the uplinks. However, the trade delay of the consensus method of periodically linking the result is large and expensive trade fees are required, so that more schemes choose the mode of the downlink consensus.

The under-chain consensus refers to the use of some consensus algorithm inside the channel to agree on the result. One solution is to use a two-stage consensus that all nodes need to check the result after the leader broadcasts the result, and if it is legal, the signature on the result needs to be returned to the leader within a specified time, and the leader node considers agreement after collecting the signatures of all nodes. In this way, as the number of user nodes in the downlink channel increases, the communication overhead and the transaction delay in the channel also increase, thereby reducing the consensus efficiency. The other scheme does not require the user nodes in the downlink channel to respond to the result of the synthesis, but only needs to perform uplink processing when a malicious situation is found. There is no special handshake consensus process between nodes, and the leader simply broadcasts the result, thereby accelerating the consensus process. However, when the leader is bad or the network condition is bad, the bad situation is delayed to be found, and the channel is updated and suspended for the dynamic joining and exiting of the node, and the channel can be continuously used after the settlement is carried out on the chain, so that the corresponding cost 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 randomly replaced leader in each round in the selection of the leader. The fixed leader's solution, the channel is continuously managed by the fixed leader from establishment to shutdown, so that its rights in the system are excessive and once the leader goes down, the channel cannot continue to be used. The leader is replaced in each round, and the existing random scheme lacks evaluation on node computing capacity, online service capacity and the like, so that under the conditions that the computing capacity of the selected leader is low, the selected leader is not online and the like, the channel service under the chain cannot be used, the stability of the channel is further damaged, the user experience is seriously influenced, and the safety of the system is endangered.

Disclosure of Invention

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

Aiming at the defects of the prior art, the invention aims to optimize the processing flow of a multi-person chain lower channel of a blockchain and realize the flux and stability improvement of a multi-person chain lower channel system, in particular to a blockchain transaction method based on the multi-person chain lower channel, which comprises the following steps:

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

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

Step 3, initiating an under-chain transaction among user nodes in the under-chain channel within a preset time, a leader carrying out a confirmation signature on the under-chain transaction according to a sender signature and a receiver signature of the under-chain transaction, recording the under-chain transaction into an under-chain account book, returning the confirmation signature to the sender and the receiver, broadcasting an under-chain account book state update to all user nodes in the under-chain channel by the leader after the preset time is reached, adding 1 in number of rounds, and executing the step 2 again;

and 4, the leader sends a check point consensus message containing the state of the chain ledger to all user nodes in the channel, and the user nodes in the channel realize that all the user nodes in the channel achieve a consistent view on the state of the chain ledger by confirming the check point consensus message, and the number of rounds is set to zero, and the step 2 is executed again.

The blockchain transaction method based on the multi-person chain lower channel comprises the following steps of

In the step 1, the user node as a leader joins the link down channel, specifically including:

account funds of the user node on the blockchain are subtracted by value_A, account funds of the user node in the downlink channel are added by value_A, and a contract returns a unique channel identifier for the transaction request;

In the step 1, a plurality of user nodes join the downlink channel through the channel identifier of the downlink channel, which specifically includes:

the user node to be added initiates a transaction of adding the under-chain channel, comprising a channel identifier to be added, locking funds of the user node to be added, updating the state of the under-chain account, representing the balance of the account and transaction information corresponding to the account by a merck line segment tree, and storing the balance of the account in an account tree through dividing the line segment; the transaction information corresponding to each account is stored in a transaction tree, wherein the expenditure transaction is represented by a merck tree, the income transaction is represented by a merck-like line segment tree, and the user nodes in the link down channel synchronize the link down account status with the user nodes to be added.

The blockchain transaction method based on the multi-person chain lower channel comprises the following steps:

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

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

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

the leader broadcasts a check point consensus message to all user nodes in the under-chain channel, including account status updates signed by the leader, requests to join and leave the node, and requests from the competing leader;

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

When the leader receives the signatures of all user nodes in the current channel, an aggregate signature message of all user node signatures is constructed and sent to all user nodes in the channel, the consensus is completed, and all user nodes achieve a consistency view on the latest chain ledger state.

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

and (3) locally calculating importance scores of candidate nodes by all user nodes in the chain channel, and updating the leader by taking the importance scores as weights and adopting an encryption lottery mode.

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

the monitoring service node in the blockchain invokes the intelligent contract of the monitoring service, locks a fund as a guarantee and provides service to the outside;

the user node in the chain channel is used as a commission node to establish commission relation with the supervision service node by using a hash time locking mechanism, and the commission node is offline before executing the step 4;

when a dispute occurs in the chain down channel, submitting a chain down account book state to the chain by initiating a state update challenge, judging whether balance division of the entrusted node in the chain down account book state submitted to the chain is correct by the monitoring service node, if so, storing the latest chain down account book state, otherwise, submitting an error challenge to the chain, and storing the latest chain down account book state after maintaining the benefit of the entrusted node;

And the consignment node is on line, synchronizes the latest chain-down account state, judges whether the fund distribution of the consignment node changes on the chain, constructs a liability-pursuing transaction if the fund distribution of the consignment node changes on the chain, calls a dispute processing function of the monitoring service intelligent contract by taking the chain-down account state and the current chain-down account state as credentials when the consignment relation is established, deducts the guarantee money from the monitoring service node, and otherwise, executes the step 2 to continue the chain-down transaction.

The invention also provides a blockchain transaction system based on the multi-person chain lower channel, which comprises:

the module 1 is used for enabling a user node to initiate a transaction request for opening a link-down channel to a blockchain, the blockchain opens the link-down channel according to the transaction request, the user node is taken as a leader to join the link-down channel and is responsible for maintaining the link-down account state, a plurality of user nodes join the link-down channel through a channel identifier of the link-down channel, and the initialization round number is 0;

the module 2 is used for judging whether the current number of rounds is smaller than a preset value, if yes, the module 3 is called, and if not, the module 4 is called;

a module 3, configured to initiate an under-link transaction between user nodes in the under-link channel within a preset time, where a leader signs a confirmation of the under-link transaction according to a sender signature and a receiver signature of the under-link transaction, logs the under-link transaction into an under-link ledger, returns the confirmation signature to the sender and the receiver, and after the preset time is reached, the leader broadcasts an under-link ledger status update to all user nodes in the under-link channel, adds 1 to the number of rounds, and executes the module 2 again;

The module 4 is configured to enable the leader to send a checkpointed consensus message including a status of the chain ledger to all user nodes in the channel, and the user nodes in the channel implement a consistent view of all user nodes in the channel on the status of the chain ledger by confirming the checkpointed consensus message, and turn the number to zero, and call the module 2 again;

wherein the user node in the module 1 is added to the link down channel as a leader, specifically comprising:

the plurality of user nodes in the module 1 join the downlink channel through the channel identifier of the downlink channel, which specifically includes:

The blockchain transaction system based on the multi-person undersink channel, wherein the module 2 comprises:

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

the module 3 comprises:

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

The module 4 comprises:

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

all user nodes in the link down 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 lottery mode;

the blockchain transaction system based on the multi-person chain lower channel further comprises:

The user node in the chain channel is used as a commission node to establish commission relation with the supervision service node by using a hash time locking mechanism, and the commission node is offline before the module 4 is called;

the consignment node is on line, the latest chain-down account state is synchronized, whether the fund distribution of the consignment node changes on the chain is judged, if yes, a responsibility-pursuing transaction is constructed, the chain-down account state and the current chain-down account state when the consignment relation is established are taken as credentials, a dispute processing function of the intelligent contract of the supervision service is called, the deduction of the guarantee money is carried out on the supervision service node, and otherwise, the module 2 is called, and the chain-down transaction is continued.

The advantages of the invention are as follows:

the current mainstream blockchain technology generally faces the problems of low flux, poor expansibility and the like in an actual service scene. The under-chain channel is used as a capacity expansion scheme with high feasibility, and is very beneficial to flux improvement. Current solutions lack in depth consideration in terms of channel internal consensus efficiency and channel stability. In fact, the core problem of the multi-person channel is how to trade among multiple persons, and how to agree on a period of trade inside the channel by multiple persons, 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 step of evaluating user nodes in the under-chain channel to select a better leader node and provide support for long-term stable operation of the channel.

Drawings

FIG. 1 is a diagram of a multiple person undersea channel system processing architecture;

FIG. 2 is a flow chart of a auditing service;

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

FIG. 3b is a schematic diagram of the system operating phase;

FIG. 4 is a state transition diagram within the under-link channel;

FIG. 5 is a diagram of checkpoint consensus within an under-chain channel;

FIG. 6 is a schematic diagram of a merck-based line segment tree;

FIG. 7 is a flow chart of a two-person payment channel process of the present invention;

FIG. 8 is a flow chart of a multi-person payment channel process of the present invention;

fig. 9 is a flow chart of a auditing service mechanism.

Detailed Description

In order to make the above features and effects of the present invention more clearly understood, the following specific examples are given with reference to the accompanying drawings.

The invention aims to optimize the processing flow of the multi-man chain lower channel of the block chain and realize the flux and stability improvement of the multi-man chain lower channel system. Specifically:

the path setup process allows multiple nodes to join the same path, rather than being limited to transactions between two parties, thereby enabling a locked-in-chain amount of funds to be used between the multiple parties under the chain. The under-chain transaction requires three parties to participate, namely a sender, a receiver and a leader, the three parties can be signed to consider the transaction to be confirmed, and any party can submit a disfiguring evidence to carry out dispute processing on the chain. The node exits, the dispute process is performed on the chain, and security is provided for the under-chain channel.

The under-chain consensus emphasizes strong consistency, the whole system state update takes rounds as the minimum unit, each round is a complete transaction process among nodes, check points are inserted among a plurality of rounds, and the plurality of rounds between the check points and the previous check points form a synchronous period of the whole system. The wheel consensus needs to be completed at the end of each round, and the checkpoint consensus is completed at the end of each cycle. In the round consensus stage, a leader sends a result, other nodes voluntarily verify and assist in monitoring service to provide service for the offline node; the check point consensus performs two-stage consensus that all nodes are online, and supports the dynamic joining and exiting of channel nodes. Therefore, the method can accelerate the consensus process, promote the system flux, reduce the risks of delayed discovery of wrongly and excessive transaction withdrawal, and ensure the flexibility of the nodes and the safety of the system.

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

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

The client manages account information, and management of the assets on the chain and the assets under the chain is achieved. Including transferring account assets on the blockchain to accounts of the undersea channel, transferring account assets in the undersea channel to accounts of the blockchain, and transferring accounts to each other in the undersea channel. The client side needs to complete the function of user interaction with the link up and down, and interaction with the link is realized through the channel management module; the link down interaction mainly completes the sending and receiving of the transaction and is responsible for the transaction processing module. When the user participates in the under-chain activity, the user needs to be responsible for the state of the user in the channel, so that the user plays a role in maintaining the channel state, and the role management module completes the role conversion function according to different participation degrees.

The on-chain block chain layer plays a role in protecting the safety of funds of users under the chain, can accept requests initiated by users, and can monitor messages under the chain to realize the coordination under the chain. Comprising the following steps: the multi-person payment channel service module provides basic supporting capability for normal operation of the multi-person channel and realizes functions of opening and closing the channel, dispute handling, node joining and exiting and the like; the channel monitoring service monitors the dispute handling information on the chain for the offline node under the chain, uploads the state in time, provides value-added service for the offline node, gives the user enough flexibility and provides security.

The under-chain multi-person channel layer mainly unloads load pressure on the chain, and quick and low-cost state conversion among the under-chain accounts is completed. The transaction module is responsible for the transaction state conversion between the two parties in the multi-party channel, and a selected leader checks the legitimacy of the transaction, confirms the transaction and prevents double flowers. It is generally considered that the signed transaction is acknowledged by the sender, receiver and leader, and completed, greatly reducing the latency on the chain. The nodes in the channel can transfer accounts with each other, each node definitely knows the current account book state of other nodes, and a consensus mechanism is used for enabling the nodes in the channel to achieve a consistency view. The consensus process is divided into two types, wheel and check point. The transaction processing process and the consensus process both need the participation of the leader to accelerate the processing process, but the leader needs to be replaced according to the need, including the normal exit of the leader at the 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 a better node.

It should be specifically noted that the process flow of the present invention is applicable to any state type of multi-person channel, including but not limited to a multi-person payment channel, a multi-person application channel, and the like. For simplicity of illustration, the invention is described with respect to a multi-person payment channel.

The specific module design for the three parts is as follows:

client side:

the client side 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 account private keys. Meanwhile, an Elliptic Curve Digital Signature Algorithm (ECDSA) and a Keccak-256 algorithm are used for obtaining the account address corresponding to the private key. Each user may have a different account. The method comprises the steps that an account asset on a blockchain is transferred to an account of an under-chain channel with a channel management module, and the account asset in the under-chain channel is transferred to the account of the blockchain; and completing the transfer of accounts in the under-chain channel with the transaction module.

The channel management module mainly completes the interaction function with the blockchain, and comprises the steps of opening or adding a certain channel, processing disputes in the channel, and participating in the fund dividing process when the channel is closed or exits.

After the node creates or joins the channel through the channel management module, the node can participate in the transaction under the chain by utilizing the transaction processing module. The participant calls a transaction sending module, designates a channel to be transacted and another peer, and completes the transfer operation between accounts in channels of both transaction sides in an under-chain multi-person channel.

The role management module is responsible for managing the ability of the current node to participate in the channel. If only the transaction is simply participated, the channel itself is only required to be maintained, including checking and authenticating each participated transaction, and the latest chain account book state is required to be synchronized during each round of consensus, and the bad situation is fed back to the chain in time. If it is desired to be the leader, further responsibility is placed, including collecting all transactions within the channel, checking and authenticating as an intermediate node for each transaction, signing the endorsement. Thus, as a leader, there may be requirements on the machine performance, on-line time, network conditions, etc. of the node, while as an incentive mechanism, the leader may charge a small amount of transaction fees for each transaction.

On-chain blockchain layer:

the main implementation form on the chain is an intelligent contract, which comprises a module for serving multiple channels and a channel supervision service module for providing offline service for user nodes in the downlink channels.

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

1. opening the channel: and the client node calls the function of opening the channel, establishes a new channel, transfers funds of the blockchain account into the channel account, allocates a unique identifier of the whole network for the channel by contract, and sets channel related parameters such as a time window for dispute processing.

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

2. The addition channel is as follows: a node having frequent transaction requirements with a node within the channel may invoke a join channel function, enter a funds comprising an identifier of the channel, and want to lock in the channel. And sends a request to the leader node.

a) Before the first checkpointing (see below under-chain channel layer-consensus module) begins, a channel building block is used as a leader node during the channel cold start phase, and a message is sent to the channel building block at the time of on-chain registration.

b) If a new leader has been created, the information of the leader node may be stored in any one of the user nodes in the downlink channel, and the current leader node may be queried by the user nodes in the downlink channel, and then a join request may be sent.

3. Dispute handling: when the number of nodes in the channel is more than or equal to 2, the transaction process can be started, once the disliked behavior of the nodes in the running period of the channel is found by honest nodes, the honest nodes call the dispute processing function, the latest information such as account book states approved by all nodes in the channel, evidence disliked by malicious nodes and the like is input, the dispute processing challenge period is entered in the contract, and the nodes under the chain can submit the latest account book states different from the chains to strive for legal rights. When the challenge period ends, the ledger state update is completed on the chain by the contract-specific rules.

4. Exit channel: when the node decides to leave the channel, it needs to complete the transfer of funds from the channel account into the blockchain account. Calling the exit channel function, inputting the information such as the quitable evidence, balance dividing and the like, recording the latest chain account book state after contract verification, removing the node from the channel and completing the transfer.

5. Closing the channel: closing the channel corresponds to all node exit channels.

And the channel monitoring service module. The module is a kind of overtaking third party service, which provides fund security for the on-line or off-line nodes of the multi-person channel, and monitors the information of the channel in the dispute process on the chain. The channel node calls the supervision service module, designates a specific supervision service node, starts the delegation process, and a specific service flow is shown in fig. 2. Specifically:

1. service node registration: the service node needs to lock a guarantee in the monitoring contract first, which means that the service node is registered, and after the registration, a unique service identifier exists in the system. The more funds the service node locks, the more likely it is that the higher the ability to take on risk will be to be selected by the nodes within the channel.

2. The channel node establishes a entrusting relation with the supervision service node: both parties have to agree on a delegate that can be verified and that can be obligated. This process employs a hash time lock mechanism. Specifically:

a) The channel node provides delegated information to the auditing contract, including node state related information: the current latest chain account-down state comprises a timestamp, the merck root of the incoming transaction and the outgoing transaction, the signature of the balance of the node account and the like; service node related information: i.e. the identifier of the server, etc.; service related content: service duration, service fee, etc.; and a hash value obtained by hashing the original value of the secret value, and locking the service fee in the monitoring contract.

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

c) The server checks whether the entrusted content is correct or not, and agrees to the parameters of the service setting or not:

1) If the entrusting requirement is agreed, and within the effective period of the reply, the secret value original value is sent to the supervision contract, the contract pays the service fee to the service party, and the service is opened.

2) If not, then not responding, and the waiting reply time expires, the gateway node may initiate a request to the audit contract to redeem the locked service fee and commit to shutdown.

3. Other honest nodes in the channel can agree on the chain-down account status of each round, and once a malicious event is found, a dispute handling process on the chain is initiated. To prevent malicious nodes from submitting incorrect state updates to the chain and being determined on the chain, resulting in loss of funds to honest nodes, it is necessary for channel nodes to monitor on-chain messages. The supervision service mainly provides a service for monitoring messages on a chain and making feedback:

a) The channel node uses the monitoring service in an online scene, so as to provide double-layer guarantee of fund security, and avoid temporary downtime or other accidents, thereby avoiding observation of disputes on the chain for processing messages.

b) After the channel node is off line, the monitoring service side full right requiring commission provides service according to commission contract, and once the adverse condition to the commission side is found, the proof of the benefit of the commission side is submitted to the on-chain dispute processing process of the channel.

c) It should be noted that if the channel node is not immediately down after delegation, and the latest state is changed due to participation in the consensus process, the latest state needs to be provided to the service node during the down-line.

4. After the channel node is online, the service condition of the monitoring service party is checked, and if the service is objectionable, the dispute processing in the monitoring service contract can be called to punish the service party.

Multiple people under chain channel layer:

the under-chain multi-person channel layer takes the blockchain as an endorsement to realize safe, quick and low-cost transaction. Mainly comprises a transaction module and a consensus module. In order to ensure that the channel is safe and controllable, an auxiliary leader is provided to replace the modules as required. In order to enhance the stability of the channel and maintain good ecology inside the channel, a node evaluation module is provided, the importance of the nodes is calculated, and a better leader is selected.

Transaction module

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

1. the user initiates a downlink transaction at the client, signs the downlink transaction, and sends the downlink transaction to the receiver. Where the transaction includes a transfer transaction, contract call, etc.

2. After receiving the transaction, the receiver checks whether the state change of the transaction is valid, and sends the signed chain off transaction to the sender.

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

It should be noted that step 3 may also be sent by the receiving direction leader, this example being for illustration only. The result of the under-chain transaction process is that a transaction is validated and signed by a three party.

Consensus module

The processing within the chain of channels is calculated in cycles. According to the difference of the consensus pattern, it is divided into a wheel (slot) and a checkpoint (checkpoint). The multiple rounds form a check point, and a period is reserved between the two check points. When checking the point, all nodes are required to be online, the link-down account state occurring in the period is synchronized, and the latest link-down account state is signed and authenticated. The auditing party provides auditing services for the offline nodes of each round. A system operation phase division schematic is shown in fig. 3 b.

And taking the result after the inspection point consensus as an initial state, and entering a trading stage of each round. A round of end-of-link enters a round of consensus phase, so that user nodes in the downlink channel can timely find out the bad situation of a leader node. And after a plurality of wheels, the inspection point consensus is carried out, and the reciprocating cycle is carried out. In-channel ledger status updates are shown in fig. 4.

A round consensus refers to a leader broadcasting the status of the chain ledger including all transactions of this round to all nodes in the channel on a regular basis. The aim is to make the honest node verify the behavior of the leader in a short time in time, so that the malicious situation can be found as early as possible, and too many rollbacks of transactions are avoided.

If the leader is good and the status of the ledger is checked off by the broadcast chain on time according to the rules, the online nodes in the channel can receive the ledger update and verify the ledger update under the condition of good network condition.

If the leader is malicious or the network condition is poor, the online node does not receive the message broadcast by the leader within a predetermined time, and sends a message to the leader to make a request. Once the leader does not respond at the prescribed time, the user node in the under-link channel posts an application to the link asking the leader to broadcast the status update for this round. Once the leader has not fed back within the prescribed time, it can conclude that the leader is bad, raise the dispute process up the chain, and enter the process of passive exit of the leader.

Checkpoint consensus is a consensus that a certain round after going through multiple rounds (or one round) requires that all nodes are online. The method aims at enabling all nodes in the channel to achieve an agreement view on the state of the chain ledger in the channel, processing the joining and exiting requests of the nodes and completing the replacement of the leader. The flow chart is shown in fig. 5:

1. the leader initiates a checkpointing consensus process and sends a checkpointing consensus message to all nodes in the channel, wherein the checkpointing consensus message comprises the current chain ledger state, a joining exit request, a candidate leader request and a channel closing request.

2. And after receiving the account book update, the user node in the link-down channel checks:

a) Without objection, the signature is sent to the leader.

b) And (5) submitting state updates to the chain to perform dispute processing in the presence of objections. Interrupting the consensus within the channel, in turn, enables determination of the current ledger update on the chain.

3. The leader waits for the result of the user node's check of the status of the chain ledger on the link down channel:

a) If the leader receives the signatures of all nodes in the channel in the normal waiting window, the leader considers that all nodes agree on the result, broadcasts the aggregate signatures of all nodes, replaces the leader and enters the next round.

b) And if the leader does not receive the signatures of all nodes in the channel in the normal waiting window, directly initiating a request on the chain, and requiring the non-response node to answer the signature. Nodes that do not submit signatures on time are penalized. In turn, the determination of the current ledger update is implemented on the chain.

Replacing the leader as needed:

the normal exit of the leader at the check point and the early exit are included as required, and the early exit also includes the active exit and the passive exit. Normal exits are lossless, while early exits have an impact on the stability of the channel, thus requiring arbitration on the chain and fines to the leader. Specifically:

1. when the channel contract is actively exited in advance, the leader invokes a leader exit function of the channel contract, and submits the current latest under-chain state update to the chain. If arbitration is done in the chain in accordance with the status of the leader's submission, then a light fine is performed on the leader, such as a proportion of the funds in the channel being fine and prohibited from participating in the transaction or the election leader for a period of time.

2. Passive exit results from poor quality of service of the leader node or a dislike condition occurs, at which time the dislike condition is found by the honest node under the chain, evidence of poor quality of service of the leader node is submitted to the dispute handler of the on-chain channel contract, the contract arbitrates, severe fines are made to the leader, e.g., funds in all channels are deducted, and the channels are evicted.

When the leader exits, a new leader needs to be generated. The new leader node elects to use the encrypted lottery, but takes the importance score of the node as the calculation weight.

The node that wants to become the leader of the r-th round uses the following encryption lottery algorithm locally:

Procedure Sortition(sk _i ,seed _r ,τ,r,w,W):

<hash，proof>←VRF _sk (seed _r ||r)

j++return<hash，proof，j>

wherein sk _i Is the private key of the candidate node, seed _r Is the random number of the r-th round, r is the current round number, τ is the threshold number of candidates expected to enter the final selection, W is the importance score importance of the current node, and W is the importance score sum. The hash value and the proof representing the current node may be calculated using the VRF. p represents the probability that each importance of a node makes it elected. To be used forAs a selection threshold, a selection can be made to satisfyNodes of the condition.

The importance score is provided as follows, wherein the functions f1, f2, f3, f4 represent functions of uniform units, delta, alpha, beta, gamma represent the impact of each term on the importance score. balance device _k Representing the balance of candidate node k at the r-1 th checkpoint; txOutNum _k Is the node in [ r-x, r-1 ]]Is the total number of output transactions, txInNum _k Is the node in [ r-x, r-1 ]]Is the total number of input transactions of (1), txSign is the node at [ r-x, r-1 ]]In addition to self transactions, other signed transaction totals, i.e., nodes select the leader and provide authenticated services to 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, a, B, C all want to be the leader of the next round, if C adds very much funds, but because it has no transaction activity for a period of time, there is a great probability that there is transaction activity for a and B with a small balance when calculating the importance score, and it is the leader of the next round.

Specifically, the process flow is as follows:

the node willing to act as a leader calculates < hash, proof, j > using the encryption lottery algorithm and sends a request to all nodes in the channel before the next checkpointing consensus.

After receiving the request, other nodes in the channel use the public key, hash value, proof and other parameters of the candidate node of the leader to verify. After verification passes j is calculated and compared with j sent by the candidate node. If the same, the record is local.

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

And comparing the candidate request with the locally received request in the consensus message by all nodes in the channel, and judging that the node with the largest hash value passes verification, and selecting the node as a leader of a new period.

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

This section takes the example of a multi-person payment channel, and the invention is further described in detail with reference to the drawings and examples.

First is a usage scenario for a two-person payment channel. Fig. 7 is a flow chart of a and B establishing a multi-person channel and conducting a transaction.

Step S1, a channel management module of the client side where A is located calls an account management module of the client side where A is located, initiates a transaction of opening a channel to a link contract, and is marked as < A, value_A, setup (setletime, epochTime, delta, constTime, respTime) >. The setup function representing the user a invoking the channel contract, locks the funds of value_a, and sets the constant parameters of the channel, including setting the challenge window to settleTime when the channel encounters a dispute, the time per round in the channel to epochTime, and the time per cycle to delta. Each round includes a transaction and a consensus time. The time to collect signatures when checkpoints agree is consttime and the response time after inter-request between user nodes in the link down channel is respTime.

In step S1.1, an account management module of the client side where A is located subtracts value_A from account funds of a user on a blockchain, and adds value_A to account funds in a channel.

In step S1.2, the contract returns a unique channel identifier channelId for this set-up channel transaction.

In step S2, the node B initiates a transaction of joining a channel to the on-link contract using the channel management module and the account management module of the client, denoted as < B, value_b, lockup (channelId) >, indicating that user B is to join the channel id, and locks the funds of value_b.

Step S2.1, node B sends a request to join the channel to node A, denoted as a join request (C/D, channelId, value,) indicating that the channel to join the ChannelId is requested and that the value funds have been locked. Meanwhile, the node A acquires the information that the node B locks funds in the contract channel through monitoring the blockchain, namely, adds the channel, updates the state of the chain account book, and is marked as <0, merkleizer IntervalTree >, the current round 0 is represented, and the balance of the account and the transaction information corresponding to the account are represented by a merck line segment tree (an example of a data structure is shown in FIG. 6). The balance of the account is stored in an account tree through line segment division; transaction information corresponding to each account is stored in a transaction tree, wherein an expenditure transaction (outlgoingtransfer) is represented by the merck tree and a revenue transaction (incoming transfer) is represented by a line segment. And A and B are synchronous to link the state of the account book.

And S3, the number of nodes in the channel is more than or equal to 2, and the under-chain transaction process in the channel can be started. The leader in the default channel cold start stage builds a cube for the channel, namely, the role of the role management module of the client side where the A is located is automatically set as the leader and is responsible for maintaining the chain account book state.

And S3.1, a sender B transfers a money to a receiver A, a transaction management module of a client where the sender B is located constructs a transaction, which is marked as < e, B, A, nonce, amountof the transaction, recollentLeafIndex > -meaning that the transaction occurs in an e-th round, the sender B sends amountof the transaction to the receiver A (the leaf index on the account tree is recollentLeafIndex), and the number of the transaction sent by the sender in the current period is marked as nonce (corresponding to the version number of the under-chain transaction) and is sent to the receiver A after being signed.

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

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

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

And S3.5, the client side where the B is located receives the transaction signed by the authentication A and updates the chain account book state locally as in the case of the authentication A. A and B can conduct any number of transactions in the ith round.

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

Step S4.1, if B does not receive the ledger state 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, then a challenge of state update < stateupdate change (e, leader) >, 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 chain account book state on time, verifying.

If B finds that the link-down ledger state recorded by a is wrong, such as line segment division in the account tree is wrong, transaction number in the transaction tree is wrong, etc., step S4.2.1, a challenge < stateupdatfaultchange (e, leader, faultmerkleizer intersvaltree >) of state update error is sent to the link, indicating that the leader node leader constructs the wrong link-down ledger state faultmerkleizer intersvaltree on the e-th round.

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

The above process describes the process of trading and round-robin consensus within two-person channels, and examples are extended next to illustrate node joining and exiting, electing a new leader node, and checkpointing consensus. The flow chart is shown in fig. 8.

And step S1, executing the transaction and consensus between A and B according to the round.

Step S2-1, nodes C, D, E lock funds into the channel and send a signed join channel request to node a.

Step S2-1.1, A receives the request of joining the channel, verifies the signatures of C, D and E, inquires about the locking condition of funds on the chain, and stores the request into a local request list Enter (E) under the condition that the locking condition of the funds on the chain is legal. It should be noted that if a plurality of nodes are added in the channel, and no transaction process exists yet, then other nodes may be added immediately, and the process proceeds to step S2.

And step S3, after the delta time, the epochTime time reaches the consensus time of the current period, and the two-stage consensus process is started.

In step S3.1, node a broadcasts a consensus message for this round, < e, merklezedIntervalTree, enter (e), withdraw (e), candidate (e+1) >, to all nodes in the tunnel (only node B at this time). Representing round e, processing node joining and exiting, a signed ledger status update, and joining and exiting node requests, requests from the leader of the next round of the campaign.

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

Step S3.2.1, if a does not broadcast a message on time or B finds that there is still an unprocessed challenge, B initiates a state update on the chain challenge statechange (e, leader). If B finds that there is an invalid entry in the consensus message, B sends a status update error challenge < stateUpdateFaultChange (e, leader), faultMerkleizer IntervalTree > on the chain.

Step S3.2.2 if the request is received by the B and there is no challenge to be responded by the leader on the chain, the consensus information is checked and then is considered valid, that is, the balance of each account in the state of the chain ledger 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 funds on the chain are appropriate, the funds of the exiting node are reasonably distributed, and the double-flower problem is avoided. B sends the signature to node a and records the latest consensus message locally.

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

In step S3.3.1, if a has an unreceived signature after consttime (only B at this time), a request to update the signature for status is initiated on the chain, < stateupdatignfequest (e, leader) >.

In step S3.3.2, if a receives signatures of all nodes in the consttime, then consensus is complete, and all user nodes in the under-link channels are considered to have a consistent view of the latest under-link ledger state.

Step S3.4, the A broadcasts the aggregate signature of the valid node to all nodes in the channel.

Step S3.4.1, if the user node in the under-link channel receives the aggregate signature, it performs verification. If the verification is passed, the aggregate signature is broadcast to other nodes and directly enters the next round of transaction.

In step S3.4.2, if the user node in the under-link channel does not receive the signature after the consttime, or does not pass the signature verification (e.g., the number of signatures is insufficient, the signature itself is problematic, etc.), B initiates a state update on the link < stateupdateChallenge >.

Step S4, all nodes in the channel locally calculate a new round of leaders. The importance scores of the candidate nodes are calculated locally, and the nodes use the VRF to derive the leader of the next round.

In step S5, the checkpointing consensus is completed 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 consensus information to the chain to finish the extraction of funds, and the latest funds distribution is recorded on the chain.

At this time, nodes in the channel are a, C, D, and E, and the following flow mainly describes the processing flow of the inspection service, see fig. 9.

Step S1-1, the elected leader (assuming still A) is responsible for the transaction in the new cycle.

And S1-2, the auditing service node F calls an auditing service intelligent contract, constructs a registration transaction, and is expressed as < F, value and Setup () >, and locks a value of fund as a guarantee to provide services to the outside.

Step S2, after the channel node C finishes a plurality of transactions, the transaction is not needed before the next check point is reached, and a entrusting relation is established with the monitoring server F before the next check point is wanted to be off-line.

In step S2.1, the channel node C invokes the auditing service intelligent contract, constructs a delegated reservation transaction < C, F, value, demand (e_start, e_end, channel id, balance_e, in_root, out_root, hash_i, time) >, indicating that C is willing to pay value for the service provided by the service provider F, the effective time of the service is the e_start round, and the end service time is the e_end round. The balance of C on account tree is balance_e, the root of the transaction tree is in_root, the root of the transaction tree is out_root, F needs to supervise the on-chain dispute handling event happening in channel Id, and the legal benefit of C is maintained. And meanwhile, selecting a random number to generate hash as a condition for F to acquire C service charge. C needs to provide a receipt within a time period.

Step S2.1.1 channel node C sends the hashed original value private to service node F.

In step S2.1.2, the service node F checks the status of the current node C, including balance, whether the transaction information is valid, whether the payment amount and the service time are appropriate, invokes the audit service smart contract, constructs a receipt transaction < F, C, hash (demand), private >, indicating that F is willing to provide service for C, and the specific content of the service is a hash of parameters in the delegated reservation transaction of C, using the original value as an unlocking condition, to transfer the C-locked funds to F in the contract.

In step S3, a dispute occurs in the channel, such as that the leader A does not broadcast the chain-down ledger status on time. The online node D initiates a state update challenge stateupdate change (e, leader) >, onto the chain. The supervising party listens to the chain ledger status submitted by the leader or other party on the chain.

In step S3.1, if the auditing service node F finds that there is incorrect balance division for the channel node C in the link-down ledger state submitted by the node, then the transaction tree of C must be changed, the offending transaction information checked, and an error challenge stateupdatfaultchange (e, leader, faultmerkleizer intervaltree) is submitted to the link.

And step S3.2, if the fund division of the node C is correct by the chain ledger state, not responding, and simultaneously storing the latest chain ledger state.

And S4, connecting the node C to the line, synchronizing the latest chain account-down state, and checking whether the monitoring service party provides service or not.

And S4.1, if the fund distribution of the C is changed on the chain, the server is not protected, a responsibility-pursuing transaction is constructed, the state of the consignment is adopted, the current state of the chain accounts-down book is adopted, receipt information is taken as a certificate, a dispute handling function of the intelligent contract of the supervision service is called, and the deposit deduction is carried out on the server.

The following is a detailed description of the processing of the various challenges herein. The cases where challenges occur include:

1. the leader node dislikes, including but not limited to broadcasting different ledgers to different nodes, omission of transactions in the ledgers, etc., requiring penalties in an on-chain manner to achieve global consensus in an on-chain manner. Expressed as:

stateUpdateFaultChallenge(e,leader,faultMerkleizedIntervalTree,proof>。

the specific processing mode is as follows:

a) The honest node submits the chain-down account state faultMerkleizer IntervalTree and proof containing wrought information to the multi-person channel intelligent contract by calling the triggerDisput method, and the contract internally performs checking, and once wrought is determined, the dispute processing flow is entered, and a dispute processing window is opened.

b) The honest nodes submit the chain account book state of the ith (i < e) round in the dispute handling window, the state needs to be closest to the current round, and the balance of the leader can compensate the loss caused by the rolled-back 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, performing the allocation of funds on the chain. The leader node is removed from the channel participant set with a portion of its funds divided into victim nodes and a portion of its funds acting as incentive to create new leader nodes.

2. The leader node acts as a disfigurement, and the result is not broadcast on time, so that other channel nodes are prevented from synchronizing the latest account book state under the chain; or the leader node needs to exit in advance, requiring an on-chain approach to achieve global consensus. Expressed as stateupdatechelle (e, leader) >. The specific processing mode is as follows:

a) The node requests the leader node to submit the chain account book state of the e-th round by calling the multi-person channel intelligent contract, enters a request processing flow and opens a request processing window.

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

c) After the leader node responds, the contract checks the validity of the response, and after the contract passes the check, whether the leader node actively exits is judged, if so, a new leader generation stage is carried out, and if not, the channel continues to normally run.

3. User nodes in the link down channel do nothing, do not respond on time, feed back signatures, etc. Expressed as < stateupdatignrequest (e, leader) >. The specific processing mode is as follows:

a) When the leader node collects the signature, if any node does not respond within a specified time, the current latest account state and the signature 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 without submitting signatures, the nodes are removed from the channel participant set, and their funds are partitioned into a channel shared pool of funds for use in-channel incentive bonus use.

The following is an example of a method of use corresponding to the above-described apparatus example, and this embodiment mode can be implemented in cooperation with the above-described embodiment mode. The related technical details mentioned in the above embodiments are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the related technical 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 undershain channel, comprising:

step 1, a user node initiates a transaction request for opening a link-down channel to the blockchain, the blockchain opens the link-down channel according to the transaction request, the user node is taken as a leader to join the link-down channel and is responsible for maintaining the link-down account state, a plurality of user nodes join the link-down channel through a channel identifier of the link-down channel, and the initialization round number is 0;

step 4, the leader sends a check point consensus message containing the state of the chain ledger to all user nodes in the channel, and the user nodes in the channel achieve a consistent view of all user nodes in the channel on the state of the chain ledger by confirming the check point consensus message, the number of rounds is set to zero, and the step 2 is executed again;

Wherein, in the step 1, the user node is added as a leader to the link down channel, specifically including:

the user node to be added initiates a transaction of adding the under-chain channel, comprising a channel identifier to be added, locking funds of the user node to be added, updating the state of the under-chain account, representing the balance of the account and transaction information corresponding to the account by a merck line segment tree, and storing the balance of the account in an account tree through dividing the line segment; the corresponding transaction information of each account is stored in a transaction tree, wherein the expenditure transaction is represented by a merck tree, the income transaction is represented by a merck line segment tree, and the user nodes in the link down channel and the user nodes to be added synchronize the link down account state;

the step 3 comprises the following steps:

If the leader does not submit the current account book state update to the chain within the set time, the user node initiating the request submits the latest check point consensus message to the chain and requests to punish the leader, so that the capital fine of the leader node is realized, and the capital allocation is divided again on the chain; all user nodes in the link down 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 lottery mode;

the step 4 comprises the following steps:

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

2. The blockchain transaction method based on multi-person undersink channels of claim 1, wherein the step 2 includes:

3. The multi-people chain lower channel based blockchain transaction method of claim 1, further comprising:

4. A blockchain transaction system based on a multi-person undershain channel, comprising:

The module 3 comprises:

the module 4 comprises:

after the check point consensus information is verified by all user nodes, all user nodes send signatures to a leader and record the latest check point consensus information locally;

5. The multi-people chain lower channel based blockchain transaction system of claim 4, wherein the module 2 includes:

6. The multi-person undersea channel based blockchain transaction system of claim 4, further comprising: