Asynchronous blockchain dynamic monitor

Abstract

The present invention discloses an asynchronous blockchain dynamic monitor, which belongs to the field of blockchain dynamic monitoring, and includes: a monitoring module for dynamically managing and troubleshooting the blockchain system; a signature module for verifying the identity of the node and the authenticity of the message; an asynchronous BFT module for integrating transaction requests into a common proposal subset to obtain a consensus result; and a threshold encryption module for encrypting and decrypting transaction data according to the number of nodes. The present invention significantly improves the scalability, reliability and security of the blockchain system in semiconductor manufacturing and supply chain management through innovative asynchronous blockchain dynamic monitoring technology.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain dynamic monitoring, and in particular relates to an asynchronous blockchain dynamic monitor. Background Art

[0002] With the rapid development of blockchain technology, its decentralized, tamper-proof and transparent features have made it widely used in finance, supply chain management, the Internet of Things, smart contracts and distributed storage. However, the popularity of blockchain technology has also brought new challenges, especially in terms of node management and network security. Traditional blockchain systems are unable to cope with large-scale networks, frequent node changes and network delays. Existing blockchain systems mainly rely on synchronous or partially synchronous network models, requiring all nodes to receive the same information and reach a consensus within a specified time. This model works well in small-scale networks, but in large-scale networks, as the number of nodes increases and the distribution range expands, the probability of network delay and node failure also increases, resulting in system performance degradation and security issues. The existence of these problems has greatly restricted the further development and application of blockchain technology.

[0003] In the semiconductor industry, similar problems are gradually emerging in supply chain management and production processes. Semiconductor manufacturing involves a complex global supply chain, covering multiple links from raw material procurement to chip production and delivery. In such a complex system, frequent node changes and network delays may lead to untimely information transmission, which in turn affects production efficiency and product quality. In addition, the semiconductor industry has extremely high requirements for data security and integrity, and the application of traditional blockchain systems in large-scale semiconductor supply chain management is subject to many restrictions. Especially in the chip design and manufacturing process, the real-time and security of data are crucial, and any delay or erroneous transmission of information may have a serious impact on the entire production chain. Summary of the invention

[0004] In order to solve the above technical problems, the present invention proposes an asynchronous blockchain dynamic monitor to solve the problems existing in the above-mentioned prior art.

[0005] To achieve the above object, the present invention provides an asynchronous blockchain dynamic monitor, comprising:

[0006] Monitoring module, used for dynamic management and troubleshooting of blockchain systems;

[0007] Signature module, used to verify the identity of the node and the authenticity of the message;

[0008] Asynchronous BFT module, used to aggregate transaction requests into a common proposal subset to obtain consensus results;

[0009] The threshold encryption module is used to encrypt and decrypt transaction data according to the number of nodes.

[0010] Preferably, the monitoring module includes an entry unit, an exit unit and a clearing unit;

[0011] The adding unit is used to add a new node;

[0012] The exit unit is used to exclude the node requesting exit from the network;

[0013] The clearing unit is used to clear the faulty node.

[0014] Preferably, the joining unit includes a joining request unit, a first verification unit and a node acceptance unit;

[0015] The join request unit is used for node P n+1 Call the Boneh-Boyen signature scheme's KeyGen to generate a key pair (SIG pkn+1 , SIG skn+1 ), node P n+1 Send JoinNode to MS;

[0016] JoinNode=((Join,SUB n+1 , SIG pkn+1 , ID n+1 ), SigGen(h(m), SIG skn+1 ));

[0017] Among them, Join is the message type, SUB n+1 It is by P n+1 Submissions to MS, SIG pkn+1 It is node P n+1 The public key, ID n+1 YesP n+1 ID, h(m) is the hash value of the information, SigGen(h(m), SIG skn+1 ) is P n+1 Signature of h(m);

[0018] The first verification unit is used to receive P n+1 After the JoinReq, the MS first checks the SUB n+1 To verify P n+1 Should we join the system, then check SigGen(h(m), SIG skn+1 ) is correct, if P n+1 Through the above verification, MS uses DTIBE.Gen to generate d IDn+1 As P n+1 The private key in the DTIBE scheme, then the MS will carry dIDn+1 The JoinAcc is sent to P n+1 , where Accept is the message type, JoinAcc=(Accept, JoinReq);

[0019] The node receiving unit is used to receive the JoinAcc, and then the node P n+1 Broadcast JoinAcc to all nodes; for each node P i , i∈(1,...,n), upon receiving P n+1 After checking the JoinAcc, it replies to NodeJoinAcc to P n+1 ;

[0020] NodeJoinAcc=((JoinConf, ID n+1 , ID i , r), SigGen(h(m), SIG ski ));

