Non-interactive threshold signature scheme under asynchronous BFT block chain

Abstract

The invention provides a non-interactive threshold signature scheme under an asynchronous BFT block chain. An existing threshold signature scheme generally depends on multiple rounds of interaction, verification of signature fragments and zero-knowledge proof depends on an interaction mode, communication overhead in an asynchronous network environment is large, the robustness requirement cannot be met in the signature process, and a protocol needs to be restarted under the condition that signature verification fails. Therefore, according to the scheme, a non-interactive mode is adopted for communication in each process, each node can still enter the next stage without waiting for the response of other nodes when sending and broadcasting the communication information, the number of communication rounds is remarkably reduced, and the method can adapt to a high-delay asynchronous network. By arranging the signature aggregator, when the honest signature node number meeting the threshold value exists, the aggregator can generate a signature, node verification errors can be tolerated, and the robustness requirement is met. Therefore, the scheme can adapt to an asynchronous block chain network environment, and has the characteristics of high robustness, high fault tolerance and non-interaction.

Description

Technical Field

[0001] The technical fields involved in this application include asynchronous BFT blockchain and threshold signature technology. In order to adapt to the application scenarios of asynchronous BFT consensus blockchain, this application proposes a non-interactive threshold signature scheme suitable for asynchronous BFT blockchain. Background Art

[0002] Currently, blockchain technology has been widely applied in a variety of fields, including decentralized finance (DeFi), supply chain management, and the Internet of Things (IoT). Blockchain systems typically rely on cryptography to ensure the security and immutability of transactions. Digital signatures are the core mechanism for blockchain transaction verification. However, in a multi-party collaborative blockchain environment, traditional single-signature schemes have significant communication and storage overhead, making them difficult to meet high throughput requirements. Therefore, to improve blockchain signature efficiency and reduce communication costs, threshold signature technology has become a key optimization solution.

[0003] Threshold signature technology allows n members to share a public key and sets a threshold value t, so that the joint participation of at least t+1 members can generate a valid signature, while a subset of less than t+1 members cannot generate a valid signature. In blockchain systems, threshold signature schemes are often used for multi-party control of accounts (such as multi-signature wallets) or consensus protocols (such as leader election in Byzantine fault tolerance mechanisms). However, existing threshold signature schemes still have the following problems:

[0004] High interactivity and communication overhead: Existing threshold signature schemes typically require multiple rounds of interaction between participants during the signature generation process to ensure security and correctness. For example, threshold signature participants must mutually verify signature fragments, perform zero-knowledge proofs, or negotiate random numbers. This not only increases communication costs but also makes the system unstable in the face of high network latency or node failures. Furthermore, if some participants fail to respond promptly during the signing process, the entire signing process may need to be restarted, further reducing efficiency.

[0005] Difficulty adapting to asynchronous BFT blockchain environments: In asynchronous Byzantine Fault Tolerant (BFT) blockchains, message transmission between nodes may be subject to varying degrees of delay. Many existing threshold signature schemes rely on the synchronous communication assumption, assuming that all messages can be delivered within a certain timeframe. Therefore, in practical applications, when network latency is high or some nodes fail, these schemes may fail to generate valid signatures, impacting system availability. Furthermore, existing threshold signature schemes typically require complex consensus protocols to ensure security in the face of Byzantine attacks, which often incur additional computational and communication overhead.

[0006] Vulnerable to Denial of Service (DoS) attacks and high storage and verification overhead: Because most threshold signature schemes rely on interactive protocols, malicious nodes can launch Denial of Service (DoS) attacks by refusing to respond, sending forged messages, or delaying communication, hindering the normal generation of signatures. Furthermore, in a blockchain system, the signature of every transaction is stored and requires verification. Traditional threshold signature schemes typically require the storage of multiple intermediate signature fragments and a complex verification process, increasing storage and computational overhead and hindering the efficient operation of the blockchain system.

[0007] This application expands on the elliptic curve digital signature (ECDSA) and designs a scheme that supports non-interactive signature generation, threshold verification, and signature aggregation, enabling it to operate efficiently in an asynchronous BFT blockchain environment and meet the requirements of high throughput, low communication cost, and high security. Summary of the Invention

