A dynamic quantum byzantine fault tolerance consensus method and server for blockchain

Abstract

The application relates to the technical field of blockchains, and discloses a dynamic quantum Byzantine fault-tolerant consensus method and a server for a blockchain. The method comprises the following steps: determining a master node of a current block on a blockchain from a consensus node set according to a hash value of a parent block of the current block, the current block being the latest block on the blockchain; if the consensus node itself is not the master node, receiving a proposal message of a candidate block broadcast by the master node, verifying the proposal message according to a symmetric quantum key; if the proposal message is verified, generating a response message to the proposal message based on the symmetric quantum key, and broadcasting the response message to other consensus nodes; after receiving the broadcasted response message, the master node writes the candidate block into the blockchain and connects the candidate block to the current block; and determining a master node of the candidate block from the consensus node set based on the hash value of the current block. The above method solves the problem of low decentralization degree of nodes and enables the blockchain platform to have security against quantum computing attacks.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a dynamic quantum Byzantine fault-tolerant consensus method and server for blockchain. Background Technology

[0002] Blockchain is a technological solution that collectively maintains a reliable database in a decentralized and trustless manner. Essentially, it's a decentralized database where every device in the blockchain system can act as a node, each node is allowed a complete copy of the data, and the nodes jointly maintain the entire blockchain based on a consensus mechanism. Blockchain data can be stored in the cloud, and each node can communicate with the cloud.

[0003] Consensus mechanisms enable mutually distrustful nodes to reach a secure and reliable consensus on the ledger state in a decentralized environment, serving as the core cornerstone for the secure and reliable operation of blockchain systems. Through mathematical and cryptographic principles, consensus mechanisms, while tolerating a certain number of node failures or malicious behavior (Byzantine faults), rigorously guarantee the legality of transactions, the determinacy of their order, and the immutability of the ledger history. This provides irreplaceable technical support for building secure, transparent, and censorship-resistant decentralized applications.

[0004] However, the relevant solutions suffer from problems such as low decentralization and low security. Summary of the Invention

[0005] The purpose of this application is to provide a dynamic quantum Byzantine fault-tolerant consensus method and server for blockchain, which solves the problem of low node decentralization and enables the blockchain platform to have security against quantum computing attacks.

[0006] To address the aforementioned technical problems, at least one embodiment of this application provides a dynamic quantum Byzantine fault-tolerant consensus method for blockchain. The method is executed by consensus nodes in a consensus node set, wherein the consensus node set is a set of nodes in a blockchain system, and each consensus node is one of several nodes in the consensus node set used to perform BFT consensus. Each consensus node is connected to a QKD device to obtain a symmetric quantum key. The method includes: determining the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain, where the current block is the block... The latest block on the chain; if the consensus node itself is not the master node of the current block, it receives the proposal message of the candidate block broadcast by the master node of the current block, and verifies the proposal message according to the symmetric quantum key; if the proposal message is verified, it generates a response message to the proposal message based on the symmetric quantum key, and broadcasts the response message to other consensus nodes, so that the master node of the current block, after receiving the broadcast response message, writes the candidate block into the blockchain and connects it to the current block; based on the hash value of the current block, it determines the master node of the candidate block from the set of consensus nodes.

[0007] At least one embodiment of this application provides a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, the method being executed by consensus nodes in a consensus node set, wherein the consensus node set is a node set in a blockchain system, and the consensus node is one of several nodes in the consensus node set used to perform BFT consensus, any one of the consensus nodes being connected to a QKD device to obtain a symmetric quantum key; the method includes: determining the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain, the current block being the latest block on the blockchain; if the consensus node itself is the master node of the current block, generating a candidate block based on the data to be added to the chain, generating a proposal message for the candidate block based on the symmetric quantum key, and broadcasting the proposal message to other consensus nodes in the consensus node set; receiving and counting response messages broadcast by the other consensus nodes, writing the candidate block into the blockchain and connecting it to the current block according to the response message, and determining the master node on the candidate block from the consensus node set based on the hash value of the current block.

[0008] At least one embodiment of this application provides a server, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the above-described dynamic quantum Byzantine fault-tolerant consensus method for blockchain.

[0009] Compared to related technologies, this application's embodiments determine the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain. The current block is the latest block on the blockchain. Simultaneously, after a candidate block is added to the chain, the hash value of the current block becomes the "parent block hash" of the candidate block. The same rules are used to determine the new master node, ensuring that all nodes have an equal opportunity to become master nodes, preventing the master node position from being monopolized by a few nodes, and maintaining the fairness and decentralization of the consensus process. Each consensus node in the block obtains a quantum key from its corresponding QKD device and generates broadcast information based on the quantum key. It also verifies the sending nodes of other broadcast messages and the signatures of other broadcast messages based on the quantum key, solving the quantum security problem of digital signatures in message transmission and preventing signature forgery or tampering under quantum computing attacks. Through independent computation and broadcast responses by multiple nodes, distributed verification of proposals is achieved, ensuring that the proposal content conforms to the consensus rules and guaranteeing the fault tolerance of the consensus. In summary, the method proposed in this application achieves quantum-resistant security, high decentralization, and dynamic fault tolerance by combining dynamic replacement of master nodes, quantum-secure verification based on quantum keys, and distributed consensus through broadcast messages. Attached Figure Description

[0010] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0011] Figure 1 This is an exemplary topology diagram of a consensus node set involved in an embodiment of this application;

[0012] Figure 2 This is a schematic diagram of the structure of a server provided in an embodiment of this application;

[0013] Figure 3 This is an exemplary flowchart of a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, as shown in an embodiment of this application.

[0014] Figure 4 This is a schematic diagram of a hash ring structure as shown in an embodiment of this application;

[0015] Figure 5 This is another exemplary flowchart of a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, as shown in another embodiment of this application;

[0016] Figure 6 This is a schematic diagram of the message distribution process of the QDBFT consensus mechanism involved in the embodiments of this application;

[0017] Figure 7 This is an exemplary flowchart illustrating the master node execution process of a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, as shown in another embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] Byzantine Fault Tolerance (BFT) consensus is a distributed system consensus mechanism widely used in the blockchain field. Its core objective is to address how to ensure honest nodes reach a consensus state when malicious nodes (Byzantine nodes) exist. Its core principle is to achieve consensus through inter-node communication and voting, guaranteeing system stability even in the presence of malicious nodes. Its key challenges lie in optimizing communication complexity, reducing latency, and improving scalability.

