A blockchain cross-chain method based on BLS threshold signature

Abstract

The present invention provides a blockchain cross-chain method based on BLS threshold signature, including: S1: any client in the initial blockchain initiates a cross-chain request; S2: a third-party organization selects multiple notary nodes according to the reputation value of the public node, and all public nodes update their own reputation according to whether they are selected; S3: all notary nodes use their respective threshold private keys to sign the data submitted across the chain in the initial blockchain, generate threshold signature data and send it to the client, and the client restores the main signature data signed by the master private key; S4: the target blockchain verifies the main signature data. The present invention adopts a reputation-based node selection mechanism for dynamic selection, thereby reducing the degree of centralization of notary selection, and at the same time, only one signature is required for verification of the cross-chain request, which reduces the total overhead of signature transmission and verification, and has a certain fault tolerance.

Description

Technical Field

[0001] The present invention relates to the fields of information privacy protection and blockchain technology, and in particular to a blockchain cross-chain method based on BLS threshold signature. Background Art

[0002] The Metaverse creates a virtual world that maps and interacts with the real world. The economic system in the Metaverse is supported by blockchain technology. However, the current Metaverse scenario lacks solutions for the interaction between various blockchains that support the economic system. Specifically, the blockchains that support the Metaverse economic system are divided into different chains, such as public chains that issue non-fungible tokens, public chains that issue homogeneous tokens, or other types of consortium chains. These different chains are each a system that independently maintains an ecosystem. Therefore, there is a problem of interconnection between chains, that is, the two chains that participate in the interaction of chain data or assets cannot perform high-reliability verification of requests to achieve mutual trust between the two chains. This problem of interconnection between chains will hinder the further promotion and development of the Metaverse.

[0003] The typical cross-chain solution is currently based on the notary mechanism, which verifies the validity of cross-chain transactions or data through highly trusted nodes that have data from both chains. However, this solution has the following problems: First, the nodes for verification are fixed, which increases the degree of centralization and has certain centralization risks. Second, for a cross-chain request, each authentication node needs to perform authentication. If the authentication result needs to be saved for later verification or provided to a third party for verification, the cost of transmitting or saving the authentication result will be extremely huge. Third, each participant in the cross-chain authentication has equal authority and there is no more detailed authority control. Summary of the invention

[0004] In view of the deficiencies in the prior art, the present invention provides a blockchain cross-chain method based on BLS threshold signature, which adopts a reputation-based node selection mechanism for dynamic selection, thereby reducing the degree of centralization in the selection of notaries. At the same time, cross-chain requests only require one signature for verification, and each node does not need to be verified, thereby reducing the total overhead of signature transmission and verification and having a certain degree of fault tolerance.

[0005] According to an embodiment of the present invention, a blockchain cross-chain method based on BLS threshold signature includes:

[0006] S1: Any client in the initial blockchain initiates a cross-chain request and submits the relevant records and data of the cross-chain request in the blockchain;

[0007] S2: The third-party organization selects multiple notary nodes based on the reputation values of the public nodes, and sends the notary node selection results to all public nodes. After receiving the information, all public nodes update their own reputations according to whether they are selected;

[0008] S3: All notary nodes use their respective threshold private keys to sign the cross-chain submitted data in the initial blockchain, generate their respective threshold signature data, and send the threshold signature data to the client. The client restores the main signature data signed by the main private key through the threshold signature data and sends it to the target blockchain;

[0009] S4: The target blockchain verifies the main signature data. If the verification is successful, it means that the data has not been tampered with and is endorsed by all notary nodes. The target blockchain starts to execute relevant cross-chain operations until the cross-chain is completed. Otherwise, it means that the data has been tampered with, the data is invalid, and the cross-chain fails.

[0010] Preferably, the third-party organization in S2 selects multiple notary nodes based on the reputation values of the public nodes, including: comprehensively considering and calculating according to the response time and the number of calls of the public nodes, sorting all public nodes in ascending order according to the calculation results, and then selecting the top n public nodes as notary nodes according to the requirements.

[0011] Preferably, in S3, the third-party organization also needs to set a security parameter t, and t < n. The client that initiates the cross-chain request stops receiving when the total number of threshold signature data received is equal to t.

