DAG-based multi-zone parallel consensus method

Abstract

The present invention relates to blockchain technology, and in particular to a DAG-based multi-zone parallel consensus method, comprising: a multi-chain network comprising a plurality of consensus zones, each consensus zone comprising a plurality of consensus nodes, and each consensus zone selecting a consensus algorithm; each consensus zone maintaining a blockchain, and when said blockchain selects one block from the current blockchain i and selects one block from any other blockchain j to jointly provide parameters to generate a new block, verifying the validity of the generated block; and if said block is valid, using said block to update a main chain where said block is located, so as to complete consensus. According to the present invention, the interoperability of blockchains is improved while data isolation is ensured, so that many different types of consensus systems can interoperate in an untrusted environment, thereby allowing open and closed networks to access each other.

Description

A multi-partition parallel consensus method based on DAG Technical Field

[0001] The present invention relates to blockchain technology, and in particular to a DAG-based multi-partition parallel consensus method. Background Art

[0002] Current blockchain architectures face numerous challenges, particularly regarding performance, scalability, and interoperability. Furthermore, many current blockchain applications, such as Bitcoin, are limited by the capacity of a single physical machine, resulting in low resource efficiency. The ideal solution to these problems is to allow multiple parallel blockchains to interoperate while maintaining security, improving transaction efficiency through multi-shard consensus and parallelizing transactions. This approach increases concurrency while ensuring data isolation. Currently, multi-shard consensus can be broadly categorized into three types: centralized or multi-level notary schemes, hash-locked transactions (HTLCs), and sidechain technology.

[0003] Based on sidechain technology, Cosmos was proposed. Cosmos is a network connecting many independent blockchains. Using a Tendermint-based hub (the Cosmos hub), different decentralized ledgers (zones) can send transactions to each other via the Inter-Blockchain Communication (IBC) protocol, improving interoperability between different blockchain platforms.

[0004] Furthermore, Gavin Wood proposed Polkadot, a scalable, heterogeneous multi-chain architecture. Unlike previous single chains that focused on providing varying degrees of versatility for potential applications, Polkadot's design inherently provides no inherent application functionality. Instead, Polkadot provides a foundational "relay chain" upon which a large number of verifiable, globally consistent, and dynamic data structures can be hosted in parallel.

[0005] However, the above solutions still have some limitations. For example, Cosmos and Polkadot as side chains require trust in dedicated blockchains, which will be detrimental to the decentralized nature of blockchains.

[0006] Summary of the Invention

[0007] In order to solve the data isolation and interoperability problems in blockchain technology applications, improve the scalability and concurrency of blockchain, and ensure security, the present invention proposes a multi-partition consensus method based on multi-chain parallel blockchain, which specifically includes the following steps:

[0008] In a multi-chain network, there are multiple consensus partitions, each of which includes multiple consensus nodes, and each consensus partition selects a consensus algorithm;

[0009] Each consensus partition maintains a blockchain. When the blockchain selects a block from the current blockchain i and any other blockchain j, they jointly provide parameters to generate a new block and verify the validity of the generated block.

[0010] If the block is valid, it will be used to update the main chain where the block is located to complete the consensus.

[0011] Furthermore, in the i-th consensus partition, a block is selected from the current blockchain i and any other blockchain j to jointly provide parameters to generate a new block B. ij , Block B ij The validity verification process includes the following steps:

[0012] When generating a block, the parameters selected from its own consensus partition are called the first parameters, and the parameters selected from other consensus partitions are called the second parameters;

[0013] Search for blocks that meet the conditions in each consensus partition. If block B that meets the conditions is found in the zth consensus partition, zl and B zk On different forks, block B ij invalid;

[0014] Among them, block B zl For block B ij The first parameter or second parameter required for the generation of any predecessor block in the consensus partition comes from block B in the zth partition. zl Block B zk The first parameter or the second parameter required for generating any predecessor block in the consensus partition where the non-block Bij is located comes from the block in the zth partition.

[0015] Furthermore, a predecessor block is selected from the partition where the new block is generated and other partitions respectively, and a new block is generated based on the consensus algorithm of the partition according to the two selected predecessor blocks.

[0016] Furthermore, the process of selecting a predecessor block from the partition where the new block is generated includes:

