Consensus method and device of named data networking blockchain based on raft algorithm

Abstract

The application discloses a consensus method and device of a named data network blockchain based on a Raft algorithm, and the consensus method comprises the following steps: receiving a transaction created by a user and putting the transaction into a transaction pool; packing the transaction into a block and setting the block as a to-be-processed state, and putting the block in the to-be-processed state into a block pool; broadcasting a log replication message through a network layer; receiving a log acquisition message sent by a follower node through the network layer, and returning block data of the block in the to-be-processed state to the follower node; when a log replication confirmation message sent by the follower node is received, and it is determined that more than a preset number of follower nodes in the blockchain successfully replicate the block in the to-be-processed state, setting the block in the to-be-processed state as a submitted state, and putting the block in the submitted state into the block pool; and broadcasting a first heartbeat message through the network layer. In the embodiment of the application, the input of the interactive device can be combined for coding, so that the coding speed and the interactive fluency are improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a consensus method and apparatus for a named data network blockchain based on the Raft algorithm. Background Technology

[0002] Blockchain technology has been around for over a decade. Due to its decentralized, immutable, and traceable characteristics, it has shown immense application potential not only in the financial industry but also in fields such as the Internet of Things and public services. As blockchain applications become more widespread, the demands on network communication are also increasing. Blockchain systems need to transmit large amounts of data synchronously across the network, but the traditional TCP / IP network architecture, with its point-to-point communication mechanism, inevitably leads to a large amount of redundant traffic, increasing network overhead and propagation latency.

[0003] In future network architecture research, Named Data Networking (NDN) features support for content distribution, multicast, and network caching. NDN's multicast and intranet caching mechanisms can accelerate blockchain synchronization and avoid network congestion. NDN's content distribution approach aligns closely with blockchain's design philosophy of "hiding the information of transacting parties while making the transaction content public." Therefore, integrating NDN networks with blockchain technology will become an important direction for the future development of blockchain technology.

[0004] In the NDN network, NDN uses a pull method for data distribution, while blockchain technology uses an active push communication method. Existing consensus algorithms cannot be directly applied to the consensus layer of the NDN network blockchain system, and the incompatibility between the NDN data distribution mechanism and the blockchain data communication mechanism still needs to be resolved. Summary of the Invention

[0005] This application provides a consensus method and apparatus for a named data network blockchain based on the Raft algorithm, which can solve the problem of incompatibility between the data distribution mechanism of NDN and the data communication mechanism of blockchain.

[0006] In a first aspect, embodiments of this application provide a consensus method for a named data network blockchain based on the Raft algorithm. The blockchain includes a leader node and several follower nodes. The leader node periodically sends a first heartbeat message to the follower nodes, and the follower nodes periodically send a second heartbeat message to the leader node. The leader node notifies the follower nodes to replicate blocks through a log replication message, and the follower nodes notify the leader node that the replication of blocks is complete through a log replication confirmation message. The first heartbeat message, the second heartbeat message, the log replication message, and the log replication confirmation message are defined using interest package names. The consensus method includes: Receive transactions created by users and place them into the transaction pool; The transactions are packaged into blocks and set to a pending state. The blocks in the pending state are then placed into the block pool. The log replication message is broadcast through the network layer to notify the follower nodes to replicate the block in the pending state; Receive the log acquisition message sent by the follower node through the network layer, and return the block data of the block in the pending state to the follower node; When the log replication confirmation message sent by the follower node is received, and it is determined that more than a preset number of the follower nodes in the blockchain have successfully replicated the block in the pending state, the block in the pending state is set to the committed state, and the block in the committed state is put into the block pool. The first heartbeat message is broadcast through the network layer to notify the follower nodes to synchronize the log number so that the block in the pending state can be set to the committed state.

[0007] In some embodiments, the first heartbeat message and the log replication message have the same interest packet format. The interest packet name definition of the first heartbeat message includes a first registered routing string and a first committed state log number. The interest packet name definition of the log replication message includes the first registered routing string, the first committed state log number, and a log replication field. The first registered routing string is used to indicate that the current interest packet is a broadcast-sent heartbeat type interest packet based on the Raft algorithm. The first committed state log number is used to indicate the log number corresponding to the committed state block in the leader node. The log replication field is used to indicate the block data pulled by the follower node from the leader node.

[0008] In some embodiments, the log replication field includes <prelognumber>fields and <prelogterm>Field, the <prelognumber>The value of the field is the previous log number of the leader node. <prelogterm>The value of the field is the term number of the previous log of the leader node; In the log replication message, the <prelognumber>Fields and the <prelogterm>The field is defined as the corresponding value; in the first heartbeat message, the <prelognumber>Fields and the <prelogterm>The field is not defined.

[0009] In some embodiments, receiving user-created transactions and placing them into a transaction pool includes: When a user creates a transaction on the follower node, the transaction data sent by the follower node is received through the network layer; The transaction data of the transaction is placed into the transaction pool.

[0010] Secondly, this application provides a consensus method for a named data network blockchain based on the Raft algorithm. The blockchain includes a leader node and several follower nodes. The leader node periodically sends a first heartbeat message to the follower nodes, and the follower nodes periodically send a second heartbeat message to the leader node. The leader node notifies the follower nodes to replicate blocks through a log replication message, and the follower nodes notify the leader node that the replication of blocks is complete through a log replication confirmation message. The first heartbeat message, the second heartbeat message, the log replication message, and the log replication confirmation message are defined by interest package names. The consensus method includes: The leader node broadcasts a log replication message, which is used to notify the follower node to replicate blocks in the pending state. Send a log retrieval message to the leader node, and receive the block data of the block to be processed returned by the leader node based on the log retrieval message; Copy the block data, set the copied block to a pending state and put it into the block pool; Send the log replication confirmation message to the leader node; The leader node broadcasts the first heartbeat message, which is used to notify the follower node to synchronize the log number so as to set the block in the pending state to the committed state.

[0011] In some embodiments, the interest packet name definition of the log replication message includes a log replication field, which includes... <prelognumber>fields and <prelogterm>Field, the <prelognumber>The value of the field is the previous log number of the leader node. <prelogterm>The value of the field is the term number of the previous log of the leader node; Sending a log retrieval message to the leader node includes: Determine if the log number is stored locally. <prelognumber>The value of the field and the corresponding term number are as described <prelogterm>The log corresponding to the field's value; If so, send a log retrieval message to the leader node, the log retrieval message including an indication of the log number. <number>The field is used to request a replication log number greater than the specified value from the leader node. <prelognumber>All logs for the field's value; If not, from the above <prelognumber>The field value is used to search backwards for the last log number among the follower nodes, and the log content of that last log number is overwritten backwards until all logs are overwritten. <prelognumber>The value of the field corresponds to the log number of the log, and then a log retrieval message is sent to the leader node. The log retrieval message includes information indicating the log number. <number>The field requests a replication log number greater than the specified value from the leader node. <prelognumber>All logs for the field's value.

