Method for constructing blockchain system based on directed acyclic graph and cuckoo filter

Abstract

The present invention relates to the field of blockchain technology, specifically a method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter, including the following steps: system startup, determining the service master node and reselecting the service master node; transaction generation and transmission to the service master node; when the service master node receives a large number of transactions, using the cuckoo filter to expand the single-chain structure into a directed acyclic graph; when the blockchain system has frequent transactions, recording transactions under the structure of the directed acyclic graph; when the blockchain system has infrequent transactions, converging the directed acyclic graph into a single-chain structure; the beneficial effects are as follows: the method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter proposed by the present invention; voting and rotation of the service master node are carried out based on the configuration, reducing the time and communication overhead spent by multiple master nodes competing for the master node when the service node crashes.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain, and specifically to a method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter. Background Art

[0002] A directed acyclic graph is a commonly used data structure in the computer field. Due to the excellent characteristics brought by its unique topological structure, it is often used in various algorithm scenarios such as dynamic programming, finding the shortest path in navigation, and data compression.

[0003] In the prior art, in the directed acyclic graph in the blockchain field, its constituent units are individual transactions. Each unit records the transaction of a single user, and the verification means depends on the verification of the previous transaction by the subsequent transaction; to conduct a transaction, it is necessary to verify the previous transactions, and specifically how many transactions to verify depends on different rules.

[0004] However, in the blockchain, data is stored among multiple parties, and the consensus algorithm is used to achieve the consistency of multi-node data. In the blockchain, data can only be appended and cannot be deleted or modified. The new blockchain is programmable, and business rules can be encoded into the blockchain using smart contracts. The rules (code) cannot be deleted or modified like data, and the code is automatically executed when called, cannot be skipped, and the execution results are also written into the blockchain. Since the data is stored among multiple parties, the data on the chain cannot be tampered with. Summary of the Invention

[0005] The purpose of the present invention is to provide a method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter to solve the problems raised in the above background art.

[0006] To achieve the above purpose, the present invention provides the following technical solution: A method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter, the blockchain system construction method includes the following steps:

[0007] S1. The system starts, determines the service master node and reselects the service master node;

[0008] S2. Transactions are generated and transmitted to the service master node;

[0009] S3. When the service master node receives a large number of transactions, it uses a cuckoo filter to expand the single-chain structure into a directed acyclic graph;

[0010] S4. When the transaction frequency is high in the blockchain system, transactions are recorded under the structure of the directed acyclic graph;

[0011] S5. When the transaction frequency is low in the blockchain system, the directed acyclic graph converges into a single-chain structure.

[0012] Preferably, the specific operations for system startup, determining the service master node, and reselecting the service master node are as follows:

[0013] S1.1 Each service node reads the same pre-generated initial block in the configuration; after sorting the addresses of all service nodes in the configuration, write them into the service node list ServeList in each service node's configuration. Suppose there are n service nodes written into this list, and let the current master node index i = 0;

[0014] S1.2 Each service node starts in a state without a service master node. After startup, by default, it takes the (i - 1)-th node in the ServeList[i] service node list as the standby service master node and sends a liveness probe request;

[0015] S1.3 The ServeList[i] node responds to the liveness probe request one by one and regularly broadcasts its own liveness heartbeat message;

[0016] S1.4 After the remaining service nodes receive the liveness probe response or the heartbeat message of ServeList[i], they broadcast the liveness confirmation message of ServeList[i];

[0017] S1.5 After the remaining nodes receive more than (n / 2) heartbeat messages or liveness confirmation messages from different sources regarding the current standby service master node ServeList[i], they set the current standby service master node as the service master node, and the master selection is completed; otherwise, execute step S1.7;

[0018] S1.6 If the remaining service nodes do not receive the heartbeat message of the service master node ServeList[i] within a certain period of time, they broadcast a re-election master request;

