An ECDSA Threshold Optimal Signature Method

Abstract

The present invention relates to an ECDSA threshold optimal signature method, which includes three stages: preprocessing, key generation, and signature. In the preprocessing stage, according to all nodes of the blockchain, the total number of nodes of the blockchain and the signature threshold value are initialized. All nodes in the blockchain generate the basic data required for the signature stage through Feldman verifiable secret sharing and first-order homomorphic encryption algorithms; in the key generation stage, all nodes perform joint secret sharing to generate a common signature public key and the signature private key fragments corresponding to each node; in the signature stage, all nodes calculate signature fragments based on the basic data in the preprocessing stage, with the private key fragments corresponding to the signature nodes greater than or equal to the signature threshold value as inputs, and finally synthesize a complete signature. The single-signature speed of the present invention can reach the millisecond level. The signature process meets the requirements of fault tolerance, auditability, algorithm reliability, and supervision, and can be applied to fields such as blockchain account security protection and cross-chain asset locking.

Description

Technical Field

[0001] The present invention relates to the technical field of threshold signatures in blockchain, and in particular to an ECDSA threshold optimal signature method. Background Art

[0002] The Elliptic Curve Digital Signature Algorithm (ECDSA) is a standard digital signature algorithm recognized by the National Institute of Standards and Technology (NIST) of the United States and the Institute of Electrical and Electronics Engineers (IEEE). Currently, it is widely used in the field of encrypted digital currencies to complete the authorization of accounts and the signature of transactions. The earliest ECDSA threshold signature algorithm was proposed by R. Gennaro et al. in 1996. Subsequently, due to the theoretical difficulties in thresholding the ECDSA signature algorithm and the lack of direct application scenarios, related research was in a stagnant state. In recent years, encrypted digital currencies represented by Bitcoin have developed rapidly, and they all use ECDSA as the account digital signature algorithm, which provides a wide range of application scenarios for the ECDSA threshold signature algorithm (such as blockchain account security protection, digital asset custody, blockchain cross-chain protocols, etc.), making it a research hotspot again.

[0003] Recent research results include GGN16, BGG17, GG18, and GG20. The design idea of GGN16 is to encrypt the parameters required for calculating the signature through an additive homomorphic encryption algorithm. The signature process is carried out in the ciphertext state and finally generates the ciphertext of the signature. Finally, all nodes cooperate to decrypt to obtain the plaintext data of the signature. Using the design idea of GGN16, nodes need a total of 6 rounds of interaction during the entire signature process. The design idea of BGG17 is similar to that of GGN16. GG18, on the other hand, adopts a completely different idea to implement the ECDSA threshold optimal signature algorithm. During the signature process, the private key sk and the random number k are no longer split through Shamir secret sharing, but through Additively Secret Sharing. The order of magnitude of the number of node interactions during the entire signature process of k×sk is O(t 2 ). GG20 is an improvement and enhancement of GG18. It adds zero-knowledge proofs for data legality verification during the calculation process to accurately identify malicious nodes and has an auditability ability. At the same time, the steps unrelated to the message to be signed in the signature process are executed offline, and only 1 round of interaction is required for the online steps. However, the number of interactions of the entire protocol is still of the order of O(t 2 ).

[0004] As can be seen from the above, the existing ECDSA threshold signature algorithms have defects such as non-threshold optimality, low computational efficiency, many interaction times, and lack of auditability, resulting in low practicality of the algorithms. Therefore, it has become an urgent problem in the industry to propose an efficient ECDSA threshold optimal signature algorithm with fewer interaction times, fast single-signature speed in a secure environment, and having fault tolerance and auditability, which can be effectively applied to the technical solutions of blockchain account security protection and cross-chain asset locking. Summary of the Invention

[0005] To solve at least one of the above technical problems, the present invention proposes an ECDSA threshold optimal signature method.

[0006] The object of the present invention is achieved through the following technical solutions:

[0007] The present invention provides an ECDSA threshold optimal signature method, including three stages: preprocessing, key generation, and signature.

[0008] In the preprocessing stage, according to all nodes of the blockchain, the total number of nodes n of the blockchain and the signature threshold value are initialized. t All nodes in the blockchain generate the basic data required for the signature stage through Feldman verifiable secret sharing and first-order homomorphic encryption algorithms.

[0009] In the key generation stage, all nodes of the blockchain perform joint secret sharing to generate a common signature public key and signature private key fragments corresponding to each node.

[0010] In the signature stage, all nodes of the blockchain use the basic data in the preprocessing stage, and take the private key fragments corresponding to no less than the signature threshold value of the signature nodes as input to calculate the signature fragments and finally synthesize the complete signature.

[0011] As a further improvement, before the preprocessing stage, first determine that all nodes share the same elliptic curve addition group parameters; establish a secure channel and share a broadcast channel among all nodes of the blockchain; and all nodes share the same first-order homomorphic encryption algorithm parameters.

[0012] As a further improvement, in the preprocessing stage, generating the basic data required for the signature stage through verifiable secret sharing and first-order homomorphic encryption algorithms includes the following steps:

[0013] S11. All nodes of the blockchain respectively randomly select two polynomials f of degree t - 1 over the finite field i (x) and F i (x), where q is the order of the elliptic curve point group.

[0014] S12. Each node calculates F according to the base point G on the elliptic curve and the encryption function TEnc of the threshold first-order homomorphic encryption algorithm. i,j , Z ij and and respectively generate zero-knowledge proofs zkpf 1 , zkpf 2 and zkpf 3 , where i = {1, 2,... n} represents the number of blockchain nodes, j represents the current blockchain node member, F i,j is the (t - 1)-th polynomial F i (x) corresponding to the j-th node of the blockchain, is the (t - 1)-th polynomial f i (x) corresponding to the j-th node of the blockchain through the encryption algorithm, is obtained by encrypting the number randomly generated by the j-th node of the blockchain, Z ij is the position obtained by performing the elliptic encryption algorithm on the number randomly generated by the j-th node of the blockchain, is the position obtained by performing the elliptic encryption algorithm on a number existing in the finite field;

[0015] S13. Each node transmits F i,j to all nodes of the blockchain through a secure channel and broadcasts Z ij , zkpf 1 , zkpf 2 and zkpf 3 ;

[0016] S14. After all nodes of the blockchain receive the data sent by other nodes, each node respectively verifies the legality of zkpf 1 , zkpf 2 and zkpf 3 . If all verifications pass, then multiply the (t - 1)-th polynomials F i (x) of all blockchain nodes to calculate F i , and calculate the ciphertext

[0017] S15. All nodes of the blockchain cooperate to decrypt the ciphertext ;

[0018] S16. Each node respectively transmits z j,i to other nodes through a secure channel;

[0019] S17. Each node verifies the legality of z j,i . If all verifications pass, then respectively calculate the (t - 1)-th polynomials f j(x) squared H i ;

[0020] S18. Output the F i and H i calculated by each node as basic data.