[0012] In some embodiments, the second heartbeat message is sent to the leader node so that the leader node updates and maintains the list of surviving follower nodes in the blockchain based on the second heartbeat message; The second heartbeat message and the log replication confirmation message have the same interest packet format. The second heartbeat message includes a second registration route string, a second committed state log number, and a last log information field. The second registration route string is used to indicate that the current interest packet is a numeric type interest packet based on the Raft algorithm for the specified leader node. The second committed state log number is used to indicate the log number corresponding to the committed block in the follower node. The last log information field is used to indicate the log number and corresponding term number of the last log in the follower node.

[0013] In some embodiments, the follower node includes an election timer; the consensus method further includes: If the election timer does not receive the first heartbeat message from the leader node within a preset time period, it triggers the current follower node to increase its own term number and change its role to that of a candidate. A new election process is initiated and voting request messages are sent to other nodes in the blockchain, the voting request messages being defined by interest package names.

[0014] In some embodiments, when a user creates a transaction on the follower node, the consensus method further includes: Transaction data is sent to the leader node through the network layer.

[0015] In some embodiments, sending transaction data to the leader node through the network layer includes: When the amount of transaction data is less than a preset threshold, the transaction data is sent as a parameter of the interest package to the leader node; When the amount of transaction data exceeds the preset threshold, the NodeID of the follower node and the hash value of the transaction data are sent to the leader node as parameters of the interest packet, and a dictionary of the correspondence between the hash value and the transaction data is constructed.

[0016] Thirdly, this application provides a consensus method for a named data network blockchain based on the Raft algorithm. The blockchain includes a leader node and several follower nodes. The leader node periodically sends a first heartbeat message to the follower nodes, and the follower nodes periodically send a second heartbeat message to the leader node. The first heartbeat message and the second heartbeat message are defined by interest packet names. The follower nodes include an election timer. The consensus method includes: If the election timer does not receive the first heartbeat message from the leader node within a preset time period, the follower node increments its own term number and transforms itself into a candidate node. The candidate node initiates a new election process and sends a voting request message to other nodes in the blockchain, the voting request message being defined by an interest package name.

[0017] In some embodiments, the candidate node initiates a new election process and sends voting request messages to other nodes in the blockchain, including: The candidate node votes for itself and sends a voting request message to other nodes in the blockchain. The voting request message carries the candidate node's current term number, the log number of the last log entry, and the corresponding term number. Upon receiving the voting request message, the follower node sends a vote to the candidate node if the first and second conditions are met. The first condition is that the current term number of the follower node is less than the current term number of the candidate node, and the second condition is that the log number and corresponding term number of the last log of the follower node are less than the log number and corresponding term number of the last log of the candidate node.

[0018] In some embodiments, each node in the blockchain is initially a follower node, and the timeout period set for the election timer in each follower node is a random duration.

[0019] Fourthly, embodiments of this application provide a consensus device for a named data network blockchain based on the Raft algorithm, including at least one processor and a memory for communicatively connecting with the at least one processor; the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to execute the consensus method as described in the first aspect.

[0020] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the consensus method as described in the first aspect.

[0021] The consensus method and apparatus for named data network blockchain based on the Raft algorithm provided in this application embodiment have at least the following beneficial effects: Based on the Raft algorithm, nodes in the blockchain are assigned leader and follower roles. To overcome the problem that NDN networks cannot directly communicate using a peer-to-peer mechanism, this application embodiment extends the Raft algorithm in NDN networks by periodically sending heartbeat messages named based on interest packets to the leader and follower nodes. The first heartbeat message periodically sent by the leader node to the follower node is used to inform the follower node of the leader node's survival status, and the second heartbeat message periodically sent by the follower node to the leader node is used to report the follower node's survival status. Furthermore, when a transaction occurs in the blockchain and block synchronization is required, the leader node notifies the follower node to perform block replication via log replication messages. In this system, after receiving a log replication message, followers pull the block data to be replicated from the leader node. After replicating the block data, they send a log replication confirmation message to the leader node. The leader node receives the confirmation message and, upon confirming that more than a certain number of follower nodes have completed the replication of the block data, changes the block data to a committed state and synchronizes the block state with the follower nodes via a first heartbeat message, achieving block consensus among nodes. Furthermore, the first heartbeat message can also be used to trigger a new round of election processes when the election timer times out, ensuring that a leader node can be generated in a timely manner and guaranteeing the stable operation of the blockchain. Therefore, the consensus method of this application solves the problem of integrating the Raft algorithm with the NDN network architecture in the blockchain consensus layer, providing a complete consensus solution for NDN networks based on the Raft algorithm. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of a blockchain framework provided in one embodiment of the present invention; Figure 2 A flowchart illustrating a consensus method for a named data network blockchain based on the Raft algorithm, provided as an embodiment of this application; Figure 3 yes Figure 2 The flowchart of the specific method for step S101 in the process; Figure 4 A flowchart illustrating a consensus method for a named data network blockchain based on the Raft algorithm, provided as another embodiment of this application; Figure 5 yes Figure 4 The flowchart of the specific method for step S302 in the process; Figure 6 A flowchart illustrating a consensus method for a named data network blockchain based on the Raft algorithm, provided as another embodiment of this application; Figure 7 A flowchart illustrating a consensus method for a named data network blockchain based on the Raft algorithm, provided as another embodiment of this application; Figure 8 A flowchart illustrating a consensus method for a named data network blockchain based on the Raft algorithm, provided as another embodiment of this application; Figure 9 A flowchart illustrating a consensus method for a named data network blockchain based on the Raft algorithm, provided as another embodiment of this application; Figure 10 yes Figure 9 The flowchart of the specific method for step S802 in the process; Figure 11 A flowchart of a log replication method provided as a specific example of the present invention; Figure 12 This is a schematic diagram of the structure of a consensus device for a named data network blockchain based on the Raft algorithm, provided in one embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] It should be noted that in the description of the embodiments of the present invention, the terms "first," "second," etc., in the specification, claims, and the accompanying drawings are used to distinguish similar objects and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the sequential relationship of the indicated technical features. "At least one" means one or more, and "more" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist, for example, A and / or B, which can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

