A method, system and node for implementing distributed key generation on a blockchain

Abstract

A method for realizing distributed key generation on a blockchain, comprising: S1: each node generates n secret shares, retains one share itself, and encrypts the remaining n-1 secret shares with a receiver key; each node generates a public verification parameter corresponding to its own secret share; each node generates a third zero-knowledge proof that its own secret share matches the corresponding public verification parameter; S2: each node sends the secret share, the public verification parameter, and the third zero-knowledge proof generated by itself to an on-chain contract through the same transaction or different transactions; S3: the on-chain contract verifies that the encrypted secret share and the corresponding public verification parameter match through the third zero-knowledge proof; and S4: each node obtains the verified secret share with the receiver being itself from the contract information, decrypts the secret share with its own key, and calculates its own private key share in combination with the local secret share.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method, system and node for implementing distributed key generation on a blockchain. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a method, system, and node for implementing distributed key generation on a blockchain, including:

[0004] A method for implementing distributed key generation on a blockchain includes:

[0005] S1: Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares with the receiver's key; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0006] S2: Each node sends its own generated secret share, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same or different transactions;

[0007] S3: The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match using a third zero-knowledge proof;

[0008] S4: Each node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0009] A method for implementing distributed key generation on a blockchain includes:

[0010] S1: Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares with the receiver's key to generate a first zero-knowledge proof that can be decrypted; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0011] S2: Each node can send the secret share and the corresponding first zero-knowledge proof, public verification parameters, and the third zero-knowledge proof that the secret share matches the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions;

[0012] S3: The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof, and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof;

[0013] S4: Each node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0014] A blockchain system comprising several nodes, wherein:

[0015] Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0016] Each node sends its own generated secret share, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same or different transactions;

[0017] The on-chain contract verifies that the encrypted secret share matches the corresponding public verification parameters using a third zero-knowledge proof.

[0018] Each node obtains a verified secret share from the contract information, with itself as the recipient, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0019] A blockchain system comprising several nodes, wherein:

[0020] Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares with the receiver's key to generate a first zero-knowledge proof that can be decrypted; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0021] Each node can send the secret share, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that the secret share matches the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions;

[0022] The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof.

[0023] Each node obtains a verified secret share from the contract information, with itself as the recipient, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0024] The first node in a blockchain system includes:

[0025] The first node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; the first node generates public verification parameters corresponding to its own secret shares; the first node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters;

[0026] The first node sends its own generated secret share, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same transaction or different transactions;

[0027] The on-chain contract verifies that the encrypted secret share matches the corresponding public verification parameters using a third zero-knowledge proof.

[0028] The first node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with the local secret share.

[0029] The first node in a blockchain system includes:

[0030] The first node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key, generating a first zero-knowledge proof that can be decrypted; the first node generates public verification parameters corresponding to its own secret shares; the first node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0031] The first node can send the secret share, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that the secret share matches the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions.

[0032] The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof.

[0033] The first node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with the local secret share.

[0034] In the above embodiment, for n nodes, the secret share generated by each node is encrypted and sent to the on-chain contract. The message complexity is n, thereby avoiding point-to-point encrypted transmission between nodes, i.e., avoiding n 2 The message complexity is reduced, which can significantly decrease the number of messages. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram of the conventional stage of a practical Byzantine fault-tolerant algorithm in one embodiment;

[0037] Figure 2 This is a schematic diagram of the view switching phase of a practical Byzantine fault-tolerant algorithm in one embodiment;

[0038] Figure 3 This is a schematic diagram of the normal phase of a practical Byzantine fault-tolerant algorithm in one embodiment where none of the consensus nodes have failed;

[0039] Figure 4 This is a schematic diagram of the block structure in one embodiment of this specification;

[0040] Figure 5 This is a flowchart illustrating the generation of a random number seed on a blockchain in one embodiment of this specification;

[0041] Figure 6 This is a schematic diagram of the block header structure in one embodiment of this specification;

[0042] Figure 7 This is a method for implementing distributed key generation on a blockchain in one embodiment of this specification;

[0043] Figure 8 This is a method for implementing distributed key generation on a blockchain in one embodiment of this specification;

[0044] Figure 9 This is a method for implementing distributed key generation on a blockchain in one embodiment of this specification. Detailed Implementation

[0045] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0046] The DKG (Distributed Key Generation) protocol is a distributed protocol that generates a set of keys through collaboration among multiple participating parties. The VSS (Verifiable Secret Sharing) protocol is a crucial theoretical foundation of the DKG protocol.

[0047] VSS (Virtual Private Server) refers to the sharing of secret data among multiple participants. Without revealing the secret data itself, the data can be divided into multiple fragments, with each participant holding one fragment. Later, when the secret data needs to be restored, all fragments must be collected to successfully reconstruct the complete data.

[0048] The VSS protocol was first proposed by Shamir in 1979 and is a secret-sharing protocol based on polynomials. The VSS protocol evolved from Shamir's Secret Sharing (SSS), so Shamir's Secret Sharing will be introduced first.

[0049] Shamir's secret sharing consists of two phases: secret sharing (or secret distribution) and secret reconstruction. It first requires a Dealer to construct a polynomial:

[0050] f(x) = a0 + a1x + a2x 2 +…+a n x n Polynomial(*)

[0051] Where a0 is the secret data to be shared.

[0052] This nth-degree polynomial is composed of a set of coefficients (a0, a1, a2, ..., a...). n This set of coefficients is uniquely determined to include n+1 values. Thus, if the curve corresponding to this nth-degree polynomial is known to pass through n+1 distinct points on the plane, then the coordinates of these n+1 distinct points (x1, y1), (x2, y2), ..., (x...) are obtained. n ,y n ),(x n+1 ,yn+1 Then, we can obtain a system of (n+1) linear equations with n+1 variables, and from this system of equations, we can determine the n+1 coefficients a0, a1, a2, ..., a n The values ​​of are then used to determine the polynomial (*), ultimately leading to the value of the secret data a0. The coordinates of the above n+1 distinct points are (x1, y1), (x2, y2), ..., (x...). n ,y n ),(x n+1 ,y n+1 This means there are n+1 secret slices.

[0053] The process of finding a curve passing through a given set of points is called polynomial interpolation. There are various methods for polynomial interpolation; the following introduces a common method: Lagrange interpolation. Given an nth-degree polynomial*, the curve corresponding to this polynomial is known to pass through n+1 points (x1, y1), (x2, y2), ..., (x...). n ,y n ),(x n+1 ,y n+1 Given the coordinates of the curve, the polynomial of the nth degree curve can be obtained using Lagrange interpolation as follows:

[0054]

[0055] Polynomial (**) and polynomial (*) are actually equivalent. In polynomial (*), if x = 0, then f(0) = a0, which gives the value of the secret data a0. Therefore, in polynomial (**), if x = 0, the value of the secret data a0 can also be obtained, i.e., f(0) = a0.

[0056] In summary, we can arbitrarily select n+1 points on the polynomial and share these n+1 points among the n+1 participants, for example, each participant receives the coordinates of one point. Collecting the coordinates of any fewer than n+1 points will not reveal the original secret data a0; only after obtaining all n+1 points can the value of the secret data a0 be reconstructed by reconstructing the polynomial coefficients. Furthermore, even if the coordinates of any fewer than n+1 points are collected, such as the coordinates of n points, since there are infinitely many nth-degree curves passing through these n points, probabilistically, the value of the secret data a0 will not be leaked. Here, the degree n is also called the degree of the polynomial.

[0057] Building upon this, threshold Shamir secret sharing can be implemented. For example, t-of-n secret sharing involves sharing a secret among n participants, with a threshold t defined as the minimum number of secret fragments required for recovery. For instance, in a four-party transaction, if the threshold is set to 3 (n=4, t=3), the secret can only be recovered if at least three participants provide their own secret fragments; otherwise, recovery is impossible. Specifically, a polynomial of degree t-1 = 2 can be constructed:

[0058] f(x) = a0 + a1x + a2x 2 Polynomial (***)

[0059] The curve corresponding to this 2-degree polynomial passes through four distinct points on the plane, i.e., the coordinates of these four points are (x1, y1), (x2, y2), (x3, y3), and (x4, y4). During the secret sharing phase, these coordinates are distributed to each of the four participants. Let's call the four participants Party1, Party2, Party3, and Party4. Assume Party1 has a slice (x1, y1), Party2 has a slice (x2, y2), Party3 has a slice (x3, y3), and Party4 has a slice (x4, y4). Since the polynomial (**) can be determined by any three points on the corresponding curve, Party... i In the sequence (i∈{1,2,3,4}), when any three participants provide their own secret fragments, the polynomial (***) can be reconstructed during the secret reconstruction phase, thus yielding the secret value a0. When fewer than three participants provide their own secret fragments, the polynomial (***) cannot be reconstructed, and therefore the secret value a0 cannot be obtained. The t mentioned above is also called the threshold.

[0060] The aforementioned Shamir secret sharing and threshold Shamir secret sharing require a role that generates the polynomial and distributes the secret shards; this role can be called a Dealer. This Dealer is an entity that knows the secret and needs to be a trusted third party among all participants. Additionally, an entity is needed to aggregate at least the threshold shards and obtain the secret; this could be the Dealer, a participant, or another entity.

[0061] In engineering practice, polynomials are often defined in finite fields (based on elliptic curves or discrete logarithms) or prime fields (based on RSA), rather than in the real number field or the natural number field.

[0062] The classic Shamir secret-sharing scheme assumes that the participants are honest. However, dishonest or malicious behavior is possible, such as a dealer deceiving one or more participants by sending them incorrect secret fragments.

[0063] In secret sharing, to address the issue of malicious behavior verification, such as verifying whether a participant has deceived the dealer (as mentioned above, verifying whether the dealer sent an incorrect secret fragment), Verifiable Secret Sharing (VSS) has been proposed. Feldman VSS is a practical VSS scheme based on Shamir's secret sharing approach, which includes:

[0064] The Dealer has a secret and distributes n shards of this secret to n participants, where t participants can reconstruct the secret. A threshold Shamir secret-sharing scheme similar to the one described above can be used to construct a t-1 degree polynomial:

[0065] f(x) = a0 + a1x + a2x 2 +…+a t-1 x t-1 Polynomial (****)

[0066] The dealer provides each participating party with a party. i Choose any non-zero x i Calculate s i =f(x) i ), and sub-secrets i Encrypted and sent to the participants of Party i Meanwhile, Dealer calculates... Where j = 0, 1, 2, ..., t-1, and A is publicly disclosed. j That is, to disclose {A0,A1,A2,…,A} t-1}. A j Also known as public validation parameters. Here, A j The method for generating A is the same as the method for generating a public key based on a private key on an elliptic curve. Therefore, A j It can also be called public key sharding or public key sharing.

[0067] For the case where the selected polynomial corresponds to an elliptic curve, disclose A. j It is safe because, according to the properties of elliptic curves, it is impossible to determine the result based on A. j By reverse reasoning, we can obtain a j .

