A transfer method based on alliance chain

Abstract

The embodiment of the present invention provides a transfer method based on a consortium chain, which includes determining k transaction participating nodes for multiple signatures from each node of the consortium chain through a proof of work mechanism for a transfer transaction of a transaction initiating node in the consortium chain, obtaining random numbers of each transaction node in the transaction node set composed of the transaction initiating node and the k transaction participating nodes from the consortium chain, and generating a signature of the transaction node for the transfer transaction based on the signature mechanism, performing aggregation processing based on the signatures of the transfer transactions of each transaction node through an aggregation node to obtain an aggregate signature, verifying the aggregate signature through a verification node, and executing the transfer transaction after the verification is passed. In this way, the scheme can ensure that the signature capabilities of each selected transaction participating node are relatively strong through the proof of work mechanism, thereby improving the success rate of the aggregate signature, thereby effectively improving the efficiency of the entire transfer transaction.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of financial technology (Fintech), and in particular to a transfer method based on an alliance chain. Background Art

[0002] With the development of computer technology, more and more technologies are being applied in the financial field. Traditional financial industry is gradually transforming into financial technology. However, due to the security and real-time requirements of the financial industry, higher requirements are also placed on technology.

[0003] Multi-signature refers to the situation in which multiple users are required to sign and authenticate the same document or transaction in digital signature applications. For example, a company statement may require the signatures of departments such as Finance, Development, Sales, and After-Sales Service, and these departments must approve the statement.

[0004] With the increasing adoption of multi-signature technology, particularly in the FinTech sector, the need to effectively ensure the quality of financial services through multiple users for multi-signature transactions has become a pressing issue. The existing approach requires that when a node in a consortium blockchain initiates a transfer transaction, multiple nodes must participate in the signature process. Only after multiple nodes have signed the transaction can the transaction be successfully executed. However, this approach often results in lengthy signature processing times, reducing the efficiency of the entire transaction.

[0005] In summary, there is an urgent need for a transfer method based on alliance chain to effectively improve the efficiency of the entire transfer transaction. Summary of the Invention

[0006] In a first aspect, an embodiment of the present invention provides a transfer method based on a consortium chain, comprising:

[0007] For the transfer transaction of the transaction initiating node in the alliance chain, k transaction participating nodes for multi-signature are determined from each node of the alliance chain through the proof of work mechanism;

[0008] For each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, obtain a random number of each transaction node in the transaction node set from the consortium chain, and generate a signature of the transaction node for the transfer transaction based on the signature mechanism;

[0009] The aggregation node aggregates the signatures of the transfer transaction based on the signatures of the transaction nodes to obtain an aggregate signature;

[0010] The aggregate signature is verified by a verification node, and after the verification is passed, the transfer transaction is executed.

[0011] In the above technical solution, because the existing technical solution randomly selects a portion of nodes as transaction participants for the multi-signature transfer transaction, one or more of the selected nodes may have poor computing power, resulting in a long time spent signing the transfer transaction, thereby affecting the efficiency of the entire transfer transaction. Based on this, the technical solution of the present invention, by adding a process for detecting the computing power of the transaction participating nodes, can ensure that the computing power of the multiple nodes selected for the multi-signature transfer transaction is high. This can ensure that the signing efficiency of each transaction participating node is high, and can avoid the problem of long signing time for the transfer transaction, thereby effectively improving the efficiency of the entire transfer transaction. Specifically, for transfer transactions of transaction initiating nodes in the alliance chain, the proof-of-work mechanism can be used to timely and effectively determine the k transaction participating nodes used for multi-signature from each node of the alliance chain. This can prove that the random signature ability of the selected k transaction participating nodes is strong. Then, the transaction node set composed of the k transaction participating nodes and the transaction initiating node will participate in the multi-signature of the transfer transaction, which can effectively improve the efficiency of the signature. That is, when each transaction node signs a transfer transaction, it obtains the random number of each transaction node in the transaction node set, consisting of the transaction initiating node and the k transaction participating nodes, from the consortium chain. Based on the signature mechanism, it generates a signature for the transfer transaction for that transaction node. At the same time, each transaction node sends its signature to the aggregator. This eliminates the need for each transaction node to exchange random numbers. Instead, the random numbers generated by each transaction node are stored on the consortium chain. The random numbers stored on the consortium chain are publicly visible to each transaction node and can be accessed by each transaction node at any time. This reduces the amount of data transmitted between transaction nodes, thereby saving network transmission resources consumed by each transaction node due to exchanging random numbers. After receiving the signatures of the transfer transactions sent by each transaction node, the aggregator aggregates the signatures of each transaction node to obtain an aggregated signature in a timely and accurate manner. The aggregated signature and the transfer transaction are then sent to the verification node. This improves the success rate of the aggregated signature because each transaction node has strong random signature capabilities and promptly participates in signing the transfer transaction. Finally, after receiving the aggregate signature, the verification node verifies it and, upon successful verification, executes the transfer transaction. This solution, through the proof-of-work mechanism, ensures that the signature capabilities of each participating node are strong, thereby improving the efficiency of the aggregate signature and, consequently, the overall transfer transaction.

[0012] Optionally, determining k transaction participating nodes for multi-signature from the nodes of the consortium chain through a proof-of-work mechanism includes:

[0013] Determine m nodes from the nodes of the consortium chain as candidate transaction nodes for multi-signature through a proof-of-work mechanism;

[0014] K candidate transaction nodes are determined from the m candidate transaction nodes as transaction participating nodes.

[0015] In the above technical solution, a part of the nodes in the alliance chain are first selected as candidate transaction nodes through the proof-of-work mechanism. This ensures that the signature capabilities of the selected candidate transaction nodes are relatively strong. However, since not all of the selected candidate transaction nodes are used for multi-signature, at least one candidate transaction node will be randomly selected from the selected candidate transaction nodes to participate in the multi-signature.

[0016] Optionally, determining m nodes from the nodes of the consortium chain as candidate transaction nodes for multi-signature includes:

[0017] Generate a function operation expression for determining candidate transaction nodes, and broadcast the function operation expression to other nodes in the consortium chain except the transaction initiating node; each of the other nodes is used to determine a calculation result based on the function operation expression;

[0018] Verify the calculation results of other nodes, and sort the timestamps of the calculation results of at least one successfully verified node in chronological order, and use the nodes ranked in the top m as candidate transaction nodes.

[0019] In the above technical solution, a difficulty problem is generated and calculated for other nodes in the alliance chain except the transaction initiating node, such as generating a function operation expression for other nodes to calculate, and the calculation results are submitted. The calculation results submitted by each of the other nodes are verified, and the timestamps of the calculation results of at least one successfully verified node (such as the timestamp of the generation of the calculation result or the timestamp of the reception of the calculation result, etc.) are sorted in chronological order, and the nodes ranked in the top m from the at least one verification node after sorting are selected as candidate transaction nodes. In this way, this solution can be used to characterize the computing power of the node. If a node can successfully calculate the calculation result, and the faster the calculation result is calculated, the stronger the computing power of the node is. Then, by sorting the timestamps of the calculation results of at least one successfully verified node in chronological order, at least one node with strong signature capabilities can be accurately selected as a candidate transaction node.

[0020] Optionally, determining k candidate transaction nodes from the m candidate transaction nodes as transaction participating nodes includes:

[0021] Creating an m-order first Vandermonde matrix with a rank of k for determining transaction participating nodes, and performing a hash operation on the transfer amount in the transfer transaction to generate a hash value of the transfer amount;

[0022] Determine m matrix sub-results using the first Vandermonde matrix and the hash value of the transfer amount, and distribute the m matrix sub-results to the m candidate transaction nodes;

[0023] Randomly selecting k rows of matrix values ​​from the first Vandermonde matrix to form a k-order second Vandermonde matrix, and randomly sending notification messages to k candidate transaction nodes among the m candidate transaction nodes; the notification messages are used to instruct the k candidate transaction nodes to submit locally stored matrix sub-results;

[0024] receiving the matrix sub-results submitted by the k candidate transaction nodes, and combining the matrix sub-results of the k candidate transaction nodes to generate a matrix sub-result set;