[0021] Among them, JoinConf is the message type, ID i It is node P i ID, r is the current round number, SigGen(h(m), SIG ski ) is P i After receiving 2f+1 NodeJoinAcc messages, node P n+1 Pack it and broadcast it to all nodes and MS, P n+1 It will join the network in round r+2. After receiving 2f+1 valid NodeJoinAcc messages, node P i Starting from round r+2, node P n+1 Join the system.

[0022] Preferably, the exit unit includes an exit request unit, a second verification unit and a notification unit;

[0023] The exit request unit is used for node P k Broadcast QuitNode to all nodes in the system;

[0024] QuitNode=((Quit, ID k , SIG pkk ), SigGen(h(m), SIG skk ));

[0025] Among them, Quit is the message type, ID k YesP k identity, SIG pkkis its public key, SigGen(h(m), SIG skk ) is the node P k Signature of h(m);

[0026] The second verification unit is used for each node P in the system i , i∈(1,...,n) receives P k After QuitNode is executed, if the signature is valid, it replies NodeQuitAcc to P k ;

[0027] NodeQuitAcc=((QuitConf, ID k , ID i , r), SigGen(h(m), SIG ski ));

[0028] Among them, QuitConf is the message type, ID i It is node P i identity, r is the current round number, SigGen(h(m), SIG ski ) is P i Signature of h(m);

[0029] The notification unit is used to receive 2f+1 NodeQuitAcc messages, and then the node P k Pack it and broadcast it to all nodes and MS, P k It will exit the network in round r+2. After receiving 2f+1 valid NodeQuitAcc messages, node P i In round r+2, node P k Exclude from the network.

[0030] Preferably, the clearing unit includes a node detection unit and a deletion unit;

[0031] The node detection unit is used for each node to send heartbeat messages to the MS regularly. If the heartbeat message of a node is not received within a certain period of time, the node is considered to be faulty and the node clearing process is started;

[0032] The deletion unit is used to find the node P s When a fault occurs, the MS broadcasts ClearAcc=(Clr, ID s ), all nodes immediately clear P from their network view upon receiving ClearAcc s , and P s Add to the local blacklist, where Clr represents the message type and IDs represents the identity of the node Ps.

[0033] Preferably, the signature module includes a key generation unit, a signature generation unit and a signature verification unit;

[0034] The key generation unit is used to generate (SIG pki , SIG ski ); K represents the security parameter, SIG ski Used for node generation signature, SIG pki Used by other nodes to check the validity of their signatures;

[0035] The signature generation unit is used to generate a signature according to SigGen(m, SIG ski ) obtain δ; m is the message to be signed, δ represents the output signature;

[0036] The signature verification unit is used by other nodes to verify δ and SIG pki Whether it matches or not, if it matches, it is a valid signature and outputs 1, otherwise outputs 0.

[0037] Preferably, the asynchronous BFT module includes a Byzantine reliable broadcast unit;

[0038] The Byzantine reliable broadcast unit meets the following properties:

[0039] If two correct replicas deliver two messages m and m', then m=m';

[0040] If a correct replica delivers a message m, then all correct replicas deliver m;

[0041] If a correct sender broadcasts a message m, then all correct replicas deliver m;

[0042] Each correct replica delivers a message m from a sender p at most once, if p is correct and m was broadcasted by p before.

[0043] Preferably, the asynchronous BFT module further comprises an asynchronous binary unit;

[0044] The asynchronous binary unit conforms to the following properties:

[0045] If all correct replicas have the same input value v, then the correct replica will pass v;

[0046] If one correct replica passes v and another correct replica passes v', then v = v';

[0047] All correct replicas eventually pass a binary value with probability 1.

[0048] Preferably, the threshold encryption scheme of the threshold encryption module includes dynamic threshold identity recognition;

[0049] The dynamic threshold identification steps include:

[0050] Enter security parameters 1 λ and the maximum number of network nodes N, set the algorithm output (MPK, SK), where MK is the master public key and SK is the master private key;

[0051] Input identity ID and master key pair (MPK, SK), the key generation algorithm outputs the private key of ID, denoted as d ID ;

[0052] Enter a set of identities ID1, ID2, ..., ID n , a threshold t, a message M and a master public key MPK, where n≤N and ⌈(n-1) / 3⌉≤t≤n, the encryption algorithm outputs a ciphertext, denoted as CT;

[0053] Input for (ID1, ID2, ..., ID n , t) ciphertext CT, private key d of identity ID ID and the master public key MPK, the decryption algorithm outputs the decryption share, denoted as S ID or ⊥;

[0054] Input for (ID1, ID2, ..., ID n , t) ciphertext CT, at least t decryption shares S ID1′ , S ID2′ , ..., S IDn′ and the master public key MPK, the combined algorithm outputs the message M or ⊥.

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