[0068] Public validation parameters {A0, A1, A2, ..., A t-1This is also called a commitment. Because the commitment is tied to the coefficients of the polynomial, it can be used to verify whether a value of the polynomial is correct. In the implementation based on discrete logarithms, g is the generator of the cyclic group over the finite field. g can be a value in the Dealer and Party... i These are pre-configured. The aforementioned sub-secrets can also be called secret shares.

[0069] The participating parties received the sub-secrets i Then, common validation parameters can be used to validate s. i The validity of s can be verified by checking whether the following equation holds. i Is it effective?

[0070]

[0071] The right-hand side of the polynomial (*****) can be derived as follows:

[0072]

[0073] The right side of the polynomial (*****) can also be written as:

[0074] It is evident that for a Party i Dealer selects a non-zero x for it. i x i For example, if it is i, then Party i You can use i and common validation parameters {A0, A1, A2, ..., A t-1} Compute the right-hand side of the polynomial (*****), and use the generator g and sub-secret s i We can calculate the left side of the polynomial (*****), and then determine whether the left and right sides of the polynomial (*****) are equal. Is it {A0, A1, A2, ..., A...}? t-1 This corresponds to a point on the curve. This verification belongs to the verification during the secret distribution phase. For simplicity, we can usually take x as the value. i =i.

[0075] In engineering, it is generally implemented based on discrete logarithms, and modulo operations are used for the above expressions, such as mod p, where p is a large prime number, and p is also the Dealer and Party. i Pre-configured. The mod p is also omitted in similar places below.

[0076] During the secret reconstruction phase, for example, at least a threshold number of participants each send their own secret fragments to the Dealer. The Dealer can then verify each secret fragment using common verification parameters corresponding to the polynomial. If the verification fails, it can also prove that the participant who sent the secret fragment acted maliciously; a secret fragment that passes verification can be used as the basis for reconstructing the secret.

[0077] During the secret reconstruction phase, the participants can reconstruct the polynomial f(x) using the Lagrange interpolation method, thereby obtaining the value of f(0), which is the secret value.

[0078] Furthermore, through the common validation parameters {A0,A1,A2,…,A…} t-1 The validity of the secret a0 can also be verified, that is, it can be verified whether (0, a0) is a point on the curve, because the following relationship exists:

[0079]

[0080] In other words, verifying the legitimacy of secret a0 can be simplified to being achieved through the public verification parameter A0.

[0081] In the above derivation, 0 is defined 0 =1, while 0 k =0, k≠0.

[0082] The above scheme requires a Dealer, which is centralized and is an entity that knows the secret. As mentioned earlier, it needs to be a trusted third party, or in other words, all participants must trust this Dealer. In a distributed scenario, it is necessary to achieve both distributed secret distribution and distributed secret reconstruction, which requires removing the centralized Dealer, thus achieving trustlessness. To address this problem, in 1999, Rabin et al. proposed an improved protocol called Joint-Feldman. The basic idea of ​​this protocol is to execute the Feldman VSS protocol in parallel n times, where each participant generates a random polynomial locally and then shares the randomly selected secret value among all participants. Since what is shared is a promise of the secret rather than the secret itself, the secret cannot be recovered unless there is collusion among multiple participants exceeding a threshold t. Such a distributed VSS protocol without a trusted third party is also called the Distributed VSS protocol.

[0083] Specifically, taking four participants as an example, assuming the threshold t = 3, the degree of the polynomial is t-1 = 2. Decentralized threshold secret sharing, also known as the Joint-Feldman implementation scheme, includes the following:

[0084] Each Pi (Party i Abbreviated as P i (i∈{1,2,3,4}) Set the secret s to be shared. i0 And randomly select other parameters to generate a t-1 degree polynomial:

[0085] Participant P1 generates a 2-degree polynomial:

[0086] f1(z)=a 10 +a 11 z+a 12 z 2 , where a 10 It is the secret s1 set by P1;

[0087] Participant P2 generates a 2-degree polynomial:

[0088] f2(z)=a 20 +a 21 z+a 22 z 2 , where a 20 It is the secret s2 set by P2;

[0089] Participant P3 generates a 2-degree polynomial:

[0090] f3(z)=a 30 +a 31 z+a 32 z 2 , where a 30 It's the secret s3 set by P3;

[0091] Participant P4 generates a 2-degree polynomial:

[0092] f4(z)=a 40 +a 41 z+a 42 z 2 , where a 40 It's the secret s4 set by P4.

[0093] Next, each participant P i Generate and distribute n values ​​on the curve corresponding to the polynomial of degree t-1. Here, let n = 4, t = 3, n = 1, 2, 3, 4, then:

[0094] Participant P1 generates s 11 =f1(1),s 12 =f1(2), s 13 =f1(3), s 14 =f1(4), keep s yourself 11 and send them separately in encrypted form. 12 To P2, encrypt and send s13 To P3, encrypt and send s 14 Up to page 4;

[0095] Participant P2 generates s 21 =f2(1), s 22 =f2(2), s 23 =f2(3), s 24 =f2(4), keep s yourself 22 and send them separately in encrypted form. 21 To P1, encrypt and send s 23 To P3, encrypt and send s 24 Up to page 4;

[0096] Participant P3 generates s 31 =f3(1),s 32 =f3(2), s 33 =f3(3), s 34 =f3(4), keep s yourself 33 and send them separately in encrypted form. 31 To P1, encrypt and send s 32 To P2, encrypt and send s 34 Up to page 4;

[0097] Participant P4 generates s 41 =f4(1),s 42 =f4(2), s 43 =f4(3), s 44 =f4(4), keep s yourself 44 and send them separately in encrypted form. 41 To P1, encrypt and send s 42 To P2, encrypt and send s 43 To P3.

[0098] Moreover, each participant P i It also generates common verification parameters corresponding to its own t-1 degree polynomial. Where k = 0, 1, ..., t-1, and is published to each participant, specifically:

[0099] Participant P1 generation include Broadcast {A 10 A 11 A 12} to P2, P3 and P4;

[0100] Participant P2 generation include Broadcast {A 20 A 21 A 22} to P1, P3 and P4;

[0101] Participant P3 generation include Broadcast {A 30 A 31 A 32} to P1, P2 and P4;

[0102] Participant P4 generation include Broadcast {A 40 A 41 A 42} to P1, P2 and P3.

[0103] Thus, P1 receives s 21 Then, you can use {A 20 A 21 A 22} Perform verification; P1 receives s 31 Then, you can use {A 30 A 31 A 32} Perform verification; P1 receives s 41 Then, you can use {A 40 A 41 A 42 The verification process is similar to that described above and will not be repeated here.

[0104] Similarly, P2 receives s 12 Then, you can use {A 10 A 11 A 12} Perform verification; P2 receives s 32 Then, you can use {A 30 A 31 A 32} Perform verification; P2 receives s 42 Then, you can use {A 40 A 41 A 42} Verify;

[0105] Similarly, P3 receives s 13 Then, you can use {A 10 A 11 A 12} Perform verification; P3 receives s 23 Then, you can use {A 20 A 21 A 22} Perform verification; P3 receives s 43 Then, you can use {A 40 A 41 A42} Verify;

[0106] Similarly, P4 receives s 14 Then, you can use {A 10 A 11 A 12} Perform verification; P4 receives s 24 Then, you can use {A 20 A 21 A 22} Perform verification; P4 receives s 34 Then, you can use {A 30 A 31 A 32} Perform verification.

[0107] Assume that the set of participants who pass the verification is Qual, and let Qual = {P1, P2, P3, P4}. Then:

[0108] P1 has secret shares generated by different participants locally. 11 s 21 s 31 s 41 and the public verification parameter {A 10 A 11 A 12}, {A 20 A 21 A 22}, {A 30 A 31 A 32}, {A 40 A 41 A 42};

[0109] P2 has secret shares generated by different participants. 12 s 22 s 32 s 42 and the public verification parameter {A 10 A 11 A 12}, {A 20 A 21 A 22}, {A 30 A 31 A 32}, {A 40 A 41 A 42};

[0110] P3 has secret shares generated by different participants locally.13 s 23 s 33 s 43 and the public verification parameter {A 10 A 11 A 12}, {A 20 A 21 A 22}, {A 30 A 31 A 32}, {A 40 A 41 A 42};

[0111] P4 has secret shares generated by different participants locally. 14 s 24 s 34 s 44 and the public verification parameter {A 10 A 11 A 12}, {A 20 A 21 A 22}, {A 30 A 31 A 32}, {A 40 A 41 A 42}

[0112] then:

[0113] Participant P1 can calculate the secret share s1 as: s1 = s 11 +s 21 +s 31 +s 41 ;

[0114] Participant P2 can calculate the secret share s2 as: s2 = s 12 +s 22 +s 32 +s 42 ;

[0115] Participant P3 can calculate the secret share s3 as: s3 = s 13 +s 23 +s 33 +s 43 ;

[0116] Participant P4 can calculate the secret share s4 as: s4 = s 14 +s 24 +s 34 +s44 ;

[0117] Each participant P i They can all calculate their own secret share s i The broadcast is sent to the other participants. Then each participant P... i After collecting at least t secret shares from {s1,s2,s3,s4}, the secret s0 can be reconstructed. Here, for t=3, each participant P i Once you have collected at least three secret shares (the threshold), you can reconstruct secret s0.

[0118] This is because the sum of the curves from all participants can be used to obtain the overall curve:

[0119] f(z)=f1(z)+f2(z)+f3(z)+f4(z)

[0120] f(z) = (a 10 +a 11 z+a 12 z 2 )+(a 20 +a 21 z+a 22 z 2 )+(a 30 +a 31 z+a 32 z 2 )+(a 40 +a 41 z+a 42 z 2 )

[0121] f(z) = (a 10 +a 20 +a 30 +a 40 )+(a 11 +a 21 +a 31 +a 41 )z+(a 12 +a 22 +a 32 +a 42 )z 2 Polynomial (I)

[0122] so:

[0123] s1 = s 11 +s 21 +s 31 +s 41 =f1(1)+f2(1)+f3(1)+f4(1);

[0124] s2 = s 12 +s 22 +s 32 +s 42 =f1(2)+f2(2)+f3(2)+f4(2);

[0125] s3 = s 13 +s 23 +s 33 +s 43 =f1(3)+f2(3)+f3(3)+f4(3);

[0126] s4 = s 14 +s 24 +s 34 +s 44 =f1(4)+f2(4)+f3(4)+f4(4);

[0127] For the overall curve f(z), the following relationship exists:

[0128] s1=f1(1)+f2(1)+f3(1)+f4(1)=f(1);

[0129] s2=f1(2)+f2(2)+f3(2)+f4(2)=f(2);

[0130] s3=f1(3)+f2(3)+f3(3)+f4(3)=f(3);

[0131] s4=f1(4)+f2(4)+f3(4)+f4(4)=f(4);

[0132] The secret is s0 = a 10 +a 20 +a 30 +a 40 .

[0133] Thus, any participant P i After collecting at least three of the secret shares s1, s2, s3, and s4, it is equivalent to obtaining at least three points on the curve corresponding to polynomial (Ⅰ), that is, obtaining at least three of the four coordinates (x1=1, y1=s1), (x2=2, y2=s2), (x3=3, y3=s3), and (x4=4, y4=s4), thereby recovering the overall curve f(z). Furthermore, f(0)=a can be calculated. 10 +a 20 +a 30 +a 40 =s0, thus the secret s0 can be obtained.

[0134] Furthermore, by verifying parameter {A 10 A11 A 12}, {A 20 A 21 A 22}, {A 30 A 31 A 32}, {A 40 A 41 A 42} can also be used for secrets s i The validity of (0, s) can be verified. i Is it a point on the overall curve? Specifically, validity is determined by verifying whether the following equation holds true:

[0135]

[0136] This is because the following relationship exists:

[0137]

[0138]

[0139] It is also common practice to assume that the right-hand side of polynomial (II) represents the public key share, denoted as pub. i i = 1, 2, ..., n, used to verify the corresponding private key share.

[0140]

[0141] As mentioned earlier, x can generally be taken as x i = i for each i = 1, 2, ..., n. In this way, i can serve as the number of each participant.

[0142] For the verification of secret s0, i.e. x i =0, the above formula can be further derived as follows:

[0143]

[0144] Definition 0 0 =1, while 0 k =0, k≠0, so the above formula can be further derived as follows:

[0145]

[0146] It can be seen that the validity of s0 can be verified based on this polynomial (Ⅲ).

[0147] Furthermore, based on the derivation in polynomial (Ⅲ) above, the verification of the legality of s0 can be further simplified to:

[0148]

[0149] It is also common practice to assume that the right side of the polynomial (Ⅳ) is the public key, denoted as pub.

[0150] The Joint-Feldman protocol described above enables distributed secret sharing, thus completing the main content of the DKG (Device Knowledge Collection). The above sequence, from Shamir to Threshold Shamir, Feldman VSS protocol, and then to the Joint-Feldman DVSS protocol, represents a series of secret sharing implementation schemes. In fact, besides these schemes starting with Shamir secret sharing, there are also schemes based on Additive Secret Share, SPDZ (an important protocol in multi-party secure computation, first proposed in 2012), or the Chinese Remainder Theorem, which can ultimately also achieve a DKG. These are omitted here and will not be elaborated further.

[0151] The implementation of the DKG protocol described above can overcome the problem of a single point of failure leading to overall unavailability due to a single entity generating the key, as well as the problem of needing to trust the single point of key generation. However, due to the various participating parties P i The secret share s generated by broadcasting ij ,i,j∈(1,2,…,n),n is the number of participants, and each participant P i They can all calculate their own secret share s i The broadcast is sent to the other participants, so that each participant P... i After collecting at least t secret shares from {s1,s2,s3,s4}, secret s0 can be reconstructed. This results in at least a threshold number of participants obtaining the final reconstructed secret s0, thus exposing secret s0 and rendering the overall curve unusable. If a new secret s0 needs to be generated again, the DKG protocol process must be repeated.

[0152] The properties of the DKG protocol, such as thresholds and secret commitments, combined with matching threshold signature algorithms, can be used to construct distributed threshold signature protocols. Blockchain, as a distributed system, extensively uses signature algorithms. Thus, nodes in the blockchain distribute secret shares through DKG, and at least a threshold number of blockchain nodes use these secret shares as private key shares to sign the information to be signed and broadcast them. Any blockchain node that has collected at least a threshold number of signature shares can reconstruct the total signature and the total public key using the aforementioned method. This reconstructed total signature can then be verified using the total public key, thereby achieving threshold signatures. Furthermore, this approach has the advantage that each blockchain node's own secret share does not need to be broadcast to other nodes, thus avoiding the exposure of its own secret share and private key. Therefore, a secret share generated by a single DKG can be reused multiple times without requiring a separate DKG protocol for each threshold signature.

[0153] The following will start with the basics of blockchain, smart contracts, and consensus mechanisms.

[0154] The Blockchain 1.0 era typically refers to the period between 2009 and 2014, a development stage of blockchain applications represented by Bitcoin, which primarily focused on solving the problem of decentralization in currency and payment methods. Starting in 2014, developers increasingly focused on addressing Bitcoin's shortcomings in technology and scalability. In late 2013, Vitalik Buterin published the Ethereum white paper, "Ethereum: A Next-Generation Platform for Smart Contracts and Decentralized Applications," introducing smart contracts to the blockchain and opening up applications beyond currency, thus ushering in the Blockchain 2.0 era.

[0155] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger, constructed using a chain-like block structure, is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to address the consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. Each node (or multiple nodes) runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions across all loyal nodes. The transactions and execution results are then packaged into blocks.

[0156] A smart contract is a computer contract that executes automatically based on defined triggering rules; it can also be seen as a digital version of a traditional contract. The concept of smart contracts was first proposed in 1994 by Nick Szabo, a legal scholar and cryptographer working across disciplines. This technology was initially hindered from practical industrial applications due to a lack of programmable digital systems and related technologies, until the emergence of blockchain technology and Ethereum provided a reliable execution environment. Because blockchain technology uses a block-chain ledger, the generated data is immutable and cannot be deleted, and the entire ledger continuously adds data, ensuring the traceability of historical data; at the same time, the decentralized operating mechanism avoids the influence of centralized factors. Smart contracts based on blockchain technology not only leverage the advantages of smart contracts in terms of cost and efficiency but also prevent malicious interference with the normal execution of contracts. By writing smart contracts digitally into the blockchain, the characteristics of blockchain technology ensure that the entire process of storage, retrieval, and execution is transparent, traceable, and tamper-proof.

[0157] The development and applications of blockchain are diversifying. Some business logic is edited into smart contracts and executed on blockchain platforms. Specifically, these smart contracts containing business logic can run on every node (or a majority of nodes, such as consensus nodes) in the blockchain network. Compared to the single point of failure that can render the entire centralized system unusable in a centralized business logic execution environment, executing smart contracts in a blockchain environment is also known as a "world computer" because a distributed blockchain network has many nodes independently executing smart contracts. As mentioned earlier, these smart contracts executing the same logic on different nodes need to obtain the same execution result to ensure that the ledgers stored by a majority of these nodes are consistent.

[0158] Some business logic may require generating a result based on random numbers. Examples include logic for lottery draws, random number generators, or distributing random amounts of money in red envelopes or blind boxes within a certain range. This typically requires including a program to generate random numbers within the smart contract. Similarly, some system contracts may need to implement voting on master nodes or small committees, which may use random methods or random numbers. As mentioned earlier, a significant characteristic of distributed blockchain networks is that the ledgers across a majority of nodes must be consistent to ensure the overall availability of the distributed blockchain network. This also necessitates that the random numbers generated by the smart contracts across a majority of nodes be consistent.

[0159] As mentioned earlier, each node (or multiple nodes) runs a blockchain program. Under certain fault tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thus guaranteeing consistent execution results for the same transactions. The transactions and execution results are then packaged to generate blocks. Current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT) algorithm, and Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm.

[0160] Taking PBFT as an example, this algorithm, proposed by Miguel Castro and Barbara Liskov in 1999, solved the problem of low efficiency in the original Byzantine fault-tolerant algorithm, reducing the algorithm complexity from exponential to polynomial, making the Byzantine fault-tolerant algorithm feasible in practical system applications. The paper was published at the 1999 International Conference on Operating System Design and Implementation (OSDI99). In the PBFT algorithm, all replicas operate in a succession of configuration process called a view. In a view, one replica acts as the primary node, and the others act as backup nodes. Views are consecutively numbered integers. The primary node can be calculated using the formula p = v mod |R|, where v is the view number, p is the replica number, and |R| is the number of replicas. The algorithm assumes that when at most f replicas (i.e., nodes) fail, if there are at least 3f+1 replicas, safety and liveness can be guaranteed in asynchronous systems. To ensure data consistency and fault tolerance across all replicas, a certain number of replicas are needed. This set typically consists of a majority of nodes in the distributed system, forming a majority (Quorum). For example, when the total number of nodes n is 3f+1 (n = 3f+2 or n = 3f can also exist, but these generally do not improve fault tolerance), the Quorum is 2f+1. Thus, for a distributed system with four nodes, any three nodes can form a Quorum; for a distributed system with seven nodes, any five nodes can form a Quorum; and so on.

[0161] PBFT includes two processes: the Normal Case Phase and the View Change Phase. Figure 1 This is a flowchart of the Normal Case Phase process. The Normal Case Phase mainly includes three stages: PRE-PREPARE, PREPARE, and COMMIT. Node 3 could, for example, represent a node that crashes. Figure 1 (represented by ×). When the master node fails ( Figure 2 The symbol × indicates that if the primary node (Replica 0) fails before the view is changed, the view change process needs to be initiated to adjust the system in case of failure and replace the primary node (e.g., Replica 1 becomes the primary node after the view is changed). Figure 2 This is a diagram illustrating the ViewChange Phase. If the master node goes offline or acts maliciously without broadcasting client requests, the client can set a timeout mechanism. If the timeout occurs, the client can broadcast a request message to all replica nodes. If a replica node detects that the master node is malicious or offline, it can also initiate a ViewChange protocol phase to replace the master node (often simply called "master replacement"). Furthermore, the three-phase consensus process of PRE-PREPARE, PREPARE, and COMMIT may fail due to the master node making an incorrect proposal, or the PREPARE and COMMIT phases may fail to reach a consensus on the required number of quorum members (e.g., 2f+1 out of 3f+1 nodes, also known as the quorum). In these cases, a ViewChange protocol phase may also be initiated to replace the master node.

[0162] Under normal circumstances, i.e., no consensus nodes fail and consensus messages reach each other within a certain time, meaning no change of leadership will occur, the Normal Case Phase process in PBFT can proceed as follows: Figure 3 As shown in the diagram, this example still uses 4 consensus nodes.

[0163] In the (r-1)th round of the Normal Case Phase, node 0, as the master node, collects a certain number of transactions to be agreed upon (or read / write sets, etc., which will be explained using transactions as an example later). It then initiates a pre-preparation process (the aforementioned PRE-PREPARE, also referred to as the PP phase). Nodes 1, 2, and 3 then enter the preparation process (the aforementioned PRE-PREPARE, also referred to as the P phase). Afterwards, nodes 0, 1, 2, and 3 enter the commit process (the aforementioned COMMIT, also referred to as the C phase). The PP, P, and C phases are generally collectively referred to as the three phases of PBFT. In this way, under normal circumstances, the three phases of the (r-1)th round of PBFT are completed, and consensus on the transaction data corresponding to the (m-1)th block is achieved. Simultaneously, the blockchain platform code can generate information such as the block number of the corresponding block. Therefore, each consensus node can, based on the consensus transaction data, execute these transactions sequentially according to the order and content of the consensus transaction data, thereby generating the world state and receipt. Specifically, each node can construct a Merkle tree (including MPT trees, which combine Merkle and Patricia trees, a more space-efficient Trie tree) based on consensus-driven transaction data locally, and generate the root hash of this Merkle tree (also known as the transaction root hash). Similarly, a Merkle tree can be constructed based on world state data, and the root hash of this Merkle tree (also known as the state root hash) can be generated. A Merkle tree can also be constructed based on receipt data, and the root hash of this Merkle tree (also known as the receipt root hash) can be generated. After each node generates these three root hashes locally, it can generate the (m-1)th block locally. The block header of this (m-1)th block can include the aforementioned block number, transaction root hash, state root hash, and receipt root hash, while the block body can include a set of transaction data, a set of world state data, and a set of receipt data. This generates the (m-1)th block.

[0164] During the generation of the m-th block, the three-stage process of PBFT will be repeated. For example... Figure 3In the process, for the m-th block, node 0, as the master node, collects a certain number of transactions awaiting consensus and initiates the PP process. Then, nodes 1, 2, and 3 enter the P process, followed by the C process. This completes the three-phase process of the r-th round of PBFT under normal circumstances, achieving consensus on the transaction data corresponding to the m-th block and generating information such as the block number. Each node can then execute these transactions sequentially based on the consensus transaction data, according to the order and content of the consensus transaction data, thereby generating the world state and receipts. After each node generates the three root hashes as described above locally, it can generate the m-th block locally. The block header of the m-th block can include the aforementioned block number, transaction root hash, state root hash, and receipt root hash, while the block body can include the transaction data set, world state set, and receipt set. This generates the m-th block. Similarly, the (m+1)-th block is generated, and this process includes... Figure 3 The three-stage process of the (r+1)th round of PBFT is shown in the figure.

[0165] As can be seen, under normal block generation conditions, each consensus node includes a PBFT Normal Case Phase process during each block generation. As blocks are continuously generated, each consensus node will repeat this consensus process. Figure 3 The diagram only illustrates the consensus process in rounds r-1, r, and r+1. Some consensus nodes act as master nodes in PBFT, while others act as backup nodes.

[0166] Taking Ethereum as an example, Figure 4 This is a schematic diagram of the block header structure of a block. Figure 4In the structure shown, each block's header includes several fields, such as the previous block hash (prevHash in the diagram), a nonce (this is the random number involved in proof-of-work, different from the random number seed in this application, and not used in some Ethereum-based consortium blockchains), a timestamp, the previous block number (Block Num), a state root hash (State Root), a transaction root hash (Transaction Root), and a receipt root hash (Receipt Root). The Prev Hash in the header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block, and also the hash value of the previous block's header. The hash value of the block header can be calculated by concatenating the fields in the block header sequentially and then applying a hash algorithm. In this way, the blockchain achieves the locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, the state root is the root hash of the world state, that is, the hash value of the root of the MPT tree composed of the states of all accounts. Pointing to the state root is a state trie in MPT form. The transaction root is generally the hash value of the root node of the original transaction list contained in this block, organized into a tree structure. The receipt root is generally the hash value of the root node of all receipts generated after the transactions contained in this block are executed, organized into a tree structure. The transaction tree and receipt tree in the block body can be similar to the state tree structure, which is omitted here.

[0167] Figure 3 r-1 in can correspond to Figure 4 N-1 in Figure 3 r in can correspond to Figure 4 N in Figure 3 r+1 in can correspond to Figure 4 The N+1 in the series, and so on.

[0168] A consensus process, specifically a three-phase process of PBFT, may include:

[0169] a110: (PRE-PREPARE pre-preparation phase) After collecting a certain number of transactions to be agreed upon, the master node 0 sorts the transactions to be agreed upon and packages them into message m (also known as the original transaction list), and sends a pre-prepare request to backup nodes 1, 2, and 3. The pre-prepare request includes the original transaction list.

[0170] a120: (PREPARE Preparation Phase) After receiving the pre-prepare request, nodes 1, 2, and 3, if the original transaction list is valid, broadcast the hash value of the received message m via a prepare message (the broadcast content generally does not include message m itself, as message m includes several original transaction requests and is generally quite large). Specifically, node 1 propagates the prepare message to nodes 0, 2, and 3; node 2 propagates the prepare message to nodes 0, 1, and 3; and node 3 propagates the prepare message to nodes 0, 1, and 2. Correspondingly, each node also receives prepare messages broadcast by other nodes. Each node adds its own sent prepare message (containing the hash value of message m, representing its own approval) and received prepare messages (containing the hash value of message m, representing the approval of other nodes) to its local log. If a node collects at least Quorum valid pp / p messages from different nodes (including pre-prepare and prepare messages it sends, and prepare messages it receives), it transitions to the prepared state.

[0171] a130: (COMMIT Phase) After entering the prepared state, each node participating in the consensus sends a commit message to the other consensus nodes and adds its own commit message to its local log (representing its own approval). Furthermore, each node also receives commit messages broadcast by other nodes. Once a node has collected at least a Quorum number of valid commit messages from different nodes, it adds them to its local log (at this point, including its own, there are a total of a Quorum number), and transitions to the committed state.

[0172] a140: Nodes that transition to the committed state output message m as the consensus result for this round.

[0173] The selection of transactions in message 'm' and their order are generally determined by the master node in a110. Determining which transactions are included and their order is crucial to the consensus mechanism. A blockchain network may receive numerous transaction requests; the master node in a110 packages these transactions, determining which will be processed and the results recorded on the blockchain. Even with the same set of transactions, different execution orders can lead to different final results, affecting the consistency of the ledgers across different nodes.

[0174] This application provides a method for generating random number seeds on a blockchain, which can be implemented by combining the above-mentioned PBFT three-stage process. For example... Figure 5 As shown, it includes:

[0175] S110: During the commit phase of PBFT, each consensus node uses its own private key share to sign the original message containing the unique values ​​of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and adds the signature share to the broadcast commit message.

[0176] Threshold signatures are an important branch of ordinary digital signatures, combining threshold secret sharing technology with digital signatures. Commonly used threshold signature algorithms include RSA-based, ECDSA-based, Schnorr-based, and BLS-based threshold signature algorithms. For example, the RSA threshold signature scheme is based on the traditional RSA algorithm.

[0177] RSA is an asymmetric encryption algorithm proposed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA can decrypt without directly transmitting the key, ensuring information security while avoiding the risk of compromise that comes with directly transmitting the key. RSA consists of a private key and a public key, which are paired. A message encrypted with the public key can only be decrypted with the corresponding private key; similarly, a message encrypted with the private key can only be decrypted with the corresponding public key. This property is due to the mathematical correlation between the paired private and public keys. For example, one underlying principle is based on number theory: finding two large prime numbers is relatively simple, but factoring their product is extremely difficult. Therefore, the product can be made public as the encryption key, thus ensuring security. The private key is usually kept strictly confidential and cannot be disclosed, while the public key is public (and can be held by multiple people). Because the private key is kept strictly confidential by the holder, others cannot forge the private key holder's signature without obtaining the private key.

[0178] The RSA signature mechanism guarantees the integrity of messages during transmission. For example, if node A needs to send a message to node B, and it may pass through several intermediate nodes, A can use the RSA signature mechanism to send the message along with its signature through these intermediate nodes to B. B's verification of the signature confirms that the received message was indeed sent by A and has not been tampered with during transmission. One RSA signature process is as follows:

[0179] b1: A generates a key pair (public key and private key). The private key is kept secret and kept confidential. The public key is public and can be obtained by anyone.

[0180] b2: A signs the hash value of the original message using its private key and then passes the original message and the signature result to B. As mentioned earlier, this transmission process may involve several intermediate nodes.

[0181] Hash algorithms, also known as hashing algorithms, map original content to a fixed-length sequence, called the hash value. Common hash algorithms include SHA256, SHA384, and SHA512. SHA256 results in 256 bits, representing 2^256 possible original content values. Similarly, SHA384 results in 384 bits, and SHA512 results in 512 bits. These hash algorithms are suitable for large amounts of original content, allowing the hash value to be much smaller than the original content. A good hash algorithm ensures that different original content values ​​have a high probability of mapping to different hash values. This mapping is random, meaning the correlation between hash values ​​obtained from different original content values ​​cannot be predicted; it is also inversely compatible, meaning the original content cannot be derived from the hash value.

[0182] The original message may be lengthy and large in size, making direct signature calculation using the private key time-consuming and computationally expensive. Therefore, a hash algorithm can be used to calculate a hash value from the original message. This hash value is short yet fully represents the original message. Then, the private key is used to encrypt this hash value, and the result is the signature.

[0183] b3: After receiving the message, B uses A's public key to verify the signature.

[0184] On one hand, B can use the same hash algorithm as A to calculate the hash value of the original message, denoted as hash1; on the other hand, B uses A's public key to decrypt the signature result and calculate hash2. If hash1 and hash2 are the same, it can be determined that the received original message was sent by A and has not been tampered with during transmission.

[0185] A threshold signature scheme first comprises one total public key and n public-private key pairs. Each public key in a public-private key pair is called a public key share, and each private key in a public-private key pair is called a private key share. Secondly, there exists a recovery function corresponding to this total public key and the n public-private key pairs. This recovery function can recover a complete signature from signature shares signed with at least a threshold number of different private key shares. The generated complete signature can also be verified for correctness using the single total public key. Signature shares fewer than the threshold number cannot be used to generate the complete signature.

[0186] In addition to the RSA-based threshold signature mechanism, other threshold signature mechanisms that can be used include ECDSA (Elliptic Curve Digital Signature Algorithm), Schnorr (a knowledge proof mechanism based on the discrete logarithm problem), and BLS (Boneh-Lynn-Shacham Signature).

[0187] It's important to note that in threshold signatures used in blockchains, the number of private key shares can be equal to the number of consensus nodes, and the minimum number of signature shares required for the recovery function to generate a complete signature (i.e., the threshold number) can be equal to the quorum in the PBFT algorithm. Of course, the number of private keys may not be equal to the number of consensus nodes, and the minimum number of signature shares required for the recovery function to generate a complete signature may not be equal to the quorum in the PBFT algorithm. The following explanation uses the former as an example.

[0188] The single public key and n public-private key pairs can be generated by a centralized dealer and distributed to n blockchain consensus nodes; this is a centralized key distribution method. Thus, combined with the consensus algorithm, each blockchain consensus node can hold one of the n private key shares. Simultaneously, each blockchain consensus node can hold the same single public key. Alternatively, there is a decentralized key distribution method, where the dealer is eliminated, and the n consensus nodes negotiate n public-private key pairs and one public key through a key negotiation process. Each consensus node still holds one of the n private key shares, and all consensus nodes hold the same public key.

[0189] Using a threshold signature algorithm, each consensus node can use its own unique private key (for example, in a blockchain network with four nodes using PBFT as the consensus algorithm, the private key shares held by nodes 0, 1, 2, and 3 using the threshold signature algorithm are sk0, sk1, sk2, and sk3, respectively, where the subscript numbers represent node numbers) to sign the original message containing the unique values ​​of the original transaction list in this consensus, thus obtaining the signature result. Here, the unique values ​​of the original transaction list can be used as the original message to be signed.

[0190] The unique values ​​of the original transaction list can include the original transaction list itself or its hash value. Generally, different transactions have different content, so different original transaction lists or their hash values ​​are usually different. Therefore, the original message can at least include the original transaction list or its hash value. The properties of the hash function are sufficient to distinguish the random number seeds generated after the consensus process for different blocks is completed.

[0191] Considering that a number is generated for the content of this consensus process, if the consensus is complete, the generated number can be used as the block number of the block corresponding to this consensus. Therefore, the block number (i.e., the identifier) ​​can also be used as content in the original message. Regardless of whether the original transaction list contained in the (N+1)th block is the same as the original transaction table contained in the Nth block, block generation is sequential, which can be reflected as the block number of the later block being the block number of the previous block + 1. Therefore, even if the original transaction list contained in the (N+1)th block is the same as the original transaction table contained in the Nth block, each node still obtains a different signature based on (original transaction list + block number) using its own private key. The master node still cannot know the signatures of other nodes, and thus cannot predict the complete signature of the (N+1)th block. Therefore, the master node cannot use the publicly available random number seed of the Nth block to predict the random number seed of the (N+1)th block, achieving the purpose of unpredictability. Similar to numbering, timestamps are also unique to a block, with the timestamp of a later block following that of the previous block. Therefore, timestamps can also be used as content within the original message.

[0192] In addition to the unique values ​​of the original transaction list, the signing object can also include other content, such as the random number seed generated in the previous block. That is, the original message can also include the random number seed generated in the previous block. After the aforementioned a140 is executed, as mentioned earlier, each node can generate the m-th block based on the consensus transaction data. Since the m-th block is generated independently by each node locally, if the blockchain nodes do not broadcast and compare the hash values ​​of their generated previous blocks, each node may not be able to determine whether the m-th blocks generated in the blockchain network are the same, or whether, from the perspective of the overall usability of the blockchain system, at least a quorum of consensus nodes have generated the same m-th block. Through the random number seed generation process in this application, the random number seeds of the same block should be the same, and the random number seeds of different blocks should be different. Therefore, the random number seed can be added to the original message. Thus, if the random number seeds for the m-th block generated by each node are different, due to the nature of the threshold signature algorithm, it may be impossible to obtain a complete signature through the recovery function during the generation of the random number seed for the (m+1)-th block. Therefore, the scheme in this application can help consensus nodes confirm whether the previous block is consistent. Alternatively, the hash value of the previous block can be used instead of the random number seed. Since the hash value of a block is generally unique, this can also help consensus nodes confirm whether the previous block is consistent.

[0193] The original message containing unique values ​​from the original transaction list used in this consensus is signed using one's own private key share. These unique values ​​can be from the original transaction list itself. Generally, the original transaction list has already been broadcast during the PP phase of PBFT, and smaller commit messages broadcast during the C phase are more conducive to propagation and bandwidth saving. Therefore, the unique values ​​from the original transaction list can be the hash values ​​of the original transaction list.

[0194] If the original message contains multiple contents, such as the hash value of the original transaction list, the block number, and the random number seed generated in the previous block, the hash value of the original message can be calculated first, and then the hash value of the original message can be signed using the private key share to obtain the signature result.

[0195] The original message is signed, and the generated signature, along with the original message, can be added to the broadcast commit message. Thus, during the commit phase, each node participating in the consensus sends a commit message to the other consensus nodes and adds its own commit message to its local log (representing its own approval). Furthermore, each node also receives commit messages broadcast by other nodes.

[0196] S120: After each consensus node collects at least a threshold number of commit messages, it obtains a complete signature by using the recovery function corresponding to the private key share generated by the threshold signature algorithm on the verified at least threshold number of signature shares.

[0197] As mentioned earlier, in application, the threshold signature algorithm can generate a total public key and n public-private key pairs, and can also generate recovery functions corresponding to these n public-private key pairs. As previously mentioned, this recovery function can recover a complete signature from at least a threshold number of correctly verified signatures. The threshold value, i.e., the threshold number, of the threshold signature algorithm can be set to w. Of course, even if there are more than w correct signatures, a complete signature can still be generated using this recovery function. In other words, whenever the number of correct signatures is greater than or equal to the threshold number w, a complete signature can be generated using this recovery function, and this generated complete signature is deterministic and will not change due to the number of correct signatures input (as long as it is greater than or equal to w).

[0198] The generated complete signature can be verified for correctness using the aforementioned master public key. Thus, any node holding this master public key can use it to verify the correctness of the complete signature. For example, after generating the complete signature, node 1 can use the master public key to verify its integrity. This involves performing cryptographic operations on the complete signature using the master public key to obtain a first hash, and then performing a hash operation on the original message to obtain a second hash. If the first hash matches the second hash, the integrity of the complete signature is confirmed. This integrity includes the fact that the complete signature is specific to the original message and that the original message has not been tampered with. As another example, after generating the complete signature, node 1 can send the complete signature, the master public key, and the original message to a device outside the blockchain. This device can then use the master public key and the original message to verify the correctness of the complete signature, following the same principle. The original message text here still contains the aforementioned content unique to the original transaction list in this consensus, or may also include the block number of the current block and / or the timestamp and / or the random number seed generated in the previous block.

[0199] Alternatively, each consensus node can collect each commit message, verify the signature share in the received commit message using the corresponding public key share, and then use the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain the complete signature. Compared to verifying the generated complete signature using the total public key, verifying each signature share using the public key share, and then restoring the complete signature using the recovery function after successful verification, can determine which signature is erroneous, thereby identifying which node might be a malicious node.

[0200] In the threshold signature algorithm, each consensus node has a total public key and one private key share and one corresponding public key share from n public-private key pairs. As mentioned earlier, these can be generated and distributed by the dealer or negotiated by the consensus nodes.

[0201] Each consensus node can verify the signature share in the received commit message using its corresponding public key share. Specifically, for example, in a consortium blockchain using the PBFT consensus algorithm with four consensus nodes, node 0 broadcasts its generated signature share σ to nodes 1, 2, and 3 in S110. 3,0 , where σ 3,0 The subscript 3 can represent the block number, and 0 can represent that this is the signature share of node 0; in S120, node 0 also receives the signature shares σ broadcast by nodes 1 and 2 respectively. 3,1 σ 3,2 Thus, node 0 has collected at least 3 signature shares, including the signature share σ broadcast by itself. 3,0 The signature share σ broadcast by nodes 1 and 2 3,1 σ 3,2 Of course, node 0 can also collect all the signature shares σ. 3,0 σ 3,1 σ 3,2 and σ 3,3 This also satisfies the minimum number of quorums.

[0202] Furthermore, node 0 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2 σ 3,3 Or may also include σ 3,1 The correctness of the signature share σ. Specifically, for example, node 0 can use the corresponding public key share to verify the signature share σ. 3,1 The calculation yields a hash value, which is denoted as hash. 3,1 Node 0 can also perform the same hash calculation on the original message to obtain hash′. 3,1 If hash 3,1 With hash′ 3,1If they are equal, it proves that the original message was sent by node 1 and was not tampered with during transmission. Thus, σ 3,1 The correctness of this has been verified. Similarly, node 0 can be related to σ. 3,2 Further verification will be conducted later, and will not be elaborated upon further.

[0203] Similarly, node 1 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2 σ 3,3 Or may also include σ 3,1 The correctness of ).

[0204] Similarly, node 2 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2 σ 3,3 Or may also include σ 3,1 The correctness of ).

[0205] Similarly, node 3 can use the corresponding public key share to verify the collected σ. 3,0 σ 3,1 σ 3,2 Or may also include σ 3,3 (or σ) 3,0 σ 3,1 σ 3,3 Or may also include σ 3,2 Or σ 3,1 σ 3,2 σ 3,3 Or may also include σ 3,0 Or σ 3,0 σ 3,2σ 3,3 Or may also include σ 3,1 The correctness of ).

