A blockchain consensus method based on a wireless ad hoc network topology

Abstract

The application discloses a kind of based on wireless self-organizing network topology's blockchain consensus method.According to the current topology of wireless self-organizing network, relay broadcast link is constructed;According to relay broadcast link, reliable broadcast network and asynchronous binary consensus network are constructed, and blockchain network is composed;According to asynchronous binary consensus network, consensus group is constructed;Periodically, the content proposed by each node is consensus, including two types of user data and network topology change information;After consensus, report to application layer, or update local network topology and re-perform system construction.The method inherits the decentralization characteristics of blockchain in network layer, avoids single point failure problem;Using the broadcast nature of wireless communication, an efficient broadcast mechanism based on network topology is used, which reduces the communication overhead in the blockchain consensus process;A blockchain construction mechanism based on network topology is used, which solves the mismatch problem of low dynamicity of traditional private chain consensus algorithm and high dynamicity of wireless self-organizing network.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of wireless ad hoc network technology and blockchain technology, and particularly relates to a blockchain consensus method based on a wireless ad hoc network topology. BACKGROUND

[0002] A wireless ad hoc network is a centerless, multi-hop, temporary autonomous system formed by devices with terminal and routing functions through wireless links. The purpose is to transmit information flow through dynamic routing technology to meet certain quality of service requirements. Compared with traditional network forms, wireless ad hoc networks do not need the support of existing communication base stations, nor do they have "gateway" nodes in traditional networks. Instead, all nodes can bear the function of routing (i.e. message relay and forwarding) for the remaining nodes, so they have the advantages of strong network robustness and low deployment cost.

[0003] On the other hand, wireless ad hoc networks have certain bottlenecks. First, compared with wired communication, the physical form of wireless communication is usually omnidirectional and unconstrained radio frequency broadcast, which results in more channel resources being occupied by a single wireless communication and makes it more likely to cause channel contention problems. Second, the network topology of wireless ad hoc networks is more complex, and each node has relay capability, so static routing protocols in traditional star networking cannot be used, and there is a high demand for consistency in the network topology cognition of each node.

[0004] In addition, there is a demand for data consistency in wireless ad hoc networks. For example, a swarm of unmanned aerial vehicles using wireless ad hoc networks needs to synchronize the strategies executed to achieve a common goal; in order to meet the consistency requirements of the application layer and the network layer, a blockchain can be deployed in the wireless ad hoc network.

[0005] Blockchain is a kind of distributed consensus system with certain anti-interference ability, which aims to achieve the so-called "consensus" by only communicating with each other among the nodes on the chain to execute a specific "consensus algorithm" without the third-party authority notarization. In this process, the blockchain system can also cope with certain node malpractice or offline situation without affecting the consistency of the results. Blockchain can be divided into two categories: public chain and private chain, among which the nodes in the private chain need to be authenticated, and each node on the chain has a certain mutual trust degree initially, showing a cooperative relationship, which is similar to the situation of wireless ad hoc network. Further, according to whether the consensus algorithm can resist node malpractice, the private chain can be divided into Byzantine Fault Tolerance (BFT) and Crash Fault Tolerance (CFT). In the BFT consensus algorithm, according to whether all nodes can propose consensus requests, it can be divided into two categories: centralized BFT and non-centralized BFT consensus algorithm. The latter is similar to the actual situation of wireless ad hoc network.

[0006] In the non-centralized BFT consensus algorithm, every fixed time, each node on the chain will make a proposal, and then each node will reach a consensus on these proposals and select some proposals as the consensus result. This process can be divided into two steps: the first is Reliable BroadCast (RBC), and the second is Asynchronous Binary Agreement (ABA). In the reliable broadcast stage, a proposal is broadcast after the init, echo, and ready stages, and the output proposal can be ensured to be the same at this time. In the asynchronous binary consensus stage, each node expresses a binary opinion of approval or opposition to each proposal output by reliable broadcast, and conducts a full vote. After several rounds of voting, the group binary opinion of each proposal will tend to be consistent, and will be finally determined and output at a certain time, thus completing the overall consensus.