[0019] S1.7 The node that receives the re-election master request determines whether it has recently received the heartbeat message of the current service master node: if not, it sends a response agreeing to the re-election; otherwise, it sends a response rejecting the re-election;

[0020] S1.8 After the node receives more than (n / 2) re-election requests regarding ServeList[i] from different sources, it calculates i = (i + 1) mod n, takes ServeList[i] as the standby service master node, and sends a service node liveness probe request to it; and execute step S1.3.

[0021] Preferably, the specific operations from transaction generation to being transmitted to the service master node are as follows:

[0022] S2.1 The user generates a transaction through the client of the blockchain system and sends the transaction to the blockchain service node;

[0023] S2.2 The service node that receives the transaction determines whether it is the main service node itself.

[0024] Preferably, when the main service node receives a large number of transactions, the specific operation of using the cuckoo filter to expand the single-chain structure into a directed acyclic graph is as follows:

[0025] S3.1 If the main service node receives more than a certain number of transactions within one second, it extracts the transaction initiator of each transaction and sequentially queries whether the transaction initiator exists in the cuckoo filters in the cuckoo filter list;

[0026] S3.2 Through the query request in step S3.1, find the first cuckoo filter that satisfies the condition that the transaction initiator does not exist in this cuckoo filter; if there is no such cuckoo filter, create a new cuckoo filter and add it to the end of the cuckoo filter list as the cuckoo filter that meets the above conditions;

[0027] S3.3 Try to insert the transaction and the transaction initiator into the cuckoo filter found in step S3.2;

[0028] S3.4 If the cuckoo filter at the head of the cuckoo filter list is full, or the timer times out, divide the transactions according to the transaction initiators in the cuckoo filter, and then use multiple threads to pack the divided transactions into multiple blocks in parallel, and then distribute the blocks to other service nodes;

[0029] S3.5 After the main service node receives the distribution confirmation requests from more than half of the service nodes, link the blocks that are confirmed for distribution in a short time in parallel to the last newly generated block;

[0030] S3.6 The main service node deletes the corresponding transaction initiator from the cuckoo filter at the head of the cuckoo filter list for the confirmed distributed blocks. If the cuckoo filter becomes empty after deleting the transaction initiator, delete the cuckoo filter from its list, and let the next cuckoo filter become the element at the head of the new cuckoo filter list and start timing.

[0031] Preferably, in the case of frequent transactions in the blockchain system, the specific operation of recording transactions under the structure of a directed acyclic graph is as follows:

[0032] S4.1 For the second cuckoo filter in the cuckoo filter list, the main service node queries whether the transaction initiator exists in the first cuckoo filter in the cuckoo filter list;

[0033] S4.2 If it exists: then query the next transaction originator in the second cuckoo filter; otherwise, delete the transaction originator from the second cuckoo filter and add it to the first cuckoo filter in the cuckoo filter list until the capacity of the first cuckoo filter in the cuckoo filter list is full or the second cuckoo filter does not contain any transaction originators; and if the second cuckoo filter in the cuckoo filter list is empty during the deletion process, delete the empty cuckoo filter;

[0034] S4.3 After searching the second cuckoo filter in step S4.2 or the first cuckoo filter has reached the maximum capacity, the cuckoo filter list starts timing again;

[0035] S4.4 After the timer times out to the specified time, the service master node divides the transactions according to the unprocessed transaction originators in the first cuckoo filter of the cuckoo filter list, then uses multiple threads to parallelly package the divided transactions into multiple blocks, and then distributes the blocks to other service nodes;

[0036] S4.5 If the service master node receives distribution confirmation requests from more than half of the service nodes, then parallelly link the blocks confirmed for distribution in a short time to the most recently confirmed distributed block to expand the directed acyclic graph structure;

[0037] S4.6 Operate the cuckoo filters in the cuckoo filter list in the same way as in step S3.6.

[0038] Preferably, when the blockchain system has infrequent transactions, the specific operation of converging from a directed acyclic graph to a single-chain structure is as follows:

[0039] S5.1 If the service master node only receives a single transaction within one second, first query whether the transaction originator of the transaction exists in the cuckoo filter at the head of the cuckoo filter list: if it exists, then continue to query the next cuckoo filter list until a cuckoo filter that does not contain the transaction originator is found, add the transaction originator to the next cuckoo filter (create a new one if it does not exist) and continue to decide whether to execute step S3.1 or S5.1 according to the number of transactions received within one second; if the transaction originator is not queried, execute step S5.2;

[0040] S5.2 The service master node packages the transaction into a block and broadcasts the block to each service node. After obtaining the distribution confirmation from more than half of the service nodes, link the block behind the most recently confirmed distributed block, and converge the nodes of multiple directed acyclic graphs into the most recently confirmed block.

[0041] Compared with the prior art, the beneficial effects of the present invention are:

[0042] The method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter proposed by the present invention; voting and rotation of service master nodes are performed based on configuration, reducing the time and communication overhead spent by multiple master nodes competing for the master node when the service node crashes. Then, when the service master node receives a large number of transactions within a unit time, a cuckoo filter is newly created to filter the transactions according to the transaction initiator, ensuring that the transactions in a cuckoo filter do not conflict, and improving the concurrent transaction processing ability of the entire system by packing these non-conflicting transactions into blocks and distributing them in parallel through multi-threading. At the same time, subsequent transactions can also be linked to non-conflicting nodes of the directed acyclic graph in advance under the condition that some block distributions are not confirmed after passing through the cuckoo filter, avoiding continuous waiting due to the long processing time of individual transactions. This solution realizes the high concurrency and high performance of the blockchain system by reducing the competition overhead of service master nodes, filtering out non-conflicting transactions through the cuckoo filter when the transaction volume is large, and constructing a directed acyclic graph by generating blocks for non-conflicting transactions in parallel. Description of the Drawings

[0043] Figure 1 It is a flowchart of the method of the present invention;

[0044] Figure 2 It is an example diagram of the main service node processing transactions of the present invention. Detailed Embodiments

[0045] In order to clearly and completely describe the objectives, technical solutions of the present invention and make the advantages more clear, the following further details the embodiments of the present invention with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are some embodiments of the present invention, rather than all embodiments, and are only used to explain the embodiments of the present invention, not to limit the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0046] Embodiment 1

[0047] Please refer to Figures 1 to 2 , the present invention provides a technical solution: a method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter, the method for constructing the blockchain system includes the following steps:

[0048] S1. The system starts, determines the service master node and reselects the service master node;

[0049] S2. Transactions are generated and transmitted to the service master node;

[0050] S3. When the service master node receives a large number of transactions, it uses a cuckoo filter to expand the single-chain structure into a directed acyclic graph;

[0051] S4. When the blockchain system has frequent transactions, it records transactions in the structure of a directed acyclic graph;

[0052] S5. When the blockchain system has infrequent transactions, it converges from a directed acyclic graph into a single-chain structure.

[0053] Embodiment 2

[0054] Based on Embodiment 1, the specific implementation is as follows:

[0055] There is a service master node among the service nodes, and the service master node has an empty cuckoo filter list during initialization. The cuckoo filter list starts timing when a new cuckoo filter appears at the head of the list.

[0056] (1) Startup phase. In this phase, the processes of system startup, determining the service master node, and reselecting the service master node are mainly described.

[0057] 1.1 Each service node reads the same pre-generated initial block in the configuration; after sorting the addresses of all service nodes in the configuration, it writes them into the service node list ServeList in each service node's configuration. Suppose there are a total of n service nodes written into this list, and let the current master node index i = 0.

[0058] 1.2 Each service node starts in the state of having no service master node. After startup, it defaults to using ServeList[i] (the (i - 1)-th node in the service node list) as the preparatory service master node and sends a liveness probe request to it.

