A blockchain network fork control method based on delayed broadcasting

Abstract

The application relates to the technical field of blockchains, in particular to a blockchain network bifurcation control method based on delay broadcasting, which comprises the following steps: comparing the block height of a new block with the block height of the latest historical block in a real-time optimal block list; if the block height of the new block is greater than the block height of the latest historical block in the real-time optimal block list, analyzing whether the parent block of the new block is in the real-time optimal block list; if the parent block of the new block is in the real-time optimal block list, analyzing whether the parent block of the new block is the latest historical block in the real-time optimal block list; if the parent block of the new block is the latest historical block in the real-time optimal block list, inserting the new block into the real-time optimal block list; if the parent block of the new block is not the latest historical block in the real-time optimal block list, replacing the historical block with the same block height as the new block in the real-time optimal block list with the new block when the priority of the new block is higher than the priority of the historical block with the same block height as the new block in the real-time optimal block list. By adopting the scheme, the blockchain network bifurcation can be prevented, and the security of the network is improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain network fork control method based on delayed broadcasting. Background Technology

[0002] As a distributed database technology, blockchain has received widespread attention and application in recent years. Its decentralized, immutable, and traceable characteristics have brought significant impacts to fields such as digital currency, smart contracts, supply chain management, and copyright protection, and it is regarded as one of the important infrastructures for building the future digital society.

[0003] In the retail industry, for example, a large supermarket chain uses blockchain technology provided by IBM to track its food supply chain, improving food safety and transparency. Through blockchain, the supermarket can record every transaction with every supplier, achieving end-to-end digital tracking, thereby enhancing brand trust and improving food safety management. In the civil aviation sector, blockchain technology is also used for end-to-end baggage tracking, breaking down information barriers between airports, airlines, and regulatory agencies, accelerating data flow and information sharing, improving processing efficiency, effectively reducing baggage error rates, and enhancing the accuracy and timeliness of baggage transportation.

[0004] The core of blockchain lies in its consensus mechanism, a key technology ensuring data consistency among all network nodes and helping to prevent security issues such as double-spending attacks. However, while consensus mechanisms offer a degree of security, they also have limitations. For example, Proof-of-Work (PoW) mechanisms have attracted attention due to their high energy consumption and relatively low efficiency, and there is a risk of network centralization, as nodes with more computing power are more likely to control the network. On the other hand, while Proof-of-Stake (PoS) mechanisms aim to reduce energy consumption, their security still needs further verification, such as the risk of stake pool attacks, where attackers can influence network consensus by controlling a large number of tokens.

[0005] In peer-to-peer (P2P) networks, due to factors such as network latency, different nodes may receive blocks in different orders, leading to blockchain forks. Forks reduce network efficiency and security and can potentially cause double-spending attacks. To address fork issues, existing blockchain systems typically employ block confirmation and the longest chain rule. Block confirmation improves transaction security by requiring a certain number of block confirmations, but this also prolongs transaction confirmation time and reduces network efficiency. The longest chain rule resolves forks by selecting the longest chain as the main chain, but it is vulnerable to 51% attacks and still presents security risks.

[0006] In conclusion, while blockchain technology has demonstrated application potential in multiple fields, it still faces significant security challenges. Therefore, there is an urgent need to provide a blockchain network fork control method that can prevent blockchain network forks and thus improve network security. Summary of the Invention

[0007] This invention provides a blockchain network fork control method based on delayed broadcasting, which can prevent blockchain network forks and improve network security.

[0008] To achieve the above objectives, this application provides the following technical solution:

[0009] A blockchain network fork control method based on delayed broadcasting includes the following steps:

[0010] S100 retrieves new blocks from the blockchain network and stores them in the list of processed blocks;

[0011] S200, Obtain the real-time optimal block list, which stores several sorted historical blocks;

[0012] S300: Compare the block height of the new block with the block height of the latest historical block in the real-time optimal block list, and generate the block height comparison result;