[0007] However, traditional blockchain research usually uses high-speed and stable wired networks, and does not consider the architecture and communication problems of the network layer. However, when deploying a blockchain in a wireless ad hoc network, the adaptability of the network layer architecture to the blockchain is also very important: first, if a traditional star network is used, the entire network will be paralyzed if the gateway node fails, which creates a single point of failure problem, causing the blockchain to lose its "decentralization" feature. Second, if the wireless channel is encapsulated as a point-to-point channel and a dynamic routing algorithm is used for point-to-point communication, because almost all communications in the blockchain are full-network broadcasts, the total network traffic for a consensus will be greatly increased, seriously affecting the consensus speed of the blockchain. Third, the nodes of a wireless ad hoc network have a certain mobility, and the network topology and total number of nodes can change over time, while traditional decentralized BFT consensus algorithms require a fixed total number of nodes. Therefore, it is necessary to design a blockchain consensus algorithm that adapts to wireless ad hoc networks, so that it can inherit the decentralized nature of the blockchain at the network layer, and fully utilize the physical characteristics of wireless ad hoc network communication to reduce the total communication volume of full-network broadcasts, and also have a certain degree of dynamic nature, allowing the blockchain network to dynamically adapt to changes in the wireless ad hoc network. SUMMARY

[0008] The present application aims at the deficiencies of the prior art and provides a blockchain consensus method based on a wireless ad hoc network topology.

[0009] To achieve the above-mentioned purpose, the present application provides a blockchain consensus method based on a wireless ad hoc network topology, comprising the following steps:

[0010] (1) Construct a relay broadcast link, the broadcast link being a tree-shaped link with a message source node as a root node and containing all other nodes;

[0011] (2) Construct a reliable broadcast network, for any node, its reliable broadcast participating nodes are all nodes in the relay broadcast link with it as the source node;

[0012] (3) Construct an asynchronous binary consensus network, the asynchronous binary consensus network being the one with the least number of participating nodes in the reliable broadcast network of all nodes;

[0013] (4) Construct a consensus group, for each node in the asynchronous binary consensus network of the entire network, construct a node set with it as the core, called the consensus group; the member nodes of the consensus group are the node and all adjacent nodes of the node that are not in the asynchronous binary consensus network of the entire network;

[0014] (5) Collect and package the consensus data to form a block; each node stores the consensus request from the upper layer application in the local cache; the node network layer detects the change of the neighboring node and stores the message in the local cache; each node takes the data from the local cache and packages it into a block, and inputs the block into the reliable broadcast protocol;

[0015] (6) Perform the reliable broadcast protocol on the block obtained in step (5);

[0016] (7) Package the block output by the reliable broadcast protocol into a macro block, and input the macro block into the asynchronous binary consensus protocol;

[0017] (8) Perform the asynchronous binary consensus protocol on the macro block obtained in step (7);

[0018] (9) Perform the smart contract or report to the application layer on the consensus result obtained in step (8); if the block is network topology change information generated by the network layer, execute the smart contract, adjust the local network topology graph, and use the new topology graph for subsequent consensus; otherwise, if the block is a general consensus message generated by the application layer, report to the local application layer.

[0019] Further, the step (1) comprises the following sub-steps:

[0020] (1.1) Generate a link root node as a source node P s , whose parent node is

[0021] (1.2) Calculate the set of nodes to be covered C i for each end node P i of the current link:

[0022] C i = N(N(P i ))-N(P i )-P f -N(P f )

[0023] Wherein, N() represents taking the neighboring node;

[0024] (1.3) Select a node P j from the range of N(P i )-P f , so that the set N(P i )∪C i has the most elements, and if there are multiple nodes with the same id, select the node with the smallest id; add the selected node to the relay broadcast link and make it a child node of P i ;

[0025] (1.4) Let Ci = C i -N(P j ), repeat step (1.3) - step (1.4) until

[0026] (1.5) For the nodes newly added to the relay broadcast link, take them as the end nodes, iteratively execute step (1.2) - step (1.5) in turn until no new node is added to the relay broadcast link, and finally obtain the tree-shaped link as the relay broadcast link of the source node P s .