[0059] 1.3 The ServeList[i] node will respond to the liveness probe request one by one and regularly broadcast its own liveness heartbeat message.

[0060] 1.4 The remaining service nodes broadcast the liveness confirmation message of ServeList[i] after receiving the liveness probe response or the heartbeat message of ServeList[i].

[0061] 1.5 After the remaining nodes receive more than (n / 2) heartbeat messages or liveness confirmation messages from different sources regarding the current preparatory service master node ServeList[i], they set the current preparatory service master node as the service master node, and the master selection is completed; otherwise, step 1.7 is executed.

[0062] 1.6 If the remaining service nodes do not receive the heartbeat message of the service master node ServeList[i] within a certain period of time, they broadcast a re-election master request.

[0063] 1.7 The node that receives the re-election master request determines whether it has recently received a heartbeat message from the current serving master node: if not, it sends a response agreeing to the re-election; otherwise, it sends a response rejecting the re-election.

[0064] 1.8 After the node receives re-election requests for ServeList[i] from more than (n / 2) different sources, it calculates i = (i + 1) mod n, takes ServeList[i] as the candidate serving master node, sends a service node liveness probe request to it; and executes step 1.3.

[0065] (2) Transaction transmission phase. In this phase, the process from transaction generation to its transmission to the serving master node is mainly described.

[0066] 2.1 The user generates a transaction through the client of the blockchain system and sends the transaction to the blockchain service node.

[0067] 2.2 The service node that receives the transaction determines whether it is the serving master node: if not, it forwards the transaction to the serving master node to execute step 3.1.

[0068] (3) Expansion phase: This phase describes the process in which the serving master node uses a cuckoo filter to expand the single-chain structure into a directed acyclic graph when it receives a large number of transactions.

[0069] 3.1 If the serving master node receives more than a certain number of transactions within one second, it extracts the transaction initiator of each transaction and sequentially queries whether the transaction initiator exists in the cuckoo filters in the cuckoo filter list.

[0070] 3.2 Through the query request in step 3.1, find the first cuckoo filter that satisfies the condition that the transaction initiator does not exist in this cuckoo filter. If there is no such cuckoo filter, create a new cuckoo filter, add it to the end of the cuckoo filter list, as the cuckoo filter that meets the above conditions.

[0071] 3.3 Try to insert the transaction and the transaction initiator into the cuckoo filter found in step 3.2.

[0072] 3.4 If the cuckoo filter at the head of the cuckoo filter list is full, or the timer times out, the transactions are divided according to the transaction initiators in the cuckoo filter, and then multiple threads are used to pack the divided transactions into multiple blocks in parallel, and then the blocks are distributed to other service nodes.

[0073] 3.5 After the serving master node receives the distribution confirmation requests from more than half of the service nodes, it parallel-links the blocks that are confirmed for distribution in a short time to the last newly generated block.

[0074] 3.6 The service master node deletes the corresponding transaction initiator in the confirmed distributed block from the cuckoo filter at the head of the cuckoo filter list. If the cuckoo filter becomes empty after deleting the transaction initiator, the service master node deletes the cuckoo filter from the list, makes the next cuckoo filter become the element at the head of the new cuckoo filter list, and starts timing.

[0075] (4) Divergence stage: This stage describes the process of the blockchain system recording transactions under the structure of a directed acyclic graph when transactions are frequent.

[0076] 4.1 For the second cuckoo filter in the cuckoo filter list, the service master node queries whether the transaction initiator in it exists in the first cuckoo filter of the cuckoo filter list.

[0077] 4.2 If it exists: then query the next transaction initiator in the second cuckoo filter; otherwise, delete the transaction initiator from the second cuckoo filter and add it to the first cuckoo filter of the cuckoo filter list until the capacity of the first cuckoo filter in the cuckoo filter list is full or the second cuckoo filter does not contain any transaction initiators. And if the second cuckoo filter in the cuckoo filter list becomes empty during the deletion process, delete the empty cuckoo filter.

