A state channel transaction method based on Hub in blockchain

Abstract

The present invention relates to a state channel transaction method based on Hub in a blockchain. On the basis of the blockchain state channel, the concept of a transaction hub Hub is introduced. When a user joins the Hub of the state channel, when both parties of the transaction are online, the users sign transaction and payment transfer information, and send the confirmed transfer information to the Hub, thereby realizing transactions between multiple parties through the Hub; when the transaction recipient is not online, the transaction sender confirms the transaction by signing with the Hub, thereby realizing the transaction between the two parties; the design method transfers the complex calculations and operations in the blockchain to the Hub for execution, thereby realizing rapid processing of transactions, and the design enables the user to join any Hub, and conduct transactions and payment transfers with other users through the Hub, thereby realizing channel transactions between multiple parties, reducing the complexity of network topology, routing and algorithm to a certain extent, and improving the efficiency of state channel transactions.

Description

Technical Field

[0001] The present invention relates to a state channel transaction method based on Hub in a blockchain, and belongs to the technical field of blockchain transactions. Background Art

[0002] Blockchain is an innovative solution that uses distributed ledger technology to solve the trust problem among multiple parties. Through blockchain technology, a trusted distributed system can be established without relying on any third-party trusted institution. However, the current blockchain system performance is seriously insufficient and cannot meet the needs of real business, which greatly limits the development of blockchain.

[0003] Blockchain expansion is an important way to improve the limited processing capacity of blockchain. There are currently two types of expansion solutions. One is the on-chain expansion method, which is to improve the blockchain itself by directly modifying the basic rules of the blockchain. The other is the off-chain expansion method, which aims to transfer the calculation to the off-chain. Instead of directly changing the rules of the blockchain itself, a layer is built on top of it to handle specific transactions, and only interact and transmit information with the blockchain when consensus participation is required. Specific expansion solutions include state channels and side chains. In the off-chain expansion solution, a large number of transactions are usually only carried out between participating nodes, and will not be transmitted throughout the network. The efficiency directly depends on the network performance between nodes, which is obviously more efficient.

[0004] State channels can provide an "instant" transaction - participants do not need to wait for any block confirmation. Lightning Network and Raiden Network are representatives of off-chain expansion solutions, which realize the two-way payment function within the channel and the cross-channel payment function. Users can trade off-chain, making it possible for blockchain to support high-frequency small transactions. Since each state channel in Lightning Network and Raiden Network is only related to two users, their network topology is complex, resulting in difficult routing of cross-channel payments and complex and inefficient algorithms. For example, if there are high-frequency two-way payments between multiple users, and each state channel of Lightning Network and Raiden Network is only applicable to value transfer between two users, most transactions require cross-channel payments or a two-way payment channel is established between any two users, which will result in low transaction performance.

[0005] In the blockchain state channel, each opening and closing of a state channel requires an on-chain transaction to open the state channel. If only one transaction is issued, it will cause a waste of resources and reduce transaction efficiency, which is not suitable for low-frequency operations. In addition, participants in the state channel must remain online at all times. Participants in the state channel need to sign transactions related to themselves and verify transaction records. If they are not online, assets may be lost. The need to be online all the time is an important factor that limits the transaction efficiency of the state channel for participants; at the same time, each state channel is only applicable to value transfers between two users, resulting in most transactions requiring cross-channel payments or establishing a two-way payment channel between any two users, which will lead to low transaction performance. Summary of the invention

[0006] The technical problem to be solved by the present invention is to provide a state channel transaction method based on Hub in blockchain, which conducts transactions and payment transfers with other users through Hub, realizes channel transactions between multiple parties, and improves application efficiency.

[0007] In order to solve the above technical problems, the present invention adopts the following technical solutions: the present invention designs a state channel transaction method based on Hub in blockchain, based on the Hub added in the state channel under the blockchain environment, for N transaction users added in the state channel, multi-party transactions between transaction users are realized, N≥2; in the state channel transaction method, based on the user information set consisting of user ID, user public key, user status, and user account balance corresponding to each transaction user received by the Hub, combined with the initialization state channel transaction number of 0 and the state channel transaction detailed information list being empty, the following steps A to G are performed;

[0008] Step A. Initialize the timer to 0, start the timer, and then go to step B;