[0027] Further, the step (6) comprises the following sub-steps:

[0028] (6.1) The source node broadcasts the initial message;

[0029] (6.2) In the reliable broadcast network of the source node, when a node in the network receives a message satisfying the first condition, the node broadcasts the echo message;

[0030] (6.3) When a node in the network receives a message satisfying the second condition, the node broadcasts the ready message:

[0031] (6.4) When a node in the network receives at least pieces of ready messages with the same V, src, m, the node accepts m and outputs {V, src, m}; wherein V refers to the consensus sequence number, src refers to the block generation source node id, m refers to the data content, and N refers to the total number of nodes in the reliable broadcast network;

[0032] (6.5) The remaining nodes have at least one adjacent node in the network; by listening to the message of the adjacent node, when at least pieces of ready messages with the same V, src, m are received, the node accepts m and outputs {V, src, m}.

[0033] Further, in the step (6.2), the first condition comprises:

[0034] Condition 1.1: an initial message;

[0035] Condition 1.2: at least pieces of echo messages with the same V, src, m;

[0036] Condition 1.3: at least pieces of ready messages with the same V, src, m.

[0037] Further, in the step (6.3), the second condition comprises:

[0038] Condition 2.1: at least pieces of messages;

[0039] Condition 2.2: at least pieces of ready messages.

[0040] Further, the step (8) comprises the following sub-steps:

[0041] (8.1) initializing consensus participants as nodes in the asynchronous binary consensus network, with the total number of nodes being N, for each consensus sequence number V; and setting the block number block_id = 0;

[0042] (8.2) for an input macro block, querying the current block number block_id according to its consensus sequence number V, if setting the binary value b = 1, otherwise, setting the binary value b = 0;

[0043] (8.3) broadcasting an asynchronous binary consensus message;

[0044] (8.4) when an asynchronous binary consensus node receives an asynchronous binary consensus message, parsing the source consensus node id, consensus sequence number V, macro block core node number core, consensus round i, and binary value b; querying the history record according to V, core, and i to obtain the number of agreeing nodes agree, the number of disagreeing nodes disagree, and the list of alternative binary values L; if b = 1, increasing agree by 1, otherwise, increasing disagree by 1;

[0045] (8.5) updating the list of alternative binary values L when the third condition is met;

[0046] (8.6) generating an asynchronous binary consensus message and broadcasting when the fourth condition is met;

[0047] (8.7) ending the asynchronous binary consensus and outputting the result when the fifth condition is met:

[0048] (8.8) when receiving pieces of messages, if no output is generated, starting the next round of consensus, setting the consensus round i to be increased by 1; randomly selecting one from the current list of alternative binary values L as the initial binary value, and broadcasting a new round of asynchronous binary consensus message.

[0049] Further, in the step (8.5), the third condition comprises:

[0050] Condition 3.1: the source consensus node is itself, and the binary value b is added to the list of alternative binary values L;

[0051] Condition 3.2: if adding binary value 1 to the list of candidate binary values L;

[0052] Condition 3.3: If adding binary value 0 to the list of candidate binary values L.

[0053] Further, in the step (8.6), the fourth condition comprises:

[0054] Condition 4.1: If the node has not generated an output yet, and and binary value 1 is not originally in the list of candidate binary values L, then broadcasting an asynchronous binary consensus message with binary value 1 and the rest of the values being the same as the received message;

[0055] Condition 4.2: If the node has not generated an output yet, and binary value 0 is not originally in the list of candidate binary values L, then broadcasting an asynchronous binary consensus message with binary value 0 and the rest of the values being the same as the received message;

[0056] Condition 4.3: If the node has generated an output b, and the node has not broadcasted a message in this round, then broadcasting an asynchronous binary consensus message with binary value b and the rest of the values being the same as the received message.

[0057] Further, in the step (8.7), the fifth condition comprises:

[0058] Condition 5.1: If accepting the message, outputting 1, and writing the block into the consensus history record;

[0059] Condition 5.2: rejecting the message, outputting 0.

