Block chain network bifurcation control method based on delay broadcast

Abstract

The invention relates to the technical field of block chains, in particular to a block chain network bifurcation control method based on delay broadcast, which comprises the following steps: comparing the block height of a new block with the block height of a 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 a 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, and if yes, judging 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 if not, when the priority of the new block is higher than the priority of a historical block with the height consistent with that of the new block in the real-time optimal block list, replacing the historical block with the height consistent with that of the new block in the real-time optimal block list with the new block. By adopting the scheme, the block chain network branching can be prevented, so that the network security is improved.

Description

Technical Field

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

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

[0003] Taking the retail industry as an example, a large supermarket uses blockchain technology provided by IBM to track the food supply chain to improve food safety and transparency. Through blockchain, the large supermarket can record every transaction link of every supplier and realize full digital tracking, thereby enhancing brand trust and improving food safety management. In the field of civil aviation, blockchain technology is also used for full-process baggage tracking, breaking through the information barriers between airports, airlines and regulatory agencies, accelerating data flow and information sharing, improving the processing efficiency of business links, effectively reducing the baggage error rate, and improving the accuracy and punctuality of baggage transportation.

[0004] The core of blockchain lies in the consensus mechanism, which is a key technology to ensure data consistency among all network nodes, and also helps prevent security issues such as double-spending attacks. However, although consensus mechanisms provide security to a certain extent, they also have limitations. For example, the Proof of Work (PoW) mechanism has attracted attention due to its high energy consumption and relatively low efficiency, and there is a risk of network centralization, because nodes with more computing power are more likely to control the network. On the other hand, although the Proof of Stake (PoS) mechanism aims to reduce energy consumption, its security still needs to be further verified, such as the risk of equity pool attacks, that is, attackers influence network consensus by controlling a large number of tokens.

[0005] In a P2P network, due to factors such as network latency, different nodes may receive blocks in different orders, resulting in blockchain forks, which can also reduce the efficiency and security of the network and may lead to problems such as double-spending attacks. In order to solve the fork problem, existing blockchain systems usually adopt block confirmation and the longest chain rule. Block confirmation improves the security of transactions by requiring a certain number of block confirmations, but this also prolongs the transaction confirmation time and reduces the efficiency of the network. The longest chain rule solves the fork problem by selecting the longest chain as the main chain, but it is vulnerable to 51% attacks and still poses security risks.

[0006] In summary, blockchain technology has shown potential for application in many fields, but it still faces great security challenges. Therefore, there is an urgent need to provide a blockchain network fork control method that can prevent blockchain network forks to improve network security. Summary of the invention

[0007] The present invention provides a blockchain network fork control method based on delayed broadcast, which can prevent the blockchain network from forking and improve the security of the network.

[0008] In order to achieve the above objectives, this application provides the following technical solutions:

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

[0010] S100, obtaining a new block from the blockchain network and storing the new block in a processed block list;

[0011] S200, obtaining a real-time optimal block list, wherein the real-time optimal block list stores a number of sorted historical blocks;

[0012] 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;

[0013] 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, then analyze whether the parent block of the new block is in the real-time optimal block list, and if so, jump to S500;

[0014] S500, analyzing whether the parent block of the new block is the latest historical block in the real-time optimal block list. If so, inserting the new block into the real-time optimal block list and updating the real-time optimal block list. If not, analyzing the priority of the new block and the priority of the historical blocks in the real-time optimal block list that are consistent with the block height of the new block, and jumping to S600;

[0015] S600, analyzing whether the priority of the new block is higher than the priority of the historical block in the real-time optimal block list that is highly consistent with the new block. If so, replace the historical block in the real-time optimal block list that is highly consistent with the new block with the new block, and update the real-time optimal block list.

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

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

[0018] Further, in S400, it is analyzed whether the parent block of the new block is in the real-time optimal block list, and if not, it is analyzed 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 processed block list, the new block is set as a secondary new block, and the secondary new block is 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, according to the time when the secondary block processing module receives the secondary new block, after extending the corresponding waiting time, obtain the real-time optimal block list;

[0022] S2, compare 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 generate a secondary block height comparison result;

[0023] 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, then analyze whether the parent block of the secondary new block is in the real-time optimal block list, if so, jump to S4;

[0024] S4, analyzing whether the parent block of the secondary new block is the latest historical block in the real-time optimal block list. If so, inserting the secondary new block into the real-time optimal block list and updating the real-time optimal block list. If not, analyzing the priority of the secondary new block and the priority of the historical blocks in the real-time optimal block list that are consistent with the block height of the secondary new block, and jumping to S5;

[0025] S5, analyzing 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 highly consistent with the secondary new block. If so, replace the historical block in the real-time optimal block list that is highly consistent with the secondary new block with the secondary new block, and update the real-time optimal block list.

[0026] The principles and advantages of the present invention are:

[0027] This scheme proposes a blockchain network fork control method based on delayed broadcast, aiming to solve the problem of short-term forks in existing blockchain technology. By analyzing and sorting the newly added new blocks, short-term forks caused by broadcasting are avoided, thereby ensuring the consistency of the blockchain. This method not only improves the stability and reliability of the system, but also ensures that all nodes can receive all blocks at the same height, thereby ensuring the fairness of block selection. First, this scheme obtains the 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 can effectively avoid short-term forks caused by broadcasting, thereby improving the stability and reliability of the system. Secondly, this scheme also verifies the new block, including structure verification, hash value verification, and connectivity verification. These verifications can further improve the reliability and security of the system and prevent malicious attackers from disrupting the normal operation of the system by forging new blocks. Finally, this scheme also simplifies the consensus process. Nodes only need to pay attention to the blocks in the optimal block list and select the best block according to certain rules. This reduces the complexity of node participation and makes the consensus process more efficient. Each node has the opportunity to become the proposer of the next block, preventing some nodes from gaining more say due to network advantages.

[0028] In summary, this solution avoids short-term forks caused by broadcasting and improves the stability and reliability of the system; ensures that all nodes can receive all blocks at the same height, ensuring the fairness of block selection; simplifies the consensus process, reduces the complexity of node participation, and makes the consensus process more efficient; and improves the reliability and security of the system through the verification mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 The present invention is a flowchart of an embodiment of a blockchain network fork control method based on delayed broadcast.

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

[0031] The following is further described in detail through specific implementation methods:

[0032] Embodiment 1:

[0033] like Figure 2As shown, this scheme provides a blockchain network fork control method based on delayed broadcast with the help of a tree-structured block buffer tree. Each node in the blockchain network appends the received new block to the delay buffer, and selects the best block to pop up after the delay buffer reaches a preset height, thereby effectively reducing the fork phenomenon in the blockchain network and improving the synchronization and efficiency of the network, thereby optimizing the data processing and transmission performance of the entire network.

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

[0035] First, the node is added to the blockchain network. The new node that needs to join the blockchain network selects a seed node and sends a synchronization request to it to obtain the historical blocks from the seed node. The new node then verifies the correctness of the historical blocks to ensure that they have not been tampered with and follow the consensus rules of the blockchain. Finally, the new node adds itself to the list of known nodes so that other nodes can discover and connect to this new node, thereby expanding the scale and connectivity of the blockchain network.

[0036] Secondly, complete time synchronization. Each node in the blockchain network continuously requests clock synchronization from neighboring nodes through NTP (Network Time Protocol) to synchronize the clocks between nodes to ensure 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] As a result, new nodes can successfully join the blockchain network and communicate and collaborate with other nodes in the network.

[0038] To implement the above method, a block buffer needs to be built. After receiving new blocks from the blockchain network, the node appends 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 timestamp (timestamps) and transaction count (count) of the block form a tuple.<timestamps,count> , as the sorting criterion for blocks. Tuple-based<timestamps,count> Compare blocks with the same previous block. Blocks with smaller timestamps and more transactions have higher priority. For any two blocks a and b, their priority is sorted according to the following formula:

[0039]

[0040] In the formula, timestamps a Timestamps is the timestamp of block a. b is the timestamp of block b, counta Count is the transaction count of block a. b Transaction count for block b.

[0041] That is, the priority comparison method is as follows: When comparing the priorities of any two blocks a and b, first compare the timestamps. If the timestamp of block a is less than the timestamp of block b, block a has a higher priority. If the timestamp of block a is equal to the timestamp of block b, compare the transaction counts. If the transaction count of block a is greater than or equal to the transaction count of block b, block a has a higher priority. Through the above steps, nodes can effectively manage and select the optimal blocks to ensure the security and stability of the blockchain network.

[0042] When adding new blocks into the buffer, two separate processing flows (flow 1 and flow 2) and processing queues (queue 1 and queue 2) are used to process the blocks. Blocks obtained from the network are first put into queue 1 and processed by flow 1.

[0043] like Figure 1 As shown, the process 1 processes the currently retrieved block as follows:

[0044] S100, obtaining a new block from the blockchain network and storing the new block in the processed block list. In this embodiment, the new block is sent to the buffer by each node in the blockchain network.

[0045] S200, obtaining a real-time optimal block list, wherein the real-time optimal block list stores a number of sorted historical blocks. Specifically, each historical block is sorted according to the above-mentioned priority comparison method, and the same real-time optimal block list is applied during the processing of process 1 and process 2, and after the processing is completed, the new block that should be added to the real-time optimal block list is also added to the same real-time optimal block list.

[0046] 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.

[0047] 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, then analyze whether the parent block of the new block is in the real-time optimal block list. If so, verify the new block and jump to S500 after the verification is passed; if not, analyze 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, set the new block as a secondary new block, and transfer the secondary new block to the secondary block processing module for block processing, that is, put it into queue 2 and hand it over to process 2 for processing; if the parent block of the new block is in the processed block list, it means that the parent block has been processed but the priority is not enough, then similarly, the priority of the new block is not enough, so the current process is directly terminated. This step ensures that the selected optimal blocks can form a chain.

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

[0049] 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 real-time optimal block list. Specifically, put the new block at the end of the real-time optimal block list; if not, analyze the priority of the new block and the priority of the historical blocks in the real-time optimal block list that are consistent with the block height of the new block, and jump to S600. If there is no historical block in the real-time optimal block list that is highly consistent with the new block, directly put the new block at the end of the real-time optimal block list and end this processing.