[0025] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0026] This application provides a consensus method and apparatus for a named data network blockchain based on the Raft algorithm. Based on the Raft algorithm, nodes in the blockchain are assigned leader and follower roles. To overcome the problem that NDN networks cannot communicate directly via a peer-to-peer mechanism, this application extends the Raft algorithm in NDN networks by periodically sending heartbeat messages named based on interest packets to the leader and follower nodes. The first heartbeat message periodically sent by the leader node to the follower node is used to inform the follower node of the leader node's liveness status, and the second heartbeat message periodically sent by the follower node to the leader node is used to report the follower node's liveness status. Furthermore, when a transaction occurs in the blockchain and block synchronization is required, the leader node notifies the follower node to perform block replication via a log replication message. Upon receiving a log replication message, the system pulls the block data to be replicated from the leader node. After replicating the block data, it sends a log replication confirmation message to the leader node. The leader node receives the confirmation message and, upon confirming that more than a certain number of follower nodes have completed the replication of the block data, changes the block data to a committed state. It then synchronizes the block state with the follower nodes via a first heartbeat message, achieving block consensus among nodes. Furthermore, the first heartbeat message can also be used to trigger a new round of elections when the election timer expires, ensuring that a leader node is generated in a timely manner and guaranteeing the stable operation of the blockchain. Therefore, the consensus method of this application solves the problem of integrating the Raft algorithm with the NDN network architecture in the blockchain consensus layer, providing a complete consensus solution for NDN networks based on the Raft algorithm.

[0027] The embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0028] Reference Figure 1 , Figure 1 This is a schematic diagram of a blockchain framework provided in one embodiment of the present invention.

[0029] In some embodiments, blockchain 100 includes a leader node 200 and several follower nodes 300. The leader node 200 periodically sends a first heartbeat message to the follower nodes 300, and the follower nodes 300 periodically send a second heartbeat message to the leader node 200. The leader node 200 notifies the follower nodes 300 to replicate blocks via log replication messages, and the follower nodes 300 notify the leader node 200 that the block replication is complete via log replication confirmation messages. For example, when a transaction occurs in blockchain 100 and block synchronization is required, the leader node 200 notifies the follower nodes 300 to replicate blocks via log replication messages. After receiving the log replication message, the follower nodes 300 pull the block data to be replicated from the leader node 200, and after replicating the block data, send a log replication confirmation message to the leader node 200 so that the leader node 200 can confirm the number of block data replicated by the follower nodes 300, thereby achieving block consensus among nodes.

[0030] It should be noted that in the blockchain system, the initial state of each server node is a follower. The nodes in the cluster will switch between the three roles of leader, candidate, and follower as time and conditions change. There can only be one leader at any time. Furthermore, the first heartbeat message, the second heartbeat message, the log replication message, and the log replication confirmation message are all defined by interest packet names to facilitate communication between the leader node 200 and the follower node 300.

[0031] It is understandable that the first and second heartbeat messages are timed messages, while the log replication message and log replication confirmation message are event-driven messages.

[0032] It will be understood by those skilled in the art that Figure 1 The framework shown does not constitute a limitation on the embodiments of the present invention. It may include more or fewer components than shown, or combine certain components, or have different component arrangements. The consensus method of the named data network blockchain based on the Raft algorithm in this embodiment will be described in detail below.

[0033] Reference Figure 2 , Figure 2 The flowchart of the consensus method for a named data network blockchain based on the Raft algorithm provided in the embodiments of this application includes, but is not limited to, the following steps S101 to S106.

[0034] Step S101: Receive transactions created by users and put them into the transaction pool; In some embodiments, transactions created by users are received and placed into a transaction pool. Users can create transactions and place them into the transaction pool through a Web API (Application Programming Interface). The specific method of receiving transactions is not specifically limited in this embodiment.

[0035] Step S102: Package the transactions into blocks and set them to a pending state, and put the pending blocks into the block pool. In some embodiments, transactions are packaged into blocks and set to a pending state. Only the leader node can package transactions into blocks and put the pending blocks into the block pool to facilitate subsequent processing of blocks in the block pool.

[0036] Understandably, the block pool contains a list of blocks to be processed, which is used to store the packaged blocks.

[0037] Step S103: Broadcast log replication messages through the network layer to notify follower nodes to replicate blocks in the pending state; In some embodiments, log replication messages are broadcast through the network layer, thereby notifying follower nodes to replicate blocks in the pending state, so as to achieve communication and consensus between leader nodes and follower nodes.

[0038] Step S104: Receive the log acquisition message sent by the follower node through the network layer, and return the block data of the block in the pending state to the follower node; In some embodiments, after broadcasting the log replication message to the follower nodes, the follower nodes respond according to the log replication message, notify other nodes to replicate the block, receive the log retrieval message sent by the follower nodes through the network layer, and return the block data of the block in the pending state to the follower nodes, so as to facilitate the subsequent replication of the block by the follower nodes.

[0039] It should be noted that in the process of receiving log acquisition messages from follower nodes and returning block data to follower nodes, multiple iterations may be required to achieve the log replication process. This embodiment does not impose a specific limit on the number of iterations.

[0040] Step S105: When a log replication confirmation message is received from a follower node, and it is determined that more than a preset number of follower nodes in the blockchain have successfully replicated the block in the pending state, the block in the pending state is set to the committed state, and the committed block is put into the block pool. In some embodiments, when a log replication confirmation message is received from a follower node, and it is determined that more than a preset number of follower nodes in the blockchain have successfully replicated the block in the pending state, the block in the pending state can be directly set to the committed state, and the committed block can be put into the block pool to complete the replication of the block by the follower node.

[0041] Step S106: Broadcast the first heartbeat message through the network layer to notify follower nodes to set the blocks in the pending state to the committed state.

[0042] In some embodiments, the first heartbeat information is broadcast through the network layer, thereby notifying follower nodes to synchronize log numbers to set the corresponding pending blocks to the committed state, completing the consensus process of the entire blockchain and improving coding speed and interaction smoothness.

[0043] In some embodiments, the first heartbeat message and the log replication message have the same interest packet format. The interest packet name definition of the first heartbeat message includes a first registered route string and a first committed state log number. The interest packet name definition of the log replication message includes a first registered route string, a first committed state log number, and a log replication field. The first registered route string is used to indicate that the current interest packet is a heartbeat type interest packet based on the Raft algorithm that is broadcast. The first committed state log number is used to indicate the log number corresponding to the committed state block in the leader node. The log replication field is used to indicate the block data that the follower node pulls from the leader node.

[0044] It should be noted that when a new block in the blockchain needs to be synchronized to other nodes, the leader node needs to broadcast a log replication message to the other follower nodes in the cluster. The leader node's heartbeat message and log replication message have the same format, except that the leader node's heartbeat message does not need to carry log content information, but only needs to carry the leader node's committed log number.