[0078] 4.3 After searching the second cuckoo filter in step 4.2 or the first cuckoo filter has reached the maximum capacity, the cuckoo filter list starts timing again.

[0079] 4.4 After the timer times out to the specified time, the service master node divides the transactions according to the unprocessed transaction initiators in the first cuckoo filter of the cuckoo filter list, then uses multiple threads to parallelly package the divided transactions into multiple blocks, and then distributes the blocks to other service nodes.

[0080] 4.5 If the service master node receives distribution confirmation requests from more than half of the service nodes, it parallelly links the blocks confirmed for distribution in a short time to the most recently confirmed distributed block to expand the directed acyclic graph structure.

[0081] 4.6 Operate the cuckoo filters in the cuckoo filter list in the same way as in step 3.6.

[0082] (5) Convergence stage: This stage describes how the blockchain system converges from a directed acyclic graph to a single-chain structure when transactions are not frequent.

[0083] 5.1 If the service master node only receives a single transaction within one second, first query whether the transaction originator of this transaction exists in the cuckoo filter at the head of the cuckoo filter list: If it exists, continue to query the next cuckoo filter list until a cuckoo filter that does not contain the transaction originator is found. Add the transaction originator to the next cuckoo filter (create a new one if it does not exist) and continue to determine whether to execute step 3.1 or 5.1 based on the number of transactions received within one second; if the transaction originator is not found, execute step 5.2.

[0084] 5.2 The service master node packages the transaction into a block and broadcasts the block to each service node. After obtaining the distribution confirmation from more than half of the service nodes, link the block behind the last newly confirmed distributed block, and converge the nodes of multiple directed acyclic graphs to the newly confirmed block.