[0008] This application provides a non-interactive threshold signature scheme under an asynchronous BFT blockchain, which is used to solve the problem of insufficient adaptability of threshold signature schemes in current asynchronous BFT consensus blockchain scenarios and effectively reduce the number of signature rounds required for threshold signature schemes.

[0009] The present application provides a complete non-interactive threshold signature scheme under an asynchronous BFT blockchain in an embodiment, which includes the following steps: 1) Signature shard private key generation phase: among the signature node set in the blockchain, a random number and a random polynomial are selected from a finite field, and shares are distributed by combining the Shamir secret sharing technology. After each signature node receives the polynomial shares sent by other nodes and verifies them, it accumulates its own signature shard private key and calculates its own signature shard public key; 2) Pre-signature phase: after each member of the signature node set obtains the signature shard private key from the signature shard private key generation phase, it selects a random number from a finite field, calculates the pre-signature additive share by converting the random number and the signature shard private key through the MtA (Multiplicative to Additive) share conversion protocol, and converts the pre-signature additive share through the AtT (Additive to 3) Online signing phase: After the pre-signature phase is completed and the transaction information M arrives, each member of the signing node set uses the pre-signature threshold share to participate in the online signing phase. When the number of honest nodes reaches the threshold value, the threshold signature parameters are reconstructed to generate the threshold signature and complete the signing.

[0010] In one embodiment of the present application, the signature shard private key generation stage further includes: each member in the signature set selects a random number within a finite field to generate a Paillier homomorphically encrypted public-private key pair and a secret private key, uses the secret private key as a constant term to generate a polynomial, calculates the public key corresponding to the secret private key and the commitment of the public key, broadcasts the commitment of the public key, calculates the polynomial shares and verification tuples of other nodes through the polynomial, sends the polynomial shares to other nodes and broadcasts the verification tuple, and after receiving the polynomial shares and verification tuples sent by other nodes, the signing node verifies the correctness of the polynomial shares through the verification tuple, and after the consistency is verified, accumulates and calculates its own signature shard private key, and calculates the corresponding signature shard public key.

[0011] In one embodiment of the present application, the pre-signature phase further includes: a node in the signature node set selects two random numbers from the domain, and uses the signature shard private key obtained in the signature shard private key generation phase to perform a calculation of the MtA share conversion protocol to obtain an additive pre-signature share for signing, wherein the security and correctness of the calculation process are guaranteed by zero-knowledge range proof and Paillier homomorphic encryption. After performing the MtA protocol, three pre-signature additive shares can be obtained, and the three pre-signature additive shares are used as a pre-signature additive vector. The pre-signature additive vector is used as a constant term in a vector polynomial, and shares are distributed through the vector polynomial. The vector polynomial shares and check tuples of other nodes are calculated, and the check tuples are broadcast. After receiving the vector polynomial shares and check tuples sent by other nodes, the signature node verifies the vector polynomial through the check tuple, and calculates the pre-signature threshold share after the consistency requirements are met.

[0012] In one embodiment of the present application, the online signing stage further includes: after the nodes in the signing node set obtain the pre-signature threshold share and transaction information M from the pre-signature stage, they participate in the online signing stage, each node encrypts its own pre-signature threshold share, calculates zero-knowledge proof and commitment, broadcasts the zero-knowledge proof and commitment, and sends the encrypted threshold share to the aggregator. The aggregator verifies the identity through zero-knowledge proof and commitment to ensure the honesty of the node. When the number of honest nodes reaches the threshold signature that can be generated, the ciphertext is decrypted, and the pre-signature threshold share is restored through the Lagrange interpolation method to obtain the parameters used to generate the signature, and finally the threshold signature is calculated.

[0013] Therefore, the embodiments of the present application have the following beneficial effects:

[0014] 1) In the embodiments of the present application, each stage does not involve the process of interaction between nodes to run. Each node can asynchronously generate its own information and send it to other nodes without waiting for other nodes to respond. The signer can generate partial signatures without interaction, which reduces communication overhead and improves efficiency. It is particularly suitable for high-throughput blockchain environments.

[0015] 2) In the embodiments of the present application, the present application is applicable to an asynchronous BFT blockchain, enabling the system to operate correctly in an asynchronous network, resist Byzantine attacks, while maintaining decentralization and security.

[0016] 3) In the embodiments of the present application, the non-interactive nature of the present application reduces communication requirements, making the solution less susceptible to denial of service (DoS) attacks and improving network stability. Threshold signatures can efficiently aggregate partial signatures, reduce storage and verification overhead, and help improve the transaction throughput of the blockchain.