[0060] Compared with the prior art, the present application has the following advantages: the present application utilizes the characteristic that all nodes in a wireless ad hoc network can serve as routing nodes, inherits the decentralized characteristic of a blockchain at the network layer, and avoids single-point failure problems. Secondly, the present application utilizes the broadcast nature of wireless communication, uses an efficient broadcast mechanism based on network topology, and greatly reduces the communication overhead in the blockchain consensus process. Finally, the present application uses a blockchain construction mechanism based on network topology, determines the nodes on the chain by using the current network topology, and automatically switches when the network topology changes, so that the blockchain is adapted to the wireless ad hoc network environment.

[0061] The present application will be further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0062] Figure 1 The system level schematic diagram of the blockchain consensus method based on the wireless ad hoc network topology structure proposed in the present application.

[0063] Figure 2 The flowchart of the implementation of the blockchain consensus method based on the wireless ad hoc network topology structure of the present application.

[0064] Figure 3 The schematic diagram of the network layer data packet format of the present application.

[0065] Figure 4 The flowchart of the broadcast routing protocol used by the network layer of the present application.

[0066] Figure 5 The schematic diagram of the network topology structure.

[0067] Figure 6 The schematic diagram of the content format of the block generated by the consensus layer of the present application.

[0068] Figure 7 The flowchart of the reliable broadcast protocol.

[0069] Figure 8 The schematic diagram of the format of the initial, echo and ready messages in the reliable broadcast protocol.

[0070] Figure 9 The schematic diagram of the content format of the macro block generated by the consensus layer of the present application.

[0071] Figure 10 The flowchart of the generation of the new consensus message in the asynchronous binary consensus protocol.

[0072] Figure 11 The flowchart of the processing of the consensus message in the asynchronous binary consensus protocol.

[0073] Figure 12 The schematic diagram of the format of the asynchronous binary consensus message. DETAILED DESCRIPTION

[0074] Exemplary embodiments of the present application are described herein with reference to the accompanying drawings, which are meant to be exemplary in nature, and include various specific details to facilitate understanding, and should be considered in the context of what is described herein. One skilled in the art will realize that various changes and modifications can be made to the embodiments described herein, without departing from the scope and spirit of the present application. Also, for the sake of brevity and clarity, any description of well-known functions and constructions will be omitted so as to not obscure the description of the present application.

[0075] The present application proposes a blockchain consensus method based on the wireless ad hoc network topology structure, which can be deployed in a distributed system using a wireless ad hoc network, wherein the method content run by each node is consistent. As shown in Figure 1As shown, the method involves three levels of network layer, consensus layer and application layer. Among them, the network layer is responsible for the information transmission between nodes, this layer maintains the current topology of wireless ad hoc network, communicates with adjacent nodes based on data link layer broadcast frame, and runs a specific broadcast routing protocol, and realizes the broadcast transmission of information in the whole network through controlled relay broadcast. The consensus layer is responsible for running the centerless BFT type blockchain consensus algorithm, including reliable broadcast and asynchronous binary consensus two sub-protocols, and the application layer is the user interface. Users can input the information that needs to be consensus at any time, and obtain the information that has been consensus at present.

[0076] For the definition and correctness proof of the centerless BFT type consensus algorithm, reliable broadcast and asynchronous binary consensus, please refer to the paper Bracha G. Asynchronous Byzantine agreement protocols [J]. Information and Computation, 1987, 75 (2): 130-143.

[0077] The flow of the method of the application is as shown in Figure 2 The specific steps include the following steps:

[0078] Step (1), constructing a relay broadcast link. The so-called broadcast link is a tree-like link with the message source node as the root node and containing the rest of the nodes. When a node in the link receives the broadcast of its parent node, it will broadcast this message to all its adjacent nodes, and then the nodes in the adjacent nodes that are located in the same broadcast link will repeat this process. When all nodes in the broadcast link have broadcasted once, all nodes in the network will be able to hear the message. The set of nodes above can be called "connected dominating set" in mathematics, and the one with the least number of nodes is called "minimum connected dominating set".

[0079] For the definition of the concept of dominating set, please refer to the monograph: Zhang Qinghua. Graph Theory and Its Application [M]. Tsinghua University Press, 2013.