[0013] S400: If the block height comparison result shows that the block height of the new block is greater than the block height of the latest historical block in the real-time optimal block list, then analyze whether the parent block of the new block is in the real-time optimal block list. If so, jump to S500.

[0014] S500: Analyze whether the parent block of the new block is the latest historical block in the real-time best block list. If so, insert the new block into the real-time best block list and update the real-time best block list. If not, analyze the priority of the new block and the priority of the historical block in the real-time best block list that is highly consistent with the new block, and jump to S600.

[0015] S600: Analyze whether the priority of the new block is higher than the priority of the historical block in the real-time best block list that has the same block height as the new block. If so, replace the historical block in the real-time best block list that has the same block height as the new block with the new block, and update the real-time best block list.

[0016] Furthermore, S400 also includes: analyzing whether the parent block of the new block is in the real-time optimal block list; if so, verifying the new block and jumping to S500 after successful verification.

[0017] Furthermore, the verification includes one or more of the following: structural verification, hash value verification, and connectivity verification.

[0018] Furthermore, in S400, it analyzes whether the parent block of the new block is in the real-time optimal block list. If not, it analyzes whether the parent block of the new block is in the processed block list.

[0019] If the parent block of the new block is not in the list of processed blocks, the new block is set as a secondary new block and transmitted to the secondary block processing module for block processing.

[0020] Furthermore, the block processing flow of the secondary block processing module includes the following steps:

[0021] S1. Based on the time when the secondary block processing module receives the new secondary block, after extending the corresponding waiting time, obtain the real-time optimal block list.

[0022] S2, compare the block height of the new secondary block with the block height of the latest historical block in the real-time optimal block list, and generate the secondary block height comparison result;

[0023] S3. If the secondary block height comparison result shows that the block height of the new secondary block is greater than the block height of the latest historical block in the real-time optimal block list, then analyze whether the parent block of the new secondary block is in the real-time optimal block list. If so, jump to S4.

[0024] S4. Analyze whether the parent block of the new secondary block is the latest historical block in the real-time best block list. If so, insert the new secondary block into the real-time best block list and update the real-time best block list. If not, analyze the priority of the new secondary block and the priority of the historical blocks in the real-time best block list that are highly consistent with the new secondary block, and jump to S5.

[0025] S5. Analyze whether the priority of the new secondary block is higher than the priority of the historical block in the real-time best block list that has the same block height as the new secondary block. If so, replace the historical block in the real-time best block list that has the same block height as the new secondary block with the new secondary block, and update the real-time best block list.

[0026] The principles and advantages of this invention are as follows:

[0027] This proposal presents a delayed broadcast-based blockchain network fork control method to address the transient fork problem in existing blockchain technologies. By analyzing and sorting newly added blocks, transient forks caused by broadcasting are avoided, thus ensuring blockchain consistency. This method not only improves system stability and reliability but also ensures that all nodes receive all blocks at the same height, guaranteeing fairness in block selection. First, this scheme obtains a real-time optimal block list and compares it with the new block to determine whether the new block should be inserted into the real-time optimal block list. This comparison process effectively avoids transient forks caused by broadcasting, thereby improving system stability and reliability. Second, this scheme also verifies the new block, including structural verification, hash value verification, and connectivity verification. These verifications further improve system reliability and security, preventing malicious attackers from disrupting the normal operation of the system by forging new blocks. Finally, this scheme simplifies the consensus process. Nodes only need to focus on the blocks in the optimal block list and select the best block according to certain rules. This reduces the complexity of node participation, making the consensus process more efficient. Each node has the opportunity to propose the next block, preventing certain nodes from gaining more influence due to network advantages.

[0028] In summary, this scheme avoids temporary forks caused by broadcasting, thus improving the stability and reliability of the system; it ensures that all nodes can receive all blocks at the same height, guaranteeing the fairness of block selection; it simplifies the consensus process, reduces the complexity of node participation, and makes the consensus process more efficient; and it improves the reliability and security of the system through the verification mechanism. Attached Figure Description