[0009] Step B. Determine whether the Hub has not received any instruction from the transaction user before the timer reaches the preset first timeout threshold. If yes, proceed to step F. Otherwise, if the instruction is a transaction instruction, the transaction user who sent the transaction instruction is the transaction sender, and proceed to step C. If the instruction is a closing instruction, proceed to step F. In addition, proceed to step F in other cases.

[0010] Step C. The Hub determines whether there is a user public key in the user information set that is the same as the user public key of the transaction recipient in the transaction instruction. If yes, the user status of the transaction user corresponding to the user public key in the user information set is saved to the user status corresponding to the transaction recipient, and the process proceeds to step D; otherwise, the user status corresponding to the transaction recipient is set to offline, and the process proceeds to step D;

[0011] Step D. The transaction sender encrypts the transaction sender user ID, transaction receiver user ID, transaction amount, transaction payer, and time to generate a transaction identifier TradeID, and sends it to the Hub. The Hub determines whether the balance of the user account corresponding to the transaction payer is less than the transaction amount based on the user information set. If yes, an error message is returned and the process returns to step B; otherwise, the process goes to step E.

[0012] Step E. Based on the Hub, according to the user status corresponding to the transaction recipient, complete the transaction between the two parties corresponding to the transaction identifier TradeID, and update the number of state channel transactions, the list of state channel transaction details, and the user account balances corresponding to the transaction sender and the transaction recipient in the transaction, and then return to step B; at the same time, if there is an error message in the process of completing the transaction, return to step B;

[0013] Step F. Hub makes a judgment on the state channel transaction details list and the number of state channel transactions. If the state channel transaction details list is not empty and the number of state channel transactions is equal to the length of the state channel transaction details list, all transaction records in the state channel transaction details list are hashed and packaged into blocks, and broadcast for blockchain confirmation, and then enter step G; if otherwise, directly enter step G;

[0014] Step G. The Hub modifies the user status of both parties of the transaction to be idle.

[0015] As a preferred technical solution of the present invention: the step E includes the following steps E1 to E4;

[0016] Step E1. Hub determines the user status corresponding to the transaction recipient. If the user status corresponding to the transaction recipient is equal to the idle state, it proceeds to step E2; if the user status corresponding to the transaction recipient is equal to the transaction state or the offline state, it proceeds to step E3;

[0017] Step E2. Hub updates the user status of the transaction recipient to the transaction status. The transaction sender sends the transaction identifier TradeID to the transaction recipient. The transaction recipient verifies the transaction amount in the transaction identifier TradeID. If it is incorrect, an error message is returned and the process returns to step B. If it is correct, the transaction recipient signs the transaction identifier TradeID and returns the signed transaction identifier TradeID to the transaction sender. The transaction sender verifies the signature of the transaction recipient, the transaction amount, the transaction sender user ID, and the transaction recipient user ID in the received transaction identifier TradeID. If the verification is successful, the transaction sender signs the received transaction identifier TradeID and sends the signed transaction identifier TradeID to the Hub. The Hub updates the user status of the transaction recipient to the waiting status and the process goes to step E4. Otherwise, an error message is returned and the process returns to step B.

[0018] Step E3. Hub determines whether the transaction identifier TradeID contains a double signature. If yes, it proceeds to step E4; otherwise, Hub signs the transaction identifier TradeID and returns the signed transaction identifier TradeID to the transaction sender. The transaction sender verifies the transaction amount in the received transaction identifier TradeID. If the verification is successful, the transaction sender signs the received transaction identifier TradeID and sends the signed transaction identifier TradeID to the status channel, and then proceeds to step E4; if the verification fails, an error message is returned and the process returns to step B;

[0019] Step E4. The Hub adds 1 to the number of state channel transactions, and the state channel signs the received transaction identifier TradeID and adds it to the state channel transaction details list according to time. Then the Hub updates the user account balances corresponding to the transaction sender and transaction receiver in this transaction, and then returns to step B.

[0020] As a preferred technical solution of the present invention: at the start time of executing step D, the timer is initialized to 0 and the timer is started. During the process of executing steps D to E, if the transaction is not completed when the timer reaches the preset second timeout threshold, it is directly defined as a timeout and returns to step B.

[0021] As a preferred technical solution of the present invention: constructing combined information for the number of state channel transactions and the list of detailed state channel transaction information, and generating a unique identifier for the combined information, the unique identifier is associated with the combined information to form a state channel identifier; in step G, the Hub modifies the user status of both parties of the transaction to be idle, and clears the cached data of the state channel identifier in the state channel.