[0080] The application uses the Dominant Pruning (DP) type algorithm to construct the approximate minimum connected dominating set as the relay broadcast link. This algorithm has multiple improved versions, and any one of them is feasible in the application.

[0081] As an example, the principle of the DP algorithm used in the application can be found in the paper Lim H, Kim C. Flooding in wireless ad hoc networks [J]. Computer communications, 2001, 24 (3-4): 353-363.

[0082] The method for constructing the relay broadcast link adopted by the application is as follows:

[0083] (1.1) Generate the link root node as the source node P s , whose parent node

[0084] (1.2) For each end node P i of the current link, calculate the set of nodes to be covered C i :

[0085] C i = N(N(P i ))-N(P i )-P f -N(P f )

[0086] Where N() represents taking the adjacent node.

[0087] (1.3) Select a node P i from the range of N(P f )-P j , so that the set N(P i )∪C i has the most elements, if there are multiple nodes with the same id, select the node with the smallest id; add the selected node to the relay broadcast link, and make it a child node of P i .

[0088] (1.4) Let C i = C i -N(P j ), repeat steps (1.3), (1.4) until

[0089] (1.5) For the nodes newly added to the relay broadcast link, take them as end nodes, and iteratively execute steps (1.2), (1.3), (1.4), (1.5) in turn, until no new node is added to the relay broadcast link, and the final tree-shaped link is the relay broadcast link of the source node P s .

[0090] After the relay broadcast link is constructed, the network layer of each node in the present application will execute a specific broadcast routing protocol and use a specific network data packet for all network layer communications. Specifically, the network layer data packet format of the present application is as shown in Figure 3 ; the network layer broadcast routing protocol flow chart is as shown in Figure 4 , and the specific description is as follows:

[0091] A: receives a network data packet, unpacks it, and obtains the data packet content m, the consensus sequence number V used, the data packet source node number src, and the broadcast link root node number root.

[0092] B: If the consensus of sequence number V has not been completed locally, the package is temporarily stored until the consensus of sequence number V is completed, and then the following steps are continued.

[0093] C: The data package content is reported to the consensus layer of the node.

[0094] D: Query the broadcast link of the source node as the root, and determine whether the node is located on the link. If yes, relay broadcast the data package.

[0095] The relay broadcast link obtained above will be responsible for the transmission of network data packages in the following steps.

[0096] Step (2), build a reliable broadcast network. For any node, its reliable broadcast participating nodes are all nodes in the relay broadcast link with it as the source node.

[0097] Step (3), build an asynchronous binary consensus network. The asynchronous binary consensus network of the whole network has only one, which is the least number of participating nodes in the reliable broadcast network of all nodes. If there are multiple network nodes with the same number, take the smallest one with the smallest index in the network. For example, when the network topology is as shown in Figure 5 , the reliable broadcast network {2, 5, 8} of node 2 and the reliable broadcast network {4, 5, 6} of node 4 both contain three nodes, which are the least in each node, but because 2 < 4, the reliable broadcast network {2, 5, 8} of node 2 becomes the asynchronous binary consensus network of the whole network.

[0098] Step (4), build a consensus group. For each node in the asynchronous binary consensus network of the whole network, build a node set with it as the core, called the consensus group. The member nodes of the consensus group are: the node and all adjacent nodes of the node that are not in the asynchronous binary consensus network of the whole network.

[0099] Step (5), collect and package the data to be consensus, and form a block. After receiving the consensus request of the upper layer application, each node stores it in the local cache; after detecting the change of adjacent nodes, the node network layer also stores this message in the local cache. Every certain time, each node takes a certain amount of data from the local cache, packages it into a block, and its format is as shown in Figure 6 ; execute the reliable broadcast protocol on the block. The value of time and quantity varies according to the total number of asynchronous binary consensus nodes, network bandwidth and other factors, and its specific quantity is determined according to experience. For example: when the total number of nodes = 20, the network bandwidth = 10 Mbps, every 1s takes 1000 messages from the local cache (if not enough, take all).