[0206] S130: Each consensus node obtains a random number seed based on the complete signature.

[0207] A random number seed is the initial value used in a pseudo-random number generator to generate pseudo-random numbers. For a single pseudo-random number generator, starting from the same random number seed will yield the same sequence of random numbers. For a single machine, the random number seed can be determined by the current state of the computer, such as the current time. However, for a distributed system, the same random number seed must be generated on all nodes to ensure that the same random numbers are generated based on the same seed in system contracts / business contracts / blockchain platform functions, and that no single node should generate random numbers in a controllable, predictable, and reversible manner. This requires the seed to be jointly determined by the nodes participating in the consensus. Furthermore, considering that distributed networks are often asynchronous or semi-synchronous, for immediacy, random numbers need to be generated and used as soon as transactions in the current block are executed.

[0208] Following steps S110-S120 above, under normal circumstances, each consensus node can obtain the same complete signature. Of course, considering the fault tolerance characteristics of distributed systems, in a blockchain network using the PBFT consensus algorithm, there should be at least a quorum number of consensus nodes, each of which can obtain the same complete signature.

[0209] In this way, based on the complete signature, each consensus node can use the same random number seed generation algorithm to generate a random number seed. A relatively simple random number seed generation algorithm is, for example, the SHA256 algorithm. Of course, the complete signature can also be used directly as the random number seed.