[0050] S600, analyzing whether the priority of the 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 new block, if so, replacing the historical block in the real-time optimal block list that is consistent with the new block height with the new block, and updating the real-time optimal block list, and then setting all blocks after the height of the new block in the real-time optimal block list to empty. Specifically, the priority comparison method is used to compare the priorities.

[0051] When inserting a new block into the real-time optimal block list, it will determine whether the buffer height has reached the upper limit. If so, the following strategy will be used for processing:

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

[0053] Due to the existence of queue 2, all its successor blocks have been added to queue 2 before processing the above new block, so the subsequent priority blocks will be processed by process 2 and set to the real-time optimal block list.

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

[0055] S1, according to the time when the secondary block processing module receives the secondary new block, after extending the corresponding waiting time, obtain the real-time optimal block list. This step can prevent the same block from being highly compared with the latest historical block in the same real-time optimal block list when it is processed in process 1 and process 2, resulting in an excessively high abandonment rate. The specific waiting time is adjusted according to actual needs. In this embodiment, the waiting time is 2s.

[0056] S2, compares 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 generates a secondary block height comparison result.

[0057] 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, then analyze whether the parent block of the secondary new block is in the real-time optimal block list. If so, jump to S4.

[0058] S4, analyze whether the parent block of the secondary new block is the latest historical block in the real-time optimal block list. If so, insert the secondary new block into the real-time optimal block list and update the real-time optimal block list. If not, analyze the priority of the secondary new block and 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, and jump to S5.

[0059] S5, analyzing 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 highly consistent with the secondary new block. If so, replace the historical block in the real-time optimal block list that is highly consistent with the secondary new block with the secondary new block, and update the real-time optimal block list.

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

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

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

[0063] The above are only embodiments of the present invention. Common knowledge such as the known specific structures and characteristics in the scheme is not described in detail here. Ordinary technicians in the relevant field know all the common technical knowledge in the technical field to which the invention belongs before the application date or priority date, can obtain all the existing technologies in the field, and have the ability to apply conventional experimental means before that date. Ordinary technicians in the relevant field can improve and implement this scheme in combination with their own abilities under the enlightenment given by this application. Some typical known structures or known methods should not become obstacles for ordinary technicians in the relevant field to implement this application. It should be pointed out that for those skilled in the art, without departing from the structure of the present invention, several deformations and improvements can be made, which should also be regarded as the scope of protection of the present invention, and these will not affect the effect of the implementation of the present invention and the practicality of the patent. The scope of protection required by this application shall be based on the content of its claims, and the specific implementation methods and other records in the specification can be used to interpret the content of the claims.

Claims

1. A blockchain network fork control method based on delayed broadcast, characterized in that: The following steps are involved: S100, obtaining a new block from the blockchain network and storing the new block in a processed block list; S200, obtaining a real-time optimal block list, wherein the real-time optimal block list stores a number of sorted historical blocks; 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, then analyze whether the parent block of the new block is in the real-time optimal block list, and if so, jump 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 so, inserting the new block into the real-time optimal block list and updating the real-time optimal block list. If not, analyzing the priority of the new block and the priority of the historical blocks in the real-time optimal block list that are consistent with the block height of the new block, and jumping to S600; S600, analyzing whether the priority of the new block is higher than the priority of the historical block in the real-time optimal block list that is highly consistent with the new block. If so, replace the historical block in the real-time optimal block list that is highly consistent with the new block with the new block, and update the real-time optimal block list.

2. The blockchain network fork control method based on delayed broadcast according to claim 1 is characterized in that: S400 also includes: analyzing whether the parent block of the new block is in the real-time optimal block list, and if so, verifying the new block, and jumping to S500 after the verification is passed.

3. The blockchain network fork control method based on delayed broadcast according to claim 2 is characterized in that: The verification includes one or more of structure verification, hash value verification and connectivity verification.

4. The blockchain network fork control method based on delayed broadcast according to claim 1 is characterized in that: In S400, it is analyzed whether the parent block of the new block is in the real-time optimal block list, and if not, it is analyzed 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, the new block is set as a secondary new block, and the secondary new block is transmitted to the secondary block processing module for block processing.

5. The blockchain network fork control method based on delayed broadcast according to claim 1 is characterized in that: The block processing flow of the secondary block processing module includes the following steps: S1, according to the time when the secondary block processing module receives the secondary new block, after extending the corresponding waiting time, obtain the real-time optimal block list; S2, compare 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 generate 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, then analyze whether the parent block of the secondary new block is in the real-time optimal block list, if so, jump 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 so, inserting the secondary new block into the real-time optimal block list and updating the real-time optimal block list. If not, analyzing the priority of the secondary new block and the priority of the historical blocks in the real-time optimal block list that are consistent with the block height of the secondary new block, and jumping to S5; S5, analyzing 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 highly consistent with the secondary new block. If so, replace the historical block in the real-time optimal block list that is highly consistent with the secondary new block with the secondary new block, and update the real-time optimal block list.

Images