[0025] Generate a matrix result value using the matrix sub-result set and the k-order second Vandermonde matrix, and determine whether the matrix result value is consistent with the hash value of the transfer amount;

[0026] If so, the k candidate transaction nodes are determined as k transaction participating nodes.

[0027] In the above technical solution, since not all of the m candidate transaction nodes selected are participating in the multi-signature transaction for this transfer transaction, a subset of these nodes must be randomly selected as participating nodes. To enhance the randomness of this selection, k candidate transaction nodes are randomly selected as participating nodes by solving a system of equations based on the Vandermonde matrix. This approach ensures that nodes with lower timestamp rankings among the m candidate transaction nodes are also selected, ensuring a relatively balanced probability of selection across all candidate transaction nodes and avoiding the high probability of selecting only higher-ranked candidate transaction nodes. Furthermore, the matrix sub-result held by each candidate transaction node serves as a certificate of its legal authority to participate in the multi-signature transaction. Nodes with this certificate of authority can participate in the multi-signature transaction for the transfer transaction, thus ensuring the security of transfer transactions within the consortium chain.

[0028] Optionally, before determining k transaction participating nodes for multi-signature from the nodes of the alliance chain through the proof-of-work mechanism, the method further includes:

[0029] The transfer transaction is serialized to generate the serialized transfer transaction.

[0030] In the above technical solution, in order to ensure that the transfer transaction occupies a small volume during transmission and thus save network bandwidth, the transaction initiating node can serialize the transfer transaction, thereby reducing the byte size occupied by the transfer transaction, so that the serialized transfer transaction can be effectively transmitted on the network.

[0031] Optionally, for each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, obtaining a random number of each transaction node in the transaction node set from the consortium chain, and generating a signature of the transaction node for the transfer transaction based on a signature mechanism, including:

[0032] For each transaction node in the transaction node set, the transaction node generates a random number and uploads the random number to the alliance chain;

[0033] The transaction node obtains the random number of each transaction node from the consortium chain, and generates a first obfuscated shard based on the random number of each transaction node;

[0034] The transaction node obtains the public keys of each transaction node from the alliance chain, and aggregates the public keys of each transaction node to generate a first aggregated public key;

[0035] The transaction node generates a signature of the transfer transaction through the random number of the transaction node, the transfer transaction, the first obfuscation shard, the private key of the transaction node, and the first aggregated public key.

[0036] In the above technical solution, since each selected transaction node has relatively strong signing capabilities, the efficiency of signing transfer transactions by each selected transaction node is relatively high, allowing for rapid completion of signatures for transfer transactions. Furthermore, the transaction nodes do not need to exchange their own generated random numbers to complete the signatures for transfer transactions. Instead, each transaction node can upload its own generated random number to the consortium chain for storage. The random number stored on the consortium chain is publicly visible to each transaction node and can be accessed from the consortium chain at any time. This reduces the amount of data transmitted between transaction nodes, thereby helping to conserve network transmission resources consumed by exchanging random numbers. Furthermore, each transaction node in the transaction node cluster generates its own signature for the transfer transaction in parallel based on the signature mechanism, without a sequential order. This means that a transaction node does not need to wait for another transaction node to generate its own signature before generating its own signature.

[0037] Optionally, generating a first obfuscated shard based on the random number of each transaction node includes:

[0038] The transaction node generates a confusing sub-shard of each transaction node based on the random number of the transaction node;

[0039] The transaction node splices the obfuscated sub-shards of the transaction nodes to generate the first obfuscated shard.

[0040] In the above technical solution, the signature mechanism for transfer transactions requires each transaction node to provide its own generated random number in order to accurately complete the signature. This means that when any transaction node signs a transfer transaction, the random numbers from each transaction node must be aggregated. Therefore, this solution processes the random number of each transaction node and the base point on the elliptic cryptographic curve based on its properties to generate a separate obfuscated sub-shard for each transaction node. These obfuscated sub-shards are then concatenated to generate a first obfuscated shard, which supports the subsequent signatures of each transaction node for transfer transactions.

[0041] Optionally, the transaction node generates a signature of the transfer transaction using the random number of the transaction node, the transfer transaction, the first obfuscation shard, the private key of the transaction node, and the first aggregated public key, including:

[0042] The transaction node concatenates the transfer transaction, the first obfuscated shard, and the first aggregated public key to generate obfuscated information, and performs a hash operation on the obfuscated information to generate a hash value of the obfuscated information;

[0043] The transaction node generates a signature of the transfer transaction based on the random number of the transaction node, the private key of the transaction node and the hash value of the obfuscated information.

[0044] In the above technical solution, for each transaction node, the signature for the transfer transaction can be accurately completed by processing according to the random number of the transaction node, the private key of the transaction node, the transfer transaction, the first obfuscated shard and the first aggregated public key.

[0045] Optionally, the aggregation node aggregates the signatures of the transfer transaction based on the signatures of the transaction nodes to obtain an aggregate signature, including:

[0046] The aggregation node receives the signatures of the transfer transactions sent by each transaction node, aggregates the signatures of each transfer transaction, and generates a first signature shard;

[0047] The aggregation node obtains the random number of each transaction node from the alliance chain, and generates a confusing sub-shard of each transaction node according to the random number of the transaction node;

[0048] The aggregation node aggregates the obfuscated sub-shards of the transaction nodes to generate a second signature shard;

[0049] The aggregation node combines the first signature fragment and the second signature fragment to generate an aggregate signature.

[0050] In the above technical solution, after receiving the signatures of the transfer transactions sent by each transaction node, the aggregator node can aggregate the signatures of each transfer transaction to generate the first signature fragment in the aggregate signature. At the same time, the aggregator node can obtain the random numbers generated by each transaction node from the consortium chain, and does not need to send the random numbers generated by each transaction node to the aggregator node. This can reduce the amount of data exchanged between each transaction node and the aggregator node, thereby reducing the network transmission resources consumed by each transaction node and the aggregator node for exchanging random numbers. At the same time, since each transaction node does not send the random number to the aggregator node immediately, and the time of sending the random number to the aggregator node is also different, the time consumed to obtain the random number of each transaction node can be reduced. Then, the aggregator node can promptly generate the second signature fragment in the aggregate signature based on the random number of each transaction node.

[0051] Optionally, verifying the aggregate signature by a verification node, and executing the transfer transaction after the verification is passed, includes:

[0052] The verification node receives the aggregate signature sent by the aggregation node, and obtains the first signature fragment and the second signature fragment from the aggregate signature;

[0053] The verification node obtains the random number of each transaction node from the consortium chain, generates a confusion sub-shard of each transaction node according to the random number of each transaction node, and splices the confusion sub-shards of each transaction node to generate a second confusion shard;

[0054] The verification node obtains the public keys of the transaction nodes from the alliance chain, and aggregates the public keys of the transaction nodes to generate a second aggregated public key;

[0055] The verification node generates a first verification shard based on the first signature shard and the public point of the elliptic curve, and generates a second verification shard based on the second signature shard, the transfer transaction, the second obfuscation shard, and the second aggregated public key;

[0056] Determining, by the verification node, whether the first verification shard is consistent with the second verification shard;

[0057] If so, the verification node deserializes the serialized transfer transaction to obtain the transfer transaction, and executes the transfer transaction.

[0058] In the above technical solution, after receiving the aggregate signature and transfer transaction sent by the aggregation node, the verification node can obtain the first signature shard and the second signature shard from the aggregate signature, and generate the first verification shard through the first signature shard and the public point of the elliptic curve, and generate the second verification shard based on the second signature shard, the transfer transaction, the second obfuscation shard and the second aggregate public key. Then, when it is determined that the first verification shard is consistent with the second verification shard, the serialized transfer transaction will be deserialized to obtain the transfer transaction and execute the transfer transaction. In this way, the transfer transaction can be completed in a timely manner and the security of the transfer transaction can be ensured.

[0059] In a second aspect, an embodiment of the present invention further provides a transfer device based on a consortium chain, comprising:

[0060] a determination unit, configured to determine, for a transfer transaction of a transaction initiating node in a consortium chain, k transaction participating nodes for multi-signature from among the nodes of the consortium chain through a proof-of-work mechanism;

[0061] A processing unit is configured to obtain, from the consortium chain, a random number of each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, and generate a signature of the transaction node for the transfer transaction based on a signature mechanism; perform aggregation processing on the signatures of each transaction node for the transfer transaction through an aggregation node to obtain an aggregate signature; verify the aggregate signature through a verification node, and execute the transfer transaction after the verification is passed.

[0062] Optionally, the determining unit is specifically configured to:

[0063] Determine m nodes from the nodes of the consortium chain as candidate transaction nodes for multi-signature through a proof-of-work mechanism;

[0064] K candidate transaction nodes are determined from the m candidate transaction nodes as transaction participating nodes.

[0065] Optionally, the determining unit is specifically configured to:

[0066] Generate a function operation expression for determining candidate transaction nodes, and broadcast the function operation expression to other nodes in the consortium chain except the transaction initiating node; each of the other nodes is used to determine a calculation result based on the function operation expression;

[0067] Verify the calculation results of other nodes, and sort the timestamps of the calculation results of at least one successfully verified node in chronological order, and use the nodes ranked in the top m as candidate transaction nodes.

[0068] Optionally, the determining unit is specifically configured to:

[0069] Creating an m-order first Vandermonde matrix with a rank of k for determining transaction participating nodes, and performing a hash operation on the transfer amount in the transfer transaction to generate a hash value of the transfer amount;

[0070] Determine m matrix sub-results using the first Vandermonde matrix and the hash value of the transfer amount, and distribute the m matrix sub-results to the m candidate transaction nodes;

[0071] Randomly selecting k rows of matrix values ​​from the first Vandermonde matrix to form a k-order second Vandermonde matrix, and randomly sending notification messages to k candidate transaction nodes among the m candidate transaction nodes; the notification messages are used to instruct the k candidate transaction nodes to submit locally stored matrix sub-results;

[0072] receiving the matrix sub-results submitted by the k candidate transaction nodes, and combining the matrix sub-results of the k candidate transaction nodes to generate a matrix sub-result set;

[0073] Generate a matrix result value using the matrix sub-result set and the k-order second Vandermonde matrix, and determine whether the matrix result value is consistent with the hash value of the transfer amount;

[0074] If so, the k candidate transaction nodes are determined as k transaction participating nodes.

[0075] Optionally, the processing unit is further configured to:

[0076] Before determining k transaction participating nodes for multi-signature from each node of the alliance chain through the proof-of-work mechanism, the transfer transaction is serialized to generate the serialized transfer transaction.

[0077] Optionally, the processing unit is specifically configured to:

[0078] Generate a random number for each transaction node in the transaction node set, and upload the random number to the alliance chain;

[0079] Obtaining a random number of each transaction node from the consortium chain, and generating a first obfuscated shard based on the random number of each transaction node;

[0080] Obtain the public keys of each transaction node from the consortium chain, and aggregate the public keys of each transaction node to generate a first aggregated public key;

[0081] Generate a signature of the transfer transaction using the random number of the transaction node, the transfer transaction, the first obfuscated shard, the private key of the transaction node, and the first aggregated public key.

[0082] Optionally, the processing unit is specifically configured to:

[0083] Generate the obfuscated sub-shard of each transaction node based on the random number of the transaction node;

[0084] The obfuscated sub-shards of the transaction nodes are spliced ​​together to generate the first obfuscated shards.

[0085] Optionally, the processing unit is specifically configured to:

[0086] Concatenating the transfer transaction, the first obfuscated shard, and the first aggregated public key to generate obfuscated information, and performing a hash operation on the obfuscated information to generate a hash value of the obfuscated information;

[0087] Generate a signature for the transfer transaction based on the random number of the transaction node, the private key of the transaction node, and the hash value of the obfuscated information.

[0088] Optionally, the processing unit is specifically configured to:

[0089] Receive the signatures of the transfer transactions sent by each transaction node, aggregate the signatures of each transfer transaction, and generate the first signature shard;

[0090] Obtain the random number of each transaction node from the consortium chain, and generate the obfuscated sub-shard of each transaction node according to the random number of each transaction node;

[0091] Aggregating the obfuscated sub-shards of each transaction node to generate a second signature shard;

[0092] The first signature fragment and the second signature fragment are combined to generate an aggregate signature.

[0093] Optionally, the processing unit is specifically configured to:

[0094] Receiving the aggregate signature sent by the aggregation node, and obtaining a first signature fragment and a second signature fragment from the aggregate signature;

[0095] Obtaining random numbers of each transaction node from the consortium chain, generating obfuscated sub-shards of each transaction node based on the random numbers of each transaction node, and concatenating the obfuscated sub-shards of each transaction node to generate a second obfuscated shard;

[0096] Obtain the public keys of the transaction nodes from the consortium chain, and aggregate the public keys of the transaction nodes to generate a second aggregated public key;

[0097] Generate a first verification shard based on the first signature shard and the public point of the elliptic curve, and generate a second verification shard based on the second signature shard, the transfer transaction, the second obfuscation shard, and the second aggregated public key;

[0098] Determining whether the first verification shard is consistent with the second verification shard;

[0099] If so, deserialize the serialized transfer transaction to obtain the transfer transaction, and execute the transfer transaction.

[0100] In a third aspect, an embodiment of the present invention provides a computing device comprising at least one processor and at least one memory, wherein the memory stores a computer program, and when the program is executed by the processor, the processor executes any of the alliance chain-based transfer methods described in the first aspect above.

[0101] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing a computer program executable by a computing device. When the program runs on the computing device, the computing device executes any of the alliance chain-based transfer methods described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0102] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0103] Figure 1 A schematic diagram of a possible system architecture provided by an embodiment of the present invention;

[0104] Figure 2 A flowchart of a transfer method based on a consortium chain provided by an embodiment of the present invention;

[0105] Figure 3 A schematic diagram of the structure of a transfer device based on a consortium chain provided by an embodiment of the present invention;

[0106] Figure 4 A schematic diagram of the structure of a computing device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0107] To make the objectives, technical solutions, and advantages of the present invention more apparent, the present invention will be further described in detail below with reference to the accompanying drawings. It is apparent that the embodiments described are only some of the embodiments of the present invention, rather than all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0108] First, some terms involved in the embodiments of the present invention are explained below to facilitate understanding by those skilled in the art.

[0109] (1) User account: As a consortium chain account, it is used to identify and distinguish each independent user. Each account corresponds to a pair of public and private keys based on the consortium chain system, and is often referred to as an external account.

[0110] (2) User virtual account: As a digital asset contract-side account, a virtual account public and private key will be created for it on the contract side. The public key is stored on the alliance chain, and the private key is stored outside the alliance chain.

[0111] (3) Aggregation account: As the aggregation account of the alliance chain, it provides signature aggregation and will create virtual account public and private keys for it on the contract side.

[0112] (4) Ledger account: As the subject account on the digital contract side, a verification method for verifying the aggregate signature will be deployed on the contract side to verify the aggregate signature of the transfer transaction and execute the transfer transaction.

[0113] The above describes some of the terms involved in the embodiments of the present invention. The following describes the technical features involved in the embodiments of the present invention.

[0114] In order to facilitate understanding of the embodiments of the present invention, first Figure 1 A possible system architecture shown in FIG is used as an example to illustrate the transfer system architecture based on the alliance chain applicable to the embodiment of the present invention. Figure 1 As shown, the system architecture may include a client 100 and a consortium chain network 200. The consortium chain network 200 may include at least one node, such as node 201, node 202, node 203, node 204, and node 205, and any two of the at least one node may be communicatively connected. The client 100 may communicate with any blockchain node in the consortium chain network 200 via a wired or wireless connection, which is not limited in this embodiment of the present invention.