[0012] Preferably, if the notary nodes selected in S2 are not exactly the same as the notary nodes selected last time, or the security parameter t changes, then the threshold private keys need to be regenerated in S3. If they are exactly the same and the security parameter t has not changed, they are not regenerated.

[0013] Preferably, in S3, if the threshold private keys need to be regenerated, first generate the main private key using the random number generation algorithm, and take the public key of the master on the corresponding elliptic curve in this algorithm. Then generate multiple threshold private keys according to the main private key, and also obtain the corresponding threshold public keys on the corresponding elliptic curve. The number of the threshold public keys and threshold private keys is the same as the number of notary nodes, both being n.

[0014] Preferably, after the threshold private keys are generated, one is distributed to each notary node, the public key of the master and the threshold public keys are made public to the blockchain network, and the main private key is destroyed.

[0015] Preferably, the threshold private keys and threshold public keys correspond one by one. After the threshold signature data is generated, the corresponding threshold public key is needed to verify it. If the verification is successful, it means that the data has not been tampered with. Otherwise, it means that the data has been tampered with and the data is invalid.

[0016] Preferably, the client only receives threshold signature data after successful verification.

[0017] Compared with the prior art, the present invention has the following beneficial effects:

[0018] (1) A reputation-based node selection mechanism is used to select multiple public nodes as notary nodes. After selection, the selected public nodes will update their own reputations. Then, when selecting public nodes next time, the reputations of all public nodes will be different from the last time. The next selection will not necessarily select the same node as the last time as the notary node. This can achieve dynamic selection, thereby reducing the degree of centralization of notary selection.

[0019] (2) The client that initiates the cross-chain request uses the received threshold signature data to restore the master signature data signed by the master private key. When the target blockchain performs verification, it only needs to verify the master signature data. It does not need to verify every node, which reduces the total overhead of signature transmission and verification and has a certain degree of fault tolerance. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is an overall flow chart of the cross-chain method according to an embodiment of the present invention.

[0021] Figure 2 This is a flowchart of a node selection algorithm according to an embodiment of the present invention.

[0022] Figure 3 This is a flow chart of the BLS threshold signature cross-chain authentication algorithm of an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0024] like Figure 1 As shown, an embodiment of the present invention proposes a blockchain cross-chain method based on BLS threshold signature. This embodiment includes 5 roles, namely blockchain 1, blockchain 2, public nodes, third-party organizations and notaries, where blockchain 1 is the initial blockchain, which includes multiple clients that can initiate cross-chain requests, blockchain 2 is the target blockchain, the public node is a node that records the data of blockchain 1 and blockchain 2 at the same time, the third-party organization is a highly trusted organization responsible for selecting nodes, distributing secret keys, data conversion or other cross-chain operations, and the notary is a subset selected from the public nodes according to the node selection algorithm, which includes multiple notary nodes.

[0025] The cross-chain method of this embodiment includes:

[0026] S1: The initial blockchain initiates a cross-chain request and submits relevant cross-chain records and data in the blockchain. For example, for asset transfer, the status record of the relevant assets being locked is submitted to complete the operation requirements required by the initial blockchain in the cross-chain request;

[0027] S2: A third-party organization selects multiple notary nodes based on the reputation of the public nodes and sends the notary node screening results to all public nodes. After receiving the information, all public nodes update their own reputations based on whether they are selected.

[0028] The node selection algorithm is the strategy for selecting notaries in this embodiment. The algorithm sets node selection into different rounds and changes the notary group according to different reputations to alleviate the centralization problem of the original notary mechanism. The reputation setting takes into account the response time of the node and the number of times the node is called. , whose reputation meets:

[0029]

[0030] in is the called coefficient, is the response time coefficient, is a weight parameter, ranging from 0 to 1. Assume there is a set of m public nodes. , then for node i, it has network transmission delay , then the response time coefficient is:

[0031]

[0032] The specific process of selecting a notary from m public nodes is as follows: Figure 2 As shown:

[0033] (1) A third-party organization sends a reputation request to a public node. Analyze whether to call the coefficient according to the request Initialize. If not initialized, directly return the reputation coefficient, otherwise set for:

[0034]

[0035] (2) Third-party organizations obtain node reputation lists , and thus sorting in ascending order yields , n notary nodes are selected from them, and the notary node set can be determined ;

