Three-dimensional traffic network-oriented block chain system consensus establishment method

Abstract

The invention discloses a three-dimensional traffic network-oriented block chain system consensus establishment method, and relates to the technical field of three-dimensional traffic networks and block chains, and the method comprises the steps: constructing a three-dimensional traffic network-oriented block chain system which comprises a plurality of nodes; the nodes are divided into consensus nodes and verification nodes. Client transaction is processed through a consensus algorithm normal protocol, if the master node fails, view switching is executed based on the consensus node to update the master node, and calculation of a master node failure result is executed based on the updated master node; and if no fault exists, confirming the transaction and creating a new block. Synchronizing a new block to a verification node by using a tree broadcast strategy, and if the number of consensus nodes reaches a set number of blocks, performing dynamic replacement; otherwise, ending the consensus process. According to the invention, the rotation system of the execution nodes in the consensus mechanism is realized, and the possibility of collusion attack of a plurality of consensus nodes is effectively reduced, so that the security of the consensus mechanism is enhanced.

Description

Technical Field

[0001] The present application relates to the fields of three-dimensional transportation networks and blockchain technology, and in particular to a method for establishing consensus in a blockchain system for a three-dimensional transportation network. Background Art

[0002] Blockchain is a distributed ledger technology that uses decentralized data storage to reduce the risk of single points of failure and improve data security and stability. Blockchain is tamper-proof; once information is recorded on the blockchain, it cannot be altered, thus ensuring the authenticity and integrity of the data. The introduction of blockchain technology can effectively enhance the security and protection of air traffic data. Leveraging blockchain's immutability, the authenticity and integrity of all data records within the multi-dimensional transportation system (such as flight logs and route data) can be ensured, preventing data tampering. Blockchain encryption technology allows for the secure transmission of sensitive information within the air traffic system, such as flight control data and passenger information, preventing interception or tampering during transmission. Furthermore, the decentralized nature of blockchain enhances the resilience of air traffic data management systems, ensuring that even if a single system node is attacked, the overall system operation will not be impacted. In short, for multi-dimensional transportation systems with stringent security requirements, the use of blockchain as a security support technology for their service systems is highly valuable.

[0003] However, blockchain consensus mechanisms for multi-dimensional transportation systems are mostly based on classic Byzantine fault-tolerant consensus mechanisms. To maintain the security and liveness of the entire blockchain system, these consensus mechanisms require frequent signaling interactions between all nodes in the network. However, in systems that require a large number of nodes to support a wide range of operations, this inevitably increases communication overhead, leading to increased transaction confirmation latency and decreased throughput, making it difficult to support scenarios with massive traffic participants. Summary of the Invention

[0004] The purpose of this application is to provide a blockchain system consensus establishment method for three-dimensional transportation networks, which can reduce the communication requirements during the consensus execution process, thereby optimizing performance indicators such as throughput and latency of the blockchain system, and ensuring the stability and efficient operation of three-dimensional transportation applications.

[0005] To achieve the above objectives, this application provides the following solutions:

[0006] In the first aspect, this application provides a blockchain system consensus establishment method for a three-dimensional transportation network, including:

[0007] A blockchain system for a three-dimensional transportation network is obtained; the blockchain system includes a plurality of nodes.

[0008] The nodes in the blockchain system are divided into consensus nodes and verification nodes.

[0009] According to the transaction initiated by the client in the blockchain system, the consensus node is controlled to execute the consensus algorithm normal protocol to obtain the main node failure result; the consensus algorithm in the consensus algorithm normal protocol works in the form of a view; the consensus node corresponding to the view is set as the main node, and the remaining consensus nodes are set as backup nodes; the normal protocol in the consensus algorithm normal protocol works in the form of a message type.

[0010] If the master node fails, view switching is performed based on the consensus node to update the master node, and the calculation of the master node failure result is performed based on the updated master node.

[0011] If the master node does not fail, the blockchain system is controlled to confirm the transaction initiated by the client through the normal protocol of the consensus algorithm and package the transaction into a new block.

[0012] A tree-like broadcast strategy is adopted to synchronize the new block to the verification node, and determine whether the consensus node corresponding to the new block has generated a set number of blocks.

[0013] If so, the consensus node is dynamically replaced.

[0014] If not, the blockchain system consensus establishment ends.