[0021] As a further improvement, the key generation phase specifically includes the following steps:

[0022] S21. All nodes on the blockchain randomly select a (t - 1)-degree polynomial g (x) over a finite field; i (x);

[0023] S22. Each node performs Feldman verifiable secret sharing. Each node sends the secret fragment s i,j to other nodes through a secure channel and broadcasts (b i,t-1 ·G,..., b i,1 ·G, s i ·G), where b i,t-1 is the (t - 1)-degree coefficient term of the polynomial g i (x), b i,1 is the 1-degree coefficient term of the polynomial g i (x), and s i is a constant;

[0024] S23. Each node verifies the legality of the secret fragment s j,i transmitted by other nodes. When all secret fragments are legal, each node calculates the signature private key fragment sk i and the signature public key gpk.

[0025] As a further improvement, in the signature phase, the signature process is implemented based on the multiplication sub - protocol.

[0026] As a further improvement, in the signature phase, the signature process is implemented based on the multiplication sub - protocol, and a legal signature is generated through four - round interaction.

[0027] As a further improvement, the first - round interaction in the signature phase includes the following steps:

[0028] S311. All nodes on the blockchain respectively randomly select two (t - 1)-degree polynomials Fk (x) and Fγ i (x) over a finite field; i (x);

[0029] S312. Each node calculates the constant term kk i of the polynomial Fk i and the polynomial Fγ iThe constant term γγ of (x) i Perform Feldman verifiable secret sharing;

[0030] S313. Each node sends the secret fragments kk of the Feldman verifiable secret sharing i,j and γγ i,j to other nodes through a secure channel, and broadcasts (c i,t-1 ·G,…,c i,1 ·G, kk i ·G) and (d i,t-1 ·G,…,d i,1 ·G, γγ i ·G), where c i,t-1 is the (t - 1)-th coefficient term of the polynomial Fk i (x), c i,1 is the 1-st coefficient term of the polynomial Fk i (x), d i,t-1 is the (t - 1)-th coefficient term of the polynomial Fγ i (x), d i,1 is the 1-st coefficient term of the polynomial Fγ i (x);

[0031] S314. Each node verifies the legality of the secret fragments kk j,i and γγ j,i sent by other nodes. If all the data is legal, each node calculates the sum k j,i of the verified secret fragments kk i and the sum γ j,i of the verified secret fragments γγ i , and at the same time uses k as the random number used in the ECDSA signature algorithm, and γ is used to solve the point k -1 ·G on the elliptic curve in the Beaver inverse algorithm.

[0032] As a further improvement, the second-round interaction in the signature phase includes the following steps:

[0033] S321. Each node of the blockchain calculates the secret fragment k j ·G of k, the secret fragment γ j ·G of γ, and the secret fragment sk j ·G of the signature private key sk respectively by broadcasting data;

[0034] S322. Broadcast (k 1 ·G,…,k n ·G), (γ 1 ·G,…,γ n ·G), and (sk 1·G,…,sk n ·G), as the input of the multiplication sub-protocol, each node runs the multiplication sub-protocol to multiply the secret fragment of k and the secret fragment of γ to calculate kγ, and multiply the secret fragment of k and the secret fragment of the signature private key sk to calculate the (n, t)-Shamir secret fragment of ksk and the corresponding legitimacy proof. After the operation, the output of each node is:

[0035]

[0036]

[0037] Among them, kγ i is the multiplication of the secret fragment of k and the secret fragment of γ on the i-th node of the blockchain, and ksk i is the multiplication of the secret fragment of k and the key on the i-th node of the blockchain, is the zero-knowledge proof verification to prove the multiplication of the secret fragments of k and γ on the i-th node of the blockchain, is the zero-knowledge proof verification to prove the multiplication of the secret fragment of k and the private key on the i-th node of the blockchain.

[0038] As a further improvement, the third round of interaction in the signature phase includes the following steps:

[0039] S331. Each node of the blockchain broadcasts the output data kγ i , ksk i ·G, and after the second round of interaction;

[0040] S332. Each node verifies whether and hold. If the verification passes, it means that kγ j and ksk j ·G are legal. After the data of all signature nodes pass the verification, each node calculates kγ by Lagrange interpolation method, where, is the zero-knowledge proof for verifying whether holds, is the zero-knowledge proof for verifying whether holds;

[0041] S333. Each node calculates the abscissa r of point R;

[0042] S334. Each node calculates the signature fragment sig i .

[0043] As a further improvement, the fourth round of interaction in the signature phase includes the following steps:

[0044] S341. Each node of the blockchain broadcasts the signature fragment sig i ;

[0045] S342. Each node verifies the legality of the signature fragment sig i . When the signature fragments of more than or equal to the signature threshold number of nodes are verified to be legal, each node calculates the abscissa s of the node signature;

[0046] S343. Take (r, s) as the legal ECDSA signature corresponding to the signature public key gpk.

[0047] An ECDSA threshold optimal signature method provided by the present invention includes three stages: preprocessing, key generation, and signature. In the preprocessing stage, according to all nodes of the blockchain, the total number of nodes of the blockchain and the signature threshold value are initialized. All nodes in the blockchain generate the basic data required for the signature stage through Feldman verifiable secret sharing and first-order homomorphic encryption algorithms; in the key generation stage, all nodes of the blockchain perform joint secret sharing to generate a common signature public key and signature private key fragments corresponding to each node; in the signature stage, all nodes of the blockchain calculate signature fragments based on the basic data in the preprocessing stage, with the private key fragments corresponding to no less than the signature threshold number of signature nodes as inputs, and finally synthesize a complete signature. The present invention cooperatively generates an account address by all nodes of the blockchain. Each node separately stores a fragment of the account private key. When sending a transaction, one of the nodes constructs the transaction content and sends it to other nodes, and then all nodes run the ECDSA threshold signature algorithm to cooperatively generate a legal signature for the transaction. Finally, one node broadcasts the signed transaction to the blockchain network. An attacker needs to successfully attack no less than the node threshold number of nodes to recover the account private key. Therefore, the ECDSA threshold signature algorithm can effectively improve the security of cryptocurrency accounts. The property of threshold optimality makes the node deployment cost lower and the account security higher. When all participating nodes are honest nodes, the single-signature speed of the solution of the present invention can reach the millisecond level. At the same time, the signature process also satisfies fault tolerance and auditability, meeting the requirements of the blockchain application scenario for algorithm reliability and regulatory compliance, and can be applied to fields such as blockchain account security protection and cross-chain asset locking. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 is a schematic flowchart of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0049] In order to enable those skilled in the art to better understand the technical solutions of the present invention, the present invention will be further described in detail below in conjunction with the drawings and specific embodiments. It should be noted that, without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other.

[0050] Glossary of terms related to the present invention:

[0051] 1. Elliptic Curve Digital Signature Algorithm: Let G be the base point of an elliptic curve point group with order q; the signature private key is sk, and the corresponding public key is pk, satisfying pk = sk · G; Hash is a secure hash function; M is the message to be signed. The ECDSA signature algorithm and signature verification algorithm are introduced as follows:

[0052] 1) Signature algorithm

[0053] Randomly select a random number denotes the discrete logarithm problem modulo q, where q is the unknown factor, and calculate the point R = k -1 · G on the elliptic curve. Set r as the abscissa of point R, and calculate s = k(m + sk × r), where m = Hash(M) mod q. Finally, the signature σ = (r, s).

[0054] 2) Signature verification algorithm

[0055] Parse the signature σ into (r, s), and calculate R' = s -1 · (m · G + r · pk). Set r' as the abscissa of R'. If the equation r' = r holds, the verification passes; otherwise, the verification fails.

[0056] 2. Zero - knowledge proof of discrete logarithm: Let be an elliptic curve point group of order q, and X, Y, H 1 , H 2 be elements in the elliptic curve group, where the multiple relationship between H 1 and H 2 is unknown, X = α · H 1 , Y = α · H 2 . D. Chaum et al. proposed a zero - knowledge proof method for discrete logarithm, which can prove the existence of α without revealing it, called DLEQ proof (Discrete Log Equivalence Proof). The original DLEQ proof generation process requires interaction between the prover and the verifier. After improvement by the technology proposed by A. Fiat et al., a non - interactive proof process can be achieved. The proof generation process and verification process are introduced as follows:

[0057] 1) Proof generation process

[0058] The prover randomly selects and calculates A 1 = w · H 1 , A 2 = w · H 2, set \(e = \text{Hash}(X|Y|A 1 |A 2 ), and calculate \(z = w - \alpha e\). Finally, output the proof \(\text{proof}=(A 1 ,A 2 ,z)\). This process is represented by \(\text{DLEQ\_Gen}(H 1 ,X,H 2 ,Y)\).

[0059] 2) Proof verification process

[0060] After receiving the proof \(\text{proof}\), the verifier parses it into \((A 1 ,A 2 ,z)\), sets \(e = \text{Hash}(X|Y|A 1 |A 2 ), calculates \(A' 1 = z\cdot H 1 + e\cdot X\), \(A' 2 = z\cdot H 2 + e\cdot Y\). If the equations \(A' 1 = A 1 \) and \(A' 2 = A 2 \) hold, the verification passes; otherwise, the verification fails. This process is represented by \(\text{DLEQ\_Verify}(H 1 ,X,H 2 ,Y,\text{proof})\).

[0061] It should be emphasized that the DLEQ proof is reliable, that is, in the absence of \(\alpha\), the probability \(\varepsilon\) that an attacker successfully generates a DLEQ proof and passes the verification is negligible. Therefore, \(\varepsilon\) is often referred to as the soundness error of DLEQ.

[0062] 3. The Level - 1 Homomorphic Encryption is a weakened version of the Fully Homomorphic Encryption. It can guarantee homomorphicity for any number of additions and multiplications with a depth of 1. Specifically, for the Level - 1 Homomorphic Encryption \(\text{LHE}=(\text{KeyGen},\text{Enc},\text{Dec})\), the plaintext space is \(\mathbb{Z} N \), where \(N\) is a large number. \(\text{KeyGen}\) is the key generation algorithm in the Level - 1 Homomorphic Encryption, \(\text{Enc}\) is the encryption algorithm in the Level - 1 Homomorphic Encryption, and \(\text{Dec}\) is the decryption algorithm in the Level - 1 Homomorphic Encryption. The ciphertext space consists of two disjoint sets, namely the zero - order ciphertext space \(C 0 \) and the first - order ciphertext space \(C 1 \). \(\text{LHE}\) satisfies the following properties:

[0063] 1) The encryption result of the plaintext is an element of the zero - order ciphertext space

[0064] Enc(m) ∈ C 0

[0065] 2) Additive homomorphism

[0066] There exists a computable operation “+” on the ciphertext space E ” that satisfies additive homomorphism. Let α, β be elements in C i , and their corresponding plaintexts be a, b respectively. Then the following equation holds:

[0067] Dec(α + E β) = a + b mod N

[0068] 3) Multiplicative homomorphism

[0069] There exists a computable operation “×” on the zero - order ciphertext space C 0 ”, and its calculation result is an element in the first - order ciphertext space C E ”. At the same time, it satisfies multiplicative homomorphism. Let α, β be elements in C 1 , and their corresponding plaintexts be a, b respectively. Then the following equation holds: 0 γ = α ×

[0070] γ = α × E β ∈ C 1

[0071] Dec(γ) = ab mod N

[0072] The above first - order homomorphic encryption algorithm can be thresholded to obtain the threshold first - order homomorphic encryption algorithm TLHE=(TKeyGen, TEnc, TDec), which is specifically introduced as follows:

[0073] 1) Key generation algorithm

[0074] TKeyGen is the key generation algorithm of the threshold first - order homomorphic encryption algorithm. The input is the security parameter 1 s , the signature threshold value t and the total number of nodes n. The output is the public key PK and the key fragments sk 1 , sk 2 , …, sk n . Each node holds a fragment. This process can be expressed by the formula:

[0075] TKeyGen(1 s , t, n)=(PK, sk 1 , sk 2 , …, sk n )

[0076] 2) Encryption algorithm

[0077] TEnc is the encryption algorithm in the threshold first-order homomorphic encryption algorithm, which is the same as the ordinary LHE. The input is the public key PK and the plaintext m, and the output is the ciphertext c. This process can be expressed by the formula:

[0078] TEnc(PK, m) = c

[0079] 3) Decryption algorithm

[0080] TDec is the decryption algorithm in the threshold first-order homomorphic encryption algorithm. The input is c and k private key fragments sk k , (k ≥ t), and the output is the plaintext m, (k ≥ t), and the output is the plaintext m. This process can be expressed by the formula:

[0081] TDec(c, sk 1 , sk 2 , …, sk k ) = m

[0082] For simplicity of description, the operators between ciphertexts (i.e., + E and × E ) will not be emphasized separately in the following text, and a unified calculation identifier is used.

[0083] Combined with Figure 1 shown in, the embodiment of the present invention provides an ECDSA threshold optimal signature method, which includes three stages: preprocessing, key generation, and signature. In the ECDSA signature algorithm, the signature private key sk and the random number k are both distributed in the form of fragments among the nodes. Therefore, two arithmetic problems need to be solved in the process of generating a legal signature:

[0084] 1) Multiplication operation: Taking the secret fragments of k and sk as inputs, calculate the secret fragment of ksk;

[0085] 2) Inversion operation: Taking the secret fragment of k as the input, calculate the point k -1 ·G on the elliptic curve.