[0210] After the above process, a random number seed can be generated on the blockchain.

[0211] In this way, during the process of blockchain nodes outputting consensus results after completing the current consensus process—that is, during the execution of a series of transactions with determined content and order—if the code includes smart contracts / system contracts / blockchain platform code that require the use of random numbers, it can be executed based on the S130 random number seed. For example, in smart contracts written in C++, the `mt19937(r)` method provided by the C++ standard library or the Boost library can be used to construct a cross-platform consistent random number engine, where the parameter `r` is the random number seed. Similarly, the `random` library in Python and Java also provides similar random number generation methods. Based on the same random number seed, the same random numbers can be generated using the same random number generation algorithm. Thus, for example, when each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random numbers based on the same random number seed, thereby completing business logic such as lotteries, red envelopes, and blind boxes, or completing system contract / blockchain platform functions, and obtaining consistent execution results on each node.

[0212] In addition, based on the above scheme, the following steps may also be included:

[0213] S140: Each consensus node places the obtained random number seed into the block header of the generated current block.

[0214] Depend on Figure 6 In the structure shown, this application can add a field to the block header—"random number seed," which is the random number seed in S130. In this way, the random number seed generated by this block can be recorded on the blockchain ledger. Furthermore, for replaying blocks, transactions involving random numbers in the block can be replayed according to the random number seed in the block header.

[0215] The above-mentioned scheme provided in this application combines the threshold signature algorithm with the PBFT consensus algorithm, so that after the original transaction list corresponding to each block reaches consensus through the PBFT algorithm, it can obtain a complete signature through the threshold signature algorithm and thus obtain a random number seed. During the execution of transactions in the original transaction list corresponding to this block, the random number can be used. In this way, no additional waiting is required to execute the transactions in this block.

[0216] The above-mentioned scheme provided in this application, based on the nature of the threshold signature algorithm, allows each consensus node to recover the same complete signature through a recovery function based on at least a threshold number of signature shares, thereby generating the same random number seed. Thus, when each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random number based on the same random number seed, thereby completing business logic such as lottery, red envelope distribution, and blind box, or completing system contract / blockchain platform functions, and obtaining consistent execution results on each node.

[0217] The scheme provided in this application combines the threshold signature algorithm with the PBFT consensus algorithm, making it impossible for any consensus node to predict the complete signature before consensus is achieved. Even the PBFT master node cannot predict the complete signature, and therefore cannot predict the random number seed and random number. In particular, when the threshold equals the quorum, once consensus is achieved, since the quorum number of nodes have reached a consensus on the content and order of the transaction list, that is, the basic content for generating a new block has been determined, at least the quorum number of nodes will obtain the same complete signature according to the recovery function. The random number seed generated by these quorum number of nodes will also necessarily be the same. Even if no more than f nodes act maliciously and try to control or revoke the obtained random number seed, these f nodes will not affect the consistency of the system. That is, these f nodes cannot manipulate or revoke the generated complete signature, random number seed, and random number.

[0218] The method in this application can be implemented during the generation of each block, so that the block header of each block can include a random number seed field. Even if the block body of a block does not contain transactions involving random numbers, the generation process of that block can still include the process of generating a random number seed.

[0219] As mentioned earlier, threshold signature algorithms can employ RSA-based, ECDSA-based, Schnorr-based, or BLS-based threshold signature mechanisms, among others. Generally, these algorithms require generating one total public key and n public-private key pairs. In a typical and concise implementation, the number of private key shares can equal the number of consensus nodes, with each node holding one private key, i.e., one private key share. Thus, each consensus node, based on the threshold signature algorithm, uses its own private key share to sign the original message to generate a signature share. The minimum number of signatures (i.e., the threshold number w) required for the recovery function to generate a complete signature can be equal to the quorum in the PBFT algorithm. This means that at least w signature shares can generate a definite complete signature using the corresponding recovery function, regardless of which w of the n signature shares are used, as long as these at least w signatures are signatures made to the same original message using their respective correct private key shares.

[0220] To implement threshold signature algorithms on blockchain consensus nodes, a mechanism is needed to ensure that each of the n consensus nodes has one private key share and one corresponding public key share, all sharing the same master public key. As mentioned earlier, this could be generated by a centralized dealer and distributed to the n blockchain consensus nodes; this is a centralized key distribution method. This centralized method requires a third-party dealer, which necessitates that the dealer act maliciously. For example, the DKG protocol implementation, mentioned earlier, theoretically requires generating a polynomial of degree t, then selecting n points on the curve formed by this polynomial, generating n private key shares from these n points, and distributing them to the n participants in the threshold signature process. If this process is performed by a single dealer, then if this dealer acts maliciously, it can obtain the private key shares of all n participants, which violates the security requirements of a blockchain system.

[0221] Furthermore, there are decentralized key generation and distribution methods, which eliminate the dealer and instead have n consensus nodes negotiate n public-private key pairs and one master public key through a key negotiation process. Each consensus node still holds one of the n private key shares, and all consensus nodes hold the same master public key. Traditionally, this approach is implemented outside the blockchain and relies on network synchronization. Nodes on the blockchain constitute a distributed network, which is generally semi-synchronous or asynchronous. Therefore, implementing key generation and distribution between nodes in a distributed network outside the blockchain is unreliable. However, achieving a reliable distributed key protocol is a crucial prerequisite for generating random number seeds on the blockchain.

[0222] The aforementioned PBFT protocol is a semi-synchronous protocol, characterized by the assumption that the network is initially asynchronous but can synchronize at a certain point. The simplest way to achieve consensus among different nodes on the same proposal is to set a master node to unify the opinions of all nodes. Timers can be used to prevent the master node from malfunctioning. In PBFT, if the Normal Case Phase is not completed within a finite time, Backups will initiate a View Change Phase to replace the master node. PBFT fixes the master node in one position, and all requests can be sent to the master node first, which then broadcasts them to other consensus nodes. In contrast, the HoneyBadgerBFT algorithm (often abbreviated as HBBFT) is an asynchronous protocol. Asynchronous protocols are suitable for asynchronous networks, where messages between nodes can be arbitrarily delayed but will eventually arrive. HoneyBadgerBFT eliminates timers, instead using messages to drive protocol execution. Furthermore, all nodes in the HoneyBadgerBFT algorithm are equal; there is no distinction between master and backup nodes, and therefore no master-slave transition. Asynchronous network consensus protocols such as HBBFT do not have the concept of a master node. Each node can propose requests and attempt to construct blocks. Therefore, asynchronous network protocols alleviate the problems of fairness and single-node bottlenecks to a certain extent.

[0223] For example, Chinese patents ZL202111175184.1, ZL202111178795.1, ZL202111178745.3, ZL202111178754.2, ZL202111175144.7, ZL202111175151.7 and Chinese patent application CN202111178779.2 all propose new consensus algorithms while taking into account the characteristics of semi-synchronous or asynchronous blockchain networks.

[0224] Through various consensus mechanisms within a blockchain network, the overall consistency and synchronization of the blockchain network can be guaranteed. For the latter, as long as the blockchain continues to produce blocks, block synchronization can be achieved. Therefore, combining blockchain with distributed key generation will be reliable.

[0225] The following describes a method for implementing distributed key generation on a blockchain, as described in this application. Figure 7 As shown, it includes:

[0226] S310: Each consensus node generates a unique set of n secret shares, keeps one for itself, and encrypts and sends the n-1 secret shares to the other n-1 nodes respectively.

[0227] In the DKG algorithm, nodes are renumbered, starting from 1. To maintain consistency with the DKG algorithm, consensus nodes will also be numbered starting from 1.

[0228] Elliptic Curve Cryptography (ECC) is a public-key encryption technique based on elliptic curve theory. It leverages the discrete logarithmic difficulty of the Abelian group formed by points on an elliptic curve over a finite field to achieve encryption, decryption, and digital signatures. The following explanation uses an elliptic curve as an example. Each node can be found in the group Z... q A polynomial of degree t is randomly selected. The Nth degree polynomial function is uniquely determined by N+1 points, because ultimately quorum consensus nodes in the blockchain network are needed to recover the signature; therefore, quorum = N+1, and the degree t of the polynomial is quorum-1. In this way, a complete signature can be recovered from quorum (quorum = t+1) signature shares using the recovery function. Of course, t can also be set to other values. The elliptic curve constructed using this polynomial can be represented as follows:

[0229] f i (z)=a i0 +a i1 z+a i2 z 2 +…+a it z t Formula (1)

[0230] In formula (1), a i0 a i1 a i2 a i3 , ..., a it These are the coefficients of a polynomial, and a polynomial can be determined by this set of coefficients.

[0231] When the number of consensus nodes n in the blockchain network is set to 4, and the quorum for algorithms such as PBFT and HBBFT is 3, then t = 2. In this case, the polynomial is:

[0232] f i (z)=a i0 +a i1 z+a i2 z 2 Formula (2)