[0021] To address the issues of high communication overhead, low decentralization, and low security associated with changes to view nodes (i.e., master nodes) in existing solutions, this application provides a dynamic quantum Byzantine fault-tolerant consensus method for blockchain. This method is executed by consensus nodes from a consensus node set, where the consensus node set is the set of nodes in the blockchain system, and each consensus node is one of several nodes in the consensus node set used to execute BFT consensus. Any consensus node is connected to a QKD (Quantum Key Distribution) device to obtain a symmetric quantum key.

[0022] In some embodiments, Figure 1 An exemplary topology diagram of a consensus node set is provided. Please refer to [link / reference]. Figure 1 This topology illustrates the entity connectivity relationships between users, nodes, and QKD devices in the dynamic quantum BFT consensus method. Specifically, Figure 1 It contains three types of core entities and connections. First, the user side includes clients such as User 1 and User 2, which are the initiators of proposals (operation requests). The node network side includes consensus nodes such as Node 1, Node 2, Node 3, and Node 4, which are the core entities that execute the BFT consensus process. Each consensus node is connected to an independent QKD device. The QKD devices form a QKD network for transmitting symmetric keys so that the consensus nodes can obtain symmetric quantum keys.

[0023] In one example, a post-quantum cryptography digital signature algorithm, such as PQC (Post-Quantum Cryptography), is used between the user side and the node network side. During the consensus process, both the user and the node need to possess each other's public keys and sign messages using their own private keys (e.g., the user's private key). Signatures and nodes (Signature) ensures the legitimacy of messages between users and nodes and their resistance to quantum attacks. Nodes digitally sign messages using symmetric keys provided by the QKD network at an "information-theoretical security level." For example, in the "quantum digital signature" part, nodes transmit symmetric quantum keys to each other via QKD devices. Both signing and verifying signatures are based on these symmetric quantum keys. The physical layer security of QKD ensures that the keys cannot be cracked by quantum computing, thus achieving quantum-resistant security for message transmission between nodes.

[0024] This application provides a server, such as Figure 2As shown, it includes: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the dynamic quantum Byzantine fault-tolerant consensus method provided in the embodiments of this application (which will be described in detail later in this document and will not be repeated here).

[0025] In some embodiments, the memory and processor are connected via a bus, which may include any number of interconnected buses and bridges. The bus connects various circuits of one or more processors and the memory. The bus may also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over a wireless medium via an antenna, which further receives data and transmits it to the processor. The processor manages the bus and general processing, and may also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. The memory may be used to store data used by the processor during operation.

[0026] The entities of users, nodes, and QKD devices, as well as server devices, implement a dynamic quantum Byzantine fault-tolerant consensus method to solve the problems of high communication overhead and low decentralization caused by dynamic node changes and view (master node) carousel, thus enabling the blockchain platform to have security against quantum computing attacks.

[0027] In the aforementioned hardware and software operating environment, the related solutions suffer from problems such as high communication overhead, low decentralization, and low security when changing view nodes (master nodes). This application provides a dynamic quantum Byzantine fault-tolerant consensus method for blockchain. By determining the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain, the current block is the latest block on the blockchain. Simultaneously, after a candidate block is added to the chain, the hash value of the current block becomes the "parent block hash" of the candidate block. A new master node is determined using the same rules, ensuring that all nodes have an equal opportunity to become master nodes, preventing the master node identity from being monopolized by a few nodes, and maintaining the fairness and decentralization of the consensus process. Each consensus node in the block obtains a quantum key from its corresponding QKD device, generates broadcast information based on the quantum key, and verifies the sending nodes of other broadcast messages and the signatures of other broadcast messages based on the quantum key, as well as verifying the correctness of the signature of the broadcast message itself. This solves the quantum security problem of digital signatures in message transmission, preventing signature forgery or tampering under quantum computing attacks. By independently computing and broadcasting responses across multiple nodes, distributed verification of proposals is achieved, ensuring that the proposal content conforms to consensus rules and guaranteeing the fault tolerance of the consensus. In summary, this application's method achieves quantum-resistant security, high decentralization, and dynamic fault tolerance through a combination of dynamically changing master nodes, implementing quantum-secure verification based on quantum keys, and achieving distributed consensus via broadcast messages.

[0028] Figure 3 This is an exemplary flowchart illustrating a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, according to some embodiments of this specification. Figure 3 The process shown can be executed by a processing device, such as by... Figure 1 The nodes and clients shown are executed. In some embodiments, the process... Figure 3 The process shown may include the following steps.

[0029] Step 310: The consensus node determines the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain. The current block is the latest block on the blockchain.

[0030] In some embodiments, the master node of the current block determines the hash value of the parent block by two parts of information: the hash value of the predecessor block (parent block) of the latest block on the blockchain (i.e., the current block), and the hash values ​​of all consensus nodes on the current block.