[0056] The present invention discloses an asynchronous blockchain dynamic monitor, including: a monitoring module for dynamically managing and troubleshooting the blockchain system; a signature module for verifying the identity of the node and the authenticity of the message; an asynchronous BFT module for integrating transaction requests into a common proposal subset to obtain a consensus result; a threshold encryption module for encrypting and decrypting transaction data according to the number of nodes. The present invention introduces a monitoring system to ensure efficient collaboration of nodes and consistency of the system in an asynchronous environment, thereby improving the scalability, reliability and security of the blockchain system. The application of this technology can not only optimize the performance of blockchain in traditional finance and supply chain management, but also achieve efficient supply chain management and data protection in the semiconductor industry, ensuring data security and traceability throughout the entire process from design to production. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0058] Figure 1 is a flowchart of an embodiment of the present invention;

[0059] Figure 2 This is an exit flow chart of an embodiment of the present invention;

[0060] Figure 3 Schematic diagram of asynchronous BFT consensus according to an embodiment of the present invention. DETAILED DESCRIPTION

[0061] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0062] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0063] Embodiment 1

[0064] This embodiment provides an asynchronous blockchain dynamic monitor, including:

[0065] Monitoring module, used for dynamic management and troubleshooting of blockchain systems;

[0066] Signature module, used to verify the identity of the node and the authenticity of the message;

[0067] Asynchronous BFT module, used to aggregate transaction requests into a common proposal subset to obtain consensus results;

[0068] The threshold encryption module is used to encrypt and decrypt transaction data according to the number of nodes.

[0069] Further, the monitoring module includes an entry unit, an exit unit and a clearing unit;

[0070] The join unit is used to join a new node;

[0071] The exit unit is used to exclude the node requesting exit from the network;

[0072] The clearing unit is used to clear the faulty node.

[0073] Further, the joining unit includes a joining request unit, a first verification unit and a node acceptance unit;

[0074] Join request unit for node P n+1 Call the Boneh-Boyen signature scheme's KeyGen to generate a key pair (SIG pkn+1 , SIG skn+1 ), node P n+1 Send JoinNode to MS;

[0075] JoinNode=((Join,SUB n+1 , SIG pkn+1 , ID n+1 ), SigGen(h(m), SIG skn+1 ));

[0076] Among them, Join is the message type, SUB n+1 It is by P n+1 Submissions to MS, SIG pkn+1 It is node P n+1 The public key, ID n+1 YesP n+1 ID, h(m) is the hash value of the information, SigGen(h(m), SIG skn+1 ) is P n+1 Signature of h(m);

[0077] The first verification unit is used to receive P n+1 After the JoinReq, the MS first checks the SUB n+1 To verify P n+1 Should we join the system, then check SigGen(h(m), SIG skn+1 ) is correct, if P n+1 Through the above verification, MS uses DTIBE.Gen to generate d IDn+1 As P n+1 The private key in the DTIBE scheme, then the MS will carry d IDn+1 The JoinAcc is sent to P n+1 , where Accept is the message type, JoinAcc=(Accept, JoinReq);

[0078] The node receiving unit is used to receive the JoinAcc, and the node P n+1 Broadcast JoinAcc to all nodes; for each node P i , i∈(1,...,n), upon receiving P n+1 After checking the JoinAcc, it replies to NodeJoinAcc to P n+1 ;

[0079] NodeJoinAcc=((JoinConf, ID n+1 , ID i , r), SigGen(h(m), SIG ski ));

[0080] Among them, JoinConf is the message type, ID i It is node P i ID, r is the current round number, SigGen(h(m), SIG ski ) is P i After receiving 2f+1 NodeJoinAcc messages, node P n+1 Pack it and broadcast it to all nodes and MS, P n+1 It will join the network in round r+2. After receiving 2f+1 valid NodeJoinAcc messages, node P i Starting from round r+2, node P n+1 Join the system, where f is the number of fault-tolerant nodes.

[0081] Further, the exit unit includes an exit request unit, a second verification unit and a notification unit;

[0082] Exit request unit for node P k Broadcast QuitNode to all nodes in the system;

[0083] QuitNode=((Quit, ID k , SIG pkk ), SigGen(h(m), SIG skk ));

[0084] Among them, Quit is the message type, ID k YesP k identity, SIG pkk is its public key, SigGen(h(m), SIG skk ) is the node P k Signature of h(m);

[0085] The second verification unit is used to verify that each node P in the system i , i∈(1,...,n) receives P k After QuitNode is executed, if the signature is valid, it replies NodeQuitAcc to P k ;