[0115] For example, when client 100 needs to make a transfer, it usually submits a transfer transaction request to any node (such as node 201) in the alliance chain network 200 in the form of a transaction. When node 201 receives the transfer transaction request, it triggers the selection mechanism of the multi-signature transaction participating node in the alliance chain system. According to this selection mechanism, at least one multi-signature node can be selected from each node in the alliance chain. For example, at least one multi-signature node (such as node 202 and node 203) can be selected from each node in the alliance chain through a proof-of-work mechanism. This transfer transaction mode can also be called a many-to-one transfer transaction mode. Then, nodes 201, 202, and 203 form a transaction node set. Each transaction node in the transaction node set will sign the transfer transaction and send the signature of the transfer transaction to the aggregation node (such as node 204). At the same time, node 201 will also send the transfer transaction to node 204, or node 202 or node 203 can send the transfer transaction to node 204. Node 204 aggregates the signatures of the transfer transactions sent by nodes 201, 202, and 203 to generate an aggregate signature, and sends the aggregate signature and the transfer transaction to a verification node (such as node 205). After verifying the aggregate signature, node 205 executes the transfer transaction.

[0116] It should be noted that the above Figure 1 The system architecture shown is only an example and is not limited in the embodiments of the present invention.

[0117] Based on the above description, Figure 2 The present invention exemplifies a process of a transfer method based on a consortium chain provided in an embodiment of the present invention, which can be executed by a transfer device based on a consortium chain.

[0118] like Figure 2 As shown in the figure, the process specifically includes:

[0119] Step 201: For a transfer transaction of a transaction initiating node in a consortium chain, k transaction participating nodes for multi-signature are determined from the nodes of the consortium chain through a proof-of-work mechanism.

[0120] In an embodiment of the present invention, a user submits a transfer transaction to a node in a consortium chain through a client. This node, acting as the transaction initiator, initiates the transfer transaction. This triggers a proof-of-work mechanism in the consortium chain system for selecting at least one participating node to participate in the multi-signature process for the transfer transaction. This proof-of-work mechanism identifies m nodes from each consortium chain node as candidate multi-signature nodes, and selects k nodes from these m candidate nodes as participating nodes to participate in the multi-signature process for the transfer transaction. This multi-signature model, which requires at least one participating node to participate in the transfer transaction, is also referred to as a many-to-one transfer transaction model. Here, m and k are both integers, and k ≤ m. Specifically, a function expression for determining candidate transaction nodes is generated through the proof-of-work mechanism. This function expression is then broadcast to all other nodes in the consortium chain, excluding the transaction initiator node. Each of these other nodes then computes the function expression, determines a result, and submits the result to the consortium chain system. Upon receiving the result from each node, the consortium chain system generates a timestamp indicating the receipt of the result. Afterwards, the consortium chain system verifies the computation results submitted by each node and sorts the timestamps of the computation results of at least one successfully verified node (such as the computation result generation timestamp or the computation result reception timestamp, etc.) in chronological order. The system then selects the top m nodes from the sorted at least one successfully verified node as candidate transaction nodes. After verifying the success of the computation results submitted by each node, the consortium chain system can store the node and its reception time in a database or data record table. The consortium chain system then sorts the successfully verified nodes in the database or data record table from smallest to largest according to their respective reception timestamps, and selects the top m nodes from the sorted successfully verified nodes as candidate transaction nodes. This scheme can be used to characterize the computing power of a node. If a node can successfully calculate a computation result, and the faster it calculates the result, the stronger the node's computing power. By sorting the timestamps of the computation results of at least one successfully verified node in chronological order, at least one node with strong signing capabilities can be accurately selected as a candidate transaction node. Among them, each node in the alliance chain acts as an independent user, and each node corresponds to a user account, which is used to identify the corresponding node.

[0121] After m candidate transaction nodes are selected, not all of them will be selected as transaction participating nodes. Instead, a subset of them will be selected as transaction participating nodes. However, to avoid the situation where multiple candidate transaction nodes with smaller timestamps (e.g., reception timestamps) (i.e., nodes ranked higher) are always selected as transaction participating nodes from the m candidate transaction nodes, while candidate transaction nodes with larger timestamps (e.g., reception timestamps) (i.e., nodes ranked lower) are less likely to be selected, and to increase the randomness of selecting at least one candidate transaction node from the m candidate transaction nodes as a transaction participating node, at least one candidate transaction node is selected as a transaction participating node by solving the system of equations based on the Vandermonde matrix. Specifically, a rank-k, m-order first Vandermonde matrix (i.e., a Vandermonde matrix with m rows and k columns) is created for the hash value of the transfer amount in the transfer transaction. Specifically, a hash operation is performed on the transfer amount in the transfer transaction to generate a hash value of the transfer amount. A rank-k, m-order first Vandermonde matrix is ​​then created for the hash value of the transfer amount, used to determine the transaction participating nodes. A system of matrix equations constructed using the first Vandermonde matrix and the hash value of the transfer amount can be solved to yield m matrix sub-results, which are then randomly distributed to m candidate transaction nodes. Then, k rows of matrix values ​​are randomly selected from the first Vandermonde matrix to form a k-order, k-row, k-column second Vandermonde matrix. Submission notification messages are then randomly sent to k of the m candidate transaction nodes, enabling these k candidate transaction nodes to promptly submit their locally stored matrix sub-results. After receiving the matrix sub-results submitted by each of the k candidate transaction nodes, the matrix sub-results submitted by the k candidate transaction nodes can be combined to generate a matrix sub-result set. Alternatively, the matrix sub-results of the k candidate transaction nodes can be combined according to the order of the matrix values ​​of the rows in the k-order second Vandermonde matrix corresponding to the matrix sub-results submitted by the k candidate transaction nodes to generate a matrix sub-result set. Finally, a matrix result value is generated using the matrix sub-result set and the k-order second Vandermonde matrix. A determination is then made as to whether the matrix result value is consistent with the hash value of the transfer amount. If they are consistent, the k candidate transaction nodes are determined as k transaction participating nodes. If they are inconsistent, the k candidate transaction nodes are not determined as k transaction participating nodes. This indicates that at least one of the k candidate transaction nodes may be malicious, or at least one node may not be among the m candidate transaction nodes. This at least one node lacks a matrix sub-result, indicating that this at least one node is illegitimate and cannot participate in the signing of the transfer transaction.In this way, this method can ensure that the candidate transaction nodes with later timestamps among the m candidate transaction nodes can also be selected, so as to ensure that the probability of each candidate transaction node being selected is relatively balanced, and it can avoid only selecting the candidate transaction nodes with earlier timestamps with high probability. At the same time, the matrix sub-results owned by each candidate transaction node can be used as the legitimate permission credentials for the candidate transaction node to participate in multi-signature. Nodes with this permission credential can participate in the multi-signature of transfer transactions, so as to ensure the security of transfer transactions in the consortium chain. Among them, after successfully determining k candidate transaction nodes as k transaction participating nodes, the transaction initiating node will send the transfer transaction to these k candidate transaction nodes. In addition, it should be noted that before the transaction initiating node sends the transfer transaction to these k candidate transaction nodes, in order to ensure that the transfer transaction is compact and occupies a small volume during transmission, so as to save network bandwidth, the transaction initiating node can perform serialization processing on the transfer transaction, so as to reduce the byte size occupied by the transfer transaction, so that the serialized transfer transaction can be effectively transmitted on the network.