[0100] Step (6), execute the reliable broadcast protocol. The flow chart of this step is as shown in Figure 7As shown, the so-called "broadcast" in this step refers to the relay broadcast along the relay broadcast link within the reliable broadcast network, unless otherwise specified. In the symbols used below, V refers to the consensus sequence number, src refers to the block generation source node id, m refers to the data content, and N refers to the total number of nodes in the reliable broadcast network. The specific steps are as follows:

[0101] (6.1) The source node broadcasts an initial message, the specific format of which is as shown in the following formula (1): Figure 8 wherein the message type is initial (represented by 1).

[0102] (6.2) In the above network (the reliable broadcast network of the source node), when a node in the network receives a message that satisfies the following first condition, the node broadcasts an echo message, the specific format of which is as shown in the following formula (2): Figure 8 wherein the message type is echo (represented by 2). It should be noted that each node in the network will construct a reliable broadcast network, which is only responsible for broadcasting the information of the node to the entire network; a node may participate in the reliable broadcast networks of multiple nodes.

[0103] Condition 1.1: an initial message;

[0104] Condition 1.2: at least echo messages with the same V, src, and m;

[0105] Condition 1.3: at least ready messages with the same V, src, and m;

[0106] (6.3) In the above network, when a node in the network receives a message that satisfies the following second condition, the node broadcasts a ready message, the specific format of which is as shown in the following formula (3): Figure 8 wherein the message type is ready (represented by 3):

[0107] Condition 2.1: at least messages with the same V, src, and m;

[0108] Condition 2.2: at least ready messages with the same V, src, and m;

[0109] (6.4) In the above network, when a node in the network receives at least ready messages with the same V, src, and m, the node accepts m and outputs {V, src, m}.

[0110] (6.5) Outside the above network, the rest of the nodes must have at least one adjacent node located in the network. By listening to the messages of the adjacent nodes, when receiving at least one ready message with the same V, src, m, the node accepts m and outputs {V, src, m}.

[0111] Step (7), package the reliable broadcast output block into a macro block. For any asynchronous binary consensus node, when it outputs a block m by the reliable broadcast protocol, store m in the local cache; then check the cache, if there is at least one consensus group, the local cache already contains blocks of all its members, then extract these blocks, package them into a whole block, called macro block, the specific format is as shown in Figure 9 ; input the macro block into the asynchronous binary consensus protocol.

[0112] Step (8), execute the asynchronous binary consensus protocol. Among them, the process of generating new asynchronous binary consensus messages is as shown in Figure 10 , and the asynchronous binary consensus process is as shown in Figure 11 . Unless otherwise specified, the so-called "broadcast" in this step refers to relay broadcast along the relay broadcast link within the scope of the asynchronous binary consensus network. The specific steps are as follows:

[0113] (8.1) For each consensus sequence number V, initialize the consensus participating nodes to be all nodes in the asynchronous binary consensus network, and denote the total number of nodes as N; the block number block_id = 0.

[0114] (8.2) For the input macro block, according to its consensus sequence number V, query the current block number block_id, if Let the binary value b = 1, otherwise, let the binary value b = 0.

[0115] (8.3) Broadcast the asynchronous binary consensus message, the format is as shown in Figure 12 .

[0116] (8.4) When an asynchronous binary consensus node receives an asynchronous binary consensus message, parse its source consensus node id, consensus sequence number V, macro block core node number core, consensus round i, and binary value b; according to V, core, i, query the historical record to obtain the number of agreeing nodes agree (initially 0), the number of disagreeing nodes disagree (initially 0), and the list of alternative binary values L (initially ).

[0117] (8.5) When the following third condition is met, update the list of alternative binary values L:

[0118] ​Condition 3.1: If the source consensus node is itself, add the binary value b to the list of candidate binary values L.

[0119] Condition 3.2: If the source consensus node is not itself, and add the binary value 1 to the list of candidate binary values L.

[0120] Condition 3.3: If the source consensus node is not itself, and add the binary value 0 to the list of candidate binary values L.

[0121] (8.6) When the following fourth condition is met, generate and broadcast an asynchronous binary consensus message:

[0122] Condition 4.1: If the node has not yet generated an output, and and the binary value 1 is not originally in the list of candidate binary values L, broadcast an asynchronous binary consensus message with binary value 1 and the rest of the values being the same as the received message.