[0086] The inversion operation process can be constructed based on the multiplication operation process through the Beaver inversion algorithm. Therefore, the key to the design of the ECDSA threshold optimal signature algorithm lies in the multiplication operation process. To achieve the property of threshold optimality, the multiplication operation needs to keep the secret recovery threshold unchanged. If t nodes can cooperate to recover k and sk, then they must be able to recover k × sk.

[0087] This paper completes the design of the multiplication operation in the ECDSA signature process by referring to the existing research results of secure multi-party computing protocols. The specific idea is as follows:

[0088] 1) \(k\) and \(sk\) are distributed among the nodes in the form of \((n, t)\)-Shamir secret shares, corresponding to the polynomials \(f\) 1 (x) and \(f\) 2 (x), where \(n\) is the total number of nodes in the blockchain, \(t\) is the signature threshold, \(x\) is the independent variable, \(f\) 1 (x) is a polynomial of degree \(t - 1\), and \(f\) 2 (x) is a polynomial of degree \(t - 1\);

[0089] 2) Each node multiplies the secret shares \(k\) i and \(sk\) i it holds to obtain the \((n, 2t - 1)\)-Shamir secret share \(ksk\) i of \(k\times sk\), and the corresponding polynomial is \(f(x)=f\) 1 (x) \(f\) 2 (x), where \(i = \{1, 2, \ldots, n\}\);

[0090] 3) Each node calculates \(ksk\) i ' = \(ksk\) i - h(i), where \(h(x)\) satisfies \(f(x)=h(x)+\sigma(x)\) and \(\deg(\sigma(x))\leq t - 1\). \(ksk\) i ’ is the \((n, t)\)-Shamir secret share of \(k\times sk\).

[0091] Among them, \(h(i)\) is a polynomial of degree \(t - 1\), and \(\deg\) represents the degree;

[0092] The key point of the above design is to "reduce the degree" of the Shamir secret sharing polynomial through \(h(i)\), and transform the secret share \(ksk\) i corresponding to the polynomial \(f(x)\) of degree \(2t - 1\) into the secret share \(ksk\) i ' corresponding to the polynomial \(\sigma(x)\) of degree \(t - 1\), ensuring that the secret recovery threshold is still \(t\). Because existing secure multi-party computation protocols rely on a trusted third party to calculate \(h(i)\) and are not applicable to decentralized application scenarios. To solve this problem, a new preprocessing process is added in the present invention, and nodes can calculate \(h(i)\) based on the output in the preprocessing process without introducing a trusted third party. Before the algorithm starts, all nodes \(n=\{P\) 1 , \(P\) 2 , \(\ldots\), \(P\) n} of the blockchain complete the following preparatory work:

[0093] 1) All nodes share the same elliptic curve addition group parameters. The base point of the elliptic curve is \(G\), and the group order is a prime number \(q\);

[0094] 2) All nodes establish secure channels pairwise and share the same broadcast channel;

[0095] 3) All nodes share the same parameters of the threshold first-order homomorphic encryption algorithm. The decryption private key fragment of node P in the blockchain i is esk i . No less than t nodes with the signature threshold can cooperate to complete the decryption process. It should be noted that the threshold first-order homomorphic encryption algorithm used in the present invention is consistent with BGG17, that is, the Paillier additive homomorphic encryption algorithm is reconstructed through the method proposed by D. Catalano et al. to obtain a first-order homomorphic encryption algorithm, and then it is transformed into a threshold first-order homomorphic encryption algorithm using the thresholding technique. Therefore, the zero-knowledge proof that guarantees the correctness of the encryption result in BGG17 can be directly reused.

[0096] In the preprocessing stage, according to all nodes of the blockchain, the total number of nodes n of the blockchain and the signature threshold t are initialized, and all nodes generate the basic data required for the signature stage through Feldman verifiable secret sharing and the first-order homomorphic encryption algorithm. Taking the blockchain node P i as an example, it includes the following steps:

[0097] S11. All nodes of the blockchain respectively randomly select two polynomials f i (x) and F i (x) of degree t - 1 over

[0098] f i (x) = a i,t-1 x t-1 +…+ a i,1 x (1 - 1)

[0099] F i (x) = f i (x) + a i,0 (1 - 2)

[0100] (z i,1 , z i,2 , …, z i,n ) (1 - 3)

[0101] where is over the finite field, f i (x) is a polynomial of degree t - 1, F i (x) is a polynomial of degree t - 1, and z i,n is the nth random number;

[0102] S12. Loop through all nodes of the blockchain, with j from 1 to n, j = {1, 2, … n,}, and each node calculates F according to the base point G on the elliptic curve point group and the encryption function TEnc of the threshold first-order homomorphic encryption algorithmi,j , Z ij and are as follows:

[0103] F i,j = F i (j)(1 - 4)

[0104]

[0105]

[0106] Z ij = z i,j ·G(1 - 7)

[0107]

[0108] Generate zero - knowledge proof zkpf 1 , zkpf 2 and zkpf 3 : zkpf 1 Prove that "for any 1 ≤ j ≤ n, there exists satisfying and "; zkpf 2 Prove that "for any 1 ≤ j ≤ n, there exists satisfying and λ j ·G = Z ij "; zkpf 3 Prove that "for any 1 ≤ j ≤ n, there exists satisfying Z ij = μ j ·G and ".

[0109] Where, F i,j is the (t - 1) - th degree polynomial F i (x) corresponding to the j - th node of the blockchain, is the (t - 1) - th degree polynomial f i (x) corresponding to the j - th node of the blockchain through the encryption algorithm, is obtained by encrypting the number randomly generated by the j - th node of the blockchain, Z ij is the position obtained by performing the elliptic encryption algorithm on the number randomly generated by the j - th node of the blockchain, is the position obtained by performing the elliptic encryption algorithm on a number in the finite field; EPK is the encryption public key;

[0110] S13. Loop through all nodes of the blockchain. For j from 1 to n, each node transmits F i,j to all nodes of the blockchain through a secure channel and broadcasts Z ij , zkf 1 、zkpf 2 and zkpf 3 :

[0111]

[0112] S14. After all nodes of the blockchain receive data sent by other nodes, each node verifies zkpf 1 、zkpf 2 and z k pf 3 If all the verifications are passed, then calculate F i and

[0113] F i =j=1nF j,i (1-10)

[0114]

[0115] Among them, F i is the t-1 degree polynomial F of all blockchain nodes i (x) multiplied, is the variance between the actual proven number and the randomly generated number, F j,i is the t-1 polynomial F of the j-th node of the blockchain j (x);

[0116] S15. All nodes of the blockchain cooperate To decrypt:

[0117]

[0118] in, is the ciphertext, t i for Decrypted plaintext, esk n is n private key fragments;

[0119] S16. Each node sends the random number z j,i Transmit to other nodes via secure channels;

[0120] S17, loop all nodes, j from 1 to n, node P i Right j,i The legitimacy of is verified, that is, whether the following equation is established:

[0121] z j,i G=Z ji (1-13)