[0015] According to the specific embodiments provided in this application, this application discloses the following technical effects:

[0016] This application provides a consensus-building method for a blockchain system for a three-dimensional transportation network. To reduce communication requirements during the consensus process and thereby optimize performance metrics such as throughput and latency, this method employs the following measures: Nodes in the blockchain system are divided into consensus nodes and validation nodes to reduce the number of nodes involved in the consensus process, thereby reducing communication volume. Consensus nodes implement a view switching mechanism when executing the consensus algorithm's normal protocol. Within each view, one consensus node is designated as the master node, and the remaining consensus nodes serve as backup nodes. When the master node fails, the master node is updated through view switching, and the master node failure results are recalculated based on the new master node. This ensures that the system remains responsive despite master node failures. If the master node is not faulty, client-initiated transactions are confirmed and packaged into new blocks. A tree-like broadcast strategy is used to synchronize new blocks to validation nodes, effectively reducing redundant communication during the broadcast process. After synchronizing a new block, a determination is made as to whether the consensus node has generated a set number of blocks. If the set number of blocks has been reached, the consensus nodes are dynamically replaced to maintain system viability and efficiency. Through the above measures, the communication requirements during the consensus execution process can be effectively reduced, thereby optimizing the performance indicators of the blockchain system such as throughput and latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction is given below to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 This is a flow chart of a method for establishing consensus in a blockchain system for a three-dimensional transportation network in one embodiment of the present application.

[0019] Figure 2 A flowchart of a blockchain system consensus establishment method provided in one embodiment of the present application.

[0020] Figure 3 A schematic diagram of a consensus node replacement method provided in one embodiment of the present application. DETAILED DESCRIPTION

[0021] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0022] In modern urban transportation systems, with ground traffic congestion becoming increasingly severe, three-dimensional transportation systems featuring integrated air and ground transportation have begun to attract widespread attention. Compared to ground transportation, three-dimensional transportation utilizes aircraft such as drones and air taxis to transport people and goods within urban spaces. By opening up new transportation routes above cities, three-dimensional transportation can effectively alleviate the pressure on ground transportation and improve urban transportation efficiency. It is characterized by high efficiency, flexibility, and scalability.

[0023] With the development of multi-dimensional transportation systems, data security has become a critical issue. Multi-dimensional transportation systems rely on vast amounts of real-time data to ensure operational safety and efficiency, including aircraft positioning data, route information, and weather data. The security of this data is directly linked to the safety and reliability of transportation services. Therefore, ensuring data security and preventing unauthorized tampering or theft are crucial challenges that multi-dimensional transportation systems must address.

[0024] The purpose of this application is to provide a blockchain system consensus establishment method for three-dimensional transportation networks, which can reduce the communication requirements during the consensus execution process, thereby optimizing the throughput and latency of the blockchain system and ensuring the stability and efficient operation of three-dimensional transportation applications.

[0025] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0026] Example 1

[0027] like Figure 1 As shown, this embodiment provides a blockchain system consensus establishment method for a three-dimensional transportation network, including:

[0028] Step 101: Obtain a blockchain system for a three-dimensional transportation network; the blockchain system includes several nodes.

[0029] Step 102: Divide the nodes in the blockchain system to obtain consensus nodes and verification nodes.

[0030] Step 103: Based on the transaction initiated by the client in the blockchain system, the consensus node is controlled to execute the consensus algorithm normal protocol to obtain the master node failure result; the consensus algorithm in the consensus algorithm normal protocol works in the form of a view; the consensus node corresponding to the view is set as the master node in the view, and the remaining consensus nodes are set as backup nodes; the normal protocol in the consensus algorithm normal protocol works in the form of a message type.

[0031] If the master node fails, view switching is performed based on the consensus node to update the master node, and the calculation of the master node failure result is performed based on the updated master node.

[0032] If the master node does not fail, the blockchain system is controlled to confirm the transaction initiated by the client through the normal protocol of the consensus algorithm and package the transaction into a new block.

[0033] Step 104: Synchronize the new block to the verification node using a tree-like broadcast strategy, and determine whether the consensus node corresponding to the new block has generated a set number of blocks.

[0034] If so, the consensus node is dynamically replaced.

[0035] If not, the blockchain system consensus establishment ends.

[0036] In some embodiments, when executing steps 101-102, the specific steps may be as follows:

[0037] like Figure 2 As shown, a blockchain system for a three-dimensional transportation network is obtained; the blockchain system includes several nodes, and specifically, the parameters of the blockchain system are initialized.

[0038] Obtaining the ID of each node in the blockchain system; sorting the nodes according to the ID of each node to obtain a node sequence; determining the first n nodes in the node sequence as consensus nodes, and determining the remaining nodes in the node sequence as verification nodes; n is less than the total number of nodes.

[0039] Specifically, let m be the total number of nodes in the system. During system initialization, the parameters set include the number of consensus nodes, n, and the period, k. This information is initialized into the system configuration table. The parameter k means that the consensus node will be replaced every time a maximum of k blocks are released. At the same time, the IDs of all nodes (a binary string with a fixed number of bytes) are sorted, and the corresponding sorting position (1, 2, ..., m) of the node is used as the corresponding node number. When the system first starts running, nodes numbered 1 to n participate in the execution of the consensus algorithm. Other nodes serve as verification nodes and do not participate in the consensus process, but instead synchronize new blocks released by the consensus nodes.

[0040] In some embodiments, when executing step 103, the specific steps may be as follows:

[0041] 1) The consensus nodes in the control system execute the Byzantine fault-tolerant consensus algorithm. Assume the number of malicious nodes is f. According to the Byzantine fault tolerance model theory, the system can tolerate Byzantine faults when f is less than one-third of n. Let n = 3f + 1.

[0042] 2) The consensus algorithm works in the form of views. Views are represented in the protocol as increasing natural numbers. Each view corresponds to a consensus node as the primary node, and the remaining consensus nodes as backup nodes.

[0043] 3) In the normal protocol, the following message types may appear in total.

[0044] I. Pre-prepare message. Broadcast by the master node, it includes the view value, transaction information, and the proof required to verify the validity of the transaction.

[0045] II. Prepare message. The content includes view value and transaction information (represented by the transaction hash value).

[0046] III. Commit message. The content includes the view value and transaction information (represented by the transaction hash value).

[0047] 4) The normal protocol process is as follows:

[0048] I. After the leader node in the current view receives a transaction from the client, it creates a pre-prepare message and assigns it a unique sequence number. The leader node broadcasts this pre-prepare message to all replica nodes. This sequence number ensures that all nodes agree on the order in which transactions are processed. After receiving the pre-prepare message, the replica node verifies its legitimacy. Once verification is successful, the replica node enters the prepare phase and broadcasts the prepare message to all nodes (including itself and the leader node).

[0049] II. When a node receives prepare messages with the same sequence number and transaction from 2f+1 different nodes (including itself), the node considers the transaction to be prepared at that sequence number.

[0050] III. After the preparation phase completes, the node enters the commit phase, broadcasting a commit message to all nodes. Similar to the preparation phase, when a node receives commit messages with the same sequence number and transaction from 2f+1 different nodes, it considers the transaction committed at that sequence number. During this phase, each node executes the transaction and saves the results in its local log.

[0051] IV. Once a transaction is executed, the node sends a reply message containing the execution result to the client. The client waits for f+1 identical replies from different nodes (because there is a possibility of f malicious nodes, f+1 identical replies ensure the correct result). Once the client receives a sufficient number of consistent replies, the transaction is considered complete.

[0052] Validation nodes are responsible for synchronizing consensus results. Validation nodes, which make up the majority of nodes in the system, do not participate in consensus but instead synchronize new blocks from the consensus nodes. New blocks are propagated using a tree-like broadcast strategy, which distributes validation nodes to each consensus node and constructs a ternary tree with the consensus node as the vertex. After a consensus node reaches consensus on a new block, it prioritizes sending the latest block to its child validation nodes. After synchronizing the latest block, the child validation nodes prioritize sending the latest block status to their own child nodes, and so on. Because each node prioritizes sending the latest block status to its child nodes, and child nodes prioritize synchronizing the latest block to their parent nodes, the network bandwidth used for block synchronization is fixed and independent of the total number of nodes in the blockchain system, thus ensuring scalability.

[0053] When executing the view switching in step 103, the specific steps may be as follows:

[0054] 1) When a master node fails in a consensus node, a view switching process must be initiated within the consensus node to replace the master node, allowing the consensus node to continue executing consensus on new transactions. View switching consists of a view switching trigger protocol and a view switching protocol, which are used to update the master node. The message types involved are as follows:

[0055] I. Complain message. This message exists in the view switching trigger protocol and is broadcast by the backup node that discovers an abnormality in the primary node. The content is the view value corresponding to the abnormal primary node.

[0056] II. View-change message. This message exists in the view-switch triggering protocol and is broadcast by the next view's master node. It contains the value of the next view and a view-change-proof verifying that the view switch actually occurred.

[0057] III. ACK message. This message exists in the view switching protocol and is sent by the backup node to the master node of the next view. It contains the value of the next view, transaction information, the view value at the exchange, and a prepare-proof verifying the validity of the transaction.

[0058] 2) The view switching trigger protocol is as follows:

[0059] Determine whether the master node has failed to complete a client transaction, sent an invalid message, or encountered a sequence number conflict within a set time; if so, record a complaint event (which can be called a complaint message) on the master node; determine the update status of the master node based on the total number of complaint events that occurred on the master node in each view state and the number of occurrences threshold; the update status includes updated and not updated.

[0060] Specifically, in the view switching trigger protocol, each node maintains a timer to determine the status of the current master node. If a node discovers that the master node is behaving abnormally (such as failing to complete the processing of client transactions within the scheduled time, sending invalid messages, or sequence number conflicts, etc.), it is considered that the master node may be invalid or have problems. Once the node discovers the anomaly, it broadcasts a complaint message to other nodes and enters the next view. When the master node of the next view has received a total of f+1 complaint messages, it will initiate a view switch, stop all activities in the current view, enter the next view, and use these f+1 complaint messages as view-change-proofs attached to the view-change message packet, and then broadcast the view-change packet to other nodes. The system then executes the view switching protocol.

[0061] 3) In the view switch protocol, when other nodes receive a view-change packet from the updated master, they first verify whether the view-change-proof consists of f+1 valid complain messages. If this verification succeeds, and the node's current view is less than the updated master's view, the node ceases participating in all protocols with the old view and checks whether it has received at least 2f+1 prepare packets for a transaction. If so, it adds the latest transaction, the view it currently holds, and the prepare-proof for that transaction (combined from the 2f+1 prepare messages for that transaction) into an ack message and sends it back to the updated master. If not, it adds an empty proof (i.e., an empty-proof) to the ack and sends it back to the updated master. After sending the ack, the node enters the normal protocol, awaiting pre-prepare messages from the updated master. After the updated master has received 2f+1 ack packets, it packages all ack messages into an ack-proof and verifies it. If all ack packets carry empty proofs, the updated master node selects a new transaction and places it in the pre-prepare packet, using the ack proof as proof and broadcasting the pre-prepare packet about the new transaction. Otherwise, it selects the transaction with the highest view number from the ack proofs and places it in the pre-prepare packet, using the ack proof as proof and broadcasting the pre-prepare packet about this transaction. After receiving the pre-prepare packet, other nodes need to verify whether the transaction violates the proof in the ack proof. If so, a view switch is triggered.

[0062] The dynamic replacement of consensus nodes is as follows:

[0063] like Figure 3 As shown in the figure, to ensure system security, after every k blocks are produced, a node is removed from the consensus node list and converted into a verification node. Then, one of the original verification nodes is selected and added to the consensus node list. This replacement is done in a rotational manner, with nodes entering and leaving in order of node number. That is, after a node in the current consensus node list produces k blocks, the oldest consensus node in the list is removed, and a node is selected to join the list, with the node number following the node number of the newest node in the list (the number following m returns to number 1).

[0064] In summary, compared with the prior art, the present application has the following advantages:

[0065] 1) This application divides blockchain nodes into consensus nodes and validation nodes, decoupling the consensus mechanism's communication complexity from node scale and avoiding the quadratic growth of consensus messages at large node scales. This consensus mechanism significantly improves the scalability of blockchain systems, providing higher transaction throughput and lower transaction confirmation latency for large-scale, multi-dimensional transportation applications.

[0066] 2) This application designs a periodic replacement scheme for consensus nodes in a blockchain system. After a group of consensus nodes has produced a certain number of blocks, a verification node, based on the node number, will take over as the new consensus node. This scheme allows for a rotation of nodes that actually execute the consensus mechanism, reducing the risk of collusion attacks by multiple consensus nodes and improving the security of the consensus mechanism.