[0029] Figure 1 This is a flowchart illustrating an embodiment of a blockchain network fork control method based on delayed broadcasting according to the present invention.

[0030] Figure 2 This is a schematic diagram of the block buffer tree structure in an embodiment of a blockchain network fork control method based on delayed broadcasting according to the present invention. Detailed Implementation

[0031] The following detailed description illustrates the specific implementation method:

[0032] Example 1:

[0033] like Figure 2As shown, this scheme provides a blockchain network fork control method based on delayed broadcasting by using a tree-structured block buffer tree. Each node in the blockchain network appends the new block it receives to the delayed buffer, and selects the best block to pop after the delayed buffer reaches a preset height. This effectively reduces forks in the blockchain network, improves the network's synchronization and efficiency, and optimizes the data processing and transmission performance of the entire network.

[0034] Specifically, the blockchain network fork control method based on delayed broadcasting includes the following:

[0035] First, nodes are added to the blockchain network. A new node choosing to join selects a seed node, sends a synchronization request to it, and retrieves historical blocks from that seed node. Next, the new node verifies the correctness of the historical blocks, ensuring they haven't been tampered with and adhere to the blockchain's consensus rules. Finally, the new node adds itself to the list of known nodes so that other nodes can discover and connect to it, thereby expanding the scale and connectivity of the blockchain network.

[0036] Secondly, time synchronization is achieved. Each node in the blockchain network continuously requests clock synchronization from neighboring nodes via NTP (Network Time Protocol) to synchronize the clocks between nodes, ensuring the consistency of timestamps in the P2P network, thereby ensuring that all nodes use the same time base when recording transactions and generating blocks.

[0037] Thus, new nodes can successfully join the blockchain network and communicate and collaborate with other nodes in the network.

[0038] To implement the above methods, a block buffer also needs to be constructed. After receiving new blocks from the blockchain network, nodes append these new blocks to the block buffer according to a specific sorting standard. In the block buffer, each new block is appended to its parent block, and the block's timestamps and transaction count form a tuple.<timestamps,count> This serves as the sorting criterion for blocks. Based on tuples.<timestamps,count> Blocks with the same preceding block are compared. Blocks with smaller timestamps and more transactions have higher priority. For any two blocks a and b, their priority is ranked according to the following formula:

[0039]

[0040] In the formula, timestamps a For the timestamp of block a, timestamps b For the timestamp of block b, counta The count is the number of transactions in block a. b The transaction count for block b.

[0041] In other words, the priority comparison method is as follows: When comparing the priorities of any two blocks, 'a' and 'b', the timestamps are compared first. If the timestamp of block 'a' is less than the timestamp of block 'b', then block 'a' has a higher priority. If the timestamp of block 'a' is equal to the timestamp of block 'b', then the transaction counts are compared. If the transaction count of block 'a' is greater than or equal to the transaction count of block 'b', then block 'a' has a higher priority. Through these steps, nodes can effectively manage and select the optimal block, ensuring the security and stability of the blockchain network.

[0042] When a new block is added to the buffer, it is processed using two separate processing flows (flow 1 and flow 2) and processing queues (queue 1 and queue 2). Blocks retrieved from the network are first placed in queue 1 and processed by flow 1.

[0043] like Figure 1 As shown, the process of processing the currently retrieved block in process 1 is as follows:

[0044] S100: Obtain a new block from the blockchain network and store it in the list of processed blocks. In this embodiment, the new block is sent to the buffer by each node in the blockchain network.

[0045] S200, Obtain the real-time optimal block list, which stores several sorted historical blocks. Specifically, each historical block is sorted according to the above priority comparison method, and the same real-time optimal block list is used when processing in process 1 and process 2. After processing, new blocks that should be added to the real-time optimal block list are also added to the same real-time optimal block list.

[0046] S300 compares the block height of the new block with the block height of the latest historical block in the real-time optimal block list and generates a block height comparison result.