[0022] The state channel transaction method based on Hub in blockchain described in the present invention adopts the above technical solution and has the following technical effects compared with the prior art:

[0023] The present invention designs a state channel transaction method based on Hub in blockchain. On the basis of blockchain state channel, the concept of transaction hub Hub is introduced. Users join the Hub of the state channel. When both parties of the transaction are online, the users sign transaction and payment transfer information, and send the confirmed transfer information (commitment transaction) to the Hub, so as to realize the transaction between multiple parties through the Hub; when the transaction recipient is not online, the transaction sender confirms the transaction by signing with the Hub, so as to realize the transaction between the two parties; the design method transfers the complex calculations and operations in the blockchain to the Hub for execution, so as to realize the rapid processing of transactions, and the design enables users to join any Hub, and conduct transactions and payment transfers with other users through the Hub, so as to realize channel transactions between multiple parties, effectively solve the application scenario of high-frequency two-way payment between multiple users, reduce the complexity of network topology, routing and algorithm to a certain extent, and improve the efficiency of state channel transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a flow chart of the Hub-based state channel transaction method in the blockchain designed by the present invention. DETAILED DESCRIPTION

[0025] The specific implementation modes of the present invention will be further described in detail below in conjunction with the accompanying drawings.

[0026] The present invention designs a state channel transaction method based on Hub in blockchain. Based on the Hub added in the state channel under the blockchain environment, multi-party transactions between N transaction users added in the state channel are realized, where N≥2. In the state channel transaction method, according to Figure 1 As shown, based on the user ID and user public key UserPKI corresponding to each transaction user received by Hub i , UserState i 、User account balance UserAmount i The user information set USERINFO = {UserInfo1, UserInfo2, ..., UserInfoN}, UserInfoi = {ID, UserPKIi, UserState i ,UserAmount i}, the state channel "locks" the state of the transaction user Useri on the blockchain in the multi-signature smart contract through the blockchain API, and combines the initialization state channel transaction times as 0 and the state channel transaction details list List as empty, constructs combined information for the state channel transaction times and the state channel transaction details list List, and generates a unique identifier for the combined information, which is associated with the combined information to form the state channel identifier channelID, and executes the following steps A to G to implement the state channel transaction method.

[0027] Step A. Initialize the timer to 0, start the timer, and then go to step B.

[0028] Step B. Determine whether the Hub has not received any instruction from the transaction user before the timer reaches the preset first timeout threshold. If so, proceed to step F; otherwise, if the instruction is a transaction instruction, the transaction user who sends the transaction instruction is the transaction sender User, and proceed to step C; if the instruction is a closing instruction, proceed to step F; in addition, proceed to step F in other cases.

[0029] Step C. Hub determines whether there is a user public key in the user information set that is the same as the user public key of the transaction receiverState in the transaction instruction. If so, the user state of the transaction user corresponding to the user public key in the user information set is saved to the user state corresponding to the transaction receiverState, and the process proceeds to step D; otherwise, the user state corresponding to the transaction receiverState is set to the offline state notOnline, and the process proceeds to step D.

[0030] Step D. The transaction sender senderUser encrypts the transaction sender senderUser user ID, the transaction receiver receiverState user ID, the transaction amount, the transaction payer, and the time to generate a transaction identifier TradeID, and sends it to the Hub. The Hub determines whether the balance of the user account corresponding to the transaction payer is less than the transaction amount based on the user information set. If so, it returns an error message and returns to step B; otherwise, it goes to step E.

[0031] Step E. Based on Hub, according to the user state corresponding to the transaction receiverState, complete the transaction between the two parties corresponding to the transaction identifier TradeID, and update the number of state channel transactions, the state channel transaction details list List, and the user account balances corresponding to the transaction sender senderUser and the transaction receiver receiverState in the transaction, and then return to step B; at the same time, if there is an error message in the process of completing the transaction, return to step B.

[0032] In actual application, the above step E specifically executes the following steps E1 to E4.

[0033] Step E1. Hub determines the user state corresponding to the transaction receiver receiverState. If the user state corresponding to the transaction receiver receiverState is equal to the idle state waiting, then go to step E2; if the user state corresponding to the transaction receiver receiverState is equal to the transaction state trading or the offline state notOnline, then go to step E3.