[0067] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0068] This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core concept of this application. At the same time, for those skilled in the art, based on the concept of this application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A blockchain system consensus building method for a three-dimensional transportation network, characterized in that: include: Obtaining a blockchain system for a three-dimensional transportation network; the blockchain system includes a plurality of nodes; Dividing the nodes in the blockchain system into consensus nodes and verification nodes; According to the transaction initiated by the client in the blockchain system, the consensus node is controlled to execute the normal protocol of the consensus algorithm to obtain the result of the master node failure; The consensus algorithm in the consensus algorithm normal protocol works in the form of a view; the consensus node corresponding to the view is set as the master node, and the remaining consensus nodes are set as backup nodes; the normal protocol in the consensus algorithm normal protocol works in the form of a message type; If the master node fails, view switching is performed based on the consensus node to update the master node, and the calculation of the master node failure result is performed based on the updated master node; If the master node is not faulty, the blockchain system is controlled to confirm the transaction initiated by the client through the normal protocol of the consensus algorithm and package the transaction into a new block; Adopting a tree-like broadcast strategy, the new block is synchronized to the verification node, and it is determined whether the consensus node corresponding to the new block has generated a set number of blocks; If so, dynamically replace the consensus node; If not, the blockchain system consensus establishment ends.

2. A blockchain system consensus building method for a three-dimensional transportation network according to claim 1, characterized in that: The nodes in the blockchain system are divided into consensus nodes and verification nodes, specifically including: Obtain the ID of each node in the blockchain system; Sort each node according to its ID to obtain a node sequence; The first n nodes in the node sequence are determined as consensus nodes, and the remaining nodes in the node sequence are determined as verification nodes; n is less than the total number of nodes.

3. The method for establishing consensus in a blockchain system for a three-dimensional transportation network according to claim 1, characterized in that: The consensus algorithm is a Byzantine fault-tolerant consensus algorithm.

4. The method for establishing consensus in a blockchain system for a three-dimensional transportation network according to claim 1, characterized in that: The message types include pre-prepare message, prepare message and commit message.

5. The method for establishing consensus in a blockchain system for a three-dimensional transportation network according to claim 2, characterized in that: Dynamically replace the consensus node, specifically including: Set the last consensus node among all consensus nodes as a verification node; The first-ranked verification node among all verification nodes is set as the consensus node.

6. The method for establishing consensus in a blockchain system for a three-dimensional transportation network according to claim 1, characterized in that: Perform view switching based on the consensus node to update the master node, specifically including: The master node is updated based on the view switching trigger protocol and the view switching protocol.

7. A blockchain system consensus building method for a three-dimensional transportation network according to claim 6, characterized in that: The view switching triggering protocol specifically includes: Determine whether the master node has failed to complete a client transaction, sent an invalid message, or encountered a sequence number conflict within the set time; If it happens, a complaint event will be recorded for the master node; According to the total number of complain events occurring on the master node in each view state, based on a threshold of the number of occurrences, the update state of the master node is determined; the update state includes update and non-update.

8. The method for establishing consensus in a blockchain system for a three-dimensional transportation network according to claim 6, characterized in that: The view switching protocol specifically includes: Determine whether other consensus nodes except the master node have received the updated view-change package of the master node; For each consensus node other than the master node, when receiving the updated view-change packet from the master node, it determines whether there are f+1 valid complain events in the view-change packet; where f is the occurrence threshold; If so, the consensus node is controlled to stop the normal protocol of the consensus algorithm and determine whether the consensus node has received at least 2f+1 prepare packets; If the consensus node has received at least 2f+1 prepare packets, it puts the information in the prepare packet into an ack message packet and sends it to the updated master node; If the consensus node has not received at least 2f+1 prepare packets, it puts an empty-proof in the ack message packet and sends it to the updated master node; When the updated master node receives a total of 2f+1 ack message packets, it packages all ack messages into ack-proof and checks them; If all ack packets contain empty-proof, the updated master node will be controlled to select the new transaction and put it into the pre-prepare packet; If all ack packets contain the information in the prepare packet, the transaction with the highest view number is selected from the ack-proof and placed in the pre-prepare packet; When other consensus nodes except the master node receive the pre-prepare package, they verify whether the transaction violates the proof in the ack-proof; If violated, a view switch is triggered.

Images