[0017] This application further explains the present solution and its beneficial effects in detail in the accompanying drawings and specific implementation methods, making this application more obvious and easy to understand. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 .This figure is a three-stage flow chart of the non-interactive threshold signature of this application.

[0019] Figure 2 .This figure shows the main communication process of the signature sharding private key generation stage of this application.

[0020] Figure 3 .This figure shows the main communication process of the pre-signature stage of this application.

[0021] Figure 4 This figure shows the main communication process of the online signing phase of this application. It should be noted that the trusted signature aggregator contains a counter count for verifying the node passing. When t+1 (i.e., count=t+1) are met, the main parameters for generating the signature can be reconstructed.

[0022] Specific embodiment

[0023] The embodiments of the present application will be described in detail below. The examples are all indicated in the accompanying drawings. The same or similar symbols and numbers in the present application represent the same or similar meanings. The drawings of the present application are all used to explain the present application and cannot be understood as limiting the present application.

[0024] For the convenience of explaining this application, it is assumed that the signature node set is {P|P1, P2, ..., P n}, the total number of nodes is n, the threshold value is t, and the threshold signature can be generated when t+1 nodes are satisfied, and the number of nodes that the adversary can control cannot exceed t.

[0025] The symbolic parameters involved in the embodiments of the present application are shown in Table 1. Incomplete parameters shown in Table 1 will be explained later.

[0026]

[0027] In the specific embodiment of the present application, the node P i From the perspective of P i For example, at the beginning, the public parameters params←Gen(1 λ ),in The entire solution of this application will be explained in more depth later.

[0028] make is the elliptic curve group A tuple of generator G and group order q, where q is a prime number. Each element in the elliptic curve group Both are represented as a pair (b x ,b y ), where b x is the projection of b on the x-axis, b y is the projection of b on the y-axis, let π: Represented as point Mapped to b x The function of modq, let H: is a hash function.

[0029] Specifically, the specific process of the signature shard private key generation stage is as follows:

[0030] S1-1: Signature Node P i From a finite field Select random number Calculate the Paillier encryption public key N i =P i Q i , calculate χ i (N) = lcm(P i -1,Q i -1), select a random number Define the function L(x) = (x-1) / N i ,calculate Get the encrypted public key ek i =(N i ,g i ) and decryption private key dk i =(χ i ,εi ), the encrypted public key ek i broadcast;

[0031] S1-2: Signature Node P i From a finite field Random number selection Calculation verification element U i =μ i G, and calculate the verification element's commitment and opening commitment [SKGC i ,SKGD i ]=Com(U i ), the verification element U i and commitment to SKGC i broadcast;

[0032] S1-3: Commitment opening phase, signature node P i Send Open Commitment SKGD i , node P i After receiving the open commitment from other nodes, if Verify(SKGC i ,SKGD i ,U i )=1, accept, otherwise ignore;

[0033] S1-4: Signature Node P i The random number μ i As a constant term of a local polynomial, and generate a local polynomial where a ik are randomly and uniformly taken from a finite field Then calculate the share and checksum tuple {A i1 ,...,A ik ,...,A it |A ik =a ik G}, node P i The polynomial fraction f i (ID j ) is sent to node P j , and the check tuple {A i1 ,...,A ik ,...,A it |A ik =a ik G} for reliable broadcasting;

[0034] S1-5: Signature Node P i Receive the polynomial share and verification tuple from other nodes, and verify the polynomial share through the verification tuple: through the formula Verify and calculate the polynomial share. If Verify(f j (ID i ),A j1 ,...,A jk ,...,A jt ,U j )=1, then pass, otherwise ignore the polynomial share;

[0035] S1-6: When the signature node P i After receiving and verifying the polynomial shares of all other nodes, calculate your own signature shard private key And calculate your own signature shard public key pk i =sk i G, the signature shard public key pk i Reliable broadcasting.

[0036] Specifically, the specific process of the pre-signature stage is as follows:

[0037] S2-1: Signature Node P i From a finite field Uniformly randomly select random numbers Calculate a random point F on the elliptic curve i =γ i G, a random point F on the elliptic curve i Calculate Commitment and Open Commitment [PC i ,PD i ]=Com(F i ), and the elliptic curve random point F i and promises to broadcast PC i ; Using the public key ek encrypted with Paillier homomorphic encryption i For random numbers (k i ,γ i ) and signature shard private key sk i Encrypt the ciphertext c a (a=k i ,γ i ,sk i ) is sent to node P j , calculate the zero-knowledge range proof ZK of the ciphertext rangeproof {a|a<q 3 ,c a}, and broadcast the zero-knowledge range proof;

[0038] S2-2: Commitment opening phase, signature node P i Send Open Commitment PD i , node P i After receiving the open commitment from other nodes, if Verify(PCi ,PD i ,F i )=1, then accept, otherwise ignore. After receiving the elliptic curve random points of all other nodes, calculate Broadcast F;

[0039] S2-3: Signature Node P i The random number (k i ,γ i ) and other nodes P j Perform MtA protocol calculation, node P i Upon receiving node P j The encrypted data c a (a=k j ,γ j ,sk j ) and then randomly select a random number from the finite field Homomorphic Computation Computing Zero-Knowledge Range Proofs and broadcast the zero-knowledge range proof;

[0040] S2-4: Signature Node P i The random number (k i ,sk i ) and other nodes P j Perform MtA protocol calculation, node P i Upon receiving node P j The encrypted data c a (a=k j ,γ j ,sk j ) and then randomly select a random number from the finite field Homomorphic Computation Computing Zero-Knowledge Range Proofs and broadcast the zero-knowledge range proof;

[0041] S2-5: Signature Node P i After receiving the zero-knowledge range proof and encrypted data sent by other nodes, verify the zero-knowledge range proof, Verify(ZK rangeproof )=1, decrypt the data to get and The result is used to calculate the threshold additive share and

[0042] S2-6: Signature Node P i The threshold additive share is taken as a vector a=(k i ,δ i ,σ i ), from a finite field Select random vector polynomials to get fi (x) = a + bx + ... + b t x t , calculate the verification elliptic curve random point vector U′ of vector a i =a·G=(k i ·G,δ i ·G,σ i G) and commitments and open commitments to elliptic curve random point vectors [AtTC i ,AtTD i ] = Com(U′ i ), Broadcast Commitment AtTC i and U′ i ;