[0031] In some embodiments, such as Figure 4 As shown, a hash ring is a hash space where 32-bit hash values ​​are concatenated end-to-end. The consensus node set is a set of N ordered nodes connected by a 32-bit hash ring (with values ​​ranging from 0 to (...)). Each consensus node is assigned hash points of equal distance. For example, the consensus nodes in the current block negotiate with each other to obtain a configuration table of their own hash points mapped on the hash ring. ,in, It represents a consensus node. This represents the position of a consensus node on the hash ring (e.g., Figure 4 (e.g., "Node 1", "Node 2" in the text) The number of all consensus nodes. This represents the configuration version number. All nodes maintain a consistent configuration table. and the configuration table Saved locally.

[0032] In some embodiments, in the parent block (i.e. Figure 4 After the "parent block" is generated (the genesis block assumes the parent block role during chain initialization), it is used... The function processes the parent node's hash value and generates the master node through an automatic master node rotation method. Specifically, the automatic master node rotation method can generate the master node as follows: Each consensus node calculates the hash value corresponding to its own identity and that of other consensus nodes, and determines its position on the hash ring based on the calculated hash value; each consensus node calculates the hash value of its parent block, and determines the position of the parent block mapped on the hash ring based on the parent block's hash value; based on the positions of the parent block and consensus nodes on the hash ring, the master node of the current block is determined from the consensus node set.

[0033] In some embodiments, determining the master node of the current block from the consensus node set based on the positions of the parent block and consensus nodes on the hash ring can be done as follows: if a consensus node exists at the position where the hash value of the parent block is mapped on the hash ring, then that consensus node is taken as the master node; if no consensus node exists at the position where the hash value of the parent block is mapped on the hash ring, then the first consensus node searched clockwise along the hash ring is taken as the master node. For example, using... The function determines the hash value of the parent block, specifically H. 32 (H(Father-Block)), where "Father-Block" is the parent block. Determine the parent block hash value, such as... Figure 4 The "parent block hash value" maps the parent block hash value to a specific location on the hash ring, for example... Figure 4 The position indicated by the dotted line is then searched clockwise along the hash ring. The first matching consensus node is the master node of the current block. For example... Figure 4 The "Node 2" node on the hash ring shown is the first node to match the consensus node, and "Node 2" serves as the master node for the current block. Figure 4 (The "new block node" in the middle).

[0034] In some embodiments, since the total hash space of the hash ring is fixed, the hash ring is a 32-bit hash ring, and its value range is... When the actual number of consensus nodes ( When the number of hash points (positive integers) is small, if each node is allocated only one hash point, the distance between hash points of adjacent nodes on the hash ring will be large. The probability of the parent block hash value mapping to the corresponding interval of each node may deviate due to the insufficient fineness of the interval distribution, resulting in some nodes having an excessively high or low probability of being selected as the master node. To make the probability of each consensus node being determined as the master node more similar, when allocating hash points of equal distance to each consensus node, the actual number of consensus nodes N is virtually increased to [a higher value]. ( For example, an integer greater than 1, such as This means creating five times the number of actual nodes (essentially increasing the number of virtual nodes, such as...). Figure 4 By symmetrically setting nodes 1, 2, etc., the hash ring is divided into finer, equal-length intervals. Then, the maximum value of the hash ring is divided by the expanded total number of intervals. This allows us to obtain the spacing (i.e., equal-length distance) between each hash point, thereby determining the specific location of all virtual hash points. Since the total number of virtual nodes is a fraction of the total number of actual nodes... The multiple, each actual node will correspond to There are multiple virtual hash points, meaning that a consensus node is mapped to multiple hash points. These virtual points are evenly distributed on the hash ring, covering a total interval of equal length. In this way, when the parent block hash value is mapped onto the hash ring, it falls into the corresponding position of each actual node. The sum of the probabilities of each virtual point interval is equal (because the total interval length is the same), thus making the probability of each consensus node being determined as the master node more consistent, avoiding the probability imbalance caused by a small number of nodes, and further ensuring the fairness and decentralization of the consensus mechanism.

[0035] Step 320: If the consensus node itself is not the master node, it receives the proposal message of the candidate block broadcast by the master node and verifies the proposal message according to the symmetric quantum key.

[0036] In one example, a client proposal is a specific business operation that the client wants the blockchain to execute, such as a transfer instruction, a data storage request, or smart contract call parameters. When a client wants to execute a business operation, it generates a proposal message containing the main content and the client's signature. Any consensus node in the current block obtains the proposal message generated by the client, and after the consensus node verifies the client's signature (i.e., the PQC signature of the proposal sent by the client user), it stores these proposal messages in its local cache pool. The proposal messages for candidate blocks are a subset of client proposals selected by the current master node from the local cache pool, and a message containing these proposals and related metadata is generated. This message is appended with a quantum signature generated based on a symmetric key, where the symmetric key is a quantum symmetric key generated by a QKD device.

[0037] In one example, other consensus nodes verify the proposal message for the candidate block broadcast by the master node. The verification process can involve consensus nodes verifying the message based on a symmetric quantum key shared with the master node. The verification process consists of two parts: first, verifying that the proposal message for the candidate block was sent by the master node; and second, verifying that the signature of the proposal message itself is correct.

[0038] Step 330: If the proposal message is verified, a response message to the proposal message is generated based on the symmetric quantum key, and the response message is broadcast to other consensus nodes.

[0039] In some embodiments, other consensus nodes successfully verify the proposal message broadcast by the master node. The verification criteria can be that the consensus nodes, using a shared symmetric quantum key (distributed by the QKD network) with the master node, confirm that the proposal message was sent by the master node, that the signature of the proposal message is valid (i.e., it indeed comes from the master node, data source authenticity verification passed), and that the message has not been tampered with (integrity verification passed). After successful verification, the consensus nodes generate a response message and attach signatures based on the symmetric quantum key. That is, the consensus nodes use the shared symmetric quantum key with other nodes (including the master node) to generate multiple signatures, ensuring the quantum security and immutability of the response message, and simultaneously include multiple signatures in a single broadcast message. The consensus nodes broadcast the signed response message to the entire consensus node set, ensuring that all nodes, including the master node, can receive the response, providing a basis for subsequent consensus confirmation.

[0040] In some embodiments, after receiving a broadcast response message, the master node writes the candidate block to the blockchain and adds it to the current block. It's important to clarify that the master node is essentially also a consensus node. After any consensus node receives and verifies a sufficient number of response messages, the block is finally added to the blockchain. For example, according to the fault tolerance requirements of the BFT mechanism, when any consensus node receives... If a majority of nodes reach a consensus on the execution result of the proposal set, then the legitimacy of the candidate block is considered to have been confirmed by the network. , The number of consensus nodes in the consensus node set. To round down, the master node generates a commit message containing the consensus result, ultimately writing the candidate block into the blockchain and "linking it to the current block." At this point, the parent hash of the candidate block points to the hash of the current block, maintaining the chain structure and temporal order of the blockchain, ensuring the continuity and immutability of the ledger. In this way, by having multiple nodes independently generate and broadcast response messages, "decentralized verification" of candidate blocks is achieved, avoiding the influence of a single node's subjective decision on the block's legitimacy. The symmetric quantum key signature of the response message ensures that even in a quantum computing environment, malicious nodes cannot forge or tamper with the response, guaranteeing the security of the consensus process.

[0041] Step 340: The consensus node determines the master node of the candidate block from the consensus node set based on the hash value of the current block.

[0042] In some embodiments, the master node of a new block is determined based on information from the preceding block. Specifically, the "new block" here refers to a confirmed candidate block on the blockchain. After a candidate block is written into the blockchain through consensus, its corresponding "master node" (i.e., the master node responsible for the next round of consensus) needs to be determined according to fixed rules. First, the preceding block is used as the new parent block. Using the same mechanism as the preceding master node, the hash value of the current block (the preceding block) is mapped onto the hash ring through a 32-bit hash ring. The first matching node configuration table found in a clockwise direction is then used ( The node of the hash point in the block is the master node corresponding to the candidate block (which has now become the new current block).

[0043] Specifically, assuming the latest block B in the blockchain... n Its master node A is based on parent block B. n-1 The hash value is determined; when B n After being uploaded to the blockchain, the next block B n+1 The master node A' (i.e., the "candidate block") is based on B. n The hash value is determined by the same rules; this cyclical mechanism, which dynamically elects the master node based on the parent block hash and generates a block containing the new block hash, thus triggering the next round of automatic master node replacement, achieves the periodic rotation of consensus dominance, fundamentally eliminating the technical risk of a single node controlling the consensus dominance for a long time. By dynamically rotating the master node according to fixed rules, it ensures that the master node for each block is objectively determined by the previous block hash and the node configuration table, avoiding human intervention or power concentration, and maintaining the decentralized nature of the system. In this process, the node configuration table (… It will update in real time as nodes join, leave, or fail (version upgrade to). The hash points of the nodes on the hash ring are also adjusted accordingly. Determining the new master node based on the current block hash and the latest configuration table ensures that even if the node set changes, the master node determination remains based on the latest state, guaranteeing consensus stability. Thus, by using the hash value of the current block and following fixed rules to determine the next master node from the node set, both the continuity of decentralization and the stability of the consensus process are ensured.

[0044] Through steps 310 to 340 above, a dynamic quantum Byzantine fault-tolerant consensus method is implemented. This method determines the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain. The current block is the latest block on the blockchain. Simultaneously, after a candidate block is added to the chain, the hash value of the current block becomes the "parent block hash" of the candidate block. A new master node is determined using the same rules, ensuring that all nodes have an equal opportunity to become the master node, preventing the master node position from being monopolized by a few nodes, and maintaining the fairness and decentralization of the consensus process. Each consensus node in the block obtains a quantum key from its corresponding QKD device and generates broadcast information based on the quantum key. It also verifies the sending nodes of other broadcast messages and the signatures of other broadcast messages based on the quantum key, and verifies that the signature of the broadcast message itself is correct. This solves the quantum security problem of digital signatures in message transmission, preventing signature forgery or tampering under quantum computing attacks. Through independent computation and broadcast responses by multiple nodes, distributed verification of proposals is achieved, ensuring that the proposal content conforms to the consensus rules and guaranteeing the fault tolerance of the consensus. In summary, the method shown in this embodiment achieves quantum-resistant security, high decentralization, and dynamic fault tolerance by combining dynamic master node replacement, quantum-secure verification based on quantum keys, and distributed consensus through broadcast messages.

[0045] To address the issue of excessive key consumption in related quantum-resistant digital signature schemes, this paper proposes an information-theoretically secure key provided by a QKD network, along with a key exchange method and a message generation method, to reduce key consumption. Figure 5 This is an exemplary flowchart illustrating a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, as shown in some embodiments of this application. Figure 5 As shown, in some embodiments, the dynamic quantum Byzantine fault-tolerant consensus method for blockchain may include the following steps.

[0046] Step 510: The consensus node determines the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain. The current block is the latest block on the blockchain.

[0047] Step 520: The consensus node shares an independent set of symmetric quantum keys with each of the other consensus nodes.

[0048] The symmetric quantum key is generated by a QKD device.

[0049] In some embodiments, each consensus node connects to an independent QKD device, which generates a symmetric quantum key with "information-theoretical security" through quantum communication technology (such as the BB84 protocol). Unlike the computational security of traditional cryptography, the keys generated by QKD are based on the principles of quantum mechanics and are theoretically unbreakable by quantum or classical computing, ensuring key security at the physical layer. The key is shared pairwise among the consensus nodes in the consensus node set, meaning that for each node containing... A set of nodes Each node generates and shares a unique set of symmetric quantum keys with every other node, forming the node-to-node symmetric quantum keys. For example, these symmetric quantum keys are the foundation for secure message transmission between nodes, specifically used for digital signature generation, signature verification, and verification of the message sending node. For instance, a node... To the node Send message At that time, it will be based on the shared key. Generate signature ,in, For message summary, This is an information-theoretic secure hash function. Those skilled in the art should know that nodes... With nodes Shared key ,node With nodes Shared key Completely independent and unrelated to each other. Any third-party node (such as...) Unable to obtain or derive The key content ensures that the key is kept secret only between the two nodes. This design avoids the risk of "a single key being cracked, causing the entire network to fail in security." Even if a key set is abnormal, it only affects the communication between the two nodes and does not affect the entire blockchain network.

[0050] Step 530: If the consensus node itself is not the master node, it receives the proposal message of the candidate block broadcast by the master node and verifies the proposal message according to the symmetric quantum key.

[0051] In some embodiments, the proposal message includes the master node's signature on the proposal message and a message generated by the master node. The consensus node decrypts the signature of the proposal message using the symmetric quantum key shared with the master node; based on the decryption result, it determines whether the master node's identity has been verified.

[0052] Step 540: If the proposal message is verified, a response message to the proposal message is generated based on the symmetric quantum key, and the response message is broadcast to other consensus nodes.

[0053] In some embodiments, after the proposal message is verified, the consensus node generates decision information and execution result information based on the message generated by the master node; based on each set of independent symmetric quantum keys shared with other consensus nodes, it encrypts and signs the decision information to obtain multiple signatures; it generates a response message based on the multiple signatures and execution result information, and broadcasts the response message to other consensus nodes so that other consensus nodes can decrypt and verify the response message based on the symmetric quantum keys shared with this node.

[0054] In some embodiments, after receiving a broadcast response message, the master node writes the candidate block into the blockchain and attaches it to the current block.

[0055] Step 550: The consensus node determines the master node on the candidate block from the consensus node set based on the hash value of the current block.

[0056] Obviously, step 510 is similar to step 310, and steps 530 to 550 are similar to steps 320 to 340, so they will not be described in detail here.

[0057] In some embodiments, the consensus node also receives requests generated by external nodes and / or internal nodes, and generates request decision information and request execution result information based on the requests; it performs encrypted signatures on the request decision information based on each set of symmetric quantum keys shared with other consensus nodes to obtain multiple signatures, and generates corresponding request proposal messages based on the multiple signatures and requests, and broadcasts the request proposal messages; it obtains response messages from other consensus nodes to the request proposal messages, and determines whether to agree to the requests of external nodes and / or internal nodes based on the number of response messages obtained.

[0058] The requests generated by external nodes are join requests, while the requests generated by internal nodes are exit requests.

[0059] In one example, a consensus node receives a join request from an external node, signs and encrypts the join request using a symmetric quantum key shared with other consensus nodes to obtain a signature, generates a join proposal message based on the signature and the join request, and broadcasts it; it then obtains response messages from other consensus nodes to the join proposal message, and determines whether to agree to the external node joining based on the number of response messages obtained.

[0060] In one example, a consensus node receives a withdrawal request from another consensus node, encrypts the withdrawal request using a symmetric quantum key shared with other consensus nodes to obtain a signature, generates a withdrawal proposal message based on the signature and the withdrawal request, and broadcasts it; it then obtains response messages from other consensus nodes to the withdrawal proposal message, and determines whether to agree to the withdrawal of that consensus node based on the number of response messages obtained.

[0061] Thus, by using the hash value of the parent block of the current block on the blockchain, the master node of the current block is determined from the consensus node set. The current block is the latest block on the blockchain. Simultaneously, after a candidate block is added to the chain, the hash value of the current block becomes the "parent block hash" of the candidate block. The same rules are used to determine the new master node, ensuring that all nodes have an equal opportunity to become master nodes, preventing the master node position from being monopolized by a few nodes, and maintaining the fairness and decentralization of the consensus process. Each consensus node in the block obtains a quantum key from its corresponding QKD device and generates broadcast information based on the quantum key. It also verifies the sending nodes of other broadcast messages and the signatures of other broadcast messages based on the quantum key, and verifies that the signature of the broadcast message itself is correct. This solves the quantum security problem of digital signatures in message transmission, preventing signature forgery or tampering under quantum computing attacks. Through independent computation and broadcast responses by multiple nodes, distributed verification of proposals is achieved, ensuring that the proposal content conforms to the consensus rules and guaranteeing the fault tolerance of the consensus. In summary, the method proposed in this application achieves quantum-resistant security, high decentralization, and dynamic fault tolerance by combining dynamic replacement of master nodes, quantum-secure verification based on quantum keys, and distributed consensus through broadcast messages.

[0062] To address the issues of high communication overhead, low decentralization, and low security associated with changes to view nodes (master nodes) in existing solutions, this application also provides another dynamic quantum Byzantine fault-tolerant consensus method for blockchain in some embodiments. This method is executed by consensus nodes in a consensus node set, where the consensus node set is a set of nodes in the blockchain system, and each consensus node is one of several nodes in the consensus node set used to execute BFT consensus. Any consensus node is connected to a QKD device. The Dynamic Quantum Byzantine Fault-Tolerant Consensus Method determines the master node for the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain. The current block is the latest block on the blockchain. Simultaneously, after a candidate block is added to the chain, the hash value of the current block becomes the "parent block hash" of the candidate block. The same rules are used to determine the new master node, ensuring that all nodes have an equal opportunity to become the master node, preventing the master node position from being monopolized by a few nodes, and maintaining the fairness and decentralization of the consensus process. Each consensus node in the block obtains a quantum key from its corresponding QKD device and generates broadcast information based on the quantum key. It also verifies the sending nodes of other broadcast messages and the signatures of other broadcast messages based on the quantum key, and verifies the correctness of the signature of the broadcast message itself. This solves the quantum security problem of digital signatures in message transmission, preventing signature forgery or tampering under quantum computing attacks. Through independent computation and broadcast responses by multiple nodes, distributed verification of proposals is achieved, ensuring that the proposal content conforms to the consensus rules and guaranteeing the fault tolerance of the consensus. In summary, the method proposed in this application achieves quantum-resistant security, high decentralization, and dynamic fault tolerance by combining dynamic replacement of master nodes, quantum-secure verification based on quantum keys, and distributed consensus through broadcast messages.

[0063] Figure 7 This is an exemplary flowchart illustrating a dynamic quantum Byzantine fault-tolerant consensus method for blockchain, according to some embodiments of this specification. Figure 7 The process shown can be executed by a processing device, such as by... Figure 1 The server and client are shown in the diagram. In some embodiments, the stream... Figure 7 The process shown may include the following steps.

[0064] Step 710: The consensus node determines the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain. The current block is the latest block on the blockchain.

[0065] Step 710 is similar to step 310, and will not be repeated here.

[0066] Step 720: If the consensus node itself is the master node, it generates candidate blocks based on the data to be uploaded to the chain, generates proposal messages for the candidate blocks based on the symmetric quantum key, and broadcasts the proposal messages to other consensus nodes.

[0067] Please see Figure 6 , Figure 6 A schematic diagram of the message distribution process for a QDBFT (quantum-safe dynamic BFT consensus mechanism) consensus mechanism is provided, and its processing flow is shown in the attached figure. Figure 6 As shown in the attached figures, each will be explained in detail.

[0068] In some embodiments, a node determines whether it is the master node for the current round based on the hash value of the parent block of the current block, using a 32-bit hash ring mapping rule (mapping the hash value to a hash ring, and finding the first matching hash point in the node configuration table clockwise is the master node). The node needs to check the configuration table ( The hash point information within the block proves its identity as a master node, preventing "fake master nodes" from initiating erroneous proposals. After confirming its identity, the master node's core task is to generate candidate blocks, with the data to be added to the chain originating from a local buffer pool. The buffer pool stores data submitted by clients via [the blockchain]. Message submission, and a valid proposal verified by the node (including operation requests). timestamp Client identity Candidate blocks not only contain a set of proposals selected from the buffer pool (etc.). In addition, key metadata such as the parent block hash (to ensure consistency with the existing blockchain chain) and block height (are also required) must be attached. ), Generate timestamp ( These, along with master node identity identifiers, form a complete block structure.

[0069] For example, the client signs the proposal after generating it. and send the message to any node (such as...) Figure 4 The middle part is "Node 2"). After Node 2 verifies the client's proposal, it stores the proposal in the local buffer pool, such as... Figure 6 The request phase is shown. (Among them) These are operation requests, such as specific business operations that the client wants the blockchain to perform, such as transfer instructions ("transfer 100 tokens to user A"), data storage requests ("store file hash XXX"), smart contract call parameters, etc. It is a request timestamp, such as recording the precise time when the proposal was initiated (e.g., a Unix timestamp). Timestamps can prevent "replay attacks" (avoiding the same proposal being maliciously submitted repeatedly) and can also be used to determine the temporal relationship of proposals (subsequent consensus processes are sorted by timestamps to ensure the order of operations). It is client identity information, such as identifying the client that initiated the proposal. It is usually the client's public key hash or account address, ensuring that the proposal is traceable (in line with the "traceable" characteristic of blockchain), and also providing a basis for subsequent permission verification (such as certain operations requiring specific permissions from specific clients). For signing, the client... A digital signature generated using the client's private key, where the PQC algorithm is used between the client and the node. The essence of the signature is "identity endorsement," meaning the receiving node can verify the signature using the client's public key. We confirmed two points: ① The proposal was indeed initiated by the client identified by c (the data source is real and not forged); ② The content of o, t, c has not been tampered with (integrity verification).

[0070] The client does not need to rely on a specific node and can submit data to any consensus node in the blockchain network (such as...). Figure 4 The proposal was submitted by "Node 2" in the blockchain. This demonstrates the decentralized nature of blockchain, meaning the system does not rely on a single node to receive requests. Even if some consensus nodes fail, clients can still access the system through other consensus nodes, improving the system's resilience and flexibility. Then, the client's public key is used to verify the proposal's origin and signature. If the verification passes (the signature matches the client's private key, and...) If the content has not been tampered with, the proposal is considered valid; if verification fails (e.g., signature forgery, content tampering), the proposal is rejected. Valid proposals are stored in Node 2's local buffer pool. This local buffer pool is a temporary storage space for proposals awaiting consensus, similar to a queue of tasks to be processed, waiting for subsequent master nodes (master nodes) to complete the consensus "pre-preparation phase" (e.g., ...). Figure 6 The master node selects proposals from its local buffer pool during the "pre-preparation phase" to initiate the block consensus process. When selecting proposals from the local buffer pool, the master node typically sorts them by timestamp or filters them according to consensus rules (such as removing duplicates and invalid proposals) to ensure that the candidate block content conforms to the blockchain rules. After generating candidate blocks, the master node needs to broadcast the proposal message to start the "pre-preparation phase" of the network-wide consensus process.

[0071] Please continue reading. Figure 6 After the master node enters the pre-preparation phase, its core task is to initiate candidate blocks and initiate consensus. For example, the master node starts a timer to monitor the process progress and prevent consensus from stalling. A subset of proposal messages is selected from the buffer pool. ,in, These are proposals selected from the local buffer pool (which stores valid client proposals) to be uploaded to the blockchain. This is the maximum number of blocks selected each time (used to determine the block size). Then the master node generates and broadcasts the message. and its corresponding signature Where 'a' represents the current master node identity (master node identifier); This refers to the current configuration table version; It is the hash value of the parent block (to ensure a chain structure). Is the master node in The hash point in the data (evidence proving that it is a legitimate master node). T is the block height (indicating the block's position in the chain); T is the timestamp of the new block being added to the chain. Message digest for proposal set M (used to simplify transmission and ensure integrity). Decision information (can take values ​​of 0 or 1 to indicate whether to pass or fail). Based on symmetric quantum key The generated ( (for other consensus nodes) This represents the number of nodes in the current consensus node set. Include ( (Summary) and , (Hash checksum) ensures message resistance to quantum tampering and authenticity of the data source. By generating and broadcasting messages, all nodes synchronize candidate block content, facilitating subsequent message source verification and signature verification (such as...). Figure 6 (The response phase) provides a unified object.

[0072] After the master node enters the pre-preparation phase, if the master node In the event of a failure or non-performance of duties, the system maintains consensus through the following process. First, when the timer expires, the master node... Not sent or consensus node No master node received If a broadcast message is received, an offline check is triggered to prevent consensus from stalling due to master node failure. At this time, the consensus node... generate Messages and Signatures ,in, Including nodes Identity, Offline Master Node Identity, timestamp Current configuration table Used to inform all master nodes in the network Offline; signature based on symmetric quantum key distribution (j represents other consensus nodes), ensuring the legitimacy of the notification. When a sufficient number of nodes (exceeding the fault tolerance threshold) , Confirm master node Offline, update configuration table → (u represents the updated version, marking the master node) (Offline), and generates new master nodes through automatic carousel. To ensure the consensus continues.

[0073] After the master node enters the pre-preparation phase, if the master node If there are no pending proposals (no new operation requests) in the local buffer pool, the master node identity needs to be transferred to avoid consensus idling. Transfer the identity to the first node in a clockwise direction. Simultaneously generate Messages and Signatures .in, Including the current node Target Node timestamp Configuration Table Parent block hash digest Block height Proving the legitimacy of the transfer; the signature is based on symmetric quantum keys. This ensures the transfer instructions are genuine and valid. Node e becomes the new master node, continuing to process subsequent proposals and maintaining the continuity of the consensus process.

[0074] Step 730: The master node receives and counts the response messages broadcast by other consensus nodes, determines whether to write the candidate block into the blockchain and connect it to the current block based on the number of response messages, and determines the master node on the candidate block from the consensus node set based on the hash value of the current block.

[0075] Please continue reading. Figure 6 In step 730, after each consensus node enters the transmission phase, the consensus nodes perform distributed verification of the candidate block proposals initiated by the master node and provide feedback on the decision results. This aims to achieve decentralized verification of consensus through independent judgment by multiple nodes. For example, consensus nodes... These are the other consensus nodes that were not selected as the current master node. It is the current master node. This is the total number of nodes. Consensus nodes. Received from master node Broadcast during the preparation phase After receiving the message (including the candidate block proposal set M, the master node decision R, etc.), the transmission phase begins. Consensus node Its primary task is to independently validate proposals and generate its own decision outcomes. For each proposal in M... consensus node Calculate independently and make your own decisions. .in, This indicates approval of the proposal. To indicate refusal, yes The actual number of proposals submitted.

[0076] During the transmission phase, consensus nodes After verifying the message source, signature, and generating a decision, the decision result and execution result need to be broadcast to the entire network, including the result set and its corresponding signature, which can be in the following form.

[0077]

[0078]

[0079] in, Identify the consensus node that is currently sending the message (to ensure traceability); It is the identity of master node A (identifying the master node and proposal corresponding to this message); Indicates the message reply timestamp (to prevent replay attacks and determine the decision sequence); The current configuration table version (ensuring all nodes participate in consensus based on the same node list and rules); for Message digest value (quick verification) (The content has not been altered) It is the summary value of the proposal set M (to verify that the content of M is consistent with the broadcast by the master node); Represents consensus nodes right The decision result set (core feedback content) for each proposal. yes Message digest (ensuring its own integrity); Based on nodes Other consensus nodes Symmetric quantum key The generated hash value (a symmetric quantum key distributed via a QKD network) is used to prove that the message indeed originated from the node. (The data source is authentic) and possesses quantum-resistant security (preventing quantum computing from forging signatures), allowing the master node to... All nodes, including The decision results provide a data foundation for the subsequent submission phase to "statistically collect enough consistent decisions".

[0080] Please continue reading. Figure 6 All nodes in step 730 Locally available Consistent The message count then enters the final confirmation stage (submission stage), in which... This represents the total number of nodes. This represents the number of malicious or faulty nodes that the system can tolerate. Consistent Message, representing a node We have received decision results from more than half (excluding f potentially abnormal nodes) of the consensus nodes. These results are consistent in their core content (e.g., regarding the set of proposals). (The approval / rejection conclusions of all proposals are consistent). This condition ensures that nodes entering the submission phase have a sufficient number of distributed verification results to lay the foundation for final confirmation and avoid the impact of abnormal decisions by a few nodes on the results. After entering the submission phase, a node needs to generate and broadcast a message and a signature. The generated message and signature can be in the following forms.

[0081]

[0082]

[0083] exist middle, This provides the identity information of the node that currently generates the message (ensuring message traceability; any node can generate this message, reflecting decentralization). The timestamp for message generation (to prevent replay attacks and mark the confirmation sequence); This is the current configuration table version (ensuring all nodes participate in the final confirmation based on the same set of node rules); It is the hash value of the parent block (which binds the current block to the existing chain of the blockchain to maintain the continuity of the chain structure). It is the block timestamp (records the time when the block was finally confirmed, used for time-series sorting); It is a core field in the message; specifically, it comes from the proposal set. Filter out all those All nodes unanimously agree ( For each proposal with a value of 1, a hash value is calculated, and then a root hash (MerkleRoot) is generated using the Merkle tree algorithm. The integrity of all approved proposals within a block is efficiently verified using a single root hash value (any tampering with a proposal will cause the MerkleRoot to change), while simplifying block storage and verification costs.

[0084] exist middle, The message digest value is used to ensure the integrity of the message itself and prevent it from being tampered with during transmission; Consensus Node With consensus nodes Symmetric quantum key The hash value generated and distributed over the QKD network proves that the message did indeed originate from the node. Furthermore, it possesses quantum-resistant security (quantum computing cannot forge this signature). The signature mechanism ensures the security of the final confirmation message, preventing malicious nodes from forging confirmation results and interfering with the blockchain's on-chain processing.

[0085] During the submission phase, when received The commit is complete once the number of consistent messages reaches 1, where 1, Consistent The message indicates that the fault tolerance threshold has been exceeded (excluding) All nodes (including potentially abnormal nodes) agree on the legitimacy of the block, reaching a final consensus across the entire network. The candidate block is then officially written into the blockchain, and its MerkleRoot, parent block hash, and other information are fixed, becoming an integral part of the blockchain. Afterwards, each node returns the processing result to the client, i.e., the REPLY phase.

[0086] In this way, through multi-node collaborative confirmation, Merkle tree verification and quantum-safe signature in step 730, the final closed loop from "candidate" to "officially added to the chain" of the block is realized.

[0087] In some embodiments, a consensus node receives a join request from an external node, signs and encrypts the join request using a symmetric quantum key shared with other consensus nodes to obtain a signature, generates a join proposal message based on the signature and the join request, and broadcasts it; it obtains response messages from other consensus nodes to the join proposal message, and determines whether to agree to the external node joining based on the number of response messages obtained.

[0088] Specifically, new nodes do not need to apply to a specific master node; they can initiate a join request to any consensus node in the network, reflecting the decentralized nature of blockchain. The request typically includes the new node's identity information (such as public key and node identifier), qualification certificates, etc. For example, a node... Upon receiving the request, its legitimacy is first verified (e.g., verifying the new node's identity and compliance with network access requirements). Once the verification is successful, a request is generated. Message and corresponding signature , in the following form.

[0089]

[0090]

[0091] 'a' is the identity of the node that processed the request; 'b' is the identity of the new node; 't' is the request processing timestamp. For the current configuration table version, ensure processing is based on the latest set of rules for the preceding nodes; yes The message summary Based on nodes Other consensus nodes Symmetric quantum key The generated hash value.

[0092] Other consensus nodes received Then, it is written to the log, and the source and signature of the request are verified. If valid, the message is broadcast. In this way, all nodes will... Recording to local logs ensures process traceability and provides a basis for subsequent consensus verification; through nodes Public key and symmetric quantum key verification The legitimacy of the message is confirmed, indicating that the message has not been tampered with and originated from the node. Meanwhile, each node will review new nodes again based on its own rules. The join request (not solely dependent on node a's judgment) avoids misjudgment or malicious approval by a single node. If approved, other consensus nodes will generate a join request in the same format. Messages are signed and broadcast to broaden the consensus scope. When any node exists in the log... ( (Excluding new nodes) A ​​consensus message is then broadcast again, reaching a consensus. Then the new node is recognized. Finally, the new node. Information (such as identity, hash points on the hash ring) is written ( (For the updated version), all nodes on the network synchronously update the configuration table to ensure that subsequent consensus processes (such as master node determination and message verification) are based on the latest node set, maintain network consistency, and the update process is consistent with the consensus phase. This means that the addition of new nodes also needs to go through a complete distributed confirmation process to avoid the configuration table being unilaterally tampered with.

[0093] In some embodiments, a consensus node receives a withdrawal request from another consensus node, encrypts the withdrawal request using a symmetric quantum key shared with the other consensus nodes to obtain a signature, generates a withdrawal proposal message based on the signature and the withdrawal request, and broadcasts it; it then obtains response messages from other consensus nodes to the withdrawal proposal message, and determines whether to agree to the withdrawal of other consensus nodes based on the number of response messages obtained.

[0094] Specifically, the exit is initiated by node b itself, without requiring application to any specific node, reflecting its decentralized nature. At this point, node... When requesting to exit, an exit message and its corresponding signature are generated and broadcast. The message and signature can be in the following form.

[0095]

[0096]

[0097] Other consensus nodes received Then, it is written to the log, the correctness of the node that issued the exit request is verified, and the validity of the signature is confirmed. Finally, the exit request is broadcast (the message format is the same as the node's). (Consistent), other consensus nodes are present in the logs. Consistent nodes If an exit message is requested, the configuration table will be updated. .

[0098] in, The identity information of the exiting node, such as node identifier, public key, etc.; The timestamp for the exit request is used to prevent replay attacks and record timing. Use the current configuration table version to ensure that exit is processed based on the latest node set rules; yes Message summary; Based on consensus nodes Other consensus nodes Symmetric quantum key The hash value generated by the QKD device is used to prove that the message did indeed originate from the node. It also possesses quantum-resistant security.

[0099] In some embodiments, if node No consensus node received for a long time Messages or failures received from other consensus nodes If the consensus node goes offline, it will unicast the verification message. Whether to go offline. If offline is confirmed, a fault message and its corresponding signature will be generated and broadcast. The message and signature can be in the following form.

[0100]

[0101]

[0102] Other consensus nodes received Then, it is written to the log, verified, and the message is broadcast (message format and node). (consistent), if other nodes exist in the logs A consistent fault node The offline message updates the configuration table. If the faulty node is the current master node, then in the configuration table... After the update is complete, a new master node will be generated automatically via master node carousel.

[0103] In the above steps, the problems of high communication overhead and low decentralization caused by dynamic node changes and view (master node) carousel are solved by maintaining a global configuration table and using an automatic master node carousel. The quantum resistance problem of the consensus mechanism is solved by using information-theoretically secure keys provided by the QKD network and PQC digital signature technology. Furthermore, this application proposes a quantum digital signature using information-theoretically secure keys provided by the QKD network to address the problem of high symmetric quantum key consumption during digital signature processing. As shown in Table 1, this application's scheme has certain advantages over existing schemes in terms of view changes, dynamic node changes, block efficiency, and digital signature overhead. Communication between nodes uses information-theoretically secure quantum digital signatures, ensuring information-theoretically secure capabilities within the node network.

[0104] Table 1

[0105]

[0106] Thus, by using the hash value of the parent block of the current block on the blockchain, the master node of the current block is determined from the consensus node set. The current block is the latest block on the blockchain. Simultaneously, after a candidate block is added to the chain, the hash value of the current block becomes the "parent block hash" of the candidate block. The same rules are used to determine the new master node, ensuring that all nodes have an equal opportunity to become master nodes, preventing the master node position from being monopolized by a few nodes, and maintaining the fairness and decentralization of the consensus process. Each consensus node in the block obtains a quantum key from its corresponding QKD device and generates broadcast information based on the quantum key. It also verifies the sending nodes of other broadcast messages and the signatures of other broadcast messages based on the quantum key, solving the quantum security problem of digital signatures in message transmission and preventing signature forgery or tampering under quantum computing attacks. Through independent computation and broadcast responses by multiple nodes, distributed verification of proposals is achieved, ensuring that the proposal content conforms to the consensus rules and guaranteeing the fault tolerance of the consensus. In summary, the method proposed in this application achieves quantum-resistant security, high decentralization, and dynamic fault tolerance by combining dynamic replacement of master nodes, quantum-secure verification based on quantum keys, and distributed consensus through broadcast messages.

[0107] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A dynamic quantum Byzantine fault-tolerant consensus method for blockchain, characterized in that, The method is executed by consensus nodes in a consensus node set, wherein the consensus node set is a set of nodes in a blockchain, and the consensus node is one of several nodes in the consensus node set used to perform BFT consensus. Each of the consensus nodes is connected to a QKD device to obtain a symmetric quantum key. The method includes: Based on the hash value of the parent block of the current block on the blockchain, the master node of the current block is determined from the consensus node set, and the current block is the latest block on the blockchain; If the consensus node itself is not the master node of the current block, it receives the proposal message of the candidate block broadcast by the master node of the current block, and verifies the proposal message according to the symmetric quantum key; If the proposal message is verified, a response message is generated based on the symmetric quantum key and broadcast to other consensus nodes, so that the master node of the current block receives the broadcast response message, writes the candidate block into the blockchain and connects it to the current block; Based on the hash value of the current block, the master node of the candidate block is determined from the consensus node set.

2. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 1, characterized in that, Before receiving the proposal message of the candidate block broadcast by the master node of the current block, and verifying the proposal message according to the symmetric quantum key, the method further includes: Each of the other consensus nodes shares an independent set of symmetric quantum keys.

3. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 2, characterized in that, The proposal message includes the signature of the master node of the current block for the proposal message and the message generated by the master node of the current block; The step of receiving the proposal message of the candidate block broadcast by the master node of the current block, and verifying the proposal message according to the symmetric quantum key, includes: The signature of the proposal message is decrypted using the symmetric quantum key shared with the master node of the current block; The identity of the master node of the current block is determined based on the decryption result.

4. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 3, characterized in that, The step of generating a response message to the proposal message based on the symmetric quantum key and broadcasting the response message to other consensus nodes includes: Decision information and execution result information are generated based on the message generated by the master node of the current block; Based on each set of independent symmetric quantum keys shared with the other consensus nodes, the decision information is encrypted and signed to obtain multiple signatures; The response message is generated based on the multiple signatures and the execution result information, and the response message is broadcast to the other consensus nodes so that the other consensus nodes can decrypt and verify the response message using the symmetric quantum key shared with this node.

5. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 2, characterized in that, The method further includes: Obtain requests generated by external nodes and / or internal nodes, and generate request decision information and request execution result information based on the requests; Based on each set of independent symmetric quantum keys shared with the other consensus nodes, the request decision information is encrypted and signed to obtain multiple signatures; Generate a corresponding request proposal message based on the multiple signatures and the request, and broadcast the request proposal message; Obtain the request response messages from the other consensus nodes to the request proposal message, and determine whether to agree to the request based on the number of request response messages obtained.

6. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 1, characterized in that, The step of determining the master node of the current block from the consensus node set based on the hash value of the parent block of the current block on the blockchain includes: Calculate the hash values ​​corresponding to the identity identifiers of this node and the other consensus nodes, and determine the positions of this node and the other consensus nodes on the hash ring based on the calculated hash values; Calculate the hash value of the parent block, and determine the position of the parent block mapped in the hash ring based on the hash value of the parent block; Based on the positions of the parent block, the current node, and the other consensus nodes on the hash ring, the master node of the current block is determined from the set of consensus nodes.

7. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 6, characterized in that, The step of determining the master node of the current block from the consensus node set based on the positions of the parent block, the current node, and the other consensus nodes on the hash ring includes: If there is a consensus node at the position on the hash ring where the hash value of the parent block is mapped, then the consensus node is taken as the master node of the current block. If the position of the hash value of the parent block mapped on the hash ring does not have any consensus node, then the first consensus node searched clockwise along the hash ring will be taken as the master node of the current block.

8. A dynamic quantum Byzantine fault-tolerant consensus method for blockchain, characterized in that, The method is executed by consensus nodes in a consensus node set, wherein the consensus node set is a set of nodes in a blockchain, and the consensus node is one of several nodes in the consensus node set used to perform BFT consensus. Each of the consensus nodes is connected to a QKD device to obtain a symmetric quantum key. The method includes: Based on the hash value of the parent block of the current block on the blockchain, the master node of the current block is determined from the consensus node set, and the current block is the latest block on the blockchain; If the consensus node itself is the master node of the current block, then a candidate block is generated based on the data to be uploaded to the chain, and a proposal message for the candidate block is generated based on the symmetric quantum key, and the proposal message is broadcast to other consensus nodes; The system receives and counts response messages broadcast by the other consensus nodes, writes the candidate block into the blockchain and connects it to the current block according to the response messages, and determines the master node on the candidate block from the consensus node set based on the hash value of the current block.

9. The dynamic quantum Byzantine fault-tolerant consensus method for blockchain according to claim 8, characterized in that, The step of receiving and counting response messages broadcast by the other consensus nodes, and writing the candidate block into the blockchain and connecting it to the current block according to the response messages, includes: When the number of received response messages exceeds a threshold, the candidate block is written into the blockchain and connected to the current block; Wherein, the threshold is , The number of consensus nodes in the set of consensus nodes. , This is for rounding down.

10. A server, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which enable the at least one processor to perform the dynamic quantum Byzantine fault-tolerant consensus method for blockchain as described in any one of claims 1 to 7, or the dynamic quantum Byzantine fault-tolerant consensus method for blockchain as described in claim 8 or 9.

Images