[0045] In some embodiments, the log replication field includes <prelognumber>fields and <prelogterm>Fields, <prelognumber>The value of this field is the log number of the previous node of the leader node. <prelogterm>The value of this field is the term number of the previous log entry for the leader node; in log replication messages, <prelognumber>fields and <prelogterm>The field is defined as the corresponding value; in the first heartbeat message, <prelognumber>fields and <prelogterm>This field is not defined and is only used by the leader node to send information about the leader node's survival status to the follower nodes.

[0046] It should be noted that the name of the interest packet in the first heartbeat message can be defined by the user as needed. Multiple fields can be defined according to actual functional requirements for communication between nodes. For example, the interest packet name can be defined as... <broadcastprefix> / <rafttag> / HEARTBEAT / <subprefix> / <nodeid> / <nonce> / <nodecount> / <term> / <commitlognumber> / <prelognumber> / <prelogterm>,in, <broadcastprefix>For broadcast prefix, <rafttag>HEARTBEAT is a prefix for the consensus algorithm name and a type keyword for the interest packet. It can be used in both the log replication messages of the leader node and the first heartbeat message sent by the leader node. <subprefix>This is the prefix for the group name of the current node. <nodeid>The name of the current node. <nonce>The random number is used to combat replay attacks. <nodecount>This represents the number of surviving nodes in the current cluster. <term>For the current term number, <commitlognumber>This is the first committed status log number. <prelognumber>Number the previous log entry. <prelogterm>The term number of the previous log entry. <prelognumber>and <prelogterm>The log replication field is used to instruct follower nodes to pull block data from the leader node. The specific field name can be changed as needed, and this implementation does not impose any specific restrictions.

[0047] Reference Figure 3 , Figure 3 Yes Figure 2 Further explanation of step S101: Step S101 includes, but is not limited to, steps S201 to S202.

[0048] Step S201: When a user creates a transaction on a follower node, the user receives transaction data sent by the follower node through the network layer. Step S202: Place the transaction data into the transaction pool.

[0049] In steps S201 to S202 of some embodiments, when a user creates a transaction on a follower node, the follower node will transmit the transaction data through the network layer and then put the transaction data into the transaction pool, thereby enabling the transmission of information between the leader node and the follower node.

[0050] Reference Figure 4 , Figure 4 The consensus method for a named data network blockchain based on the Raft algorithm provided in another embodiment of this application includes, but is not limited to, the following steps S301 to S305.

[0051] Step S301: Receive the log replication message broadcast by the leader node; It should be noted that log replication messages are used to notify follower nodes to replicate blocks in the pending state.

[0052] Step S302: Send a log retrieval message to the leader node and receive the block data of the unprocessed blocks returned by the leader node based on the log retrieval message; Step S303: Copy the block data, set the copied block to a pending state and put it into the block pool; Step S304: Send a log replication confirmation message to the leader node; Step S305: Receive the first heartbeat message broadcast by the leader node.

[0053] It should be noted that the first heartbeat message is used to notify follower nodes to set the block in the pending state to the committed state.

[0054] In steps S301 to S305 of some embodiments, after receiving a user-created transaction and placing it into the transaction pool, the follower node receives a log replication message broadcast by the leader node, thereby enabling it to replicate blocks in the pending state. It then sends a log retrieval message to the leader node through the network layer and receives block data of the pending block corresponding to the specified log number returned by the leader node based on the log retrieval message. After replicating this block data, the replicated block is set to the pending state and placed into the block pool. The follower node then sends a log replication confirmation message to the leader node through the network layer and receives a first heartbeat message broadcast by the leader node. This allows the follower node to set the pending block to the committed state based on the first heartbeat message, enabling encoding based on the input from the interactive device, thereby improving encoding speed and interaction fluency.

[0055] Reference Figure 5 , Figure 5 Yes Figure 4 Further explanation of step S302: Step S302 includes, but is not limited to, steps S401 to S403.

[0056] Step S401: Determine whether a log with the specified number is stored locally. <prelognumber>The value of the field and the corresponding term number are <prelogterm>The log corresponding to the field's value; Step S402, if applicable, send a log retrieval message to the leader node to request a replication log number greater than [number missing]. <prelognumber>All logs for the field's value; It should be noted that the log retrieval message includes information indicating the log number. <number>Field.

[0057] In some embodiments, during the process of receiving block data of unprocessed blocks returned by the leader node, it is necessary to determine whether the log number is stored locally. <prelognumber>The value of the field and the corresponding term number are <prelogterm>The value of the field corresponds to the log file. If it is determined that a log number is stored locally... <prelognumber>The value of the field and the corresponding term number are <prelogterm>If the value of the field corresponds to a log, a log retrieval message is sent to the leader node to request the replication of the log number greater than [log number missing]. <prelognumber>All logs for the field's value, and overwrite these logs in the follower nodes with the log number. <prelognumber>After reading the logs, the log copying process will be complete.

[0058] Step S403, if not, from <prelognumber>The field value searches backwards for the last log number in the follower nodes, and then overwrites the log content of that last log number with the current log number, until all logs are overwritten. <prelognumber>The field value corresponds to the log number of the log file, and then a log retrieval message is sent to the leader node, requesting the replication of logs with log numbers greater than or equal to the specified value. <prelognumber>All logs for the field's value.

[0059] It should be noted that the log retrieval message includes information indicating the log number. <number>Field.

[0060] In some embodiments, if it is determined that the log number is not present locally... <prelognumber>The value of the field and the corresponding term number are <prelogterm>For the log corresponding to the field value, it is necessary to iterate backwards until the follower node has a corresponding log number and its term number. Once the last log number in the follower node is obtained, its content is overwritten backwards until the entire log is overwritten. <prelognumber>The value of this field corresponds to the log number of the log file. After overwriting the log content sequentially, a log retrieval message is sent to the leader node to retrieve all log content from PreLogNumber onwards, and this content is added to the log file with the specified number. <prelognumber>After reading the logs, the log copying process will be complete.

[0061] Reference Figure 6 , Figure 6 A consensus method for a named data network blockchain based on the Raft algorithm, provided in another embodiment of this application, includes, but is not limited to, the following step S501.

[0062] Step S501: Send a second heartbeat message to the leader node so that the leader node updates and maintains the list of surviving follower nodes in the blockchain based on the second heartbeat message.

[0063] It should be noted that the second heartbeat message and the log replication confirmation message have the same interest packet format. The interest packet name definition of the second heartbeat message includes the second registration route string, the second committed state log number, and the last log information field. The second registration route string is used to indicate that the current interest packet is a numeric type interest packet based on the Raft algorithm of the specified leader node. The second committed state log number is used to indicate the log number corresponding to the committed state block in the follower node. The last log information field is used to indicate the log number of the last log in the follower node and the corresponding term number.