[0047] In step S400, if the block height comparison result shows that the new block's block height is greater than the latest historical block height in the real-time optimal block list, then it analyzes whether the new block's parent block is in the real-time optimal block list. If so, the new block is verified, and after successful verification, the process jumps to S500. If not, it analyzes whether the new block's parent block is in the processed block list. If the new block's parent block is not in the processed block list, the new block is set as a secondary new block and transmitted to the secondary block processing module for block processing, i.e., placed in queue 2 for processing in process 2. If the new block's parent block is in the processed block list, it means that the parent block has been processed but its priority is insufficient. Similarly, the new block's priority is also insufficient, so the current process ends directly. This step ensures that the selected optimal blocks can form a chain.

[0048] The verification includes one or more of structural verification, hash value verification, and connectivity verification. In this embodiment, it includes hash value verification and connectivity verification.

[0049] In step S500, analyze whether the parent block of the new block is the latest historical block in the real-time optimal block list. If so, insert the new block into the real-time optimal block list and update the list; specifically, place the new block at the end of the list. If not, analyze the priority of the new block and the priority of historical blocks in the real-time optimal block list that have the same block height as the new block, and jump to step S600. If there is no historical block in the real-time optimal block list with the same height as the new block, directly place the new block at the end of the list and end the current processing.

[0050] S600: Analyze whether the priority of the new block is higher than the priority of the historical block with the same block height as the new block in the real-time best block list. If so, replace the historical block with the new block height in the real-time best block list with the new block, update the real-time best block list, and then set all blocks after the new block height in the real-time best block list to empty. Specifically, the priority comparison method described above is used.

[0051] While inserting a new block into the real-time best block list, it checks whether the height of the buffer has reached the upper limit. If it has, the following strategy is used:

[0052] If inserting a new block makes a historical block no longer the optimal block, then the corresponding block is removed from the buffer. Otherwise, the first historical block in the optimal block list is removed from the buffer and inserted into the local blockchain replica if they meet the blockchain continuity requirements.

[0053] Because of the existence of queue 2, all its successor blocks have been added to queue 2 before the new block is processed. Therefore, the successor priority block will be processed by process 2 and set into the real-time optimal block list.

[0054] The block processing flow of the secondary block processing module includes the following steps, that is, the process of processing the currently retrieved block in process 2 is as follows:

[0055] S1: Based on the time when the secondary block processing module receives the new secondary block, after extending the corresponding waiting time, obtain the real-time optimal block list. This step prevents the same block from being highly compared with the latest historical block in the completely identical real-time optimal block list during processing in both process 1 and process 2, thus avoiding an excessively high abandonment rate. The specific waiting time is adjusted according to actual needs; in this embodiment, the waiting time is 2 seconds.

[0056] S2 compares the block height of the new secondary block with the block height of the latest historical block in the real-time optimal block list, and generates the secondary block height comparison result.

[0057] S3. If the secondary block height comparison result shows that the block height of the new secondary block is greater than the block height of the latest historical block in the real-time optimal block list, then analyze whether the parent block of the new secondary block is in the real-time optimal block list. If so, jump to S4.

[0058] S4: Analyze whether the parent block of the new secondary block is the latest historical block in the real-time best block list. If so, insert the new secondary block into the real-time best block list and update the real-time best block list. If not, analyze the priority of the new secondary block and the priority of the historical blocks in the real-time best block list that are highly consistent with the new secondary block, and jump to S5.

[0059] S5. Analyze whether the priority of the new secondary block is higher than the priority of the historical block in the real-time best block list that has the same block height as the new secondary block. If so, replace the historical block in the real-time best block list that has the same block height as the new secondary block with the new secondary block, and update the real-time best block list.

[0060] If inserting a new block makes a historical block no longer the optimal block, then the corresponding block is removed from the buffer. Otherwise, the first historical block in the optimal block list is removed from the buffer and inserted into the local blockchain replica if they meet the blockchain continuity requirements.