[0122] Among them, Z ji is the position obtained by performing the elliptic encryption algorithm on the number randomly generated by the i-th node of the blockchain, and z j,i is the number randomly generated by the i-th node of the blockchain. If all verifications pass, then calculate H i as follows:

[0123]

[0124] Among them, H i is the square of the t-1 degree polynomial f j (x) of all nodes.

[0125] The above are all the steps of the preprocessing process. Let's assume

[0126]

[0127]

[0128] Among them, F(x) is the sum of the t-1 degree polynomials F i (x) of all block nodes, and H(x) is the sum of the squares of the t-1 degree polynomials f i (x) of all block nodes. F i (x) is the t-1 degree polynomial F i (x) of the i-th block node, and f i (x) is the t-1 degree polynomial f i (x) of the i-th block node. Then the following equation holds:

[0129] F(x) 2 = H(x) + δ(x) (1-17)

[0130] F i = F(i) (1-18)

[0131] H i = H(i) (1-19)

[0132] Among them, δ(x) is a polynomial with a degree less than or equal to t-1, and P i in the output (F i , H i ) during the preprocessing process are the values of the polynomials F(x) and H(x) at i respectively;

[0133] S18. Output the F i and H i calculated by each node as basic data.

[0134] Regarding the preprocessing process, the following explanations are provided:

[0135] 1) The use of the first-order homomorphic encryption algorithm is necessary. If f j (i) is directly sent to P i for the calculation of H i , P i can combine F j,i to calculate the value of a j,0 , ultimately leading to the risk of forged signatures;

[0136] 2) The calculations in the ciphertext state only appear in Equation (1-11). Multiplication operations are performed in the zero-order ciphertext space, and subtraction operations are performed in the first-order ciphertext. It meets the operation requirements of the first-order homomorphic encryption algorithm. Therefore, the preprocessing process is computationally feasible;

[0137] 3) The introduction of the random number z j,i is to ensure the confidentiality of H i , because only P i can obtain z 1,i , z 2,i , …, z n,i , and calculate H i through t i , while other nodes cannot calculate it;

[0138] 4) provides the data basis for constructing the zero-knowledge proof of the correctness of the output result of the multiplication sub-protocol.

[0139] In the key generation phase described above, all nodes in the blockchain perform joint secret sharing to generate a common signature public key and signature private key fragments corresponding to each node, specifically including the following steps:

[0140] S21. All nodes on the blockchain randomly select the previous t-1 degree polynomial g i (x):

[0141] g i (x) = b i,t-1 x t-1 + … + b i,1 x + s i (2-1)

[0142] where g i (x) is the t-1 degree polynomial of the i-th node, b i is the coefficient, and s i is the constant;

[0143] S22. Each node performs Feldman verifiable secret sharing:

[0144] FSS(s i , gi (x), n, t) = (s i,1 , s i,2 , …, s i,n ) (2 - 2)

[0145] Among them, FSS is the Feldman verifiable secret sharing encryption algorithm, s i,n is the last constant of the nth node polynomial g i (x). Loop through all nodes, j from 1 to n, P i Send s i,j to other nodes P j through a secure channel, and broadcast (b i,t-1 ·G, …, b i,1 ·G, s i ·G);

[0146] S23. Loop through all nodes, j from 1 to n. Each node P i verifies the legality of the secret fragment s j transmitted by other nodes P j,i , that is, determines whether the following equation holds:

[0147]

[0148] If all secret fragments are legal, P i calculates the signature private key fragment sk i and the signature public key gpk as follows:

[0149]

[0150]

[0151] It should be noted that the complete signature private key is and exists in each node in the form of secret fragments.

[0152] In the signature stage, all nodes of the blockchain calculate signature fragments and finally synthesize a complete signature based on the basic data in the preprocessing stage, with the private key fragments corresponding to no less than the signature threshold as the input. The signature process is implemented through a multiplication sub-protocol. Specifically:

[0153] Without loss of generality, let the (n, t)-Shamir secret fragments of the secret L be (l 1 , …, l n ), and the (n, t)-Shamir secret fragments of the secret M be (m 1 , …, m n ), where l i and m i are only known to node P iMaster, (l 1 ·G, …, l n ·G) and (m 1 ·G, …, m n ·G) are publicly known. P i The output of the preprocessing process is (F i , H i ). Through the multiplication sub - protocol, no less than t nodes can obtain the (n, t)-Shamir secret shares (lm 1 , …, lm n ) of LM through one - round interaction. Without loss of generality, assume the number of participating nodes is n. Taking node P i as an example, the running steps are as follows.

[0154] Step 1: P i Calculates and broadcasts x i and y i :

[0155] x i = l i - F i (3 - 1)

[0156] y i = m i - F i (3 - 2)

[0157] Where x i is the ordinate broadcast by the i - th node, and y i is the abscissa broadcast by the i - th node.

[0158] Step 2: Loop through all nodes, j from 1 to n. P i Verifies the legality of the data x j and y j broadcast by P j , that is, verifies whether the following equations hold:

[0159] x j ·G = l j ·G - F j ·G (3 - 3)

[0160] y j ·G = m j ·G - F j ·G (3 - 4)

[0161] Where F j ·G can be calculated from the data broadcast in the preprocessing process.

[0162] Step 3: If the data of at least t nodes is legal (without loss of generality, assume the legal data subscripts are from 1 to t), Pi Calculate X, Y, A i , B i as follows:

[0163]

[0164]

[0165] A i = F i + X (3 - 7)

[0166] B i = F i + Y (3 - 8)

[0167] where X is the vertical coordinate calculated and verified by the verifier, Y is the horizontal coordinate calculated and verified by the verifier, A i is the vertical coordinate for the verifier to verify the i-th node, and B i is the horizontal coordinate for the verifier to verify the i-th node.

[0168] Step 4P i Calculate the (n, t)-Shamir secret fragments lm of the secret LM i as follows:

[0169] lm i = A i B i - H i (3 - 9)

[0170] lm i The proof of legitimacy can be calculated as:

[0171] Mult_zkpf = DLEQ_Gen(G, A i · G, B i · G, lm i · G + H i · G) (3 - 10)

[0172] where Mult_zkpf is a zero-knowledge proof.

[0173] The correctness of the multiplication sub-protocol is proved as follows:

[0174] Theorem 1 The (lm 1 , …, lm n ) generated by the multiplication sub-protocol are the (n, t)-Shamir secret fragments of LM, and Mult_zkpf can guarantee its legitimacy.

[0175] Proof: According to the Shamir secret sharing principle, it only needs to prove lm iIt is the value of a polynomial with degree not exceeding t - 1 and constant term LM at i.

[0176] Combining equations (3 - 1), (3 - 2), (3 - 5) and (3 - 6), we can see that:

[0177]

[0178]

[0179] where is the constant term of F(x).

[0180] According to equations (1 - 18), (1 - 19), (3 - 11) and (3 - 12), we can calculate:

[0181]

[0182]

[0183]