[0122] Exemplarily, taking a certain node in the consortium chain (that is, a node corresponds to a user account, for example, the user account of a certain node is A) as the transaction initiating node to initiate a transfer transaction that requires multiple nodes to participate. After the transaction initiating node initiates this transfer transaction, the consortium chain system will select several nodes to jointly participate in the signature of this transfer transaction. Suppose the asset transfer behavior information of a total of x quantities sent from the transaction initiating node A to the verification node B can be expressed as E A→Bx , in order to save network bandwidth and help the transfer transaction to be effectively transmitted on the network, it is necessary to use RLP (Recursive Length Prefix, recursive length prefix encoding) to perform serialization processing on the asset transfer behavior information E A→Bx (that is, the transfer transaction), so that the byte size occupied by the asset transfer behavior information is relatively small, so as to save bandwidth and avoid the problem of inconsistent Hash results caused by the too large volume of Json encoding and the data differences of Protobuf binary encoding. Then, the consortium chain system selects k + p candidate transaction nodes from the nodes of the consortium chain through the proof-of-work mechanism, that is, broadcasts a computational difficulty problem to other nodes in the consortium chain except the transaction initiating node. For example, broadcasts a difficulty problem keccak256(rlp(block)||nonce i )<difficulty to other nodes, and other nodes calculate the random number nonce iAmong them, block is used to represent the latest block in the alliance chain, rlp (block) is used to represent the serialization processing of the latest block, difficulty is used to represent the result value of the difficulty problem, the keccak256 algorithm is a hash algorithm, and nonce i It is used to indicate the random value that needs to be calculated by other nodes. Each node submits the calculated random value to the alliance chain system. After receiving the random value submitted by other nodes, the alliance chain system verifies the random value submitted by each node, that is, substitutes the random value submitted by each node into keccak256(rlp(block)||nonce i ), verify keccak256(rlp(block)||nonce i ) is less than the difficulty. After verifying the random values ​​submitted by other nodes, the timestamps of the calculation results of the successfully verified nodes are sorted in chronological order. The top k+p nodes in the sorted order are selected as candidate transaction nodes. The random values ​​calculated by the other nodes will be uploaded to the consortium chain for public disclosure after the current transfer transaction is completed and before the next transfer transaction is initiated, allowing other nodes to verify and raise questions, thereby ensuring the security of the consortium chain system.

[0123] After k+p candidate transaction nodes are selected, not all of them will be used as transaction participating nodes. Instead, a portion of them will be selected as transaction participating nodes. First, a k+p-order Vandermonde matrix with rank k is created to determine the transaction participating nodes. This k+p-order Vandermonde matrix with rank k can satisfy the following form:

[0124]

