A multi-signature method based on ECDSA and a cross-chain transaction method

Abstract

The application discloses a kind of multiple signature method and cross-chain transaction method based on ECDSA, multiple signature method includes the following steps: initialization, determine public parameter;Key generation, according to public parameter and random number, generate the public key and private key of user;Signature generation, given message and the private key of user, select a random number, generate signature;Multiple signature generation, when multiple participants sign the same message, according to the private key of multiple participants, generate multiple signature;Signature verification, verify whether the signature is valid and verify whether multiple signature is valid.The method of the application not only solves the problem of notary node function concentration, but also improves the processing efficiency of cross-chain transaction, which helps to promote the role of blockchain technology in a wider range of application scenarios.

Description

Technical Field

[0001] This invention belongs to the field of blockchain cross-chain technology, specifically involving a multi-signature method and a cross-chain transaction method based on ECDSA. Background Technology

[0002] Independent blockchain networks suffer from information silos and interoperability issues, limiting the comprehensive development and application of blockchain technology. Cross-chain technology has emerged to address this problem.

[0003] Currently, mainstream cross-chain technologies include hash locking, sidechains / relays, and notary mechanisms. Hash locking locks the hash value of a transaction on the source chain, ensuring that it can only be unlocked after the corresponding operation is performed on the target chain, achieving secure cross-chain asset transfers. It has a high degree of decentralization, but its efficiency is limited, payment costs are high, and its application scenarios are relatively restricted. Sidechains are blockchains that exist in parallel with the main chain, enabling bidirectional asset transfers and data transmission between them. Relays are a technology that connects different blockchain networks through relay chains, enabling cross-chain information transmission and execution, and fully guaranteeing decentralization. However, both technologies have their own drawbacks: sidechains need to be aware of the main chain's information at all times and maintain synchronization, while relay technology is difficult to implement and thus difficult to apply on a large scale. Notaries are special entities or nodes responsible for verifying and confirming the validity of cross-chain transactions, thereby ensuring the correct execution of various cross-chain operations. The notary mechanism has a relatively simple implementation principle and effectively overcomes the shortcomings of other cross-chain technologies.

[0004] There are generally three implementation methods for notary mechanisms: single-signature notary mechanisms, where one node acts as a notary; multi-signature notary mechanisms, where multiple nodes act as a notary group using a multi-signature mechanism; and distributed signature notary mechanisms, where multiple notaries hold fragments of a single signing key, which are randomly distributed among the notaries. Traditional single-signature notary technology suffers from significant drawbacks, such as excessively high credibility requirements and an imperfect notary selection mechanism. For example, the single-notary mechanism implemented by Hope-bailie et al. in their paper "Interledger: Creating a Standard for Payments" uses only one notary, where only one notary is selected for each ledger. This leads to an over-concentration of power in cross-chain transactions, with success or failure determined by a single person. Therefore, expanding the notary to a notary group and decentralizing power through multi-signature or distributed signature technologies to achieve a more reliable and secure notary mechanism is currently the mainstream approach. Summary of the Invention

[0005] The main objective of this invention is to overcome the shortcomings and deficiencies of existing technologies and propose a multi-signature method and cross-chain transaction method based on ECDSA. By adopting ECDSA multi-signature technology, the functions of notary nodes can be decentralized, thereby improving system stability.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] A multi-signature method based on ECDSA includes the following steps:

[0008] Initialize and determine common parameters;

[0009] Key generation: Generate the user's public and private keys based on public parameters and random numbers;

[0010] Signature generation: Given a message and the user's private key, select a random number to generate a signature;

[0011] Multi-signature generation: When multiple parties sign the same message, a multi-signature is generated based on the private keys of the multiple parties.

[0012] Signature verification verifies whether the signature is valid and whether the multi-signature is valid.

[0013] This invention also includes a blockchain cross-chain transaction method, based on a provided ECDSA-based multi-signature method, which includes a verifier and a connector, and comprises the following steps:

[0014] S1. Randomly select n nodes to form a transaction verification group and assign n transactions {M1,...,M}. n Each node independently reviews these n transactions and verifies their legality and validity. Then, the nodes obtain the final valid transaction M according to the consensus algorithm. i Where i∈[1,n];

[0015] S2, Each validator node uses the MultiSignGen algorithm to verify transaction M. i Performing multi-signature yields (σ1,σ2,...,σ) n );

[0016] S3, Transaction M i In M i The signature and corresponding public key are placed into the cross-chain transfer pools of their respective source and target chains, awaiting signature aggregation and verification by the connector. Transaction M i In M i The signature and corresponding public key on the [database] are represented as {M}. i ,(σ1,σ2,...,σ n ),pk1,...,pk n};

[0017] S4, The connector receives the transaction M. i The signatures are aggregated to obtain