[0184] Combining equation (1 - 16) and equation (1 - 19) again, we can calculate:

[0185]

[0186] Without loss of generality, let Obviously, its degree does not exceed t - 1 and the constant term is LM, and lm i = θ(i), so (lm 1 , …, lm n ) is the (n, t)-Shamir secret fragment of LM.

[0187] The correctness of Mult_zkpf is based on the following equivalence relation:

[0188]

[0189] According to the definition of DLEQ proof, only when P i provides the correct lm i (or lm i ·G), equation (3 - 16) will hold, and the zero - knowledge proof Mult_zkpf can be generated. At the same time, the parameters required for Mult_zkpf verification (i.e., A i ·G, B i ·G and H i ·G) can be generated through broadcast data, and anyone can complete the verification.

[0190] Proof completed.

[0191] In the signature phase, a legal signature is generated through four rounds of interaction. The first round of interaction includes the following steps:

[0192] S311. All nodes of the blockchain randomly select the previous two polynomials of degree t - 1, Fk i (x) and Fγ i (x):

[0193] Fk i (x) = c i,t-1 x t-1 +…+ c i,1 x + kk i (3 - 17)

[0194] Fγ i (x) = d i,t-1 x t-1 +…+ d i,1 x + γγ i (3 - 18)

[0195] Among them, Fk i (x) is the polynomial of degree t - 1, Fk i (x), Fγ i (x) is the polynomial of degree t - 1, Fγ i (x), kk i is the constant term of the polynomial Fk i (x), γγ i is the constant term of the polynomial Fγ i (x), c i,t-1 is the coefficient term of degree t - 1 of the polynomial Fk i (x), c i,1 is the coefficient term of degree 1 of the polynomial Fk i (x), d i,t-1 is the coefficient term of degree t - 1 of the polynomial Fγ i (x), d i,1 is the coefficient term of degree 1 of the polynomial Fγ i (x);

[0196] S312. Each node performs Feldman verifiable secret sharing on kk i and γγ i :

[0197] FSS(kk i , Fk i (x), n, t) = (kk i,1 , kk i,2 , …, kk i,n ) (3 - 19)

[0198] FSS(γγi , Fγ i (x), n, t) = (γγ i,1 , γγ i,2 , …, γγ i,n ); (3 - 20)

[0199] S313. Loop through all nodes, with j from 1 to n. Each node sends the secret fragment kk of Feldman verifiable secret sharing i,j and γγ i,j to other nodes through a secure channel, and broadcasts (c i,t-1 ·G, …, c i,1 ·G, kk i ·G) and (d i,t-1 ·G, …, d i,1 ·G, γγ i ·G), where c i,t-1 is the (t - 1)-th coefficient term of the polynomial Fk i (x), c i,1 is the 1-st coefficient term of the polynomial Fk i (x), d i,t-1 is the (t - 1)-th coefficient term of the polynomial Fγ i (x), and d i,1 is the 1-st coefficient term of the polynomial Fγ i (x);

[0200] S314. Loop through all nodes, with j from 1 to n. Each node verifies the legitimacy of the secret fragments sent by other nodes:

[0201]

[0202]

[0203] where kk j,i and γγ j,i are the verification secret fragments of the secret fragments kk i,j and γγ i,j . If all data is legitimate, each node calculates k i and γi respectively:

[0204]

[0205]

[0206] where k i is the sum of the verification secret fragments kk i,j , and γ i is the sum of the verification secret fragments γγ i,j .

[0207] Let's assume k is used as the random number used in the ECDSA signature algorithm, and γ is used in the Beaver inversion algorithm to solve the point k on the elliptic curve -1 ·G.

[0208] The second round of interaction in the signing phase includes the following steps:

[0209] S321. Loop through all nodes, with j from 1 to n, and each node of the blockchain performs the following calculations by broadcasting data:

[0210]

[0211]

[0212]

[0213] S322, k's (n, t)-Shamir secret fragment is (k 1 ,k 2 ,…,k n ), the (n,t)-Shamir secret fragment of γ is (γ 1 ,γ 2 ,…,γ n ), the (n,t)-Shamir secret fragment of the signature private key sk is (sk 1 ,sk 2 ,…,sk n ), and (k 1 ·G,…,k n ·G)、(γ 1 ·G,…,γ n ·G) and (sk 1 ·G,…,sk n G) is mastered by each corresponding node, and after calculation in step S321, (k 1 ·G,…,k n ·G)、(γ 1 ·G,…,γ n ·G) and (sk 1 ·G,…,sk n G), taking the above data as the input of the multiplication sub-protocol, each node runs the multiplication sub-protocol to calculate the (n, t)-Shamir secret fragments and corresponding legitimacy proofs of kγ and ksk. After the operation, the output of each node is:

[0214]

[0215]

[0216] Among them, \(k\gamma\) is the multiplication of the \(k\)th secret fragment and the \(\gamma\)th secret fragment, \(ksk\) is the multiplication of the \(k\)th secret fragment and the secret fragment of the signature private key \(sk\), \(k\gamma\) i is the multiplication of the \(k\)th secret fragment and the \(\gamma\)th secret fragment on the \(i\)th node of the blockchain, \(ksk\) i is the multiplication of the \(k\)th secret fragment and the key on the \(i\)th node of the blockchain, is the zero-knowledge proof verification of the multiplication of the \(k\)th and \(\gamma\)th secret fragments on the \(i\)th node of the blockchain, is the zero-knowledge proof verification of the multiplication of the \(k\)th secret fragment and the private key on the \(i\)th node of the blockchain.

[0217] The third-round interaction in the signature phase includes the following steps:

[0218] S331. Each node of the blockchain broadcasts the output data \(k\gamma\) of each node after the second-round interaction i , \(ksk\) i ·G, and ;

[0219] S332. Each node verifies whether and hold. If the verification passes, it means that \(k\gamma\) j and \(ksk\) j ·G are legal. After the data of all signature nodes pass the verification, each node calculates \(k\) by Lagrange interpolation method γ :

[0220]

[0221] where, is the zero-knowledge proof for verifying whether holds, is the zero-knowledge proof for verifying whether holds;

[0222] S333. Each node calculates the abscissa \(r\) of point \(R\):

[0223]

[0224] \(r = R_x r = R\) x (3 - 32)

[0225] S334. Each node calculates the signature fragment \(sig\) i :

[0226] \(sig\) i = k i m + ksk i r (3 - 33)

[0227] The fourth round of interaction in the signature phase includes the following steps:

[0228] S341. Each node of the blockchain broadcasts the signature fragment sig i .

[0229] S342. Loop through all nodes, with j from 1 to n, and each node verifies the legality of the signature fragment sig i , that is, determine whether the following equation holds:

[0230] sig j ·G = m·(k j ·G) + r·(ksk j ·G) (3 - 34)