[0034] Step E2. Hub updates the user state of the transaction receiver State to the transaction state trading. The transaction sender User sends the transaction identifier TradeID to the transaction receiver State. The transaction receiver State verifies the transaction amount in the transaction identifier TradeID. If it is incorrect, an error message is returned and the process returns to step B. If it is correct, the transaction receiver State signs the transaction identifier TradeID and returns the signed transaction identifier TradeID to the transaction sender User. The transaction sender User verifies the signature of the transaction receiver State in the received transaction identifier TradeID, as well as the transaction amount, the transaction sender User user ID, and the transaction receiver State user ID. If the verification is successful, the transaction sender User signs the received transaction identifier TradeID and sends the signed transaction identifier TradeID to the Hub. The Hub updates the user state of the transaction receiver State to the waiting state and the process enters step E4. Otherwise, an error message is returned and the process returns to step B.

[0035] Step E3. Hub determines whether the transaction identifier TradeID contains a double signature. If yes, it goes to step E4; otherwise, Hub signs the transaction identifier TradeID and returns the signed transaction identifier TradeID to the transaction sender senderUser. The transaction sender senderUser verifies the transaction amount in the received transaction identifier TradeID. If the verification is successful, the transaction sender senderUser signs the received transaction identifier TradeID and sends the signed transaction identifier TradeID to the status channel, and then goes to step E4; if the verification fails, an error message is returned and it returns to step B.

[0036] Step E4. Hub adds 1 to the number of state channel transactions, and the state channel signs the received transaction identifier TradeID and adds it to the state channel transaction details list List according to time. Then Hub updates the user account balances corresponding to the transaction sender senderUser and the transaction receiver receiverState in this transaction, and then returns to step B.

[0037] Step F. Hub makes a judgment on the state channel transaction details list List and the number of state channel transactions. If the state channel transaction details list List is not empty and the number of state channel transactions is equal to the length of the state channel transaction details list List, all transaction records in the state channel transaction details list List are hashed and packaged into blocks, and broadcasted for blockchain confirmation, and then enters step G; if otherwise, directly enters step G.

[0038] Step G. The Hub modifies the user status of both parties of the transaction to idle state waiting, and clears the cached data of the state channel identifier channelID in the state channel.

[0039] While the above steps are being executed, it is further designed that at the start time of executing step D, the timer is initialized to 0 and the timer is started. During the execution of steps D to E, if the timer reaches the preset second timeout threshold and the transaction is still not completed, it is directly defined as a timeout and returns to step B. This design, that is, while executing the transaction, introduces a transaction timeout limit design to ensure the security of the transaction process.

[0040] The above technical solution designs a state channel transaction method based on Hub in blockchain. On the basis of blockchain state channel, the concept of transaction hub Hub is introduced. Users join the Hub of the state channel. When both parties of the transaction are online, users sign transaction and payment transfer information, and send the confirmed transfer information (commitment transaction) to the Hub, so as to realize transactions between multiple parties through the Hub; when the transaction recipient is not online, the transaction sender confirms the transaction by signing with the Hub to realize the transaction between the two parties; the design method transfers the complex calculations and operations in the blockchain to the Hub for execution, so as to realize the rapid processing of transactions, and the design allows users to join any Hub, conduct transactions and payment transfers with other users through the Hub, so as to realize channel transactions between multiple parties, reduce the complexity of network topology, routing and algorithm to a certain extent, and improve the efficiency of state channel transactions.

[0041] Since the Lightning Network and the Raiden Network require transaction users and inter-channel users to confirm transactions, the transaction users are required to be online at the same time. In practical applications, the Hub-based state channel transaction method in the blockchain designed by the present invention solves the problem that the transaction recipient is not online through the hub role of the Hub, and finally realizes state channel multi-user transactions, thereby improving the efficiency of state channel transactions.

[0042] The embodiments of the present invention are described in detail above with reference to the accompanying drawings, but the present invention is not limited to the above embodiments, and various changes can be made within the knowledge scope of ordinary technicians in this field without departing from the purpose of the present invention.

Claims