[0017] Where E represents the set Zone_Children(B ij ) in the zone; Zone_Children(B) indicates the direct verification block B in the i-th zone ij Children(E) represents the set of blocks that directly or indirectly verify block E in the i-th partition or other partitions; Q F.zoneItra (F) represents the weight value of block F itself.

[0018] Furthermore, Q F.zoneItra (F) is inversely proportional to the block generation rate.

[0019] Furthermore, when generating a new block, the process of selecting predecessor blocks from other partitions includes:

[0020] Calculate the cumulative weight of the block, which is the sum of the weight of the block itself and the weights of all blocks that prove the block;

[0021] Select blocks with cumulative weights between [W, 2W];

[0022] Place N particles on the selected block, and the particles perform a random walk. During the random walk, the block that can serve as the predecessor module is selected as the target block, and the block that can prove the current block is selected as the relay block candidate;

[0023] The probability of a block in the relay block candidate being selected as a relay block is calculated based on the cumulative weight of the current block and the cumulative weight of the relay block;

[0024] The particle that arrives at the destination node first uses the currently arrived block as the selected predecessor block;

[0025] Where W is the weight accumulation threshold.

[0026] Furthermore, the current block X is calculated based on its cumulative weight W. X and the cumulative weight W of relay block Y Y Calculate the probability of being selected as a relay node, which is expressed as Among them, α is a positive number and e is a natural constant.

[0027] Furthermore, when the cumulative weight of a new block reaches a set threshold, the new block is published to the corresponding blockchain. The cumulative weight of the new block is the sum of the cumulative weights of all blocks that verify the new block.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] 1. Propose an innovative multi-partition consensus mechanism for multi-chain parallel blockchains, which improves blockchain interoperability while ensuring data isolation, enabling many different types of consensus systems to interoperate in an untrusted environment, thereby allowing open and closed networks to access each other;

[0030] 2. Based on multi-partition consensus technology to ensure decentralization, it does not rely on trusting dedicated blockchains or trusted third parties to achieve multi-partition consensus and inter-blockchain operations;

[0031] 3. Improve the performance and scalability of blockchains, increase concurrency, and ensure the security of blockchains while achieving interoperability between different blockchains, avoiding rollback issues and reducing the probability of successful double-spending attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG1 is a schematic diagram of a calculation process of cumulative weight in the present invention;

[0033] FIG2 is a schematic diagram 2 of the calculation process of the cumulative weight in the present invention;

[0034] FIG3 illustrates block generation in a multi-partition consensus method based on a multi-chain parallel blockchain according to the present invention;

[0035] FIG4 is a schematic diagram of the general process of executing a cross-chain transaction in the present invention;

[0036] FIG5 is a schematic diagram of the general process of a double-spending attack in the present invention;

[0037] Figure 6 shows double-spending attack cases, (a) is double-spending case 1, (b) is double-spending case 2, and (c) is double-spending case 3.

[0038] FIG. 7 is a diagram of P in the present invention. S Schematic diagram of the relationship with m;

[0039] FIG8 is a flowchart of a DAG-based multi-partition parallel consensus method of the present invention. DETAILED DESCRIPTION

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

[0041] The present invention proposes a multi-partition consensus method based on a multi-chain parallel blockchain, as shown in FIG8 , which specifically includes the following steps:

[0042] In a multi-chain network, there are multiple consensus partitions, each of which includes multiple consensus nodes, and each consensus partition selects a consensus algorithm;

[0043] Each consensus partition maintains a blockchain. When the blockchain selects a block from the current blockchain i and any other blockchain j, they jointly provide parameters to generate a new block and verify the validity of the generated block.

[0044] If the block is valid, it will be used to update the main chain where the block is located to complete the consensus.

[0045] In the present invention, the concept of DAG is applied. Compared with the traditional distributed ledger blockchain that stores and verifies transactions one block after another, DAG regards each transaction as a block, and each transaction can be linked to multiple previous transactions for verification.

[0046] In a directed acyclic graph (DAG), every transaction directly contributes to the maintenance of the entire network. Once a transaction is initiated, it is broadcast directly to the entire network, skipping the miner block-packaging phase. This reduces the time required to package transactions and generate blocks, improving the blockchain's efficiency. Over time, all transaction blockchains become interconnected, forming a graph-like structure.