[0018] S5, the connector will use multi-signature Public key set {pk i} i∈[1,n] and transaction M i The data is input into the Verify algorithm, which reviews and verifies the transaction. Once it is confirmed to be correct, it is processed to complete the cross-chain asset transaction.

[0019] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0020] 1. This invention adopts ECDSA multi-signature technology, which can distribute the functions of notary nodes and improve system stability. In this invention, there is no single notary node responsible for all signing and verification work. Instead, multiple nodes work together to complete the work, which can effectively prevent single points of failure and improve the robustness of the system.

[0021] 2. This invention also significantly improves the processing efficiency of cross-chain transactions; by adopting multi-signature, multiple transactions can be processed in parallel, greatly improving the processing speed, while also reducing the workload of individual nodes, enabling the entire system to maintain stable operation while maintaining high efficiency. Attached Figure Description

[0022] Figure 1 This is a flowchart of the present invention;

[0023] Figure 2 This is a diagram of a cross-chain transaction model for an example. Detailed Implementation

[0024] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0025] Example

[0026] like Figure 1 As shown, this invention provides a multi-signature method based on ECDSA, comprising the following steps:

[0027] Initialization, determining common parameters; specifically:

[0028] Users negotiate to choose a prime number p, and select a, b∈F. p According to the elliptic curve formula E:y 2 =x 3 +ax+b(mod p) generates the elliptic curve E. p (a,b); where F pLet p be a finite field of prime order p;

[0029] In elliptic curve E p Choose a base point G = (x) on (a,b) G ,y G ) ≠ O, choose a hash function to obtain the common parameter pp = (E p (a,b),N,G,Hash), where x G ,y G ∈F p G has an order of N, and O represents the identity element.

[0030] Key generation involves generating the user's public and private keys based on public parameters and random numbers. The KeyGen algorithm is used for key generation.

[0031] Based on the public parameter pp, select a random number x∈[1,N-1] as the user's private key sk, calculate x·G as the user's public key pk, and output the user's public-private key pair (pk=x·G,sk=x).

[0032] Signature generation: Given a message and the user's private key, a random number is selected to generate a signature; the signature generation uses the SignGen algorithm, specifically:

[0033] Based on message m and the user's private key sk = x, select a random number k ∈ [1, N-1] and calculate R = k -1 ·G=(x R ,y R );

[0034] Calculate the hash value of message m, e = Hash(m), and let r = x. R If r = 0, then re-execute the SignGen algorithm. If r ≠ 0, then calculate s = (k * (e + r * x)) mod N. If s = 0, then re-execute the SignGen algorithm. If s ≠ 0, then output the signature σ = (r, s).

[0035] Multi-signature generation involves multiple parties signing the same message. A multi-signature is generated based on the private keys of all parties. The multi-signature generation uses the MultiSignGen algorithm, specifically:

[0036] Suppose there are n participants P1, ..., Pn. n Need to handle the same message Each participant, P, must sign. i Enter your respective private keys sk i =x i The final output signature The specific steps are as follows:

[0037] Each participant P i Choose two random numbers k i ∈[1,N-1] and δ i ∈[1,N-1], and assume

[0038] Each participant P i To execute the privacy product protocol, input your respective k. i and δ i get yes The share, and finally each participant P i Broadcast δ i ·G and

[0039] Each participant P i Obtain other participants {P j,j≠i} broadcast δ j,j≠i ·G and calculate and Recalculate

[0040] Regarding the message and Each participant P i calculate And order like Then the MultiSignGen algorithm is re-executed; each participant P i To execute the privacy product protocol, input your respective k. i and private key x i Obtain protocol output yes share, For each participant P i P i Local computing If [s] i =0 or signature If invalid, re-execute the MultiSignGen algorithm;

[0041] Each participant P i Collect publicly available signatures from other participants[s] i Calculated locally

[0042] like Then the MultiSignGen algorithm is re-executed; finally, the multi-signature is output.

[0043] The privacy product protocol is as follows:

[0044] (a1,...,a n ,b1,...,b n → {[ab] i}, i = 1, 2, ..., n,

[0045] At the beginning of the agreement, each participant P i Holding a i ,b i Through the interaction between the participants, at the end of the agreement, each participant receives an additive share of the product of a and b [ab]. i ;

[0046] The privacy product protocol specifically includes the following steps:

[0047] Participant P i Choose a random number r i Calculate b i -r i ;

[0048] Participant P i P holds the public and private keys pk and sk of the additive homomorphic encryption scheme. i Encrypting r using public key pk i Get Enc pk (r i ), and Enc pk (r i Together with b i -r i Send to other participants;

[0049] Received from participant P i Sending Enc pk (r i ) and b i -r i Afterwards, participant P j If j ≠ i, select a random number r. j Calculate Enc using the property of additive homomorphism pk (a j *r i +r j ) = a j *Enc pk (r i )+Enc pk (r j ), and calculate the cross term a*b i share [a*b i ] j =aj *(b i -r i )-r j =a j *b i -(a j *r i +r j Finally, the calculation result Enc pk (a j *r i +r j )Sent to participant P i ;

[0050] Participant P i Use your private key sk to decrypt participant P j , j≠i, the sent ciphertext Enc pk (a j *r i +r j ), to obtain a j *r i +r j And calculate the cross term a*b i share

[0051] After each participant calculates its share of n cross terms, the shares are aggregated to obtain the final share of the product of a and b. For participant P i Its share is expressed as

[0052] Signature verification uses the Verify algorithm, specifically:

[0053] Verify that the signature is valid:

[0054] Based on the signature of a single user, σ=(r,s)=(x R (k*(e+rx)), the user's public key pk=x·G, and the message m;

[0055] Calculate e = Hash(m);

[0056] Calculate u1 = e*s -1 mod N, u2=r*s -1 mod N;

[0057] Calculate (x) ′ ,y ′ )=u1·G+u2·pk, if x ′ If the value is r, the signature is valid; otherwise, the signature is invalid.

[0058] The specific calculation steps are as follows:

[0059] Based on the input of a single user's signature σ=(r,s), the user's public key pk=x·G and message m;

[0060] The signer calculates the point k of the elliptic curve. -1 ·G=(x R ,y R )=(r,y R );

[0061] The verifier calculates the elliptic curve point (x) ′ ,y ′ ) = u1·G + u2·pk, where u1 = e*s -1 mod N, u2=r*s - 1 mod N;

[0062] Determine x ′ =whether r is true or false is equivalent to judging (x) ′ ,y ′ )=(x R ,y R Is this true?

[0063] (x ′ ,y ′ )=u1·G+u2·pk

[0064] =u1·G+u2x·G

[0065] = (u1+u2x)·G

[0066] =(e*s -1 +r*s -1 x)·G

[0067] =(e+rx)s -1 ·G

[0068] =(e+rx)(e+rx) -1 k -1 ·G

[0069] =k -1 ·G

[0070] Therefore, we get x ′ =r;

[0071] Verify that the multi-signature is valid:

[0072] According to multi-signature information and the public key set of the participants {pk i =x i G} i∈[1,n] ;

[0073] calculate in

[0074] calculate

[0075] Calculate (x) ′ ,y ′ )=u1·G+u2·pk, if If the signature is valid, it is valid; otherwise, it is invalid.

[0076] The specific calculation steps are as follows:

[0077] Based on the input multi-signature The public key set of the participants {pk i =x i ·G} i∈[1,n] Message m;

[0078] n participants calculated locally and calculate

[0079] The verifier calculates the elliptic curve point (x) ′ ,y ′ ) = u1·G + u2·pk, where

[0080] judge Whether it is true or false is equivalent to judging. Is it true or false?

[0081]

[0082]

[0083] Therefore,

[0084] In another embodiment, a blockchain cross-chain transaction method is also provided, based on the ECDSA-based multi-signature method of the above embodiments, which includes a verifier and a connector, and includes the following steps:

[0085] S1. Randomly select n nodes to form a transaction verification group and assign n transactions {M1,...,M}. n Each node independently reviews these n transactions and verifies their legality and validity. Then, the nodes obtain the final valid transaction M according to the consensus algorithm. i Where i∈[1,n];

[0086] S2, Each validator node uses the MultiSignGen algorithm to verify transaction M. i Performing multi-signature yields (σ1,σ2,...,σ) n );

[0087] S3, Transaction M i In M i The signature and corresponding public key are placed into the cross-chain transfer pools of their respective source and target chains, awaiting signature aggregation and verification by the connector. Transaction M i In M i The signature and corresponding public key on the [database] are represented as {M}. i ,(σ1,σ2,...,σ n ),pk1,...,pk n};

[0088] S4, The connector receives the transaction M. i The signatures are aggregated to obtain

[0089] S5, the connector will use multi-signature Public key set {pk i} i∈[1,n] and transaction M i The data is input into the Verify algorithm, which reviews and verifies the transaction. Once it is confirmed to be correct, it is processed to complete the cross-chain asset transaction.

[0090] like Figure 2 The diagram shown is a cross-chain transaction model diagram of an embodiment.