[0086] NodeQuitAcc=((QuitConf, ID k , ID i, r), SigGen(h(m), SIG ski ));

[0087] Among them, QuitConf is the message type, ID i It is node P i identity, r is the current round number, SigGen(h(m), SIG ski ) is P i Signature of h(m);

[0088] The notification unit is used to notify the node P after receiving 2f+1 NodeQuitAcc messages. k Pack it and broadcast it to all nodes and MS, P k It will exit the network in round r+2. After receiving 2f+1 valid NodeQuitAcc messages, node P i In round r+2, node P k Exclude from the network.

[0089] Further, the clearing unit includes a node detection unit and a deletion unit;

[0090] The node detection unit is used for each node to send heartbeat messages to the MS regularly. If the heartbeat message of a node is not received within a certain period of time, the node is considered to be faulty and the node clearing process is started;

[0091] The deletion unit is used to find the node P s When a fault occurs, the MS broadcasts ClearAcc=(Clr, ID s ), all nodes immediately clear P from their network view upon receiving ClearAcc s , and P s Add to the local blacklist.

[0092] Further, the signature module includes a key generation unit, a signature generation unit and a signature verification unit;

[0093] The key generation unit is used to generate (SIG pki , SIG ski ); K represents the security parameter, SIG ski Used for node generation signature, SIG pki Used by other nodes to check the validity of their signatures;

[0094] The signature generation unit is used to generate a signature according to SigGen(m, SIG ski ) obtain δ; m is the message to be signed, δ represents the output signature;

[0095] The signature verification unit is used by other nodes to verify δ and SIGpki Whether it matches or not, if it matches, it is a valid signature and outputs 1, otherwise outputs 0.

[0096] Further, the asynchronous BFT module includes a Byzantine reliable broadcast unit;

[0097] The Byzantine reliable broadcast unit meets the following properties:

[0098] If two correct replicas deliver two messages m and m', then m=m';

[0099] If a correct replica delivers a message m, then all correct replicas deliver m;

[0100] If a correct sender broadcasts a message m, then all correct replicas deliver m;

[0101] Each correct replica delivers a message m from a sender p at most once, if p is correct and m was broadcasted by p before.

[0102] Further, the asynchronous BFT module also includes an asynchronous binary unit;

[0103] Asynchronous binary units conform to the following properties:

[0104] If all correct replicas have the same input value v, then the correct replica will pass v;

[0105] If one correct replica passes v and another correct replica passes v', then v = v';

[0106] All correct replicas eventually pass a binary value with probability 1.

[0107] Further, the threshold encryption scheme of the threshold encryption module includes dynamic threshold identity recognition;

[0108] The dynamic threshold identification steps include:

[0109] Enter security parameters 1 λ and the maximum number of network nodes N, set the algorithm output (MPK, SK), where MK is the master public key and SK is the master private key;

[0110] Input identity ID and master key pair (MPK, SK), the key generation algorithm outputs the private key of ID, denoted as d ID ;

[0111] Enter a set of identities ID1, ID2, ..., ID n , a threshold t, a message M and a master public key MPK, where n≤N and ⌈(n-1) / 3⌉≤t≤n, the encryption algorithm outputs a ciphertext, denoted as CT;

[0112] Input for (ID1, ID2, ..., ID n , t) ciphertext CT, private key d of identity ID ID and the master public key MPK, the decryption algorithm outputs the decryption share, denoted as S ID or ⊥;

[0113] Input for (ID1, ID2, ..., ID n , t) ciphertext CT, at least t decryption shares S ID1′ , S ID2′ , ..., S IDn′ and the master public key MPK, the combined algorithm outputs the message M or ⊥.

[0114] The above asynchronous blockchain dynamic monitor is described as follows:

[0115] This embodiment proposes a new monitoring system (MonitorSystem, MS) based on Byzantine fault tolerance, which is the core part of the system. The existing asynchronous Byzantine fault-tolerant protocol can be made dynamic by using MS, specifically including: MS can monitor state changes, the addition of new nodes, the departure of nodes, and the removal of faulty nodes. When a new node applies to join the network, MS verifies it to ensure that its source is credible. After verification, MS distributes the necessary configuration parameters (such as public keys, network addresses, etc.) to the new node so that it can participate in network communication and consensus processes. These configuration parameters include the node's private and public key pairs, network connection information, and initial state information after joining. Each node in the system needs to run two protocols, one is the asynchronous Byzantine fault-tolerant protocol, and the other is the MS protocol. The two protocols use the same IP address but different ports to receive information to avoid message confusion. The MS solution is introduced as follows:

[0116] Joining scheme: In order to enable new nodes to join the network seamlessly without stopping or reconfiguring the entire system, the present invention designs a joining scheme. Assume that there are already n nodes in the system, and now a new node numbered n+1 wants to join the system. The scheme flow is as follows Figure 1 As shown, the specific steps are as follows:

[0117] 1. Join request phase: Node P n+1 Call the Boneh-Boyen signature scheme's KeyGen to generate its key pair (SIG pkn+1 , SIG skn+1 ). Node P n+1 Send JoinNode to MS.

[0118] JoinNode=((Join,SUB n+1 , SIG pkn+1 , IDn+1 ), SigGen(h(m), SIG skn+1 ));

[0119] Among them, Join is the message type, SUB n+1 It is by P n+1 Materials Submitted to MS. SIG pkn+1 It is node P n+1 The public key of the ID n+1 YesP n+1 ID. h(m) is the hash value of the above information, SigGen(h(m), SIG skn+1 ) is P n+1 The signature of h(m).

[0120] 2. Verification phase: After receiving P n+1 After the JoinReq, the MS first checks the SUB n+1 To verify P n+1 Should we join the system, then check SigGen(h(m), SIG skn+1 ) is correct. If P n+1 Through the above verification, MS uses DTIBE.Gen to generate d IDn+1 As P n+1 The private key in the DTIBE scheme. Then, the MS will carry d IDn+1 The JoinAcc is sent to P n+1 . Among them, Accept is the message type.

[0121] JoinAcc = (Accept, JoinReq);

[0122] 3. Node acceptance phase: After receiving JoinAcc, node P n+1 Broadcast JoinAcc to all nodes. For each node P i , i∈(1,...,n), upon receiving P n+1 After checking the JoinAcc, it replies to NodeJoinAcc to P n+1 .

[0123] NodeJoinAcc=((JoinConf, ID n+1 , ID i , r), SigGen(h(m), SIG ski ));

[0124] Where JoinConf is the message type. i It is node P i ID. r is the current round number. SigGen(h(m), SIG ski) is P i Signature of h(m). After receiving 2f+1 NodeJoinAcc messages, node P n+1 Package it and broadcast it to all nodes and MS. n+1 It will join the network at the beginning of round r+2. This design ensures that new nodes only join the system at the beginning of a new round, ensuring that there is enough time for message delivery. After receiving 2f+1 valid NodeJoinAcc messages, node P i Starting from round r+2, node P n+1 Join the system, where f is the number of fault-tolerant nodes.

[0125] Exit plan: When node P k When you want to leave the network, the solution process is as follows Figure 2 As shown, the specific steps are as follows:

[0126] 1. Exit request phase: Node P k Broadcast QuitNode to all nodes in the system.

[0127] QuitNode=((Quit, ID k , SIG pkk ), SigGen(h(m), SIG skk ));

[0128] Where Quit is the message type. k YesP k identity, SIG pkk is its public key. SigGen(h(m), SIG skk ) is the node P k The signature of h(m).

[0129] 2. Verification phase: For each node P in the system i , i∈(1,...,n), upon receiving P k After QuitNode is executed, if the signature is valid, it replies NodeQuitAcc to P k .

[0130] NodeQuitAcc=((QuitConf, ID k , ID i , r), SigGen(h(m), SIG ski ));

[0131] Where QuitConf is the message type. i It is node P i identity. r is the current round number. SigGen(h(m), SIGski ) is P i The signature of h(m).

[0132] 3. Notification phase: After receiving 2f+1 NodeQuitAcc messages, node P k Package it and broadcast it to all nodes and MS. k Will exit the network in round r+2. After receiving 2f+1 valid NodeQuitAcc messages, node P i In round r+2, node P k Exclude from the network.

[0133] Cleanup plan: The cleanup plan is designed to remove inactive (faulty) nodes from the consensus group. The specific steps are as follows:

[0134] 1. Node detection phase: Each node should send heartbeat messages to the MS regularly. If the heartbeat message of a node is not received within a certain period of time, the node is considered to be faulty and the node clearing process is started.

[0135] 2. Clearing phase: If node P is found s Failure, MS broadcasts ClearAcc=(Clr, ID s ), all nodes immediately clear P from their network view upon receiving ClearAcc s and add it to the local blacklist.

[0136] Signature algorithm: We assume that the identity of the node cannot be forged. To this end, a node needs to use its own signature to transmit various messages to other nodes. In this invention, this is ensured by using the Boneh-Boyen signature algorithm, which is simple, efficient and secure, and is suitable for signature requirements in distributed systems and multi-party computing. The aggregate signature of our system is introduced as follows:

[0137] 1. Key generation: KeyGen(k)→(SIG pki , SIG ski ). K represents the security parameter, SIG ski Used for node generation signature, SIG pki Used by other nodes to check the validity of its signature.