[0123] Condition 4.2: If the node has not yet generated an output, and the binary value 0 is not originally in the list of candidate binary values L, broadcast an asynchronous binary consensus message with binary value 0 and the rest of the values being the same as the received message.

[0124] Condition 4.3: If the node has already generated an output b, and the node has not broadcast a message in this round, broadcast an asynchronous binary consensus message with binary value b and the rest of the values being the same as the received message.

[0125] (8.7) When the following fifth condition is met, end the asynchronous binary consensus and output the result:

[0126] Condition 5.1: If accept the message, output 1, and write the block to the consensus history record.

[0127] Condition 5.2: reject the message and output 0.

[0128] (8.8) When receiving messages, if no output is generated, start the next round of consensus, increment the consensus round number i by 1, randomly select one from the current list of candidate binary values L as the initial binary value, and broadcast a new asynchronous binary consensus message for the next round.

[0129] Step (9), execute the smart contract or report to the application layer for the consensus result. If the block is network topology change information generated by the network layer, execute the smart contract, adjust the local network topology graph, and use the new topology graph for subsequent consensus; otherwise, if the block is a general consensus message generated by the application layer, report to the local application layer.

[0130] The above merely provides the specific embodiments of the present application, and cannot be used to limit the scope of the present application. Any equivalent changes made by those skilled in the art according to the present application, and the changes well known to those skilled in the art, shall still fall within the scope of the present application.

Claims

1. A blockchain consensus method based on wireless ad hoc network topology, characterized in that: The following steps are involved: (1) Constructing a relay broadcast link, which is a tree-like link with the message source node as the root node and including the remaining nodes; (2) Construct a reliable broadcast network. For any node, its reliable broadcast participating nodes are all nodes in the relay broadcast link with it as the source node; (3) constructing an asynchronous binary consensus network, wherein the asynchronous binary consensus network is the one with the least number of participating nodes in the reliable broadcast network of all nodes; (4) Constructing a consensus group. For each node in the asynchronous binary consensus network of the entire network, a node set with it as the core is constructed, which is called a consensus group. The member nodes of the consensus group are the node and all its neighboring nodes that are not in the asynchronous binary consensus network of the entire network. (5) Collect and package the data to be agreed upon to form a block; after each node receives the consensus request from the upper-layer application, it stores it in the local cache; After the node network layer detects a change in a neighboring node, it stores the message in the local cache. Each node takes the data from the local cache, packages it into a block, and inputs the block into the reliable broadcast protocol. (6) executing a reliable broadcast protocol on the block obtained in step (5); (7) Packing the blocks output by the reliable broadcast protocol into macro blocks, and inputting the macro blocks into the asynchronous binary consensus protocol; (8) executing an asynchronous binary consensus protocol on the macroblock obtained in step (7); (9) Execute the smart contract or report the consensus result obtained in step (8) to the application layer; if the block is the network topology change information generated by the network layer, execute the smart contract, adjust the local network topology map, and use the new topology map for subsequent consensus; otherwise, if the block is a general consensus message generated by the application layer, report it to the local application layer.

2. The blockchain consensus method based on wireless ad hoc network topology according to claim 1 is characterized in that: The step (1) includes the following sub-steps: (1.1) Generate the link root node as source node P s , its parent node (1.2) For each end node Pi of the current link, calculate the set of nodes to be covered C i : C i =N(N(P i ))-N(P i )-P f -N(P f ) Among them, N() represents taking neighboring nodes; (1.3) From N(P i )-P f Select a node P within the range j , so that the set N(F i )∪C i If there are multiple nodes with the same ID, the node with the smallest ID value is selected; the selected node is added to the relay broadcast link and becomes the P in the link. i 's child nodes; (1.4) Let C i =C i -N(P j ), repeat steps (1.3)-step (1.4) until (1.5) For the node newly added to the relay broadcast link, take it as the end node and iterate step (1.2) to step (1.5) in sequence until no new node is added to the relay broadcast link. The final tree link is the source node P s relay broadcast link.