[0231] where sig j is the signature fragment sig i After verification, when the node signature fragments greater than or equal to the signature threshold are verified to be legal (without loss of generality, assume the legal signature fragments are sig 1 , sig 2 , …, sig t ), each node calculates s as follows:

[0232]

[0233] (r, s) is the legal ECDSA signature corresponding to the signature public key gpk, where r is the abscissa of point R and s is the abscissa of the node signature;

[0234] S343. Take (r, s) as the legal ECDSA signature corresponding to the signature public key gpk.

[0235] The present invention consists of three parts: a preprocessing process, a key generation process, and a signature process. The homomorphic encryption algorithm is only used in the preprocessing stage. The signature process has a low computational complexity and only requires four rounds of interaction to generate a legal signature. An account address is generated by the cooperation of all nodes in the blockchain. Each node separately stores a fragment of the account private key. When sending a transaction, one of the nodes constructs the transaction content and sends it to other nodes. Then all nodes run the ECDSA threshold signature algorithm to jointly generate a legal signature for the transaction. Finally, one node broadcasts the signed transaction to the blockchain network. Compared with existing solutions, this algorithm has obvious advantages in terms of performance. When all participating nodes are honest nodes, the single-signature speed can reach the millisecond level. At the same time, the signature process also meets the requirements of fault tolerance and auditability, satisfying the needs of blockchain application scenarios for algorithm reliability and regulatory compliance. The property of optimal threshold makes the node deployment cost lower and the account security higher. In terms of flexibility, the values of the total number of all nodes and the signature threshold can be set arbitrarily to meet different scenario requirements. In terms of anonymity, the locked account generated by the ECDSA threshold signature algorithm has the same data structure and usage method as a normal account, and a legal signature cannot expose the information of the nodes participating in the signature process. In terms of scalability, each transaction is the same as a normal transaction and only needs to carry an ECDSA digital signature, reducing the transaction fee. In summary, the ECDSA threshold signature algorithm can effectively complete cross-chain asset locking, ensure asset conservation, and can be applied to fields such as blockchain account security protection and cross-chain asset locking.

[0236] The experimental analysis of the embodiments of the present invention is as follows:

[0237] The computing platform for the system operation is a Windows 10 OS Laptop, the processor is a 2.50 GHz Intel(R) Core(TM) i7-7660U, the memory is 8G, the programming language is Python, and the underlying elliptic curve selects the Secp256k1 curve widely used in the blockchain. The large number operation and the elliptic curve point addition and doubling operations are completed through the Starkbank-ECDSA library.

[0238] 1) Experimental analysis of the original algorithm: Test the performance of the algorithm under different signature threshold parameters (i.e., t), and count the time of each round of operation and the total operation time of a single node in the signature process. The results are shown in Table 1. The statistical results show that when t increases from 4 to 20, the signature time increases from 1.232 seconds to 19.66 seconds. Considering the current block generation time of different blockchains (such as 10 minutes for Bitcoin), in the case of an unblocked network, the computational efficiency of the algorithm can ensure that there is enough time for the transaction to be broadcast and written into the next block after signing. Therefore, the performance of this solution basically meets the requirements of the application scenario.

[0239] Table 1 Operation time of each round under different threshold parameters

[0240] Threshold parameter First round (seconds) Second round (seconds) Third round (seconds) Fourth round (seconds) Total time (seconds) t＝4 0.260 0.662 0.227 0.082 1.232 t＝8 0.948 1.791 0.477 0.156 3.372 t＝12 2.178 3.464 0.762 0.261 6.665 t＝16 4.744 7.080 0.903 0.342 13.06 t＝20 7.319 10.25 1.522 0.564 19.66

[0241] 2) Experimental analysis of the pre - calculation algorithm: Analyzing the data in Table 1, it can be seen that the time consumed in the first and second rounds of signature accounts for a relatively large proportion of the total running time. The main reason is that multiple elliptic curve multiple - point calculations are required in these two rounds to ensure data legality. Therefore, the signature efficiency can be further improved through pre - calculation, that is, each node pre - executes steps 1, 2, and 3 of the first round before the signature process starts, and calculates the data on the right - hand side of equations (3 - 21) and (3 - 22) and the calculations of equations (3 - 25) and (3 - 26) according to the broadcast data. This greatly reduces the calculation time in the first and second rounds of the signature process. The operation time of the ECDSA threshold optimal signature algorithm after pre - generating data is shown in Table 2. Compared with the original algorithm, the signature time is significantly reduced.

[0242] Table 2 Operation time of each round under different threshold parameters after adding pre - calculation

[0243] Threshold parameter First round (seconds) Second round (seconds) Third round (seconds) Fourth round (seconds) Total time (seconds) t＝4 0.016 0.357 0.219 0.075 0.667 t＝8 0.017 0.942 0.543 0.163 1.665 t＝12 0.018 1.428 0.772 0.233 2.451 t＝16 0.019 1.959 1.111 0.381 3.470 t＝20 0.021 2.573 1.549 0.456 4.599

[0244] 3) Experimental analysis of the algorithm in a secure environment: One application scenario of the ECDSA threshold optimal signature algorithm is to ensure the security of blockchain accounts. In this application scenario, users no longer store the complete account private key, but split it into multiple fragments and store them on different terminals. Each terminal cooperates through the ECDSA threshold signature algorithm to generate a complete signature to complete the transfer. The terminals storing the private key fragments are generally laptops or mobile phones controlled by individual users, and there is no possibility of sending incorrect data. Therefore, the ECDSA threshold optimal signature algorithm runs in a secure environment (that is, there are no malicious nodes), and the calculations for verifying data legality in the algorithm can be omitted to improve the signature efficiency. The operation time of the ECDSA threshold optimal signature algorithm in a secure environment is shown in Table 3. From the data in Table 3, it can be seen that the single - signature generation time is in the millisecond level.

[0245] Table 3 Total operation time of the secure - environment algorithm under different threshold parameters

[0246]

[0247] 4) Comparative analysis with similar algorithms: The signature process of this solution is compared with the existing ECDSA threshold optimal algorithms (GGN16, BGG17, GG18, GG20) in terms of fault tolerance, audibility, and the number of interactions to highlight its design advantages. The comparison results are shown in Table 4.

[0248] Table 4 Comparison of ECDSA threshold optimal signature algorithms

[0249] Scheme Fault tolerance Auditability Number of interactions GGN16 Yes Yes 6 rounds BGG17 Yes Yes 4 rounds GG18 No No <![CDATA[O(t 2 ) wheel]]> GG20 No Yes <![CDATA[O(t 2 ) wheel]]> This scheme Yes Yes 4 rounds

[0250] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as falling within the scope described in this specification.

[0251] The above-described embodiments merely represent several implementation manners of the present invention. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the present invention patent shall be subject to the appended claims.

Claims