[0061] The existence of the secondary block processing module, namely queue 2, can prevent excessive blocking of the main block processing queue 1 before a certain block arrives. Its processing flow is highly overlapping with that of process 1, and its specific processing method will not be elaborated here.

[0062] This scheme avoids temporary forks caused by broadcasting, improving system stability and reliability; ensures that all nodes can receive all blocks at the same height, guaranteeing fairness in block selection; simplifies the consensus process, reduces the complexity of node participation, and makes the consensus process more efficient; and improves system reliability and security through the verification mechanism.

[0063] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A blockchain network fork control method based on delayed broadcasting, characterized in that: The method comprises the following steps: S100, obtaining a new block from a blockchain network and storing the new block in a processed block list; S200, obtaining a real-time optimal block list in which a plurality of sorted historical blocks are stored; S300, comparing the block height of the new block with the block height of the latest historical block in the real-time optimal block list, and generating a block height comparison result; S400, if the block height comparison result is that the block height of the new block is greater than the block height of the latest historical block in the real-time optimal block list, analyzing whether the parent block of the new block is in the real-time optimal block list, and if yes, jumping to S500; S500, analyzing whether the parent block of the new block is the latest historical block in the real-time optimal block list, if yes, inserting the new block into the real-time optimal block list, and updating the real-time optimal block list, and if no, analyzing the priority of the new block and the priority of the historical block with the same block height as the new block in the real-time optimal block list, and jumping to S600; S600, analyzing whether the priority of the new block is higher than the priority of the historical block with the same block height as the new block in the real-time optimal block list, if yes, replacing the historical block with the same block height as the new block in the real-time optimal block list with the new block, and updating the real-time optimal block list. 2.The delay broadcast based blockchain network fork control method of claim 1, wherein: S400 further comprises: analyzing whether the parent block of the new block is in the real-time optimal block list, and if yes, verifying the new block, and jumping to S500 after the verification is passed. 3.The delay broadcast based blockchain network fork control method of claim 2, wherein: The verification comprises one or more of structural verification, hash value verification and connectivity verification. 4.The delay broadcast based blockchain network fork control method of claim 1, wherein: In S400, if the parent block of the new block is not in the real-time optimal block list, analyzing whether the parent block of the new block is in the processed block list; If the parent block of the new block is not in the processed block list, setting the new block as a secondary new block, and transmitting the secondary new block to a secondary block processing module for block processing. 5.The delay broadcast based blockchain network fork control method of claim 4, wherein: The block processing procedure of the secondary block processing module comprises the following steps: S1, according to the time when the secondary block processing module receives the secondary new block, obtaining a real-time optimal block list after prolonging a corresponding waiting time; S2, comparing the block height of the secondary new block with the block height of the latest historical block in the real-time optimal block list, and generating a secondary block height comparison result; S3, if the secondary block height comparison result is that the block height of the secondary new block is greater than the block height of the latest historical block in the real-time optimal block list, analyzing whether the parent block of the secondary new block is in the real-time optimal block list, and if yes, jumping to S4; S4, analyzing whether the parent block of the secondary new block is the latest historical block in the real-time optimal block list, if yes, inserting the secondary new block into the real-time optimal block list, and updating the real-time optimal block list, and if no, analyzing the priority of the secondary new block and the priority of the historical block with the same block height as the secondary new block in the real-time optimal block list, and jumping to S5; S5, analyzing whether the priority of the secondary new block is higher than the priority of the historical block with the same block height as the secondary new block in the real-time optimal block list, if yes, replacing the historical block with the same block height as the secondary new block in the real-time optimal block list with the secondary new block, and updating the real-time optimal block list. S5, analyze whether the priority of the secondary new block is higher than the priority of the historical block in the real-time optimal block list that is consistent with the block height of the secondary new block, if yes, replace the historical block in the real-time optimal block list that is consistent with the block height of the secondary new block with the secondary new block, and update the real-time optimal block list.

Images