[0036] (3) For the selected public node, the called coefficient Perform the update as follows:

[0037]

[0038] For the public nodes that are not selected, perform the following updates:

[0039]

[0040] S3: All notary nodes use their respective threshold private keys to sign the data submitted across chains in the initial blockchain, generate their own threshold signature data, and send the threshold signature data to the client. The client restores the master signature data signed by the master private key through the threshold signature data and sends it to the target blockchain;

[0041] BLS threshold signature cross-chain authentication is participated by each notary node. Its main purpose is to authenticate and endorse the blockchain records related to a cross-chain request and provide it to the target blockchain for verification. This threshold signature authentication method combines BLS signature and Shamir secret sharing technology. BLS signature is used to reduce the space overhead of signature, while Shamir secret sharing technology is used to aggregate multiple BLS signatures into one BLS signature. Compared with the transmission, storage and verification of signatures in the typical notary mechanism, this method can effectively reduce network transmission overhead and signature storage overhead. The specific algorithm flow is as follows: Figure 3 As shown, it can be divided into initialization phase, key issuance phase, signature phase and verification phase:

[0042] Initialization phase: After the notary screening is completed, the third-party organization will determine whether to generate a threshold key based on the situation. If the notary node selected is not exactly the same as the notary node selected last time, specific security parameters have changed or re-initialization is required, the threshold private key needs to be regenerated. Otherwise, it will not be regenerated and the signing phase will start directly.

[0043] This embodiment takes the case where the notary node selected is not exactly the same as the notary node selected last time and the threshold private key needs to be regenerated as an example. First, the multiplication cyclic group of the prime number p to be used in this algorithm is issued. ,as well as The corresponding generator , a bilinear mapping function , and secure hash mapping functions , these parameters will be made public to all notary nodes for subsequent verification.

[0044] Key distribution phase: The main role in this phase is still the third-party organization, which is mainly divided into two steps. The first step is to randomly generate the master private key required in the BLS threshold signature algorithm. , and obtain the master public key on the corresponding elliptic curve , where the parameters of the threshold signature are (t,n), where t is the minimum number of signatures required to restore the signature of the master private key, and n is the number of participants:

[0045]

[0046] The second is that the organization randomly selects t-1 elements , and set , thus constructing a t-1 order polynomial , generate a private key for each notary node i and the corresponding public key , and finally publish the master public key As well as all user public keys and attach the organization's certification, and destroy the polynomial that generates the private key and the master private key after completion .

[0047] Signature phase: Each notary node i uses the private key it receives Cross-chain related data To sign, the first step is to hash the message and map the resulting hash digest to On, that is ,and ,d is equal to 0,1,2,..., this is because if the value obtained by hashing the cross-chain related data m is directly mapped to the curve, there is a 50% chance that it cannot be mapped to a specific point, so the value of d is continuously increased until the point is successfully mapped. Therefore, the signature of the notary node i on the cross-chain related data m Will be obtained as follows:

[0048]

[0049] The client that initiates the cross-chain request later uses the corresponding threshold public key The received signature Verification is performed to determine whether the cross-chain related data m has been tampered with. If it has not been tampered with, proceed to the next step. If it has been tampered with, it will be discarded.

[0050] Afterwards, the client that initiated the cross-chain request received a set of signatures composed of t notary nodes. The completed signature group, and each signature in the signature group has passed verification, can obtain the master private key according to the Lagrange interpolation method Signing the message :

[0051]

[0052] Then the signature Sent to any node of the target blockchain.

[0053] In addition, the user weight can be adjusted according to the security parameter t by setting the number of threshold private keys owned by each notary node. The more threshold private keys a notary node has, the higher the weight and the higher the authentication weight of the notary node. For example, if the node has t threshold private keys, then the node can directly authenticate cross-chain data.

[0054] S4: The target blockchain verifies the primary signature data. If the verification is successful, it means that the data has not been tampered with. The target blockchain reads and starts to execute related cross-chain operations until the cross-chain is completed. Otherwise, it means that the data has been tampered with, the data is invalid, and the cross-chain fails.

[0055] After the target blockchain receives the signature, it uses the master public key Verify that it is signed by multiple nodes from a specific group of nodes:

[0056]

[0057]

[0058]