[0091] It should also be noted that, in this specification, terms such as "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0092] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-signature method based on ECDSA, characterized in that, Includes the following steps: Initialization, determining common parameters; specifically: Users agree to choose a prime number. and select According to the elliptic curve formula Generate elliptic curves ;in, prime order A finite field; In elliptic curves Choose a base point and select one Function, obtain common parameters ,in, , The order is , Represents the unit yuan; Key generation involves generating the user's public and private keys based on public parameters and random numbers. The KeyGen algorithm is used for key generation. According to public parameters Choose a random number As the user's private key ,calculate As the user's public key Output the user's public / private key pair ; Signature generation: Given a message and the user's private key, a random number is selected to generate a signature; the signature generation uses the SignGen algorithm, specifically: According to the news and the user's private key Choose a random number ,calculate ; Calculate the hash value of message m and order ,like If so, the SignGen algorithm will be re-executed. Then calculate ,like If so, the SignGen algorithm will be re-executed. Then output the signature. ; Multi-signature generation involves multiple parties signing the same message. A multi-signature is generated based on the private keys of all parties. The multi-signature generation uses the MultiSignGen algorithm, specifically: Assume there is Each participating party Need to handle the same message Each participant must sign. Enter your private key The final output signature The specific steps are as follows: Each participant Select two random numbers and And assume , , ; Each participant To execute the privacy product protocol, input your respective... and get , yes The share, and finally each participant's share. broadcast and ; Each participant Acquire other participants Broadcast and ,calculate and , then calculate ; Regarding the message and Each participant calculate and order ,like If so, the MultiSignGen algorithm will be re-executed; each participant To execute the privacy product protocol, input your respective... and private key Obtain protocol output , yes share, , For each participating party , Local computing ,like Or signature If invalid, re-execute the MultiSignGen algorithm; Each participant Collect publicly available signatures from other participants Calculated locally ,like If the multisignature is not found, the MultiSignGen algorithm will be re-executed; finally, the multisignature will be output. ; The privacy product protocol is represented as follows: ； At the beginning of the agreement, each participant hold Through the interaction between the participants, each participant receives [amount] at the end of the agreement. Addition share of product ; The privacy product protocol specifically includes the following steps: Participants Choose a random number And calculate ; Participants Holding the public and private keys of the additive homomorphic encryption scheme Participants Using public key encryption get and will Together Send to other participants; Received by the participants Sent and Afterwards, the participating parties Choose a random number Calculate using the property of additive homomorphism And calculate the cross term. share Finally, the calculation results Send to the participants ; Participants Use your own private key Decryption participants ciphertext sent ,get And calculate the cross term. share ; After each participant calculates their share of n cross items, the results are aggregated to obtain... The final share of the product for the participating parties Its share is expressed as ; Signature verification verifies whether the signature is valid and whether the multi-signature is valid.

2. The multi-signature method based on ECDSA according to claim 1, characterized in that, The signature verification uses the Verify algorithm, where verifying the validity of the signature specifically involves: Based on individual user signatures User's public key and messages ; calculate ; calculate , ; calculate ,like If the signature is valid, the signature is valid; otherwise, the signature is invalid.

3. The multi-signature method based on ECDSA according to claim 2, characterized in that, Verifying the validity of a multi-signature involves the following steps: According to multi-signature = ,information and the public key set of the participants ; calculate , ,in ; calculate , ; calculate ,like If the condition is met, the multi-signature is valid; otherwise, the multi-signature is invalid.

4. The multi-signature method based on ECDSA according to claim 3, characterized in that, The specific calculation steps for verifying the validity of a signature are as follows: Based on the signature of the individual user. The user's public key and messages ; The signer calculates the elliptic curve points. ; The verifier calculates the elliptic curve points. ,in , ; judge Whether it is true or false is equivalent to judging. Is it true or false? Therefore, ; The specific calculation steps to verify whether a multi-signature is valid are as follows: Based on the input multi-signature The public key set of the participants ,information ; Each participant calculates locally and ,calculate ; The verifier calculates the elliptic curve points. ,in , ; judge Whether it is true or false is equivalent to judging. Is it true or false? Therefore, .

5. A blockchain cross-chain transaction method, characterized in that, The multi-signature method based on ECDSA according to any one of claims 1-4 includes a verifier and a connector, and comprises the following steps: S1. Randomly select n nodes to form a transaction verification group and assign n transactions. Each node independently reviews these n transactions and verifies their legality and validity. Then, the nodes obtain the final valid transactions based on the consensus algorithm. ;in, ; S2. Each validator node uses the MultiSignGen algorithm to verify transactions. Multi-signature ; S3, Transaction ,exist The signature and corresponding public key are placed into the cross-chain transfer pools of their respective source and target chains, awaiting signature aggregation and verification by the connector before the transaction can proceed. ,exist The signature and corresponding public key are represented as follows: ; S4, The connector's response to received transactions The signatures are aggregated to obtain ; S5, the connector will use multi-signature Public key set and transactions The data is input into the Verify algorithm, which reviews and verifies the transaction. Once it is confirmed to be correct, it is processed to complete the cross-chain asset transaction.

Images