[0125] Then, a matrix equation system is constructed based on the k+p order Vandermonde matrix of rank k and the hash value of the transfer amount in the transfer transaction, namely F*Matrix=keccak256(C), where keccak256(C) is used to represent the hash value of the transfer amount C in the transfer transaction. The solution set F can be solved through this matrix equation system, that is, k+p matrix sub-results can be solved, namely F=(f1,f2,…,f k+p), and randomly distribute k+p matrix sub-results to k+p candidate transaction nodes. Each candidate transaction node maintains the correspondence between the transfer transaction object and the matrix sub-result locally. In addition, according to the properties of solving the equation system based on the matrix rank (for example, the rank is k), it can be known that k rows of matrix values ​​can be selected from the Matrix to form a new Vandermonde matrix, and the corresponding k matrix sub-results can be obtained, which can be obtained through F k *Matrix k Restore keccak256(C). That is, the alliance chain system can randomly select k rows of matrix values ​​from the Matrix to form a new k-order Vandermonde matrix, and randomly send notification messages to k candidate transaction nodes among the k+p candidate transaction nodes to submit the matrix sub-results, so that the k candidate transaction nodes can promptly obtain the matrix sub-results corresponding to the locally stored transfer transaction object according to the correspondence between the transfer transaction object and the matrix sub-results, and use the public key of the alliance chain system to encrypt the matrix sub-results and submit them to the alliance chain system. After receiving the encrypted matrix sub-results submitted by each of the k candidate transaction nodes, the alliance chain system uses its own private key to decrypt the encrypted matrix sub-results submitted by each of the k candidate transaction nodes, and can combine the decrypted k matrix sub-results to generate a matrix sub-result set, i.e., F k =(f1,f2,…,f k ), or, the decrypted k matrix sub-results can be combined according to the order of the matrix values ​​of each row in the k-order second Vandermonde matrix corresponding to the decrypted k matrix sub-results to generate a matrix sub-result set, that is, F k =(f1,f2,…,f k Then, the matrix result value is generated by the matrix sub-result set and the k-order second Vandermonde matrix, which is F k *Matrix k You can get a matrix result value and determine F k *Matrix k Is it consistent with keccak256(C)? If it is consistent, the k candidate transaction nodes will be determined as k transaction participating nodes. If it is inconsistent, the k candidate transaction nodes will not be determined as k transaction participating nodes. Finally, the transaction initiating node A will transfer the transaction E A→Bx It is sent to the k transaction participating nodes, and a transaction initiating node set T is generated at the same time, that is, T=(T A ,T1,…,T k If the consortium chain system does not receive k matrix sub-results, that is, the number of received matrix sub-results is less than k, it means that there are not enough transaction participating nodes, and the consortium chain system will reject this transfer transaction.

[0126] Step 202: For each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, obtain the random number of each transaction node in the transaction node set from the consortium chain, and generate a signature of the transaction node for the transfer transaction based on the signature mechanism.

[0127] In an embodiment of the present invention, each transaction node in the transaction node set generates a random number and uploads the random number to the consortium chain. Each transaction node obtains the random number of each transaction node from the consortium chain and generates a first obfuscated shard based on the random number of each transaction node. The public key of each transaction node is then obtained from the consortium chain and aggregated to generate a first aggregated public key. A signature for the transfer transaction is then generated using the random number of the transaction node, the transfer transaction, the first obfuscated shard, the private key of the transaction node, and the first aggregated public key. When generating the first obfuscated shard, the transaction node generates obfuscated sub-shards for each transaction node based on the random number of each transaction node and concatenates the obfuscated sub-shards to generate the first obfuscated shard. When signing a transfer transaction, the transaction node concatenates the transfer transaction, the first obfuscation shard, and the first aggregated public key to generate obfuscated information. The obfuscated information is hashed to generate a hash value. The signature of the transfer transaction is then generated based on the transaction node's random number, its private key, and the hash value of the obfuscated information. This ensures that each selected transaction node possesses strong signing capabilities, resulting in high efficiency in signing transfer transactions, enabling rapid and accurate signatures. Furthermore, each transaction node does not need to exchange its own generated random numbers to complete the signature of a transfer transaction; they can be obtained from the consortium chain at any time, thereby reducing the amount of data transmitted between transaction nodes. It should be noted that each transaction node in the transaction node set generates its signature for the transfer transaction in parallel based on the signature mechanism. In other words, each transaction node generates its signature for the transfer transaction in parallel based on the signature mechanism.

[0128] For example, the transaction initiation node set T generated above is used as an example for description. For each transaction node in the transaction initiation node set T, the transaction node generates its own random number through a random number generator, such as a VRF random number (Verifiable Random Function) generator, a VDF function (Verifiable Delay Function) and other random number generation algorithms, and uploads the random number to the alliance chain, where the mapping relationship between the user virtual account number of the transaction node and the random number is maintained. That is, the random number array generated by each transaction node can be expressed as U T =(u A ,u1,…,u k ), then the number of the user virtual account that maintains the transaction node on the alliance chain is acc i With the random number u i The mapping relationship is [acc i :u i Then, for each transaction node in the transaction initiation node set T, the transaction node can obtain the random number generated by each transaction node from the alliance chain according to the virtual account number of each transaction node in the transaction initiation node set T, and generate the confusion sub-shard of each transaction node according to the random number of each transaction node, that is, R i =u i *G. The transaction node splices the obfuscated sub-shards of each transaction node to generate the first obfuscated shard, i.e. At the same time, the transaction node will also obtain the public key of each transaction node from the alliance chain according to the virtual account number of each transaction node in the transaction initiating node set T, and sum the public keys of each transaction node to generate the first aggregate public key, namely pk T =∑ i∈T pk i Finally, each transaction node for the transfer transaction E A→Bx Sign, that is, s i =u i +keccak256(E A→Bx ||R T ||pk T )*sk i , where i∈T, and the signature s i Send it to the aggregation node. At the same time, any transaction node (such as the transaction initiation node) will send the transfer transaction E A→Bx Send to the aggregation node. In this way, each transaction node in the transaction initiating node set T will send its own signature for the transfer transaction to the aggregation node.

[0129] Among them, there are two situations when nodes in the alliance chain system generate public and private keys. One situation is: during the initialization phase of the alliance chain system, each node in the alliance chain generates its own public and private keys, that is, in the initial phase of the alliance chain system, the standard elliptic encryption base curve secp256k1 is deployed, and the base point G is initialized as the starting coordinate G→secp256k1. When each node in the alliance chain joins the alliance chain, it needs to obtain an access certificate from the certification center, and the latest block height on the alliance chain and the user virtual account number will be provided to each node. Then, each node will generate a random number based on the latest block height and the user virtual account number, and use the random number as the private key, that is, sk i =vrf(blockheight+i). Assuming there are N nodes in the alliance chain, then sk N =(sk1,sk2,…,sk i ,…,sk N ). Among them, sk i It is used to represent the private key generated by the i-th node, and vrf is used to represent the random number generation method, which can be generated by any secure pseudo-random generator. For example, each node can choose a 256-bit random number as its own private key. In addition, after each node generates its own private key, it also needs to generate the corresponding public key, that is, through pk i =sk i *G, you can generate the public key corresponding to your own private key. Assuming there are N nodes in the alliance chain, then pk N =(pk1,pk2,…,pk i ,…,pk N ). Among them, pk i It is used to represent the public key generated by the i-th node. Finally, each node uploads its own public key to the alliance chain for storage. The alliance chain will maintain the mapping relationship between the user virtual account number of each node and its own public key, that is, the user virtual account number acc i With the public key pk i The corresponding relationship [acc i :pk i Another scenario is: after generating the transaction node set, each transaction node obtains the access certificate from the authentication center, and at the same time obtains the latest block height on the alliance chain and the number of its own user virtual account, generates a random number based on the latest block height and the number of the user virtual account, and uses the random number as the private key sk i . Moreover, when generating your own private key sk i After that, through pk i =sk i*G, you can generate a public key corresponding to your private key. Then, upload your public key to the alliance chain for storage, and the alliance chain maintains the user's virtual account number acc i With the public key pk i The corresponding relationship [acc i :pk i ].

[0130] In step 203, the aggregation node aggregates the signatures of the transfer transaction based on the signatures of the transaction nodes to obtain an aggregate signature.

[0131] In this embodiment of the present invention, after receiving the signatures of transfer transactions sent by each transaction node, the aggregator node aggregates the signatures of each transfer transaction to generate a first signature fragment. It then obtains the random number of each transaction node from the consortium chain and, based on the random number of each transaction node, generates a corresponding obfuscated sub-shard. These obfuscated sub-shards are then aggregated to generate a second signature fragment. This eliminates the need for each transaction node to send its own generated random number to the aggregator node, thereby reducing the amount of data exchanged between each transaction node and the aggregator node, thereby reducing the network transmission resources consumed by the exchange of random numbers between the transaction nodes and the aggregator node. Finally, the first signature fragment and the second signature fragment are combined to generate an aggregate signature.

[0132] For example, the aggregation account J is used as the aggregation node. When the aggregation account J receives the signature s of the transfer transaction sent by each transaction node, i and transfer transaction E A→Bx After that, the signature s of the transfer transaction sent by each transaction node can be i Perform aggregation processing to generate the first signature fragment, that is, S = ∑ i∈T s i At the same time, the aggregation account J will obtain the random number generated by each transaction node from the alliance chain according to the user virtual account number of each transaction node in the transaction initiation node set T, that is, obtain U T =(u A ,u1,…,u k ), and generate the confusion sub-shard of each transaction node according to the random number of each transaction node, that is, Then, the confusion sub-shards of each transaction node are summed up to generate the second signature shard, that is, R = ∑ i∈T R i Then, the aggregation account J will aggregate the signature (S, R) and the transfer transaction E A→Bx Sent to the verification node.

[0133] Step 204: Verify the aggregate signature through a verification node, and execute the transfer transaction after the verification is passed.

[0134] In an embodiment of the present invention, after receiving the aggregate signature from the aggregator, the verification node can obtain the first signature fragment and the second signature fragment from the aggregate signature. It then obtains the random number of each transaction node from the consortium chain and, based on the random number of each transaction node, generates an obfuscated sub-fragment for each transaction node. These obfuscated sub-fragments are then concatenated to generate a second obfuscated fragment. Simultaneously, the public key of each transaction node is obtained from the consortium chain and aggregated to generate a second aggregated public key. Then, based on the first signature fragment and the public point of the elliptic curve, a first verification fragment is generated. Furthermore, based on the second signature fragment, the transfer transaction, the second obfuscated fragment, and the second aggregated public key, a second verification fragment is generated. Finally, the consistency between the first and second verification fragments is determined. If they are consistent, the serialized transfer transaction is deserialized to obtain the transfer transaction and executed. If they are inconsistent, the serialized transfer transaction is not deserialized and therefore not executed. In this way, the solution can complete the transfer transaction in a timely manner and ensure the security of the transfer transaction.

[0135] For example, let account B be the verification node. Account B receives the aggregate signature (S, R) and transfer transaction E from aggregate account J. A→Bx After that, the signature fragment S and signature fragment R can be obtained from the aggregate signature (S, R). At the same time, the random number generated by each transaction node can be obtained from the alliance chain according to the user virtual account number of each transaction node in the transaction initiation node set T, that is, U T =(u A ,u1,…,u k ), and obtain the public key of each transaction node from the alliance chain according to the number of the user virtual account of each transaction node in the transaction initiating node set T, that is, PK T =(pk1,pk2,…,pk k ). Then, the confusion sub-shards of each transaction node are generated according to the random numbers of each transaction node, namely R i =u i *G, and concatenate the obfuscated sub-shards of each transaction node to generate the second obfuscated shard, i.e. And the public keys of each transaction node are summed to generate the second aggregate public key, namely pk T ′=∑ i∈T pk i Then, the signature fragment S is multiplied with the public point G of the elliptic curve to generate the first verification fragment, namely S*G, and the signature fragment R, the transfer transaction E A→Bx , the second obfuscated fragment R T′ and the second aggregate public key pk T ' is processed to generate the second verification fragment, namely R+keccak256(E A→Bx ||R T ′||pk T ′)*pk T ′. Finally, verify that S*G is the same as (R+keccak256(E A→Bx ||R T ′||pk T ′)*pk T ′) are equal, if they are equal, then the ledger account B will transfer the transaction E A→Bx After deserialization, the transfer transaction can be obtained and executed, so that the transfer transaction can be completed in time. At the same time, after the transfer transaction is completed, the temporary storage of [acc i :pk i ] and [acc i :u i ].

[0136] For example, suppose there are two transaction nodes in the transaction initiation node set T, namely transaction node 1 and transaction node 2. The random number generated by transaction node 1 is u1, and R1 = u1*G is generated based on the random number; the random number generated by transaction node 2 is u2, and R2 = u2*G is generated based on the random number. At the same time, suppose that the signature of transaction node 1 for the transfer transaction is s1, namely s1 = u1 + keccak256 (E A→Bx ||R T ||pk T )*sk1, the signature of transaction node 2 for the transfer transaction is s2, that is, s2=u2+keccak256(E A→Bx ||R T ||pk T )*sk2, where R T =(R1||R2), pk T =pk1+pk2, pk1=sk1G, pk2=sk2G, after the aggregation account J aggregates the signatures sent by transaction node 1 and transaction node 2, it generates a signature fragment S=s1+s2, and adds the confusion sub-fragments of transaction node 1 and transaction node 2 to generate R=R1+R2, and then adds the aggregate signature (S, R) and the transfer transaction E A→Bx Sent to account B. Account B receives the aggregate signature (S, R) and transfer transaction E from aggregate account J. A→BxAfter that, the signature fragment S and signature fragment R can be obtained from the aggregate signature (S, R), and the signature fragment S is multiplied with the public point G of the elliptic curve, that is, the first verification fragment S*G=(s1+s2)*G=(u1+keccak256(E A→Bx ||R T ||pk T )*sk1+u2+keccak256(E A→Bx ||R T ||pk T )*sk2)*G=((u1+u2)+(sk1+sk2)*keccak256(E A→Bx ||R T ||pk T ))*G=(u1G+u2G)+(sk1G+sk2G)*keccak256(E A→Bx ||R T ||pk T )=(R1+R2)+(pk1+pk2)*keccak256(E A→Bx ||R T ||pk T )=R+keccak256(E A→Bx ||R T ||pk T )*pk T .

[0137] In addition, by splitting the signature R and the transfer transaction E A→Bx , the second obfuscated fragment R T ′ and the second aggregate public key pk T ' is processed to generate the second verification fragment, namely R+keccak256(E A→Bx ||R T ′||pk T ′)*pk T '. In this way, it is possible to verify whether the first verification shard is consistent with the first verification shard, thereby determining whether a transfer transaction needs to be executed.

[0138] The above embodiments demonstrate that, because existing technical solutions randomly select a portion of nodes as participants in a multi-signature transaction for a transfer transaction, one or more of these selected nodes may have poor computing power, resulting in a long time spent signing the transfer transaction, thus affecting the efficiency of the entire transfer transaction. Based on this, the technical solution of the present invention, by adding a process for detecting the computing power of the transaction participating nodes, can ensure that the computing power of the multiple nodes selected for the multi-signature transaction is high. This ensures that each participating node has high signing efficiency for the transfer transaction, avoids the problem of long signing time for the transfer transaction, and effectively improves the efficiency of the entire transfer transaction. Specifically, for transfer transactions of transaction initiating nodes in the alliance chain, the proof-of-work mechanism can be used to timely and effectively determine the k transaction participating nodes used for multi-signature from each node of the alliance chain. This can prove that the random signature ability of the selected k transaction participating nodes is strong. Then, the transaction node set composed of the k transaction participating nodes and the transaction initiating node will participate in the multi-signature of the transfer transaction, which can effectively improve the efficiency of the signature. That is, when each transaction node signs a transfer transaction, it obtains the random number of each transaction node in the transaction node set, consisting of the transaction initiating node and the k transaction participating nodes, from the consortium chain. Based on the signature mechanism, it generates a signature for the transfer transaction for that transaction node. At the same time, each transaction node sends its signature to the aggregator. This eliminates the need for each transaction node to exchange random numbers. Instead, the random numbers generated by each transaction node are stored on the consortium chain. The random numbers stored on the consortium chain are publicly visible to each transaction node and can be accessed by each transaction node at any time. This reduces the amount of data transmitted between transaction nodes, thereby saving network transmission resources consumed by each transaction node due to exchanging random numbers. After receiving the signatures of the transfer transactions sent by each transaction node, the aggregator aggregates the signatures of each transaction node's transfer transactions to obtain an aggregated signature in a timely and accurate manner. The aggregated signature and the transfer transaction are then sent to the verification node. This improves the success rate of the aggregated signature because each transaction node has strong random signature capabilities and promptly participates in signing the transfer transaction. Finally, after receiving the aggregate signature, the verification node verifies it and, upon successful verification, executes the transfer transaction. This solution, through the proof-of-work mechanism, ensures that the signature capabilities of each participating node are strong, thereby improving the efficiency of the aggregate signature and, consequently, the overall transfer transaction.

[0139] Based on the same technical concept, Figure 3An embodiment of the present invention provides an exemplary embodiment of a transfer device based on a consortium chain, which can execute the process of a transfer method based on a consortium chain.

[0140] like Figure 3 As shown, the device includes:

[0141] A determination unit 301 is configured to determine, for a transfer transaction initiated by a transaction initiating node in a consortium chain, k transaction participating nodes for multi-signature from among the nodes of the consortium chain through a proof-of-work mechanism;

[0142] The processing unit 302 is configured to obtain, from the consortium chain, a random number of each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, and generate a signature of the transaction node for the transfer transaction based on a signature mechanism; perform aggregation processing on the signatures of each transaction node for the transfer transaction through an aggregation node to obtain an aggregate signature; verify the aggregate signature through a verification node, and execute the transfer transaction after the verification is passed.

[0143] Optionally, the determining unit 301 is specifically configured to:

[0144] Determine m nodes from the nodes of the consortium chain as candidate transaction nodes for multi-signature through a proof-of-work mechanism;

[0145] K candidate transaction nodes are determined from the m candidate transaction nodes as transaction participating nodes.

[0146] Optionally, the determining unit 301 is specifically configured to:

[0147] Generate a function operation expression for determining candidate transaction nodes, and broadcast the function operation expression to other nodes in the consortium chain except the transaction initiating node; each of the other nodes is used to determine a calculation result based on the function operation expression;

[0148] Verify the calculation results of other nodes, and sort the timestamps of the calculation results of at least one successfully verified node in chronological order, and use the nodes ranked in the top m as candidate transaction nodes.

[0149] Optionally, the determining unit 301 is specifically configured to:

[0150] Creating an m-order first Vandermonde matrix with a rank of k for determining transaction participating nodes, and performing a hash operation on the transfer amount in the transfer transaction to generate a hash value of the transfer amount;

[0151] Determine m matrix sub-results using the first Vandermonde matrix and the hash value of the transfer amount, and distribute the m matrix sub-results to the m candidate transaction nodes;

[0152] Randomly selecting k rows of matrix values ​​from the first Vandermonde matrix to form a k-order second Vandermonde matrix, and randomly sending notification messages to k candidate transaction nodes among the m candidate transaction nodes; the notification messages are used to instruct the k candidate transaction nodes to submit locally stored matrix sub-results;

[0153] receiving the matrix sub-results submitted by the k candidate transaction nodes, and combining the matrix sub-results of the k candidate transaction nodes to generate a matrix sub-result set;

[0154] Generate a matrix result value using the matrix sub-result set and the k-order second Vandermonde matrix, and determine whether the matrix result value is consistent with the hash value of the transfer amount;

[0155] If so, the k candidate transaction nodes are determined as k transaction participating nodes.

[0156] Optionally, the processing unit 302 is further configured to:

[0157] Before determining k transaction participating nodes for multi-signature from each node of the alliance chain through the proof-of-work mechanism, the transfer transaction is serialized to generate the serialized transfer transaction.

[0158] Optionally, the processing unit 302 is specifically configured to:

[0159] Generate a random number for each transaction node in the transaction node set, and upload the random number to the alliance chain;

[0160] Obtaining a random number of each transaction node from the consortium chain, and generating a first obfuscated shard based on the random number of each transaction node;

[0161] Obtain the public keys of each transaction node from the consortium chain, and aggregate the public keys of each transaction node to generate a first aggregated public key;

[0162] Generate a signature of the transfer transaction using the random number of the transaction node, the transfer transaction, the first obfuscated shard, the private key of the transaction node, and the first aggregated public key.

[0163] Optionally, the processing unit 302 is specifically configured to:

[0164] Generate the obfuscated sub-shard of each transaction node based on the random number of the transaction node;

[0165] The obfuscated sub-shards of the transaction nodes are spliced ​​together to generate the first obfuscated shards.

[0166] Optionally, the processing unit 302 is specifically configured to:

[0167] Concatenating the transfer transaction, the first obfuscated shard, and the first aggregated public key to generate obfuscated information, and performing a hash operation on the obfuscated information to generate a hash value of the obfuscated information;

[0168] Generate a signature for the transfer transaction based on the random number of the transaction node, the private key of the transaction node, and the hash value of the obfuscated information.

[0169] Optionally, the processing unit 302 is specifically configured to:

[0170] Receive the signatures of the transfer transactions sent by each transaction node, aggregate the signatures of each transfer transaction, and generate the first signature shard;

[0171] Obtain the random number of each transaction node from the consortium chain, and generate the obfuscated sub-shard of each transaction node according to the random number of each transaction node;

[0172] Aggregating the obfuscated sub-shards of each transaction node to generate a second signature shard;

[0173] The first signature fragment and the second signature fragment are combined to generate an aggregate signature.

[0174] Optionally, the processing unit 302 is specifically configured to:

[0175] Receiving the aggregate signature sent by the aggregation node, and obtaining a first signature fragment and a second signature fragment from the aggregate signature;

[0176] Obtaining random numbers of each transaction node from the consortium chain, generating obfuscated sub-shards of each transaction node based on the random numbers of each transaction node, and concatenating the obfuscated sub-shards of each transaction node to generate a second obfuscated shard;

[0177] Obtain the public keys of the transaction nodes from the consortium chain, and aggregate the public keys of the transaction nodes to generate a second aggregated public key;

[0178] Generate a first verification shard based on the first signature shard and the public point of the elliptic curve, and generate a second verification shard based on the second signature shard, the transfer transaction, the second obfuscation shard, and the second aggregated public key;

[0179] Determining whether the first verification shard is consistent with the second verification shard;

[0180] If so, deserialize the serialized transfer transaction to obtain the transfer transaction, and execute the transfer transaction.

[0181] Based on the same technical concept, an embodiment of the present invention further provides a computing device, such as Figure 4 As shown, it includes at least one processor 401 and a memory 402 connected to the at least one processor. The embodiment of the present invention does not limit the specific connection medium between the processor 401 and the memory 402. Figure 4 For example, the processor 401 and the memory 402 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, and the like.

[0182] In an embodiment of the present invention, the memory 402 stores instructions that can be executed by at least one processor 401. By executing the instructions stored in the memory 402, the at least one processor 401 can execute the steps included in the aforementioned alliance chain-based transfer method.

[0183] Among them, the processor 401 is the control center of the computing device. It can use various interfaces and lines to connect various parts of the computing device, and realize data processing by running or executing instructions stored in the memory 402 and calling data stored in the memory 402. Optionally, the processor 401 may include one or more processing units. The processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, etc., and the modem processor mainly processes the issuance of instructions. It is understandable that the above-mentioned modem processor may not be integrated into the processor 401. In some embodiments, the processor 401 and the memory 402 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0184] Processor 401 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic diagrams disclosed in the embodiments of the present invention. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiment of the consortium chain-based transfer method can be directly implemented and executed by a hardware processor, or by a combination of hardware and software modules in the processor.

[0185] The memory 402 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 402 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (RAM), a static random access memory (SRAM), a programmable read-only memory (PROM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic memory, a magnetic disk, an optical disk, and the like. The memory 402 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 402 in the embodiment of the present invention can also be a circuit or any other device that can implement a storage function, for storing program instructions and / or data.

[0186] Based on the same technical concept, an embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program that can be executed by a computing device. When the program runs on the computing device, the computing device executes the steps of the above-mentioned alliance chain-based transfer method.

[0187] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0188] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0189] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0190] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0191] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0192] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications of the present invention fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A transfer method based on alliance chain, characterized in that: include: For the transfer transaction of the transaction initiating node in the alliance chain, k transaction participating nodes for multi-signature are determined from each node of the alliance chain through the proof of work mechanism; For each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, obtain a random number of each transaction node in the transaction node set from the alliance chain, and generate a signature of the transaction node for the transfer transaction based on a signature mechanism; The aggregation node aggregates the signatures of the transfer transaction based on the signatures of the transaction nodes to obtain an aggregate signature; The aggregate signature is verified by a verification node, and after the verification is passed, the transfer transaction is executed; The k transaction participating nodes for multi-signature are determined from the nodes of the alliance chain through the proof-of-work mechanism, including: Determine m nodes from the nodes of the alliance chain as candidate transaction nodes for multi-signature through a proof-of-work mechanism; Creating an m-order first Vandermonde matrix with a rank of k for determining transaction participating nodes, and performing a hash operation on the transfer amount in the transfer transaction to generate a hash value of the transfer amount; Determine m matrix sub-results by using the first Vandermonde matrix and the hash value of the transfer amount, and distribute the m matrix sub-results to the m candidate transaction nodes; Randomly select k rows of matrix values ​​from the first Vandermonde matrix to form a k-order second Vandermonde matrix, and send notification messages to k candidate transaction nodes among the m candidate transaction nodes in a random manner; the notification messages are used to instruct the k candidate transaction nodes to submit the locally stored matrix sub-results; Receiving the matrix sub-results submitted by the k candidate transaction nodes, and combining the matrix sub-results of the k candidate transaction nodes to generate a matrix sub-result set; Generate a matrix result value through the matrix sub-result set and the k-order second Vandermonde matrix, and determine whether the matrix result value is consistent with the hash value of the transfer amount; If so, the k candidate transaction nodes are determined as k transaction participating nodes.