[0138] 2. Signature generation: SigGen(m, SIG ski) →δ. m is the message to be signed and δ represents the output signature.

[0139] 3. Signature verification: SigVerify(δ, SIG pki )→1 or 0. Other nodes verify δ and SIG pkiWhether it matches. If it is a valid signature, it outputs 1, otherwise it outputs 0.

[0140] This process ensures the accuracy and completeness of the message.

[0141] Asynchronous BFT protocol: The basic working process of asynchronous BFT protocol (such as HoneyBadgerBFT) is as follows Figure 3 As shown in Figure 1, HoneyBadgerBFT is the first practical asynchronous BFT protocol. Clients in the network send their transaction requests to all nodes, and the nodes execute the BFT protocol continuously. At the beginning of a round, each node will make its own proposal, and at the end of this round, a common subset of proposals will be output as the consensus result. It mainly consists of threshold encryption, Byzantine Reliable Broadcast (RBC) and Asynchronous Binary Protocol (ABA), where ABA and RBC are collectively called Asynchronous Common Subset (ACS).

[0142] Reliable Byzantine Broadcast (RBC): In RBC, a sender sends a message to all other replicas (slave nodes). An asynchronous RBC protocol satisfies the following properties:

[0143] Consistency: If two correct replicas deliver two messages m and m', then m=m'.

[0144] Comprehensiveness: If some correct replica delivers a message m, then all correct replicas deliver m.

[0145] Validity: If a correct sender broadcasts a message m, then all correct replicas deliver m.

[0146] Completeness: A message m delivered from a sender p is delivered at most once by each correct replica. If p is correct, then m was broadcasted by p before.

[0147] Asynchronous Binary Protocol (ABA): In the ABA protocol, each replica has a binary value as the initial input vinput (also called a vote). ABA allows replicas to agree on the value of a single bit and communicate that value. ABA satisfies the following properties:

[0148] Validity: If all correct replicas have the same input value v, then the correct replica will pass v.

[0149] Consistency: If one correct replica delivers v and another correct replica delivers v', then v = v'.

[0150] Termination: All correct replicas eventually deliver a binary value with probability 1.

[0151] Threshold encryption: The threshold encryption scheme TPKE in HoneyBadgerBFT can only set threshold parameters and define consensus groups during the configuration phase. This application uses the dynamic threshold identity identification DTIBE (Dynamic Threshold Identity-Based Encryption) scheme to replace TPKE. DTIBE includes the following five steps:

[0152] 1. DTIBE.Setup(1 λ , N)→(MPK, SK): Input security parameter 1 λ and the maximum number of network nodes N, set the algorithm output (MPK, SK), where MK is the master public key and SK is the master private key.

[0153] 2. DTIBE.Gen(ID, MPK, SK)→d ID :Input the identity ID and the master key pair (MPK, SK), the key generation algorithm outputs the private key of the ID, represented by d ID .

[0154] 3. DTIBE.Enc(ID1, ID2,..., ID n , t, M, MPK)→CT: Input a set of identities ID1, ID2, ..., ID n , a threshold t, a message M and the master public key MPK, where n≤N and ⌈(n-1) / 3⌉≤t≤n, the encryption algorithm outputs the ciphertext, denoted as CT.

[0155] 4. DTIBE.ShareDec(CT, d ID ,MPK)→S ID or ⊥: Input for (ID1, ID2, ..., ID n , t) ciphertext CT, private key d of identity ID ID and the master public key MPK, the decryption algorithm outputs the decryption share, denoted as S ID or ⊥.

[0156] 5. DTIBE.Combine (CT, S ID1′ , S ID2′ , ..., SID n′ , MPK)→M or ⊥: Input for (ID1, ID2, ..., ID n , t) ciphertext CT, at least t decryption shares S ID1′ , S ID2′ , ..., S IDn′ and the master public key MPK, the combined algorithm outputs the message M or ⊥.

[0157] Before the system starts running, eachi Node P i The signature key pair (SIG pki , SIG ski ). SIG pki It is node P i The public key of SIG ski is its private key used to generate the signature. MS verifies each node P i Whether to join the consensus group, then execute the DTIBE.Setup algorithm and broadcast the master public key MPK to all valid nodes in the network. MS will use the DTIBE.Gen algorithm to i Generate and send its private key d IDi Node P i The public information can be represented as a pair (ID i , SIG pki ), the consensus protocol is carried out in consecutive rounds. Assuming that the current round number is r, each node generates its proposal, and then the consensus protocol is executed among all nodes. Finally, the consensus result of round r is a common subset of the proposals. The consensus process is similar to HoneyBadger BFT. We use the DTIBE.Enc algorithm in the threshold encryption process, and each node uses DTIBE.ShareDec to calculate the threshold decryption process, and then uses DTIBE.Combine to get the plaintext, and then proceed to round r+1.