3. The blockchain consensus method based on wireless ad hoc network topology according to claim 1 is characterized in that: The step (6) includes the following sub-steps: (6.1) The source node broadcasts the initial message; (6.2) In a reliable broadcast network of a source node, when a node in the network receives a message that meets the first condition, the node broadcasts an echo message; (6.3) When a node in the network receives a message that meets the second condition, the node broadcasts a ready message: (6.4) When a node in the network receives at least When a ready message is received, the node accepts m and outputs {V, src, m}; Among them, V refers to the consensus sequence number, src refers to the block generation source node ID, m refers to the data content, and N refers to the total number of nodes in the reliable broadcast network; (6.5) The remaining nodes have at least one neighboring node in the network; by listening to the message of the neighboring node, when receiving at least one message with the same V, src, m When a ready message is received, the node accepts m and outputs {V, src, m}.

4. The blockchain consensus method based on wireless ad hoc network topology according to claim 3 is characterized in that: In the step (6.2), the first condition includes: Condition 1.1: an initial message; Condition 1.2: At least one echo message; Condition 1.3: At least one ready messages.

5. The blockchain consensus method based on wireless ad hoc network topology according to claim 3 is characterized in that: In the step (6.3), the second condition includes: Condition 2.1: At least one Messages; Condition 2.2: At least one ready messages.

6. The blockchain consensus method based on wireless ad hoc network topology according to claim 1 is characterized in that: The step (8) includes the following sub-steps: (8.1) For each consensus sequence number V, the initial consensus participating nodes are all nodes in the asynchronous binary consensus network, with a total number of nodes being N; block number block_id = 0; (8.2) For the input macroblock, according to its consensus sequence number V, query the current block number block_id, if Let the binary value b=1, otherwise, let the binary value b=0; (8.3) Broadcast asynchronous binary consensus messages; (8.4) When an asynchronous binary consensus node receives an asynchronous binary consensus message, it parses the source consensus node ID, consensus sequence number V, macroblock core node number core, consensus round number i, and binary value b. Based on V, core, and i, it queries the historical records to obtain the number of agreeing nodes, the number of dissenting nodes, and the list of alternative binary values ​​L. If b = 1, it increments agree by 1; otherwise, it increments disagree by 1. (8.5) When the third condition is met, update the candidate binary value list L; (8.6) When the fourth condition is met, an asynchronous binary consensus message is generated and broadcast; (8.7) When the fifth condition is met, the asynchronous binary consensus ends and the result is output: (8.8) When receiving After receiving the message, if no output is generated, the next round of consensus is started, and the consensus round number i is incremented by 1; a binary value is randomly selected from the current candidate binary value list L as the initial binary value, and a new round of asynchronous binary consensus message is broadcast.

7. The blockchain consensus method based on wireless ad hoc network topology according to claim 6 is characterized in that: In the step (8.5), the third condition includes: Condition 3.1: The source consensus node is itself, and the binary value b is added to the candidate binary value list L; Condition 3.2: If Add the binary value 1 to the candidate binary value list L; Condition 3.3: If Add the binary value 0 to the list L of candidate binary values.

8. The blockchain consensus method based on wireless ad hoc network topology according to claim 6 is characterized in that: In the step (8.6), the fourth condition includes: Condition 4.1: If this node has not yet produced any output, and If the binary value 1 is not originally in the candidate binary value list L, then an asynchronous binary consensus message with the binary value 1 and the remaining values ​​being the same as the received message is broadcast; Condition 4.2: If this node has not yet produced any output, If the binary value 0 is not originally in the candidate binary value list L, then an asynchronous binary consensus message with the binary value 0 and the remaining values ​​being the same as the received message is broadcast; Condition 4.3: If the node has already generated output b and has not broadcast any message in this round, then broadcast an asynchronous binary consensus message with the binary value b and the remaining values ​​being the same as the received message.

9. The blockchain consensus method based on wireless ad hoc network topology according to claim 6 is characterized in that: In the step (8.7), the fifth condition includes: Condition 5.1: If Accept the message, output 1, and write the block into the consensus history; Condition 5.2: Reject the message and output 0.

Images