[0233] Node 1 can randomly select a set of numbers from a finite prime field as coefficients, i.e., as a. 10 a 11 a 12 The generated polynomial is: f1(z) = a 10 +a11 z+a 12 z 2 .

[0234] Similarly, node 2 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 20 a 21 a 22 The generated polynomial is: f2(z) = a 20 +a 21 z+a 22 z 2 .

[0235] Similarly, node 3 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 30 a 31 a 32 The generated polynomial is: f3(z) = a 30 +a 31 z+a 32 z 2 .

[0236] Similarly, node 4 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 40 a 41 a 42 The generated polynomial is: f4(z) = a 40 +a 41 z+a 42 z 2 .

[0237] Each node, based on a defined polynomial, can further determine a set of secret shares. The secret shares can be determined from the polynomial coefficients using the following formula:

[0238] s ij =f i (j)mod q(j=1,…,n) Formula (3)

[0239] In formula (3), q is the same large number used by each node for f. i (j) The purpose of using q as the modulus is to make f i The value of (j) is limited to the range [0, q-1]. For example:

[0240] Consensus node 1 generates 4 secret shares, namely S 11 =f1(1)mod q,S 12 =f1(2)mod q,S 13 =f1(3)mod q,S 14=f1(4)mod q. Here, the 4 secret shares represent the total number of consensus nodes. In other words, to ultimately achieve the goal of generating a complete signature by taking any w from the n signature shares and then using the recovery function, n secret shares need to be generated. The same applies below.

[0241] Consensus node 2 generates 4 secret shares, namely S 21 =f2(1)mod q,S 22 =f2(2)mod q,S 23 =f2(3)mod q,S 24 =f2(4)mod q.

[0242] Consensus node 3 generates 4 secret shares, namely S 31 =f3(1)mod q,S 32 =f3(2)mod q,S 33 =f3(3)mod q,S 34 =f3(4)mod q.

[0243] Consensus node 4 generates 4 secret shares, namely S 41 =f4(1)mod q,S 42 =f4(2)mod q,S 43 =f4(3)mod q,S 44 =f4(4)mod q.

[0244] Furthermore, in addition to retaining its own secret share, each node can exchange other secret shares generated with other consensus nodes through a P2P network. Specifically, this can be done as follows:

[0245] Consensus node 1 retains S 11 , will S 12 Send to node 2, and send S 13 Send to node 3, and send S 14 The secret share can be sent to node 4 via the underlying P2P (Peer-to-Peer) network component in the blockchain network. The sent secret share needs to be kept confidential. Consensus node 1 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient via a secure connection such as TLS (Transport Layer Security).

[0246] Consensus node 2 retains S 22 , will S 21 Send to node 1, and send S 23 Send to node 3, and send S 24Sending to node 4 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 2 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0247] Consensus node 3 retains S 33 , will S 31 Send to node 1, and send S 32 Send to node 2, and send S 34 Sending to node 4 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 3 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0248] Consensus node 4 retains S 44 , will S 41 Send to node 1, and send S 42 Send to node 2, and send S 43 Sending to node 3 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 4 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0249] As you can see, the two numbers in the subscript of the secret share represent the node number that issued the secret share (left) and the node number that received the secret share (right). Thus:

[0250] Consensus node 1 has a secret share S generated by different nodes locally. 11 S 21 S 31 S 41 ;

[0251] Consensus node 2 has a different secret share S generated by different nodes locally. 12 S 22 S 32 S 42 ;

[0252] Consensus node 3 has a secret share S generated by different nodes locally. 13 S 23 S 33 S 43 ;

[0253] Consensus node 4 has a different secret share S generated by different nodes locally. 14 S 24S 34 S 44 .

[0254] Among them, consensus node 1 has S locally. 11 It is generated by itself, and consensus node 2 has it locally. 22 It is generated by itself, and consensus node 3 has it locally. 33 It is generated by itself, and consensus node 4 has it locally. 44 It was generated by itself.

[0255] Ideally, consensus nodes should sign the secret share to be sent, for example, using their own private key or a MAC (Message Authentication Code), to ensure message integrity and prevent man-in-the-middle attacks. Correspondingly, the node receiving the secret share can verify the correctness of the signature.

[0256] S320: Each node generates public verification parameters corresponding to its own secret share and broadcasts them through an on-chain contract; the on-chain contract adds the number of the node requesting the broadcast to the first node set.

[0257] Each consensus node can generate a set of verification parameters corresponding to its own key share. The generation method can use the following formula:

[0258]

[0259] In formula (4), g is a base point on the elliptic curve. According to the operational properties of elliptic curves, a power of g is also a point on the elliptic curve. t is the degree of the polynomial, typically set to (quorum-1). As mentioned earlier, to ultimately achieve the goal of generating a complete signature from any w signatures selected from n signature shares using the recovery function, the degree of the polynomial needs to be set to t, where t = w-1. The same applies below.

[0260] Based on the above formula (4), let t = 2, and the set of verification parameters generated by consensus node 1 is as follows: 10 A 11 A 12 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 2 generates a set of verification parameters as follows: 20 A 21 A 22 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 3 generates a set of verification parameters as follows: 30 A 31 A 32 ​​​This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 4 generates a set of verification parameters as follows: 40 A 41 A 42 > This set of verification parameters is broadcast via an on-chain contract.

[0261] Based on the properties of cryptography, A ik Even if it's published, it won't lead to the derivation of a. ik Therefore, even if the published A is obtained from the chain... ik Furthermore, it is also impossible to obtain the polynomial in S310.

[0262] Through on-chain contract broadcasting, specifically, each node can sign a transaction with its own private key and send it to the blockchain. Each node can have a built-in blockchain SDK (Software Development Kit). An SDK is a collection of program interfaces, documentation, examples, development tools, etc. With a built-in SDK, a blockchain node can initiate transactions to the blockchain network like a blockchain client. Transactions signed by a blockchain node with its own private key can contain calls to smart contracts on the blockchain. The called contract, for example, is a DKG contract. This DKG contract can be a system-level contract, that is, a contract pre-deployed on the blockchain, such as a contract created by an account with system administrator privileges, providing system-level control functions, rather than a contract developed and deployed by the user to implement specific business logic.

[0263] Like other contracts, DKG contracts can execute in a virtual machine (such as the Ethereum Virtual Machine, EVM) or a container (such as Docker); the limitations are not specified. An external account initiates a transaction to the blockchain to invoke an on-chain contract, triggering the contract's execution. The transaction content includes fields such as `from`, `to`, `value`, and `data`. The `from` field can be the account address of the transaction initiator, the `to` field can represent the address of the smart contract being invoked, the `value` field can be a native token on the blockchain (such as the value of Ether in Ethereum), and the `data` field can contain the method and parameters for invoking the smart contract. By specifying the address of the smart contract to be invoked in the `to` field, it indicates that a call is being made to a specific smart contract on the blockchain. A smart contract typically includes one or more functions, each of which can include some input parameters. The `data` field in the transaction specifies the function within the smart contract to be invoked and contains the required parameters.

[0264] ​The outcome of contract execution can alter the contract's storage, i.e., its world state. Furthermore, the transaction's execution result or related information can be recorded in a blockchain receipt. Specifically, the contract execution result / related information can be represented as events within the receipt. An event's structure might look like this:

[0265] Event:

[0266] [topic][msg]

[0267] [topic][msg] ......

[0269] In the example above, there can be one or more events. Each event can include fields such as topic and data. The format of the events output during transaction execution can be specified in the contract. Through the built-in SDK, blockchain clients or blockchain nodes can listen for events on specific topics, and upon detecting events on a specific topic, retrieve the content of the corresponding message, and perform preset processing after listening for certain content from a specific topic or the corresponding message.

[0270] In this event mechanism, nodes can store execution results in the `msg` field corresponding to a specific topic. Listeners on that topic (i.e., clients with the built-in blockchain SDK or blockchain nodes) can then obtain the corresponding execution results. In S320, a node can transmit the generated public verification parameters to the blockchain network by initiating a call to the first function in the DKG contract (e.g., a function named `Broadcast`, which can include parameters, including public verification parameters). One result of the blockchain network executing this transaction is that the public verification parameters are placed into the `msg` field corresponding to the specific topic in the receipt. Nodes listening to that topic can then obtain the content of the `msg` field, i.e., obtain the public verification parameters. This completes the on-chain contract broadcast.

[0271] You can register events to listen for with a blockchain node via an SDK. Specifically, the blockchain node can bind a hook function to the generated events in the running blockchain platform code (the hook function can be edited along with the platform code during the development phase). This hook function is a callback function that can be called when the listened-for event occurs and can execute certain processing logic. The listening code can include, for example, listening to the transaction content of blockchain transactions, the contract state of smart contracts, receipts generated by contracts, or one or more other things. After registering the listening events with the blockchain node via the SDK, the blockchain node can maintain a mapping relationship between the listened-for events and the listeners (e.g., the network connection of the client / node that has embedded the SDK and initiated event listening, which generally includes information such as IP address and port number). For example, it can maintain a mapping relationship between listening to a specific event of a specific contract and the listeners. When the hook function detects that the corresponding event topic has occurred, it can be called, and the hook function can then query the mapping relationship and push the listened-for event to the network connection. In this way, the SDK that initiated the listening can obtain the listened-for events through the maintained network connection. Contract execution is also implemented in a similar way through on-chain contract broadcasting. Specifically, the execution results of the contract and other transactions in the same block are stored in a transaction result cache area of ​​the blockchain node. Once all transactions in the blockchain have been executed and organized into a block, the blockchain platform code can listen to the receipts in the transaction results and broadcast the monitored events to the SDK that initiated the listening. Here, through this listening mechanism, nodes can listen to registered events for specific topics, and when such events occur, they can obtain the corresponding message (msg) for that topic through the maintained connection, thus obtaining the content of the message, which includes public verification parameters. In short, the blockchain's event mechanism can be used to broadcast public verification parameters, and the event listening mechanism can be used to receive the broadcast content.

[0272] Thus, the result of broadcasting the public verification parameters generated by each node on the blockchain can be as follows:

[0273] Consensus node 1 has a secret share S generated by different nodes locally. 11 S 21 S 31 S 41 and verification parameters 10 A 11 A 12 > and can obtain public verification parameters from the chain. 20 A 21 A 22 >, 30 A 31 A 32 >, 40 A​​​​41 A 42 >;

[0274] Consensus node 2 has a different secret share S generated by different nodes locally. 12 S 22 S 32 S 42 and verification parameters 20 A 21 A 22 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 30 A 31 A 32 >, 40 A 41 A 42 >;

[0275] Consensus node 3 has a secret share S generated by different nodes locally. 13 S 23 S 33 S 43 and verification parameters 30 A 31 A 32 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 20 A 21 A 22 >, 40 A 41 A 42 >;

[0276] Consensus node 4 has a different secret share S generated by different nodes locally. 14 S 24 S 34 S 44 and verification parameters 40 A 41 A 42 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 20 A 21 A 22 >, 30 A 31 A 32 >

[0277] ​​​​​​​​​​​​As mentioned above, through on-chain contract broadcasting, specifically, each node can sign a transaction with its own private key and send it to the blockchain. For example, a node sends the generated public verification parameters to the blockchain network by initiating a transaction. This transaction may call the Broadcast(r) function in the DKG contract, where the function can include the parameter r, and r can include the public verification parameters. The execution logic of the Broadcast(r) function, in addition to placing the public verification parameters into the msg corresponding to a specific topic in the receipt, can also include adding the node number requesting the broadcast to the first node set, i.e., changing the contract's storage, i.e., changing the contract's world state. Assuming that consensus nodes 1-4 each send a transaction calling the Broadcast(r) function in the DKG contract, the execution result of the Broadcast(r) function includes storing the numbers 1-4 of the four consensus nodes that initiated the transaction into the first state maintained by the contract. This state is, for example, in the form {1,2,3,4}, where {} represents a set, and this set is, for example, named the Party set.

[0278] S330: Each consensus node verifies each received secret share and the corresponding public verification parameter, and sends the node number of the failed verification to the contract through a complaint transaction; the contract determines the second node set based on the node number of the failed verification sent by each consensus node and the first node set.

[0279] Each consensus node can receive secret shares from any other node and receive public verification parameters broadcast by the on-chain contract.

[0280] As mentioned in S310 above, each consensus node generates n secret shares S. ij Each node retains one copy and sends its n-1 secret shares, encrypted, to the other n-1 nodes via a P2P network component. As mentioned in S320 above, each node generates public verification parameters corresponding to its own secret share and broadcasts them via an on-chain contract.

[0281] If the secret share issued by each node and the corresponding public verification parameter belong to the same polynomial, then the following equation should hold:

[0282]

[0283] As mentioned before, t = quorum - 1; when n = 4, quorum = 3, and at this time t = 2.

[0284] Based on the property of formula (5), this formula can be used to verify each received secret share and public verification parameter. If the verification equation holds, it means that the secret share and the corresponding public verification parameter belong to the same polynomial; otherwise, they do not belong to the same polynomial. This can also be used to check whether the node that generates the secret share and the corresponding public verification parameter has engaged in malicious behavior. A typical malicious behavior is, for example, a node generating S based on the first polynomial. ij However, A was generated using different polynomials. ik (k = 0, ..., t).

[0285] The above verification specifically includes:

[0286] When j=1, that is, consensus node 1 can verify the following:

[0287] i=1: (In fact, consensus node 1 does not need to verify whether this equation holds, because the secret share S) 11 and verification parameters 11 A 12 A 13 >All are generated by themselves)

[0288] i = 2:

[0289] i = 3:

[0290] i = 4:

[0291] If the equation corresponding to i=2 is false, consensus node 1 can send the failed verification node number 2 to the DKG contract. Similarly, if the equations corresponding to i=2 and i=3 are false, consensus node 1 can send the failed verification node numbers 2 and i=3 to the DKG contract. Similarly, if the equations corresponding to i=2, i=3 and i=4 are false, consensus node 1 can send the failed verification node numbers 2, i=3 and i=4 to the DKG contract.

[0292] When j=2, that is, consensus node 2 can verify the following:

[0293] i=1:

[0294] i = 2: (In fact, consensus node 2 does not need to verify whether this equation holds, because the secret share S) 22 and verification parameters 20 A 21 A 22 >All are generated by themselves)

[0295] i = 3:​​

[0296] i = 4:

[0297] If the equation corresponding to i=1 is false, consensus node 2 can send the failed verification node number 1 to the DKG contract. Similarly, if the equation corresponding to i=1, 3 is false, consensus node 2 can send the failed verification node numbers 1 and 3 to the DKG contract. Similarly, if the equation corresponding to i=1, 3, 4 is false, consensus node 2 can send the failed verification node numbers 1, 3, and 4 to the DKG contract.

[0298] When j=3, that is, consensus node 3 can verify the following:

[0299] i=1:

[0300] i = 2:

[0301] i = 3: (In fact, consensus node 3 does not need to verify whether this equation holds, because the secret share S) 33 and verification parameters 30 A 31 A 32 >All are generated by themselves)

[0302] i = 4:

[0303] If the equation corresponding to i=1 is false, consensus node 3 can send the node number 1 that failed verification to the DKG contract. Similarly, if the equations corresponding to i=1 and i=2 are false, consensus node 3 can send the node numbers 1 and i=2 that failed verification to the DKG contract. Similarly, if the equations corresponding to i=1, i=2 and i=4 are false, consensus node 3 can send the node numbers 1, i=2 and i=4 that failed verification to the DKG contract.