[0158] Through the above process, the system reaches a consensus and ensures the correctness and consistency of transactions.

[0159] The technical effects of the present invention are mainly reflected in the following aspects:

[0160] Enhance the system's dynamics and adaptability: This solution uses MS to effectively manage the system's dynamic joining, exiting, and clearing of nodes. This dynamicity significantly improves the flexibility of the Byzantine Fault Tolerant consensus system, enabling it to maintain high stability and consistency in a constantly changing network environment. MS can monitor system changes in real time and adjust the system configuration according to actual conditions, thereby avoiding the need to restart or reconfigure the system and ensuring continuous operation and efficient response of the system.

[0161] Improve the security and credibility of nodes: The design of the joining and exiting protocols ensures the security of node authentication and message delivery in the network. The joining protocol prevents the illegal joining of malicious nodes by verifying the identity of new nodes and distributing necessary configuration parameters. The exiting protocol ensures that the node will not affect the normal operation of the system when leaving the network through the signature authentication and round control of the nodes. In addition, the use of threshold encryption and signature algorithms further ensures the security of communication between nodes and the integrity of messages, reducing the risk of system attacks.

[0162] Optimized system performance and resource utilization: The design of MS enables the system to efficiently synchronize states and pass messages. The use of asynchronous communication protocols reduces delays and conflicts in inter-node communication and improves the system's processing power and response speed. The introduction of dynamic threshold identification schemes and signature algorithms further reduces computational and communication overhead and improves the overall performance of the system.

[0163] Improved system fault tolerance and stability: The introduction of the removal scheme enables the system to detect and remove faulty nodes in a timely manner, preventing these nodes from causing potential negative impacts on the system. By regularly detecting the heartbeat information of the nodes, the MS can quickly discover and handle faulty nodes to ensure high availability and stability of the system. In addition, the removal and blacklisting mechanism of faulty nodes further enhances the system's fault tolerance, allowing it to maintain efficient and stable operation in the face of complex network environments.

[0164] In summary, the present invention optimizes the dynamics, security, reliability and performance of the Byzantine fault-tolerant consensus system by introducing a monitoring system, effectively improving the stability and robustness of the system in a complex network environment, and providing users with a more reliable and efficient transaction confirmation service.

[0165] The above are only preferred specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An asynchronous blockchain dynamic monitor, characterized in that: include: Monitoring module, used for dynamic management and troubleshooting of blockchain systems; The monitoring module includes an entry unit, an exit unit and a clearing unit; The adding unit is used to add a new node; The joining unit includes a joining request unit, a first verification unit and a node acceptance unit; The join request unit is used for node P n+1 Call the Boneh-Boyen signature scheme's KeyGen to generate a key pair (SIG pkn+1 , SIG skn+1 ), node P n+1 Send JoinNode to the monitoring system MS; JoinNode=((Join,SUB n+1 ,SIG pkn+1 ,ID n+1 ), SigGen(h(m), SIG skn+1 )); Among them, Join is the message type, SUB n+1 It is by P n+1 Materials submitted to the monitoring system MS, SIG pkn+1 It is node P n+1 The public key, ID n+1 YesP n+1 ID, h(m) is the hash value of the information, SigGen(h(m), SIG skn+1 ) is P n+1 Signature of h(m); The first verification unit is used to receive P n+1 After the JoinReq, the monitoring system MS first checks the SUB n+1 To verify P n+1 Should we join the system, then check SigGen(h(m), SIG skn+1 ) is correct, if P n+1 Through the above verification, the monitoring system MS uses DTIBE.Gen to generate d IDn+1 As P n+1 The private key in the DTIBE scheme, then the monitoring system MS will carry d IDn+1 The JoinAcc is sent to P n+1 , where Accept is the message type, JoinAcc=(Accept, JoinReq); The node receiving unit is used to receive the JoinAcc, and then the node P n+1 Broadcast JoinAcc to all nodes; for each node P i , i∈(1,...,n), upon receiving P n+1 After checking the JoinAcc, it replies to NodeJoinAcc to P n+1 ; NodeJoinAcc=((JoinConf,ID n+1 ,ID i ,r),SigGen(h(m),SIG ski )); Among them, JoinConf is the message type, ID i It is node P i ID, r is the current round number, SigGen(h(m), SIG ski ) is P i After receiving 2f+1 NodeJoinAcc messages, node P n+1 Pack it and broadcast it to all nodes and monitoring system MS, P n+1 It will join the network in round r+2. After receiving 2f+1 valid NodeJoinAcc messages, node P i Starting from round r+2, node P n+1 Join the system, where f is the number of fault-tolerant nodes; The exit unit is used to exclude the node requesting exit from the network; The exit unit includes an exit request unit, a second verification unit and a notification unit; The exit request unit is used for node P k Broadcast QuitNode to all nodes in the system; QuitNode=((Quit,ID k ,SIGN pkk ),SigGen(h(m),SIG skk )); Among them, Quit is the message type, ID k YesP k identity, SIG pkk is its public key, SigGen(h(m), SIG skk ) is the node P k Signature of h(m); The second verification unit is used for each node P in the system i , i∈(1,...,n) receives P k After QuitNode is executed, if the signature is valid, it replies NodeQuitAcc to P k ; NodeQuitAcc=((QuitConf,ID k ,ID i ,r),SigGen(h(m),SIG ski )); Among them, QuitConf is the message type, ID i It is node P i identity, r is the current round number, SigGen(h(m), SIG ski ) is P i Signature of h(m); The notification unit is used to receive 2f+1 NodeQuitAcc messages, and then the node P k Pack it and broadcast it to all nodes and monitoring system MS, P k It will exit the network in round r+2. After receiving 2f+1 valid NodeQuitAcc messages, node P i In round r+2, node P k Exclude from the network; The clearing unit is used to clear the faulty node; Signature module, used to verify the identity of the node and the authenticity of the message; Asynchronous BFT module, used to aggregate transaction requests into a common proposal subset to obtain consensus results; The threshold encryption module is used to encrypt and decrypt transaction data according to the number of nodes.