[0043] S2-7: Commitment opening phase, signature node P i Send Open Commitment AtTD i , node P i After receiving the open commitment from other nodes, if Verify(AtTC i ,AtTD i ,U i ') = 1, then accept, otherwise ignore;

[0044] S2-8: Signature Node P i Calculate polynomial share vector and the corresponding check tuple vector {A i1 ,...,A ik ,...,A it |A ik =b ik G}, node P i The polynomial share vector f i (ID j ) is sent to node P j , and the check tuple {A i1 ,...,A ik ,...,A it |A ik =b ik G} for reliable broadcasting;

[0045] S2-9: Signature Node P i Receive the polynomial share vector and check tuple vector from other nodes, and verify the polynomial share vector through the check tuple vector: through the formula Verify and calculate the polynomial share. If Verify(f j (ID i ),A j1 ,...,A jk ,...,A jt,U′ j )=1, then the polynomial is passed; otherwise, the polynomial share is ignored.

[0046] S2-10: When the signature node P i After receiving and verifying the polynomial share vectors of all other nodes, calculate your own threshold signature share

[0047] Specifically, the online signing process is as follows:

[0048] S3-1: When a transaction message M arrives, the signature node P i The confidential data of the threshold signature share is sent to the trusted signature aggregator; the threshold signature share is calculated Elliptic curve random verification point and corresponding commitments and open commitments [SC i ,SD i ]=Com(US i );

[0049] S3-2: Signature Node P i Calculate threshold signature share Zero-knowledge proof of calculation Public key From a finite field Select random number r1 to calculate challenge e1 = Hash(H1, H2), where H2 = r1·G, and get zero-knowledge proof proof1 = ZK{H1, H2, z1}, where And broadcast the zero-knowledge proof;

[0050] S3-3: Signature Node P i Calculate threshold signature share Zero-knowledge proof of calculation Public key From a finite field Select random number r2 to calculate challenge e2 = Hash(H3,H4), where H4 = r2·G, and get zero-knowledge proof proof2 = ZK{H3,H4,z2}, where And broadcast the zero-knowledge proof;

[0051] S3-4: The trusted signature aggregator receives the signature node P i After verifying the information, if Verify(SC i ,SD i ,US i)=1, accept, otherwise ignore; Verify(proof1)={e1=Hash(H1,H2),z·G?=H2+e1·H1}, if Verify(proof1)=1, accept, otherwise ignore; Verify(proof2)={e2=Hash(H3,H4),z·G?=H4+e2·H3}, if Verify(proof2)=1, accept, otherwise ignore;

[0052] S3-5: When the number of nodes that have passed the verification reaches t+1, the t+1 pre-signed threshold shares Reconstruct and restore using Lagrange interpolation method to obtain (k,δ,σ) where Finally, calculate the point R=δ -1 F, r = R x , m = Hash (M), s = mk + rσ, get the threshold signature (r, s), broadcast the threshold signature (r, s);

[0053] S3-6: Threshold Signature Verification

[0054] Verify(r,s,∑pk i ,m):

[0055] R′=(s -1 m)·G+(s -1 r)·(∑pk i )

[0056] =(s -1 m)·G+(s -1 r)·(∑sk i ·G)

[0057] =(s -1 m)·G+(s -1 r·sk)·G

[0058] =(s -1 (m+rsk))·G

[0059] =k -1 ·G

[0060] We get r′=R x ′, if r′=r, the verification is successful, otherwise the signature fails. It is worth noting that σ=k·sk, so it can be calculated correctly. In addition, the consistency verification of R is as follows:

[0061]

[0062]

[0063] It should be noted that none of the three stages above involve an interactive signing process. After the aggregator receives information from other signing nodes, it verifies and calculates the threshold signature and broadcasts it. Furthermore, when the threshold value t+1 is met, the signature can be calculated and generated without waiting for all nodes to broadcast information. Even if a node verification error occurs, a complete threshold signature can still be generated. This ensures that the solution of this application meets robustness requirements and is tolerant to corrupt signing nodes.

Claims

1. A non-interactive threshold signature scheme technology in an asynchronous BFT blockchain, characterized by the following Basic process: Signature shard private key generation phase: The signing node generates a homomorphically encrypted public-private key pair, selects a random number for distributed polynomial secret sharing, and distributes polynomial shares with other nodes in the signature set to generate a shard private key for signing. Pre-signing phase: Each signing node selects multiple random numbers and signature shard private keys to perform multiplication-to-addition calculations with other nodes in the signing node set to generate additive pre-signed shares. Subsequently, the additive pre-signed shares are converted into threshold pre-signed shares through the additive-to-threshold protocol. Signing phase: All nodes in the signing node collection encrypt the threshold pre-signed share, generate corresponding commitments and zero-knowledge proofs, send the verification information and ciphertext to the signature aggregator, and generate a threshold signature.

2. The method according to claim 1, characterized in that In the design of the signature shard private key generation stage, each signing node uses Paillier homomorphic encryption and a t-order univariate polynomial to generate a signature shard private key and a shard public key, and uses the generated signature shard public keys to accumulate and add them together for threshold signature verification. The signature shard private key generation process adopts a non-interactive method, and each node can complete the calculation independently at different times, which can avoid the impact of delays on the calculation.

3. The method according to claim 1, characterized in that The pre-signature stage design transforms the interactive multiplication-to-addition protocol into a non-interactive multiplication-to-addition protocol. Signature nodes can each generate additive pre-signature shares. An additive-to-threshold protocol is designed, and vector polynomials are used to convert the properties of the shares. This improves the efficiency of the entire conversion process and reduces communication overhead.

4. The method according to claim 1, wherein The online signature stage design adopts a non-interactive design. Each node sends all the calculated ciphertext and verification information to the signature aggregator. The signature aggregator uses the Lagrange interpolation formula to reconstruct the node information that meets the threshold value, obtains the parameters for calculating the signature, and finally calculates the threshold signature.

5. The method according to claim 1, characterized in that The method is applicable to asynchronous BFT blockchains, can operate correctly in asynchronous network environments, and resist Byzantine attacks. Even if some nodes fail or act maliciously, legal threshold signatures can still be generated.

6. The method according to claim 1, characterized in that The signature aggregation stage reduces storage and computational overhead, improves the throughput of blockchain transactions, and is suitable for high-concurrency application scenarios.

Images