[0304] When j=4, that is, consensus node 4 can verify the following:

[0305] i=1:

[0306] i = 2:

[0307] i = 3:

[0308] i = 4: (In fact, consensus node 4 does not need to verify whether this equation holds, because the secret share S) 44 and verification parameters <A​40 A 41 A 42 >All are generated by themselves)

[0309] If the equation corresponding to i=1 is false, consensus node 4 can send the node number 1 that failed verification to the DKG contract. Similarly, if the equation corresponding to i=1, 2 is false, consensus node 4 can send the node numbers 1 and 2 that failed verification to the DKG contract. Similarly, if the equation corresponding to i=1, 2, 3 is false, consensus node 4 can send the node numbers 1, 2, and 3 that failed verification to the DKG contract.

[0310] Each node can sign a transaction with its own private key and send it to the blockchain. For example, a node can send the node number that failed verification to the blockchain network by initiating a transaction. This transaction is, for example, a complaint transaction, which can call the Confirm(r) function in the DKG contract. This function can include the parameter r, which can include the node number that failed verification submitted by the node in the complaint transaction.

[0311] The execution logic of the `Confirm(r)` function can include copying the node IDs of those nodes in the first node set `Parties` that did not receive a complaint transaction to the second node set. Assuming the first node set `Parties` is {1,2,3,4}, but the DKG contract receives a complaint transaction that includes node ID 4 (e.g., the parameter `r=4` in the `Confirm(r)` function called in a complaint transaction initiated by consensus node 1), then the DKG contract marks node ID 4 in the first node set `Parties` as deleted. Assuming that no other node IDs in the other nodes in the first node set `Parties` have received a corresponding complaint, then node IDs 1, 2, and 3 in the first node set are retained. In this way, the DKG contract can determine the second node set {1,2,3} based on the node ID 4 that failed verification sent by each consensus node and the first node set {1,2,3,4}, for example, named QUAL.

[0312] It's important to note that in blockchain networks, due to the semi-synchronous or asynchronous nature of the network, contract execution doesn't necessarily occur within the same block. Instead, it may be performed in parts across different blocks. In such cases, a state machine can be set up within the contract, allowing the state machine to transition as a part of the execution is completed, or until the state machine reaches a certain final state. Each step of the state machine execution can be triggered upon receiving a transaction. Therefore, the set of nodes determined by the DKG contract in this step may span multiple blocks.

[0313] S340: Each consensus node calculates its public key share based on the verification parameters and the set of second nodes, and calculates its own private key share based on its local secret share and the set of second nodes.

[0314] On the one hand, each consensus node can calculate its public key share locally based on the verification parameters and the set of second nodes, using the following formula:

[0315]

[0316] On the other hand, each consensus node calculates its own private key share based on its local secret share and the set of second nodes, which can be done using the following formula:

[0317] x j =∑ i∈QUAL s ij mod q formula (7)

[0318] For example, consensus node 1 calculates its own private key share locally:

[0319]

[0320] Consensus node 2 calculates its own private key share locally:

[0321]

[0322] Consensus node 3 calculates its own private key share locally:

[0323]

[0324] Consensus node 4 calculates its own private key share locally:

[0325]

[0326] It is evident that the private key shares calculated by nodes 1, 2, 3, and 4 are not the same.

[0327] On the other hand, each consensus node can calculate the total public key locally based on the verification parameters and the set of second nodes. The total public key can be calculated according to the following formula:

[0328] y = Π i∈QUAL y i Formula (7)

[0329] Among them, y i =A i0 .

[0330] Thus, for example, consensus node 1 can calculate the total public key as follows:

[0331] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0332] Similarly, for example, consensus node 2 can calculate the total public key as follows:

[0333] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0334] Similarly, for example, consensus node 3 can calculate the total public key as follows:

[0335] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0336] Similarly, for example, consensus node 4 can calculate the total public key as follows:

[0337] y = y1 * y2 * y3 * y4 = A 10 *A 20 *A 30 *A 40

[0338] As can be seen, the total public key calculated by nodes 1, 2, 3 and 4 is the same, that is, each node obtains the same total public key through the above method.

[0339] The aforementioned private key share x1 corresponds to public key share pub1, private key share x2 corresponds to public key share pub2, private key share x3 corresponds to public key share pub3, and private key share x4 corresponds to public key share pub4. As mentioned earlier, each public key share can be used to verify the signature share generated by the corresponding private key share. Moreover, a complete signature recovered by the recovery function from the signature shares generated by at least quorum private key shares can be verified by the corresponding total public key.

[0340] For example, if the second node set is {1,2,3}, the public key share calculated by consensus node 1 could be:

[0341]

[0342] Similarly, the public key share calculated by consensus node 2 could be:

[0343]

[0344] Similarly, the public key share calculated by consensus node 3 could be:

[0345]

[0346] As can be seen, if node 4 acts maliciously, its secret share and corresponding public verification parameters are not generated according to the same polynomial, and thus it is verified by at least one node and a complaint is initiated. In this case, node 4 is not included in the set of second nodes. Therefore, at least nodes 1, 2, and 3 will not calculate the public key share based on the public verification parameters generated by node 4, but based on the public verification parameters generated by nodes 1, 2, and 3 in the set of second nodes.

[0347] Each consensus node calculates its own private key share based on its local secret share and the set of second nodes.

[0348] For example, consensus node 1 calculates its own private key share locally:

[0349]

[0350] Consensus node 2 calculates its own private key share locally:

[0351]

[0352] Consensus node 3 calculates its own private key share locally:

[0353]

[0354] Consensus node 4 calculates its own private key share locally:

[0355]

[0356] Therefore, assuming node 4 acts maliciously, its secret share and corresponding public verification parameters are not generated using the same polynomial, resulting in verification failure and a complaint from at least one node. Since node 4 is not included in the second node set, at least nodes 1, 2, and 3 will not calculate their private key shares based on the secret share generated by node 4, but rather on the secret shares generated by nodes 1, 2, and 3 in the second node set. Furthermore, at least nodes 1, 2, and 3 will calculate different private key shares.

[0357] Each consensus node can calculate the total public key locally based on the verification parameters and the set of second nodes.

[0358] Thus, for example, consensus node 1 can calculate the total public key as follows:

[0359] y = y1 * y2 * y3 = A 10 *A 20 *A30

[0360] Similarly, for example, consensus node 2 can calculate the total public key as follows:

[0361] y = y1 * y2 * y3 = A 10 *A 20 *A 30

[0362] Similarly, for example, consensus node 3 can calculate the total public key as follows:

[0363] y = y1 * y2 * y3 = A 10 *A 20 *A 30

[0364] Similarly, for example, consensus node 4 can calculate the total public key as follows:

[0365] y = y1 * y2 * y3 = A 10 *A 20 *A 30

[0366] As can be seen, assuming node 4 acts maliciously, its secret share and corresponding public verification parameters are not generated according to the same polynomial, thus failing verification and initiating a complaint by at least one node. Since node 4 is not included in the second node set, at least nodes 1, 2, and 3 will not base their calculations of the total public key on the public verification parameters generated by node 4, but rather on the public verification parameters generated by nodes 1, 2, and 3 in the second node set. Furthermore, at least nodes 1, 2, and 3 will calculate the same total public key; that is, through the above method, at least honest nodes will obtain the same total public key.

[0367] Therefore, for a total of n consensus nodes, using the threshold signature algorithm, if at least w signature shares out of m signature shares can be used to recover a complete signature, and if there are no malicious nodes (i.e., the secret shares and corresponding public verification parameters are generated according to the same polynomial), then n can be equal to m. If there are malicious nodes, for example, b malicious nodes, then m = nb, while w remains unchanged. However, m must be ensured to be no less than w; otherwise, the threshold signature algorithm will fail.

[0368] As mentioned in S330 above, each consensus node verifies each received secret share and its corresponding public verification parameters. If verification fails, the verifying node can sign a complaint transaction using its own private key and send it to the blockchain. Specifically, this transaction can call the Confirm(r) function in the DKG contract, where the function can include the parameter r, which can include the node number of the node that failed verification in the complaint transaction. For example, node j receives the secret share S encrypted and sent by node i in S310.ij The receiving node j sends S to i ij Verification is performed using formula (5). A typical case where verification fails is when node i sends S... ij If the received secret share S does not correspond to the public verification parameters generated by node i and broadcast through the on-chain contract, then... ij Node j can be verified in S330, and if verification fails, node j can send its ID i to the DKG contract. To prove that the secret share sent by node i has not been tampered with, in addition to sending node i's ID, node j can also send node i's secret share and signature to the DKG contract. As mentioned in S310, nodes can sign the generated and issued secret shares. For the DKG contract to verify the secret share and its corresponding public verification parameters, the plaintext of the secret share needs to be included in the complaint transaction; that is, the plaintext obtained by node j after decrypting the secret share encrypted by node i. Furthermore, to enable the DKG contract to verify the signature, it is best for node i to first sign the secret share in S310, and then encrypt the plaintext secret share and signature together before sending it to node j. In other words, the consensus node that generated the secret share signs and encrypts the generated secret share before sending it to other nodes. Thus, the complaint transaction sent by node j to the DKG contract includes not only the node i's number, but also the secret share of the plaintext sent by node i to node j and the signature of the generator i on the generated secret share of plaintext.

[0369] Before determining the second node set based on the node numbers of the failed verifications sent by each consensus node and the first node set, the DKG contract can first verify the signature of the secret share in the complaint transaction. If the verification is correct, it can be confirmed that the secret share originally sent by node i to node j in the above example has not been tampered with. Furthermore, the DKG contract can verify whether the secret share and the corresponding public verification parameters belong to the same polynomial, such as by verifying according to the aforementioned formula (5). If the equation is not valid according to formula (5), it can be confirmed that the secret share and the corresponding public verification parameters do not belong to the same polynomial, and the complaint is valid; if the equation is valid according to formula (5), it can be confirmed that the secret share and the corresponding public verification parameters belong to the same polynomial, and the complaint is invalid. For complaints that are valid, i.e., those that are confirmed to have failed verification, the DKG contract can determine the second node set based on the node numbers in the complaint transaction and the first node set. For example, if a complaint transaction includes node number 4, then as in the previous example, the DKG contract can mark node number 4 in the first node set `Parties` as deleted, so the first node set `Parties` = {1,2,3,4}. Furthermore, the DKG contract can determine the second node set `QUAL` = {1,2,3} based on the failed verification of node number 4 and the `Parties` set `{1,2,3,4}`. However, for complaints that are invalid, i.e., those where verification failure cannot be confirmed, the DKG contract does not mark node number 4 in the first node set `Parties` as deleted, nor does it set `QUAL` to `{1,2,3}`; instead, it retains `{1,2,3,4}`.

[0370] Furthermore, it's possible that in a previous distributed key generation process, the secret share sent by node i to node j was inconsistent with the corresponding public verification parameters generated by node i. Therefore, node j's complaint transaction against node i succeeded. However, in a subsequent distributed key generation process, the secret share sent by node i to node j is actually consistent with the corresponding public verification parameters generated by node i. In this case, in the later round, node j can still use the plaintext secret share and signature from node i in the previous round to initiate a complaint transaction, causing the DKG contract to misjudge in the later round. This is clearly a malicious complaint. To address this, in each round of distributed key generation, a sequence number representing the current round of distributed key generation, such as epoch, can be included in the initiated transaction. Each time a new round of distributed key generation is performed, the epoch can be incremented by 1. Thus, in S310, the secret share generated and sent by node i and the epoch can be signed together before encryption. Furthermore, during the distributed key generation process at epoch=p, if node i acts maliciously, node j can send the ID of node i (which failed verification), the secret share of the plaintext sent by node i to node j, epoch=p, and a signature through a complaint transaction. Upon receiving the complaint transaction, the DKG contract can verify it and firstly, through the signature, confirm that the secret share of the plaintext and epoch=p in the original message have not been tampered with. Thus, during the distributed key generation process at epoch=p+1, assuming node i is not malicious, even if node j sends the ID of node i (which failed verification), the secret share of the plaintext sent by node i to node j, epoch=p+1, and the signature from the previous round through a complaint transaction, the signature from the previous round, which was for epoch=p, will not match the original message. Therefore, upon receiving the complaint transaction, the DKG contract can first verify through the signature that the original message has been tampered with and will not trust this complaint, thus avoiding malicious complaints.

[0371] It should be noted that sending the plaintext secret share in S330 is based on the premise that honest nodes will inevitably respond correctly within a certain time. This ensures that sending the entire secret share will not lead to the leakage of the private key share, and thus the final complete signature will not be leaked.

[0372] In S320, the public verification parameters broadcast by each consensus node through the on-chain contract are also accompanied by the aforementioned round. This allows for the differentiation of the round to which the public verification parameters belong, even in the presence of network latency.

[0373] By using the above method, on the basis of ensuring the overall consistency and synchronization of the blockchain network through the consensus mechanism, distributed key generation is achieved by combining blockchain smart contracts. This ensures that the generation of distributed keys is achieved by the cooperation of various participants, and that the generated results are consistent and reliable. This eliminates the strong dependence of distributed key generation outside the original blockchain on network synchronization and solves the problem of unreliability of the generated results in this case.

[0374] The above Figure 7 In the corresponding embodiments, there is a large number of messages. For example, in S310, each consensus node generates a unique set of n secret shares, and encrypts and sends n-1 of these secret shares to the other n-1 nodes. This encrypted transmission is generally performed off-chain in a peer-to-peer (P2P) manner. Therefore, for a blockchain network with n consensus nodes, the message complexity is n. 2 For example, with 100 consensus nodes, the message volume will reach the order of 10,000. It is evident that in this model, the large number of messages sent consumes significant bandwidth, substantially impacting blockchain performance.

[0375] This application provides a method for implementing distributed key generation on a blockchain, such as... Figure 8 As shown, it includes:

[0376] S410: Each consensus node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares with the receiver's key; each consensus node generates public verification parameters corresponding to its own secret shares; each consensus node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0377] Let's continue using elliptic curves as an example. Suppose the number of consensus nodes in a blockchain network is n, and the threshold value w in the threshold signature is equal to the quorum in the consensus algorithm used, i.e., w = quorum. Each node can participate in the group Z. q Let's randomly select a polynomial of degree t. Then, according to the formula above, t = w⁻¹ = quorum⁻¹. Of course, w can take other values, in which case t = w⁻¹ will still be maintained. The following explanation uses w = quorum as an example.

[0378] Each node can be in group Z q Randomly select a polynomial of degree t, for example as follows:

[0379] f i (z)=a i0 +a i1 z+a i2 z 2 +…+a it zt Formula (1)

[0380] In formula (1), a i0 a i1 a i2 a i3 , ..., a it These are the coefficients of a polynomial, and a polynomial can be determined by this set of coefficients.

[0381] When the number of consensus nodes n in the blockchain network is set to 4, and the quorum for algorithms such as PBFT and HBBFT is 3, then t = 2. In this case, the polynomial is:

[0382] f i (z)=a i0 +a i1 z+a i2 z 2 Formula (2)

[0383] Node 1 can randomly select a set of numbers from a finite prime field as coefficients, i.e., as a. 10 a 11 a 12 The generated polynomial is: f1(z) = a 10 +a 11 z+a 12 z 2 a 10 It is the secret s1 set by node 1.