[0064] In some implementations, follower nodes periodically send second heartbeat messages to the leader node, enabling the leader node to update and maintain the list of surviving follower nodes in the blockchain based on these messages, thus allowing the leader node to keep abreast of the survival status of each node in the cluster.

[0065] Understandably, the name of the interest packet in the second heartbeat message can be defined by the user according to their needs. Multiple fields can be defined based on actual functional requirements for communication between nodes. For example, the interest packet name can be defined as... <routableprefix> / <subprefix> / <rafttag> / <nodeid> / NUMBER / <fromnodeid> / <lastlognumber> / <lastlogterm> / <commitedlognumber> / <nonce>,in, <routableprefix>For routing prefix, <subprefix>This is the prefix for the group name of the current node. <rafttag>This is a prefix for the consensus algorithm name. <nodeid>Here, NUMBER is the name of the leader node, and NUMBER is the type keyword for this interest packet. It can be used in log replication acknowledgment messages sent by follower nodes to the leader node, or in second heartbeat messages sent by follower nodes. <fromnodeid>The name of the follower node, i.e., the name of the current node. <lastlognumber>The last log number for the follower. <lastlogterm>Number the last term of the follower. <commitedlognumber>This is the log number of the committed state in the follower node, i.e., the second committed state log number. <nonce>The random number is used to combat replay attacks. <routableprefix> / <subprefix> / <rafttag> / <nodeid> / NUMBER / is the registered route string.

[0066] Reference Figure 7 , Figure 7 A consensus method for a named data network blockchain based on the Raft algorithm, provided in another embodiment of this application, includes, but is not limited to, the following steps S601 to S602.

[0067] It should be noted that follower nodes include election timers.

[0068] Step S601: When the election timer does not receive the first heartbeat message from the leader node within the preset time, it triggers the current follower node to increase its own term number and change its role to that of a candidate. Step S602: Start a new election process and send a vote request message to other nodes in the blockchain.

[0069] It should be noted that the voting request message is defined by the interest package name.

[0070] In steps S601 to S602 of some embodiments, the follower node includes an election timer. If the follower node does not receive a first heartbeat message from the leader node within a preset duration of the election timer, it is considered that there is no leader node in the current system, and a new election process can begin. This triggers the current follower node to increment its own term number, transforming its role into a candidate, and simultaneously sending a voting request message to other nodes in the cluster, thereby initiating the node voting process. This ensures that a leader node can be generated in a timely manner in the blockchain, guaranteeing the stable operation of the blockchain.

[0071] It should be noted that the preset duration in the election timer can be set according to the network conditions and server performance requirements, for example, 0.1 seconds, 0.3 seconds or 1 second, etc. The voting request message sent by the follower node is sent in the form of a request vote broadcast interest packet, and this embodiment does not impose specific restrictions.

[0072] Reference Figure 8 , Figure 8 A consensus method for a named data network blockchain based on the Raft algorithm, provided in another embodiment of this application, includes, but is not limited to, the following step S701.

[0073] Step S701: When a user creates a transaction on a follower node, the transaction data is sent to the leader node through the network layer.

[0074] In some embodiments, when a user creates a transaction on a follower node, the follower node needs to send the transaction to the leader node after receiving the transaction created by the user through the Web API. That is, the transaction data is sent to the leader node through the network layer, and then the leader node packages the transaction into a block. Therefore, it is necessary to provide the function of the follower node sending transactions to the leader node.

[0075] In some embodiments, when the amount of transaction data is less than a preset threshold, the transaction data is sent to the leader node as a parameter of the interest packet; when the amount of transaction data is greater than the preset threshold, the NodeID of the follower node and the hash value of the transaction data are sent to the leader node as parameters of the interest packet, and a dictionary of the correspondence between the hash value and the transaction data is constructed, thereby enabling the processing of transaction data with large or small amounts of data.

[0076] It's important to note that follower nodes send transaction data to the leader node via the network layer in the form of interest packets. The interest packet name does not contain the transaction data. There are two processing methods for transaction data transmission. Typically, when the amount of blockchain transaction data is small, the simplest method is to send the transaction data directly to the leader node as a parameter of the interest packet. If the transaction content data is large, to maintain the design principles of NDN, the follower node's NodeID and the transaction data's hash value can be sent to the leader node as parameters. Furthermore, the follower node needs to maintain a dictionary mapping transaction hashes to transaction content. This allows the leader node to subsequently send an interest packet containing the transaction content corresponding to the hash value to the follower node corresponding to the NodeID, thereby retrieving the transaction content data.

[0077] It is understood that the preset threshold in this embodiment can be set by the user as needed, and this embodiment does not impose any specific restrictions.

[0078] Reference Figure 9 , Figure 9 The consensus method for a named data network blockchain based on the Raft algorithm provided in another embodiment of this application includes, but is not limited to, the following steps S801 to S802.

[0079] Step S801: When the election timer does not receive the first heartbeat message from the leader node within the preset time, the follower node increments its own term number and transforms itself into a candidate node. In step S802, the candidate node begins a new election process and sends a voting request message to other nodes in the blockchain.

[0080] It should be noted that the voting request message is defined by the interest package name.

[0081] In steps S801 to S802 of some embodiments, if the election timer does not receive the first heartbeat message from the leader node within a preset time period, it is considered that there is no leader in the current system. Follower nodes need to increase their own term number and transform themselves into candidate nodes. Then, the candidate nodes start a new election process and send voting request messages to other nodes in the blockchain. The voting request messages are defined by interest package names, thereby realizing the voting election process in the system, ensuring that a leader node can be generated in the blockchain in a timely manner, and ensuring the stable operation of the blockchain.

[0082] Understandably, the interest packet name definition for the voting request message sent by the candidate node is as follows: <broadcastprefix> / <rafttag> / VOTE / <subprefix> / <nodeid> / <term> / <lastlognumber> / <lastlogterm>,in, <broadcastprefix>For broadcast prefix, <rafttag>The VOTE prefix is ​​used to indicate the consensus algorithm name, and it is the type keyword for the interest packet, i.e., the request for a vote. <subprefix>This is the prefix for the group name of the current node. <nodeid>The name of the current node. <term>For the current term number, <lastlognumber>Number the last log entry. <lastlogterm>Number the last term. <broadcastprefix> / <rafttag> / VOTE is the registered route string.

[0083] Reference Figure 10 , Figure 10 Yes Figure 9 Further explanation of step S802: Step S802 includes, but is not limited to, steps S901 to S902.

[0084] Step S901: The candidate node votes for itself and sends a voting request message to other nodes in the blockchain; It should be noted that the voting request message carries the candidate node's current term number, the log number of the last log entry, and the corresponding term number.