[0085] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for constructing a blockchain system based on a directed acyclic graph and a cuckoo filter, characterized in that: The method for constructing the blockchain system includes the following steps: S1. The system starts, determines the service master node, and reselects the service master node; S2. Transactions are generated and transmitted to the service master node; S3. When the service master node receives a large number of transactions, it uses the cuckoo filter to expand the single-chain structure into a directed acyclic graph; S4. When the blockchain system has frequent transactions, it records transactions under the structure of the directed acyclic graph; S5. When the blockchain system has infrequent transactions, the directed acyclic graph converges into a single-chain structure; The specific operations for the system to start, determine the service master node, and reselect the service master node are as follows: S1.1 Each service node reads the same pre-generated initial block in the configuration; after sorting the addresses of all service nodes in the configuration, write them into the service node list ServeList in each service node's configuration. Suppose there are n service nodes written into this list, and let the current master node index i = 0; S1.2 Each service node starts in the state of having no service master node. After starting, it defaults to using the (i - 1)-th node in the ServeList[i] service node list as the standby service master node and sends a survival probe request; S1.3 The ServeList[i] node responds to the survival probe request one by one and regularly broadcasts its own survival heartbeat message; S1.4 After the other service nodes receive the survival probe response or the heartbeat message of ServeList[i], they broadcast the survival confirmation message of ServeList[i]; S1.5 After the other nodes receive more than (n / 2) heartbeat messages or survival confirmation messages from different sources regarding the current standby service master node ServeList[i], they set the current standby service master node as the service master node, and the master selection is completed; otherwise, execute step S1.7; S1.6 If the other service nodes do not receive the heartbeat message of the service master node ServeList[i] within a certain period of time, they broadcast a re-election master request; S1.7 The node that receives the re-election master request determines whether it has recently received the heartbeat message of the current service master node: if not, it sends a response agreeing to the re-election; otherwise, it sends a response rejecting the re-election; S1.8 After the node receives more than (n / 2) re-election requests regarding ServeList[i] from different sources, it calculates i = (i + 1) mod n, uses ServeList[i] as the standby service master node, and sends a service node survival probe request to it; and executes step S1.3; The specific operations for transactions to be generated and transmitted to the service master node are as follows: S2.1 The user generates a transaction through the client of the blockchain system and sends the transaction to the blockchain service node; S2.2 The service node that receives the transaction determines whether it is the service master node; The specific operation for the service master node to use the cuckoo filter to expand the single-chain structure into a directed acyclic graph when receiving a large number of transactions is: S3.1 If the service master node receives more than a certain number of transactions within one second, it extracts the transaction initiator of each transaction and sequentially queries whether the transaction initiator exists in the cuckoo filters in the cuckoo filter list; S3.2 Through the query request in step S3.1, find the first cuckoo filter that satisfies the condition that the transaction initiator does not exist in this cuckoo filter; if there is no such cuckoo filter, create a new cuckoo filter and add it to the end of the cuckoo filter list as the cuckoo filter that meets the above conditions; S3.3 Try to insert the transaction and the transaction initiator into the cuckoo filter found in step S3.2; S3.4 If the cuckoo filter at the head of the cuckoo filter list is full or the timer times out, divide the transactions according to the transaction initiators in the cuckoo filter, then use multiple threads to parallelly package the divided transactions into multiple blocks, and then distribute the blocks to other service nodes; S3.5 After the service master node receives the distribution confirmation requests from more than half of the service nodes, parallelly link the blocks confirmed for distribution in a short time to the last newly generated block; S3.6 The service master node deletes the corresponding transaction initiator from the cuckoo filter at the head of the cuckoo filter list. If the cuckoo filter becomes empty after deleting the transaction initiator, delete this cuckoo filter from its list, make the next cuckoo filter become the element at the head of the new cuckoo filter list and start timing; In the case of frequent transactions, the specific operations for recording transactions in the directed acyclic graph structure of the blockchain system are as follows: S4.1 For the second cuckoo filter in the cuckoo filter list, the service master node queries whether the transaction initiator exists in the first cuckoo filter in the cuckoo filter list; S4.2 If it exists: then query the next transaction initiator in the second cuckoo filter; otherwise, delete the transaction initiator from the second cuckoo filter and add it to the first cuckoo filter in the cuckoo filter list until the capacity of the first cuckoo filter in the cuckoo filter list is full or the second cuckoo filter does not contain any transaction initiators; and if the second cuckoo filter in the cuckoo filter list becomes empty during the deletion process, delete this empty cuckoo filter; S4.3 After searching the second cuckoo filter in step S4.2 or the first cuckoo filter has reached the maximum capacity, the cuckoo filter list starts timing again; S4.4 After the timer times out to the specified time, the service master node divides the transactions according to the unprocessed transaction initiators in the first cuckoo filter in the cuckoo filter list, then uses multiple threads to parallelly package the divided transactions into multiple blocks, and then distributes the blocks to other service nodes; S4.5 If the service master node receives the distribution confirmation requests from more than half of the service nodes, parallelly link the blocks confirmed for distribution in a short time to the most recently confirmed distributed block to expand the directed acyclic graph structure; S4.6 Operate on the cuckoo filters in the cuckoo filter list in the same way as step S3.6; In the case of infrequent transactions, the directed acyclic graph converges into a single-chain structure, and the specific operations are as follows: S5.1 If the service master node only receives a single transaction within one second, first query whether the transaction initiator of this transaction exists in the cuckoo filter at the head of the cuckoo filter list: If it exists, continue to query the next cuckoo filter list until a cuckoo filter that does not contain the transaction initiator is found. Add the transaction initiator to the next cuckoo filter. If such a cuckoo filter does not exist, create a new one, and continue to decide whether to execute step S3.1 or S5.1 based on the number of transactions received within one second; if the transaction initiator is not queried, execute step S5.2; S5.2 The service master node packages the transaction into a block and broadcasts the block to each service node. After obtaining the distribution confirmation from more than half of the service nodes, link the block behind the last latest confirmed distributed block, and converge the nodes of multiple directed acyclic graphs to the latest confirmed block.

Images