2. The asynchronous blockchain dynamic monitor according to claim 1, characterized in that: The clearing unit includes a node detection unit and a deletion unit; The node detection unit is used for each node to periodically send heartbeat messages to the monitoring system MS. If the heartbeat message of a node is not received within a certain period of time, the node is considered to be faulty and the node clearing process is started; The deletion unit is used to find the node P s When a fault occurs, the monitoring system MS broadcasts ClearAcc=(Clr, ID s ), all nodes immediately clear P from their network view upon receiving ClearAcc s , and P s Add to the local blacklist, where Clr indicates the message type and ID s Represents node P s identity.

3. The asynchronous blockchain dynamic monitor according to claim 1, characterized in that: The signature module includes a key generation unit, a signature generation unit and a signature verification unit; The key generation unit is used to generate (SIG pki , SIG ski ); K represents the security parameter, SIG ski Used for node generation signature, SIG pki Used by other nodes to check the validity of their signatures; The signature generation unit is used to generate a signature according to SigGen(m, SIG ski ) obtain δ; m is the message to be signed, δ represents the output signature; The signature verification unit is used by other nodes to verify δ and SIG pki Whether it matches or not, if it matches, it is a valid signature and outputs 1, otherwise outputs 0.

4. The asynchronous blockchain dynamic monitor according to claim 1, characterized in that: The asynchronous BFT module includes a Byzantine reliable broadcast unit; The Byzantine reliable broadcast unit meets the following properties: If two correct replicas deliver two messages m and m', then m=m'; If a correct replica delivers a message m, then all correct replicas deliver m; If a correct sender broadcasts a message m, then all correct replicas deliver m; Each correct replica delivers a message m from a sender p at most once, if p is correct and m was broadcasted by p before.

5. The asynchronous blockchain dynamic monitor according to claim 1, characterized in that: The asynchronous BFT module also includes an asynchronous binary unit; The asynchronous binary unit conforms to the following properties: If all correct replicas have the same input value v, then the correct replica will pass v; If one correct replica passes v and another correct replica passes v', then v = v'; All correct replicas eventually pass a binary value with probability 1.

6. The asynchronous blockchain dynamic monitor according to claim 1, characterized in that: The threshold encryption scheme of the threshold encryption module includes dynamic threshold identity recognition; The dynamic threshold identification steps include: Enter security parameters 1 λ and the maximum number of network nodes N, set the algorithm output (MPK, SK), where MPK is the master public key and SK is the master private key; Input identity ID and master key pair (MPK, SK), the key generation algorithm outputs the private key of ID, denoted as d ID ; Enter a set of identities ID1, ID2, ..., ID n , a threshold t, a message M and a master public key MPK, where n≤N and ⌈(n-1) / 3⌉≤t≤n, the encryption algorithm outputs a ciphertext, denoted as CT; Input for (ID1, ID2, ..., ID n , t) ciphertext CT, private key d of identity ID ID and the master public key MPK, the decryption algorithm outputs the decryption share, denoted as S ID or ⊥; Input for (ID1, ID2, ..., ID n , t) ciphertext CT, at least t decryption shares S ID1′ , S ID2′ , ..., S IDn′ and the master public key MPK, the combined algorithm outputs the message M or ⊥.

Images