1. A Hub-based state channel transaction method in a blockchain, characterized in that, based on the Hub added in the state channel under the blockchain environment, for N trading users added in the state channel, multi-party transactions among the trading users are realized, N≥2; in the state channel transaction method, based on the user information set composed of the user ID, user public key, user status, and user account balance corresponding to each trading user received by the Hub, combined with the initial state channel transaction times being 0 and the state channel transaction details list being empty, the following steps A to G are executed; Step A. Initialize the timer to 0, start the timer, and then enter Step B; Step B. Before the timer reaches the preset first timeout threshold, determine whether the Hub has not received an instruction from the trading user. If so, enter Step F; otherwise, if the instruction is a transaction instruction, the trading user who sends the transaction instruction is the transaction sender, and enter Step C; if the instruction is a close instruction, enter Step F; in addition, enter Step F in other cases; Step C. The Hub determines whether there is a user public key in the user information set that is the same as the user public key of the transaction recipient in the transaction instruction. If so, save the user status of the transaction user corresponding to the user public key in the user information set to the user status corresponding to the transaction recipient, and enter Step D; otherwise, set the user status corresponding to the transaction recipient to the offline state, and enter Step D; Step D. The transaction sender encrypts the transaction sender user ID, transaction recipient user ID, transaction amount, transaction payer, and time to generate a transaction identifier TradeID, and sends it to the Hub. The Hub determines whether the user account balance corresponding to the transaction payer is less than the transaction amount according to the user information set. If so, return an error message and return to Step B; otherwise, enter Step E; Step E. Based on the Hub, complete the transaction between the two parties corresponding to the transaction identifier TradeID according to the user status corresponding to the transaction recipient, and update the state channel transaction times, state channel transaction details list, and the user account balances corresponding to the transaction sender and transaction recipient in the transaction, and then return to Step B; at the same time, during the process of completing the transaction, if there is an error message, return to Step B; Step F. The Hub makes a judgment on the state channel transaction details list and the state channel transaction times. If the state channel transaction details list is not empty and the state channel transaction times are equal to the length of the state channel transaction details list, then perform a hash operation on all the transaction records in the state channel transaction details list to pack them into a block, broadcast it for blockchain confirmation, and then enter Step G; if it is other cases, directly enter Step G; Step G. The Hub modifies the user status of both transaction parties to the idle state.

2. The Hub-based state channel transaction method in a blockchain according to claim 1, characterized in that: Step E includes the following steps E1 to E4; Step E1. Hub determines the user status corresponding to the transaction recipient. If the user status corresponding to the transaction recipient is equal to the idle state, it proceeds to step E2; if the user status corresponding to the transaction recipient is equal to the transaction state or the offline state, it proceeds to step E3; Step E2. Hub updates the user status of the transaction recipient to the transaction status. The transaction sender sends the transaction identifier TradeID to the transaction recipient. The transaction recipient verifies the transaction amount in the transaction identifier TradeID. If it is incorrect, an error message is returned and the process returns to step B. If it is correct, the transaction recipient signs the transaction identifier TradeID and returns the signed transaction identifier TradeID to the transaction sender. The transaction sender verifies the signature of the transaction recipient, the transaction amount, the transaction sender user ID, and the transaction recipient user ID in the received transaction identifier TradeID. If the verification is successful, the transaction sender signs the received transaction identifier TradeID and sends the signed transaction identifier TradeID to the Hub. The Hub updates the user status of the transaction recipient to the waiting status and the process goes to step E4. Otherwise, an error message is returned and the process returns to step B. Step E3. Hub determines whether the transaction identifier TradeID contains a double signature. If yes, it proceeds to step E4; otherwise, Hub signs the transaction identifier TradeID and returns the signed transaction identifier TradeID to the transaction sender. The transaction sender verifies the transaction amount in the received transaction identifier TradeID. If the verification is successful, the transaction sender signs the received transaction identifier TradeID and sends the signed transaction identifier TradeID to the status channel, and then proceeds to step E4; If the verification fails, an error message is returned and the process returns to step B; Step E4. The Hub adds 1 to the number of state channel transactions, and the state channel signs the received transaction identifier TradeID and adds it to the state channel transaction details list according to time. Then the Hub updates the user account balances corresponding to the transaction sender and transaction receiver in this transaction, and then returns to step B.

3. According to the state channel transaction method based on Hub in blockchain according to claim 1 or 2, Features: At the start time of executing step D, the timer is initialized to 0 and started. During the process of executing steps D to E, if the transaction is not completed when the timer reaches the preset second timeout threshold, it is directly defined as a timeout and returns to step B.

4. According to the state channel transaction method based on Hub in blockchain in claim 1, Features: Combination information is constructed for the number of state channel transactions and the list of detailed state channel transaction information, and a unique identifier is generated for the combination information. The unique identifier is associated with the combination information to form a state channel identifier; in step G, the Hub modifies the user status of both parties of the transaction to be idle, and clears the cached data of the state channel identifier in the state channel.

Images