1. An ECDSA threshold optimal signature method, characterized in that, it includes three stages: preprocessing, key generation, and signature; Preprocessing stage: Initialize the total number of nodes and signature threshold of the blockchain according to all nodes of the blockchain. All nodes generate the basic data required for the signature stage through Feldman verifiable secret sharing and first-order homomorphic encryption algorithm; including: S11, all nodes of the blockchain randomly select finite fields Two t-1 degree polynomials f i (x) and F i (x) and n random numbers, where q is the group order of the elliptic curve point group; S12. Each node calculates F according to the base point G on the elliptic curve point group and the encryption function TEnc of the threshold first-order homomorphism encryption algorithm i,j , Z ij and and generates zero-knowledge proofs zkpf 1 , zkpf 2 and zkpf 3 , where i = {1, 2, … n} represents the number of blockchain nodes, j represents the current blockchain node member, F i,j is the (t - 1)-th degree polynomial F i (x) corresponding to the j-th node of the blockchain, is the (t - 1)-th degree polynomial f i (x) corresponding to the j-th node of the blockchain through the encryption algorithm, is obtained by encrypting the number randomly generated by the j-th node of the blockchain, Z ij is the position obtained by performing the elliptic encryption algorithm on the number randomly generated by the j-th node of the blockchain, is the position obtained by performing the elliptic encryption algorithm on a number existing in the finite field; S13. Each node transmits F i,j to all nodes of the blockchain through a secure channel and broadcasts Z ij , zkpf 1 , zkpf 2 and zkpf 3 ; S14. After all nodes of the blockchain receive the data sent by other nodes, each node verifies zkpf separately 1 zkpf 2 and zkpf 3 for legality. If all verifications pass, multiply the (t - 1)-th polynomials F i (x) of all blockchain nodes to calculate F i , and calculate the ciphertext S15. All nodes of the blockchain cooperate to decrypt the ciphertext ; S16. Each node respectively transmits the random number z j,i to other nodes through a secure channel; S17. Each node pair z j,i verifies the legality of. If all verifications pass, then calculate the square H of all node t - 1 degree polynomials f j (x) i ; S18. Output the F i and H i calculated by each node as basic data; Key generation phase; all nodes of the blockchain perform joint secret sharing to generate a common signature public key and signature private key fragments corresponding to each node; including: S21, all nodes on the blockchain randomly select a polynomial g of degree t-1 over a finite field i (x); S22. Each node performs Feldman verifiable secret sharing, and each node sends the secret fragment s i,j to other nodes through a secure channel, and broadcasts (b i,t-1 ·G, …, b i,1 ·G, s i ·G), where b i,t-1 is the coefficient term of degree t - 1 of the polynomial g i (x), b i,1 is the coefficient term of degree 1 of the polynomial g i (x), and s i is a constant; S23. Each node verifies the legality of the secret fragments s transmitted by other nodes. When all the secret fragments are legal, each node calculates the signature private key fragment sk j,i and the signature public key gpk; i ​ Signature stage: All nodes in the blockchain calculate signature fragments based on the basic data in the preprocessing stage, using the private key fragments corresponding to the signature nodes greater than or equal to the signature threshold as inputs, and finally synthesize a complete signature; The first round of interaction in the signature stage includes the following steps: S311. All nodes of the blockchain respectively randomly select two polynomials \(F_{k}(x)\) and \(F_{\gamma}(x)\) of degree \(t - 1\) over a finite field. of degree \(t - 1\) i \((x)\) and \(F_{\gamma}\) i \((x)\); S312. Each node performs Feldman verifiable secret sharing on the constant term kk of the polynomial Fk i (x) and the constant term γγ of the polynomial Fγ i (x); i (x) i ​ S313. Each node sends the secret fragment kk of the Feldman verifiable secret sharing i,j and γγ i,j to other nodes through a secure channel, and broadcasts (c i,t-1 ·G, …, c i,1 ·G, kk i ·G) and (d i,t-1 ·G, …, d i,1 ·G, γγ i ·G), where c i,t-1 is the (t - 1)-th coefficient term of the polynomial Fk i (x), c i,1 is the 1-st coefficient term of the polynomial Fk i (x), d i,t-1 is the (t - 1)-th coefficient term of the polynomial Fγ i (x), d i,1 is the 1-st coefficient term of the polynomial Fγ i (x); S314. Each node verifies the legality of the secret fragments kk i,j and γγ i,j sent by other nodes. If all the data are legal, each node calculates the sum k j,i of the verified secret fragments kk i and the sum γ j,i of the verified secret fragments γγ i respectively. At the same time, k is used as the random number in the ECDSA signature algorithm, and γ is used to solve the point k -1 ·G on the elliptic curve in the Beaver inverse algorithm; The second round of interaction in the signature stage includes the following steps: S321. Each node of the blockchain calculates the secret fragment k of k by broadcasting data respectively j · the secret fragment γ of G, γ j · the secret fragment sk of G and the signature private key sk j · G; S322. Take the (k 1 ·G, …, k n ·G), (γ 1 ·G, …, γ n ·G) and (sk 1 ·G, …, sk n ·G) as the inputs of the multiplication sub - protocol. Each node runs the multiplication sub - protocol to multiply the secret fragments of k and the secret fragments of γ to calculate kγ, and multiply the secret fragments of k and the secret fragments of the signature private key sk to calculate the (n, t)-Shamir secret fragments of ksk and the corresponding legitimacy proofs. After the operation, the output of each node is: Among them, kγ i is the multiplication of the k secret fragment and the γ secret fragment on the i-th node of the blockchain, and ksk i is the multiplication of the k secret fragment and the key on the i-th node of the blockchain, is the zero-knowledge proof to verify the multiplication of the k and γ secret fragments on the i-th node of the blockchain, is the zero-knowledge proof to verify the multiplication of the k secret fragment and the private key on the i-th node of the blockchain; The third round of interaction in the signature stage includes the following steps: S331. Each node of the blockchain broadcasts the output data kγ i , ksk i ·G, and after the second round of interaction; S332. Each node verifies and whether it holds. If the verification passes, it indicates that kγ j and ksk j ·G is legal. After the data verification of all signature nodes passes, each node calculates kγ by Lagrange interpolation method, where is a zero-knowledge proof for verifying whether it holds, is a zero-knowledge proof for verifying whether it holds; S333. Each node calculates the abscissa r of point R; S334. Each node calculates the signature fragment sig i ; The fourth round of interaction in the signature stage includes the following steps: S341. Each node of the blockchain broadcasts the signature fragment sig i ; S342. Each node verifies the legality of the signature fragment sig i After the signature fragments of more than or equal to the signature threshold number of nodes are verified to be legal, each node calculates the abscissa s of the node signature; S343. Take (r, s) as the legal ECDSA signature corresponding to the signature public key gpk.

2. The ECDSA threshold optimal signature method according to claim 1, characterized in that, before the preprocessing stage, first determine that all nodes share the same elliptic curve addition group parameters; establish a secure channel and share a broadcast channel among all nodes in the blockchain; and all nodes share the same first-order homomorphic encryption algorithm parameters.

Images