[0384] Similarly, node 2 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 20 a 21 a 22 The generated polynomial is: f2(z) = a 20 +a 21 z+a 22 z 2 , where a 20 It is the secret s2 set by node 2.

[0385] Similarly, node 3 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 30 a 31 a 32 The generated polynomial is: f3(z) = a 30 +a 31 z+a 32 z 2 , where a 30 It is the secret s3 set by node 3.

[0386] Similarly, node 4 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 40 a 41 a 42 The generated polynomial is: f4(z) = a 40 +a 41 z+a 42 z 2 , where a 40 It is the secret s4 set by node 4.

[0387] Each node, based on a defined polynomial, can further determine a set of secret shares. The secret shares can be determined from the polynomial coefficients using the following formula:

[0388] s ij =f i (j)mod q(j=1,…,n) Formula (3)

[0389] In formula (3), q is the same large number used for each node, also called the order, for f i (j) The purpose of using q as the modulus is to make f i The value of (j) is limited to the range [0, q-1]. For example:

[0390] Node 1 generates 4 secret shares, namely S 11 =f1(1)mod q,S 12 =f1(2)mod q,S 13 =f1(3)modq,S 14 =f1(4)mod q.

[0391] Node 2 generates 4 secret shares, namely S 21 =f2(1)mod q,S 22 =f2(2)mod q,S 23 =f2(3)modq,S 24 =f2(4)mod q.

[0392] Node 3 generates 4 secret shares, namely S 31 =f3(1)mod q,S 32 =f3(2)mod q,S 33 =f3(3)modq,S 34 =f3(4)mod q.

[0393] Node 4 generates 4 secret shares, namely S 41 =f4(1)mod q,S 42 =f4(2)mod q,S 43=f4(3)modq,S 44 =f4(4)mod q.

[0394] Each consensus node retains one copy of the generated n secret shares and can encrypt the remaining n-1 secret shares using the recipient's key. Asymmetric encryption is preferred here. Asymmetric encryption is a public-key encryption scheme where the recipient generates a public-private key pair, publishes the public key, and keeps the private key secret. The sender encrypts the secret using the published public key, and only the recipient with the corresponding private key can decrypt it; those without the private key cannot decrypt it. While symmetric encryption can also achieve encrypted transmission, the key cannot be published, and both the encrypting and decrypting parties must have the same key. This avoids the key negotiation and transmission issues and man-in-the-middle attacks associated with symmetric encryption.

[0395] For example:

[0396] The 4 secret shares s generated by node 1 11 ,s 12 ,s 13 ,s 14 Node 1 retains s itself 11 And s is encrypted using node 2's public key pk2. 12 Encrypt s using node 3's public key pk3. 13 Encrypt s using the public key pk4 of node 4. 14 .

[0397] The 4 secret shares s generated by node 2 21 ,s 22 ,s 23 ,s 24 Node 2 retains s itself 22 And s is encrypted using node 1's public key pk1. 21 Encrypt s using node 3's public key pk3. 23 Encrypt s using the public key pk4 of node 4. 24 .

[0398] The 4 secret shares s generated by node 3 31 ,s 32 ,s 33 ,s 34 Node 3 retains s itself 33 And s is encrypted using node 1's public key pk1. 31 Encrypt s using node 2's public key pk2 32 Encrypt s using the public key pk4 of node 4. 34 .

[0399] The 4 secret shares s generated by node 4 41 ,s 42,s 43 ,s 44 Node 4 retains s itself 44 And s is encrypted using node 1's public key pk1. 41 Encrypt s using node 2's public key pk2 42 Encrypt s using node 3's public key pk3. 43 .

[0400] Accordingly, each consensus node can generate a public verification parameter A corresponding to its own polynomial. ik k = 1, 2, ..., t. As mentioned before, Since the product of this set of public verification parameters can verify points on the polynomial curve, and the generated public verification parameters are in the same form as the public key generated on ECC, that is... Therefore, the result of a series of multiplications is also called the public key. For x i =i,

[0401] When the total number of nodes n = 4 and the threshold w = 3, that is, when the degree of the polynomial t = 2, then:

[0402] The public key of node 1 is

[0403] The public key of node 2 is

[0404] The public key of node 3 is

[0405] The public key of node 4 is

[0406] pk j This represents the public key of the j-th node. This pk j The public key is different from the pub key mentioned above. i Public key. pk j This represents the public key in the public-private key pair generated by each node itself; it can be referred to here as the first public key. The above pub... i The public key refers to the public key associated with the polynomial generated by the node itself, and can be called the second public key.

[0407] Furthermore, each consensus node generates a third zero-knowledge proof that matches its own secret share with the corresponding public verification parameters. Since the encrypted secret share needs to be sent to the on-chain contract via a transaction in S420, and cannot be exposed, the above formula (5) cannot be directly used to verify the match between the secret share and the public verification parameters. Instead, each consensus node can use the Sigma Protocol to generate a third zero-knowledge proof that matches its own encrypted secret share with the corresponding public verification parameters. Accordingly, by using the third zero-knowledge proof and the Sigma Protocol, it is possible to verify whether the encrypted secret share matches the corresponding public verification parameters.

[0408] S420: Each consensus node can send its own generated secret share, public verification parameters, and a third zero-knowledge proof that matches the secret share with the corresponding public verification parameters to the on-chain contract in the same or different transactions.

[0409] Transactions signed by blockchain nodes using their private keys can include calls to smart contracts on the blockchain. Contracts, such as the DKG contract, can be pre-deployed on the blockchain. A deployed contract can have an on-chain contract address. Subsequently, the on-chain contract can be invoked by launching a transaction, for example, by setting the recipient address of the transaction to the address of the contract to be invoked.

[0410] A consensus node can sign a transaction using its private key and send it to the blockchain. The transaction recipient's address can be set to the address of the DKG contract. Furthermore, the transaction can carry parameters input when calling the contract and can specify the function within the contract to be called. The input parameters and the specified function can be located in the transaction's data field.

[0411] In one implementation, each consensus node can send its generated secret share, public verification parameters, and a third zero-knowledge proof matching the secret share with the corresponding public verification parameters to an on-chain contract by sending a transaction.

[0412] In another implementation, each consensus node can send its generated and encrypted secret share to the on-chain contract by sending a first transaction. The encrypted secret share can be set in the data field of the first transaction. Similarly, each consensus node can send its generated public verification parameters to the on-chain contract by sending a second transaction. Likewise, each consensus node can send a third zero-knowledge proof matching its generated secret share with the corresponding public verification parameters to the on-chain contract by sending a third transaction. These first, second, and third transactions can be, for example, transactions that call the DKG contract. Alternatively, the secret share and public verification parameters can be sent to the on-chain contract in the same transaction, while the third zero-knowledge proof is sent to the on-chain contract in another transaction; or the third zero-knowledge proof and the public verification parameters can be sent to the on-chain contract in the same transaction, while the secret share is sent to the on-chain contract in another transaction; or the secret share and the third zero-knowledge proof can be sent to the on-chain contract in the same transaction, while the public verification parameters are sent to the on-chain contract in another transaction.

[0413] S430: The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof.

[0414] After receiving the third zero-knowledge proof, the secret share, and the corresponding public verification parameters through a transaction, the on-chain contract, as mentioned above, can verify that the encrypted secret share and the corresponding public verification parameters match through the third zero-knowledge proof.

[0415] After successful verification, since the on-chain contract now possesses the public verification parameters corresponding to the polynomials generated by each consensus node, the on-chain contract can generate the total public key based on the public verification parameters, similar to the formula (7) above.

[0416] S440: Each consensus node obtains a verified secret share from the contract, with itself as the recipient, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0417] This is similar to the aforementioned S340, so I will not repeat it here.

[0418] Since the on-chain contract generates the master public key in S430, each consensus node can also obtain the master public key from the contract information in step S440 or later. Alternatively, each consensus node can also obtain public verification parameters from the contract information and calculate the master public key based on these parameters.

[0419] In the above embodiment, for n nodes, the secret share generated by each node is encrypted and sent to the on-chain contract. The message complexity is n, thereby avoiding point-to-point encrypted transmission between nodes, i.e., avoiding n2 The message complexity is reduced, which can significantly decrease the number of messages.

[0420] Furthermore, by sending the secret share, public verification parameters, and third zero-knowledge proof generated by each node to the on-chain contract, the code logic within the on-chain contract can verify whether the secret share matches the corresponding public verification parameters using the third zero-knowledge proof. This avoids the need for nodes in S330 to perform off-chain verification after obtaining the secret share and public verification parameters from the on-chain contract. Verifying the match between the secret share and the corresponding public verification parameters via the on-chain contract avoids the step of each node filing a complaint with the contract again after a mismatch is verified off-chain, saving at least one round of communication.

[0421] In S410 above, it is assumed that each consensus node is honest and does not act maliciously. However, malicious behavior may actually occur, such as a consensus node generating and sending an incorrect secret share, or a consensus node not encrypting the secret share using the recipient's public key. If the consensus node does not encrypt the secret share using the recipient's public key, according to the above... Figure 8 In this example, the solution can still be verified through the on-chain contract, but the recipient cannot correctly decrypt the encrypted secret share. If the consensus node generates and sends an incorrect secret share, the recipient may also fail to decrypt it correctly. Therefore, the solution is incomplete. To make the solution more complete, zero-knowledge proof-related technologies can be used, allowing the code logic in the on-chain contract to further verify the correctness of the secret share.

[0422] Based on this, this application provides a method for implementing distributed key generation on a blockchain, such as... Figure 9 As shown, it includes:

[0423] S510: Each consensus node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares with the receiver's key to generate a first zero-knowledge proof that can be decrypted; each consensus node generates public verification parameters corresponding to its own secret shares; each consensus node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0424] Similar to S410 mentioned above, node 1 can randomly select a set of numbers from a finite prime field as coefficients, i.e., as a. 10 a 11 a 12 The generated polynomial is: f1(z) = a 10 +a 11 z+a 12 z 2 a 10 It is the secret s1 set by node 1.

[0425] Similarly, node 2 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 20 a 21 a 22 The generated polynomial is: f2(z) = a 20 +a 21 z+a 22 z 2 , where a 20 It is the secret s2 set by node 2.

[0426] Similarly, node 3 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 30 a 31 a 32 The generated polynomial is: f3(z) = a 30 +a 31 z+a 32 z 2 , where a 30 It is the secret s3 set by node 3.

[0427] Similarly, node 4 can randomly select a set of numbers from the same finite prime field as coefficients, i.e., as a. 40 a 41 a 42 The generated polynomial is: f4(z) = a 40 +a 41 z+a 42 z 2 , where a 40 It is the secret s4 set by node 4.

[0428] Each node, based on a defined polynomial, can further determine a set of secret shares. The secret shares can be determined from the polynomial coefficients using the following formula:

[0429] s ij =f i (j)mod q(j=1,…,n) Formula (3)

[0430] In formula (3), q is the same large number used for each node, also called the order, for f i (j) The purpose of using q as the modulus is to make f i The value of (j) is limited to the range [0, q-1]. For example:

[0431] Node 1 generates 4 secret shares, namely S 11 =f1(1)mod q,S 12 =f1(2)mod q,S 13=f1(3)modq,S 14 =f1(4)mod q.

[0432] Node 2 generates 4 secret shares, namely S 21 =f2(1)mod q,S 22 =f2(2)mod q,S 23 =f2(3)modq,S 24 =f2(4)mod q.

[0433] Node 3 generates 4 secret shares, namely S 31 =f3(1)mod q,S 32 =f3(2)mod q,S 33 =f3(3)modq,S 34 =f3(4)mod q.

[0434] Node 4 generates 4 secret shares, namely S 41 =f4(1)mod q,S 42 =f4(2)mod q,S 43 =f4(3)modq,S 44 =f4(4)mod q.

[0435] As mentioned earlier, in S420, each consensus node sends an encrypted secret share to the on-chain contract during a transaction. All nodes on the chain can then obtain this encrypted secret share from the contract information. For example, any node can listen in through the aforementioned event mechanism and thus detect the encrypted secret share in the event's message. To ensure that only the recipient with the valid key can decrypt the message, similar to S410, the sender can encrypt the corresponding secret share using the recipient's public key.

[0436] Meanwhile, to avoid the consensus node generating and sending incorrect secret shares, which would prevent the receiver from decrypting correctly, and to ensure that the contract code logic can verify this, zero-knowledge proofs can be used. Zero-knowledge proofs refer to the ability of the prover to convince the verifier that a statement is true without providing any useful information. One example of zero-knowledge proof here is RangeProof. RangeProof is a zero-knowledge proof technique that proves the range of plaintext bit lengths in a Pedersen commitment. Its function is to convince the verifier that the encrypted ciphertext is decryptable by proving the length of the plaintext encrypted by the ciphertext. For example, for 32-bit ciphertext, by building a table, the party possessing the private key can quickly exhaustively decrypt it. A Pedersen commitment is a type of commitment in cryptography, proposed by Torben Pryds Pedersen in 1992. Currently, Pedersen commitments are mainly used in conjunction with elliptic curve cryptography (and can also be combined with exponential operations), possessing a ciphertext form based on the discrete logarithm difficulty problem and homomorphic addition properties.

[0437] To enable RangeProof encryption, TwistedElgamal encryption can be used as an asymmetric encryption scheme within the framework of asymmetric encryption. TwistedElgamal is an additive homomorphic public-key encryption scheme that is friendly to zero-knowledge proofs.

[0438] In Twisted Elgamal encryption, the decryption process involves a brute-force algorithm using exhaustive search. Encrypting binary data longer than 32 bits requires searching through a large number of bits, making decryption impossible within a reasonable timeframe—typically milliseconds to seconds on a computer with average computing power. For example, decrypting a 64-bit binary data would take several years, while 256 bits would be an astronomical time. In contrast, encrypting a 32-bit binary data allows the holder of the corresponding private key to decrypt it within milliseconds.

[0439] Based on this, for s ij In encryption, s can be ij It is split into 32-bit segments.

[0440] By setting the value of the order q, s can be... ij The range of values ​​for is limited to a uniform range. For example, setting q to a 256-bit prime number allows s to be... ij The value range is limited to 0 to 2. 256 Within the range of -1, thus, sij The value of can be represented by a 256-bit binary number. Generally, s ij Setting the value to 256 bits or more is necessary to ensure the security of the ciphertext, meaning that a party without a legitimate key cannot crack it within a reasonable timeframe.

[0441] For a given order q, it is possible to make s ij The length is |q|, where || represents the operation of retrieving bits from a binary number. Therefore, for a number of length |q|, s can be... ij The data is divided into m equal parts from high to low, with each part consisting of a segment of |q| / m binary numbers. For each s... ij In the case of 256 bits, it can be split into 8 segments of 32 bits from high to low. The numbering from high to low (i.e. from left to right) can be segment 7, segment 6, segment 5, segment 4, segment 3, segment 2, segment 1, and segment 0.

[0442] The segment is split into 32-bit segments because a 32-bit length allows the receiver to quickly decrypt ECC-based asymmetric encryption, for example, through brute force. A 64-bit or longer segment is beyond the capabilities of current ECC asymmetric encryption algorithms for fast decryption. Of course, if q is set to a 32-bit prime number, then s... ij The value range is limited to 0 to 2. 32 Within the range of -1, thus, s ij The value of can be represented by a 32-bit binary number. s ij If the value is represented by a 32-bit binary number, as mentioned above, then no segmentation is required.