2. The method according to claim 1, characterized in that The step of determining m nodes from the nodes of the alliance chain as candidate transaction nodes for multi-signature includes: Generate a function operation expression for determining a candidate transaction node, and broadcast the function operation expression to other nodes in the alliance chain except the transaction initiating node; each of the other nodes is used to determine a calculation result according to the function operation expression; The calculation results of other nodes are verified, and the timestamps of the calculation results of at least one successfully verified node are sorted in chronological order, and the nodes ranked in the first m are taken as candidate transaction nodes.

3. The method according to claim 1, characterized in that Before determining k transaction participating nodes for multi-signature from the nodes of the alliance chain through the proof of work mechanism, it also includes: The transfer transaction is serialized to generate the serialized transfer transaction.

4. The method according to any one of claims 1 to 3, characterized in that For each transaction node in the transaction node set consisting of the transaction initiating node and the k transaction participating nodes, a random number of each transaction node in the transaction node set is obtained from the alliance chain, and a signature of the transaction node for the transfer transaction is generated based on a signature mechanism, including: For each transaction node in the transaction node set, the transaction node generates a random number and uploads the random number to the alliance chain; The transaction node obtains the random number of each transaction node from the alliance chain, and generates a first obfuscated shard based on the random number of each transaction node; The transaction node obtains the public keys of each transaction node from the alliance chain, and aggregates the public keys of each transaction node to generate a first aggregated public key; The transaction node generates a signature of the transfer transaction through the random number of the transaction node, the transfer transaction, the first obfuscation shard, the private key of the transaction node and the first aggregated public key.