[0085] In step S902, after receiving the voting request message, the follower node sends a vote to the candidate node if the first and second conditions are met.

[0086] It should be noted that the first condition is that the current term number of the follower node is less than the current term number of the candidate node, and the second condition is that the log number and corresponding term number of the last log of the follower node are less than the log number and corresponding term number of the last log of the candidate node.

[0087] In some embodiments, when a candidate node initiates a new election process, the candidate node votes for itself and sends voting request messages to other nodes in the blockchain. When follower nodes in the cluster receive the candidate node's voting request message, they vote according to a first-come, first-served principle, meaning each node will vote for at most one term number. <term>Send a vote. The current node needs to determine the term number of the candidate node. <term>In addition to determining whether it is larger than its own, the current node also needs to determine the last term number of the candidate node. <lastlogterm>and the last log number <lastlognumber>The current node will send a vote to the candidate node only if both conditions are met, and the vote must be greater than or equal to its last term number and last log number.

[0088] Understandably, the interest packet name for follower nodes sending votes to candidate nodes is defined as follows: <routableprefix> / <subprefix> / <rafttag> / <nodeid> / VOTED_FOR / <votefromnodeid> / <term>,in, <routableprefix>For routing prefix, <subprefix>This is the prefix for the group name of the current node. <rafttag>This is a prefix for the consensus algorithm name. <nodeid>Here, VOTE_FOR is the name of the candidate node, and VOTE_FOR is the type keyword for this interest packet, i.e., the type of vote sent. <votefromnodeid>This refers to the name of the node from which the votes originated, i.e., the name of the current node. <term>This represents the term number of the candidate node. <routableprefix> / <subprefix> / <rafttag> / <nodeid> / VOTED_FOR is the registered route string.

[0089] In some embodiments, the initial state of each node in the blockchain is a follower node, and the timeout duration of the election timer in each follower node is set to a random duration, thereby broadening the application scenarios of the consensus method.

[0090] The consensus method of the named data network blockchain based on the Raft algorithm in this application is illustrated below through three examples.

[0091] Example 1: refer to Figure 11 , Figure 11 A flowchart of a log replication method provided as a specific example of the present invention; After a follower node receives the first heartbeat message from the leader node, it needs to reset its election timer. <commitlognumber>Set copied but uncommitted logs to a committed state. If it's a log copy message, it also needs to be set to a committed state. <prelognumber> , <prelogterm>Log replication is performed, and the log replication process is as follows: Figure 11 As shown, the steps are as follows: When a follower node receives a log replication broadcast message from the leader node, it needs to check if it has a log number of that type. <prelognumber>and term number <prelogterm>The corresponding logs; If so, the follower node sends a log retrieval message to the leader node, requesting... <prelognumber>+1 and all subsequent logs, and overwrite these logs to the follower node's log number. <prelognumber>After reading the logs, the log copying process will be complete.

[0092] If not, iterative searching is required. The initial iteration value is set to i=1. Follower nodes send log retrieval messages to the leader node, retrieving log numbers as... <prelognumber>-i specifies the log and its term number, and determines whether the log number and term number exist in the follower node; If it does not exist, increment the iteration value i by 1 and continue sending log retrieval messages to the leader node, searching in the direction of smaller log numbers, until a follower node has the corresponding log number and its term number (or <prelognumber>If the -i value is 0, the iteration will exit; Then the log content will be overwritten sequentially to the numbered... <prelognumber>After logging with -i, send a log retrieval message to the leader to retrieve all log content from PreLogNumber onwards, and add it to the log number. <prelognumber>After reading the logs, the log copying process will be complete.

[0093] Example 2: Example 2 shows the specific steps and procedures for consensus synchronization by the leader node; In the blockchain system, each server node is initially in a follower state. After the blockchain service is started, the election timer of each node begins to count down. Since the election timeout interval is random, the node that times out first will initiate the leader election operation first. After the leader is successfully elected, different consensus operation processes are executed according to the different roles of the nodes. The blockchain consensus synchronization process will be introduced from the perspectives of leader and follower roles respectively.

[0094] The leader consensus synchronization process consists of the following steps: Step S1001: The user creates a transaction via the Web API and places it into the transaction pool.

[0095] Step S1002: For transactions created by users on follower nodes, the follower nodes transmit the transaction data to the consensus module through the network layer.

[0096] Step S1003: The consensus module puts transactions from follower nodes into the transaction pool.

[0097] Step S1004: The transaction node requests a transaction from the transaction pool.

[0098] Step S1005: The transaction pool returns the transaction to the transaction node.

[0099] Step S1006: The transaction node packages the transaction into a block and sets it to the pending state, and puts the pending block into the block pool.

[0100] Step S1007: The consensus module requests blocks in the pending state from the block pool.

[0101] Step S1008: The block pool returns the blocks in the pending state to the consensus module.

[0102] Step S1009: The consensus module broadcasts log replication messages through the network layer to notify follower nodes to replicate the blocks to be processed.

[0103] Step S1010: The log acquisition message sent by the follower node will be passed to the consensus module through the network layer.

[0104] Step S1011: The consensus module returns the block data of the blocks in the pending state.

[0105] Step S1012: The consensus module receives the log replication confirmation message from the follower node through the network layer.

[0106] Step S1013: If the number of blocks in the pending state that have been successfully replicated exceeds half of the total number of blocks in the cluster, then the pending state is set to the committed state and placed into the block pool.

[0107] Step S1014: The transaction node requests a block in the committed state from the block pool.

[0108] Step S1015: The block pool returns the committed blocks to the transaction nodes.

[0109] Step S1016: The transaction node executes the block and saves the execution result in the database.

[0110] It should be noted that steps S1006 to S1007 pertain to the log replication method, and the log replication process can be performed with reference to Example 1. This example will not elaborate further on this.

[0111] Example 3: Example 3 is a detailed process for consensus synchronization by follower nodes, including but not limited to steps S2001 to S2014. Step S2001: The user creates a transaction via the Web API and places it into the transaction pool.

[0112] Step S2001: The consensus module requests transaction data from the transaction pool.

[0113] Step S2003: The transaction pool returns the transaction data to the consensus module.

[0114] Step S2004: The consensus module sends transaction data to the leader node through the network layer.

[0115] Step S2005: The consensus module receives the log replication message from the leader node.

[0116] Step S2006: The consensus module sends log retrieval messages to the leader node through the network layer.

[0117] Step S2007: The consensus module receives the block data corresponding to the specified log number returned by the leader node.

[0118] Step S2008: Set the blocks obtained after log copying to the pending state and store them in the block pool.

[0119] Step S2009: The consensus module sends a log replication confirmation message to the leader node through the network layer.

[0120] Step S2010: The consensus module receives the first heartbeat message sent by the leader node through the network layer.

[0121] Step S2011: The consensus module sets the blocks in the pending state to the committed state.

[0122] Step S2012: The transaction node requests a committed block from the block pool.

[0123] Step S2013: The block pool returns the committed blocks to the transaction nodes.

[0124] Step S2014: The transaction node executes the committed blocks and saves the results in the database.

[0125] It should be noted that steps S2006 to S2007 pertain to the log replication method, and the log replication process can be performed with reference to Example 1. This example will not elaborate further on this.

[0126] In some embodiments, the consensus synchronization processes of the leader node and follower nodes are interconnected. Transactions in the leader node's transaction pool include transactions created by the leader node through its own Web API service, and transactions created by other follower nodes in the cluster through their own Web API services and transmitted to the leader node over the network. Transactions in the follower node's transaction pool are created only by its own Web API service. In the leader-follower consensus synchronization process, follower node synchronization step S2004 corresponds to leader node synchronization step S1002.

[0127] It's important to note that only the transaction nodes of the leader node can package transactions into blocks; the transaction nodes of follower nodes cannot. After packaging a block, the leader node sets it to a pending state and places it in the block pool. The consensus module then broadcasts a log replication message at the network layer, notifying follower nodes to replicate the block. When a follower node receives the log replication message broadcast by the leader node, it needs to actively send a log retrieval message to the leader to pull the missing block. The block replication process may require multiple iterations.

[0128] The follower node sets the received block to a pending state and adds it to the block pool. It then sends a log replication confirmation message to the leader node, notifying it that log replication was successful. The leader node receives the second heartbeat message from the follower through the network layer. In the consensus synchronization process between the leader and follower nodes, step S2009 of the follower node synchronization process corresponds to step S1012 of the leader node synchronization process.

[0129] When the number of successfully replicated blocks in the leader node's pending state exceeds a certain value in the entire cluster (e.g., more than half the total number of follower nodes), the leader node sets the pending blocks to the committed state and adds them to the block pool. The leader node's transaction nodes request committed blocks from the block pool, retrieve and execute the blocks, and finally save the execution results in the database. Since the leader node needs to periodically send first heartbeat messages to other nodes in the cluster, the leader node's heartbeat broadcast interest packet carries information such as the leader's committed log number and term number. When a follower node receives the leader's heartbeat broadcast interest packet, it sets the pending blocks corresponding to that log number and term number to the committed state. The follower node's transaction nodes request committed blocks from the block pool, execute the blocks, and save the results in the database. Therefore, the consensus method of this application embodiment solves the problem of integrating the Raft algorithm with the NDN network architecture in the blockchain consensus layer, providing a complete consensus solution for NDN networks based on the Raft algorithm.

[0130] This application also provides a consensus device for a named data network blockchain based on the Raft algorithm, including at least one processor and a memory for communicating with the at least one processor; the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the aforementioned remote command interaction method.

[0131] Reference Figure 12 Taking the consensus device 1000 of a Raft-based named data network blockchain, where the control processor 1001 and memory 1002 are connected via a bus as an example, the memory 1002, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, the memory 1002 may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1002 may optionally include memory remotely located relative to the control processor 1001, and these remote memories can be connected to the Raft-based named data network blockchain consensus device 1000 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0132] Those skilled in the art will understand that Figure 12 The device structure shown does not constitute a limitation on the consensus device 1000 of the named data network blockchain based on the Raft algorithm, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0133] This application also provides a computer-readable storage medium storing computer-executable instructions that are executed by one or more control processors, for example, by... Figure 12 One of the control processors 1001 executes, which can cause the one or more control processors to execute the remote command interaction method in the above method embodiment.