[0443] Next, node i can encrypt each of the m binary numbers corresponding to itself to obtain the ciphertext. Where C represents the ciphertext, and the subscripts i, j and s ij The indices are the same, indicating that the j-th secret share generated by node i will be sent to node j. k represents the segment number mentioned above. For example, if the 256 bits are divided into eight 32-bit segments from high to low, the segment numbers from high to low (i.e., from left to right) are: segment m=7 for the 7th segment, m=6 for the 6th segment, m=5 for the 5th segment, m=4 for the 4th segment, m=3 for the 3rd segment, m=2 for the 2nd segment, m=1 for the 1st segment, and m=0 for the 0th segment. h, like g, represents a generator in the group. r represents a random number. pk j This represents the public key of the j-th node, where the j-th node acts as the secret receiver.

[0444] The above The right side of the equals sign indicates an encryption method, such as TwistedElgamal, which uses... right Performing a masking operation is equivalent to a encryption operation.

[0445] In this way, a 256-bit original text can be divided into 8 segments of 32 bits each using Twisted Elgamal, and then encrypted to generate 8 ciphertexts, with each ciphertext corresponding to one segment.

[0446] Accordingly, a RangeProof proof is used, specifically generating a RangeProof for each ciphertext. Thus, for a 256-bit plaintext, this results in 8 ciphertexts and 8 corresponding RangeProofs. These 8 RangeProofs are denoted as RangeProof. i,j,m , where the subscript i represents the node number of the generator, j represents the node number of the receiver, and m represents the segment number, where m = 0, 1, 2, ..., 7.

[0447] As mentioned earlier, Twisted Elgamal is an additive homomorphic public-key encryption scheme that is friendly to zero-knowledge proofs. Based on the additive homomorphic property, eight ciphertexts and their corresponding eight RangeProofs can be superimposed to generate a range proof, denoted as RangeProof. i,j Furthermore, stacking multiple RangeProof values ​​to generate a single range proof can significantly reduce the space required for the proof. For example, if RangeProof... i,j,m Each occupies 100 bytes. Therefore, the ciphertext generated by sender node i and received by node j is divided into 8 ciphertexts, corresponding to 8 RangeProofs. i,j,0 RangeProof i,j,1 ,...,RangeProof i,j,7 It occupies a total of 800 bytes. Based on the aforementioned homomorphic property of addition, RangeProof... i,j,0 RangeProof i,j,1 ,...,RangeProof i,j,7 These eight range proofs are merged into one range proof, namely RangeProof. i,j The merged RangeProof i,j It occupies approximately 200-300 bytes, less than half the size of 800 bytes, while retaining the characteristics of zero-knowledge proofs, meaning that this merged range proof can still prove s. ijEach segment of the ciphertext is 32 bits, meaning it can be decrypted within a reasonable timeframe; for example, the decryptor holding the corresponding private key can complete decryption within milliseconds. Clearly, compared to unmerged range proofs, merged range proofs can reduce the size of transactions sent to the chain, which also reduces the storage space required for on-chain data.

[0448] Furthermore, each consensus node typically registers its public key on the blockchain. The Twisted Elgamal example above uses the recipient's public key for encryption; similarly, the verifier, such as an on-chain smart contract, can use the recipient's registered public key to encrypt the RangeProof. i,j and C i,j,k The verification process, if successful, not only proves that decryption can be completed within milliseconds, but also proves that the public key held by the decryptor was used for the PK (peer-to-peer) operation. j The encryption is performed. In this way, a smart contract on the blockchain can verify that the party holding the corresponding private key (i.e., the receiver) can decrypt the data without holding the decryptor's private key. Of course, even if multiple range proofs are generated instead of being superimposed to form a single range proof, a smart contract on the blockchain can still verify that the party holding the corresponding private key (i.e., the receiver) can decrypt each ciphertext within a reasonable timeframe without holding the decryptor's private key.

[0449] Instead of not sending the first zero-knowledge proof, this method sends the first zero-knowledge proof—proving that the secret share can be decrypted by the recipient—to the on-chain contract. This allows the code logic within the on-chain contract to verify the correctness of the secret share. If the verification passes, the on-chain contract can determine that the content sent by the sender is correct, and the recipient can certainly decrypt it correctly. This eliminates the need for the aforementioned complaint process and reduces the number of rounds of interaction between the node and the on-chain contract.

[0450] Accordingly, each consensus node can generate a public verification parameter A corresponding to its own polynomial. ik k = 1, 2, ..., t. As mentioned before, Since the product of this set of public verification parameters can verify points on the polynomial curve, and the generated public verification parameters are in the same form as the public key generated on ECC, that is... Therefore, the result of a series of multiplications is also called the public key. For x i =i,

[0451] When the total number of nodes n = 4 and the threshold w = 3, that is, when the degree of the polynomial t = 2, then:

[0452] The public key of node 1 is

[0453] The public key of node 2 is

[0454] The public key of node 3 is

[0455] The public key of node 4 is

[0456] The above PK j This represents the public key of the j-th node. This pk j The public key is different from the pub key mentioned above. i Public key. pk j This represents the public key in the public-private key pair generated by each node itself; it can be referred to here as the first public key. Here, pub... i The public key refers to the public key associated with the polynomial generated by the node itself, and can be called the second public key.

[0457] S520: Each consensus node can send the secret share, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that the secret share matches the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions.

[0458] The shaft is similar to that of the S420, so it will not be described in detail again.

[0459] S530: The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share matches the corresponding public verification parameters through a third zero-knowledge proof.

[0460] As described in S510, on-chain contracts can use the public key of the recipient registered on-chain, based on the TwistedElgamal algorithm to calculate RangeProof. i,j and C i,j,k The verification process, if successful, not only proves that the receiver can complete decryption within milliseconds, but also proves that the decryptor used the public key held by the decryptor to perform a PK (penetrate-by-dots) operation. j The encryption is performed in a way that means the receiving node holding the corresponding private key can correctly decrypt it.

[0461] Specifically, for a scheme that uses RangeProof and Twisted Elgamal encryption, as mentioned earlier, for s ij In the encryption of s ijThe data is split into 32-bit segments. Thus, for a 256-bit original text, Twisted Elgamal can divide it into eight 32-bit segments, which are then encrypted to generate eight ciphertexts, each corresponding to one segment. A RangeProof is then used; either a range proof can be generated for each ciphertext, or the eight ciphertexts and their corresponding eight RangeProofs can be combined to generate a single range proof. Accordingly, in S530, on-chain contracts can verify the receiver's ability to decrypt the data by validating this range proof. For the data... ij The ciphertext is divided into 32-bit segments. The ciphertext of each segment can be restored, for example, by shifting it according to its position and then stacking it. For instance, the ciphertext of segment 1 can be shifted left by 32 bits, segment 2 by 64 bits, segment 3 by 96 bits, segment 4 by 128 bits, segment 5 by 160 bits, segment 6 by 192 bits, and segment 7 by 224 bits. Segment 0 does not need to be shifted or shifted left by 0 bits. The shifted ciphertexts can be stacked and merged, and the merged ciphertext can be verified against the range of the merged ciphertext. This verification can be expressed as:

[0462] in For the above division into 8 segments, the value of m can be from 0 to 7.

[0463] The verification of the encrypted secret share and the corresponding public verification parameters through the third zero-knowledge proof is similar to S430 and will not be described again.

[0464] S540: Each consensus node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0465] This step is similar to S440 above, and will not be repeated here.

[0466] Since the on-chain contract in S540 generates the master public key, each consensus node can obtain the master public key from the contract information in or after step S540. Alternatively, each consensus node can also obtain public verification parameters from the contract information and calculate the master public key based on these parameters.

[0467] Furthermore, regarding the S510 scheme employing RangeProof and Twisted Elgamal encryption, as mentioned earlier, for s ij In the encryption, s can be ijThe original text is divided into 32-bit segments. Thus, for a 256-bit original text, Twisted Elgamal can divide it into 8 segments of 32 bits each, and encrypt each segment to generate 8 ciphertexts, each corresponding to one segment. For example, Twisted Elgamal can divide the original text into 8 segments of 32 bits each, and encrypt each segment to generate 8 ciphertexts, each corresponding to one segment. The receiving node can then obtain each ciphertext segment from the contract information, concatenate them bit by bit to obtain the ciphertext sent by each sender, and then use formula (7) to obtain the private key share, which will not be elaborated further.

[0468] Through the above process, not only can peer-to-peer broadcasting between nodes be avoided, but the on-chain contract can also verify whether each node is acting maliciously. If no malicious activity is detected, the code logic in the on-chain contract can further verify the correctness of the secret share and verify that the encrypted secret share and its corresponding public verification parameters match. This eliminates the verification and complaint processes in S330, and also eliminates the need for individual nodes to interact with the on-chain contract, thereby reducing the number of interaction rounds.

[0469] Although the above text repeatedly mentions consensus nodes, those skilled in the art will know that in some implementation purposes, they may also be ordinary nodes, or consensus nodes and non-consensus nodes, rather than all of them being consensus nodes.

[0470] The following describes a blockchain system provided in this application, comprising several nodes, wherein:

[0471] Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0472] Each node sends its own generated secret share, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same or different transactions;

[0473] The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match using a third zero-knowledge proof.

[0474] Each node obtains a verified secret share from the contract information, with itself as the recipient, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0475] The following describes a blockchain system provided in this application, comprising several nodes, wherein:

[0476] Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares with the receiver's key to generate a first zero-knowledge proof that can be decrypted; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0477] Each node can send the secret share, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that the secret share matches the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions;

[0478] The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof.

[0479] Each node obtains a verified secret share from the contract information, with itself as the recipient, decrypts it using its own key, and calculates its own private key share in combination with its local secret share.

[0480] The following describes a first node in a blockchain system provided in this application, including:

[0481] The first node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; the first node generates public verification parameters corresponding to its own secret shares; the first node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters;

[0482] The first node sends its own generated secret share, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same transaction or different transactions;

[0483] The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match using a third zero-knowledge proof.

[0484] The first node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with the local secret share.

[0485] The following describes a first node in a blockchain system provided in this application, including:

[0486] The first node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key, generating a first zero-knowledge proof that can be decrypted; the first node generates public verification parameters corresponding to its own secret shares; the first node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters.

[0487] The first node can send the secret share, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that the secret share matches the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions.

[0488] The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof.

[0489] The first node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with the local secret share.

[0490] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0491] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0492] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0493] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0494] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0495] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0496] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0497] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0498] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0499] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0500] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0501] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0502] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0503] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0504] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for implementing distributed key generation on a blockchain, comprising: S1: Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; Each node generates public verification parameters corresponding to its own secret shares; Each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters; n is greater than or equal to 3; S2: Each node sends its generated n-1 secret shares, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same transaction or different transactions; the n-1 secret shares are sent through the same transaction; S3: The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match using a third zero-knowledge proof; S4: Each node obtains the verified secret share of the contract information, with itself as the recipient, and decrypts it using its own key. It then calculates its own private key share by combining the local secret share with the private key share.

2. As described in claim 1, in S2 each node uses the Sigma Protocol to generate a third zero-knowledge proof that matches its own encrypted secret share with the corresponding public verification parameters; correspondingly, in S3 the on-chain contract uses the Sigma Protocol and verifies the match between the encrypted secret share and the corresponding public verification parameters through the third zero-knowledge proof.

3. The method as described in claim 1, wherein the on-chain contract further generates a master public key based on the public verification parameters.

4. The method of claim 3, wherein each node further obtains the master public key from the contract.

5. The method as described in claim 1, wherein each node further obtains the public verification parameters from the contract information and calculates the total public key based on the public verification parameters.

6. A method for implementing distributed key generation on a blockchain, comprising: S1: Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key, generating a first zero-knowledge proof that can be decrypted; Each node generates public verification parameters corresponding to its own secret shares; Each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters; n is greater than or equal to 3. S2: Each node can send the n-1 secret shares, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof matching the n-1 secret shares with the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions; the n-1 secret shares are sent through the same transaction; S3: The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof, and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof; S4: Each node obtains the verified secret share of the contract information, with itself as the recipient, and decrypts it using its own key. It then calculates its own private key share by combining the local secret share with the private key share.

7. The method as described in claim 6, in S1, each node performs asymmetric encryption on the n-1 secret shares using the receiver's public key.

8. In the method of claim 7, in S1, each node performs asymmetric encryption on the n-1 secret shares using the receiver's public key, and then generates a corresponding first zero-knowledge proof that the data can be decrypted.

9. The method of claim 8, wherein each node performs asymmetric encryption on the n-1 secret shares using the recipient's public key, including using Twisted Elgamal encryption.

10. The method of claim 9, wherein the Twisted Elgamal encryption comprises: The original text is divided into several segments of 32 bits each, and then encrypted using the recipient's public key based on the Twisted Elgamal algorithm to generate several ciphertexts, with each ciphertext corresponding to one segment.

11. The method of claim 10, wherein the first zero-knowledge proof includes a RangeProof proof.

12. The method of claim 11, wherein the RangeProof range proof comprises: Generate a RangeProof for each ciphertext; or, Generate a RangeProof for each ciphertext, and merge the RangeProofs of each ciphertext into a single RangeProof.

13. A blockchain system comprising a plurality of nodes, wherein: Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters; n is greater than or equal to 3; Each node sends its generated n-1 secret shares, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same transaction or different transactions; the n-1 secret shares are sent through the same transaction. The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match using a third zero-knowledge proof. Each node obtains a verified secret share from the contract information, with itself as the recipient, decrypts it using its own key, and calculates its own private key share by combining it with its local secret share.

14. A blockchain system comprising a plurality of nodes, wherein: Each node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key, generating a first zero-knowledge proof that can be decrypted; each node generates public verification parameters corresponding to its own secret shares; each node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters; n is greater than or equal to 3. Each node can send the n-1 secret shares, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that matches the n-1 secret shares with the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions; the n-1 secret shares are sent through the same transaction; The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof. Each node obtains a verified secret share from the contract information, with itself as the recipient, decrypts it using its own key, and calculates its own private key share by combining it with its local secret share.

15. A first node in a blockchain system, comprising: The first node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key; the first node generates public verification parameters corresponding to its own secret shares; the first node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters; n is greater than or equal to 3. The first node sends its generated n-1 secret shares, public verification parameters, and third zero-knowledge proof to the on-chain contract through the same transaction or different transactions; the n-1 secret shares are sent through the same transaction. The on-chain contract verifies that the encrypted secret share and the corresponding public verification parameters match using a third zero-knowledge proof. The first node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with the local secret share.

16. A first node in a blockchain system, comprising: The first node generates n secret shares, keeps one for itself, and encrypts the remaining n-1 secret shares using the receiver's key, generating a first zero-knowledge proof that can be decrypted; the first node generates public verification parameters corresponding to its own secret shares; the first node generates a third zero-knowledge proof that matches its own secret shares with the corresponding public verification parameters; n is greater than or equal to 3; The first node can send the n-1 secret shares, the corresponding first zero-knowledge proof, the public verification parameters, and the third zero-knowledge proof that matches the n-1 secret shares with the corresponding public verification parameters to the on-chain contract in the same transaction or different transactions; the n-1 secret shares are sent through the same transaction; The on-chain contract verifies the encrypted secret share through a first zero-knowledge proof and verifies that the encrypted secret share and the corresponding public verification parameters match through a third zero-knowledge proof. The first node obtains the verified secret share of itself from the contract information, decrypts it using its own key, and calculates its own private key share in combination with the local secret share.

Images