[0047] In this embodiment, the system includes multiple partitions, each partition maintains a blockchain, and different blockchains can use different block generation procedures. For example, any block generation algorithm from existing technologies such as PoW, PPCoin (Proof of Coin-age), and PoSpace can be used. A block requires the hash value of blocks selected from the current partition and other partitions.

[0048] The present invention proposes the concepts of block self-weight and cumulative weight. As shown in Figure 1, each box represents a transaction. The small number in the lower right corner of each box represents the block's own weight. The self-weight generally does not change, while the number in the middle represents the cumulative weight. The cumulative weight increases with the number of other blocks that the block directly or indirectly verifies. For example, transaction F has a self-weight of 3. Transaction F is directly or indirectly selected by transactions A, B, C, and E. F's cumulative weight is 9 = 3 + 1 + 3 + 1 + 1, which is the sum of F's own weight and the weights of A, B, C, and E. Successfully issued transactions will not be confirmed until their cumulative weight reaches a pre-set threshold. If a block X with a self-weight of 3 appears and has not verified other blocks, the cumulative weight of the block is only its own weight. The cumulative weight of other blocks (or transactions; the present invention packages transactions and publishes them as a block) that have verified the block increases.

[0049] In the top diagram of Figure 1, the unselected transactions are A and C, meaning they have not directly or indirectly verified any other transactions. When a new transaction X arrives and verifies A and C, X becomes the only tip, and the cumulative weight of all other transactions increases by 3 (X's own weight).

[0050] For a DAG node, its height is the length of the longest path toward the origin (i.e., the genesis block in the diagram), and its depth is the length of the longest reverse path to a particular tip. In Figure 2, G has a height of 1 and a depth of 4 because the reverse path is F, D, B, and A, while D has a height of 3 and a depth of 2. Furthermore, by definition, in Figure 2, the only tips are A and C. Transaction A directly or indirectly selects transactions B, D, F, and G, so A's score is 1+3+1+3+1=9. Similarly, C's score is 1+1+1+3+1=7.

[0051] To understand the relevant definitions in DAG, we can assume that the weight of all transactions is equal to 1. Under this assumption, the cumulative weight of transaction X is 1 + the number of transactions that directly or indirectly approve X, and the score is 1 + the number of transactions that X directly or indirectly approves.

[0052] This paper designs a multi-zone consensus method, which primarily involves multiple consensus zones, each containing multiple consensus nodes. Nodes within a zone must reach consensus. Each zone maintains its own ledger, and multiple zones can be connected to form a multi-chain system. Therefore, competing block packaging and transaction confirmation can be performed independently and in parallel, maintaining a stable block production rate and addressing the issue of excessive resource consumption caused by block generation.

[0053] In this invention, a distributed aggregation group (DAG) structure is used to coordinate chain state updates across all partitions. While transactions are the fundamental unit of the ledger in traditional DAG consensus, the fundamental unit of the DAG ledger in this invention consists of blocks generated across all partitions. Technically, DAG has demonstrated its scalability potential, but it also faces inherent limitations. For example, the stability and security of system performance are affected by network load. However, this invention, by combining the stable block production speed provided by multiple consensus partitions, can provide a scalable, distributed, and stable solution.

[0054] In addition, in order to meet the differentiated consensus ranges required by different applications, different partitions may use different consensus algorithms. In the face of multi-partition consensus, when the overall node competitiveness is divided into multiple partitions, how to deal with double-spending attacks in a single partition becomes a major problem. Based on this problem, the present invention adopts an improved main chain determination algorithm and block verification algorithm. The main chain of each partition is determined based on the cumulative weight of the DAG ledger. Therefore, it is not the individual nodes scattered in the partition that prevent the data of each chain from being tampered with, but the cumulative competitiveness of the honest nodes in all partitions. In other words, the multi-partition consensus mechanism makes attacking a single partition as difficult as attacking the entire blockchain system.

[0055] This paper proposes an innovative multi-partition consensus mechanism to solve the security and consensus mechanism limitations problems faced by existing blockchain partitions, and enables the operation of different consensus algorithms in multiple partitions.

[0056] In order to meet the differentiated consensus ranges required by different applications, different partitions may use different consensus algorithms. In the face of multi-partition consensus, when the overall node competitiveness is divided into multiple partitions, how to deal with double-spending attacks in a single partition becomes a major problem. Based on this problem, the present invention adopts an improved main chain determination algorithm and block verification algorithm. The main chain of each partition is determined based on the cumulative weight of the DAG ledger. Therefore, it is not the individual nodes scattered in the partition that prevent the data of each chain from being tampered with, but the cumulative competitiveness of the honest nodes in all partitions. In other words, the multi-partition consensus mechanism makes attacking a single partition as difficult as attacking the entire blockchain system.

[0057] In this embodiment, as shown in Figure 3, when a new block is to be generated in a partition, a block is selected from the blockchain in the partition as a tip, and a block is selected from the blockchain in another partition as a tip. The block is generated based on the selected tip, the generated new block is verified, and the verified block is published to the blockchain. The process of multi-partition consensus includes the following steps:

[0058] 1. Tip selection within a partition

[0059] In this invention, each partition maintains a single chain. When selecting a Tip within a partition, the main chain Tip block is selected based on the DAG structure and the main chain determination algorithm, and its hash value is used as the hashIntra of the new block. Specifically, the process of selecting a predecessor block from the partition where the new block is generated includes:

[0060] Where E represents the set Zone_Children(B ij ) in the zone; Zone_Children(B) indicates the direct verification block B in the i-th zone ij Children(E) represents the set of blocks that directly or indirectly verify block E in the i-th partition or other partitions; Q F.zoneItra (F) represents the weight value of block F itself; B ij Select a block from the current blockchain i and any other blockchain j and provide parameters to generate a new block.

[0061] 2. Tip selection between partitions

[0062] The process of selecting predecessor blocks from other partitions includes:

[0063] Calculate the cumulative weight of the block, which is the sum of the weight of the block itself and the weights of all blocks that prove the block;

[0064] Select blocks with cumulative weights between [W, 2W];

[0065] Place N particles on the selected block, and the particles perform a random walk. During the random walk, the block that can serve as the predecessor module is selected as the target block, and the block that can prove the current block is selected as the relay block candidate;

[0066] The probability of a block in the relay block candidate being selected as a relay block is calculated based on the cumulative weight of the current block and the cumulative weight of the relay block;

[0067] The particle that arrives at the destination node first takes the currently arrived node as the selected predecessor block;

[0068] Wherein, W is the weight accumulation threshold. This value is balanced with the scale of the network, the transaction volume, and the computing power of the node. Those skilled in the art can obtain a final threshold parameter based on specific simulation data, and will not be described in detail in this embodiment.

[0069] Preferably, the current block X is calculated based on its cumulative weight W X and the cumulative weight W of relay block Y Y Calculate the probability of being selected as a relay node, which is expressed as Among them, α is a positive number and e is a natural constant.

[0070] 3. Block Generation

[0071] After a user initiates a transaction, the chain node receives the message. Within the system, there are intra-chain transactions (txIntra) and inter-chain transactions (txInter). Each transaction can be summarized as having two types of operations: Input (denoted by In, representing a payment transaction) and Output (denoted by Out, representing a payment transaction). Regardless of the transaction model used, transaction processing can be explained by the logical dependency relationship between Input and Output. Out.i is the output of the transaction initiator, and Out.r is the output of the transaction recipient. Because the transaction initiator and recipient belong to different blockchains, the input and output dependencies of txIntra and txInter are different, resulting in different transaction processing in the system.

[0072] The chain node of blockchain y initiates the transaction as the transaction initiator. In the multi-partition consensus, different partitions may adopt different blockchain consensus mechanisms, such as PoW, PoS, etc. According to the consensus algorithm used and the selected hashIntra and hashInter, the transaction will be encapsulated as a new block B in blockchain y. yh , when the new block B yh Directly or indirectly references B generated by blockchain z zi Block, and B zi If the recipient of the transaction is a cross-chain transaction in blockchain y, then B zi The cross-chain transaction contained in will be encapsulated into the new block B yh After the block producer generates a block, it broadcasts the block in the network and sends it to other partition nodes. The hashIntra contained in the block is the hash value of the block selected from the partition, and hashInter is the hash value of the block selected from other partitions.

[0073] 4. Block Verification

[0074] After receiving a block, a node must verify the legitimacy of both the transaction and the block to update the local blockchain. This prevents the spread of invalid blocks and protects against distributed denial of service (DDoS) attacks, safeguarding the blockchain's security. This process primarily involves two parts: transaction verification and block verification.

[0075] Transaction verification is the process of checking the legitimacy of transactions. In some consensus mechanisms, nodes may also need to verify the legitimacy of transactions in the block and the legitimacy of the block producer, verifying the correctness of the transactions and the consistency of the nodes' execution of the transactions.

[0076] Block checking is to check whether the block meets the requirements of the blockchain. By traversing the blockchain, find B ij The ancestor block (belonging to B ij The intra and inter blocks selected by partitioning are the blocks with the highest z partition, B ij and its ancestor blocks (not belonging to B ij The intra and inter blocks selected by the partition are in the highest block of the z partition, and are verified to be not on different forks, which meets the requirements of the blockchain and avoids double spending attacks.

[0077] Specifically, verify that in the i-th consensus partition, select a block from the current blockchain i and any other blockchain j to jointly provide parameters to generate a new block B ij , Block B ij The validity verification process includes the following steps:

[0078] When generating a block, the parameters selected from its own consensus partition are called the first parameters, and the parameters selected from other consensus partitions are called the second parameters;

[0079] Search for blocks that meet the conditions in each consensus partition. If a block B that meets the conditions is found in the zth consensus partition, zl and B zk On different forks, block B ij invalid;

[0080] Among them, block B zl For block B ij The first parameter or second parameter required for the generation of any predecessor block in the consensus partition comes from block B in the zth partition. zl Block B zk Non-block B ij The first parameter or the second parameter required for generating any predecessor block in the consensus partition comes from the block in the zth partition.

[0081] 5. Transaction execution and main chain update

[0082] When the new block B ij After verification, the blocks in the system can be updated and transactions can be executed to update the ledger. As shown in Figure 4, for txIntra, the ledger state updates of the transaction initiator and the recipient are recorded in the same ledger because they belong to the same blockchain. zn (Blockchain #z midchain node #n) and receiver M zm When (blockchain #z midchain node #m) are in the same blockchain, the In, Out.i, and Out.r operations of txIntra in the block encapsulated by the transaction can be executed simultaneously.

[0083] For txInter, i.e., cross-chain transactions, if the block is generated in the same partition as the initiator of the cross-chain transaction, the corresponding In and Out.i blocks will be executed to update the ledger. If the block is generated in the same partition as the recipient of the cross-chain transaction, the corresponding Out.r block will be executed to update the ledger.

[0084] This paper proposes a DAG-based multi-partition parallel consensus mechanism to address the security and consensus mechanism limitations faced by existing blockchain partitions, enabling the operation of different consensus algorithms in multiple partitions. The following analyzes the performance and security of the blockchain architecture of this invention.

[0085] As shown in Figure 5, the general process of a double-spending attack includes the following steps:

[0086] 1. At time T1, the payment transaction sent by the malicious organization to the merchant is encapsulated in block B 12 Waiting for selection.

[0087] 2. At time T2, the transaction that conflicts with the payment transaction is encapsulated in B, a parasitic chain private to the malicious organization. 13 In the block, it should be noted that there is no clear order between T1 and T2. For ease of understanding, in this embodiment, T1 is assumed to be earlier than T2 in FIG. 5 .

[0088] 3. At T3 = T d +T1, where T d The expected confirmation delay refers to the time delay when the cumulative weight of a block reaches a specified threshold after it is published to the blockchain, that is, the confirmation threshold W(T d )=wThe required delay, and then the merchant sends the corresponding goods to the malicious organization.

[0089] 4. After the goods are exchanged, the malicious organization will announce its parasitic chain. h (t) is the cumulative weight of the honest chain at time t, Y m (t) is the cumulative weight of the malicious parasitic chain at time t. Y(t) = Y m (t)-Y h (t) is the cumulative weight difference between the malicious parasitic chain and the honest chain at time t. At time T3, if Y(t)>0, the double-spending attack is successful. Otherwise, the malicious organization will continue to expand the malicious parasitic chain until Y(t')>0 and t'>T3.

[0090] The probability of a successful double-spending attack (P s ) is: P s =P{Y(T3)>0}+P{Y(T3)≤0,Y(t')>0}

[0091] The relationship between the probability of a successful double-spending attack and m is shown in Figure 7.

[0092] Let p y (k d ,T d ) is the probability distribution function of Y(t+T1), where k d is the cumulative weight difference between the malicious parasitic chain and the honest chain at time t, then the probability of a successful double-spending attack at time T3 is:

[0093] In addition, the probability of a double-spending attack succeeding after T3 is:

[0094] Let λ im>0 is the block generation speed of the malicious organization in the i-th partition. For the three double-spending attack scenarios, this embodiment will describe how they increase the cumulative weight of their parasitic chains:

[0095] In case 1 shown in Figure 6(a), the double-spending attack is launched only in a single partition #1 by the malicious chain maintainer. The cumulative weight growth rate of the malicious parasitic chain is Qλ 1m , Q is the block’s own weight;

[0096] In case 2 shown in Figure 6(b), the colluder attempts to generate a 33 The block is used to cross-chain verify the malicious parasitic chain. However, the block will be judged as an invalid block, and the cumulative weight growth rate of the malicious parasitic chain in Case 2 is still Qλ 1m ;

[0097] In case 3 shown in Figure 6(c), the block B generated by the conspirators is 33 is valid, then, considering that all partitions have accomplices, the cumulative weight growth rate of the parasitic chain is (When λ im ≥0).

[0098] In summary, the cumulative weight growth rate of the malicious parasitic chain in the three cases can be expressed by the general expression as follows:

[0099] It is an indicator of the overall cumulative weight growth rate of the malicious parasitic chain. The value of m is determined by the malicious block generation ability. The higher m is, the more dangerous it is. t0 is the duration of the adaptation period, that is, the time from the generation of the block to the time it is directly or indirectly selected by all other partitions. Since T d >t0, we can conclude that T3=T d +T1≥t0+T1. According to the cumulative weight growth rate formula, the cumulative weight growth rate of the honest chain after T3 is nQλ, where n is the number of partitions. This leads to a very important property: in this invention, a block cannot recognize both the honest chain and the parasitic chain at the same time. This results in the independent cumulative weight growth of the parasitic chain and the honest chain. Then, the probability that a new block is generated by an honest block and the probability that it is generated by a malicious block are:

[0100] The probability that a malicious organization will equalize the weight difference after T3 is:

[0101] For a malicious parasitic chain, its cumulative weight growth is a Poisson process because it is the sum of the Poisson processes of independent block generation in all regions. Then, Y m The probability distribution function of (t+T2) is:

[0102] In this formula, k m is the cumulative weight of the parasitic chain at time t.

[0103] For the honest chain, its cumulative weight growth is a non-homogeneous Poisson process, then Y h The probability distribution function of (t+T1) is:

[0104] In this formula, k h is the cumulative weight of the honest chain at time t.

[0105] Consider an extreme strategy where a collusion of malicious nodes does not launch an attack before generating an honest block. Then, we can assume that T2 equals T1, meaning that both the honest and malicious nodes start generating blocks at the same time. Therefore, as the difference of two independent Poisson processes, the probability distribution function of Y(t+T1) is:

[0106] Among them, k d is the cumulative weight difference between the malicious parasitic chain and the honest chain at time t, I kd (z) is the improved Bessel function of the first kind.

[0107] To summarize, the probability of a successful double-spending attack is:

[0108] Figure 6 illustrates this security enhancement under different n, where T d Set to 1, the index of the cumulative weight growth rate of the malicious parasitic chain is m; n = 3 on the curve (m, P s )=(3,1) means when n=3, single area (P s =1) is the safety margin This is greater than 50% of PoW. At the same time, the security margin is 80% when n=4, 83.3% when n=5, and 85.7% when n=6. That is, as n increases, the security margin of a single area will further increase.

[0109] To verify the security and consistency of cross-chain transaction execution in the present invention, a real system was implemented using C++. A malicious node was simulated in a real environment to evaluate the consistency of transactions between different blockchains. The security of the present invention was demonstrated based on simulation experiments. It was proved that the present invention can ensure the consistency of transaction execution when conducting cross-chain transactions between different blockchains. Specifically, the following steps were included:

[0110] Set up n independent single chains in the blockchain system, add malicious nodes to the blockchain#, and the malicious nodes first synchronize with the entire blockchain network to obtain data;

[0111] Malicious nodes will begin to build private forks in an attempt to tamper with the main chain content and shut down normal nodes to simulate a 51% attack. When the computing power of malicious nodes exceeds that of normal nodes, the private forks will continue to grow.

[0112] When a malicious node builds a fork longer than the original blockchain and starts a normal node, when the malicious node joins the partition and attempts to tamper with the main chain of partition #1, the block generated by the malicious node can be judged as an illegal block after block verification. After ledger synchronization, the malicious node synchronizes the ledger of the normal node, thereby achieving the failure of the malicious node attack and ensuring the consistency of transactions in different blockchains.

[0113] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A multi-partition parallel consensus method based on DAG, characterized in that Specifically, it includes the following steps: In a multi-chain network, it includes multiple consensus partitions. Each consensus partition includes multiple consensus nodes, and each consensus partition selects a consensus algorithm; Each consensus partition maintains a blockchain. When the blockchain selects a block from the current blockchain i and any other blockchain j respectively to jointly provide parameters to generate a new block, it verifies the validity of the generated block; If the block is valid, it uses the block to update the main chain where the block is located to complete consensus.

2. The multi-partition parallel consensus method based on DAG according to claim 1, characterized in that, Verify that in the $i$-th consensus partition, a new block $B$ is generated by selecting a block from the current blockchain $i$ and any other blockchain $j$ respectively to jointly provide parameters ij , block $B$ ij The validity verification process includes the following steps: When generating a block, the parameter selected from its own consensus partition is called the first parameter, and the parameter selected from other consensus partitions is called the second parameter; Search for blocks that meet the conditions in each consensus partition. If a block B that meets the conditions is found in the z-th consensus partition zl and B zk are on different forks, then block B ij is invalid; Among them, block B zl is block B ij when any one of its predecessor blocks in the consensus partition where it is located is generated, the first parameter or the second parameter comes from block B in the z-th partition zl ; block B zk is non-block B ij when any one of its predecessor blocks in the consensus partition where it is located is generated, the first parameter or the second parameter comes from the block in the z-th partition 3. The multi-partition parallel consensus method based on DAG according to claim 1, wherein When generating a new block, it selects a predecessor block from the partition where the new block is generated and other partitions respectively, and generates a new block based on the two selected predecessor blocks according to the consensus algorithm of the partition.

4. The multi-partition parallel consensus method based on DAG according to claim 3, wherein When generating a new block, the process of selecting a predecessor block from the partition where the new block is generated includes: where E represents the blocks in the set Zone_Children(B ij ); Zone_Children(B) represents the Directly verify block B in the i-th partition ij ; Children(E) represents the set of blocks that directly or indirectly verify block E in the i-th partition or other partitions; Q F.zoneItra (F) represents the weight value of block F itself.

5. A multi-partition parallel consensus method based on DAG according to claim 4, characterized in that Q F.zoneItra (F) is inversely proportional to the block generation rate.

6. The multi-partition parallel consensus method based on DAG according to claim 3, wherein When generating a new block, the process of selecting predecessor blocks from other partitions includes: Calculating the cumulative weight of the block. The cumulative weight of the block is the sum of the weight of the block itself and the weights of all blocks that prove this block; Selecting blocks with cumulative weights between [W, 2W]; Placing N particles on the selected blocks. The particles perform random walks. During the random walk, the blocks that can be used as predecessor blocks are used as destination blocks, and the blocks that can prove the current block are selected as candidate relay blocks; For the blocks in the candidate relay blocks, calculate the probability of being selected as a relay block according to the current block based on its cumulative weight and the cumulative weight of the relay block; The particle that first reaches the destination block uses the block currently reached as the selected predecessor block; Among them, W is the weight accumulation threshold.

7. A multi-partition parallel consensus method based on DAG according to claim 6, characterized in that The current block X calculates the probability of being selected as a relay node based on its cumulative weight W X and the cumulative weight W of the relay block Y Y The probability is calculated as where α is a positive number and e is the natural constant.

8. A multi-partition parallel consensus method based on DAG according to claim 1, characterized in that When the cumulative weight of the new block reaches the set threshold, the new block is published to the corresponding blockchain. The cumulative weight of the new block is the sum of the cumulative weights of all blocks that verify this new block.

Images