[0134] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.< / prelognumber> < / prelognumber> < / prelognumber> < / prelognumber> < / prelognumber> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / commitlognumber> < / nodeid> < / rafttag> < / subprefix> < / routableprefix> < / term> < / votefromnodeid> < / nodeid> < / rafttag> < / subprefix> < / routableprefix> < / term> < / votefromnodeid> < / nodeid> < / rafttag> < / subprefix> < / routableprefix> < / lastlognumber> < / lastlogterm> < / term> < / term> < / rafttag> < / broadcastprefix> < / lastlogterm> < / lastlognumber> < / term> < / nodeid> < / subprefix> < / rafttag> < / broadcastprefix> < / lastlogterm> < / lastlognumber> < / term> < / nodeid> < / subprefix> < / rafttag> < / broadcastprefix> < / nodeid> < / rafttag> < / subprefix> < / routableprefix> < / nonce> < / commitedlognumber> < / lastlogterm> < / lastlognumber> < / fromnodeid> < / nodeid> < / rafttag> < / subprefix> < / routableprefix> < / nonce> < / commitedlognumber> < / lastlogterm> < / lastlognumber> < / fromnodeid> < / nodeid> < / rafttag> < / subprefix> < / routableprefix> < / prelognumber> < / prelognumber> < / prelogterm> < / prelognumber> < / number> < / prelognumber> < / prelognumber> < / prelognumber> < / prelognumber> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / number> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / commitlognumber> < / term> < / nodecount> < / nonce> < / nodeid> < / subprefix> < / rafttag> < / broadcastprefix> < / prelogterm> < / prelognumber> < / commitlognumber> < / term> < / nodecount> < / nonce> < / nodeid> < / subprefix> < / rafttag> < / broadcastprefix> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelognumber> < / number> < / prelognumber> < / prelognumber> < / prelognumber> < / number> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber>

Claims

1. A consensus method for named data network blockchains based on the Raft algorithm, characterized in that, The blockchain includes a leader node and several follower nodes. The leader node periodically sends a first heartbeat message to the follower nodes, and the follower nodes periodically send a second heartbeat message to the leader node. The leader node notifies the follower nodes to replicate blocks through a log replication message, and the follower nodes notify the leader node that the block replication is complete through a log replication confirmation message. The first heartbeat message, the second heartbeat message, the log replication message, and the log replication confirmation message are defined by interest package names. The consensus method includes: Receive transactions created by users and add them to the transaction pool; The transactions are packaged into blocks and set to a pending state. The blocks in the pending state are then placed into the block pool. The log replication message is broadcast through the network layer to notify the follower nodes to replicate the block in the pending state; Receive the log acquisition message sent by the follower node through the network layer, and return the block data of the block in the pending state to the follower node; When the log replication confirmation message sent by the follower node is received, and it is determined that more than a preset number of the follower nodes in the blockchain have successfully replicated the block in the pending state, the block in the pending state is set to the committed state, and the block in the committed state is put into the block pool. The first heartbeat message is broadcast through the network layer to notify the follower nodes to set the block in the pending state to the committed state.