5. The method according to claim 4, characterized in that The generating a first obfuscated shard based on the random number of each transaction node includes: The transaction node generates a confusing sub-shard of each transaction node based on the random number of the transaction node; The transaction node splices the obfuscated sub-shards of the transaction nodes to generate the first obfuscated shard.

6. The method according to claim 4, characterized in that The transaction node generates a signature of the transfer transaction through the random number of the transaction node, the transfer transaction, the first obfuscated shard, the private key of the transaction node, and the first aggregated public key, including: The transaction node concatenates the transfer transaction, the first obfuscated shard, and the first aggregated public key to generate obfuscated information, and performs a hash operation on the obfuscated information to generate a hash value of the obfuscated information; The transaction node generates a signature of the transfer transaction according to the random number of the transaction node, the private key of the transaction node and the hash value of the obfuscated information.

7. The method according to claim 4, characterized in that The aggregation node performs aggregation processing on the signatures of the transfer transaction based on each transaction node to obtain an aggregate signature, including: The aggregation node receives the signatures of the transfer transactions sent by each transaction node, and aggregates the signatures of each transfer transaction to generate a first signature fragment; The aggregation node obtains the random number of each transaction node from the alliance chain, and generates a confusing sub-shard of the transaction node according to the random number of each transaction node; The aggregation node aggregates the obfuscated sub-shards of the transaction nodes to generate a second signature shard; The aggregation node combines the first signature fragment and the second signature fragment to generate an aggregate signature.

8. The method according to claim 7, characterized in that The aggregate signature is verified by a verification node, and after the verification is passed, the transfer transaction is executed, including: The verification node receives the aggregate signature sent by the aggregation node, and obtains a first signature fragment and a second signature fragment from the aggregate signature; The verification node obtains the random number of each transaction node from the alliance chain, generates the obfuscated sub-shards of each transaction node according to the random number of each transaction node, and splices the obfuscated sub-shards of each transaction node to generate a second obfuscated shard; The verification node obtains the public keys of the transaction nodes from the alliance chain, and aggregates the public keys of the transaction nodes to generate a second aggregated public key; The verification node generates a first verification shard according to the first signature shard and the public point of the elliptic curve, and generates a second verification shard according to the second signature shard, the transfer transaction, the second obfuscation shard and the second aggregated public key; The verification node determines whether the first verification shard is consistent with the second verification shard; If yes, the verification node deserializes the serialized transfer transaction to obtain the transfer transaction, and executes the transfer transaction.

Images