[0059] If the verification is successful, the operation of the starting blockchain required for the cross-chain operation is deemed to have been recorded on its blockchain, and the cross-chain related operations within this blockchain continue. The target blockchain reads and starts to execute related cross-chain operations until the cross-chain operation is completed. Otherwise, it is deemed invalid and the cross-chain operation fails.

[0060] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solution of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solution of the present invention, which should be included in the scope of the claims of the present invention.

Claims

1. A blockchain cross-chain method based on BLS threshold signature, characterized by: The method includes: S1: Any client in the initial blockchain initiates a cross-chain request and submits the relevant records and data of the cross-chain request in the blockchain; S2: A third-party organization selects multiple notary nodes based on the reputation of the public nodes and sends the notary node screening results to all public nodes. After receiving the information, all public nodes update their own reputations based on whether they are selected. The reputation value satisfies: in is the called coefficient, is the response time coefficient, is a weight parameter, ranging from 0 to 1. For a set of m public nodes , then for node i, it has network transmission delay , j is the set For any public node in , the response time coefficient is: The third-party organization selects multiple notary nodes based on the reputation value of the public nodes, including: (1) A third-party organization sends a reputation request to a public node. Analyze whether to call the coefficient according to the request Initialize. If not initialized, directly return the reputation coefficient, otherwise set for: (2) Third-party organizations obtain node reputation lists , and thus sorting in ascending order yields , select the first n notary nodes with high reputation values, and determine the notary node set ; (3) For the selected public node, the called coefficient Perform the update as follows: For the public nodes that are not selected, perform the following updates: S3: All notary nodes use their respective threshold private keys to sign the data submitted across chains in the initial blockchain, generate their own threshold signature data, and send the threshold signature data to the client. The client restores the master signature data signed by the master private key through the threshold signature data and sends it to the target blockchain; The master signature data is obtained according to the Lagrange interpolation method: in is the primary signature data, To randomly generate the master private key required in the BLS threshold signature algorithm, h(M) is a hash mapping function. is cross-chain related data, d is equal to 0, 1, 2, ..., M is The message obtained by successfully splicing with d, is the received private key, is a set of signatures of t notary nodes, and j is the identifier of the corresponding notary node; S4: The target blockchain verifies the primary signature data. If the verification is successful, it means that the data has not been tampered with and is endorsed by all notary nodes. The target blockchain starts to execute related cross-chain operations until the cross-chain is completed. Otherwise, it means that the data has been tampered with, the data is invalid, and the cross-chain fails.

2. A blockchain cross-chain method based on BLS threshold signature as claimed in claim 1, characterized in that: In S3, the third-party organization also needs to set a security parameter t, and t<n. The client initiating the cross-chain request stops receiving when the total number of threshold signature data received is equal to t.

3. A blockchain cross-chain method based on BLS threshold signature as claimed in claim 2, characterized in that: If the notary node selected in S2 is not exactly the same as the notary node selected last time, or the security parameter t changes, the threshold private key needs to be regenerated in S3. If they are exactly the same and the security parameter t has not changed, it is not regenerated.

4. A blockchain cross-chain method based on BLS threshold signature as claimed in claim 3, characterized in that: In S3, if the threshold private key needs to be regenerated, the master private key is first generated using a random number generation algorithm, and the master public key is obtained on the corresponding elliptic curve in the algorithm. Then, multiple threshold private keys are generated based on the master private key, and the corresponding threshold public keys are also obtained on the corresponding elliptic curve. The number of threshold public keys and threshold private keys is the same as the number of notary nodes, both of which are n.

5. A blockchain cross-chain method based on BLS threshold signature as claimed in claim 4, characterized in that: After the threshold private key is generated, one must be issued to all notary nodes, the master public key and the threshold public key are made public to the blockchain network, and the master private key is destroyed.

6. A blockchain cross-chain method based on BLS threshold signature as claimed in claim 4, characterized in that: The threshold private key and the threshold public key correspond one to one. After the threshold signature data is generated, it needs to be verified using the corresponding threshold public key. If the verification is successful, it means that the data has not been tampered with. Otherwise, it means that the data has been tampered with and the data is invalid.

7. A blockchain cross-chain method based on BLS threshold signature as claimed in claim 6, characterized in that: The client will only receive threshold signature data after successful verification.

Images