2. The consensus method according to claim 1, characterized in that, The first heartbeat message and the log replication message have the same interest packet format. The interest packet name definition of the first heartbeat message includes a first registered route string and a first committed state log number. The interest packet name definition of the log replication message includes the first registered route string, the first committed state log number, and a log replication field. The first registered route string is used to indicate that the current interest packet is a broadcast-sent heartbeat type interest packet based on the Raft algorithm. The first committed state log number is used to indicate the log number corresponding to the committed state block in the leader node. The log replication field is used to indicate the block data that the follower node pulls from the leader node.

3. The consensus method according to claim 2, characterized in that, The log replication fields include <prelognumber>fields and <prelogterm>Field, the <prelognumber>The value of the field is the previous log number of the leader node. <prelogterm> The value of the field is the term number of the previous log of the leader node;< / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> In the log replication message, the <prelognumber>Fields and the <prelogterm>The field is defined as the corresponding value; in the first heartbeat message, the <prelognumber>Fields and the <prelogterm> The field is not defined.< / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> 4. The consensus method according to claim 1, characterized in that, The process of receiving user-created transactions and placing them into the transaction pool includes: When a user creates a transaction on the follower node, the transaction data sent by the follower node is received through the network layer; The transaction data of the transaction is placed into the transaction pool.

5. A consensus method for named data network blockchains based on the Raft algorithm, characterized in that, The blockchain includes a leader node and several follower nodes. The leader node periodically sends a first heartbeat message to the follower nodes, and the follower nodes periodically send a second heartbeat message to the leader node. The leader node notifies the follower nodes to replicate blocks through a log replication message, and the follower nodes notify the leader node that the block replication is complete through a log replication confirmation message. The first heartbeat message, the second heartbeat message, the log replication message, and the log replication confirmation message are defined by interest package names. The consensus method includes: The leader node broadcasts a log replication message, which is used to notify the follower node to replicate blocks in the pending state. Send a log retrieval message to the leader node, and receive block data of the unprocessed blocks returned by the leader node based on the log retrieval message; Copy the block data, set the copied block to a pending state and put it into the block pool; Send the log replication confirmation message to the leader node; The leader node receives the first heartbeat message broadcast by the leader node, which is used to notify the follower node to set the block in the pending state to the committed state.

6. The consensus method according to claim 5, characterized in that, The interest packet name definition of the log replication message includes a log replication field, which includes... <prelognumber>fields and <prelogterm>Fields, the <prelognumber>The value of the field is the previous log number of the leader node. <prelogterm> The value of the field is the term number of the previous log of the leader node;< / prelogterm> < / prelognumber> < / prelogterm> < / prelognumber> Sending a log retrieval message to the leader node includes: Determine if the log number is stored locally. <prelognumber>The value of the field and the corresponding term number are as described <prelogterm> The log corresponding to the field's value;< / prelogterm> < / prelognumber> If so, send a log retrieval message to the leader node, the log retrieval message including an indication of the log number. <number>The field is used to request a replication log number greater than the specified value from the leader node. <prelognumber> All logs for the field's value;< / prelognumber> < / number> If not, from the above <prelognumber>The field value is used to search backwards for the last log number among the follower nodes, and the log content of that last log number is overwritten backwards until all logs are overwritten. <prelognumber>The value of the field corresponds to the log number of the log, and then a log retrieval message is sent to the leader node. The log retrieval message includes information indicating the log number. <number>The field requests a replication log number greater than the specified value from the leader node. <prelognumber> All logs for the field's value.< / prelognumber> < / number> < / prelognumber> < / prelognumber> 7. The consensus method according to claim 5, characterized in that, Also includes: Send the second heartbeat message to the leader node so that the leader node updates and maintains the list of surviving follower nodes in the blockchain according to the second heartbeat message; The second heartbeat message and the log replication confirmation message have the same interest packet format. The interest packet name definition of the second heartbeat message includes a second registration route string, a second committed state log number, and a last log information field. The second registration route string is used to indicate that the current interest packet is a numeric type interest packet based on the Raft algorithm for the specified leader node. The second committed state log number is used to indicate the log number corresponding to the committed block in the follower node. The last log information field is used to indicate the log number and corresponding term number of the last log in the follower node.

8. The consensus method according to claim 5, characterized in that, The follower node includes an election timer; the consensus method further includes: If the election timer does not receive the first heartbeat message from the leader node within a preset time period, it triggers the current follower node to increase its own term number and change its role to that of a candidate. A new election process is initiated and voting request messages are sent to other nodes in the blockchain, the voting request messages being defined by interest package names.

9. The consensus method according to claim 5, characterized in that, When a user creates a transaction on the follower node, the consensus method further includes: Transaction data is sent to the leader node through the network layer.

10. The consensus method according to claim 9, characterized in that, Sending transaction data to the leader node through the network layer includes: When the amount of transaction data is less than a preset threshold, the transaction data is sent as a parameter of the interest package to the leader node; When the amount of transaction data exceeds the preset threshold, the node name of the follower node and the hash value of the transaction data are sent to the leader node as parameters of the interest packet, and a dictionary of the correspondence between the hash value and the transaction data is constructed.

11. A consensus method for named data network blockchains based on the Raft algorithm, characterized in that, The blockchain includes a leader node and several follower nodes. The leader node periodically sends a first heartbeat message to the follower nodes, and the follower nodes periodically send a second heartbeat message to the leader node. The first and second heartbeat messages are defined by interest package names. The follower nodes include an election timer. The consensus method includes: If the election timer does not receive the first heartbeat message from the leader node within a preset time period, the follower node increments its own term number and transforms itself into a candidate node. The candidate node initiates a new election process and sends a voting request message to other nodes in the blockchain, the voting request message being defined by an interest package name; The candidate node initiates a new election process and sends voting request messages to other nodes in the blockchain, including: The candidate node votes for itself and sends a voting request message to other nodes in the blockchain. The voting request message carries the candidate node's current term number, the log number of the last log entry, and the corresponding term number. Upon receiving the voting request message, the follower node sends a vote to the candidate node if the first and second conditions are met. The first condition is that the current term number of the follower node is less than the current term number of the candidate node, and the second condition is that the log number and corresponding term number of the last log of the follower node are less than the log number and corresponding term number of the last log of the candidate node.

12. The consensus method according to claim 11, characterized in that, In the blockchain, each node is initially a follower node, and the election timer in each follower node is set to a random timeout duration.

13. A consensus device for a named data network blockchain based on the Raft algorithm, characterized in that, It includes at least one processor and a memory for communicatively connecting to the at least one processor; the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the consensus method as described in any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the consensus method as described in any one of claims 1 to 10.

Images